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?

The label in the triple itself is a string, of course, just like all 
the other labels. Urirefs are strings, too.  So '10' is a string 
(which is also a numeral).  On the other hand, 10 is a number, as in 
'10=6+4'. The question is whether the literal label *denotes* a 
string or not. I want to be able to write a numeral and have it 
denote a number. If we interpret the double quotes as genuine 
quotation then that is impossible: all such quotations denote strings.

>If so,
>what is it? A URI? A local ID? Grounded in what base (a'la
>xml:base)?

I guess its just a literal. (But maybe, for you, "literal" *means* 
"string" ? There seems to be one subcommunity which takes that for 
granted. If so, however, there seems to be little point in this 
entire discussion, since obviously a string doesn't have properties 
like being base-64. Its just a bare sequence of characters. )

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

It doesn't, probably. Look, I'm not expecting miracles to occur. All 
that the MT extension can do is to make sure that datatyping 
information is tallied up with literal labels in a sensible way. If 
someone uses a literal that isn't the right type, then something 
ought to barf (that something would probably be outside RDF, and 
would know a lot about the intimate details of the datatyping 
scheme.) So in this case, RDF would tell the xsd: expert that '0x12' 
was supposed to be an integer, and that expert would tell it to go to 
hell.

>ASSERTION:
>    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
>verify...

Superordinate *datatypes*, not types in general. But yes, it does 
seem to require that. But is that so hard to verify? I'm assuming 
that we will be using genuine, published datatype schemes with URIs, 
not just random stuff put together in a back room. But even there, as 
long as mydatatype:frobjet is not asserted to also be an xsd:number, 
or some such, then there are no superordinate datatypes to get in the 
way.

Maybe we should ask our Chair what the intended scope of this 
discussion is supposed to be. By 'datatype' should we understand only 
XML datatypes, or *any* datatyping scheme that anyone could possibly 
dream up, or something in between? Are there any general assumptions 
that we can make about all 'reasonable' datatyping schemes?

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:13:38 UTC