Re: Denotation of datatype values

>Patrick:
>>  But it seems that no'one (myself included) feels that the
>>  answer is 'yes' (apart from perhaps Jeremy, though he has
>>  not responded to this question directly) so I'll drop it.
>
>Whilst it is good of you to keep thinking of me, I have decided that I am
>too far from the group consensus to contribute positively to the process.
>
>I have lost quite what the "question" refered to above was, but it seems
>that the e-mail has settled on a rational point (which I disagree with).
>
>In some contexts the literal string "25" in the model theory denotes the
>literal string "25" but "according to our shared understanding" there is a
>corresponding value of 25. The 25 does not occur in the model theory, but
>the application is expected to use it.
>
>Personally I detect doublethink. If the specification indicates that the
>application should use 25 when it receives "25"

That might be doublethink, but that isnt a correct conclusion. There 
isnt enough in this graph to insist that the application SHOULD use 
25, only that it COULD use 25, if it knew enough about the 'context' 
to know that strings were being used here to indicate their values. 
But it couldnt know that from the RDF alone, since the RDF graph is 
consistent with other possibilities (eg that literals really do mean 
numerals rather than numbers). The MT stops just where the RDF stops: 
it goes that far and no further. Some RDF customers don't want to go 
any further, it seems (eg Dublin Core).

>then wherever the official
>line at which the model theory stops there is an implicit and
>ill-articulated extended conceptual model which has the value 25 in it.

It is UNarticulated because it depends on unarticulated content, ie 
something about the 'context' that isn't represented in the RDF 
graph. But the MT does not rule it out; it just doesn't aspire to 
describe it.

>That
>is the conceptual model that the specifications expect the application
>writer to use (and document authors ...). My earlier argument that the
>datatyping proposal was non-monotonic is refuted up to the model theory.
>This is from the clarity that there is only "25" and not 25. But the
>argument still stands as far as the conceptual model goes.
>
>It seems that the clarity of this thread that one idiom delivers

In order to say this we would need to know what 'delivers' means. It 
is quite possible for the RDF graph to in a sense 'deliver' enough 
information to enable some engine to determine that a value (eg 25) 
is in some broad sense relevant, even though there is nothing in the 
graph which actually denotes or names that value. I don't see any 
problem in this situation: the same could be said about RDF without 
datatyping, if the engine to which the RDF is delivered happens to 
know enough about the meaning of some uriref and its intended meaning 
to enable it to draw some extra conclusion, more than is explictly 
represented in the RDF graph itself. There is no way to legislate 
against such a situation, even if we wanted to do so (and I suggest 
that we do not want to, in any case.)

I dont think this has anything to do with the local/global datatyping 
issue as it has been discussed previously.

>  25 whereas
>the other delivers "25" should be made clear in the document

I think that this is clear: each idiom has nodes denoting things 
unambiguously (literals denoting strings and sometimes bnodes 
denoting values) and it also has unambiguous wellformedness 
constraints. There is no ambiguity that I can see.

>, and an
>explicit admission that the disideratum of interoperability between the
>global and local type mechanism has not been met.

I disagree, see above. The local and global (ie range-based) 
datatyping machinery all interoperate.

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 Monday, 15 April 2002 16:17:53 UTC