Re: simplified datatyping proposal

>On 2002-02-20 11:13, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
>wrote:
>
>>  Oh dear, it's looking as if I seriously dropped the ball on this...
>>
>>  With my CC/PP hat on I don't see the following "long-range" usage is
>>  supported:
>>
>>    _:SomeClientComponent client-property:dpi "100" .
>>
>>     :
>>
>>    client-property:dpi rdfs:range datatype:number .
>>
>>  i.e. does not define support for idiom B in the datatyping desiderata
>>  document:
>>
>>    http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0133/00-gk.htm
>>
>>  What also now seriously bothers me is that I can't see how the full
>>  proposal [1] supports this either.  I had earlier convinced myself that
>>  this was all OK, but now I can't see it.   Aaargh!
>
>It was specifically to provide this support that I suggested
>the union interpretation of rdfs:drange, so that it would
>provide a consistent interpretation for both the S-B idiom
>and the bNode idioms.

I don't think that the union idea works mathematically, is the 
problem. But I think we can get the same utility (and the same 
behavior on the examples) without using the union construction as 
such, though based I think on the same intuition.  And Im beginning 
to see that it is very useful to have an explicit name for the 
lexical class, to be sure.

Let me get back to y'all on this later in the day.

>Folks can still use the S-B idiom *without* any defined
>range constraints to interpret all such inlined literals as just
>literals. If you have long range datatyping, you are doing
>datatyping. Tough.

Well, OK, as long as you are prepared to accept that this is a 
non-monotonic construction. That is going to stick in many craws, 
however.

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 Wednesday, 20 February 2002 14:47:00 UTC