RE: heading toward datatyping telecon

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

Exactly.

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

Although I agree with the spirit of the above
statements, I am still a bit puzzled by the fact
that the literal is acting as the subject. Surely
we are not saying that all occurrences of the literal
"21" are of type xxd:decimalNumber, are we?

Rather, we are saying there is some value X that has
a lexical form "17" and is of the type xxd:decimalNumber.

I.e.

   #X rdf:value "17".
   #X rdf:type xxd:decimalNumber .

The fusion of literal as subject really confuses me
(an easy thing to do, I'll admit ;-)

Subjects are resources which have unique global identity
represented by a URI. Literals are not URIs, so how can
they serve as subjects. 

If you are using the form

  "17" rdf:type xxd:decimalNumber .

simply as a syntactic convenience, meaning that somewhere
underneath that literal is in fact a node with globally
(or at least system) unique identity, fine, but that is
rather confusing IMO.

After all, we are talking about a value here, not a given
lexical form, and the value has both a type and lexical
form, thus the anonymous node #X represents the value,
not the literal. Eh? And so long as we must represent that
value in terms of a lexical form, we need to have a consistent
and persistent construct to tie form and type together which
will endure across operations such as inferred binding to
properties of superordinate or equivalent types. Thus we
need to have that anonymous node (or some other encapsulation
such as a URV encoding).

Patrick

Received on Wednesday, 7 November 2001 03:00:07 UTC