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

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

> 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 .

 best

Received on Tuesday, 11 June 2019 16:30:22 UTC