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

Markus, Gregg

this is, sort of, my joint reply for both of you, I would prefer to avoid repeating myself... And thanks to both of you!

First of all, I think what this discussion reveals for me is that the relevant section in the syntax document needs major editorial work, eventually, to make these things clearer even if we remain with the current syntax. That would clearly improve things. I do have a clearer picture now; maybe some of the issues we discussed should be retrofitted in the document. I am still wondering whether the term '@graph' is really intuitive for 'pure' JSON users, though it is clearly intuitive for me...

Two things:

- It is a little bit unclear at the moment whether JSON-LD has the notion of syntax for nested graphs or not. Markus, I may misunderstand what you write, but you say:

[[[
>> Note that TriG, as it stands, does not allow nested graphs, ie,
>> 
>> <URI> {
>>   <a> <b> <c> .
>>   <URI1> {
>>      <p> <q> <r> .
>>   }
>> }
>> 
>> is not accepted.
> 
> Neither does JSON-LD at the moment.
]]]

because you do give an example below of nested graphs in the syntax.

But that is probably my mistake; as Andy already mentioned separately, in SPARQL this seems to be (essentially) syntactic sugar. I may be wrong and TriG does allow such constructs (or will allow it to have a compatibility with the SPARQL query syntax) but I guess it would also be syntactic sugar (we have ruled out nested graphs as a WG resolution a few weeks ago). My understanding of your explanation is that this is the same in JSON-LD. If so, this is great because harmonization on that is good.

(I must admit I did not realize that such nested syntax is allowed in SPARQL either, thanks to Andy for pointing that out.)

Something to make clear in the document?

- As for the current JSON-LD syntax choices: I know you guys (and Manu) will hate me but I would have probably chosen a slightly different approach. For me, there is conflation of two different issues: on the one hand, the necessity, due to the limitations of the JSON syntax, of explicitly enumerating the content (sometimes) to avoid repeating the @context and, on the other hand, the legitimate need for the notion of graphs. I would have approached this issue slightly differently syntax-wise.

For the 'JSON' issue, I would have chosen a keyword to make that explicit, without muddling the waters. Something like

{ 
   "@context" : { ... whatever ... },
   "@content" : [
      { ... }
      { ... }
    ]
}

with the obvious understanding that "@content" is unnecessary if there is only one top level object (just like you do now with the top level "@graph" right now). That seems to be clear, clean, and does not introduce a new, overloaded notion for the JSON user (and is fairly clear for an RDF user). Yes, I know that we try to keep the number of keywords low, but, well, something is clearly needed here.

On the other hand, to denote a graph, I would have made explicit that an object, well, is a graph. Something like

{  "@id"   : "URI" ,
   "@type" : "@graph",
   "@content" : [
      { ... },
      { ... }
   ],
}

and the missing "@type":"@graph" simply means that we are talking about the default graph. Yes, this usage of "@content" is almost identical to the current usage of "@graph", I realize that, but I believe it provides a cleaner separation of the concepts, and a better conceptual hierarchy of terms for users: use the concept of 'graphs' only if you really need it (which I do not believe would happen at the 'entry level', so to say).

All syntax choices are a matter of personal taste, so I will not lie down the road if the group takes up the current JSON-LD syntax. But I thought I would raise that anyway...

Cheers, and thanks for your patience:-)

Ivan 

On Jun 15, 2012, at 01:42 , Markus Lanthaler wrote:

> Hi Ivan,
> 
> let me try to explain it in different words (the copy goes to RDF comments
> as I still don't have access to public-rdf, so please forward it so that the
> full thread is there as well).
> 
> 
>>> 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.
>> 
>> Yep. I think that minor entry should then be removed before going to
>> FPWD.
> 
> I agree, it's really confusing. I just removed it.
> 
> 
>> Well, to be honest, I am actually lost (and that shows either that I am
>> stupid, or that the section seems to be half baked, or both...) and I
>> am not 100% sure how the @graph syntax works. Just to make it very
>> clear, how would you encode a simple TriG thing:
>> 
>> {
>>  <a> <b> <c> .
>> }
>> <URI> {
>>   <p> <q> <r> .
>> }
>> 
>> I see where I did make some mistake, but I also do not fully grasp, out
>> of the description, what the 'value' of the "@graph" really is, and on
>> what does "@id" applies in that case.
> 
> The idea of the @graph keyword is, that the object containing it, describes
> the graph. The other thing you need to know is that if an object doesn't
> contain an explicit identifier, i.e., an @id property, JSON-LD will
> automatically create a blank node for it when converting to RDF for example.
> 
> So, your example above would be encoded as
> 
> {
>  "@context": {
>    "b": { "@id": "b", "@type": "@id" },
>    "q": { "@id": "q", "@type": "@id" }
>  },
>  "@graph": [
>    {
>      "@id": "a",
>      "b": "c"
>    }
>    {
>      "@id": "URI",
>      "@graph":
>      {
>        "@id": "p",
>        "q": "r"
>      }
>    }  
>  ]
> }  
> 
> The first @graph defines the default graph. You could eliminate it if it
> would contain just one object, but in this example we need two. The second
> object defines a named graph. @id is the name of the graph and the value of
> @graph is the "content" of that graph; @graph does not name the graph!
> 
> This doesn't mean though that graphs are nested. The current processing
> model is to re-start processing with the new, disjoint graph. So, e.g.
> 
> {
>  "@id": "graph1",
>  "creator": "Markus"
>  "@graph": {
>    "@id": "example"
>    "title": "This is an example"
>    "contains": 
>      {
>        "@id": "graph2",
>        "@graph": 
>          {
>            "@id": "something-else",
>            "title": "Something else"
>          }
>      }
>  }
> }
> 
> Would create two named graphs, graph1 and graph2. graph1 would contain the
> triples
> 
>  <example> <title> "This is an example"
>  <example> <contains> <graph2>
> 
> and graph2 would contain
> 
>  <something-else> <title> "Something else"
> 
> Furthermore there would be the triple about graph1:
> 
>  <graph1> <creator> "Markus"
> 
> 
>> Note that TriG, as it stands, does not allow nested graphs, ie,
>> 
>> <URI> {
>>   <a> <b> <c> .
>>   <URI1> {
>>      <p> <q> <r> .
>>   }
>> }
>> 
>> is not accepted.
> 
> Neither does JSON-LD at the moment.
> 
> 
>>> Yes, if there are other properties, the object is treated as an
>> entity with a blank node subject.
>> 
>> And my questions above (and also my comments below) show the confusion.
>> All the other '@' properties have a fairly similar analogy to property-
>> value pairs, but this one does not... At least I have not grasped it
>> yet.
> 
> I think the thing here is that the value of graph is implicitly typed to @id
> and that's why that string is there. I think it's clearer if you look at it
> as
> 
>  @graph: { "@id": "http://www.markus-lanthaler.com/" }
> 
> .. but you are right.. It's confusing and no triples would be generated in
> this case.
> 
>> Its bare bone JSON-LD format would be something like
>> 
>> [
>>  {
>>    "@id": <a>,
>>    "<x>" : {"@id":"<c>", "@type":"@id" },
>>  }
> 
> To be exact, it would be (without @type)
> 
>    "<x>" : { "@id":"<c>" },
> 
> 
>> My current bias is:
>> 
>> - we solve the immediate and necessary use case of the top level
>> @context by a dedicated and simple keyword, and we consider ourselves
>> happy
>> - we mark the generic @graph thingy as at risk; if TriG is well defined
>> then we do something along the same line for JSON-LD. I am not sure it
>> is worth creating two syntaxes that are wildly different in this
>> respect. (I know. I am RDF biased:-)
> 
> Hope my explanations above helped. I agree that the spec definitely has to
> be improved in that regard, but do you still believe that @graph in its
> current form should be dropped and replaced by a separate keyword for the
> top-level @context issue!? I think a sentence like "If multiple objects are
> the top-level explicitly defining the linked data graph allows to avoid the
> need to repeat the context in each object" would be clear enough to explain
> the use of @graph for that issue, isn't it?
> 
> 
>> But _again_: those can be done either before or even after the FPWD,
>> this is not a reason to stop the transition to the RDF WG!
> 
> Good :-)
> 
> 
> Thanks,
> Markus
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 


----
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 Friday, 15 June 2012 09:28:26 UTC