Re: second review of json-ld

Gregg Kellogg
gregg@greggkellogg.net

On Mar 29, 2013, at 8:24 AM, Sandro Hawke <sandro@w3.org> wrote:

> ...
> 
> Alas, there is no defined way to merge RDF datasets.
> 
> The problem is that sometimes it's obvious that the merge of
>     <g> { <a> <b> 1 }
> and
>     <g> { <a> <b> 2 }
> is 
>     <g> { <a> <b> 1,2 }
> and sometimes it's obvious the two can't be merged because they contradict each other.
> 
> See: http://www.w3.org/2011/rdf-wg/track/issues/17
> RESOLVED: close issue-17 -- there is no general purpose way to merge datasets; it can only be done with external knowledge.
> 
> Proposed solution is to define it here, something like:  If multiple embedded JSON-LD documents are extracted as RDF, the result is a dataset formed by merging all the graphs that have the same name (and thus making a single named graph per graph name) and all the default graphs (to make one resulting default graph).
> 
I discussed this on the GitHub issue tracker too.

We had a discussion on IRC about the problems of merging default graphs. For example, if a developer re-states the facts in both RDFa and JSON-LD in the same document (worse, microdata, which almost encourages the use of BNodes), the result will be a merger with duplicate BNodes, that typically are intended to be exactly the same node.

One way would be to provide an algorithm for creating a named graph to contain the default graphs of all included script, microdata or RDF/XML which is also extracted (another case where BNode graph IDs would have been useful). Alternatively, a Note on the subject could just warn against this pattern.

Alternatively, the result could simply be a set of graphs and datasets where there is no defined merger, leaving it up to the application; however, I don't find this very satisfying.
> ...
> 
>     -- Sandro
> 
> 
Gregg