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

Just for archival in the RDF WG

Ivan

Begin forwarded message:

> Resent-From: public-linked-json@w3.org
> From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
> Subject: RE: comments/questions on JSON-LD spec (but _not_ for the CG->WG transition!)
> Date: June 15, 2012 01:42:48 GMT+02:00
> To: "'Ivan Herman'" <ivan@w3.org>
> Cc: "'Linked JSON'" <public-linked-json@w3.org>, "'RDF Comments'" <public-rdf-comments@w3.org>
> Archived-At: <http://www.w3.org/mid/001301cd4a87$68ae5bb0$3a0b1310$@lanthaler@gmx.net>
> List-Id: <public-linked-json.w3.org>
> 
> 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 08:48:39 UTC