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

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 might be
rather complicated, so a SHOULD, let alone a MUST might be too much to
ask IMHO

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