Re: Why is node embedding not allowed for @type values (in the rdf:type - sense)

> On Oct 6, 2022, at 1:44 AM, Hoekstra, Rinke (ELS-AMS) <r.hoekstra@elsevier.com> wrote:
> 
> Hi All,
>  
> I stumbled upon a restriction on the allowed values for the @type keyword in a node object when specifying the rdf:type for a resource in JSON-LD.
>  
> I would expect [4] to be equivalent to [5], but where [4] is allowed, [5] is syntactically incorrect. (NB: the Python rdflib library does not complain; but jsonld.js and pyLD do)
>  
> It looks like embedding [1] (node objects as property values) is not allowed in this case, even though this is not explicitly mentioned in the section on embedding.. This is also not made clear in the section on specifying the type [2] (it just gives examples of using an IRI string as value, or an array of such strings, or a term defined in the active context).
>  
> Both sections are non-normative (which may explain things), and the restriction is only made clear in the JSON-LD grammar [3] for node objects:
>  
> If the node object <https://www.w3.org/TR/json-ld11/#dfn-node-object> contains the @type key, its value MUST be either an IRI reference <https://tools.ietf.org/html/rfc3987#section-1.3>, a compact IRI <https://www.w3.org/TR/json-ld11/#dfn-compact-iri> (including blank node identifiers <https://www.w3.org/TR/rdf11-concepts/#dfn-blank-node-identifier>), a term <https://www.w3.org/TR/json-ld11/#dfn-term> defined in the active context <https://www.w3.org/TR/json-ld11/#dfn-active-context> expanding into an IRI <https://tools.ietf.org/html/rfc3987#section-2>, or an array <https://infra.spec.whatwg.org/#list> of any of these. See § 3.5 Specifying the Type <https://www.w3.org/TR/json-ld11/#specifying-the-type> for further discussion on @type values.
>  
> My main question is: why this restriction? It is perfectly normal in RDF to have nesting for the rdf:type property (e.g. relate to a class that is itself a subclass of another class).

As you note, the value space for @type is described in the normative text, with the informative text being more about how and why to use @type, rather than the motivations for restricting its value space. This is mainly because the string values of @type have specific expansion characteristics that allow relative values to be interpreted either vocabulary-relative or document-relative. The though was that if people wanted to be more creative in their use of types, they could do this using “rdf:type”.

The JSON-LD API discusses more details of processing @type during expansion in steps 11 and 13.4.4 of the Expansion Algorithm (https://www.w3.org/TR/json-ld11-api/#algorithm-3 <https://www.w3.org/TR/json-ld11-api/#algorithm-3>). Note the specific language on raising an error if the value of @type isn’t a string or array of strings in 13.4.4.1:

> 13.4.4.1)  If value is neither a string <https://infra.spec.whatwg.org/#javascript-string> nor an array <https://infra.spec.whatwg.org/#list> of strings <https://infra.spec.whatwg.org/#javascript-string>, an invalid type value <https://www.w3.org/TR/json-ld11-api/#dom-jsonlderrorcode-invalid-type-value> error has been detected and processing is aborted. ...

> One reason I can think of is that the value for @type should never be a Literal; that makes sense, so any string value for the @type key will have to be interpreted as an IRI. However, disallowing for embedded node objects, seems overly restrictive to me, and I'm inclined to see this as a bug in the spec.
>  
> I can work around this by mapping a custom "type" entry in a context to rdf:type, but I'd much rather use the built-in @type for consistency.

That’s the right way to do it. JSON-LD expansion is complex enough without furhter complicating its processing model, at least IMHO.

Gregg
 
> Could someone explain the reasoning behind this?
>  
> Thanks,
>  
> Rinke
>  
>  
> [1] https://www.w3.org/TR/json-ld11/#embedding <https://www.w3.org/TR/json-ld11/#embedding>
> [2] https://www.w3.org/TR/json-ld11/#specifying-the-type <https://www.w3.org/TR/json-ld11/#specifying-the-type>
> [3] https://www.w3.org/TR/json-ld11/#node-objects <https://www.w3.org/TR/json-ld11/#node-objects>
> [4] https://tinyurl.com/2jx8e6r4 <https://tinyurl.com/2jx8e6r4>
> [5] https://tinyurl.com/mr3t75zn <https://tinyurl.com/mr3t75zn>
> -- 
> Rinke Hoekstra
> Lead Architect – Knowledge
> Industry Director of Elsevier’s Discovery Lab
> ELSEVIER - Amsterdam
> r.hoekstra@elsevier.com <mailto:r.hoekstra@elsevier.com>
>  
> Emails can arrive at all hours, but at Elsevier we respect your personal time. Feel free to respond to this email during your normal working hours.
> 
> Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.
>