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

Re: heading toward datatyping telecon

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Tue, 06 Nov 2001 11:58:29 +0000
Message-ID: <3BE7D065.9090507@hplb.hpl.hp.com>
To: Pat Hayes <phayes@ai.uwf.edu>
CC: w3c-rdfcore-wg@w3.org

Pat Hayes wrote:

>> 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,
> ?? Sorry, maybe I am not following your sharp and blunt ends. (I assume 
> the blunt end is the subject and the sharp end is the object in an RDF 
> triple, right?)
> If we were to write a class name at the blunt end we would be 
> attributing a property to the *class*, right? Do you mean something like
> xsd:integer rdf:type rdf:DataType .

Please forgive my being unclear.  Its a small point and probably not worth the 
effort, but let me try again:

There seem to be three fundamentally different approaches in play.  They all 
have in common that a literal value, e.g. an integer, is denoted by a node in 
the graph.  They differ on whether an arc from that node, labelled with 
rdf:type, takes a value which denotes a value space or a datatype (Pat's use of 
the term datatype i.e. as defined in XSD a tuple defining lexical space, value 
space and facets).

All I was originally trying to say is that programmers, and some of the time I 
am one, are used to the type of something denoting the value space alone.

Received on Tuesday, 6 November 2001 07:03:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:53 UTC