Re: Denotation of datatype values

On 2002-04-16 14:52, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
wrote:

> At 09:27 AM 4/16/02 +0300, Patrick Stickler wrote:
>>> I think that this way of phrasing it might be potentially misleading,
>>> since it suggests that the pairings are actually in the MT.
>> 
>> Perhaps they should be.
> 
> [GK wanders over to the stake in the ground, and gives it a hard kick, to
> make sure it's still firmly planted...]

Was it? ;-)

Was the kick to test if was firmly planted, or to ensure
that it remains firmly planted?

>> But we have been asked, to a certain extent, to provide an answer
>> that extends to the point of obtaining a datatype value unambiguously
>> and reliably. The present MT does not bring users to that point.
>> A datatyped literal pairing does -- insofar as it identifies a single
>> value which is obtainable by an application which groks the datatype
>> in question.
> 
> Having an rdfd:range [[or substitute current vocab]] associated with a
> property tells you nothing about the denotation of an object of that
> property.  I.e. it does nothing to help "obtaining a datatype value
> unambiguously and reliably".  (I found that trying to make it do so leads
> to contradictions.)
> 
> All it does is limit the allowable literals at the property's sharp end.

I either don't fully follow you, or disagree (or both ;-)

If RDF Datatyping cannot provide a consistent and unambiguous
interpretation resulting in a specific datatype value, then
we're just wasting our time.

If a given approach to reaching that goal results in contradictions,
then there is something wrong with the approach, not the goal, and
I believe that the approach defined by the present WD achieves that
goal without contradiction.

Can you show that it does not? (if so, then that would be very useful)

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Tuesday, 16 April 2002 10:01:41 UTC