Re: Issue-130 (conformance)

On 8 Sep 2008, at 21:29, Ivan Herman wrote:

>
>
> Ian Horrocks wrote:
>>
> [snip]
>>>
>>> To go back to the original issue and Ian's proposal: I actually  
>>> do not
>>> have a problem with the current formulation for entailement  
>>> checkers.
>>> Yes, implementation may simply say that they return UNKNOWN if  
>>> they do
>>> not want to go down the path of the theorem 1 checking, and that  
>>> is fine
>>> with me.
>>>
>>> Unless we go along with the extra stuff above, I'm still not  
>>> fully sure
>>> what this whole thing means for the implementation pattern where  
>>> a, say,
>>> forward chaining engine like Oracle's expands the graph (that  
>>> include
>>> the ontology) and then SPARQL queries are issued on the result.  
>>> After
>>> all, SPARQL queries do not usually return True or False, they either
>>> bindings to patterns or they do not return any binding. My rough  
>>> reading
>>> is that applications should interpret an empty binding return as
>>> 'unknown', and that is it; the underlying OWL-RL implementation  
>>> does not
>>> necessarily have anything else to do. (I know implementation may
>>> implement more rules than those listed in our document, but that is
>>> another issue.)
>>>
>>> Is that correct? It does not feel 100% right, but I cannot put my  
>>> finger
>>> on it...
>>
>> I don't think that this is correct -- an empty answer might be the
>> correct answer.
>>
>> Answering a query amounts, in theory, to checking for every possible
>> answer tuple if that tuple is entailed by the ontology. E.g., if the
>> query simply asks for C(?x) (i.e., for all the instances of C),  
>> then we
>> can think of this as checking for every URI name u in an ontology  
>> O if O
>> entails C(u). Thus, we can guarantee that the answer is sound and
>> complete only if we can guarantee that checking such entailments will
>> never return Unknown. Theorem 1 indicates when this is the case for
>> implementations based on the RL/RDF rules -- i.e., when the  
>> ontology and
>> query satisfy the relevant conditions. If these conditions are not
>> satisfied, or if the conditions have not been checked, then only
>> returning answers for which the relevant entailment check returns  
>> "True"
>> will ensure that query answers are still sound, but completeness  
>> cannot
>> be guaranteed.
>>
>
> Is it really different from what I said for an implementation that  
> does
> not check Theorem 1? Your note in the document says that such
> implementation should return Unknown if the entailement True is not
> possible. Ie, if no match is found for, say, C(?x), the correct answer
> for such an implementation is, formally, Unknown...

If I ask a simple entailment question (sometimes called a Boolean  
query), e.g., "Does O entail C(Ivan)?", then I expect the answer to  
be either yes (True) or no (False); in practice it could also be  
Unknown if an implementation isn't able to determine a definite  
answer. If I ask a retrieval query, e.g., "what are all the ?x such  
that O entails C(?x)?", then the answer I expect is a (possibly  
empty) set of URIs -- neither yes nor no makes much sense. In  
practice it could be the case that an implementation isn't able to  
guarantee that the answer set includes all the valid answers -- e.g.,  
if Theorem 1 doesn't hold or wasn't checked. In this case, returning  
the answer Unknown still doesn't seem to make much sense -- an  
implementation probably may/should/must return the computed answer (a  
possibly empty set) along with an additional indication that this  
answer may not be complete.

Ian


>
> Ivan
>
>> Ian
>>
>>
>>
>>>
>>> Ivan
>>>
>>>>
>>>>      -- Sandro
>>>>
>>>
>>> -- 
>>>
>>> Ivan Herman, W3C Semantic Web Activity Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>
>
> -- 
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Monday, 8 September 2008 21:54:58 UTC