W3C home > Mailing lists > Public > public-owl-wg@w3.org > May 2009

Re: draft response for JC2

From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
Date: Sat, 16 May 2009 14:53:08 +0100
Cc: <alanruttenberg@gmail.com>, <public-owl-wg@w3.org>
Message-Id: <B6870EDB-8629-47D7-97FD-242BBD55E9DE@cs.manchester.ac.uk>
To: "Peter F.Patel-Schneider" <pfps@research.bell-labs.com>
On 16 May 2009, at 00:53, Peter F.Patel-Schneider wrote:

> I went in and upgraded the third point of the response to talk about
> another reason for including owl:real, namely modelling hygene.
> I also put in more about the mess in RDF wrt empty lexical spaces and
> added a point that the WG would be prepared to make the lexical  
> space of
> owl:real the same as the one for owl:rational, even though it is a
> slight extra burden, as long as that is the sole remaining problem  
> with
> owl:real.

I was thinking about this and I realized that I don't want to make the  
lexical space non-empty.

	1) There's no technical reason for this. That is, it won't hurt  
compatibility with existing RDF systems in *any* way. Essentially,  
we've just said that *any* literal of the form "anyChar+"^^owl:real is  
malformed. Which is fine as existing systems have to handle malformed  
literals for *any* datatype.
	2) It captures exactly what we want. owl:real is for constraining the  
solution space of an equation. Any returned answer should be in a more  
specific type for which we can supply lexical forms. For example,  
owl:rational. Future systems can introduce new subsets of owl:real  
*with new lexical forms* as they see fit (e.g., owl:radical). And  
everything is nice and groovy.
	3) The 'requirement' is artifical and unnecessary. Heck, it's pretty  
explicit that they were trying to be as loose as possible about future  
possible datatypes. This is hardly a *radical* innovation.
	4) The specs are arguably contradictory. We can send an errata.

In other words, I don't think it's worth distorting our design to meet  
a requirement that has no technical effect and definitely doesn't  
affect the person making the request.

(Btw, "having a non-empty lexical space" is not a testable requirement  
in principle. For example, I can make a lexical space that is a subset  
of all unicode strings that are larger than the powerset of gluons in  
the universe.)

Received on Saturday, 16 May 2009 13:53:50 UTC

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