W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

RE: datatypes and MT

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 13 Nov 2001 19:20:15 -0600
Message-Id: <p05101040b81773356128@[]>
To: Patrick.Stickler@nokia.com
Cc: w3c-rdfcore-wg@w3.org
>  > >>  then I am saying that my shoe size is a character string, right?
>>  >
>>  >That's my suggestion.
>>  But like I said in an earlier thread, that seems *obviously wrong*.
>>  And as you said, it *is* obviously wrong, but all these silly people
>>  insist on writing these obviously wrong things. Doesn't that suggest
>>  that they are not writing obviously wrong things, in fact, but rather
>  > interpreting those double quotes differently?
>We need to keep in focus the fact that "10" is a lexical representation
>of the value, not the value.

Well, that is one of the issues being discussed. In the S proposal, 
the value of  the literal "10" would be the string "10".

>Yes, folks are not saying that the shoe size is a string. They
>are expecting that lexical form to mapped to a value in a particular
>value space.

Right, which is what the P(++) datatyping proposals try to do.

>The same is true of the lexical representation of literals in a
>programming language.
>    protected Integer shoeSize = 10;
>is not saying the shoeSize is the character sequence '10' (even
>though there are no quotes), but the value ten.

Right, but that lack of quotes is significant. In LISP for example, 
supplying the character sequence '10' as an argument indicates the 
value ten, while supplying the character sequence ''10' indicates 
that the value is the character sequence '10'.

>The difference between e.g. Java and RDF is that Java actually
>interprets the lexical forms before it uses them, but RDF just
>holds on to them as-is.
>The mistake here is to somehow thing that RDF will interpret
>them in any way.

Right. But I believe that nobody is making that particular mistake. 
The discussion is about whether a literal label should be taken to 
*denote* the string or the value it has under a datatyping scheme.
>  > I just meant to avoid the implication that they were to be
>>  interpreted as strings, since that interpretation begs the question.
>>  If we can agree that XML syntax in general should not be interpreted
>>  using logical canons of notational rigor, then we can leave the quote
>>  marks there and not call them quotes.
>Exactly. No interpretation is going to happen in RDF.

We are at cross purposes. Interpretation, in the sense I was using 
it, is not something that HAPPENS.

>They *are* strings.
>Leave the quote marks to indicate they are strings.

They don't need quote marks to indicate that they are strings. The 
quote marks, if interpreted as genuine quotations, would indicate 
that those strings denoted other strings, eg the string of four 
characters on the next line:
is often understood as denoting the string of two characters on the next line:
which in turn is usually taken to denote the number ten.

It is this 'quotation' interpretation that is under discussion, and 
that is accepted by the S and DC conventions but not by the P(++) 
ones. The question doesn't arise in the X proposal, since literals in 
this sense are not used.

>>  Ah. So this would be OK, would it?
>>  aa eg:prop _:x .
>>  _:x xsd:integer "10"
>>  _:x xsd:integer "0010"
>>  That does make sense, I agree.
>But, just to clarify here, RDF is not determining that
>these two lexical forms map to the same value in the
>xsd:integer value space.

It certainly is making this claim!  The use of the common bNode _:x 
asserts that there is one thing that is related to "10" and to "0010" 
by the same xsd:integer property.

>Insofar as RDF is concerned,
>they are different values.

_:x is only one node, so it can have only one value.

>Note that there is a difference between a lexical space
>and a canonical lexical space. The latter does not permit
>such semantically vacuous variant forms. Any value has
>but one lexical form.
>If literals were canonical lexical forms, then comparison
>of literals of the same type would suffice to determine

Right, but nobody is talking about canonical forms.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 13 November 2001 20:20:12 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:42:38 EDT