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

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?


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


> 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 ...
  ]
}


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


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


Cheers,
Markus



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 5 February 2013 14:23:13 UTC