Proposal: A @container using @graph

Rather than continuing to reiterate the use case we have for language maps
(which has been called a bogus use case and an anti-pattern by members of
the WG), I thought it could be worth looking at another option.

What Drupal needs isn't really language management. Drupal needs version
management, where the versions just happen to be based on language. That's
why I originally considered named graphs. The idea of using named graphs
for our use case made members of the WG balk and we were encouraged to look
to language maps.

However, it seems now that language maps need to round trip to RDF. This
means that language maps will force a change in the data model... for
example inserting blank nodes in between a subject and its properties. I'm
unclear on why it is preferable to create blank nodes in a data model than
it is to use a named graph. The named graph at least lets you keep the same
base triple structure, and consumers can choose whether or not to pay
attention to the 4th element of the quad. As I recall, on a telecon where I
brought it up, Gregg said that named graphs shouldn't be used unless you
needed to make statements about the graph itself. However, others such as
<a href="http://blog.ldodds.com/2009/11/05/managing-rdf-using-named-graphs/">Leigh
Dodds</a> have discussed using named graphs for versioning or providing
context, and I'm not sure that it's such an unconventional idea.

I would be interested to hear what concerns the WG have with this sort of
use of named graphs.

Besides being discouraged from using them by the WG, the other reason I
decided against named graphs was because there was no good way to access
properties in named graphs. Since JSON-LD's query API is still unspecified,
direct access to properties using the tree structure needs to be easy for
the end user developer.

Instead of continuing to try to shoehorn language maps into our use case
(or vice versa), I'm wondering whether making named graphs easier to
traverse would be a better option.

For example, I imagine something like:

{
    "@context": {
        "site": "http://ex.org/",
        "body": {
            "@id": "site:body",
            "@container": "@graph"
        },
        "en": "site:node/1/en",
        "de": "site:node/1/de"
    },
    "@id": "site: node/1",
    "body": {
        "en": [
            "Here is some body text for the article."
        ],
        "de": [
            "Hier sind einige Textkörper für den Artikel."
        ],
    }
}

It would normalize to:
<site:node/1> <site:body> "Here is some body text for the article."
<site:node/1/en>
<site:node/1> <site:body> "Hier sind einige Textkörper für den Artikel."
<site:node/1/de>

And values could be accessed the same way as was intended with language
maps:
obj.body.en[0]

I imagine this could be useful for expressing version information beyond
language (for example, revisioning), which I could see being a large use
case for many other CMSs besides Drupal.

-Lin

-- 
Lin Clark
Drupal Consultant

lin-clark.com
twitter.com/linclark