Re: Really minimal dataset semantics

Having the default graph simply be the merge of the named graphs is only one 
possibility.  There are many others, including the one raised by Pat in the TC 
today, where the default graph is extracted from the named graphs and excludes 
questionable stuff in them.   I thus don't see that an argument based solely 
on this use of datasets holds water.

I still have problems with inconsistency in the named graph making the dataset 
inconsistent.  For example, I may just want to record multiple graphs and the 
default graph may just be the first one, sort of a first among equals.

I also have problems with any dataset semantics that isn't based on the actual 
form of the named graphs.   Isn't a major use of datasets supposed to be for 
associating a graph with its source?  if so, neither of these two semantics 
seems to be correct, as the meaning of a named graph in a dataset is not a 
graph but is instead something like an equivalence class of graphs.  The 
semantics then destroys the relationship between the name and the actual 
graph. (Of course, you could always just ignore the semantics and directly use 
the graph from the dataset, but then what is the point of having the named 
graph there?)

peter

PS: Sorry for not explicitly bringing up this last point before.


On 09/19/2012 12:58 PM, Antoine Zimmermann wrote:
> 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,

Received on Wednesday, 19 September 2012 20:13:28 UTC