RE: RDF speficiations (was RE: Cutting the Patrician datatype kno t)

> If you define myxsd:integer as something that defines a 
> lexical-to-value
> mapping in a different way than xsd:integer does, then, of course any
> implementation of RDF plus datatypes that understands 
> whatever method you
> used to define myxsd:integer must follow your definition.  If 
> the value
> space of myxsd:integer is the same as the value space of 
> xsd:integer and
> the lexical-to-value mapping is the usual one, then, again of 
> course, the
> RDF plus datatypes implementation is *required* to answer 
> affirmatively
> that <John> <age> <myxsd:integer:010> entails <John> <age> 
> <xsd:integer:10>
> Otherwise the implementation is non-conforming.  How can it 
> be otherwise?

It is important (crucial really) to differentiate between means
of defining relations between data types and mechanisms for
defining the actual mappings between lexical and value spaces.

It appears that the desire to be able to model the actual mapping
between lexical and value spaces in RDF is the desire to determine
the compatability between two data types in terms of value or
lexical spaces. But such relations between types can be captured
in RDF without having to model the mappings explicitly.

One can say that there are two distinct cases where one data type 
is a subtype of another, where

(a) any member of the value space of the subtype is also a
member of the value space of the supertype, or 

(b) that any member of the lexical space of a subtype is a member 
of the lexical space of the supertype *and* maps to the same value 
in the value spaces of both classes (has an identical interpretation 
for both classes) 

and these cases/relations can be captured without knowing what the 
particular mapping or value is.

It is of course necessary to clarify how such relations should be 
defined in RDF so that these cases (a and b) are distinct.

I would propose that rdfs:subClassOf would be the logical choice
to denote case 'a', addressing relations only between value
spaces of data types. All members of the value space of type X 
which is an rdfs:subClassOf another type Y would also be members
of the value space of Y, but their lexical spaces and the mappings
between lexical and value spaces would (presumably) not be compatible.

We would then need an additional property to define case 'b',
such as something like rdfs:subTypeOf which would be an
rdfs:subPropertyOf rdfs:subClassOf and which would denote a
much tighter relationship between types such that a member
of the lexical space of a type X which is an rdfs:subTypeOf
another type Y would also be a member of the lexical space
of type Y *and* would share the same mapping to the same value
which would be a member of the value space of both types.

Since rdfs:subTypeOf is a rdfs:subPropertyOf rdfs:subClassOf,
then we would know that any type X which is an rdfs:subTypeOf
type Y is also rdfs:subClassOf type Y.

These two properties allow us to capture the necessary 
relations between data type classes to make logical 
inferences about compatability between both value and
lexical spaces, without burdening RDF with having to provide
the mechanisms by which the actual mappings between lexical
and value spaces are defined or with having to provide any
native representation for the actual values.
 
Thus, to get back to your example above, one could define
that

   myxsd:integer rdfs:subClassOf xsd:integer .

to say that every member of the value space of myxsd:integer
is also a member of the value space of xsd:integer, but
that lexical spaces and mappings are (presumed) incompatible,
such that an application that understood xsd:integer would
not be able to reliably interpret a literal (lexical form)
defined in terms of the myxsd:integer lexical space.

Or you could define that

   myxsd:integer rdfs:subTypeOf xsd:integer .

to say that, not only is it true that every member of the value 
space myxsd:integer is also a member of the value space of 
xsd:integer, but that any application that understands 
xsd:integer can reliably interpret a literal defined in
terms of the myxsd:integer lexical space as an xsd:integer.

To give two other examples that illustrate further this
distinction, the xsd:byte type would be an rdfs:subTypeOf
xsd:integer whereas a Scheme programming language integer
type scm:integer, which allows variant notations in decimal, 
binary, octal, etc. would only be an rdfs:subClassOf xsd:integer
since even though their value spaces are compatible, their
lexical spaces are not.

The ability to define relations between data types in terms
of value space alone, irrespective of lexical space, allows
us to capture the interoperable characteristics of various
data typing schemes which denote the same value spaces but
which have, for various reasons, differing lexical spaces
and mappings from lexical spaces to value spaces.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Friday, 7 December 2001 17:51:43 UTC