Re: Proposal: A @container using @graph

On Nov 8, 2012, at 6:17 PM, Lin Clark <lin.w.clark@gmail.com> wrote:

> 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.

Hmm, I don't remember suggesting that named graphs should only be used when making assertions about a graph itself; do you have a reference? I could have done so, as the reason named graphs were brought in was particularly for the provenance use case, where you want to make assertions about other information.

In any case, we have come to the realization that JSON-LD is really a dataset model (like TriG) and not really a pure graph model (like Turtle). The only thing the RDF WG could agree upon is that datasets have no semantics, so we can infer that they don't in JSON-LD either. As you note many people use named graphs for all kinds of reasons, and I think (now anyway) that this might be a good solution for you.

I did see that back in July, we discussed @container: @graph as a potential solution for WikiData's solution, and if there's something we can do that addresses Drupal's use case, particularly if it does it better than language maps, then that seems like an interesting area to pursue.

> 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>

Yes, this looks right. It's certainly unusual, as the subject and property appear in the default graph, with the value(s) in the named graph, but it seems quite consistent. So, the semantics would be that the relevant subject and property are "pulled into" the named graph associated with their values, and any node definitions within that context would remain within the named graph.

Expanding such a structure (flattening, anyway) would likely look like the following:

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

Figuring out how to reverse this when compacting might be challenging, but we haven't lost any information, so we should be able to do it.

Gregg

> 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
>

Received on Friday, 9 November 2012 05:33:12 UTC