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.

Well, I took a liberty here, to make my point. This isn't legal RDF.

>Surely
>we are not saying that all occurrences of the literal
>"21" are of type xxd:decimalNumber, are we?

No; we are saying that THAT particular occurrence is. That is why 
datatype reasoning has to be defined with respect to nodes in the 
graph, rather than literal labels.

>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

I concede it is a little shifty because it relies on an intensional 
reading of the class. Think of the type information as saying 'this 
value is being treated, here (ie on this node), as being in a class 
which is associated with a particular datatype mapping, viz. 
xxd:decimalNumber.'

>(an easy thing to do, I'll admit ;-)
>
>Subjects are resources which have unique global identity
>represented by a URI.

Nonsense. First, there is no 'unique global identity'; the same URI 
can be used to identify many different entities at different times, 
and the same thing, sorry, resource, can have many URIs. Second, a 
literal can denote the same thing as a URI can (you had better admit 
this is true if you want URVs to be URIs), so even if the value can 
be referred to by a URI, it can also be referred to by a literal. I 
see no rational reason why one kind of name should only be used in 
one kind of place.

>Literals are not URIs, so how can
>they serve as subjects.

Literals denote values in the same away that URIs do, so why can they 
not serve as subjects? (?? You seem to be assuming that the only way 
to refer to something is to use a URI, maybe? But in that case, why 
do you not object to using literals as objects?)(Added later: Ah, you 
do. OK, I give you consistency :-)

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

Why is that confusing? The RDF syntax is defined over nodes. Every 
subject or object in any piece of RDF is attached to a unique node 
with a unique identity. That is a basic fact of RDF syntax, and its 
rather a nice one, so why waste it?

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

I don't want to even use the anonymous node at all. I want the 
literal to BE a string and to DENOTE its literal value (eg in this 
case, a number). Just like urirefs ARE strings and DENOTE resources.

>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

Well, we need to be able to reliably infer it, I would say.

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

No, that does not follow.

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 Wednesday, 7 November 2001 16:36:22 UTC