Re: Implementation report RDF Semantics

On 18-12-13 16:17, Sandro Hawke wrote:
> On 12/18/2013 08:40 AM, Guus Schreiber wrote:
>>
>>
>> On 18-12-13 13:12, Sandro Hawke wrote:
>>> Ivan Herman <ivan@w3.org> wrote:
>>>> Thanks Peter
>>>>
>>>> What effect does this have on the PR transition? Strictly speaking, we
>>>> do not have two independent implementations for the complete test
>>>> suite, ie, we have not fulfilled our exit criteria. Can there be a
>>>> clear explanation that can be used to convince the Director that we can
>>>> move ahead nevertheless? (I am looking for an elevator pitch equivalent
>>>> of what you write below; something like "these tests are side-effect on
>>>> the approach used for otherwise correct inference engines"...) One
>>>> could actually argue whether these tests are correct in the first place
>>>> if they are really dependent on the engines.
>>>>
>>>
>>> One procedural technique would be to rescind those tests as not
>>> helpful to interoperability.
>>
>> OK, so lets look at the two tests:
>>
>> 1. datatypes-intensional-xsd-integer-string-incompatible [1]
>>
>> xsd:integer rdfs:subClassOf xsd:string .
>>   false
>>
>> As I said earlier: this requires a form of disjointness reasoning
>> (primitive datatypes are disjoint). Our ClioPatria reasoner handles it
>> correctly, because we built  a kind of first-principles reasoner.
>> However, such an approach is  typically not taken by tool builders,
>> because it is not very efficient. The fact that the test is false will
>> typically be built implicitly into the machinery, so the system can't
>> actually say explictly it is wrong.
>>
>> I suggest that failing this test is therefore in practice not a threat
>> to implementation interoperability.
>>
>>
>> 2. xmlsch-02-whitespace-facet-3 [2]
>>
>> ex:a ex:prop "3"^^xsd:int .
>>   entails
>> ex:a ex:prop [ a rdfs:Literal ] .
>>
>> A bit of the same story. Yes, it is true. When reasoning from first
>> principles you would derive this fact. But why would an implementation
>> care?
>>
>> What you do care about as implementer are the other datatype tests, e.g.:
>> * when there is a mismatch/equality/.. between two literals
>> * when there is a mismatch between a literal and its datatype.
>> Those are interoperability issues. And we have plenty of tests for
>> these. But these issues are not at stake in the two tests above.
>>
>> I therefore PROPOSE that these two tests be rescinded as they are not
>> helpful to interoperability.
>>
>
> That all makes sense.   Are there other tests that should be rescinded
> using this reasoning...?

Possibly, but I don't have time to check. I know that many other 
datatype tests are really useful ones, from an interoperability point of 
view.

Guus

>
>       -- Sandro
>
>> Guus
>>
>> [1]
>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/reports/index.html#test_datatypes-intensional-xsd-integer-string-incompatible
>>
>> [2]
>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/reports/index.html#test_xmlsch-02-whitespace-facet-3
>>
>>>
>>>      - Sandro
>>>
>>>> Thanks
>>>>
>>>> Ivan
>>>>
>>>>
>>>>
>>>> On 17 Dec 2013, at 21:55 , Peter F. Patel-Schneider
>>>> <pfpschneider@gmail.com> wrote:
>>>>
>>>>> Here is my analysis of the two "failures" from Corese.
>>>>>
>>>>> datatypes-intensional-xsd-integer-string-incompatible
>>>>>     The test says that it is inconsistent to state that xsd:integer is
>>>> a
>>>>>     subclass of xsd:string.
>>>>>
>>>>> As most implementations directly implement datatype reasoning, they
>>>> don't
>>>>> depend on this fact about integers and strings.  They can correctly
>>>> reason
>>>>> about data values without noticing this invariant fact about the
>>>> datatype
>>>>> classes themselves.
>>>>>
>>>>> OWL implementations have to reason from facts like these, for example
>>>> to
>>>>> correctly infer that the intersection of string and integer is empty,
>>>> and so
>>>>> any property with both string and integer as a range can never have
>>>> any
>>>>> fillers.
>>>>>
>>>>>
>>>>> xmlsch-02-whitespace-facet-3
>>>>>     Test that an explicit literal implies a blank filler that is a
>>>> Literal
>>>>>
>>>>> Most forward-chaining implementations of RDF reasoning do not
>>>> directly
>>>>> perform complete entailment.  This kind of inference and perhaps one
>>>> other
>>>>> is then handled by a separate portion of the system, which appears to
>>>> not be
>>>>> part of the Corese that was used in the testing.
>>>>>
>>>>>
>>>>> So, Corese appears to have a good implementation of the core of
>>>> forward-chaining RDF entailment, but does not directly implement two
>>>> special cases (one related to datatype intensions and one related to
>>>> datatype extensions and blank nodes).
>>>>>
>>>>>
>>>>> peter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/17/2013 10:00 AM, Ivan Herman wrote:
>>>>>> Looks much better! Thanks
>>>>>>
>>>>>> Guys, we have two implementations of semantics. One is 100% (hurray
>>>> Jan!), one is almost 100%. Peter, it would probably be good to have a
>>>> good idea tomorrow why Corese fails on two tests and whether those are
>>>> essential in terms of testing. Put it another way, can we try to go to
>>>> PR based on these test results?
>>>>>>
>>>>>> (We are still missing Michael Schreiber's report...)
>>>>>>
>>>>>> Ivan
>>>>>>
>>>>>
>>>>
>>>>
>>>> ----
>>>> Ivan Herman, W3C
>>>> Digital Publishing Activity Lead
>>>> Home: http://www.w3.org/People/Ivan/
>>>> mobile: +31-641044153
>>>> GPG: 0x343F1A3D
>>>> FOAF: http://www.ivan-herman.net/foaf
>>>
>>>
>>>
>>
>

Received on Wednesday, 18 December 2013 15:30:49 UTC