- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Thu, 21 Feb 2002 11:30:07 +0000
- To: Pat Hayes <phayes@ai.uwf.edu>
- Cc: w3c-rdfcore-wg@w3.org
Pat, I'm rolling up responses to several or your messages into one here, in the hope and belief that various misunderstandings are becoming unmisunderstood... At 09:23 PM 2/20/02 -0600, Pat Hayes wrote: >AAARGH!!! I wish you would say what it is you DO want. People keep >contradicting themselves, no wonder we cant get to a resolution of this >damnable issue. > >I thought that the whole point of the B idiom was that it DID allow >datatyping to alter the denotation of the literal. If CC/PP doesn't need >that, we don't need to allow the inline idiom to be sensitive to datatypes. > >Please will you say EXACTLY what you want to be able to do. Then I promise >I will hit your target. But for Gods sake keep the target still for a while. Short-form response: Under Sergey's S proposal, the B idiom works with every literal denoting itself. ... Here is a slightly longer version: I have quite consistently not deeply cared what the literal *denotes* in the B idiom ... (though I acknowledge that what I have said may not always convey that.) Indeed, my goal in presenting the idioms was to try and separate how people use RDF literals from the model theoretic denotations. What I want to be able to do is define some schema that lets me say: person:Jenny ex:age "10" . but that does not let me say: person:Jenny ex:age "Humpty Dumpty" . in the presence of some well-understood datatyping scheme for representing the values that can be used as a measure of age. Note, I say "in the presence of" -- I don't require that the "10" denotes that measure, just that the literal values that can be used here are somehow constrained; i.e. under some schema, say: ex:age rdfs:drange datatype:DecimalNumber . the statement: person:Jenny ex:age "Humpty Dumpty" . would always be false (given some reasonable understanding of "datatype:DecimalNumber"), but: person:Jenny ex:age "10" . may or may not be true. I understand that the model theory must take some view about what the literals denote, but for the purposes of this particular issue, I don't care what that view is. For example, under Sergey's S proposal, the B idiom worked with every literal denoting itself. Under other schemes, it worked with the literal denoting some (datatype-defined) value. My point is to refute your statement above that "the whole point of the B idiom was that it DID allow datatyping to alter the denotation". ... And from another message: >>At 12:27 PM 2/20/02 -0600, Pat Hayes wrote: >>>Well, I half-agree, but we can't have all three things at once: >>> >>>1. You and Graham want range-sensitive inline literals. >>>2. Dan C. wants an inline literal used with no datatyping to >>>unambiguously denote a character string. >>>3. We all want the logic to be monotonic. >>> >>>Something has to give. >> >>Didn't the S proposal achieve all that? > >No proposal can possibly achieve all that. Regardless of semantic >ingenuity, those three are a logical contradiction by themselves. The >*spec* is a contradiction, so theres no point trying to meet it. Hmmm... either I'm completely missing something, or we're stumbling over what "range-sensitive inline literals" means. (I don't insist on range-sensitive denotation.) ... And another message: >>(b) CC/PP, myself >>(c) A defined way to constrain a property range to the lexical space of >>some datatype; >>e.g. for CC/PP: >> >> _:SomeClientComponent client-property:dpi "100" . >> : >> client-property:dpi rdfs:range datatype:number . > >OK, let me tackle this more cooly. I didn't read this kind of example as >saying that a property range is constrained to a lexical space. That >second triple says that the range of the property is the datatype, not the >lexical space of the datatype. It doesn't mention lexical spaces anywhere, >as far as I can see. I understood you to be saying that you wanted >in-line uses of literals (as in the first triple) to be >datatype-sensitive, ie to change their *meaning* according to the datatype >information applied to the range of the property, so that this example >would say that the value of client-property:dpi applied to the subject was >the number one hundred. So I invented a scheme to enable you to do that. I >believe this was also what Patrick wants, and what I know Peter >Patel-Schneider would like, and it may also be what Brian wants, although >Im not sure as I no longer know what people mean when they refer to the >S-B idiom. > >But it seems that is not what you , Graham, want at all. You want that >first triple to mean that the value of the property IS the string '100', >and definitely not a number, but *in addition* to know that this string is >in the lexical space of the datatype. (Right? Have I got that now?) If so, >then that is yet a third possibility, and I'll have to think about how to >do it. Much closer. I don't particularly care what the denotation is, which is why I've been happy to go along with otherwise completely different proposals. >First let me check one more thing. Is it absolutely required that this >information about lexical spaces must be conveyed by a triple using >rdfs:range? (If so, I have no idea how to do that, and would suggest that >anyone who managed to form that idea from reading any spec ever written >about RDF is living in a fantasy, and their problems should not concern >us.) Or can it be conveyed in some other way? For CC/PP, using rdfs:range would be nice, but I've come to live with the idea that it might need to be something different (i.e. revising the CC/PP schema is not, to my knowledge, going to impact running code: revising the actual CC/PP profile data certainly would). ... #g ------------------------------------------------------------ Graham Klyne MIMEsweeper Group Strategic Research <http://www.mimesweeper.com> <Graham.Klyne@MIMEsweeper.com>
Received on Thursday, 21 February 2002 06:48:00 UTC