Re: Issue-130 (conformance)

On Sep 8, 2008, at 7:25 PM, Ivan Herman wrote:

> Sandro Hawke wrote:
>>
>> In SPARQL (which doesn't provide this information), we can do an  
>> in-band
>> query for reasoner metadata like this:
>>
>>    SELECT ?completeness [...your vars...]   {
>>         ?g1 { [...your pattern...] }
>>         { ?g1 owlq:completenessLevel ?completeness }
>>    }
>>
>> I think this works (thanks to Eric Prud'hommeaux for working it  
>> out with
>> me), but it would require standardizing one RDF predicate (written  
>> here
>> as owlq:completenessLevel).  It's kind of an outlier -- it's  
>> certainly
>> not part of the OWL language -- but we could be defined in some  
>> normative
>> appendix.
>
> But the down side is that we, sort of, require to modify all relevant
> SPARQL implementations to return this information.

That's going to have to happen anyway to handle owl semantics. Shrug.  
Gotta get working on the SPARQL/OWL spec :)

But, really, it's not that hard a mod, yes? All you need to do is add  
the relevant triple (for the dumb version). It wouldn't require more  
than a single line on load.

> This also means that
> one is supposed to use SPARQL in a particular way when using such a
> store.

If you care.

> I am not sure this is realistic or worth pushing...
[snip]
> 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.

Yes. Think of it this way, you can convert a sparql query into an  
entailment check (via construct) or just by doing an ask query on a  
ground BGP. If you query an implementation which is incomplete for  
atomic subsumption with the following query:

	ASK  { :C rdfs:subClassOf :D }

then, obviously, you cannot interpret no answers as anything other  
than unknown. But this isn't surprising, yes? Of course, the  
application *can* treat the no answer as a no, but it does so at its  
own risk.

I can imagine an extension that allowed a reasoner to provide extra  
information, e.g., that this no answer is really a no.

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

Cheers,
Bijan.

Received on Monday, 8 September 2008 18:54:10 UTC