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

Dear Pierre-Antoine,

Thank you for this - it helps :)

In this response, I'll offer proposals for making this clearer...

(My immediate goal here is to suggest something that I could point to, which 
makes it clear the problematic use I came across is not in accordance with the 
spec.)

On 11/06/2019 17:29, Pierre-Antoine Champin wrote:
> Dear Graham,
>
> On Tue, 11 Jun 2019 at 17:51, Graham Klyne <gk@ninebynine.org> wrote:
> (...)
>
>> 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.
>>
>
> correct.
>
>>
>> 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.
>>
>
> actually, it also works with a "@type" value of "@vocab",
> but you got the general idea, yes.
>
> This is described in the 'Type coercion' section of the spec (
> https://www.w3.org/TR/json-ld11/#type-coercion),
> which starts with

Aha!

>
>> JSON-LD supports the coercion of string values to particular data types
>
> then a little further down:
>
>> Alternatively, the keyword @id or @vocab may be used as value
>> to indicate that within the body of a JSON-LD document,
>> a string value of a term coerced to @id or @vocab is to be interpreted as
> an IRI.
>
> I know it is always easier when you know where to look... Where else do you
> think this should be emphasized?
>
> Also, just to be clear: type coercion in a term definition only applies to
> simple JSON strings. It is always possible to override that by using an
> explicit node object (to create an IRI) or value object (to create a
> literal). See this example: http://tinyurl.com/y2lghv3f
>
> Finally, regarding the double meaning of @type in the data,
> we have put a note about that in the definition of the @type keyword,
> under https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords .

I think this helps, as it draws attention to the dual-use.  I don't think the 
justification is really needed, but it would help to mention its use in expanded 
term definitions; e.g. I might suggest some thing like this:

[[
NOTE

The @type keyword is used to define a type for both [node objects] and [value 
objects], and addresses the basic need to type data, be it a literal value or a 
more complicated resource.  It may also be used with an [expanded term 
definition], where it indicates a type for an associated [typed value], as 
described for [type coercion].
]]


I note that "type coercion" talks about "typed value", where the @type note 
refers to "value object".  I see these are different, but related, but wonder if 
this may not be immediately obvious to a casual reader.  Maybe add something 
like this to the glossary entry for "Value object":

[[
A value object with a @type member represents a [typed value].
]]

(Technically, when mapped to RDF (per 1.1), I think that idea would also apply 
without the @type keyword as RDF bare literals are now typed as xsd:string - but 
I'm not sure that notion applies to the JSON-LD model.)

#g
--

Received on Wednesday, 12 June 2019 06:44:01 UTC