- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 25 Apr 2013 09:10:11 -0400
- To: public-rdf-wg@w3.org
On 04/24/2013 09:56 AM, Antoine Zimmermann wrote:
> I'm a bit annoyed by the new definition of merge in RDF Semantics.
> Currently, merge is just set union.
>
> First, I dislike the fact that we give a new name for an existing
> concept, namely, set union, when it applies to RDF graphs. Isn't union
> a good name to talk about union? Superficially, this looks like we
> have changed the definition of merge. In effect, we simply removed it
> alltogether, keeping only the notion of union, which existed already.
>
> Second, the merge (=union) of a set of RDF graphs is not logically
> equivalent to the set. There is a literature about RDF, and
> specifications made on top of RDF, that relies on the notion of merge
> as in RDF 2004, where this equivalence holds.
>
> Third, what positive impacts does it have (with evidence that it is
> positive, not just "I think it is simpler this way")? I does not have
> any impact (positive or negative) on implementations.
>
> Fourth, merge in RDF 2004 could be made by simply giving 2 graphs in
> any representation, and nothing more. In 2013, merge requires one to
> know the scope of bnode identifiers when the RDF graphs are provided
> in a concrete serialisation. As a rule of thumb, we said that scope is
> delimited by files. But what about graphs that are not in files? E.g.,
> in an in-memory model? In a data stream? And what about files that
> contain several graphs? e.g., in different examples of one PDF
> article? or a serialised Java object that contains several Jena models?
>
> The situation thus evolved from "I don't know whether I should do a
> merge or a union" to "I don't know how to merge/union". In both cases,
> you need the extra knowledge, but in one case, we keep our standards
> persistent.
+1 the terms "merge" and "union" are definitely used (eg in
discussions of ways different SPARQL systems work), with the 2004
meanings, and we should not get rid of or change them.
- s
Received on Thursday, 25 April 2013 13:10:21 UTC