W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2013

RE: The default graph, @id, and @graph

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 6 Feb 2013 16:14:08 +0100
To: "'JSON-LD CG'" <public-linked-json@w3.org>
Cc: "'Erik Isaksson'" <erikis@kth.se>
Message-ID: <019101ce047c$9d6a7aa0$d83f6fe0$@lanthaler@gmx.net>
On Wednesday, February 06, 2013 3:48 PM, Erik Isaksson wrote:

> > Hmm.. I don't understand the intention. To make it clear, that's what
> you have:
> >
> > {
> >   "@graph": [
> >     { "@id": "/node/1", "label": "Node 1" }
> >     ... more nodes objects ...
> >   ]
> > }
> >
> > Is that expressing a named graph? What's the name then? If not, is
> has to be default graph (as it can't be anything else) and that's what
> we currently do. Do I miss something?
> 
> Normally, there would be other properties in the top-level object. My
> worry is that somebody would sometime forget to include other
> properties there (or actually intend to do that), but still keep the
> @graph (where, in my system, metadata can freely be added whereas
> properties in the top-level object, i.e., default graph, are somewhat
> limited as they are managed by the system). The @graph would, in that
> case, be interpreted in an unexpected way.

OK, I see what you mean. The cleanest solution in that case (using the current spec) is to *always* have the top-level @graph and then *always* put the top-level node in that @graph. I'm still not convinced that @default would improve things.


> Right. In my Java JSON-LD processor, I haven't implemented this yet,
> though. :) That was by mistake, but I don't think having a separate
> keyword is a problem when implementing processors. Actually, I think
> it makes the implementation more clear (fewer special cases).

I think it's easier for humans the way it is. Very few people will write a processor so that's a secondary concern.


> By the way, what if multiple graphs with the same name are included in
> one document? (Should they be merged?) And what about nested use of
> @graph? Reading through the syntax and API specs previously, I don't
> think I've seen anything forbidding this. Of course, such usage
> shouldn't be recommended, but if it's ever encountered, it needs to be
> dealt with somehow.

Yes, they will be merged, just as node objects get merged. You can't nest graphs in the traditional sense, you can just reference a graph from a node in another graph.


> >> Whether to allow @graph for blank nodes is probably a separate
> >> discussion; I'm using blank nodes as graph names when describing
> >> resources as part of creation requests (i.e., the resource hasn't
> been
> >> assigned an identifier yet, but it will have an IRI after creation).
> >
> > What about using a relative IRI instead? It will expand to a full IRI
> once the target IRI is created/known.
> 
> I'd like (in my system) to allow automatically generated (random)
> identifiers, in the case that no IRI has been provided in the resource
> creation request. (What I'm providing is a kind of instantiation of
> dereferencable, Linked Data resources.)

You might wanna weight in on rdf-comments [1] then. RDF currently just allows IRIs as graph names and since JSON-LD is being published by the RDF WG we will probably get some pushback if we keep this "feature". The discussion already started [2] (this is a members-only list, so you need to comment on rdf-comments)


> > I like the direction. What about changing it to
> >
> >   When a JSON-LD document’s top-level structure is an object that
> >   contains no other properties than @graph and optionally @context
> >   (properties that are not mapped to an IRI or a keyword are
> ignored),
> >   @graph is considered to express the otherwise implicit default
> graph.
> >   This mechanism can be useful when a number of nodes exist at the
> >   document's top level that share the same context. The @graph
> keyword
> >   collects such nodes in an array and allows the use of a shared
> context.
> 
> I like it. That's much more clear than what's currently in the spec.

OK, if no one objects I will update the spec tomorrow.


> > Thanks a lot for your feedback. It is very helpful since for all of
> us it is quite difficult to spot such weaknesses in the spec after
> having worked for so long on them.
> 
> Ok, I'll probably give you more feedback in the next few weeks. :)

Much appreciated!


[1] http://lists.w3.org/Archives/Public/www-rdf-comments/
[2] http://lists.w3.org/Archives/Public/public-rdf-wg/2013Feb/0000.html


--
Markus Lanthaler
@markuslanthaler
Received on Wednesday, 6 February 2013 15:14:41 GMT

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