Re: Question about JSON-LD: @type in expanded term definitions in @context

Hi Gregg,

Thanks for your response.  I think it supports my view, but unfortunately, I 
still feel as if the intent is not entirely clear.  Maybe because I didn't frame 
my question adequately.

On 10/06/2019 14:47, Gregg Kellogg wrote:
> On Jun 10, 2019, at 3:54 AM, Graham Klyne <gk@ninebynine.org> wrote:
>> I'm working from the 1.0 version of the JSON-LD spec:
>> https://www.w3.org/TR/json-ld/
>>
>> My question is this: does the inclusion of a "@type" value in an "expanded term
>> definition" [1] in a JSON-LD context automatically mean that the defined term is a datatype property URI, and hence that the value of the "@type" key must be a datatype URI?
>
> Other than for `@id`, `@vocab` and `null`, the value is interpreted as an IRI and is the datatype of any strings expanded using this term definition. JSON-LD makes no semantic requirement for what the IRI means.

Maybe that's sufficient detail when talking about the JSON-LD model, though in 
JSON-LD terms it would help me to know if the object referenced via an expanded 
term definition is a "Node object" or "Value object".  But what I'm really 
concerned with is the specification of correspondence with the RDF model.

In RDF, I think your "datatype of any string" would have to refer to an RDF 
literal node, which is a distinct from a URI node (or blank node).  My sense, 
but it's not something I am finding clearly stated, is that when an "expanded 
term" with a @type IRI is used, the corresponding JSON-LD corresponds to an RDF 
statement with a literal node as its object, with the data type of that node 
indicated by the given IRI.  In the presence of such a @type IRI, I don't think 
the JSON-LD can map to an RDF statement with a URI node.

I think the only way to use an expanded term to create the equivalent of an RDF 
statement with a URI node object is to use a "@type" value of "@id" in the 
expanded term definition.

(My apologies if this all sounds overly picky, but I'm responding to what I 
think is an actual misinterpretation of the current spec.  I believe there are 
justified interoperability concerns here.  I see the expanded term mechanism is 
central to achieving useful interworking between "ordinary" JSON and linked 
data, for which clear specification is a vital issue.)

>
>> [1] https://www.w3.org/TR/json-ld/#dfn-expanded-term-definition
>>
>> I think the answer is "yes" (it's the usage illustrated for Typed Values [2]),
>> but I'm struggling to find anything in the spec that definitively states this is the case).
>>
>> [2] https://www.w3.org/TR/json-ld/#typed-values
>>
>> ...
>>
>> In hindsight, I think the use of the same "@type" keyword for node types and
>> value types maybe unfortunate, and what is leading to this uncertainty.  If I'm
>> correct in my interpretation, the spec has clearly been misinterpreted by others (see below), and may benefit from some clarification in the 1.1 round.
>
> In retrospect, yes, but changing it now would represent an incompatible change.

Indeed.

>
> There is another issue (I can’t access right now) where we discussed the rationale for. To using this for item types and I believe text has been added supporting this. If not, it may go in the best practices or primer documents.

Hmmm... I think this needs to be unambiguous in the spec itself (and also 
covered by test cases).  That is the place I'd look to for resolving 
interoperability issues.

#g
--


>
> Gregg
>
>> More background on my question is at:
>> https://github.com/LinkedPasts/linked-places/issues/11
>>
>> #g
>> --
>>
>

Received on Tuesday, 11 June 2019 15:50:42 UTC