From: Pat Hayes (phayes@ai.uwf.edu)
Date: 10/10/01
>From: Pat Hayes <phayes@ai.uwf.edu> >Subject: model theory and literals >Date: Wed, 10 Oct 2001 12:36:24 -0500 > >> 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. > >Hmm. Interesting, sneaky, and underhanded! I like it. > >Well, actually, I don't think that it works. > >> 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. > >See below. > >> 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? > >The problem is that I want (for what I consider to be good reasons, see my >posting to www-rdf-comments OK, have done now. I emphatically don't agree with your point 2. There are two different issues here: syntactic datatyping, and assertion of membership in a class. The first can reasonably entail the second, but it shouldn't be *identified* with it. To do that is essentially to abandon the utility of literals in the first place, in my view, since it means that the task of determining the datatype of a literal is the general inference problem. There is no way to distinguish semantically between the case where an RDFS graph contains an explicit rdfs:range triple, and the case where the range is inferred by an arbitrarily long inference chain from other information in the graph. Note that in your example, the fact that "07" is a literal is irrelevant to the reasoning; you could replace the literals by a URI and reach the same conclusions. Mary age "07" . age rdfs:range ????:integer . There are other problems, in any case. For example, suppose that (as is perfectly legal in rdfs) that several rdfs:range assertions are made about age; what is the datatype of the literal in this case? (PS Ive posted the above as a comment on rdf-comments, just to get the ball rolling.) However this disagreement is an aside to the current discussion >) to be able to have that > > John age 05 . > >has several models, some which have (this) 05 be an integer and some which >have it be a string. That would be fine with me also, and I think that would be allowed in this scheme, just by changing the 'identity' of the node that is labelled with '05' (same Ntriples document, just generate a new graph from it, eg by unfaithfully copying the old one.) . What you have at the moment, as far as I can see, is that it is a set of strings and integers (and God knows what else, depending on the ingenuity of future datatype-schema designers) all at the same time. 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
This archive was generated by hypermail 2.1.4 : 04/02/02 EST