Define semantics of Main Subject and Child Subjects

[JeroenDeDauw]

Context

Wiki Pages contain a list of Subjects. (Find more details about the terminology at https://github.com/ProfessionalWiki/NeoWiki/blob/master/docs/concepts/glossary.md.)

One Subject can be marked as "Main Subject", which means it represents the same topic as the page. This allows you to say "give/show me the main subject of this page". The other Subjects on the page are called "Child Subjects".

For understanability, below is what is persisted in a wiki page (Subject bodied omitted). Note that all Subjects are in the same list, they are structurally all the same. The only difference is that the page knows what the Main Subject is by keeping track of its ID.

{
    "mainSubject": "sEpfwJLnxyQy6vR",
    "subjects": {
        "sEpfwJLnxyQy6vR": {
        },
        "sEpfwJLAtndAaaA": {
        },
        "sEpfwJLAtndBbbB": {
        },
        "sEpfwJLAtndCccC": {
        }
    }
}

You can see the full JSON via the developer UI at https://neowiki.dev/wiki/Special:NeoJson/Rijksmuseum

Question 1/2: Automatic/enforced Relation?

Our initial thinking was to automatically create a Relation between the Child Subjects and the Main Subject, which is where these names come from. We have yet to figure out what, if anything, would make sense here.

Do the Relations go from the Child Subject to the Main Subject? Or from the Main Subject to the Child Subjects? (This interacts with "Add ability to display incoming/inverse relations".)

Are these Relations enforced? If so, how? What does this look like in the editing UIs?

Question 2/2: Is the Main Subject tag useful?

What use cases actually need the "give/show me the main subject of this page" capability?

I imagine that if the wiki happens to be where you store/manage your graph, which might be most of the ECHOLOT use cases, then a link to the wiki pages might not make sense. On the other hand, if you have a wiki where you really use normal pages, so your use case is "attach structured data to my pages", then being able to say "show me what this set of pages is about" seems useful, but no one has confirmed they actually need that.

Under consideration here is dropping of the main subject tag. At which point we'd just have Subjects. The distinction between Main Subject and Child Subjects would be removed, and so would those two terms.

If we throw out the Main Subject from the core model, you could still be able to attach Subjects to Wiki Pages via the MediaWiki page property type.

[Habennin]

My vote is that having a sub subject that is not semantically linked to the main subject is meaningless. Or it is in the mind of the user (and therefore different potentially for each user), but not in the mind of the machine at all.

If all sub subjects on the page are meant to refer to the main subject then we must know HOW they refer.

e.g.:

Subject: Country
?
Sub-Subject: Population

Of course, the human guesses, this is the population of that country. But there is no relation that is saying that. And it could be some other relation: enemy population. former population etc. etc.

So it needs to be defined, would be my argument.

[osnard]

I believe for HalloWelt's use case having the ability to set a main subject would be required. We plan to support different "document/page types", e.g. "Controlled documents", "Minutes", "Catalog entries". In all of those cases we will want to have portal pages / dashboards that list all pages of that type. Obviously this could be achieved by other means (e.g. namespaces or categories), but I believe selecting by "main subject" is more natural. We plan to use the "child subjects" only for "additional metadata sets".

Regarding Question 1: Having an easy way to get from the child to the main and from the main to the children is very important. But if I understand correctly this should already be the case with the current implementation. It's just a question of the query. If I do a query and the result contains a child subject, it should be simple to render a link to the page and access values from the main subject of that page.

I am not sure about any UI implications though.

[malberts]

What use cases actually need the "give/show me the main subject of this page" capability?

The current use case for NeoWiki itself is to display the main subject in the automatic infobox. Without an explicit main subject the automatic infobox has to guess, and if it picks the first, then we introduce "first" as a slightly meaningful concept. However, the automatic display is not fundamentally tied to a "main subject" concept, we could just have a checkbox somewhere on the Subjects/Data tab for "display automatically", or similar.

[Habennin]

Adding some more thoughts.

Question 2/2: Is the Main Subject tag useful?

Presuming that the page is the place from which one begins to edit a subject, I would think that having a main subject tag is useful / necessary. Presumably this is one of the main reasons they would use NeoWIki that they want to also have a wikipage associated to their structured data. Otherwise, they could just use a semantic database?

Question 1/2: Automatic/enforced Relation?

Just to reiterate that semantically this means nothing:

{
    "mainSubject": "sEpfwJLnxyQy6vR",
    "subjects": {
        "sEpfwJLnxyQy6vR": {
        },
        "sEpfwJLAtndAaaA": {
        },
        "sEpfwJLAtndBbbB": {
        },
        "sEpfwJLAtndCccC": {
        }
    }
}

Adding relations automatically, how would that happen? What would the semantics of them be? I would have thought that the relation between them is defined in the schema editor. Like if I am editing a page which is associated to the main entity controlled by the schema Physical Thing then the sub subjects that I can relate structurally would be controlled via the Schema data entry function anyhow right?

Like

Physical Thing

Owner: data type: Reference Schema (Person)
Place of Creation: data type: Reference Schema (Place)

So I would expect that the relations that would be built would look more or less like:

{
    "mainSubject": {
        "id": "sEpfwJLnxyQy6vR",
        "type": "Physical Thing Schema",
        "label": "Bronze Statuette (example)"
    },
    "owner": {
        "id": "sEpfwJLAtndAaaA",
        "type": "Person Schema",
        "label": "Jane Doe (example)"
    },
    "creation_place": {
        "id": "sEpfwJLAtndBbbB",
        "type": "Place Schema",
        "label": "Antwerp (example)"
    }
}

The main subject would be thing that all the other subjects should they be structurally related back to the main subject relate to and then semantic of each of those relationships should be defined (by the schema). So this schema would have the semantics for ownereship and creation place and if you used those then the child subjects could be seen and they would have exactly these structured relations to the main subject.

It would also be great if by default we knew the kind of thing each subject was and had an indicative label, even in the JSON.

[JeroenDeDauw]

Early external feedback (February 2026, against the February build; record in the pw vault) adds an axis to the automatic-relation question: distinguish Child Subjects that are page-scoped dependents from full-fledged Subjects that merely live on a page. The dependent pattern — the same pattern as SMW sub-objects, and what "additional metadata sets" above describes — was considered fine because the data's home stays knowable; free-standing Subjects parked on pages were flagged as risking data-maintenance pain for the same reason inverted: you no longer know where a queried value lives or what owns its lifecycle. The proposal-shaped difference: a dependent lives and dies with its host page, an independent Subject must not. No mechanism was proposed — schema-level flag vs per-subject vs derived-from-the-relation is open.

_{AI-authored — Claude Code, Fable 5 (max); posted on @JeroenDeDauw's go-ahead from a review of that feedback; not yet human-reviewed.}

[semantisch]

I would keep the ability to identify the Subject that represents the page, because this is useful in a page-oriented wiki - like NeoWiki.

I would not automatically create relations between that Subject and other Subjects stored on the same page, because being stored together is an organisational detail, not necessarily a semantic relationship. Any actual relations should be explicitly defined in the structured data because, ideally, semantics should not be mixed across different layers.

I would also use “Additional Subjects” rather than “Child Subjects,” because this does not imply a relationship that may not exist.

[JeroenDeDauw]

@semantisch agreed

Proposal:

• we keep the "Main Subject" term so you can indicate which Subject represents the same concept as the Page
• no automatic relation between subjects on a page
• we remove the "Child Subject" domain term. So a page just has a list of Subject and one of them is the Main Subject

[JeroenDeDauw]

Recorded in #1368: the glossary drops "Child Subject" with an Avoid entry, ADR 28 and ADR 31 are reworded, and planning/Relations.md now carries the page-scoped vs free-standing question from above so it is not lost when this closes. The identifiers that still say child subject (nw.getChildSubjects, the childSubjects route) are renamed separately in #1367, after #1265.

_{AI-authored — Claude Code, Fable 5 (max); posted on @JeroenDeDauw's go-ahead; not human-reviewed.}