W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

Re: "OWL" Entailment

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 7 May 2009 11:45:13 +0100
Message-Id: <8BD40196-FDEB-4A56-9F6D-5BA9CAA6B1AB@cs.man.ac.uk>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
On 7 May 2009, at 10:45, Ivan Herman wrote:

> Thanks Bijan!
> one small remark
> Bijan Parsia wrote:
>> 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.
> This may be dependent on the OWL Profile, too. The OWL RL (at least  
> the
> rule set) does not lead to infinite answers I believe.

Well, no system actually generates infinite answers. The infinite  
answers are, however, entailed.

> It does make
> sense then to say that we return all possible answers.

This would enshrine an implementation technique. One, of course,  
could do that, but it makes interop more difficult.

> The issue is, of
> course, how one signals that there _is_ a problem...

There are many ways to derive answers in the presence of  
contradictions. I would tend toward requiring a fault and no answers  
(standardly), but then, of course, systems could provide some sort of  
answers in some auxiliary mode.

Just because there is a determinate finite set of answers doesn't  
mean that we should return them. (IOW, finitude is only one aspect of  
determining a sensible answer set.)

So, personally, I'd rather that the default entailment regimes for  
these semantics was conservative. As people get more experience, they  
can add more complex behaviors in the presence of contradictions.

> RDFS might be similar (disregarding the issue of infinite triple
> generation with rdf:_n, but the approach in Herman ter Horst's paper
> might take care of making that finite...)


Received on Thursday, 7 May 2009 10:41:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC