RE: DATATYPES: mental dump.

> >I am still unsure just what you mean by "mapping".
> 
> I just mean in it the ordinary mathematical sense. A correspondence 
> between two sets of things. Call it a function if you like, or a 
> morphism, or a set of ordered pairs, or whatever.
> 
> The point being that it isn't enough to JUST give the lexical and the 
> value spaces; you have to say HOW the datatype maps one into the 
> other. 

If you mean defining the mapping in terms of statements such
as:

  * for a data type which defines a lexical space, every member of the 
    lexical space maps to one and only one member of the value space

  * for a data type which defines a canonical lexical space, every member 
    of the canonical lexical space maps to one and only one member 
    of the value space

  * for a data type which defines both a lexical space and a canonical 
    lexical space, every member of the lexical space maps to one 
    and only one member of the canonical lexical space

Then I agree. It is needed. Sure.

> For example, let me define a rather silly datatype that might 
> be called regetni, where the lexical and value spaces are just like 
> xsd:integer, but the mapping between them reads the numerals 
> backwards, so that "12" means twenty-one and "0034" means four 
> thousand three hundred. 
>
> The lexical and value spaces are the same, but the mapping is different.

Right. The spaces are the same, (or rather, the spaces are distinct but
have a perfect intersection of members) but the data types are not the 
same.

It is the data type that defines the specific mappings, but
we don't have to define what that mapping actually is, only
that it must exist. And not only might the data types define
different mappings between their (otherwise identical) sets
of lexical forms and values, but those data types may impose
other interpretations on those sets such as different orders,
etc.

So the *spaces* are not the same, even if they have a perfect
intersection of members, because those spaces have associated
with them semantics beyond the basic set of members.

It may be necessary to say that a lexical
form maps to one and only one value, but not what that value is
or how that mapping is "executed" -- because in order to define 
that, you have to define the complete data type, and I don't
see the RDF MT defining all data types themselves.

Eh?

> >I don't see how you could actually express the explicit
> >*mapping* from lexical form to that actual value
> 
> Right, I'm not talking about a mapping that could be 
> *computed* by anything.

You miss my point. You said that you want to define how
the lexical form maps to the value, which from your
example above says you want to define the actual mappings

I.e.

Data Type     Lexical Form    Value 
--------------------------------------------------
xsd:integer   "12"           'twelve'
xsd:integer   "0034"         'thirty-four'
xsd:regetni   "12"           'twenty-one
xsd:regetni   "0034"         'four-thousand-three-hundred' 

And I'm asserting that the definition of such a
mapping does not belong in the core RDF MT, even if
one may later wish to define such a mapping in terms
of the RDF MT by a specialized ontology.

I.e., to define such a mapping is to write a function
specific to the data type, and I don't think RDF should
be writing such functions.

And if you want to define a language for writing such
functions that is compatible with the MT, fine, but
I don't see that it should be part of the MT because
one would not be able to express those functions in
RDF. If one could express those functions in RDF, then
they can do so in terms of the MT without such extension.

All that RDF IMO should define is that the mapping exists
and that a given lexical form maps to one and only one
value. Past that, you are in the domain of the specific
data types or beyond what can be expressed in RDF.

Eh?

Patrick

Received on Friday, 16 November 2001 06:16:09 UTC