Ensure that blank node identifiers for anonymous graphs are reused

[gkellogg]

From w3c/json-ld-syntax#30 (comment), @ericprud notes the problem with using ShEx, or anything else, to match the content of a named graph with only blank node subjects. Consider the following JSON-LD (from expansion test 0079):

{
  "@context": {
    "@version": 1.1,
    "input": {"@id": "foo:input", "@container": "@graph"},
    "value": "foo:value"
  },
  "input": {
    "value": "x"
  }
}

Currently, this will generate TriG similar to the following:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

 [ <foo:input> _:b1] .

_:b1 {
   [ <foo:value> "x"] .
}

and expanded JSON-LD:

[{
  "foo:input": [{
    "@graph": [{
      "foo:value": [{"@value": "x"}]
    }]
  }]
}]

Following the link from _:b1 as an object to the graph using that name is feasible, but finding an unnamed subject within that graph can't really be done, for any reasonably complex named graph.

This proposal would cause the expansion algorithm to re-use the blank-node identifier naming the graph for the implicitly named subject contained within the graph, generating the following TriG:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

 [ <foo:input> _:b1] .

_:b1 {
   _:b1 <foo:value> "x" .
}

This makes it possible to follow the chain from the object identifying the graph to the primary subject of that graph. Provisions must be made for forms in which there are multiple unnamed subjects within the named graph.

[iherman]

I do not really follow this. The two TriG snippets are different through the reuse of a bnode.

The whole area of RDF Datasets semantics is a bit murky, and there was never a full consensus on the details. But that section clearly says, for example, that:

The graphs in a single dataset may share blank nodes.

ie, a single graph does not constitute some sort of a separate "namespace" (for the lack of a better word).

[gkellogg]

This is. It really about dataset semantics, but a practical solution to a narrow use case. Through framing, JSON-LD encourages that graph names be the object of some triple in another (usually defaultj graph. Not RDF semantics, but a JSON-LD bias. Verifiable Claims. Ames use of such a representation. When liking for how to find a shape that matches the content of a named graph, where the subject is a blank node, it helps if it is the same blank node used to name the graph. This is really something coming from @ericprud, and maybe he can comment further.

[iherman]

I do not really understand the issue, maybe indeed @ericprud can tell further but, regardless, I do not think it is a good idea if the expansion algorithm generates a semantically different RDF dataset than what the original syntax defines. My feeling is that this is exactly what would happen here.

[ericprud]

I think we're defining the syntax now so we can't really deviate from "what the original syntax defines."
I am, however, keenly interested in making sure the RDF graph is as closely aligned with the JSON tree as possible.
Consider JS accessing the data in (a superset of) Gregg's example:

V = {
  "input": {
    "bar": "a",
    "value": "x",
    "baz": { "value": "y" }
  }
}

The JSON tree provides direct access to "x" via the path V.input.value.
Finding the same info in the RDF graph implied by the @graph requires both the ability to search the graph and prescient knowledge of which bnodes were generated for the "input":{} object:

_:b0 foo:input _:b1 .

_:b1 {
   _:b2 foo:bar "a" .
   _:b2 foo:value "x" .
   _:b2 foo:baz _:b3 .
   _:b3 foo:value "y" .
}

There's no way to know that input's value is "x" and not "y" without presuming that JSON-LD only does forward arcs (now and in perpetuity) and doing an exhaustive search for the triple with a foo:value predicate and no incoming arcs.
Doing so would not only make the RDF graph much less attractive to work with, it would paint future versions of JSON-LD into a corner.
If, however, the graph node were used as the subject:

_:b0 foo:input _:b1 .

_:b1 {
   _:b1 foo:bar "a" .
   _:b1 foo:value "x" .
   _:b1 foo:baz _:b2 .
   _:b2 foo:value "y" .
}

the connection from foo:input to "x" would be easy to navigate in e.g. SPARQL:

SELECT ?value WHERE {
  [] foo:input ?g
  GRAPH ?g { ?g foo:value ?value }
}

I'm not particularly in love with the idea of _:b1 having dual use as a node and a graph name but it seems less controversial than the alternatives, all of which involve creating extra triples:

• root connector rdf:rootNode in referring graph:

  _:b0 foo:input _:b1 .
  _:b0 rdf:rootNode _:b2 . # <-- root connector
  
  _:b1 {
     _:b2 foo:bar "a" .
     _:b2 foo:value "x" .
     _:b2 foo:baz _:b3 .
     _:b3 foo:value "y" .
  }
  

• root annotation rdf:nodeRole in referenced graph:

  _:b0 foo:input _:b1 .
  
  _:b1 {
     _:b2 rdf:nodeRole rdf:TreeRoot . # <-- root annotation
     _:b2 foo:bar "a" .
     _:b2 foo:value "x" .
     _:b2 foo:baz _:b3 .
     _:b3 foo:value "y" .
  }

See also: w3c/json-ld-syntax#30 (comment)

[gkellogg]

When we discuss this, I think it would be important to have @dlongley (and/or @msporny) and @ericprud on the call, as they are most informed about the use case.

[iherman]

I do not think that @ericprud's comment answered my concern:

I do not think it is a good idea if the expansion algorithm generates a semantically different RDF dataset than what the original syntax defines. My feeling is that this is exactly what would happen here.

[ericprud]

I think you're arguing for the proposal then. Let's examine this without the , "@container": "@graph":

{
  "@context": {
    "@version": 1.1,
    "input": {"@id": "foo:input"},
    "value": "foo:value"
  },
  "input": {
    "value": "x"
  }
}

yields

_:b0 foo:input _:b1 .
_:b1 foo:value "x" .

I.e. the object of foo:input is the subject of foo:value. Without this proposal, they are completely disconnected in the graph implied by "@container": "@graph":

_:b0 foo:input _:b1 .
_:b2 foo:value "x" _:b1 .

To me, that seems like "semantically different RDF" -- what was once navigable by a path now requires a heuristic search (something involving finding a node with no incoming arcs, unless you have inverse properties in the @context, in which case, good luck). With this proposal, they are once again connected, even though the 2nd triple is in another graph:

_:b0 foo:input _:b1 .
_:b1 foo:value "x" _:b1 .

[gkellogg]

@iherman There is no conflict with 1.0, as there was no notion of implicitly defined named graphs. The "@container": "@graph" creates this possibility 1.1 to make connected JSON work and have meaning as RDF.

The fundamental issue with shapes, is if you can identify the graph name as it is the object of a triple in the default graph, that says nothing about any shape contained within that graph.

By re-purposing the graph name as the default subject of that named graph we run the risk of conflating the meaning of that identifier: does it name a graph or does it name a subject within the graph. But, for practical purposes, it makes sense to do this to be able to follow a chain from the default graph, through an identified graph name, and to a subject within that graph.

The alternative for ShEx would be to use some other properties of that graph to hook up the shape, for example, find the subject within that graph which is not also an object in that graph, but this could be convoluted and expensive for large graphs, and does not take into consideration the possibility of reverse properties used within the JSON-LD serialization.

In summary, the proposal solves a problem that exists in the real world at the expense of some blank node identifier semantics.

[iherman]

I am sorry, maybe I am rusty with my RDF. In my reading,

{
  "@context": {
    "@version": 1.1,
    "input": {"@id": "foo:input", "@container": "@graph"},
    "value": "foo:value"
  },
  "input": {
    "value": "x"
  }
}

Must yield:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

[ <foo:input> _:b1] .

_:b1 {
   [ <foo:value> "x"] .
}

or, to make it into n-Quads

_:b0 <foo:input> _:b1 .
_:b2 <foo:value> "x" _:b1 .

This is what happens today. The object foo:input is a graph (that is what "@container": "@graph" means after all, right?) and this does not mean it is (also) the subject of a triple within that graph. These are two different things.

In other words,

_:b0 <foo:input> _:b1 .
_:b1 <foo:value> "x" _:b1 .

is, imho, plainly wrong.

We seem to be in an impass; maybe we should try to ask the opinion of another RDF expert...

[gkellogg]

You're correct that that's what the spec says now, the proposal is to change this meaning. As this is entirely new behavior, there is no real compatibility issue. It is most useful if the default subject of the graph is the same as the graph name, for the purposes of shape matching, anyway, but in general traversing between graphs.

[iherman]

If I change this meaning I create a backward incompatible version of JSON-LD. Didn't we say that is a big no-no?

We can introduce a new type of @container (I am not sure I would like this) which has an additional semantics. I am not sure how one would define that formally, and I think it would add to the general confusions...

[gkellogg]

JSON-LD 1.0 had no graph containers, so there is no backwards compatibility issue. In 1.0, all named graphs were explicit. The "@container": "@graph" is something introduced in the CG work, basically to handle the Verifiable Claims issue.

[iherman]

Ah, m’y bad. sorry about that.

I still feel a bit uncomfortable, but less. It somehow more than a “simple” container: it is not the property refers to a graph, but it refers to a graph that has a special additional behavior. This is different than, say, a container to a list, whch is just that: refers to a list, without any further strings attached. These mini, baroque additional thingies may bite us later because it will contribute to the overall impression of a very complex language.

[ericprud]

This proposal is specifically intended to address the increased complexity that arises when creating disconnected nodes in a graph (see the first TRIG example in my write-up above).

My guess is that some folks may want to motivate more controls in the @context; what we're working on here is the default behavior in the absence of extra directives for synthesizing URLs when there's no @id in the nested graph.

In Linked Data, there's a sharp divide between the purists who want to separate graph names from the nodes for which those graphs were created and pragmatists who don't see the need.

• Purist: <http://…MyFoafPage> has an RDF node <http://…MyFoafPage#me> which stands for me;
• Pragmatist: The Uniprot page <P04637> has a Turtle representation which states that <P04637> rdf:type up:Protein.

In the pragmatist approach, <P04637> identifies both the page and the protein. In the purist approach, a trick of HTTP (that the fragment identifier is not passed in an HTTP request) allows us to map from the node <http://…MyFoafPage#me> to the page <http://…MyFoafPage> (though not the other way around).

Because there's no analogous trick for bnodes (implied by objects with no @id), we are stuck with adding extra triples. Above, I described two approaches which synthesize extra URLs, one in the referring graph (root connector) and one in the referenced graph (root annotation). The root connector approach could have lots of forms. I mocked one up where the referring predicate got a sibling triple pointing to the root node:

_:b0 foo:input _:b1 .
_:b0 rdf:rootNode _:b2 . # <-- root connector
_:b1 { _:b2 foo:bar "a" … }

A perhaps more forward-thinking approach would be to create a structure for pairing roots with graphs:

_:b0 foo:input _:b1 .
_:b1 rdf:graphReference _:b2 . # <-- identify the created graph
_:b1 rdf:rootNode _:b3 . # <-- identify the node implied by the nested JSON object
_:b2 { _:b3 foo:bar "a" … }

A pairing of a graph name and a root or focus node would be helpful in other contexts e.g. identifying the pair of created web resource and RDF node in the return from a POST to an ldp:Container. Addressing this would also stanch the "I can't believe you guys haven't already solved this" comments I hear in HL7 when trying to use RDF to represent clinical resources.