Re: Draft for a "minimal dataset semantics"

Interesting, I did not realize that.

So, if I understand things right, SPARQL has already made some decision so that (translated into the issues in this proposal):

- ISSUE 1: is actually yes per SPARQL; even more, it allows for a different entailment regime to be applied for each graph (something Antoine has considered and we discussed at some point and we thought it would be too complicated to get a consensus

- ISSUE 3: is not 100% the same in SPARQL, but SPARQL seems to have a possibility to describe what a specific service does with a graph, ie, which entailment it uses. The issue here is to use something similar for datasets (not for processing endpoint). But that is certainly something similar.

What is interesting here is the SPARQL approach to ISSUE #1. The question is whether this WG should follow the SPARQL approach. But the fact that SPARQL already does it looks like a very strong argument to do it in general, too... (which may invalidate my cautious approach I had so far)

Ivan


On Sep 6, 2012, at 15:11 , Andy Seaborne wrote:

> Maybe different graphs will have different entailment regimes in the same datasets.
> 
> http://www.w3.org/TR/sparql11-service-description/#sd-entailmentRegime
> 
> The abstract model is that entries for named graphs (sic - (name,graph) pair) are <n,G,e>
> 
>  Andy
> 
> 
> On 06/09/12 12:04, Ivan Herman wrote:
>> Antoine,
>> 
>> thank you.
>> 
>> (I have made a tiny editorial change on the page adding a number to each issue, so that we can discuss it more easily.)
>> 
>> executive summary from my side: this may be indeed consensus ready (modulo some details). I would be happy to get some sort of a resolution that the group refines the details of this but that is what will end up in the final spec.
>> 
>> Some technical details/comments; to give more structure to the discussion, I have added my personal opinion on each of the issues you've explicitly added.
>> 
>> - In section 3 (the Model-theoretical semantic) I guess the precise terminology requires us to say that V is the vocabulary of the dataset (come back to this later) plus whatever vocabulary the respective E entailment defines. Ie, if E is the OWL RDF based semantics, then there are quite a number of terms that are added to V before the definition of the interpretation function...
>> 
>> As for what is V: if I have (G,<n1,G1>,...,<nk,Gk>) then we may have several choices:
>> 
>> 1. V = G
>> 2. V = G ∪ { n1, n2, ..., nk }
>> 3. V = G ∪ { n1, n2, ..., nk } ∪ G1  ∪ ...  ∪ Gk
>> 
>> My instinct says that we should go for #2. Note that for the alternative you describe in Issue 6 on the domain of IGEXT to be valid, either #2 or #3 should be chosen.
>> 
>> - Issue 1:
>> 
>> Technically, this may be useful but it would probably made the semantics (though marginally) more complex. Actually, the alternative we also explored is where each named graph may have a different entailment regime attached. I am not sure we could get consensus on this, the complexity is a bit off putting.
>> 
>> For the sake of simplicity and moving forward, we should probably go with the current approach, ie, one entailment regime to rule them all...
>> 
>> - Issue 2:
>> 
>> I think this depends on Issue 1. If Issue 1 allows for different entailments between the graphs and the default graph, then the 'no entailment' makes sense to simplify the semantic formalism; it would make it indeed possible to have a semantics whereby some entailment is done, say, on the default graph, whereas the individual graphs are treated as some sort of a black boxes with no entailment at all. (Incidentally, this is what we meant as 'quoting semantics' in the document we put forward a few weeks ago.) But if Issue 1 is voted to keep simplicity, ie, one entailment for all, then Issue 2 is, in my view, moot.
>> 
>> - Issue 3:
>> 
>> We did discuss this and had a proposal (as you note in the text). However, I do not see any consensus coming on this in the group. Besides, no such syntax exists right now, at least in terms of the core RDF standards, for entailments in general, regardless of named graphs. So probably the answer should be 'no'.
>> 
>> B.t.w., here again, this Issue really makes sense only if Issue 1 is voted for a more complex approach. If not, then current practice definitely dictates a 'no' answer.
>> 
>> (That being said, we may define such a vocabulary in a W3C note if Issue 1 is voted as 'yes'. But that is besides the point for the current, rec track discussion.)
>> 
>> - Issue 4:
>> 
>> I think this is the same as Issue 6. See below for my vote
>> 
>> - Issue 5
>> 
>> I am not sure what I/we meant by 'quoting semantics' is exactly the same as what you describe there and, honestly, I am not even sure I understand what you write:-( But see also my comment on Issue 2.
>> 
>> - Issue 6
>> 
>> I think the distinction between what was called IRI-GEXT and RES-GEXT is fairly minor in practice. Richard had some good arguments in favour of RES-GEXT; let me add my aesthetic argument: formalizing IGEXT having the resources as a domain and not the URI-s (ie, going the RES-GEXT) is also in line with the way properties and classes are modeled in the current RDF semantics. My vote would therefore go to change the semantics in the way you describe in Issue 6 to ensure a more consistent view of the world.
>> 
>> Thanks again!
>> 
>> Ivan
>> 
>> On Sep 5, 2012, at 16:56 , Antoine Zimmermann wrote:
>> 
>>> Dear all,
>>> 
>>> 
>>> Based on the recent discussions on dataset semantics, which seemed to be rather fruitful, I made a first attempt to write down the latest ideas, as David suggested me to do, in order to have a basis for discussion in our telecon.
>>> 
>>> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics
>>> 
>>> I've put a short informal introduction as well as the model-theoretic formalisation.
>>> 
>>> I also recorded issues that may have to be solved and can affect the semantics.
>>> 
>>> This draft, at the moment, does not refer to the use cases. It only describes the semantics itself. It will be improved.
>>> 
>>> 
>>> 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/
>>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>> 
>> 
>> 
>> 
>> 
>> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Thursday, 6 September 2012 13:53:06 UTC