RE: Reject change to rdf:value

>  > ...as the identity
>>  mapping (perhaps naively) and made-up examples such as xxd:date as
>>  mappings from calendar formats such as '10-10-01' into some space of
>>  days or time-intervals.  The idea being that a given literal may
>>  occur in several lexical spaces, and hence not have a determinate
>>  meaning until the particular datatype mapping is somehow connected
>>  with it;
>
>This seems to imply to me that once that data type mapping is
>connected to the literal that it is immutable

Right, that would be my interpretation as well.

>or that once the
>interpretation takes place, the lexical form becomes irrelevant.

??? I'm not sure what you mean by 'takes place'. By 'interpretation' 
I didn't mean to refer to a process. The lexical form is not 
irrelevant, since its the only thing that determines the actual 
literal value.

>
>The problem is that RDF does not itself provide those canonical
>internal representations for value spaces

What canonical internal representations? Nobody has mentioned these 
until now, as far as I know.

>, but preserves the lexical
>forms of such values -- hence in such cases, the data type of a
>literal is inseperable with the lexical form embodied in the literal.

Well, its not *inseperable*. What is true is that you need both to 
fully disambiguate the literal label.

>The mappings from literals to value spaces do not happen in RDF,
>and therefore all information needed for such mappings to take
>place must be preserved across all processes prior to actual
>interpretation.
>
>>  and the debate is about various proposals for how to use
>>  some form of RDF syntax to establish that association.
>
>Fair enough. I've proposed the encoding of typed data literals as
>URVs, a special class of URI explicitly intended for such purposes.
>So I guess that's one more proposal on the table... ;-)

Right. BTW, do you have a pointer to that URV idea?

>
>>  (In my
>>  proposal, these mappings are treated much like the denotation mapping
>>  in the model theory. Other proposals make these mappings explicit as
>>  rdf properties in one way or another. ) Do you agree with this
>>  summary so far?
>
>Sure, but we have to ensure that those mappings remain fixed until
>interpretation, including processes which by inference or other
>means bind values to properties belonging to data types other than
>that originally defined for the value.

I'm puzzled. You seem to be assuming that interpretation is something 
that happens at some stage in processing (?) I was using 
'interpretation' in the sense of model theory. Maybe we are at cross 
purposes.

>
>>  One of our communication problems has been that the bare term
>>  'datatype' is used in a variety of senses (sometimes for the value
>>  domain, sometimes for the mapping, etc.), so perhaps I had better try
>>  to avoid it. I have used examples like octal, decimal and so on as
>>  illustrative examples only to emphasize that two different datatype
>>  mappings may share the same value space.
>
>I agree that there is a problem with the terminology. The term datatype
>(as I use it, and also as I understand XML Schema to use it) defines
>a given value space. It may also, for a given system/context, define
>one or more lexical forms by which values in that value space may
>be expressed.

Ah. My understanding was that a datatype corresponded to a mapping 
from a lexical space to a value space. I see why we have been having 
some trouble communicating.

>
>Thus, decimal, hexidecimal, octal, binary, etc. are all possible
>lexical forms (notations) of integers (and other possible data types),
>and are not themselves data types. It is IMO incorrect to equate a
>given lexical form or notation as a data type. A data type defines
>primarily a value space.

Well, never mind who is in the right, but let us try to agree on some 
terminology we can all understand. If a datatype is a value space, 
what do you call the mapping from lexical to value spaces?

>Lexical forms are only a means to an end.
>Data types are, in general, portable across systems and platforms
>even if their lexical forms are not.

Ah, I profoundly disagree for RDF. There is no 'end' in this sense; 
nothing gets compiled; its not a programming language. All there is 
is the syntax, and all you ever get back from any kind of inference 
is more syntax. There aren't any inner canonical forms, and no code 
gets interpreted.

>
>Lexical forms of values for a given data type are relevant for
>source code, but become irrelevant when that code is interpreted
>and those values are mapped to canonical internal representations.
>
>The same should be true for RDF, except that because RDF does not
>actually define any canonical internal representation for any data
>types independent of lexical form, the lexical form remains significant
>for processes which traditionally had no concern about lexical forms.
>
>It's a very interesting problem, really. Just how much is RDF/XML like
>source code, and how much is an RDF graph a compilation of that code
>which various processes can be executed against.

I would say, not in the slightest.

>
>I think we're mostly in agreement,

Yes, sorry I got testy. I will blame the pneumonia, its got to be 
useful for something.

>though I still am concerned
>about maintaining the inseparability of lexical form and data
>type for data typed literals.

I don't mind letting them get separate as long as there is always a 
way to get them back together. Inside a given graph there is, but 
your point about queries has me worried that this isn't good enough.

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 Tuesday, 6 November 2001 22:15:13 UTC