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

Re: Denotation of datatype values

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 18 Apr 2002 16:45:22 +0300
To: Pat Hayes <phayes@ai.uwf.edu>, Graham Klyne <Graham.Klyne@mimesweeper.com>
CC: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B8E4A8A2.135CE%patrick.stickler@nokia.com>
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!

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

The *only* reason for even mentioning xsd:integer is to achieve,
at *some* level of interpretation, the value *ten*.

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, 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.

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.

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.


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Thursday, 18 April 2002 14:25:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:12 UTC