Re: simplified datatyping proposal

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