Datatype disjointness objection summary

Obsolete. See Datatype Disjointness instead.

 

The WG had initially decided *not* to make numeric datatypes
disjoint. However, after receiving two adverse LC comments [1, 2] and
feedback from implementers the WG decided to reconsider the
issue. There was an extensive discussion at the F2F on 23 February
2009 [3]. Many members of the WG expressed the opinion that the above
mentioned comments and feedback, as well as the benefits of
compatibility with XSD, RIF and existing implementations (such
as Jena and Pellet), were very strong arguments in favour of
disjointness. Some WG members wanted to consult with their
organisations, so a vote on the issue was postponed. At the 11 March
2009 teleconf the WG again discussed the issue, and the opinion in
favour of disjointness was overwhelming [4]; it was resolved (12 for and 1
against) to make all base datatypes, including owl:real, xsd:float and
xsd:double, disjoint as per XSD [5].

The objection to this decision from Science Commons is summarised in
[6]. It should be pointed out that this summary fails to mention that
the revised decision was also motivated by implementation reports (in
particular from Boris Motik, who reported that implementing the
non-disjoint design turned out to be very difficult in practice),
existing implementation practice (it was reported that both Jena and
Pellet implement disjoint datatypes), and more careful consideration
from potential implementers (e.g., after consultation with colleagues
about their OWL Prime implementation, the Oracle rep revised his
position to be in favour of disjointness).

The Science Commons summary also refers to and email from Dave
Peterson regarding XSD's stance on disjointness [7]. It is claimed
that "Peterson's response supports the notion that XSD type
disjointness does not necessarily apply to OWL". However, this seems
to overstate what can be understood from the email. Peterson confirms
that XSD value spaces are disjoint, but isn't sure if OWL needs
identity or equality. Even if it is assumed that equality rather than
identity is what is needed (which is by no means clear), what Peterson
says is:

	  "XSD says that for its purposes, it chooses to define its
	  equality and order relation in such-and-such a way.  But it
	  explicitly says that adopters of the datatypes should feel
	  free to redefine equality and order (among other things) as
	  they see fit.  What more can we say?  It's pretty clear that
	  Alan, for example, expects a different equality from that
	  chosen by XSLT/XQuery.  We clearly can't satisfy all users."

In other words, the spec does allow for adopters to *redefine*
equality, but the result would then be inconsistent with the
definitions chosen by XSD and XSLT/XQuery. So, disjointness is still
be needed in order to be *consistent* with XSD, even if it isn't
strictly needed for *conformance*.


[1] http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0031.html
[2] http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0027.html
[3] http://www.w3.org/2007/OWL/meeting/2009-02-23#Disjointness
[4] http://www.w3.org/2007/OWL/meeting/2009-03-11#Datatypes
[5] http://www.w3.org/2007/OWL/meeting/2009-03-11#resolution_3
[6] http://neurocommons.org/page/OWL_unified_numbers
[7] http://lists.w3.org/Archives/Public/www-xml-schema-comments/2008JulSep/0014.html