Re: Implementation report RDF Semantics (ACTION-335) [RESOLVED]

Implementation report [1] and manifest updated to remove the two tests.

This resolves ACTION-335.

Gregg Kellogg
gregg@greggkellogg.net

[1] https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/reports/index.html

On Dec 18, 2013, at 7:30 AM, Guus Schreiber <guus.schreiber@vu.nl> wrote:

> 
> 
> 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 16:42:16 UTC