- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Wed, 10 Oct 2001 12:36:24 -0500
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- Cc: w3c-rdfcore-wg@w3.org, joint-committee@daml.org
Peter, after my mini-epiphany during the telecon yesterday, I had an even better one :-). I think that there is a very tiny, if unconventional, change to the RDF MT which will allow it to accommodate smoothly to your (or anyone else's) proposed treatment of literals: simply say (with some explanatory prose :-) that the XL mapping is a fixed mapping from literal TOKENS to literal values. That is, it allows one occurrence of <whatever>05</whatever> to denote an integer and another one to denote a string, just as long as they each denote the same thing in every interpretation. This allows both the case where every literal is simply a string which denotes itself, and it also allows the extreme other case where an elaborate external datatyping process assigns special values in all sorts of ways. However, it does insist that each literal label token has a fixed interpretation; it doesn't tolerate ambiguity of any *particular* literal label. I don't want to allow that kind of ambiguity. This will leave entirely mysterious how anyone or anything could determine what the actual denotation of any particular literal token actually is, of course. That is assumed to be done somehow, but is outside the scope of the MT itself. With this change in wording, the actual equations can remain as they are. Would that be sufficient flexibility for you, along with allowing IR to consist of both resources and literal values, so that rdfs:Literal doesn't force literal values to be resources? Pat PS I'm cross-posting this to both groups in case anyone can see a fatal objection. -- --------------------------------------------------------------------- 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, 10 October 2001 13:36:24 UTC