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

>>>> 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