W3C home > Mailing lists > Public > public-json-ld-wg@w3.org > June 2019

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

From: Graham Klyne <gk@ninebynine.org>
Date: Mon, 24 Jun 2019 22:14:35 +0100
Message-ID: <5D113D3B.1030705@ninebynine.org>
To: Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr>
CC: Gregg Kellogg <gregg@greggkellogg.net>, "public-json-ld-wg@w3.org" <public-json-ld-wg@w3.org>
On 24/06/2019 18:44, Pierre-Antoine Champin wrote:
> Dear Graham,
> sorry, this email has been sitting in my inbox for a while...
> Re. mentioning type coercion in the description of the `@type` keyword:
> Well, type coercion is mostly about the "datatype" interpretation of @type,
> since its effect is to "convert" a plain JSON string to a value object with the
> given @type -- with the exception of "@type": "@id"/"@vocab", which converts it
> to a node object *without a @type*. Some people find this confusing and have
> been quite vocal about it. So mentioning type coercion in this context would
> increase the confusion, I'm affraid...

Well, the spec can certainly confuse :)  I was trying for a minimal fix for my 
particular issue, but maybe something more fundamental is called for?

An explicit description somewhere along the lines of what you write above (*) 
might help.

(*) referring to "... type coercion is mostly about the "datatype" 
interpretation of @type, since its effect is to "convert" a plain JSON string to 
a value object with the given @type -- with the exception of "@type": 
"@id"/"@vocab", which converts it to a node object *without a @type* ..."

(I'm pushing on this because I think there's a clearly demonstrated 
interoperability problem with the existing spec (per my previous emails), and 
it's not clear that 1.1 has really done enough to address that.  I'm probably 
now getting too close to the issue to judge clearly.  But I do think it's 
important that the spec - especially one like JSON-LD with it's potentially very 
broad reach - can be interpreted by someone who hasn't spent months steeped in it.)

> Re. "typed value" vs. "value object", both terms link to their respective
> definition everytime they are used in the document (if they don't, that's a bug)

Maybe, but what I found is that they aren't clearly connected to each other, 
though they do seem to be different manifestations of the same underlying 
language structure.


>   best
> [1] https://www.w3.org/TR/json-ld11/#dfn-typed-value
> On Wed, 12 Jun 2019 at 08:43, Graham Klyne <gk@ninebynine.org
> <mailto:gk@ninebynine.org>> wrote:
>     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
>     <mailto: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 Monday, 24 June 2019 21:15:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:15:26 UTC