W3C home > Mailing lists > Public > public-webont-comments@w3.org > July 2008

Re: ISSUE-126 (Revisit Datatypes): A new proposal for the real <-> float <-> double conundrum

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Fri, 4 Jul 2008 16:56:06 -0400
Cc: public-webont-comments@w3.org, public-owl-wg@w3.org, www-xml-schema-comments@w3.org
Message-Id: <B163CCB2-09CD-4466-B55E-3285C16BA671@gmail.com>
To: Rob Shearer <rob.shearer@comlab.ox.ac.uk>

Thanks for your comments Rob. It occurs to me that both the XML Schema  
and the OWL working groups are in progress, that this is an issue that  
touches both groups, that having the specifications be able to be read  
in conjunction without confusion as to their relationship would be  
beneficial to overall efforts of the W3C towards harmonization and the  
implementors and users of those specifications.

Perhaps we can take advantage of the felicitous timing to ensure that  
our respective specifications are consistent with each other by  
ensuring that terms are used in the same way, if necessary adding  
clarification, and by attempting to have any additional datatype  
concepts needed for a good OWL specification be incorporated into the  
XML Schema specification.

Towards the end of understanding the terminology, I've been trying to  
understand what the value space of XML Schema means, given that it  
doesn't mean what one would expect in a mathematical sense. Similarly,  
there seems to be missing an underlying type for the date types -  
although there is reference to timeOnTimeline, this value type is not  
surfaced in the type hierarchy.

One thought is that whether a correct interpretation is more along the  
lines of considering the value spaces as data structures. In favor of  
this interpretation it is clear that floats and integers are distinct  
and the stated influences - java, sql, machine independent data types.  
Contrary to this is that it makes it harder to interpret the integers  
as a restriction of decimals, since representation of arbitrary  
precision decimals is by a different data structure, and to understand  
the difference between base64Binary and hexBinary, which are  
represented on the machine as the same data structure.

Another thought is that the value spaces are another aspect of lexical  
expression. This would account well for there being a difference  
between base64Binary and hexBinary, but not explain why these are not  
pattern facet restrictions on string.

Finally, I wonder if you have comments on a couple of other aspects of  
datatypes that appear in XML schema. Specifically, data types that are  
derived by list and time and date types. Clearly such concepts or  
similar are relevant to OWL given work on, e.g. workflow, or  in  
spatial reasoning. Where do they fit into your view of OWL class space?


On Jul 4, 2008, at 12:46 PM, Rob Shearer wrote:

> This message is in regard to the discussion related to [this](http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0101.html 
> ).
> When I was implementing the Cerebra OWL reasoner, I came to the firm  
> conclusion that the OWL (1.0) spec was downright broken on this  
> point, and I fear we're in danger of breaking OWL 2.0 in exactly the  
> same way.
> Putting aside the issue of whether or not it's possible to use  
> (only) the XML Schema datatypes to represent meaningful and  
> implementable OWL datatype value spaces, I expect that there is  
> consensus that when users were writing `xsd:float` and `xsd:double`  
> without values in OWL 1.0, what they really meant was "any number".  
> No user ever intended to restrict the semantic space to a nowhere- 
> dense number line. If the OWL spec presupposes that most of our  
> users would a prefer a number line which does not include 1/3, my  
> choice as an implementor would be to once again ignore the spec and  
> be intentionally non-compliant. Doing what all my users want and  
> expect in this case turns out to be way way easier than doing what a  
> broken spec would require. Any working group who would produce such  
> a spec would clearly be putting their own interests (ease of spec  
> authoring and political considerations) above their duty to their  
> intended users.
> (Note that in the course of the discussion I read on public-owl-wg  
> the notions of "dense" and "continuous" seem to have become  
> confused. I think the notion of density is probably the only one  
> that makes a difference in terms of current OWL semantics, since  
> number restrictions can cause inconsistencies in non-dense number  
> lines, but continuity is really what users have in their heads.)
> The [XML Schema datatype spec](http://www.w3.org/TR/xmlschema-2/) is  
> focused on representing particular values, not on classes of values.  
> The notion of "value spaces" is used within the spec, but only in  
> service of representation of values---note that there's not a single  
> value space mentioned which is continuous with respect to the reals,  
> nor are such notions as "rationals" defined. This makes sense in  
> terms of data serialization (the driving XML use case) and standard  
> programming languages (where manipulation of values is the driving  
> use case), but OWL is in a very different situation. The primary OWL  
> use case is reasoning about the emptiness (or size) of value spaces,  
> and the definitions provided in the XML Schema spec do not serve  
> this purpose well.
> Note that I'm not saying XML Schema is a bad spec; merely that it  
> addresses different problems than we have.
> I strongly encourage the working group to publish a spec which  
> provides for the following types of semantic spaces:
> 1. A countably infinite, nowhere-dense datatype. I.e. the integers.
> 2. A countably infinite, dense datatype. I.e. strings.
> 3. An uncountably infinite, dense, continuous datatype. I.e. the  
> reals.
> I don't particularly care what each of these three is called; as  
> long as OWL specifies the internal semantics of these three types of  
> spaces, then it's straightforward to "implement" the datatypes users  
> will actually want in terms of them. But, of course, the ability to  
> use XML Schema Datatypes to encode specific values within each of  
> these spaces would be quite convenient---and would use the XML  
> Schema specification for *exactly* what it's good at.
> -rob
Received on Friday, 4 July 2008 20:56:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:30 UTC