Re: comments/questions on JSON-LD spec (but _not_ for the CG->WG transition!)

On Jun 14, 2012, at 3:29 AM, Ivan Herman wrote:

> To avoid any kind of misunderstandings: my comment/question should not have a bearing on whether the document comes over to the RDF WG or not, ie, I do not consider that as a prerequisite for starting the whole procedure. Consider it as a comment that may result in active RDF WG issues on the draft either before or after the FPWD publication.
> 
> My questions are on the section on @graph, ie, section 4.9 (and tried to look at the API doc, too). They may be clarification issues but maybe missing features in the spec. Obviously, I look at this with an RDF, more exactly RDF Named Graph (put your preferred term here:-) goggle on. I also have some comments on the construct itself, see below.
> 
> Question 1: I do not understand the last example in the section, namely the lonely "http://www.markus-lanthaler.com/". There is some text there about additional meta data about Markus, but what would that mean in terms of TriG? Could you describe this? 

Yeah, I put this in here partly to provoke a reaction :), and it should definitely be considered to be at risk. Given that the document will be an RDF WG spec, this can only be included if it is compliance with the rest of RDF Concepts and Semantics.

It's in there because of two basic reasons:

1) JSON-LD is an expression of Linked Data. The use of a bare IRI was to indicate that a separate resource might be named as part of a dataset that comprises the agregated linked resources. If it is a best practice to use IRIs to denote resources which describe themselves, then this use is in keeping with those principles.

2) A problem that came up in WikiData is that you often want to describe a statement using separate provenance, so that a given statement (or collection of statements) could be considered to be in more than one layer/named graph at the same time. For example, a statement is given provenance as deriving from a particular source (e.g., Berlin population), came from some other source document, along with other statements and so forth. Basically, from my observation, this group has described a number of different, but seemingly mutually-exclusive, uses of named graphs. The notion of using an IRI to resolve the resource which is otherwise named was some attempt to hint at a way in which an external resource could be considered to be part of multiple layers/named graphs.

That said, it's not my intent to open the debate on how a set of statements might be considered to be in more than one named graph at the same time (other than by simply repeating the statements). It was really just a means of exploring how follow-your-nose linked data principles might intersect with named graphs.

> Question 2: My understanding is that
> 
> {
>  "@context" : ...
>  "@graph" : ...
> }
> 
> (without @id) defines triples into the default graph. Which also means that if I have a nested situation of the sort:
> 
> {
>   "@context" : ...
>   "@id" : URI
>   "@graph: {
>       "a" : "b",
>       "@graph" : {
>           "q" : "r"
>       }
>   }
> }
> 
> translates into
> 
> URI {
>  "a" : "b"
> }
> {
>   "q" : "r"
> }
> 
> Is that correct?

This is certainly not intended usage, as @graph evolved from a desire to be able to define multiple top-level entities (subject definitions) where an array would otherwise be used.

However, this can be interpreted by the processor to generate quads. Basically, the [a,b] tuple belongs to an anonymous entity (blank node subject), which is in the graph denoted by URI. The [q, r] tuple also belongs to an anonymous entity (with a different BNode) in a named graph denoted by the BNode of the including entity. (JSON-LD syntax allows the use of BNodes for graph names, even though it might not result in valid RDF).

If you run a cleaned up example through the playground, you can see the Quads which are emitted:

{
  "@context" : {"a": "http://foo/a", "q": "http://foo/q", "URI": "http://URI"},
  "@id" : "URI",
  "@graph": {
      "a" : "b",
      "@graph" : {
          "q" : "r"
      }
  }
}

_:t0 <http://foo/a> "b" <http://URI> .
_:t1 <http://foo/q> "r" _:t0 .


> However, I tried to look at the RDF algorithm in the API document, and I did not see anything about the case when the @id is not set for a @graph. Did I miss something?

Yes, if there are other properties, the object is treated as an entity with a blank node subject.

> Comment 1: I also try to imagine a JSON user who does not know anything about RDF and, obviously, of named graphs either: for that person this construct may be a bit confusing. First of all, such a person may not _really_ think in term of a graph (and the rest of JSON, ie, also the JSON-LD document, cleverly hides this concept). Ie, this keyword might be confusing. Also, the "@graph" : { ... } does not really fit, at least for me, in the mental model of a property-value pairs _on a common subject_, that is the fundamental paradigm in JSON-LD (rightfully so) because it is, somehow, fundamentally different; we are not making statements on the @id value, we are somehow changing the nature of what is happening. I know something is needed at least for the top level objects even if we do not talk about the named graphs (after all, I raised this issue in the past), but I am not convinced about the direction this goes syntax-wise. (Again, this is a discussion on or before the FPWD, _not_ a prerequisite to get the document over to the RDF WG!)

The named-graph usage really fell out of needing a way to enclose a number of top-level objects as a value property, rather than a top-level array. We are currently examining an alternative mechanism for doing this (@id maps), so we could consider changing this, but it would be a fairly radical change at this point.

> Comment 2: There is, of course, the general question whether it is wise to publish a FPWD with a @graph features as long as the discussion on named graphs is still raging in the group. Maybe that section should be stripped down, for the moment, to the bare minimum that is necessary to express a graph with several top level subjects... But that is just a thought. I know the API values are set in terms of quads but we can say, at this moment, that JSON-LD does not yet have a syntax to express the full quads, only those for a default graph...

Point taken, and Manu had raised this, except that we had specific use cases to address. I'd suggest we mark the section as at-risk instead of removing it entirely.

Gregg

> Thanks
> 
> Ivan
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
>

Received on Thursday, 14 June 2012 15:47:12 UTC