Really minimal dataset semantics

Pat and Peter,


The so called minimal dataset semantics proposed in the wiki is not 
minimal, and this non-minimality causes the issues mentionned by Peter.
The tricky entailment of
http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics#Brain_twisters
is an example of the trouble caused by the constraint that IRIs denoting 
the same resource must map to a single graph.

It is not the proposal I initial wrote, and I support another proposal. 
My initial more-minimal proposal was:
http://www.w3.org/2011/rdf-wg/wiki/index.php?title=TF-Graphs/Minimal-dataset-semantics&oldid=2438

Entailment is independent in the default graph and in the named graphs 
as long as the default graph is consistent.

This addresses one of Peter's comment.

Now, let us examine the situation wrt the consistency of the default 
graph. The argument comes from an implementation practice in SPARQL 
store. If we approve the Proposal made by Sandro, then such a practice 
is irrelevant to us for the definition of dataset semantics.

When you want to exchange a dataset between systems, I doubt it would be 
a good idea to serialise the merge of all the graphs, in addition to 
serialising all the named graphs themselves. That would be insanely 
redundent. So, in the end, what gets exposed, and what has to be 
interoperable, does not (or should bot, if that's what people do) 
contain an unrestricted, unclean garbage of triples inside the default 
graph.

I doubt that people are going to write TriG files where all the triples 
get duplicate because inside the implementation there was the "default 
as union" policy.

Isn't this TriG file ridiculous?  I wish it was inconsistent.

{ :s owl:differentFrom :s .
   # 10000 other triples from :g1
   rdf:type owl:sameAs owl:sameAs .
   # 10000 other triples from :g2 }
:g1 { :s owl:differentFrom :s .
   # 10000 other triples from :g1 }
:g2 { :rdf:type owl:sameAs owl:sameAs .
   # 10000 other triples from :g2 }


The more-minimal dataset semantics is not clashing with SPARQL. Before 
SPARQL 1.1 Entailment Regimes, there was no way to query an inconsistent 
graph with the default regime. With SPARQL 1.1, it is possible to sublit 
a query to an inconsistent graph, which may generate an error. But at 
any moment of the query resolution, only the semantics of graphs are 
used. The query engine has to resolve Basic Graph Pattern matching 
according to the graph-entailment regime, and build the complete answers 
to the query according to SPARQL algebra. Dataset-semantics is never 
involved.

So, according to this view, I'm interested in knowing if there are still 
counter arguments from Pat or Peter.
If there are, would the objection be a firm "-1" or something else?


Best,
-- 
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, 19 September 2012 16:59:21 UTC