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

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