- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Wed, 7 Nov 2001 15:13:36 -0600
- To: Patrick.Stickler@nokia.com
- Cc: Brian McBride <bwm@hplb.hpl.hp.com>, w3c-rdfcore-wg@w3.org
> > 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