"OWL" Entailment

There are some questions that pretty much all more or less expressive  
entailment regimes have to answer to be a sane SPARQL entailment regime:

1) If you entail BNodes, what/how many BNodes do you return?
	Example (Simple Entailment):
		s p o entails  s p _:g.
	Should SELECT ?X WHERE {s p ?X} return both s and _:g? (No!)

	Compare with:
		s p o.
		s p _:g.
	Where we do *now* get 2 answers (and should).

	Example (OWL):
		s rdf:type [a owl:Restriction;
			owl:onProperty :p;
			owl:someValuesFrom owl:Thing]
		entails s p _:g.
	
	Should SELECT ?X WHERE {s p ?X} return anything? (I say no) But
			s rdf:type [a owl:Restriction;
			owl:onProperty :p;
			owl:someValuesFrom owl:Thing].
			s p _:g.
	should return one answer.

2) If your data is contradictory, what should you return?
	Typically, contractions entail everything, thus infinite answers.
	Obvious solution is to return a fault (with no answers) and suggest  
using a weaker entailment regime.

3) If your query contains "higher order" variables, what do you return?
	Example (OWL):
		?C rdfs:subClass ?D
	Always has infinite answers, e.g., owl:Thing, UnionOf(owl:Thing,  
owl:Thing), etc.
	Solution (in SPARQL-OWL) restrict solution set to names of classes.  
Pretty standard. RDFS gets this for free as it has no compound classes.

4) Controlling variable range (related to 1)

In OWL systems (such as Pellet, RacerPro, and KAON2) there are two  
kinds of variables "distinguished" and "non-distinguished" which are  
distinguishable by what sorts of bindings they allow: names only (and  
maybe "static" bnodes) or arbitrary elements of the domain. (See  
around slide 24 of <http://www.cs.man.ac.uk/~bparsia/2006/row- 
tutorial/index.html>.) It's good to allow for both sorts since  
distinguished variables are much cheaper to compute but non- 
distinguished variables get you more answers.

5) I've lost it :)

There are different answers one could make at various points. For  
example, with 2, you could try to return some answers, or the  
contradictory bits. For 3, you could return solutions drawn from the  
set of subconcepts of the ontology. However, I think in each case  
there is an obvious, simple, implementable, compatible with current  
sparql answer that is quite reasonable for most applications and is  
"upwards compatible" with future elaborations.

I'll also note that the answers to these questions that I propose  
make specing Simple, RDF, RDFS,

Cheers,
Bijan.

Received on Wednesday, 6 May 2009 17:10:36 UTC