Re: Issue-130 (conformance)

Ian Horrocks wrote:
[snip]
>>>
>>> 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.
> 

O.k. I understand. The problem of course is that SPARQL, by default,
does not have such status indication information (hence Sandro's attempt
to formalize it), at least not in the current release.

I am not sure whether our documents should say anything about this or
not but then it seems that we cannot really specify the full behaviour
of such an implementation pattern (chaining rules+SPARQL). This may be
all right although maybe a note somewhere making this clear would help.
Maybe...

Thanks

Ivan

> 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
> 

-- 

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