Framing with value matching, aggressive re-embed, deep filtering, and graph support

Hi all,

I just updated my JSON-LD processor [1] to support:
 a) more specific frame matching aka value matching [2]
 b) deep filtering [2]
 c) aggressive re-embedding [3]
 d) don't embed all children by default [2]
 e) named graphs [4]
  
I also uploaded a modified version of the playground [5] so that you can try
it out without having to download/install anything. I'm sure there are still
some minor bugs in my implementation but overall I think this would be a
great enhancement for framing and would make it much more useful.

Let me quickly describe each feature for those that didn't read the whole
discussion in the issue tracker.


a) More specific frame matching aka value matching [2]
----------

This allows you, e.g., to filter values by their language or just return
subjects where a property has a specific value. In the following example, it
could be used to just return the German and Italian label, e.g.

{
  "@context": {
    "ex": "http://example.com/vocab/"
  },
  "@id": "http://example.com/experiment",
  "ex:label": [
    { "@value": "experiment", "@language": "en" },
    { "@value": "Experiment", "@language": "de" },
    { "@value": "esperimento", "@language": "it" }
  ]
}

See: http://bit.ly/JnjF1W



b) Deep filtering [2]
----------

This means that the framing process does not restart at every level but
deeply traverses the graph and just returns a result if the frame matches
the input graph.
Taking the library example from the JSON-LD playground (a library that
contains a book that in turn contains a chapter), the following frame:

{
  "@context": {
    "dc": "http://purl.org/dc/elements/1.1/",
    "ex": "http://example.org/vocab#"
  },
  "ex:contains": { "@type": "ex:Chapter" }
}

Should in my opinion just return the book (at the top-level of the result)
and the chapter it contains and not the library as the current spec does.

See: http://bit.ly/KkGmI3 in contrast to http://bit.ly/Lzrxh6 which is the
currently specified behavior

Btw. this and a) made me drop support for @omitDefault.



c) Aggressive re-embedding [3]
----------

This was an issue raised by Josh Mandel. The current framing algorithm tries
to avoid to embed the same data multiple times which makes it difficult to
work with the returned data as it is not trivial to foresee where the data
will be embedded and where it will just be referenced.
Gregg's example illustrates that quite nicely: http://tinyurl.com/7jzaqj3
(look at doap:creator and doap:developer).

By aggressively re-embedding data by default as deep as the frame is this
problem can be circumvented completely. 

See: http://bit.ly/JF7ZJv 



d) Don't embed all children by default [2]
----------

As currently specified, framing automatically embeds all children (just up
to the point at which cycles would occur). While this is sometimes desired,
I think most of the time it isn't. An author should (by default) just get
back what he requested and not a potentially huge graph in which most of the
data is irrelevant.

Look at the slightly modified library example (for the sake of this example
the chapter contains a library to create cycle) with an empty frame:
http://bit.ly/Kej7Q5

All the data is included three times which is most likely not what the
author intended (at least in my opinion). In contrast, by not embedding
everything by default, the output would reflect the author's intent more
closely in my opinion: http://bit.ly/JFXdaz

Since Dave Longley pointed out that Digital Bazaar needs that behavior in
PaySwarm I added a @embedChildren flag which will restore that behavior (see
http://bit.ly/LTMw4A). Nevertheless, I strongly believe this should be
turned off by default.



e) Named graphs [4]
----------

Last but not least I implemented support for named graphs. It is, e.g.,
possible to select all subjects defined in a graph by a frame like the
following:

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "ex": "http://property.com/"
  },
  "@id": "http://example.com/graphA",
  "@graph": {}
}

See: http://bit.ly/KNkW1P



[1] https://github.com/lanthaler/JsonLD/
[2] https://github.com/json-ld/json-ld.org/issues/110
[3] https://github.com/json-ld/json-ld.org/issues/119
[4] https://github.com/json-ld/json-ld.org/issues/118
[5] http://www.markus-lanthaler.com/jsonld/playground/



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 27 May 2012 13:54:31 UTC