Subject: [LC response] To Jeremy Carroll
Thank you for your comment
on the OWL 2 Web Ontology Language last call drafts.
We will deal with your general comments regarding motivation in a separate email. In this email we will address your detailed comments about specific aspects of the language, dealing with each of these separately below. Many of these comments raise specific questions w.r.t. motivation and use cases. Please note that New Features and Rationale (NF&R)  is not intended to provide comprehensive use cases for all the features of the language, but rather to provide examples that illustrate the rationale behind the new features of OWL 2. As noted in its abstract NF&R document should be read in conjunction with the OWL Use Cases and Requirements document .
Regarding your specific comments:
Danger of bias: This seems to be part of your general comments regarding motivation which we will deal with in a separate email.
RDF interoperability: As we mentioned above, NF&R only covers new features. The motivation for RDF interoperability in OWL 2 is carried over from OWL 1 and is achieved via the same design principles--nothing has changed in this respect.
Effective?: The abstract has been completely rewritten and no longer mentions effective reasoning algorithms.
OWLED: This again seems to be part of your general comments regarding motivation which we will deal with in a separate email.
Manchester Syntax: This is not a Last Call Working Draft, and the working group has decided that it will not be part of the recommendation but will be published as a working group note. It may be worth pointing out, however, that it is widely used, e.g., in TopBraid Composer, the Protege editor and the OWL 2 Primer.
OWL/XML: It should be noted that RDF/XML is the only syntax that MUST be supported by implementations; support for the XML syntax is not required (see also FH3). The XML syntax is motivated by the desire to support OWL users who want better interoperability with XML based tools and languages, for example WSDL. An additional benefit is that XML data can be exposed to RDF/OWL applications using GRDDL (see ). We will extend NF&R to better motivate the need for an XML syntax.
Links to Wiki should be links to TRs: Thank you for pointing this out. We will investigate the cause of the problem and ensure that it does not recur fix in future versions of the document(s).
Syntax examples should include RDF: This deficiency has been noted and the current version of the Syntax document allows readers to see the RDF graph version of all examples.
DisjointUnion subPropertyof UnionOf: You suggest "adding the assertion that owl:disjointUnionOf rdfs:subPropertyOf owl:unionOf". However, this doesn't make sense from a semantic point of view (see ).
DisjointUnion and DisjointClasses: As you rightly say, these constructs do not extend the expressive power of the language, but only add "syntactic sugar". However, users of OWL have pointed out that the lack of such constructors is very inconvenient and can lead to a significant blow-up in the size of the ontology if large numbers of pair-wise disjointness axioms need to be added -- see, e.g., . The triple form of the new n-ary axioms and its relationship to the binary form exactly parallels the case for differentIndividuals, so it should not add significantly to the implementation burden. Implementers within the working group, including those working on triple-based implementations, do not consider these features difficult to implement.
Negative Property Assertions: Such assertions are useful in applications, e.g., to state that a person does not live at a given location or that their age is not a given value (see ). Using complements of hasValue restrictions is cumbersome, and it is hard to see how this would be easier for RDF based systems to process or how it would improve RDF interoperability. The OWL 2 RDF Based Semantics includes semantic conditions that deal with negated property assertions  and thus ensure interoperability.
SelfRestriction and the Schneider variant of the Patel-Schneider paradox: The ability to express additional "properties of properties", such as reflexivity, irreflexivity and asymmetry, is often needed in applications -- see, e.g., . SelfRestriction provides for "localised" reflexivity. This may be more useful in practice that global reflexivity. The OWL 2 RDF-Based semantics is not so susceptible to paradox problems, and so neither reflexivity nor SelfRestriction introduces any particular difficulties. NF&R discusses the support for this new feature.
QCRs: Thank you for your supportive comments.
Reflexive, irreflexive, asymmetric and disjoint properties: see above. The usefulness of these features was explicitly mentioned by the Health Care and Life Sciences interest group in their last call comment -- see . The Semantic Web Deployment (SWD) Working Group explicitly mentioned the usefulness of property disjointness for specifying the semantics for SKOS mapping relations, and the potential usefulness of reflexivity and asymmetry -- see . Reflexivity can also be used to "approximate" SelfRestriction in profiles that do not support this feature. NF&R discusses the support for these new features.
Property chain inclusion axioms: At F2F5, the working group resolved to change the current RDF encoding of sub property chain axioms to a single triple form, which avoids the blank node on the left hand side and the use of "subPropertyOf" [4a]. The new vocabulary term "owl:propertyChainAxiom" has been introduced. Several documents were modified to effect this change - the best places to see the difference is in RDF-Based Semantics [4b], the Mapping to RDF was also changed [4c].
unary datatypes: Thank you for your supportive comments.
N-ary datatype: Please see , where it says: "This specification currently does not define data ranges of arity more than one; however, by allowing for n-ary data ranges, the syntax of OWL 2 provides a "hook" allowing implementations to introduce extensions such as comparisons and arithmetic." I.e., n-ary datatypes are not supported, but the language is designed so as to facilitate future extensions in this direction. Such an extension will be published as a working group note (currently under preparation -- see ).
Annotations: We are glad to hear your general welcome for the improvements in the annotation system. Regarding the use of reification in annotations, this is mainly done in order to provide for annotations on axioms, a crucial feature in many tools and applications, as is suggested in your comment (note that this requirement was identified in the OWL Use Cases and Requirements document ). This is necessary, for example, on a simple subClassOf axiom relating two named classes; in this case there is no "convenient blank node", so your proposed solution does not work. In other cases, however, OWL 2 does attach annotations to blank nodes. RDF tools are accommodated in the existing design by including both "reified" and standard triple encodings of annotated axioms. The decision not to use RDF reification properties was taken in order to avoid overloading the meaning of the RDF vocabulary, and in response to comments from the RDF community (see Issue-67 ).
Profiles: Thank you for your generally supportive comments.
Appendix and dependency on HCLS: As mentioned above, NF&R is only intended to provide examples that illustrate the rationale behind the new features of OWL 2. The HCLS community has been very energetic and has contributed many of these examples. We would welcome any examples that you might like to contribute from your user base to broaden the base of use cases in NF&R.
UC#10 and UC#11: UC#10 and UC#11 motivate a feature which the working group was not able to fully develop, but for which it intends to publish a note . It is true that these motivate a feature that did not ultimately become part of the language, although as we have discussed above the language does include the relevant "hooks" and an n-ary datatype extension will be published as a WG note . Moreover, documenting the motivation for unimplemented features may be of use to future working groups and is consistent with the approach taken in the OWL Use Cases and Requirements document .
TopBraid Composer: This has now been corrected.
Trademark: This has now been corrected.
Error in Appendix and Informative?: We have deleted the reference to TBC in the IETF application. However, although support for Manchester syntax is optional, the working group still considers it worthwhile to continue with the mimetype registration.
GRDDL: The working group has resolved to add GRDDL support to the OWL XML syntax (see ).
Informative?: See the above comment on OWL/XML. Although support for the XML syntax is optional, the working group still considers it worthwhile to continue with the MIME type registration. MIME type registration is not related to normativity.
XSD datatypes: Some aspects of the OWL 2 use of XSD datatypes have been changed, in particular OWL 2 now makes the value spaces of all XSD primitive datatypes pairwise disjoint, as in XSD. Because of this change, owl:realPlus has been removed from OWL 2.
owl:real: The new numeric datatypes specific to OWL 2 have been added partly to support reasoning with n-ary datatypes . Unions of other datatypes are not adequate for this purpose.
owl:datetime: This has been superseded by xsd:dateTimeStamp (see ).
Please acknowledge receipt of this email to <mailto:firstname.lastname@example.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.
on behalf of the W3C OWL Working Group
CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.
PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL
TopQuadrant believes that the current working drafts for the OWL2 specifications, would, if advanced to Recommendation, be detrimental to our business, and to our customers' use of the Semantic Web Recommendations. We ask the working group to consider whether this is an atypicality of the market segment which we serve, or whether the scientific HCLS use cases motivating much of the design of OWL2 are atypical. If the latter, we suggest either scaling back or rebranding the OWL2 Recommendation.
TopQuadrant is a small company offering both products and services. All of our revenues depend on the successful deployment of Semantic Web technologies. We are profitable. To date that success has been possible through co-existence strategies that use both RDF and OWL together, including OWL full where expressiveness and ease of understanding out-weigh decidability.
We have a range of concerns about the OWL2 specifications. Recognizing the considerable technical achievements in their design, we have no major technical criticism. Thus, our concerns are, in the main, not suited to being Last Call comments on the Rec track documents, but are better expressed as comments concerning the New Features and Rationale document. We make one formal procedural comment against the last call, merely to connect these comments to the last call, and the W3C process.
The main thrust of our concerns is that we find the motivations for changes to the OWL Recommendation to be weak or non-existent, and to be limited in their scope to what we believe to be a narrow section of the Semantic Web marketplace.
Specifically many of the new features are motivated by highly scientific
Thus, while those consortium members using ontologies to express precise assertions about domain theories, may benefit from the new specifications, we do not believe we will; and we suspect that our lack of benefit will be the more common experience amongst consortium members, and the wider public. Given this is the case, then the consortium would be ill-advised to advance them to Recommendation without significant change.
TopQuadrant is committed to the consensus process of the consortium, and will not press these concerns without support from other members. However, anecdotal evidence, e.g. OWL 2 Far and Schism in the Semantic Web community, indicate that others in the industry share our experience and opinion.
Last Call Comment
TopQuadrant's principal last call comment on all of the technical OWL2 specification documents is the following request:
Since most of our comments concern the overall design, rather than the technical details, we have made them against the New Features and Rationale document, which is not technically part of the last call. Hence, we ask the WG to formally address our comments on the New Features and Rationale working draft as part of the last call process for the technical specifications.
Comments on New Features and Rationale working draft
These are comments on: New Features and Rationale of 02 December 2008.
Main comment: OWL Too?
This single comment will be made as a separate e-mail, for ease of tracking.
The rationale document (and the design) has not taken into account the cost of new features particularly to those who do not need them. These costs include: implementation costs, training costs, documentation costs, and simply the cost of ignoring something. (It needs to be understood before it can be ignored). This is seen anecdotally in the ease with which people slip into thinking: "OWL Too Far", "OWL Too Full", "OWL Too Much".
An example use case illustrating such costs is as follows:
Izzie, Joseph, Kevin, Lucy and Makato are building a set of ontologies and semantically enhanced applications in the area of dietary planning. They are using a collection of tools each of which supports some of the semantic web recommendations. They have some informations sources that they have prepared in-house, they are also integrating several Web-based information sources, most (Diet.example.org, Energy.example.org, Food.example.org) of which are available in RDF; some (Diet.example.org, Energy.example.org) of these use OWL1 features, and are available in RDF/XML, and one (Comestibles.example.org) of which is only available in the Manchester OWL Syntax, and one of which (Beverages.example.org) is only available in
While these problems are largely to be expected in an ontology development project, and can be addressed by a range of techniques such as improved project management, cache control, version management, and aspirins, we believe that OWL2 introduces many additional places where such problems might arise, and we do not see adequate consideration of these costs in the design.
We believe that the rationale document shows a very significant dependency on a narrow section of the Health Care and Life Sciences applications. The needs expressed are not ones which we find are pressing for our HCLS customers.
We ask that many under-motivated new features should be dropped, including all unmotivated new features.
An alternative, possibly better approach to addressing this comment, might be to rebrand most, if not all, of the new features of OWL2, as "Web-SROIQ", and put them in a separate namespace, not branded as OWL, so that the (vast) majority of Semantic Web users for whom these features are neither useful nor helpful, but merely confusing, can rest more easily in ignoring them. Notice the choice of name for the rebranding does not include the string "OWL".
Comments on Manchester Syntax
Document reviewed: Manchester Syntax
Comments on OWL/XML
Document reviewed: XML Serialization
Comments on datatypes in Structural Specification
These comments are on Structural Specification and Functional-Style Syntax; and concern the datatype mapping section, and the features at risk.