RE: Cutting the Patrician datatype knot

From: Pat Hayes <>
Subject: RE: Cutting the Patrician datatype knot
Date: Thu, 29 Nov 2001 17:40:02 -0600


> OK, but now what is the problem with my MT extension, again? Of 
> course, with THIS sense of "union", one cannot treat [integer union 
> string] as in any sense the simple class-union of the classes 
> [integer] and [string]. So as far as the RDF reasoner is concerned, 
> [integer union string] is just another datatype, which might as well 
> be called [foodle]. If someone were to assert that
> [integer] rdfs:subClassOf [integer union string] .
> that would be correct, but that would cause no problem in the MT, 
> since [integer union string] agrees with [integer] on numerals; they 
> have the same lexical-to-value mapping on anything that would map to 
> an integer. Similarly, it would be correct to assert
> [string] rdfs:subClassOf [string union integer] .
> though in that case it seems rather pointless since in this case the 
> datatypes are identical, since even numerals will be mapped as 
> strings by that union. But again, this poses no problems for the MT. 
> On the other hand, if someone were to assert
> [string] rdfs:subClassOf [integer union string] .
> then that would be simply false, as all numeral strings are in the 
> former value space but not the latter.

I don't see how this follows.  The value space of the XML Schema datatype
[integer union string] is precisely the union of the value spaces of
integer and string.  Yes, you do need extra syntactical constructions to
access the shadowed part of the value space, but this does not eliminate
it.  Even if you couldn't, I don't see the requirement that the
lexical-to-value mapping be onto.


> >Instead, again, it is the presence of two (different) datatypes that have
> >overlapping value spaces but different lexical-to-value maps within this
> >overlap!
> Which are, exactly? As far as I can see, this situation never arises 
> with the combinations
> [integer], [string] , [integer union string], [string union integer].
> The lexical and value spaces are respectively
> [integer]       numerals   --->  N (integers)
> [string]         S (strings)  --->  S (strings)
> [integer union string]    S  ---> N union (S - numerals)
> [string union integer]    (same as [string])
> None of these have the pathological behavior that you describe, since 
> their lexical-to-value mappings coincide on the parts of the value 
> spaces that overlap.

My view of the situation is diametrically opposite, and is, I think, taken
directly from the XML Schema documents.

 [integer]       numerals   --->  N (integers)
 [string]         S (strings)  --->  S (strings)
 [integer union string]    S  ---> N union S
 [string union integer]    S  ---> N union S

Why, because in XML Schema it is possible to type a property (or what
passes for one in XML) as an [string union integer] and still have a value
for that property be an integer.  

This can be done by something like (and, yes, this is not completely valid
XML Schema syntax):

	  age  ...  [string union integer]


	<Person> <age xsi:type="xsd:integer">10</age> </Person>

So XML Schema does have datatypes that share value spaces, but that have
diverging lexical-to-value maps.	

> Pat Hayes


Received on Friday, 30 November 2001 12:11:12 UTC