Yet Another Point of Entailment/Virtual Graph point of clarification

Voluminous email with Enrico reveals some stuff.

There are three ways on the table for specifying query answers.

1) Virtual graph deductive closure (
2) Enrico deductive closure
3) Enrico entailment

2 is equivalent to 3 as Enrico has presented.

All three, I believe, handle the disjunction problem.

1 is a bit trickier, especially when we get to more expressive 
languages (it probably is the same as 2 and 3 for simple, rdf, and 
rdfs). Also because no one has worked out the details :) For OWL-DL, 
for example (and perforce OWL Lite), what is the Virtual Graph that 
corresponds to the deductive closure of an OWL DL ontology such that we 
may match our sparql queries against? OWL DL entailment is specified in 
terms of OWL abstract syntax:
	<http://www.w3.org/TR/owl-semantics/direct.html#3.4>

So, we can get the deductive closure of the Ontology in abstract 
syntax, but we cannot query that with Graph Patterns, since they are 
the wrong shape. So you have two choices: 1) convert the Graph Pattern 
into an "abstract syntax pattern" (which we have not done) or 2) covert 
the deductive closure in abstract syntax into an OWL ontology in RDF 
graph form.
	<http://www.w3.org/TR/owl-semantics/mapping.html#4.2>

One must be careful since
	"""An RDF graph is an OWL DL ontology in RDF graph form if it is equal 
(see below for a slight relaxation) to a result of the transformation 
to triples above of a collection of OWL DL ontologies and axioms and 
facts in abstract syntax form that has a separated vocabulary. """

and the transformation is highly non-deterministic, with lots of 
optional information one might expect. E.g., for any property P, the 
transformation table:
	<http://www.w3.org/TR/owl-semantics/mapping.html#4.1>

*permits* but does not require a corresponding triple:

	P rdf:type rdf:Property .

So, a trasnformation that included all these optional triples would 
have non empty answers to:

[Q1]	?p rdf:type rdf:Property

whereas one that did not, would always return no answers for [Q1].

2 and 3 agree with the conservative transformation for [Q1].

Keeping [Q1] non empty for RDF, RDFS on up is a desirable property, but 
opens a can of worms. Allowing arbitrary non-empty "syntax-queries" 
(that is queries with any of much of the RDF, RDF, and OWL namespaces) 
by querying the deductive closure of an OWL ontology in RDF Graph form 
essentially puts you into OWL Full entailment, and probably 
undecidabilty (Enrico says that Boris Motik has a proof; I'm just not 
sure that there isn't a motivated restriction to the 1 view that would 
be decidable.)

Some queries that are empty on the 2/3 view no matter what the dataset 
with OWL-DL/Lite entailment:
	miranda rdf:type ?C

	?C rdfs:subClassOf Tree

	?p rdf:type owl:ObjectProperty

	?C owl:equivalentClass ?D

These are non empty on many owl ontologies under bnode-redundant, 
simple, rdf, and rdfs entailment.

Conlusions: 1, 2, and 3 all handle the disjunction case, which means 
they can be used with more expressive semantics for source documents 
(e.g., OWL). 3 (and the equivalent 2) correspond to most of the current 
suite of OWL-DL query implementations (though there are some which go 
somewhat beyond). 1 may or may not be brutal for those implementations 
(and would certainly need more work from the working group to help 
determine this).

1 is a subset of OWL Full entailment (probably).

It is tricky to make 1 correspond to 2 or 3 (and it will end up be very 
ugly since you'll have to add a bunch of restrictions and 
qualifications).

This I think reinforces the decision to move toward Enrico's language 
(i.e., 2 and 3). 1 then is subsumed by OWL Full entailment.

Test cases can be generated from analogues of the queries above. We'll 
have answers from told-bnode, simple, rdf, rdfs and owl full 
entailment, but not from OWL-Lite and OWL-DL entailment, for certain 
ontologies.

I would expect some (sophisticated) client implementations (ok, MY 
client implementation :)) to check such queries that are determinably 
empty from the syntax of the query for a given level of entailment. (Or 
maybe and editor.)

I regret that we don't have a primer to put this sort of thing in :)

Cheers,
Bijan.

Received on Monday, 26 September 2005 23:28:25 UTC