Re: heading toward datatyping telecon

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.

Brian

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