W3C home > Mailing lists > Public > public-owl-wg@w3.org > September 2008

Re: ISSUE-130 / ACTION-194 Come up with a proposal for conformance

From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
Date: Wed, 3 Sep 2008 14:22:30 +0100
Message-Id: <F5B57C56-419F-42CF-A87B-0359216AC160@comlab.ox.ac.uk>
Cc: Sandro Hawke <sandro@w3.org>, Michael Schneider <schneid@fzi.de>, W3C OWL Working Group <public-owl-wg@w3.org>
To: Ivan Herman <ivan@w3.org>

On 3 Sep 2008, at 14:06, Ivan Herman wrote:

> Ian Horrocks wrote:
> [skip]
>> Implementations may choose to provide a "strict" (minimal?) mode in
>> which only the RL/RDF rules are used.
> At this moment I am in favour of that idea...
>>                                       I'm not sure if we could or  
>> should
>> insist on this. If we wanted to be more strict w.r.t. conformance, we
>> could strengthen the statement about warning users when they are  
>> asking
>> questions that the implementation may not be able to answer  
>> correctly,
>> i.e., state that they SHOULD or MUST issue such a warning.
> Just for my understanding: what would that require for an
> implementation? Would it mean that the RDF graph has to be converted
> into the functional syntax and check against RDF-RL?

That is how it is *defined*, but tools are free to *implement* it in  
any way they choose -- it might be possible, e.g., to implement  
checks that operate directly on the RDF graph.

> That might be
> rather complicated, so a SHOULD, let alone a MUST might be too much to
> ask IMHO

This had already been mentioned in the WG discussion, and was the  
reason for using MAY.


> Ivan
>>> Here's one way I could be told.  This would work whether or not I  
>>> can
>>> also control the additional reasoning methods/rulesets (the "+"  
>>> option).
>>>  case 1  FO(O1) <union> R entails FO(O2)
>>>          (which implies O1 entails O2)
>>>          it MAY return "True RL", meaning the entailment is shown  
>>> by the
>>>          base RL ruleset
>>>  case 2  If O1 entails O2 and
>>>          FO(O1) <union> R does not entail FO(O2)
>>>          it MAY return "True RL+", meaning that while the  
>>> entailment is
>>>          not shown by the base RL ruleset, it is still (somehow)  
>>> known
>>>          to hold
>> I don't think we need to distinguish shades of truth, because  
>> conforming
>> implementations can return True *only* when the entailment holds.
>>>  case 3  If FO(O1) <union> R does not entail FO(O2)
>>>          it MAY return "False RL", meaning the entailment is not
>>> supported by
>>>          the base RL ruleset (but may, in fact, still hold).
>>>  case 4  If FO(O1) <union> R <union> R2 does not entail FO(O2),  
>>> for some
>>>          R2, it MAY return "False RL+", meaning the entailment is  
>>> not
>>>          supported by the base RL ruleset, even with some extension.
>>>          (The entailment may, in fact, still hold.)
>>>  case 5  If O1 does not entail O2
>>>          it MAY return "False", meaning the entailment is known  
>>> not to
>>>          hold.
>>>        Note that whenever "True RL+" is a valid response, "False  
>>> RL" is
>>>        also a valid response.  It is less helpful, though, and "True
>>>        RL+" SHOULD be returned in these cases, if the entailment is
>>>        known to hold.
>>> (I'm trying to think of better terms for "False RL" and "False RL+".
>>> More accurate and less misleading than false would be  
>>> "Unprovable" or
>>> "Unsupported", I think.   I guess, myself, I'd go with case 3 and 4
>>> being "Unprovable RL" and "Unprovable RL+".)
>>> I think I would also allow additional characters after the "+" for
>>> implementation-specific purposes, so they can indicate which  
>>> additional
>>> R2 ruleset was used, like "True RL+RDFS".
>> This all sounds terribly complicated. If you really wanted to be
>> "perfect", then you could have "Don't Know" as a possible answer, and
>> insist that False is returned only when the entailment really doesn't
>> hold. In view of what I explained above, however, I'm not sure  
>> that any
>> of this is necessary -- users are, after all, free to treat False as
>> Don't Know when the completeness guarantee can't be made.
>> Ian
>>>        -- 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
Received on Wednesday, 3 September 2008 13:23:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:51 UTC