On framing a context

Hi all!

I have been meaning to study up on the framing algorithm and write
down my own perspective on framing. But I'd like to get something out
now for discussion.

I mainly agree with Ivan that framing is closely related to things
like CBD. I recently (some days ago) made a draft JSON-LD serializer
[1] for use in our legal information service application (both for
exposing linked JSON entries and for indexing in ElasticSearch). The
JSON representation is a simple conversion made after I've run a
SPARQL CONSRUCT query [2] to pick important data about the current
resource, and both outgoing and *incoming* relations (which are
*crucial*, more on that below).

So the problem of framing -- as I see it -- can either be generally
approached (like with CBD), or be expressed as a
domain/scenario-specific data extraction method (e.g. a SPARQL query,
or IIUC the current JSON-LD framing). I've done the latter in most
situations, as there are almost always some important, non-general
details to handle (e.g. I want data about the person something is a
homepage of, or I need to add information about a legal document
superseding the current one; but I *don't* want to provide all the
thousands of documents who are part of a collection in a view of that
collection).

Now, I'm quite interested in how a JSON-LD context can help me
*simplify* generating these scenario-specific SPARQL constructs. (I've
previously sketched on ways to generate SPARQLTree-compliant [3]
queries from the Gluon equivalent of @context.) I will get back to
this with a more thorough analysis of the current JSON-LD approach
compared to that. But suffice to say, I believe that framing is
orthogonal to serialization, and although certain formats can help you
express specific needs, it is probably wise to leave it out of the
core spec..

Finally, and most pressingly for me: for my needs there is an
important piece missing in the JSON-LD format. I need a way to express
"@rev" relations to the current resource, i.e. "things linking to
this". I have currently done it as follows.

Given:

  <http://example.org/someone#self> :homepage <http://example.org/someone> .

If I generate a JSON-LD view for <http://example.org/someone> (the
homepage), I want:

  {
    "@subject": "http://example.org/someone"
    "@rev": {
      "homepage": [
        {
          "@subject": "http://example.org/someone#self",
          "homepage": {"@subject": "http://example.org/someone"} //
this may seem redundant, but there are situations where it makes sense
to keep
        }
      ]
    }
  }

This means that the "@rev" contains the set of properties via which
other resources are linked *to* the current subject. This example may
seem contrived, but that's mostly because it lacks richer data. In
real scenarios there's often a set of resources related to the current
one which are important to supply data about in order to be able to
e.g. generate a comprehensive web page. Or for that matter, be able to
successfully navigate between resources.

Since I give the serializer only the triples I want in the output
JSON, it was simple to serialize data like the above automatically,
without any explicit framing mechanisms in place. The "framing" is
simply done by the preceding CONSTRUCT, in that I there pick which
paths from/to the current resource to follow and which properties of
the related resources I need.

There is one sole premise for this to work: the serializer needs to
know which resource will act as the *root* JSON object. But that's
what I find appealing with JSON-LD -- it doesn't primarily express
arbitrary collections of potentially disconnected triples, but focus
on a "subject-oriented" approach. Which I've found to be the useful
way for expressing linked data entities in JSON, given how and by whom
it's intended to be used. (For directly representing rich graphs, we
already have RDF "proper" in XML and Turtle.)

(You can see working code for this (albeit work-in-progress) at [1].)

If you see the usefulness of this I'll strive to write down a proposal
and spec text for this "@rev" mechanism.

Best regards,
Niklas

[1]: https://github.com/rinfo/rdl/blob/develop/packages/java/rinfo-base/src/main/groovy/se/lagrummet/rinfo/base/rdf/jsonld/JSONLDSerializer.groovy
[2]: https://github.com/rinfo/rdl/blob/develop/packages/java/rinfo-service/src/main/resources/construct_relrev_data.rq
[3]: http://code.google.com/p/oort/wiki/SparqlTree

Received on Thursday, 1 September 2011 10:06:34 UTC