- From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
- Date: Wed, 3 Sep 2008 14:22:30 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: Sandro Hawke <sandro@w3.org>, Michael Schneider <schneid@fzi.de>, W3C OWL Working Group <public-owl-wg@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. Ian > > 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