Re: Question about number types

On 4 Jul 2008, at 12:25 , Bijan Parsia wrote:

>
> On 4 Jul 2008, at 19:06, C. M. Sperberg-McQueen wrote:
> [snip]
>> My earlier answer pointed to passages in the 1.0 and 1.1 specs,
>> but on reflection I think the stronger argument is just:  given
>> that several of the value spaces are described in the same terms
>> (numbers, bit strings), how could the rule that the value spaces
>> of the XSD types are disjoint be taken any other way than as
>> specifying that they are treated as disjoint for purposes of the
>> comparison operations defined in the XSD spec for purposes of
>> bounds checking, enumerations, and identity constraints?
>
> If one interprets the XSD type system as having named, not merely  
> structural types, then when one adopts the XSD type system (or  
> tries to) one imports that aspect as well.
>
> See:
> 	http://thid.thesa.com/thid-0513-0671-th-0683-5303
> 	http://en.wikipedia.org/wiki/Structural_type_system
> 	http://en.wikipedia.org/wiki/Nominative_type_system
>
> This is how I read it. Since OWL basically treats the XSD type  
> system *as* a type system (including adopting portions of its  
> definitoin system), it seems a reasonable choice to respect those  
> constraints.

Yes, quite right, it does.  If I have appeared to suggest otherwise,
I have perhaps been careless in my wording.  There may be more
than one reasonable choice, of course.

>> The disjointness of the value spaces postulated by XSD is a
>> convenient way of handling the relatively few cases of
>> cross-primitive comparison that can arise in schema-validity
>> assessment, and of ensuring that one can postulate, given
>> a value, knowledge of its primitive datatype.
>
> That intention isn't determinable from the spec, so I don't see  
> that you can rely on people treating the disjointness as a mere  
> convenience.
>
> (The comments in the spec about implementation seems, again, to be  
> different from the issue of what is the nature of the type system.  
> I can implement a structural types system in a language with a  
> nominative type system.

Quite true.

> The question here is what are the right answers from the  
> perspective of the *XSD type system*.)


I think using the comparison operators of XPath 2.0
Functions and Operators provides a clean solution in part
because the comparators are defined in a way that does not
involve denying the disjointness of the primitive value
spaces; there is a well defined type promotion hierarchy
which is deployed when operations involving multiple
primitives are performed.  If there is a reason that those
operators cannot be used, then perhaps the right answer is
for OWL to use the type conversion functions of FO and
require explicit type conversions.

But I think that Functions and Operators does provide an
account of cross-primitive comparisons (and other operations)
on values of the XSD type system which is consistent with the
XSD type system and works reasonably well in practice.  I'll
invite others who know more about the internals of F and O
to say more, if appropriate.

--CMSMcQ

Received on Friday, 4 July 2008 19:55:24 UTC