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 or that once the
interpretation takes place, the lexical form becomes irrelevant.

The problem is that RDF does not itself provide those canonical
internal representations for value spaces, 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.
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... ;-)

> (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.

> 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.

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. 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. 

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.

> >It is also important to note that XML Schema does *not* allow the
> >expression of xsd:integer in anything but base 10. Hence the examples
> >above such as [ rdf:value "#xA"; rdf:type xsd:integer ]. are in fact
> >invalid and erroneous
> 
> Well then why in Gods name did you introduce them? 

Things seemed a little slow to me on the list... thought I'd
make sure you were awake  ;-)

Well, "someone else" introduced the various base notations and
since we're supposed to be thinking in terms of XML Schema, I
just used xsd:integer out of habit, and only later noticed the
conflict (which I may not have had I not used the XML Schema data
type).

> You seemed to be 
> arguing against my point, 

I can see how you may have gotten that impression. Apologies
for my poor choice of words and examples.

> then you turn around and make my own point 
> back at me.

I think we're mostly in agreement, though I still am concerned
about maintaining the inseparability of lexical form and data
type for data typed literals.

Patrick

Received on Tuesday, 6 November 2001 11:00:52 UTC