OWL Too?

This is the main TopQuadrant comment on OWL2 at last call.
I have extracted this from the longer context:
http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/att-0051/index

This is merely for ease of tracking, etc.

===

This is a comment on: New Features and Rationale of 02 December 2008.


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 application/owl+xml. Both of these last two use OWL2 features, but have some useful information in their OWL1 subset.
    Izzie is the team lead and has a good understanding of the full range of the Semantic Web recommendations. Kevin is a modelling expert, with a background in knowledge representation, Lucy understands inference well, Makato is a SPARQL wizard. Joseph is fresh out of school. (The economy has picked up, and Izzie was slighty disappointed with the limited choice of candidates for the Junior Ontologist Trainee role).
    Izzie makes the design decision that OWL2 features are not needed for this project, and that the advantages of using several OWL or RDF applications that do not support OWL2 features is the critical factor. She sends Joseph on a Semantic Web training course, while the rest of the team get started on the project.
    Most of their tools cannot read the manchester syntax or OWL/XML, so they use a Jena extension to convert Beverages.example.org and Comestible.example.org to RDF/XML; and they keep the copies locally.
    They experience a variety of problems related to OWL2, including:

       1. Various OWL2 constructs (from Diet.example.org, Energy.example.org) are meaningless in OWL1, and the OWL1 implications are lost.
       2. Joseph's training was 1-day RDF, 1-day OWL1, 1-day SPARQL, half-day RIF, half-day OWL2. He got somewhat confused! He sees the OWL2 constructs being used in some of the data sources, and when mapping some proprietary data into OWL he uses the same constructs. Despite the fact that he used the OWL2 constructs correctly, the overall system does not take his modelling into account, since several of the components are not OWL2 aware. Izzie has to take him to one side, and spell out the decision to use OWL1 only and what that means.
       3. One of their tools do understand the manchester syntax and OWL/XML, this ends up going to the web and retrieving the latest version of Beverages.example.org and Comestible.example.org. A couple of months into the project, these ontologies are updated on the web, and the local copies (in RDF/XML) are not. A few days later, unexpected system behaviour is observed, which is eventually tracked down to the version mismatch.
       4. A week or two after this, a team meeting gets completely derailed when Kevin pipes up in advocacy of supporting various OWL2 features because he wants the extra expressive power; Lucy gets quite irate at having to explain, all over again, her estimates of the runtime cost in the inference engines for the additional expressive power, and her inability to meet her performance targets using the additional features; while Makato tries to drill down with Kevin on precisely what is wrong with the SPARQL queries that the team have been using to fill in gaps where the expressive power of OWL1 is less than is required for their application. After a fairly unproductive 90 minutes, Izzie calls time, and reminds the team of the earlier design decision to use OWL1. Joseph has a headache.

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

===

Jeremy Carroll, on behalf of TopQuadrant

Received on Monday, 26 January 2009 21:55:16 UTC