From: Bijan Parsia <bparsia@cs.man.ac.uk>

Date: Wed, 18 Feb 2009 14:37:33 +0000

Message-Id: <D1D86ACE-CD83-46C9-89C9-3E9DC3E333E6@cs.man.ac.uk>

Cc: Bijan Parsia <bparsia@cs.manchester.ac.uk>, Chris Welty <cawelty@gmail.com>, Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org, Boris Motik <boris.motik@comlab.ox.ac.uk>, W3C OWL Working Group <public-owl-wg@w3.org>

To: Alan Ruttenberg <alanruttenberg@gmail.com>

Date: Wed, 18 Feb 2009 14:37:33 +0000

Message-Id: <D1D86ACE-CD83-46C9-89C9-3E9DC3E333E6@cs.man.ac.uk>

Cc: Bijan Parsia <bparsia@cs.manchester.ac.uk>, Chris Welty <cawelty@gmail.com>, Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org, Boris Motik <boris.motik@comlab.ox.ac.uk>, W3C OWL Working Group <public-owl-wg@w3.org>

To: Alan Ruttenberg <alanruttenberg@gmail.com>

On 18 Feb 2009, at 13:47, Alan Ruttenberg wrote: > Hi Bijan, > > The problem is that the implementation considerations that lead RIF to > want disjointness lead to further consequences (primarily the desire > to use existing implementations of the xpath numeric operators) extend > beyond disjointness. That's not a problem for the OWL WG. That they may go beyond what is reasonable (at least for OWL) doesn't stop it being reasonable for us to go with disjointness. > As the report of my discussion with Jos revealed, > it extends into how facets can be used, requiring further changes, > and, because of, for instance, the lack of a precise, implementation > independent definition of them, yield consequences that undermine the > stated goal of interoperability with OWL and across the SW stack. > > A discussion of our decision, in my view, needs to address all these > issues and I would be against a decision to choose disjointness if it > only brings an illusory gain. We have ample other reason to reconsider the disjointness consideration. It's hard to imagine any reform of the RIF numeric handling that would press them to give up disjointness, whatever else they may or may not change. Are you against, qua chair, our bringing this question to the OWL group? Will you even take the temperature of the group? [snip] >> (I have to do some interpretation to figure out what you mean by >> "specify >> machine representations of numbers...". I presume you mean that we >> should >> define the number system of OWL via standard mathematical >> apparatus (we do) >> such that they align with common mathematical connotation of the >> natural >> language terms (for which either disjointness or non-disjointness is >> justifiable). There is no univocal set of mathematical properties >> associated >> with the term "float" even up to reasonable isomorphism. > > We aren't working with the natural language definition of "float". We > are working with (effectively) the IEEE definition. Which says nothing about the relationship to integers (for example, at least for the purposes of identity). And, in fact, we are working with the XSD Schema datatypes system (xsd:float, not ieee:float). And arguably, they are disjoint in that mathematical structure. Q.E.D. >> So there is no >> "given" to adjudicate which mathematical structure we select. That >> is, you >> are *not* on the mathematical or philosophical high ground here, >> and I would >> appreciate it if you would stop writing as if you were.) > > I'm sorry if you don't like my style of writing. It's not primarily your style, it's your content. There is no in principle mathematical argument which says that floats are not disjoint from decimals in a number system. None. Zero. Zip. Zilch. 0.0. "0"^^nonNegativeInteger. > However I stand by my > arguments. What arguments? I don't see any beyond "We should define stuff in terms of the mathematical properties of the numbers". I grant that and also point out that float disjoint decimal is a perfectly sane set of mathematical properties. We have several other considerations that make this set of mathematical properties overwhelmingly preferable. I've not heard anything from you in the other direction. >> mplementability >> is firmly on the side of disjointness, the usability argument is >> further >> undermined by the usability costs of diverging from RIF (and standard >> interpretations of XML Schema), and I have a second wind :) > > As I've pointed out, we are likely to diverge from RIF because of the > other consequences of them relying on built in numeric operators not > designed with reasoning in mind. We will not diverge from them on disjointness. The only point in your email that is not disjointness related is 3 where you confuse facets with op:numeric-greater-than. These are different predicates and there is no incompatibility in different predicates behaving differently. Those predicates do not appear in OWL ontologies. This is a bit like saying that we'll diverge with them on conditionals. Sure. Because we have *different conditionals*. So, under all the ado there's a heaping pile of nothing. [snip] >> (hence, new information), then, unless there are actual, new >> technical >> arguments in the offing > > there are, as I detail in my recounting of the discussion with Jos. [snip] In point of fact, there are not. We have an easy solution to the *actual* last call request that fits in with other new information we have and, I believe, the overwhelming view of the working group. Hence, we should do this fix and move on. If you wish to pursue further numerics issues with RIF, I believe that they have last call coming up. Or you could join that group. If that isn't sufficient, I hereby raise a last call comment that float (et al) and decimal (et al) should be disjoint in accordance with XML Schema 1.0, with common practice and implementation (Jena, Pellet) and for implementation reasons (cf. HermiT). (I know it's past the LC period but we've accepted lots of out of period LC comments.) Cheers, Bijan.Received on Wednesday, 18 February 2009 14:34:03 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:42:09 UTC
*