RDF merge in RDF Semantics FPWD

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.
-- 
Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Wednesday, 24 April 2013 13:56:40 UTC