Thoughts on Framing named graphs

Although the framing algorithm hasn't been documented adequately, it's been implemented by both Dave and myself. However, our addition of named graphs has added some complications. (Note that algorithms for from/to RDF have already been updated, and expansion/compaction required only minimal changes..

The basic issue is that framing works by first flattening the document to an array of JSON objects in expanded form. Given that the @graph bit is required structure, we can't simply do that (usually). Also, the existence of named graphs implies other usage patterns where we may want to select based on graph membership, in addition to type and property.

My first suggestion is that, by default, framing flattens named graphs into a single default graph, so that the existing algorithm works as is. For many respects, this is what people want to do anyway, so by default, I'd suggest that we just leave the algorithm as is, with the exception that @graph contents, which would otherwise just contain references to the named objects, would be removed.

Consider the following document (test fromRdf-0005.jsonld):

[[{
  "@id": "http://example.com/U",
  "@graph": [
    {
      "@id": "http://example.com/Subj1",
      "@type": ["http://example.com/Type"],
      "http://example.com/ref": [{"@id": "http://example.com/U"}],
      "http://example.com/list": {
        "@list": [
          {"@value": "a"},
          {"@value": "b"}
        ]
      }
    }
  ],
  "@type": ["http://example.com/Graph"],
  "http://example.com/name": [{"@value": "Graph"}]
}]

This has a default graph, containing <U>, and a graph named <U> that includes <Subj1>. As it is now, this would be flattened to the following:

I would suggest that this would be something like the following after basic framing:

[
  {
    "@id": "http://example.com/U",
    "@type": ["http://example.com/Graph"],
    "http://example.com/name": [{"@value": "Graph"}]
  },
    {
      "@id": "http://example.com/Subj1",
      "@type": ["http://example.com/Type"],
      "http://example.com/ref": [{"@id": "http://example.com/U"}],
      "http://example.com/list": {
        "@list": [
          {"@value": "a"},
          {"@value": "b"}
        ]
      }
    }
]

Then, normal framing can operate on all elements as it does today.

However, given named graphs, people will probably want to do different types of queries. you might imagine a frame such as the following:

{
  "@graph": null,
  "@type": {}
}

This could return only subjects (with @type) in the default context and return something like the following:

[
  {
    "@id": "http://example.com/U",
    "@type": ["http://example.com/Graph"],
    "http://example.com/name": [{"@value": "Graph"}]
  }
]

Or,

{
  "@graph": {},
  "@type": {}
}

which could return all named graphs and could be something like the following:

[[{
  "@id": "http://example.com/U",
  "@graph": [
    {
      "@id": "http://example.com/Subj1",
      "@type": ["http://example.com/Type"],
      "http://example.com/ref": [{"@id": "http://example.com/U"}],
      "http://example.com/list": {
        "@list": [
          {"@value": "a"},
          {"@value": "b"}
        ]
      }
    }
  ],
}]

(note that the properties of the referring element are gone.)

There could be various combinations of these. If a frame includes @graph, then flattening would preserve the @graph structure when flattening the graph, maintaining parralel structures at the base for subjects in the un-named graph, and the same flattening structure within each @graph. This should allow the flattening algorithm to work recursively on each graph and require only relatively small changes.

Specifying a @id along with @graph could limit the results to only the graph with the specified ID. In this case, it might remove the named context, and just give the content of @graph.

Thoughts?

Gregg

Received on Monday, 16 April 2012 10:21:39 UTC