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

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

Received on Thursday, 14 June 2012 23:43:17 UTC