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

On Tue, Feb 5, 2013 at 3:22 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> On Tuesday, February 05, 2013 2:18 PM, Erik Isaksson wrote:
>
>> "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?
>
> In my opinion it wouldn't be better. It's one more keyword to remember, it can be used at maximum once in the whole document, and it obfuscates the fact the default graph is conceptually the same as every other graph, it just has no name.
>
>
>> 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.
>
> 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.

>
>
>> 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).
>
> That's true, but that's how we designed it. We wanted graph to act like a containers (please don't confuse this with @container), an alternative design could be to use @graph to express to which graph a node belongs to, something like:
>
> {
>   "@id": "/node/1",
>   "label": "I'm a node belonging to graph 1",
>   "@graph": "/graphs/1"
> }
>
> There are a number of problems with an approach like this: you need to specify the graph in every node, it becomes tricky when you link nodes together (embedding), etc.

I much prefer your current approach. One of the best features of
JSON-LD, compared to RDF/JSON and other RDF serializations, is how
graphs can be embedded.

>
>
>> 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).
>
> There's basically one case where it is handy to be able to explicitly express the default graph: when you have multiple nodes at the top level. Otherwise you would have to include @context in each of them:
>
> [
>   { "@context": ..., ...},
>   { "@context": ..., ...},
>   { "@context": ..., ...},
> ]
>
> =>
>
> {
>   "@context": ...,
>   "@graph": [
>     ... nodes ...
>   ]
> }
>

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).

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.

>
>> 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.)

>
>
>> 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".
>
> So:
>
>   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 (e.g., @id) 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
>   to the application, but a shared @context is still to be used for all of
>   the nodes.
>
> 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.

>
>> 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.)
>
> Agreed
>
>
>> By the way, if an array
>> is at the top-level, how should "a document's top-level object" be
>> interpreted?
>
> Good point. I considered that in the proposal above.
>
>
>
>> 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)
>
> 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. :)

Best regards,
Erik

>
>
> Cheers,
> Markus
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>

Received on Wednesday, 6 February 2013 14:48:32 UTC