RE: Proposal: A @container using @graph

I created ISSUE-195 for this proposal:

https://github.com/json-ld/json-ld.org/issues/195



> -----Original Message-----
> From: Gregg Kellogg [mailto:gregg@greggkellogg.net]
> Sent: Friday, November 09, 2012 6:32 AM
> To: Lin Clark
> Cc: public-linked-json@w3.org
> Subject: 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 10:36:26 UTC