RE: Cutting the Patrician datatype knot

>From: Patrick.Stickler@nokia.com
>Subject: RE: Cutting the Patrician datatype knot
>Date: Wed, 28 Nov 2001 18:18:21 +0200
>
>>  > -----Original Message-----
>>  > From: ext Peter F. Patel-Schneider
>>  > [mailto:pfps@research.bell-labs.com]
>>  > Sent: 24 November, 2001 09:16
>>  > To: Stickler Patrick (NRC/Tampere)
>>  > Subject: RE: Cutting the Patrician datatype knot
>>  >
>>  >
>>  > From: Patrick.Stickler@nokia.com
>>  > Subject: RE: Cutting the Patrician datatype knot
>>  > Date: Fri, 23 Nov 2001 20:57:49 +0200
>>  >
>>  > [...]
>>  > >
>>  > > If the data type does not define a lexical space, then
>>  > > no mechanism is going to work. Either there's a defined
>>  > > mapping from lexical form to value or there isn't. It
>>  > > is therefore enough to identify that pairing of lexical
>>  > > form (literal) to data type (URI) in order to denote the
>>  > > value.
>>  >
>>  > The problem is not that the datatypes don't meet your
>>  > conditions above, the
>>  > problem occurs when two datatypes share some data values, but
>>  > disagree on
>>  > how to do the lexical-to-value mapping.  If the typing comes
>>  > from RDF(S),
>>  > then it may be the case that a literal gets these two
>>  > datatypes.  Then the
>>  > value for that literal is ambiguous.
>>
>>  The value*S* are not ambigous. In the case where there are
>>  multiple pairs of lexical forms and data types, each pair
>>  denotes a value in the value space of the data type. If those
>>  values are not the "same" then we have a contradiction.
>>
>>  Contradictions are part of general life in the semantic web,
>>  no?
>
>The whole point, and the problem with Pat Hayes's solution, is that you
>don't get a contradition.

? Yes you do. At least, you do if the datatyping schemes are 
incompatible. Then with the extended datatyped MT, there is no typed 
interpretation which satisfies the graph (with both clashing rdf:type 
assertions in it), ie the graph is contradictory.

Now, it is true that in order to *detect* this contradiction, an 
inference engine would need to have access to the internals of the 
datatyping schemes, in order to detect that they were in fact 
incompatible. (How could it be otherwise?) That is why it would not 
be a simple RDFS contradiction, but only a contradiction relative to 
datatyped interpretations.

>A contradition might be much better than what
>you actually get, which is a model that has an unintended lexical-to-value
mapping.

No, you don't get that, unless there is such a mapping in the 
datatyping scheme. For example, if (integer intersection string) is a 
datatype, then indeed that will be the datatype mapping selected in 
the interpretation. But if there is no such datatype in the 
datatyping scheme named in the RDF triples (as a datatype class name) 
then there will be no 'unintended' mapping in the model.

>  However, if you switch Pat's model theory around to remove the
>ambiguities, then there are datatyping schemes, such as XML Schema, where
>most literals have no coherent value.
>
>
>For example, if you allow union XML Schema datatypes there is a model of
>
>	<rdfs:range foo xsd:[integer union string]>
>	<John foo 7>
>
>where the value of John's foo is the string "7", which is not the intended
>value.

How do you know that is not the intended value? What part of the RDF 
graph indicates that the intended datatype here is integer?? You 
cannot infer intended datatypes by telepathy.

>This is because you can datatype the literal as a string and use
>string's lexical-to-value map.

Right, and that interpretation is consistent with the content of the 
RDF as stated. The type given for the predicate is a union, not an 
intersection, so it is *correct* to use the string interpretation.

>If you instead require that the
>lexical-to-value map be consistent with all the types of the value, then
>you get too many contractions.  For example, the integer 7 belongs to the
>datatype integer, which is fine, but it also belongs to the datatype
>[string union integer].  Therefore you can't get from the literal 7 to the
>integer 7, because that would violate the lexical-to-value map for [string
>union integer].

You seem to have made a problem out of nothing. If someone uses a 
union type, they presumably mean to say what they have in fact said, 
which is that the type is that union, not some component of it.

>
>>  By basing the data typing solution on the *pairing* of lexical
>>  form to data type, where the data type defines both lexical
>>  and value space, then we are free to employ whatever idioms
>>  we choose to define such pairings and interpretation is reliable,
>>  even when we have contradictory assertions. E.g.
>>
>>     x eg:property [ rdf:value "10"; rdf:type xsd:gDay ] .
>>     eg:property rdfs:range xsd:gMonth .
>>
>>  resulting in the contradiction that "10" is a lexical form
>>  denoting a day value *and* a month value. In both cases,
>>  the pairing is crystal clear
>>
>>     ("10",xsd:gDay)
>>     ("10",xsd:gMonth)
>>
>>  Whether the values denoted by those pairings are the same, and
>>  whether there is a contradiction is a matter for the application.
>>
>>  RDF has done its part by making the pairings clear and available
>>  for such interpretation.
>
>I don't see how this does anything to help the situation, at least in the
>RDF model theory.  If you do the obvious translation of the above into the
>RDF model theory you get the same ambiguities as before.  If you make a
>small change, which you seem to be expecting, you get contradictions where
>you expect none.
>
>To show that you indeed have a solution you will have to present a full
>description of what exactly is the meaning here.  This doesn't have to be a
>model theory, but it does have to be much more than is presented above.
>For example, what is the theory of rdf:type on datatype classes?

OK, Pats answer is: it means exactly what it means on all other 
classes; but in a typed interpretation, that meaning is used in a 
particular way to select an appropriate lexical-to-value mapping for 
the literal so typed.

Pat


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 29 November 2001 16:33:17 UTC