RE: datatypes and MT

> Pat shoeSize "10"
> then I am saying that my shoe size is a character string, right?
>  From here on I will omit the double quotes to avoid confusion.

Do you mean then

  Pat shoeSize 10


Such that 10 is something other than a string/literal? If so, 
what is it? A URI? A local ID? Grounded in what base (a'la
> Well, I do. The motivating example for me was the use of range 
> information to fix a datatype, as in
> aaa shoeSize 10 .
> shoeSize rdfs:Range xsd:integer .
> which seems to me to be eminently simple. Obviously, the literal 
> should be interpreted using xsd:integer. No need to apply rules or 
> rewrite using bnodes; you just use the literal  in the triple.

Ahhh, but what if we have

  aaa shoeSize 0x12 .
  shoeSize rdfs:range xsd:integer .

Hmmm.... xsd:integer requires a decimal notation. It may
also be that the person making the statement about shoe
size is not the one asserting the range constraint. That
might be a localized interpretation.

So just how does a system *know* how to interpret
'0x12' as an xsd:integer?

   Typed data literals must have local type defined that
   is inseparable from the lexical form embodied in the
   literal value. Range asserted interpretation does not
   suffice for interpretation of the lexical form.

The alternate is to impose the requirement that all lexical
forms of all data types be valid lexical forms for all
superordinate types of that data type. Ouch. Tough to

Granted, XML Schema seems to comply with such a requirement
(I haven't checked rigorously though). But whether we
could actualy empose such a requirement (either reasonably
or practically) is questionable.

> >         <...#me> <...#shoeSize> _:x.
> >         _:x <...rdf-syntax-ns#type> <...#integer>.
> >         _:x <...#decimalRep> "10".

This representation presumes that the lexical form is
separate from the data type, which is not the case
(neither for RDF or XML, nor for a given programming
language). The typing system of RDF does not apply to
canonical internal representations of values in
value spaces, but of lexical forms corresponding to
values in value spaces. As such, the #decimalRep
could be seen as superfluous, as one would expect
that #integer would define the lexical space and the
literal value would conform to that space.

Those languages which allow for multiple notations of the
same data type in lexical forms utilized mechanisms in
the lexical form itself to differentiate those variant
notations. The above treatment seems to me to presume
that no lexical space is defined for the data type at 
all, therefore it must be specified separately, and that
I think is incorrect.



Received on Wednesday, 7 November 2001 02:38:26 UTC