- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Wed, 22 Sep 2010 18:17:18 +0100
- To: Olivier Corby <Olivier.Corby@sophia.inria.fr>, Chimezie Ogbuji <ogbujic@ccf.org>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Hi Olivier, thanks for the review. I comment inline. @Chime: I also updated the RIF part since Olivier had just syntactical and easy to do comments for that section. I also read the document again myself an made a couple of other changes (nothing major). I meant to do that earlier, but didn't find the time :-( Here's a short summary (also stated in the change summary of the document) - I updated the abstract and beginning of the introduction following Andy's comment to give a more precise and clear definition of what an entailment regime actually is. I am not completely done with that (latest tomorrow) and will update the CVS version then. - I added Section 1.4, which gives a short overview of what constitues an entailment regime, basically explaining the tables that we have for each regime. For example, I don't think we said anywhere before that the IRI of the regime is meant to be used in the service description. - The example in Section 2.1 has been extended to make the intuition behind the use of Skolemization clearer. - At the end of Section 2.2 I added an editorial note, which suggests an alternative C2 condition that basically forbits terms of the form rdf:_n as bindings. I am a bi concerned that if you want to implemen the regime via a set of materialisation rules, then at the moment, you have to look for which n the terms rdf:_n occur in the graph and for all those you add the axiomatic triples. This seems hard to do with a set of pre-defined rules that is independent of the input. If you would use the alternative, materialisation rules do not have to care for which n a term rdf:_n occurs in the input. I think it might be useful to point this out and maybe get some feedback from impementors. - I added one more example for the OWL RDF-Based Semantics entailment regime showing what inferences one can and cannot expect under this semantics. - I removed the optional condition (C4) for the Direct Semantics. This condition was actually motivated by what the OWL API required reasoners to do. (Reasoners don't have to compute all entailed data assertions since we do not have a goal-directed for this readily available.) We had several long discussion with OWL reasoner implementors regarding this and the conditions got more and more complicated to capture more and more entailments that can be computed in a goal-directed way. In the end we decided that this is getting too complicated and we just say that reasoners can be incomplete for data values and this is what the just released OWL API 3.1 says for the OWLReasoner interface. Since an incomplete implementation is anyway an option, I now removed the complicated optional restriction and just suggest that implementors say in their dicumentation if they use an incomplete algorithm for data value retrieval (literal bindings). Best regards, Birte On 21 September 2010 14:01, Olivier Corby <Olivier.Corby@sophia.inria.fr> wrote: > Hi, > > The document is in a good shape and I have the following comments. > > Olivier > > > > SPARQL 1.1 Entailment Regimes > > W3C Working Draft ?? May 2010 > > ** Set up the date I don't think we have set a date yet, I will update as soon as we have one. > 1.1.1 Graph Syntax > abbreviatens done, abbreviations > 2.1 Blank Nodes in the Queried Graph (Informative) > infinie answers done > 2.2 Answers from Axiomatic Triples (Informative) > > Although μ3(?x)=rdf:subject does not occur in SG, it occurs in rdf-Minus > ** should be: in rdfV-Minus done > Since μ5(?x)=rdf:_2 occurs neither in SG nor in rdf-Minus > ** should be: in rdfV-Minus done > 2.4 Boolean Queries (Informative) > The two conditions C1 and C2 also have an effect on the answers to Boolean > queries. For Boolean queries that contain variables, e.g., > > ASK { ?x a rdf:Property } > > The query answer is yes (true) if there is at least one solution mapping > (i.e., a solution that satisfies also conditions C1 and C2) and it is no > (false) otherwise. For example, if the queried graph is the empty graph, the > query has no solution since even if a pattern instance mapping yields an > axiomatic triple, condition C2 cannot be satisfied. > > ** The query pattern has for solution triples from rdfV-Minus and hence the > answer is true. done > Editorial note > > If the modified condition would only apply to variables hat > ** that done > 3.1.1 Effects of Unchecked Inconsistencies > discoverning done > 6.2 The OWL 2 Direct Semantics Entailment Regime > An implementation of the OWL 2 Direct Semantics entailment regime may > restrict the use of literal variables and may only literal bindings from a > set of easy to compute bindings. > > ** verb is missing in: may only literal bindings from added verb use > 6.3.2 Restriction on Data Property Assertions > succesors done > 7 RIF Core Entailment > It also maintained a correspondence > ** maintains done > In addition and as described in [OWL2-RL-RIF] , > ** [OWL2-RL-RIF], I assume that this refers to the extra space between the reference and the comma: removed > 8 Entailment Regimes and Data Sets (Informative) > > The named graphs contain the following data: > > http://example.org/a.rdf: > > ex:p rdfs:domain ex:A . > > http://example.org/b.rdf: > > ex:x ex:p ex:y . > > If we ask the following query under RDFS entailment > > SELECT ?g WHERE { GRAPH ?g { ex:x a ?type } } > > the answer sequence is empty > > ** I think that, in active graph http://example.org/b.rdf, RDFS entailment > produces ex:x rdf:type rdfs:Resource, by rule rdfs4a from > http://www.w3.org/TR/rdf-mt/#RDFSRules and so the answer is not empty Yes, I keep forgetting the axiomatic triples (My excuse is that I am an OWL Direct Semantics erson, where there are no axiomatic triples ;-) ) Since the main point is to show that the two graphs do not influence each other, I now changed the example query to: SELECT ?g WHERE { GRAPH ?g { ?inst a ex:A } } I believe that axiomatic triples will not ruin this one, while we still show that the domain axiom from a.rdf has no effect on the triples in b.rdf. Consequently, I also updated the following example to use this updated BGP with two from clauses. > C.1 Parsing BGPs into Objects of the Extended OWL 2 Structural Specification > > DPE(x) = DPE(x) UNION { (x, x) | x in V(BGP) and type(x)=DatatypeProperty }, > > ** owl:DatatypeProperty I actually changed this bit to repeat the table from the OWL Mapping to RDF spec because also the function type used there was not defined. Further I clarified that import triples have no effects when converting BGP into OWL axioms. -- Dr. Birte Glimm, Room 309 Computing Laboratory Parks Road Oxford OX1 3QD United Kingdom +44 (0)1865 283520
Received on Wednesday, 22 September 2010 17:17:57 UTC