Re: Draft for a "minimal dataset semantics"

Le 14/09/2012 16:33, Peter F. Patel-Schneider a écrit :
>
> On 09/14/2012 09:26 AM, Antoine Zimmermann wrote:
> [skip]
>>>
>>> I prefer having the named graphs independent of each other, and
>>> independent of the default graph. I might be able to live with the
>>> situation where an inconsistent default graph makes the named graphs
>>> irrelevant, but why should I have to? We could just go back to the
>>> proposals from much earlier where these sorts of issues do not arise.
>>
>> Which proposals?
>>
>
> Here are some documents/messages with proposals.
>

For ease on the reader's side, I summarise those proposals below.

> http://www.w3.org/2011/rdf-wg/wiki/images/3/3b/Rdfwg-graphs-tf-report.pdf slide
> 5 proposal (a), although I can't find a separate source for the proposal
> itself

Ok, this is "we do not provide a formal semantics for datasets".


> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Mar/0041.html
> proposes a simpler semantics, which I prefer over the more complex one,
> but I prefer something even simpler

I've been supportive of this kind of semantics since the very beginning 
of the WG. It only got contempt. With little updates, as in the current 
version of 
http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal#Semantics, 
it got more support, but still not enough to create consensus.

This kind of semantics achieve basically the same as the "minimal" DS 
semantics where IGEXT maps IRIs instead of resources, except that the 
dataset is inconsistent iff one of the graphs, named or default, is 
inconsistent.

BTW, as I said already, I'm supportive of the IRI-IGEXT variant.


> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0188.html

Again, this is the "no semantics for dataset" proposal.

 >
> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Aug/0030.html the
> suggestion near the bottom of the message

This says "say nothing about semantics or the semantics of a dataset is 
the semantics of the default graph" and that's all.


>> To me, it is important to have entailment between datasets.
>>
>> { <n,G> } entails { <n,G'> }
>>
>> is not the same as "extract G from <n,G>, G entails G'".
>>
>> I want that the inferred triples are labeled by the graph IRI, for
>> various purposes including version management, provenance management,
>> temporal validity, etc.
>>
> I don't see what you get from this beyond entailment between RDF graphs.
> If, however, the WG ends up with some definition of entailment between
> RDF datasets, I much prefer a direct relationship between the IRI and
> the graph.

You get entailment between <name,graph> pairs. One of the things that I 
want to be able to do is materialise inferences over a dataset and claim 
"the dataset I build is known to be semantically equivalent to the 
original dataset, by virtue of the W3C approved dataset semantics".

If you say nothing, then there can be different behaviours, such as: 
extract the graph from the <n,g> pair, apply forward chaining inference 
an put back those inference inside a freshly named graph.

This is something you may want to do inside your system, and it's fine, 
but if you expose the result to the world in a TriG file, there is no 
way to understand the relation between the truth of graph in a 
<name,graph> pair, and the inferred triples that may or may not exist in 
a different pair.


There's also the argument relative to semantic extensions of the dataset 
semantics for dealing with certain cases. To specify an extension, you 
need at least a base semantics. Otherwise it's just yet another 
semantics from scratch.
There are very strong connections between the dataset semantics, however 
simple it may be, and contextual logics.


--AZ

>
> peter
>
>
>

-- 
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 Friday, 14 September 2012 15:21:46 UTC