Re: Review of Entailment Regimes (Action-317)

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