From: Pat Hayes ([email protected])
Date: 11/29/01
>Here is a slight revision of my datatyping message of last week. I've
>cleaned up a few things, and added XML Schema methods as another
>alternative.
>
>By the way, what I would hope comes out of RDF Core is at least something
>like:
>
>1/ Use a locally specified lexical-to-value map, employing XML Schema
> mechanisms for compatibility reasons.
>
>2/ Text nodes (i.e., those that don't have an XML Schema-specified
> lexical-to-value map) are underspecified and don't have a fixed
> lexical-to-value map, leaving the door open for better schemes.
>
>peter
>
>
>Pat's proposal for datatypes (http://lists.w3.org/Archives/Public/
>w3c-rdfcore-wg/2001Oct/0453.html) has the following peculiarity.
>Suppose you have two datatypes, say integer and fraction, where integer is
>interpreted in the usual way but fraction is interpreted as 1/1+n. Then it
>is possible to interpret the following:
>
><age> <rdfs:type> <integer> .
><John> <age> "0" .
As noted in an earlier reply, this isn't my proposal. But leave that
aside for now....
>as having John's age be 1, by making the datatype of the node for the "0"
>be fraction.
>
>
>The problem is that the datatype of the node for "0" can be any datatype
>that maps "0" into an integer, and not the intended datatype, integer.
Maybe I am missing something, but I fail to see how this arises. The
proposal assumes, perhaps naively, that any processing engine is able
to recognize a URI denoting a datatype and is able to apply the
appropriate datatype mapping. Thus, if your triple refers to
<integer>, and that is indeed a recognized datatype, then that is the
datatype mapping that will be applied; the MT requires that the
interpretation of such a URI is indeed the appropriate datatype
mapping (condition 1). The fact that some other datatype might map
the literal to some other value is irrelevant.
This relies on the uniqueness of URIs like 'xsd:integer', ie it
appeals implicitly to a global convention that some URis have a fixed
meaning. This is rather outside the spirit of traditional model
theory, I will admit, but it does seem realistic for the RDF(S) and
DAML contexts.
Seems to me that there is no problem here to fix. Can you articulate
the problem more carefully?
......<snip>
>
>This more-or-less requires that the type hierarchy for datatypes is not
>determined by their extension,
Indeed, it need not be in RDFS. This seems like one of the few good
arguments for an intensional view of classes, in fact.
>so that integer-union-string does not
>subsume string.
Well, indeed it does not even in extension, as I mentioned in an
earlier email. The string '79' for example is not in the value space
of integer-union-string.
>(Otherwise, any use of a numeral on something typed as a
>string would be incoherent.)
>
>
>I suggest a combination of 0 and 2. That is, allow local specification of
>the lexical-to-value mapping using XML Schema constructs. For untyped text
>nodes use range information to specify which lexical-to-value mapping(s)
>must be used. As far as DAML+OIL is concerned, all datatypes would be
>incomparable.
Right, since the relevant classes (of literal values) cannot be
spoken of in DAML+OIL. But that seems like a hollow victory to me. I
am quite sure that strings and integers are classes, and no amount of
speak-no-evil is going to convince me otherwise.
Pat
--
---------------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola, FL 32501 (850)202 4440 fax
[email protected]
http://www.coginst.uwf.edu/~phayes
This archive was generated by hypermail 2.1.4 : 04/02/02 EST