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

Re: heading toward datatyping telecon

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 6 Nov 2001 18:50:45 -0600
Message-Id: <p05101029b80caaaf864f@[65.212.118.166]>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org
>Pat Hayes wrote:
>
>[...]
>
>>
>>Oh, I agree its not helpful to conflate them. But let me probe this 
>>other usage a little. Consider various kinds of numerals, eg 
>>decimal, hexadecimal, octal, binary. Obviously these all have the 
>>same value space, so it doesn't make sense to use something like 
>>'octal number' to refer to a value space. So I'm left wondering 
>>what this usage is supposed to mean.  For example, what is a 
>>decimal *integer* ?
>
>
>Yes, I agree.  That's why I don't expect to see arcs labelled 
>rdf:type with xsd:integer at the sharp end.  I expect rdf:type to 
>identify the class of the node at its blunt end, and I think of the 
>class of the object as identifying its value space, and is 
>independent of its lexical space.
>
>My mental model.  I can change it its wrong; but I don't think its uncommon.

Ah, now I see what you mean, Sorry I was obtuse.

Yes, I would agree with you if classes were understood extensionally. 
But this is where the subtlety of the MT comes into play, in its 
class/extension distinction. Two different classes might have the 
same extension (or, equivalently, two different things might have 
exactly the same rdf:type property values on the whole universe.). So 
it does make sense to have a class called, say, decimals, and a class 
called, say, octals, and for these two classes to have the same 
extension. Now, what doesn't make sense is to pick one thing in that 
extension - say, the number 17 - and ask: what class is it *really* 
in? Because in this case the only possible answer is, it is in all of 
them. They are all the same extension. So if you ask if 17 is an 
octal or a decimal integer, the answer is, both. However, when 
asserted to be an octal number, we can say, it has a sense which goes 
along with that property - that it is represented using an octal 
numeral. So if we are considering it is an octalnumber, and we know 
that the numeral "21" denotes it, then we know it is 17. Similarly, 
if we are considering it as a decimal number and we know that "17" 
denotes it, then we know it is 17. The way of interpreting the 
strings goes along with the class, not with the things in the 
extension of the class. If we know that we are supposed to treat the 
thing as being in a class which is a datatype class, then we know how 
to interpret any literals that might denote it. That information is 
associated with the class, not with the thing. Hence the Ntriples++ 
triple:

lit rdf:type <datatypeClass> .

says exactly what it ought to say; eg

"21" rdf:type xxd:octalNumber .

tells us that the literal denotes 17, which is exactly what

"17" rdf:type xxd:decimalNumber .

also tells us.

Classes and properties are first-class entities in RDF - one way in 
which it scores over traditional FOL, in fact - and so it makes 
perfect sense to assign a particular class as a range, say, and have 
it mean more than simply that everything that is a value of the 
property is in the class extension. (It does mean that, of course, 
but it can mean more than that.) So the assignment of rdf:type 
octalnumber to a literal, in particular, can be understood 
meaningfully as saying something about the *property* of 
octal-number-hood, rather than about the value of the literal being 
an octal number (which of course doesn't mean anything much); in 
fact, it can be understood as saying that this literal is to be 
understood as having its value determined by the 
literal-interpretation rules that go along with that property.

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 Tuesday, 6 November 2001 19:50:54 EST

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