Re: Possible tweak to datatype semantics

I actually take this back as after thinking about it, I think Pat has it 
right and I don't see where it would cause big troubles.


AZ



Le 13/09/2013 14:43, Antoine Zimmermann a écrit :
> I'm with Peter on this.
> I don't see a real benefit with this proposal.
>
>
> AZ
>
>
> Le 13/09/2013 08:03, Peter F. Patel-Schneider a écrit :
>> What good would this change from the 2004 situation do?
>>
>> Even if inertia was strongly indicating that this change should not be
>> made, I would vote against it.
>>
>> If you make this change, you have the situation that if x:dt is not a
>> recognized datatype, the empty graph does not RDFS entail
>>    x:dt rdf:type rdfs:Class .
>> but
>>    :a :p "foo"^^x:dt .
>> does.
>>
>> I believe that your argument falls apart when you look closer at it.
>> You are saying, in effect, that if x:dt is a recognized datatype then
>> any well-typed literal with it as the datatype belongs to it, and the
>> appearance of an ill-typed literal causes a contradiction, and thus
>> entails any graph, including the graph that states that the ill-typed
>> literal belongs to the x:dt, so why not make this hold even if x:dt is
>> not a recognized datatype. However, when x:dt is *not* a recognized
>> datatype this reasoning doesn't hold water, so there is no reason to
>> modify the semantics to make it valid.
>>
>> You might just as well argue that if x:dt is a recognized datatype then
>> it is a subclass of rdfs:Literal therefore anything should be a subclass
>> of rdfs:Literal.
>>
>> peter
>>
>> On 09/12/2013 10:25 PM, Pat Hayes wrote:
>>> I know its very late to even be talking about this, but Antoine's test
>>> cases made me notice an oddity which the current semantics for
>>> datatyped literals produces, and which would be easy to fix. So I'm
>>> outlining it here in case the WG feels it would be worth doing.
>>>
>>> We distinguish 'recognized' datatype IRIs from the others, and right
>>> now, if you see a literal with an unrecognized datatype IRI in it, say
>>> x:dt, then you know nothing at all about what that literal means.
>>> Absolutely nothing. So this inference:
>>>
>>> :a :p "foo"^^x:dt .
>>>
>>> |=
>>>
>>> :a :p _:x .
>>> _:x rdf:type x:dt .
>>>
>>> is not a valid entailment. But if x:dt were recognized, it would be:
>>> and moreover, you know this without knowing anything about x:dt. This
>>> entailment is valid for ANY recognized datatype, and ANY string "foo".
>>> So why isn't it valid for any datatype, recognized or not?  This is
>>> clearly slightly irrational. A rational way to reason would be: I know
>>> now, even without recognizing that datatype, that this inference will
>>> be valid when I do recognize it; and I won't need to know anything
>>> more about the datatype in order to make that inference; so why not
>>> just pretend that I recognize the datatype and make the inference now,
>>> to save time?
>>>
>>> We could fix this with the following changes.
>>>
>>> In section 7.1, add the condition (to the table, it would be the third
>>> line out of three):
>>>
>>> For any literal "sss"^^aaa, if IL("sss"^^aaa) is defined then
>>> <IL("sss"^^aaa), I(aaa)> is in IEXT(I(rdf:type))
>>>
>>> and add the explanatory text immediately below:
>>> "The third condition applies to all datatyped literals, whether the
>>> datatype IRI is recognized or not."
>>>
>>> And in section 7.2.1, at the beginning of the text, add the entailment
>>> pattern (moved from section 8.1.1, and with "for ddd in D" removed):
>>>
>>> rdfD1  <if S contains>  xxx aaa "sss"^^ddd  <then S D-entails> xxx aaa
>>> _:nnn .      _:nnn rdf:type ddd .
>>>
>>> together with its explanatory text from 8.1.1.
>>>
>>>
>>> The advantage to RDF engines is that this is one less case where they
>>> have to check whether or not a datatype is "recognized", and it means
>>> that the interpolation lemma is more useful when there are datatyped
>>> literals around.
>>>
>>> Any comments? Is this worth doing? Is this legally possible to do at
>>> this LC stage? I would be willing to declare the current version an
>>> error if that is what it takes :-)
>>>
>>> Pat
>>>
>>> ------------------------------------------------------------
>>> IHMC                                     (850)434 8903 home
>>> 40 South Alcaniz St.            (850)202 4416   office
>>> Pensacola                            (850)202 4440   fax
>>> FL 32502                              (850)291 0667   mobile (preferred)
>>> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

-- 
Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Friday, 13 September 2013 15:32:47 UTC