1 Introduction↩︎

Research on language-model privacy, memorization, and user-state behavior has become increasingly dataset-dependent. Memorization studies have used inserted canaries to measure exposure [1], web-scale extraction attacks to recover verbatim training snippets containing public PII [2], and real user traces to study privacy inference beyond memorization [3]. PII detection and redaction work has introduced synthetic span-labeled corpora such as SPY and Nemotron-PII [4], [5]. Long-term memory and personalization benchmarks use multi-session conversations, user histories, or curated profiles to test whether models can recall, update, and apply user state [6]–[9]. These lines of work show that synthetic or semi-synthetic personal data is already central to NLP research, especially when real personal data is unsafe or unreleasable.

These datasets leave a common lower-level gap. Canary studies provide controlled secrets, but not coherent people. Extraction and inference studies often depend on real web or social traces, which are difficult to redistribute, perturb, or audit as synthetic identities. PII corpora provide labeled spans in rendered text, but usually do not expose the underlying person graph that generated those spans. Memory and personalization benchmarks provide fixed conversations, histories, or user profiles for a particular evaluation, but not a scalable population from which new privacy, retrieval, dialogue, document, or agent-state datasets can be derived under the same schema and seed. The missing artifact is therefore not another single task benchmark; it is a reusable source layer: an auditable population of internally consistent synthetic people whose identifiers, relationships, employers, addresses, timelines, and provenance can be rendered into many downstream study designs.

ProfileFoundry is designed as this base layer. It provides structured adult Person Objects whose demographics, contacts, households, family links, employers, addresses, identifiers, and event histories are generated and validated together. Researchers can transform these objects into task-specific artifacts such as PII-laced text, memory entries, retrieval documents, forms, dialogue states, linkage pairs, perturbation sets, or exposure corpora while retaining a known source object and deterministic generation path. Existing resources support important pieces of this workflow, but they generally expose different layers: rendered text, task instances, learned or simulated tables, local fake fields, or domain-specific longitudinal records.

ProfileFoundry does not claim that structured synthetic profiles are new. Its distinct contribution is to separate and release a broader source artifact: a versioned schema, represented-person and employer graph, snapshot-aligned events, normalized analytical views, deterministic generator, and release-level evidence. Appendix Tables 16 and 17 record the artifact-level distinction.

ProfileFoundry is especially relevant now because language systems increasingly act through tools, memory, retrieval, and persistent user state. A source object makes controlled confounders possible: two people can share a household, employer, surname, or city without being the same person; an earlier address or job can be superseded by a later event; and rendered spans can retain links to the fields and events that produced them. The present paper establishes the source layer and its released evidence, not downstream model effectiveness.

Our contributions are:

• Person Object abstraction: a reusable Person Object with snapshot fields, graph links, typed events, reserved document hooks, and generation provenance for constructing sensitive-data-like foundation-model evaluations without releasing real user traces.

• Internally consistent linked generation: the generator first commits to household roles, represented relationships, shared addresses, employers, and snapshot facts, then derives person records, graph edges, foreign keys, and snapshot-aligned events from those commitments so linked fields simulate real person.

• Executable generator and SDK: a Python package and CLI for deterministic profile and household generation, scaled release builds, validation, export, and release-rebuild workflows.

• Audited reference release: the 100K release includes canonical JSONL, a complete viewer Parquet file, flat snapshots, normalized relational tables, manifest hashes, and a dataset card, accompanied by validation, leakage, and report-quality evidence.

• Artifact-accountability protocol: a release audit that separates distributional gaps, declared consistency, referential and temporal closure, coincidence screens, reserved-domain email checks, provenance, and documentation-drift evidence.

2 Related Work↩︎

Synthetic personal data spans privacy, personalization, agent evaluation, record linkage, statistical disclosure control, and domain simulation, but these areas usually release different artifacts. Privacy corpora expose rendered text and labels; memory benchmarks expose fixed histories or tasks; population and tabular systems expose linked records, learned relationships, or domain simulations; and fake-data libraries expose localized fields or schema-generated records. ProfileFoundry targets the reusable source layer: schema-governed Person Objects with inspectable links, typed state-changing events, normalized exports, provenance, and release-level evidence.

2.0.0.1 Privacy-rich text and PII corpora.

Language-model privacy work shows that models can memorize sensitive strings and infer private attributes without verbatim reproduction [1]–[3]. Privasis, PANORAMA, SynthPAI, SPY, Nemotron-PII, Gretel’s multilingual financial PII data, and PIIBench address releasable private text, PII/PHI detection, span labeling, de-identification, memorization, or corpus unification [4], [5], [10]–[14]. Several use profiles internally and provide substantial human or benchmark evaluation. ProfileFoundry differs at the exposed layer: it releases the structured identities, households, employers, relationships, identifiers, events, normalized views, and provenance from which text corpora can be derived, but it does not itself release rendered prose or span labels.

2.0.0.2 Personalization, memory, and private-user benchmarks.

PersonaBench, LaMP, LoCoMo, LongMemEval, and PersonaMem evaluate personal-information QA, personalized tasks, long-term conversational memory, temporal reasoning, knowledge updates, or user-aware response generation [6]–[9], [15]. LoCoMo and PersonaMem have meaningful temporal structure, and PersonaBench uses a social graph during construction. Their primary interfaces remain fixed conversations, documents, or tasks. ProfileFoundry instead makes source state reusable through stable profile IDs, represented-person links, employer IDs, relationship edges, and typed histories.

2.0.0.3 Personas and simulated behavior.

PersonaChat, Persona Hub, and generative-agent systems use persona facts, descriptions, memories, reflection, planning, or social behavior as conditioning signals [16]–[18]. Generative Agents in particular model social behavior over simulated time. ProfileFoundry is narrower in behavior and broader in release structure: it provides inspectable personal-state objects and links rather than a behavioral simulation or persona-prompt collection.

2.0.0.4 Synthetic populations, record linkage, and tabular synthesis.

Pseudopeople exposes stable simulant, household, and employer identifiers across simulated administrative records and is the closest population-level comparator [19], [20]. Synthea provides longitudinal, linked patient records within healthcare [21]. Febrl and GeCo support generation, corruption, and linkage workflows [22], [23]. synthpop, SDV, PrivBayes, and PrivSyn provide statistical, relational, sequential, or differentially private synthesis [24]–[27]. ProfileFoundry does not replace these systems; it packages a multi-locale, NLP-facing person-state layer with canonical objects, normalized views, represented links, typed events, and release evidence.

2.0.0.5 From fake fields to coupled objects.

Faker generates localized values and composite profiles, while current Mimesis schemas can express foreign-key references between generated schemas [28], [29]. ProfileFoundry uses fake-data providers at the leaf level but adds release-specific cross-field constraints, represented household and employer commitments, snapshot-aligned histories, deterministic identifiers, and audit artifacts. Its novelty is therefore the combination and exposure of these layers, not the first generation of synthetic names, profiles, households, or longitudinal records.

Appendix Tables 15, 16, and 17 summarize the closest adjacent resources and give the resource-by-resource evidence rubric.

3 Object Contract↩︎

ProfileFoundry generates from a constrained object space. A Person Object is not a bag of independent fake fields; it is a typed adult record whose snapshot fields, household references, employer links, event history, normalized rows, and provenance are generated as mutually constrained commitments. Figure 1 shows the object at the level a downstream NLP system would consume: current fields, linked household members, snapshot-aligned address and job histories, release rows, and seed and manifest metadata.

The canonical schema has four surfaces. The snapshot contains identity, contact, addresses, employment, education, finance, health, government IDs, household ID, family graph, events, reserved document hooks, and generation metadata. The graph surface contains household membership, spouse or partner links, parent–adult-child links, sibling links, colleague links, and employer IDs. The temporal surface contains typed events: , , , , , , , and . The provenance surface records global seed, profile seed, SDK version, generation date, exported timestamp, and reference manifest hash.

The schema is also an interoperability contract. The in-memory source is implemented with Pydantic models and exported as JSON Schema for non-Python consumers [30]. Canonical JSONL preserves complete nested objects, while Parquet views expose the same source record as row-counted relational tables. This separation lets one source object seed an agent-memory store, rendered document, PII-tagged passage, linkage pair, or perturbation set without discarding provenance. Appendix Table 6 maps each schema group to the release evidence that supports it.

4 Constrained Generation↩︎

4.1 Household-First Linkage↩︎

The generator implements the object contract as the cascade summarized in Appendix Figure 3. It first samples a household plan, turns that plan into member hints, materializes each person under those hints, closes links, constructs events from the finalized snapshot, and then exports audited release files. This ordering creates the conditions under which marital pins, adult-child slots, shared surnames, shared addresses, family edges, employer reuse, historical rows, and temporal constraints can be made coherent before release validation.

Generation begins with a locale-specific household composition table. For en-US, the eight implemented weights are single households at 0.285, couples without children at 0.265, couples with represented adult children at 0.190, single-parent households with represented adult children at 0.090, cohabiting households without children at 0.050, cohabiting households with represented adult children at 0.030, multigenerational households at 0.045, and unrelated-adult households at 0.045. The weights sum to one. The “child” slots in v1.0 are adult children living with parents, normally age 18–28.

Figure 2 shows the dependency map behind this household-first design and why it is not equivalent to sampling marital status and then adding dependents. Composition determines which role slots exist. Role slots then carry sex hints, age bands, marital pins, surname rules, and shared-address context into the person factory. The family builder closes the represented graph: head-spouse mutual links, cohabiting partner links, parent-child links from head and spouse to every adult-child slot, sibling links among adult children, and grandparent-to-head links in multigenerational households. When a married or cohabiting partner is not represented, the partner field is explicitly marked external rather than silently omitted or assigned a dangling profile ID.

Several small constraints are deliberately visible in the generated object. Spouse ages are sampled within an 11-year band around the head with mass near small gaps; adult-child ages are capped by the youngest represented parent; adult siblings are spaced by at least three current-age years when possible; co-residents share a home phone when one is present; and emergency contacts prefer spouse, parent, sibling, then another household adult. Current employers are assigned from a deterministic locale pool of 250 employers; compatible working adults in a household share an employer with probability 0.25. These rules support internal coherence but are modeling heuristics, not claims about every locale’s real household structure. Appendix Figure 12 shows the resulting employer and colleague-edge structure in the release.

4.2 Field Materialization and Partial Replay↩︎

Within each member slot, fields are generated in dependency order. Age is sampled first and gates downstream choices. Education zeroes out levels whose minimum completion age exceeds the sampled age: Bachelor requires age 21, Master 22, and Doctorate 25. Marital status is sampled by age band and sex, then adjusted by feasibility rules: below the configured modeling floor the state is Single; former-partner states are impossible under 19; widowhood under 40 is multiplied by 0.05; cohabiting is multiplied by 0.40 for ages 35–44 and by 0.10 for ages 45–54; and cohabiting is zero at 55+. These are generator assumptions rather than legal or demographic ground truth. Appendix Figures 4 and 5 provide the detailed visual atlas.

Occupation sampling uses education and age gates over title tiers. At age 30, a High School profile has most eligible title weight in Entry/Service and Skilled/Technical titles, whereas a Bachelor profile shifts mass toward Professional/Analyst and Management/Executive titles. Master and Doctorate profiles are hard-blocked from Entry/Service, while some overqualification paths remain possible at small weights; Appendix Figure 6 summarizes which field combinations are blocked, bent, or kept as weighted outliers. Title tier bounds salary; salary percentile drives finance tier; and credit scores use locale-specific bureau scales. The US release uses FICO 300–850 with tier centers 480, 580, 680, 740, and 790, while non-US locales use explicit scale labels in the schema. These coupled heuristics can encode socioeconomic assumptions and are documented as limitations.

After link closure, temporal history is constructed from the finalized snapshot rather than sampled independently. This avoids stale timeline rows caused by linkages or current fields changing after draft events were sampled. The event backfill always includes birth, appends the current move when an address exists, appends the current job-change when employment exists, aligns represented-spouse marriage dates, emits name-change and divorce events when the snapshot implies them, and samples prior moves or jobs only when enough lifetime span exists. Validation checks that the latest covered move and job events agree with current address and employment, that address rows retain source-event IDs, and that events do not predate DOB. This is snapshot-aligned history with partial replay over declared fields, not complete event sourcing of the whole Person Object. Appendix Figure 7 shows a concrete example.

Contact and ID fields are also downstream of earlier commitments. Work email depends on the final employer name and employer ID; phone formatting depends on locale and address region; personal and work emails use reserved domains following RFC 2606 [31]. Social handles are age-gated, LinkedIn requires age 16, banned-platform rules are locale-aware, and platform selection changes with age rather than being flat across the adult range.

5 Release↩︎

We distribute ProfileFoundry in two complementary forms: an executable Python package and a fixed 100K reference dataset. The package supports incremental fixes and task-specific generation under the same schema; ProfileFoundry-Synthetic-Person-Objects provides a stable, citable population without requiring users to rerun generation. Hosted access conditions and package metadata are governed by the accompanying artifacts, so the paper does not depend on an unrestricted-hosting claim.

5.1 Python Package Release↩︎

The package can be installed with . It emits the Person Object schema described above, so a generated profile can be consumed as nested JSON, converted into normalized tables, or used as a seed object for downstream NLP artifacts. Table [tab:release_package_surface] summarizes the command guide.

5.2 100K Reference Release↩︎

ProfileFoundry-Synthetic-Person-Objects is the fixed reference artifact for direct use and comparison. It is intended for users who want a stable population without rerunning the generator, while the package supports task-specific generation under the same object contract. Table [tab:release_reference_metadata] lists the release contents and reproducibility pins.

The release is deliberately more than a flat profile table. The canonical JSONL preserves nested Person Objects, while the Parquet views expose scalar, temporal, relational, household, employer, education, address, social-handle, and allergy views for downstream analysis. The 14-file local bundle contains 709,228 events, 518,564 directed relationships, 167,089 addresses, 111,955 employment rows, 74,738 education rows, 40,338 households, and 52,491 employers. Appendix Figure 8 maps the release inventory and object topology, Appendix Table 3 gives the complete row-counted inventory, and Appendix Figure 9 reports profile-level coverage.

The reference bundle and associated reports are rebuilt through the repository release workflow, "". The fixed data identity is pinned by its manifest identifier, per-file hashes, row counts, seed, and dates. Appendix Figure 18 and Table 14 record the reproducibility pin and the command-level verification checklist.

6 Audit↩︎

The ProfileFoundry-Synthetic-Person-Objects audit asks whether the reference release is usable as a synthetic person-object substrate: whether its limited population comparisons are disclosed, its declared references and covered histories resolve, its objects satisfy the implemented rules, its coincidence risks are screened, and its reports remain tied to the artifact. These forms of evidence answer different questions and are not combined into one quality score.

6.1 Population Fit and Declared Consistency↩︎

For the five full-validation locales—US, UK, IN, CA, and AU—the validator compares generated age-by-sex, education, and marital-status bucket shares with public reference tables. For each marginal, it reports the largest absolute bucket-share difference, an \(L_{\infty}\) marginal gap rather than a Kolmogorov–Smirnov statistic. Separately, it checks whether every generated object in those locales satisfies the declared structural and covered replay invariants. IE, NZ, and PH are included in the release but excluded from the locked marginal-fit table because their reference coverage is lighter.

The locked targets were maximum gap \(\le 0.10\) per attribute and mean gap \(\le 0.07\) per locale. The release does not meet the mean target, and we report the miss directly: locale means range from 0.074 to 0.089, with IN largest because its male and female age gaps are both approximately 0.124. In contrast, all 90,000 profiles in the five full-validation locales pass the declared consistency suite. This pass establishes agreement with implemented constraints; it does not independently validate the realism of those constraints, joint distributions, household topology, or event rates.

6.2 Object, Linkage, and Temporal Closure↩︎

The object audit covers age gates, address validity after DOB, phone and locale rules, reserved-domain contacts, identifier uniqueness, employer foreign keys, relationship endpoints, household closure, whole-household selection, and partial replay. Across the full 100K normalized release, relationship source and target endpoints have zero misses; employment rows and current profile employer references have zero missing employer foreign keys; household member counts sum to 100,000; and represented spouse links are mutual in 49,072 of 49,072 cases. Parent–child, partner, sibling, household-member, and colleague reciprocal commitments have zero reported reverse-edge misses. External spouse references are explicit sentinel cases rather than broken edges.

Temporal checks cover 709,228 typed events. All 167,089 address rows retain source-event identifiers, every profile has one current address, and no event predates date of birth. Latest covered move and job-change events agree with current address and employment. These checks establish source linkage and partial replay for covered fields; they do not establish complete event sourcing or realism of real-world transition rates.

6.3 Coincidence, Collision, and Drift Screens↩︎

We screen coincidence and drift separately from privacy claims: 7 repeated name+DOB tuples, 1,038 repeated name+birth-city tuples, 0 personal-email self-collisions, 0 email-syntax findings, and 342 Wikidata Bloom flags. The Bloom filter covers 683,897 humans with known birth dates and at least five sitelinks, indexing and keys at target false-positive rate \(10^{-4}\) [32]. Reserved domains make email evidence syntax/uniqueness-only; a report-quality verifier checks manuscript counts, figures, validation, leakage, and manifest metadata for drift. Appendix Figures 13, 10, and 14–17 and Appendix Tables 8, 4, 5, 9–13, and 10 give the supporting ledger, closure, inventory, leakage, and provenance evidence.

7 Downstream Use as an NLP Substrate↩︎

ProfileFoundry supports downstream datasets by rendering audited fields, links, and events into text or records; intervening through masking, corruption, updates, withholding, or temporal shifts; and evaluating outputs against canonical profile, field, relationship, and event IDs. This covers document understanding, memory and agent-state evaluation, privacy and PII rendering, and record linkage while preserving deterministic provenance and controlled near-misses: shared households, employers, cities, or surnames without identity; stale facts superseded by later events; and graph-grounded ambiguous pairs. Appendix Table 7 summarizes recommended, caveated, and discouraged uses.

8 Conclusion↩︎

ProfileFoundry argues for a different unit of synthetic personal data: not isolated fake fields, fixed personas, or unreleasable real traces, but schema-governed people whose identities, households, links, histories, exports, and provenance can be inspected together. This matters for stateful NLP because memory, privacy, document, agent, and linkage evaluations often depend on the same hidden requirement: a coherent source person that can be rendered, perturbed, partially replayed, and audited.

The v1.0 release makes that substrate concrete through an executable generator and a 100K reference population with normalized views, manifest hashes, validation reports, closure checks, coincidence screens, and reproducibility commands. The release is intentionally not presented as a perfect population model, a formal privacy mechanism, or a completed downstream benchmark. Its contribution is a reusable, accountable baseline for building evaluations in which the synthetic person behind each artifact remains visible.

9 Limitations↩︎

ProfileFoundry v1.0 is English-only, adult-only, and limited to eight locales; Faker and project-specific references constrain field coverage and cultural fidelity. Binary sex/gender conditioning, surname sharing, household composition, education–occupation mappings, salary/credit heuristics, disability/health categories, and social-platform rules are simplifying assumptions that may be narrow or stereotyped; Appendix Table 1 lists risks and disclosures. Household “children” are represented adults, so pediatric, school, custody, guardian-consent, and child-safety workflows are unsupported; family links are household-local with external-partner sentinels, limiting extended kin and non-household graphs. Several full-validation locales miss marginal targets, and the population audit covers univariate age-by-sex, education, and marital-status marginals rather than joint distributions, household composition, age gaps, graph degrees, employer structure, or event rates. Invariants test implemented rules, not realism; temporal history is snapshot-backfilled partial replay. The paper includes no downstream benchmark, human study, or household-first ablation; finance/health/ID/salary fields are synthetic plausibility attributes, and package/card/report/manifest metadata require synchronization.

10 Ethical Considerations↩︎

Synthetic person objects can still be misused for impersonation, fraud rehearsal, spam, credential testing, or misleading demonstrations. The release uses reserved email domains, excludes minors, records synthetic provenance, and publishes collision and notable-person coincidence screens. These safeguards do not provide differential privacy, proof of non-resemblance, or authorization to use generated contact-like fields outside controlled research. Generated phone numbers, government identifiers, addresses, names, and other identity-like values should not be used to contact, authenticate, evaluate, or make decisions about real people.

Because demographic and socioeconomic rules may reproduce stereotypes, downstream studies should report which fields and locales they use, preserve synthetic labeling and provenance, audit group-conditioned outcomes, and avoid treating the resource as demographic ground truth. Derived text or documents should retain the dataset card, license, and relevant risk disclosures. ProfileFoundry should not be used to train or validate consequential decision systems about real people.

11 Acknowledgments↩︎

We gratefully acknowledge the open-source and open-science infrastructure that made ProfileFoundry practical. Faker provides important localized synthetic-data providers used at the leaf-field level, while Pydantic and JSON Schema support the typed object contract and public schema export. We also thank the maintainers of the scientific Python and columnar-data ecosystem, especially NumPy, pandas, and PyArrow, as well as Hugging Face tooling and the LaTeX venue templates used to package and disseminate the release.

12 Supplementary Evidence and Reference Material↩︎

This appendix collects the supporting evidence for ProfileFoundry and follows four buckets. Appendix 12.1 documents the generation logic: the age-gated constraint atlas, the education–career–finance signature, the outlier policy, snapshot-aligned partial replay, and modeling assumptions. Appendix 12.2 describes the released artifacts, covering the Python package command surface, the 100K reference set, its inventory and object topology, per-profile coverage, household and employer graph structure, temporal surface, schema, and use guidance. Appendix 12.3 gives the audit evidence: validation against public marginals, reference-data provenance, referential and temporal closure, leakage and collision screening, invariant families, claim-to-evidence mapping, and reproducibility. Appendix 12.4 provides the resource-by-resource related-work comparison. Counts are descriptive of the fixed reference release unless a caption states otherwise. Internal consistency, distributional fit, coincidence screening, formal privacy, and downstream utility remain separate forms of evidence.

12.1 Generation Logic↩︎

These figures expand the constrained-generation mechanics summarized in the main text. Age is the master gate that conditions education, marital state, occupation, and finance; the generator then preserves plausible rare combinations rather than collapsing every profile toward the modal path, and finally reconstructs history backward from the finalized snapshot.

12.1.0.1 Generator mechanics.

The generator deliberately preserves some rare combinations after feasibility checks. These weighted outliers are different from contradictions: a doctorate holder may still appear outside high-professional work, a high-income person may still have a lower credit tier, and household members may have different employers unless a shared-employer draw fires. The validator blocks impossible or unsupported combinations, but it does not collapse every profile toward the modal path.

12.1.0.2 Assumption ledger.

Table 1 records the high-level modeling assumptions that downstream users should disclose when using generator outputs.

12.2 Released Artifacts: Package and 100K Reference Set↩︎

The release ships as both an executable Python package and a fixed 100K reference bundle. Table 2 lists the package command surface; the remaining figures and tables describe the reference set, which is an object graph rather than a flat profile table: one canonical Person Object fans out into normalized address, employment, education, event, household, employer, and relationship views.

12.2.0.1 Release use guidance.

Table 7 summarizes recommended, caveated, and discouraged uses of the released package and reference population.

12.3 Audit↩︎

Audit evidence is reported as several distinct forms rather than a single pass/fail summary. Each generation stage carries its own validator family into the release audit (Figure 14): distributional fit against public marginals, referential and temporal closure, leakage and collision screening, structural invariants, and reproducibility are stated separately.

12.3.0.1 Evidence overview.

Figure 13 and Table 8 map each headline claim about the release to the concrete public artifact that backs it and to the metric or check that verifies it. The figure is a visual ledger of this correspondence; the table states the same mapping in full.

The full-validation report uses public age-by-sex, education, and marital-status reference tables for US, UK, IN, CA, and AU. The metric is a maximum absolute bucket-share discrepancy (\(L_{\infty}\) marginal gap), not a KS statistic. The report does not tune the generator repeatedly against the target because that would overfit the release to its own audit. IE, NZ, and PH are included in the release but excluded from the locked marginal-fit and consistency table in v1.0.

12.3.0.2 Leakage methodology.

The Wikidata filter is constructed over humans with a known birth date and at least five sitelinks. The released filter covers birth years 1850–2015, contains 683,897 records, and indexes 667,179 name-year keys plus 631,907 name-city keys. Bloom filters introduce false positives; the configured target false-positive rate is \(10^{-4}\). Because the filter is a screening tool over common names and places, its output is best interpreted as a conservative coincidence rate.

The HIBP prototype audit is intentionally not a release metric. The public-email-domain prototype demonstrated that realistic patterns can overlap breached-account corpora even when no real identity was copied. The current release changes the design by using reserved domains, so the correct release audit is syntax and uniqueness rather than breached-account lookup.

12.4 Comparison with Adjacent Resources↩︎

12.4.0.1 Comparison rubric.

The main-text comparison is intentionally descriptive. The rubric below distinguishes public artifacts from generation-time internals, persistent identifiers from ordinary co-occurrence, explicit state change from timestamps, localized fields from multilingual text, and formal privacy from quality or provenance checks. The resource rows are kept individual rather than grouped into heterogeneous families.

3.1pt

3pt

Sources: [4]–[18].

3pt

Sources: [19]–[29], [33].

References↩︎