Get a demo

ADR 35: Dependent Subjects ​

Date: 2026-10-02

Status: Draft

Context ​

NeoWiki has a simple data model: Subjects contain Statements, each holding one Value. A value that needs context, such as a date with its source, becomes a Subject of its own, referenced via a Relation from the Subject it describes (Qualifiers and References).

Wikis that use CIDOC-CRM as their in-wiki model need many more small Subjects like these: names, identifiers, and births, each hanging off a bigger Subject such as a Person. One partner's model has 12 Schemas for things like people and objects, and 24 for such small Subjects.

The data model supports both, but nothing in it says that a Birth should be handled together with its Person. So NeoWiki treats every Subject as a thing of its own: the Person's editor makes you pick from all Births in the wiki rather than fill in a date and place, a subject-first wiki gives each new Birth a page of its own, and deleting a Person leaves its Births behind. NeoWiki needs to know which Subjects to handle together with another.

Decision ​

A Schema's Subjects are standalone unless the Schema declares them dependent. The declaration is made when the Schema is created and cannot be changed later; to switch, create a new Schema.

A Dependent Subject is edited, stored and removed with exactly one Host Subject: the Subject whose Relation points at it, such as the Person for a Birth.

A Person's editor and its row on the Data tab, both showing its Birth's fields inline, and the Birth on its own on Special:Subject; callouts name the Host Subject, the Dependent Subject and a standalone Subject

Each Dependent Subject:

  • Is referenced by exactly one Relation. Additional Relations to it are refused.
  • Can only be referenced by a relation property that targets Schemas with Dependent Subjects.
  • Is created in the same save that makes its Host Subject point at it. A relation property that targets Schemas with Dependent Subjects can only point at a Subject on the same page; a save that breaks this is refused, so such a Relation never points at a missing Subject.
  • Is stored on its Host Subject's page, in page-first and subject-first wikis alike (ADR 33).
  • Is removed with its Host Subject, or with the Relation to it: a save that cuts it off from every standalone Subject on the page, directly or through other Dependent Subjects, removes it. Deleting it on its own also removes the Relation to it.
  • Has no label.
  • Is never a page's Main Subject.
  • Can be the Host Subject of further Dependent Subjects.

These rules apply even on wikis with validation enforcement off (ADR 26).

Anything other Subjects need to point at, such as a Place, is a standalone Subject.

A Property Definition of type Relation cannot mix Schemas with Dependent Subjects and Schemas with standalone ones in its list of target Schemas (ADR 28).

The Relation is stored on the Host Subject and points at the Dependent Subject: the Person points at its Birth. An ontology may draw the link the other way. CIDOC-CRM does: a Birth "brought into life" a Person. A Mapping to such an ontology then uses the inverse property, here "was born", which runs from the Person to the Birth.

A relationship with no natural Host Subject, such as a marriage or an exhibition, is either a standalone Subject that points at its participants, or a Dependent Subject of one side that points at the others. In the second case, the others find it under "Referenced by" on their Special:Subject page.

Consequences ​

  • Editing: the Host Subject's editor shows a Dependent Subject's fields inline instead of a picker. If the relation property targets several Schemas, adding a Dependent Subject first asks which one.
  • Display: Special:Subject and the Data tab show a Dependent Subject inside its Host Subject, as a table where the relation property allows multiple values. A View leaves that relation property out unless its Layout names it. A Dependent Subject is named after its Schema and its Host Subject, as in "Birth of Pablo Picasso", not by the bracketed id ADR 31 would give it.
  • A Dependent Subject keeps its own id, IRI and graph node. Special:Subject and the Data tab show it and can open it for editing on its own, and queries and exports include it.
  • Finding: search shows a match in a Dependent Subject as a hit on the standalone Subject at the top of its chain of Host Subjects, so a search that matches a Birth finds the Person. Fields for choosing an existing Subject, such as a relation field in the Subject editor, never offer a Dependent Subject.
  • Creation: Schemas with Dependent Subjects are not offered where a Subject is created without a Host Subject.
  • Moving a Subject to another page takes its Dependent Subjects along. A Dependent Subject cannot be moved on its own.
  • Tracked in #1554.

Alternatives Considered ​

Other designs ​

  • User-defined records: a property whose value is a group of fields defined in its Schema, like Semantic MediaWiki's Record type. A Birth property on the Person Schema would hold a date and a place. Such a value has no ID or IRI, so it cannot be opened or queried on its own. Other Schemas can't reuse its fields, while one Name Schema can serve both Person and Organization. And a Mapping to CIDOC-CRM would still have to create a node for the Birth. Compound values with a fixed shape, such as monolingual text (ADR 34), are Value Types, not records.
  • A per-property inline flag: a relation property marked inline would show its targets' fields in the editor, while the targets stay ordinary Subjects. That changes only editing. Where a Subject is stored, when it goes, whether it needs a label and whether search offers it are about the Subject, not about one property that points at it.
  • Inferring dependence from where a Subject is created: a Birth and a Place can both be created from a Person's editor, but only the Birth is handled together with the Person; other Subjects point at the Place.

Other rules ​

  • Letting a Schema change its declaration later: turning existing standalone Subjects into Dependent Subjects would first require checking that each has exactly one referencing Relation. That needs where-used (#1039), a scan of every page, or a Graph Store.
  • Letting other Subjects point at a Dependent Subject: those Relations would turn into red links when it is removed with its Host Subject. The UI could only create such a Relation by pasting an id. And the strict rule can be relaxed later without invalidating stored data, while a permissive one cannot be tightened. The cost: a Subject cannot be both edited inline and pointed at by others. A wiki that edits rooms inside a building's form, with events that point at rooms, has to make the rooms standalone.
  • Letting a Dependent Subject have several Host Subjects, such as a Birth shared by the child and the mother: with one Host Subject, where the Birth is stored, when it is removed, what it is called and what moving does all follow from that Host Subject and its page. With Host Subjects on several pages, each becomes a question across pages, and removing the Birth with the last of them needs where-used (#1039).
  • Refusing to delete a Dependent Subject on its own: deleting a Subject through the API is never refused.
  • Storing the Relation on the Dependent Subject, pointing at its Host Subject as CIDOC-CRM draws a birth: the Person's editor would then have to edit Relations that point at the Person, which it cannot do. Stored on the Person, the Relation lets its editor reach the Birth through the Person's own Statements.