W3C home > Mailing lists > Public > public-linked-json@w3.org > January 2012

Re: Multiple graphs syntax (ISSUE-68)

From: Ivan Herman <ivan@w3.org>
Date: Tue, 31 Jan 2012 19:50:13 +0100
Message-Id: <157E5835-3FE2-4405-992F-975C07975CCF@w3.org>
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, Linked JSON <public-linked-json@w3.org>
To: Gregg Kellogg <gregg@kellogg-assoc.com>
Gregg,

to avoid any misunderstandings: I talked about a graph with multiple roots, and not of multiple graphs like in TriG. That will be another issue at some point, but I would concentrate on the multiple roots.

To be clear: I am not necessarily against the current approach, though I prefer the @data to differentiate things. My real issue was that the current document does not define this, just uses. If it is reasonably defined in the spec, I am fine.

Ivan

----
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net



On 31 Jan 2012, at 19:35, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:

> On Jan 31, 2012, at 9:56 AM, Ivan Herman wrote:
> 
>> 
>> On Jan 31, 2012, at 18:35 , Markus Lanthaler wrote:
>> 
>>> Currently we have a 
>>> 
>>> {
>>> "@context": "...",
>>> "@id" : [
>>>   { "@id": ..." },
>>>   { "@id": ..." }
>>> ]
>>> }
>>> 
>>> shorthand to avoid the need to re-declare the context in every disjoint
>>> graph as you normally would have to do:
>>> 
>>> [
>>> { "@context": "...", "@id": "..." },
>>> { "@context": "...", "@id": "..." }
>>> ]
>>> 
>>> 
>>> I think the easiest solution for this issue is to just remove the @id: @id
>>> "optimization". 
>>> 
>>> So, requiring an array at the top level would be cleanest solution IMO.
>>> Since the graphs are disjoint, it would even be fair to assume that they
>>> don't share the same context. If they are really the same, then well, one
>>> has to define them twice. Is that really such a bad thing?
>> 
>> I am sorry, but I do not think that is really good. My use case is the serialization of an RDFa content; that content very often contains several graphs (e.g., there might be statements on some content the author defines, and then some other statements on the enclosing HTML file). The context for all these graphs are identical or, to be more exact, an RDFa processor has no way to find out (or it is very complicated) which context should be used for which graph. As a result, possibly complex contexts (with all the namespace definitions from the RDFa source) will be repeated. I think that is ugly.
> 
> I agree that removing this case of "@id": [{"@id"}...] is not necessary to resolve this issue, but I want to be clear on your requirement for supporting multiple graphs. Is this for a graph with multiple roots, or for multiple graphs in the TriG sense? For multiple roots, I think the "@id": [] case handles this (either at the root, or as the value of some property). The only thing we need to resolve is what the how this works when it is the value of some other property.
> 
> In Issue 54 [1] I discussed the following:
> 
> {
>  "@id": "_:node1";
>   "something" : { "@id":
>      [
>         "http://www.test.com/a",
>         "http://www.test.com/b"
>      ],
>      "otherprop": ["1", "2"]
>   }
> }
> 
> This could be determined to result in the following:
> 
> [ <something> <http://www.test.com/a>, <http://www.test.com/b> ] .
> <http://www.test.com/a> <pred> "1", "2" .
> <http://www.test.com/b> <pred> "1" , "2" .
> 
> Which I think we want to avoid. My proposed resolution is that, for "@id", the value of an array is the value of the last item in the array.
> 
> If we want to consider support for multiple graphs (Quads), first I think we should wait for the dust to settle around TriG, which currently is like SPARQL named graphs, but could become more like N3 graph literals. Presuming that it retain the SPARQL-like behavior, we would need to consider how to specify both named and default graphs, and I think that might be something to leave for the time being.
> 
> Gregg
> 
> [1] https://github.com/json-ld/json-ld.org/issues/54
> 
>>> P.S.: Ivan proposed a @data keyword that could be used as the "root"
>>> element. I think that's overhead for an optimization which we don't really
>>> need. If someone would have to serialize a large number of disjoint graphs,
>>> he could simply put the context in an external file.
>>> 
>>> 
>> 
>> See my use case above.
>> 
>> Ivan
> 
> 
>>> 
>>> --
>>> 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 Tuesday, 31 January 2012 18:47:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:36 GMT