- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Thu, 18 Apr 2002 19:03:27 -0500
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: w3c-rdfcore-wg@w3.org
>On 2002-04-18 0:40, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote: > >>> Jenny age "10" . >>> age rdfd:range xsd:integer . >> >> ... Jenny's actual age probably is ten, but Jenny's >> <ex:age> is *definitely* the string "10" according to this RDF. That >> is fixed and unambiguous no matter what the datatyping information >> is, and we should be clear about that. > >No! If Jenny's age (not ex:age) were the string "10" then there >is no need to make the rdfd:range/datatype assertion at all! YES. That is what the proposal says, unambiguously. The point has been flogged to death and I don't think there is any point in going back over it now. Literal meanings are FIXED, and the meaning of the inline triple is then determined by the ordinary RDF MT to be that the extension of <ex:age> contains <Jenny, "10">, not <Jenny, 10>. No ambiguity; fixed, firm, a done deal. Datatyping in this case is wanted, by some users, in order to provide a lexical form constraint on the literal. (I think this is kind of dumb as well, but that's what they want.) >There is no need to constrain the literal to the lexical space >of xsd:integer if it is only going to be interpreted as a literal >string! > >The *only* reason for even mentioning xsd:integer is to achieve, >at *some* level of interpretation, the value *ten*. Well, not everyone agrees with you on that. > >As far as I am concerned, the above two statements say that >Jenny's age (not ex:age) is ten, and any other intepretation >is just plain crazy Well then you really shouldnt have written it in that form, because that ISNT what it says in RDF. Which illustrates the importance of being clear in the spec. If a user wants to say that Jenny age is ten, they they should use a different idiom. We have several they can use: they could use a datatype property, or use dlex with this range datatyping, either will work. BUt what IS important is that we tell them quite clearly that the inline idiom does NOT say that. If we tell them that the MT says one thing, but don't worry about that because we all know that *really* it doesnt mean that, you know, ha ha, that's just for those semantic geeks, then we are seriously misleading them. Because for any conforming inference engine (or indeed for any conforming engine of any kind), that IS what it means. >, and if the MT does not capture in some >way that the value ten is communicated by the combination >of the above two statements, then it is broken, or incomplete >and fails to meet the needs of RDF Datatyping and the needs >of reliable, meaningful interchange of datatyped knowledge >on the SW. On the contrary. It says what the meaning is very precisely, and the idioms offer users the possibility of being achingly precise in saying what they mean. >And since someone is surely going to misunderstand (as always) >what I said above, I did *not* say that the literal "10" denotes >the value ten or that the explicit value of ex:age is ten. Saying that the literal "10" denotes the string "10" IS saying that Jenny's <ex:age> is the string. That is what the MT tells you. There isn't any way to make it say what the MT says it doesn't say: defining what it says is what the MT is FOR. > >If that doesn't work in the MT in any way, then toss the inline >idiom as a datatyping idiom and be done with it. It works, but it doesnt work in the way that you want it to. But what if someone WANTS a property value to be a string? You saying that should be *illegal* in RDF??? 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 Thursday, 18 April 2002 20:03:37 UTC