Re: Denotation of datatype values

>On 2002-04-18 1:02, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>
>
>>>  The MT, IMO, stops short of the line. It gets 95% there and fails
>>>  to actually say how to get to the finish. It fails to capture
>>>  the ultimate "why" of the idioms.
>>
>>  Patrick, you want to ALTER the MT, clearly.
>
>I actually don't think so. I just consider it acceptable
>to interpret the present MT as all three of the datatyping
>idioms identifying a datatype value, even if the inline
>idiom does not provide explicit denotation for that value
>in the graph.

Of course a literal and a datatype 'identify' a datatype value in 
some sense, just as <3, inc> identifies 4. But we don't even need any 
RDF to tell us that. The issue here is to explain what datatyped RDF 
means, and if someone were to interpret this explanation as saying 
that a 'datatyped literal' means a datatype value (and how else could 
they be expected to interpret it?), then that seriously misrepresents 
the MT. The current MT clearly does not say that, in fact it says 
something that is clearly inconsistent with that. Thats why Im making 
all the fuss here. That would be a very different MT, and would have 
lots of other implications about tidiness and literal subjects and so 
on, and wouldn't support inferences that Dan C wants supported, and 
wouldn't sanction uses that Graham tells us the DCore want to have 
sanctioned, and so on.

>What the users of RDF Datatyping need, IMO, is the ability
>to express and communicate datatype values. If they can't
>do that, then something is broken.

They CAN do that, eg by using a dataype property or dlex. But they 
can also do other things: they arent OBLIGED to do that. And they 
can't do that using the inline idiom. If all the idioms had the same 
meaning, we wouldnt need them all.

>
>I don't think the MT needs to be changed. I actually think
>we are in very violent agreement, and are just bandying over
>words and how best to explain what the MT says to folks who
>will not or cannot read the MT.
>
>It is your interpretation of the inline idiom as only constraining
>literals to the lexical space and not actually identifying a
>datatype value that I consider not "going all the way".

It is important that it does not go all the way, because some users 
do not want to go all that way. They are passionately agnostic about 
values, and care only about lexical forms. They are devoted to text 
and want to be systematically sloppy about values: they want to 
freely mix strings and numbers and call them all 'age'.

>
>>  The trouble with your
>>  position, however, is that the place you want to get to, that last
>>  5%, is a place we have already surveyed, and we found problems with
>>  it.
>
>We found problems with trying to have all three idioms denote
>the datatype value. But by agreeing that the inline idiom does
>not in fact denote the value, even if it does unambiguously
>identify the value, works just fine.

It has all the appeal of theft over honest toil: it says there is a 
precise specification and also that we are cheerfully ignoring it. 
What is to stop someone totally ignoring the entire MT and saying 
that is OK because he is talking about what the RDF 'identifies', not 
what it denotes?Since we havn't defined 'identifies', who is to say 
he is wrong?

>
>>  Some of our customers definitely do not want to be located there.
>>  They WANT to be able to be sloppy about datatype values, mix talk of
>>  strings with talk of integers, etc., and still they want to invoke
>>  lexical form checking using datatypes.
>
>I understood the concerns/desires differently. I heard that they
>wanted to be able to use the inline idiom and leave the interpretation
>entirely to the application, or at most, indicate which datatypes
>should apply to the interpretation of which literal values.
>
>But perhaps you're right, and I've misunderstood...

Well, check this out with Graham.

>
>>>  If you want the MT to be the only level addressed in the RDF
>>>  Datatyping specification, then could we consider giving datatyped
>  >> literal pairings a formal definition in the MT. They need no
>>>  explicit denotation in the graph, no more so than the datatype
>>>  mappings do. They only need definition. Eh?
>>>
>>
>>  I don't see how this will help, or even what it really means.
>
>Forget the pairings. They are only a conceptual convenience that
>captures what I consider to be the key mechanism of RDF datatyping.
>
>What I ultimately want to see from the MT (and thought it provided)
>is that each and every one of the datatyping idioms (when complete)
>define/identify/provide a specific datatype value.

None of those words have a precise definition. Ask rather what the MT 
says the various parts of the graph denote, and you will get exact 
answers.

>
>>... The various idioms
>>  provide all the precision (or lack of it) that anyone seems to need,
>
>I consider all of the idioms to be equally precise, though some are
>more explicit than others.
>
>>  If you want to be sloppy, you can be;
>
>The only way to be sloppy, IMO, is to use an implicit idiom without
>any rdfd:datatype assertion, i.e. for their to be no datatype associated
>with the literal to tell the application what the intended interpretation
>is. If you specify the datatype, it is fully precise.

The datatype is, but the denotations of different parts of different 
graphs need not be.

>
>Not having a bnode to denote the value is not, IMO, being sloppy.

What I meant is that if you (the user) are interested in lexical 
checking but want to be deliberately underspecified concerning 
datatype values, you have that option. That is what the drange 
datatyping does, or whatever its called now: it works with both the 
inline idiom and the dlex idiom, and does the same *lexical* check in 
both cases, even though the  ranges are presumably different (or 
maybe the range is a union)(or maybe you just dont care about the 
range.)

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 17:18:01 UTC