- From: Erik Isaksson <erikis@kth.se>
- Date: Tue, 5 Feb 2013 14:17:50 +0100
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: JSON-LD CG <public-linked-json@w3.org>
On Sat, Feb 2, 2013 at 8:14 PM, Manu Sporny <msporny@digitalbazaar.com> wrote: >> Niklas Lindström: .. "When @graph is used in a document's top-level >> object which has no other properties that are mapped to an IRI or a >> keyword it is considered to express the otherwise implicit default >> graph." >> >> Niklas Lindström: my friend had a problem with this wording. … If I >> understand him, he wasn't sure it was enough to add @id; he wanted to >> make sure he had a named graph. >> >> Manu Sporny: The text is wrong, but let's try to fix it now. I'll >> make a change right after the call. > > Actually, the text is correct Niklas. The sentence is talking about how > to express the 'default graph'. If he added @id, it would no longer > express the default graph. > > Is there some other wording we could introduce to make this more clear > to your friend? "When @graph is used in a document's top-level object which has no other properties that are mapped to an IRI or a keyword it is considered to express the otherwise implicit default graph. This mechanism can be useful when a number of nodes do not directly relate to one another through a property or where embedding is not desirable to the application." My thoughts here were: Wouldn't it be better (mainly as in easier to understand intuitively) to use a separate keyword (e.g., @default) when the intention is to provide the default graph? Also, isn't it possible (although an unusual case) that one would actually like to have a top-level object that has a @graph, but no other properties (not even @id, i.e., it is a blank node)? This would currently result in the contained graph being interpreted as the default graph, which isn't the intention here. Even without this (perhaps strange) case, it may be confusing that (seemingly) unrelated properties affect the semantics of @graph (i.e., whether it's the default graph or a named graph). In my own use case, I'm fine with inserting a blank node (or perhaps urn:uuid:) identifier into the top-level object to make sure that any contained @graph is never interpreted as the default graph. However, I'd like to avoid the semantic confusion described above (it did confuse a colleague of mine when he was looking at the spec recently). 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). The part of the spec quoted above could be rewritten as "...or a keyword (e.g., @id)" and "...or where embedding is not desirable to the application, but a shared @context is still to be used for all of the nodes". I know that shared context is mentioned in the next paragraph, but I think the sentence makes more sense if shared context is mentioned there already. (Otherwise, an array can equivalently, and I think preferably, be used at the top-level.) By the way, if an array is at the top-level, how should "a document's top-level object" be interpreted? I hope this is useful to you. Thank you for all of your great work on JSON-LD, and I hope I can be of a little help as well with these and perhaps other, future comments. Best regards, Erik (aka Niklas' friend) > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Aaron Swartz, PaySwarm, and Academic Journals > http://manu.sporny.org/2013/payswarm-journals/ >
Received on Tuesday, 5 February 2013 13:18:23 UTC