fix(search)!: let a derive read a Reference Type entry’s node IRI

[ddeboer]

Fix #842.

#832 stopped a Reference Type entry from carrying an id, on the grounds that nothing read it. One thing did: a derive on the referrer. Linked Open Limburg picks the IIIF manifest out of a work’s associatedMedia entries by encodingFormat and returns that entry’s id, and SCHEMA-AP-NDE states the manifest URL nowhere else – the entry has an @id and no contentUrl. On 0.26.0 the field comes out undefined for every work.

The node IRI is a reading device

The projection already has the concept this needs. An internal field is populated so a later derive can read it and pruned before the document leaves, so it reaches neither the writer nor the API. An entry’s node IRI now follows the same rule:

• during projection every entry carries the IRI of the node it was projected from as id, and a derive on the referrer can read it
• pruneInternalFields deletes it from a Reference Type entry in the same pass that deletes the internal fields, after every derive has run
• the entry dedupe ignores it, so two edge nodes stating one fact still collapse into one entry

A Root Type keeps its id wherever it nests: that is the key its own collection files it under, and a local lookup resolves against it.

Nothing to declare. Everything #832 wanted still holds past the projection: one shape per entry whether the node was named or blank, nothing stored that the collection does not declare, no id on an edge type. The test from #832, “no id however the graph named the edge”, keeps passing because it reads a pruned document.

I started with a flag on the type (identified: true, then hasId) and threw it out: it made the author learn a new member to get back something a derive could read before, and its name kept colliding with ref.identity. Exposing a nested node’s IRI in the API per entry is the one thing this cannot do, and nobody has asked for it.

The GraphQL half #832 announced

The 0.26.0 changelog said an edge type loses its id field in a GraphQL surface. The adapter kept emitting it on every nested type, always null. The second commit offers id only where the projection fills it: a lookup target and a local lookup. That is a change to the published surface for any deployment nesting a Reference Type, so it is marked breaking.

Downstream

No schema change in LOL. The projection-level test on limburg/lol#173 goes green once this ships; the GraphQL schema there loses CreatorRole.id, ContributorRole.id and MediaObject.id, all null since 0.26.