Problem
The IRI scalar promises identity:
A field or filter typed IRI keys on identity, never on a literal.
But an idOnly reference surfaces as that same scalar, and idOnly's own docs describe the opposite case as its main use: "a reference whose referent is not an entity this deployment describes: a canonical vocabulary URI, a licence, a content URL".
A content URL is a locator, not an identity. So a consumer applying the scalar's rule – IRI-typed ⇒ resolvable, joinable, "show me everything related to this IRI" – is invited to treat a JPEG URL as an entity key. It finds nothing rather than something wrong, but the surface claims more than it holds, which is exactly what #723 set out to fix on the filter side.
What the declaration already knows
ref.typeName is optional on idOnly precisely to mark the difference:
Declare it when the referent's IRIs form a nameable set an API surface should distinguish; omit it for IRIs that belong to no such set.
So the distinction is stated in the schema and dropped by the surface: buildOutputField maps every idOnly reference to iriScalar regardless of typeName.
Proposal
Type a typeName-less idOnly output as a scalar that does not claim identity – a sibling of IRI with the same absolute-IRI validation and a description saying it locates rather than identifies. Named idOnly references keep IRI.
Minimal, additive on the server, and it makes the existing typeName opt-in load-bearing on both surfaces rather than only in prose. Alternatives, if the extra scalar is unwelcome: keep one scalar and narrow its description to stop asserting identity (cheapest, loses the machine-readable distinction #723 wanted), or emit a per-target scalar for named idOnly references.
Where it bites
LOL types MediaObject.thumbnailUrl, contentUrl and license as typeName-less idOnly references, which is what the profile says they are (SCHEMA-AP-NDE gives all three sh:nodeKind sh:IRI). They now surface as IRI alongside dataset and creator, which really are identities in the index.
Problem
The
IRIscalar promises identity:But an
idOnlyreference surfaces as that same scalar, andidOnly's own docs describe the opposite case as its main use: "a reference whose referent is not an entity this deployment describes: a canonical vocabulary URI, a licence, a content URL".A content URL is a locator, not an identity. So a consumer applying the scalar's rule – IRI-typed ⇒ resolvable, joinable, "show me everything related to this IRI" – is invited to treat a JPEG URL as an entity key. It finds nothing rather than something wrong, but the surface claims more than it holds, which is exactly what #723 set out to fix on the filter side.
What the declaration already knows
ref.typeNameis optional onidOnlyprecisely to mark the difference:So the distinction is stated in the schema and dropped by the surface:
buildOutputFieldmaps everyidOnlyreference toiriScalarregardless oftypeName.Proposal
Type a
typeName-lessidOnlyoutput as a scalar that does not claim identity – a sibling ofIRIwith the same absolute-IRI validation and a description saying it locates rather than identifies. NamedidOnlyreferences keepIRI.Minimal, additive on the server, and it makes the existing
typeNameopt-in load-bearing on both surfaces rather than only in prose. Alternatives, if the extra scalar is unwelcome: keep one scalar and narrow its description to stop asserting identity (cheapest, loses the machine-readable distinction #723 wanted), or emit a per-target scalar for namedidOnlyreferences.Where it bites
LOL types
MediaObject.thumbnailUrl,contentUrlandlicenseastypeName-lessidOnlyreferences, which is what the profile says they are (SCHEMA-AP-NDE gives all threesh:nodeKind sh:IRI). They now surface asIRIalongsidedatasetandcreator, which really are identities in the index.