- From: Michael Smith <msmith@clarkparsia.com>
- Date: Tue, 01 Jul 2008 13:05:19 +0000
- To: Boris Motik <boris.motik@comlab.ox.ac.uk>
- Cc: 'OWL Working Group WG' <public-owl-wg@w3.org>
On Tue, 2008-07-01 at 13:15 +0100, Boris Motik wrote: > 1. We introduce the owl:real datatype with the value space of all real numbers. We don't add any constants of the form owl:real. > 3. We leave xsd:integer and all the derived types as they are. Thus, "1"^xsd:integer is still valid as usual. > 5. We make xsd:decimal the subset of owl:real and we leave all constants as they are. Thus, "1.0"^^xsd:decimal is still a valid > constant in OWL. > > 6. We disallow the "pattern" facet on all numeric datatypes. > The items above sound good. > 2. We introduce the owl:rational datatype with the value space of all > rational numbers. We add a constant for each rational number > along the lines of http://www.w3.org/2007/OWL/wiki/OWL_Rational. Thus, > we would be able to write things such as "1/3"^^owl:rational > or even "1/1"^^owl:rational. I haven't heard anyone request a datatype that is just rationals. The proposal was to have rational constants, but over the real value space. If we constrain ourselves to rationals in the value space, we'd likely run into some of the numerics problems we're trying to avoid. > 4. We make xsd:double the subset of real numbers between the minimal double and the maximal double number. We do the same for > xsd:float. All constants are the same as in XML Schema; thus, "1"^^float and "1.0"^^float are all the same constants. We disallow > the NaN (not-a-number) constant (allowing NaN would make owl:double not a subset of owl:real). > > We are thus staying "almost" true to XML Schema, in thatwe have exactly the same set of constants as in XML Schema. The main change > is that, in order to facilitate simpler implementations, we make the extension of xsd:double and xsd:float continuous rather than > discrete. On Jun 19 (in [1]) I mentioned that this is a change from best practice advice [2] and impacts existing implementations. I asked for clarification on what the benefit of the change would be so we could evaluate this as a trade-off. > As I explained in my last e-mail, two constants can be different even though they denote the same value. Constants that are different but which map to the same value -- this isn't a difference that is significant to a reasoner. Do I misunderstand you? > This elegantly solves the > problems that Alan mentioned in his last e-mail. For example, if the ontology initially contains "1.0"^^xsd:float, this would be > read into a constant whose lexical representation is "1.0" and whose URI is xsd:float. Thus, if you write the ontology back from the > structural spec, the constant would be written out as "1.0"^^xsd:float, and thus the form of the ontology would be preserved. This would only be true if one's tool supported some sort of literal round-trip guarantee. The internal representation of literal constants is an efficiency trade-off over which I expect tool vendors would be making their own decisions. > The only thing that changes really is that we'd say that the extensions of xsd:double and xsd:float are continuous and not discrete, > and we'd tweak them (e.g., by removing NaN) to make them subsets of owl:real. It seems that "supporting" xsd:float and xsd:double, but not allowing some of their permitted values is likely to confuse users. -- Mike Smith Clark & Parsia [1] http://lists.w3.org/Archives/Public/public-owl-wg/2008Jun/0149.html [2] http://www.w3.org/TR/swbp-xsch-datatypes/#sec-values
Received on Tuesday, 1 July 2008 13:05:59 UTC