W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

Re: Denotation of datatype values

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Thu, 18 Apr 2002 19:03:27 -0500
Message-Id: <p05101536b8e50c053ecc@[65.217.30.94]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-04-18 0:40, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>
>>>      Jenny age "10" .
>>>      age rdfd:range xsd:integer .
>>
>>  ... Jenny's actual age probably is ten, but Jenny's
>>  <ex:age> is *definitely* the string "10" according to this RDF. That
>>  is fixed and unambiguous no matter what the datatyping information
>>  is, and we should be clear about that.
>
>No! If Jenny's age (not ex:age) were the string "10" then there
>is no need to make the rdfd:range/datatype assertion at all!

YES. That is what the proposal says, unambiguously. The point has 
been flogged to death and I don't think there is any point in going 
back over it now. Literal meanings are FIXED, and the meaning of the 
inline triple is then determined by the ordinary RDF MT to be that 
the extension of <ex:age> contains <Jenny, "10">, not <Jenny, 10>. No 
ambiguity; fixed, firm, a done deal.  Datatyping in this case is 
wanted, by some users, in order to provide a lexical form constraint 
on the literal. (I think this is kind of dumb as well, but that's 
what they want.)

>There is no need to constrain the literal to the lexical space
>of xsd:integer if it is only going to be interpreted as a literal
>string!
>
>The *only* reason for even mentioning xsd:integer is to achieve,
>at *some* level of interpretation, the value *ten*.

Well, not everyone agrees with you on that.

>
>As far as I am concerned, the above two statements say that
>Jenny's age (not ex:age) is ten, and any other intepretation
>is just plain crazy

Well then you really shouldnt have written it in that form, because 
that ISNT what it says in RDF. Which illustrates the importance of 
being clear in the spec. If a user wants to say that Jenny age is 
ten, they they should use a different idiom. We have several they can 
use: they could use a datatype property, or use dlex with this range 
datatyping, either will work. BUt what IS important is that we tell 
them quite clearly that the inline idiom does NOT say that. If we 
tell them that the MT says one thing, but don't worry about that 
because we all know that *really* it doesnt mean that, you know, ha 
ha, that's just for those semantic geeks, then we are seriously 
misleading them. Because for any conforming inference engine (or 
indeed for any conforming engine of any kind), that IS what it means.

>, and if the MT does not capture in some
>way that the value ten is communicated by the combination
>of the above two statements, then it is broken, or incomplete
>and fails to meet the needs of RDF Datatyping and the needs
>of reliable, meaningful interchange of datatyped knowledge
>on the SW.

On the contrary. It says what the meaning is very precisely, and the 
idioms offer users the possibility of being achingly precise in 
saying what they mean.

>And since someone is surely going to misunderstand (as always)
>what I said above, I did *not* say that the literal "10" denotes
>the value ten or that the explicit value of ex:age is ten.

Saying that the literal "10" denotes the string "10" IS saying that 
Jenny's <ex:age> is the string. That is what the MT tells you. There 
isn't any way to make it say what the MT says it doesn't say: 
defining what it says is what the MT is FOR.

>
>If that doesn't work in the MT in any way, then toss the inline
>idiom as a datatyping idiom and be done with it.

It works, but it doesnt work in the way that you want it to. But what 
if someone WANTS a property value to be a string? You saying that 
should be *illegal* in RDF???

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, 18 April 2002 20:03:37 EDT

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