From: Rob Shearer <rob.shearer@comlab.ox.ac.uk>

Date: Mon, 7 Jul 2008 01:02:14 +0100

Cc: OWL Working Group WG <public-owl-wg@w3.org>, public-webont-comments@w3.org

Message-Id: <FF872971-5F95-4531-B37F-0AFB9453C42E@comlab.ox.ac.uk>

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

Received on Monday, 7 July 2008 00:02:51 GMT

Date: Mon, 7 Jul 2008 01:02:14 +0100

Cc: OWL Working Group WG <public-owl-wg@w3.org>, public-webont-comments@w3.org

Message-Id: <FF872971-5F95-4531-B37F-0AFB9453C42E@comlab.ox.ac.uk>

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

>>>> XSD offers a lexical syntax for points that happen to lie on the >>>> real number line >>> >>> It offers several and we're free to define one for owl:real. If we >>> use any decimal notation, we have exactness problems (e.g., 1/3), >>> but decimal is very user friendly. So, I was thinking that the >>> valid syntax for a real would be decimal floating points and >>> ratios of integers. We could include scientific notation as well. >> >> Why on earth would the OWL group come up with their own syntax for >> encoding numbers? > > I'm presuming we're sticking with the basic xsd framework. So types > have a lexical space and a values space. NO. There is no lexical space to represent all of the reals. That's the whole point---the reals include lots and lots of values that cannot necessarily be represented lexically. > So, owl:real has a value space of the reals. But what should the > lexical space be? I'd propose that at least the union of the xsd > numeric types lexical spaces be the lexical space for our new type. > I would add additional syntax for exact rationals (such as 1/3). The > first part is isomorphic to your proposal about xsd syntax, I believe. Again, I have no intention of implementing rationals. And if you want to come up with some syntax for encoding rational numbers in XML I suggest you join the XSchema working group, because that's way beyond the OWL charter. >> The XSchema guys have already done that, and people have >> implemented parsers for their spec. If there's going to be a syntax >> for rationals or algebraics, then that seems to be right up their >> alley. > > They don't seem interested, alas. And I very much hope the OWL WG takes that as a sign that they should be even less interested. >>>> XSD datatypes have a lexical space (e.g., the syntax) and a value >>>> space. You are suggesting, I thought, that we adopt a value space >>>> that is the reals and something about using xsd syntax (i.e., >>>> lexical spaces) for the syntax. >> >> For the syntax of particular values. I keep trying to stress that >> values spaces should be kept separate from the syntax used for >> particular values. > > Sure. But that's true in XSD as well. No it's [not](http://www.w3.org/TR/xmlschema-2/#value-space): "Each value in the value space of a datatype is denoted by one or more literals in its ·lexical space·." In XSD the lexical and value spaces and very tightly bound together. This should *not* be true for OWL. > From what I can tell, you want all the literals that have > "xsd:float" (to pick an example) to map to (a subset) of the reals > (as the value space) and constrain/enable certain syntax. So > "1.0"^^xsd:float would be a syntax error. That looks like a valid [float][http://www.w3.org/TR/xmlschema-2/ #float] to me. But `"rob"^^xsd:float` looks like a syntax error. Again, all these syntax issues should be deferred to the XSD spec. >> . I want `real` to be a value space with no lexical connotations. > > I'd be surprised if we could get consensus on abandoning the lexical > space/value space language and understanding. It's pretty deeply > embedded into RDF. It's impossible to have a real number line and have lexical representations for all values. The "value spaces" in OWL serve a fundamentally different purpose than the "value spaces" defined in XSD. See my first message. XSD is concerned with representing values. Future incarnations can add more representations for more values, and existing data sets can be seamlessly extended with these new values. OWL is concerned with spaces of values. If the OWL 2.0 value space for numbers does not include, for example, the rationals, then the system can *not* be seamlessly extended to include the rationals, because they've already been excluded. The value spaces from XSD are inappropriate for OWL because they fail in exactly the wrong way. OWL extensions trim down value spaces. XSD extensions build up value spaces. To make this clearer, perhaps we should abandon the "value space" terminology altogether and instead talk about OWL "data domains". I suggest that OWL have a string data domain and a number data domain. The integer data domain is a subset of the number data domain. There is absolutely no need for a float data domain. OWL implementations should support particular values encoded using the `xsd:int` and `xsd:float` lexical representations. These values are all in the number domain. >> I want to be able to specify a particular point in this value space >> using a string such as "1.0e0^^xsd:float". > > Yeah, I'm kinda against that. But I would support "1.0e0^^owl:real". That's craziness. You're crazy. Stop being crazy. >> The XSD lexical forms are not "the lexical space for reals". There >> is no such thing as "the lexical space for reals". > > Bravo! ;) > >> There is such a thing as "the space of lexical representations >> which a conformant implementation must support for particular >> values in the real value space", but this space is much smaller >> than the real value space. > > Our initial proposal for owl:real is to support for syntax, pairs of > integers with the second being non-zero (i.e., standard fraction > syntax for rationals) and (at least) the algebraic reals for the > value space. If you don't have equations or special constants, you > can't address the irrationals or transcendentals anyway. We are > aiming to support some classes of equation, but only with rational > constants. But why on earth would you cut down the value space at *all*? That just cuts off any possibility of future extension! >>> If we want exactness for the rationals, we need either to allow >>> repeating (e.g., 0.333repeating) (usually done with a macron) or >>> fraction syntax (e.g., 1/3). >> >> I don't intend to support exactness for rationals. A conformant >> implementation should only be required to provide exact support for >> `xsd:int` and `xsd:float` values. > > I don't think that would fly. Who is the vast army of users in need of support for exact rationals? I strongly strongly suspect that if they really existed they would have pushed on the XSchema folks to give them a lexical representation---XML is kind of big as a data representation language, you know. > Also, perhaps I misrecall, but don't you want arbitrarily sized > floats? An `xsd:float` has a limited size, by definition. > """For the restriction "forall R `xsd:float`" I simply bounded the > real number line at the min and max values of floats. Still a dense, > infinite number line, but with bounds. I hated this usage, however, > and would prefer if it became illegal.""" > > So you did bound...but you "hate it"? Which, the bounds? the > universal quantifier? I hated that the user was saying `float` and I was interpreting it as "real between `FLT_MIN` and `FLT_MAX`". I hope OWL 2.0 allows only OWL data domains in such a context. (But of course an individual value is a valid data domain, and complex data domains could be built using facets with individual values.) -rob

- application/pkcs7-signature attachment: smime.p7s

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Monday, 7 December 2009 10:43:30 GMT
*