Warning:
This wiki has been archived and is now read-only.
View source for LC Responses/JC1a

Jump to: navigation, search
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, 106, 41712-chairs.
You can view and copy the source of this page.
This is the current proposed response.  The one later in the document is an earlier draft.

{{LCreply
| commenteremail=jeremy@topquadrant.com
| commentername= Jeremy Carroll
| commenterfirstname=Jeremy
| commentLink=http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0051.html
| responder=Ian Horrocks
| response=
We will deal with your specific comments regarding the various documents in a separate email. In this email we will address your more general remarks regarding motivation. In particular, you claim that "The rationale document (and the design) has not taken into account the cost of new features particularly to those who do not need them". We note, however, that the story you use to illustrate this claim applies equally well to OWL DL and OWL Full and to OWL1 with OWL Lite. For syntax, one could have ontologies published in Turtle, NTriples, Manchester Syntax, etc. Furthermore, one could point to extensions like Protege's extensions for QCRs and user defined datatypes and, for that matter, OWL 1.1 and even current versions of OWL.

Thus, we do not believe that the story gives new information or a new perspective. One of the goals of OWL 2 from the beginning was to reduce or eliminate, as much as possible, these costs by producing a standard new version to converge on. We believe the overall advantages and, especially, the new clarity of the specification will make it easier for tool developers to cope with real world ontologies and for new tool developers to enter the market. Furthermore, the working group has continually worked to mitigate the transition costs. OWL 2 deliberately avoids radical new features (such as non-monotonic features, or an entirely new, stratified metamodeling system, or fuzzy extensions). Even features that are well understood and have strong utility and demand were dropped or weakened in response to the sorts of analyses you ask for, e.g., property punning or required n-ary data predicates.

Returning to the motivation for new language features, the New Features and Rationale document (NF&R) [1] is being extended to better document the motivation for the new features of OWL 2. We should also mention that NF&R should be read in conjunction with the OWL Use Cases and Requirements document [2], which already motivates some of these new features, e.g., extended annotations. The make up of the OWL working group is indicative of broad support for OWL 2, not just from academia but also from industry, and we also received many supportive comments in response to the call for review (see [3]). Finally, your own comment expresses support for several of the new features, including qualified cardinality constraints, property chain inclusion axioms, (unary) datatypes, annotations and profiles.

Finally, you questioned the role of OWLED and its representativeness w.r.t. the OWL community. The current wording of the Overview of the New Features and Requirements mentions several underpinnings of the new features of OWL 2.  Only part of this experience came through the OWLED workshops from 2005, 2006, 2007, and 2008DC, and only part of that influenced the OWL member submission.  There is desire for the new features of OWL 2, and implementation experience as well.  The long-term business viability of OWL 2 remains to be determined, of course, but the working group believes that there is sufficient evidence to proceed.

In view of the above, the OWL WG does not intend to make any changes to the design of OWL 2 in response to your comment.

[1] http://www.w3.org/2007/OWL/wiki/New_Features_and_Rationale<br/>
[2] http://www.w3.org/TR/webont-req/<br/>
[3] http://www.w3.org/2007/OWL/wiki/Support<br/>
}}



--

{{LCreply
| commenteremail=jeremy@topquadrant.com
|commentername= Jeremy Carroll
| commenter=Jeremy
| commentLink=http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0051.html
| responder=Bijan Parsia
| response=
The comment you've sent is quite long and complex which attempts to present quite a deep understanding of TopQuadrant's perspective. The working group appreciates that effort and is equally committed to the consensus process. This response is to what we understand as the broadest action we believe you request of us. Where we discerned smaller, specific technical issues that could be sensibly dealt with separately, we separated them out. You will receive distinct responses for each of those.

We believe that the fundamental comment and call for action is the following quote:
   """We ask that many under-motivated new features should be dropped, including all unmotivated new features."""
We perceive the rest of the text as explication of the general approach you would like the group to take when assessing when a feature is under- or un-motivated along with a set of examples of where TopQuadrant would judge a feature to be under- or un-motivated.

We distinguish two sorts of judgement: A feature may be under- or un-motivated with respect to TopQuadrant's perception of its current and likely business needs (and of its customer base), and under- or un-motived with respect to a broad enough community (esp. of W3C members) to be worth standardization, all things considered (including potential asymmetric costs to TopQuadrant or to other parties). We believe that it is the latter that is our responsibility to determine to the best of our abilities, though, obviously the former is critical input to those judgments. Essentially, the consensus process is for the WG to take TopQuadrant's input very seriously and to point TopQuadrant to evidence of other parties' interests. Hopefully, we can reach consensus. We welcome ongoing feedback from TopQuadrant.

One point of clarification: While we are happy to take your feedback on the LC drafts via comments on the FPWD of the New Features & Rationales(NF&R) document, we wish to point out that since the NF&R document is not complete, there may be significant distortions in your understanding of the motivations, costs, and benefits of the design of OWL2. The working group is satisfied that it did weight the costs and benefits broadly and often made decisions based on minimizing the costs and maximizing the benefits to organizations like your own, often based on feedback from you, Jeremy, personally (which was much appreciated). Thus, we do not think there is sufficient justification to do a systematic re-review of each feature.

In particular, you claim that "The rationale document (and the design) has not taken into account the cost of new features particularly to those who do not need them" (I focus on the design issue. The rationale document will be, in due course, updated.) If we examine your illustrative story, we note that it is clear that this story could equally well function without OWL 2. For example, one could replace OWL2 throughout with OWL DL and OWL Full and OWL1 with OWL Lite. For syntax, one could have ontologies published in Turtle, NTriples, Manchester Syntax, etc. Furthermore, one could point to extensions like Protege's extensions for QCRs and user defined datatypes and, for that matter, OWL 1.1 and even current versions of OWL. 

Thus, we do not believe that the story gives new information or a new perspective. One of the goals of OWL 2 from the beginning was to reduce or eliminate, as much as possible, these costs by producing a standard new version to converge on. We believe the overall advantages and, especially, the new clarity of the specification will make it easier for tool developers to cope with real world ontologies and for new tool developers to enter the market. Furthermore, the working group has continually worked to mitigate the transition costs as much as possible. OWL2 deliberately avoid radical new features (such as non-monotonic features, or an entirely new, stratified metamodeling system, or fuzzy extensions). Even features that are well understood and have strong utility and demand were dropped or weakened in response to the sorts of analyses you ask for, e.g., property punning or required n-ary data predicates.

While the working group might have erred in some of this, we do not believe that we can make a more accurate prediction at this time, nor do we believe that we did not successfully analyze matters along the way.

Regarding bias, we first point out that the working group has had members strongly representing the point of view you advocate, including yourself. If you believe that your interests and comments were not given, procedurally, due consideration, then we encourage you to raise an issue with W3C management.

Secondly, members of the working group who might possibly be seen to have the sort of bias you are concerned about are precisely the people who have striven to solicit negative cost analyses. For example, the panel "An OWL Too Far" was proposed by Peter, Ian, Uli, and myself and included Stefan Decker, a long time opponent of OWL DL and, indeed, OWL. (Stefan has not been participating in the OWL 1.1 to 2 effort, so this was a deliberate attempt to bring in a competing voice that had "given up".)

Again, the working group, as a collective, could be wrong. Time will tell. But we do not think there is more that we could have done to avoid the problems in methodology that you site. At this point, we just have a difference of opinion. 

And not a large one, as far as we can tell. TopQuadrant endorses many of the features. The working group believes that they will come to endorse more. There are many features, like property chains, that have been opposed by some people as unmotivated who are now enthusiastic about them.

Furthermore, at the moment we have strong evidence from last call of wide endorsement of the overall design.@@pointers to last call comments

@@Something about HCLS?!?

Finally, we believe that fundamentally reassessing a large number of features -- and even dropping them -- has considerable costs of their own. In general, there hasn't been strong opposition to the feature set and quite a bit of support. Changing that risks breaking the considerable consensus we already have. Without specific evidence of issues, we do not believe that it is sensible, or cost effective, to risk breaking that consensus.

As for your other proposal, that we brand the features "Web-SHROIQ". We are rather confused... severing any connection to OWL seems to introduce potentially even more confusion (there's yet another ontology language?). Given the near total overlap between OWL1 and OWL2 (the overwhelming majority of the language is the same; OWL1 ontologies are OWL2 ontologies) while it would certainly make it easier for people who strictly don't need OWL2 features to 
ignore it, it would also make it exceedingly difficult for everyone else as well as muddling the message. It is also outside the scope of our charter.
}}

{| border="1" cellspacing="5" cellpadding="5"
|-
|
<html><h2>Summary</h2>
<p>
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.
</p>
<h2>Introduction</h2>
<p>
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.
</p>
<p>
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 <em>New Features and Rationale</em> document. We make one 
formal procedural comment
against the last call, merely to connect these comments to the last call, 
and the W3C process.
</p>
<p>
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.
</p>
<p>
Specifically many of the new features are motivated by highly scientific 
applications within
<q>HCLS</q>. Our customers, including our HCLS customers, are typically
interested in applications such as data integration from multiple heterogeneous sources;
for these the new features of OWL2 are not needed and represent a considerable cost and performance impact.
</p>
<p>
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.
</p>
<p>
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.
<a href="http://videolectures.net/iswc08_panel_schneider_owl/">OWL 2 Far</a> and 
<a href="http://lists.w3.org/Archives/Public/semantic-web/2009Jan/0034">Schism in the Semantic Web community</a>, 
indicate that others
in the industry share our experience and opinion.
</p>
<h2>Last Call Comment</h2>
<p>TopQuadrant's principal last call comment on all of the technical OWL2 specification documents is the following request:</p>
<p>
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 <em>New Features and Rationale</em> working draft
as part of the last call process for the technical specifications.
</p>
<h2>Comments on <em>New Features and Rationale</em> working draft</h2>
<p>
These are comments on:
<a href="http://www.w3.org/TR/2008/WD-owl2-new-features-20081202/">
New Features and Rationale</a> of 02 December 2008.
</p>
<h3>Main comment: OWL Too?</h3>
<p><em>This single comment will be made as a separate e-mail, for ease of tracking.</em></p>
<p>
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".
</p>
<p>
An example use case illustrating such costs is as follows:
</p>
<blockquote>
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 (<em>Diet.example.org</em>, <em>Energy.example.org</em>, <em>Food.example.org</em>) of which are available in RDF; 
some (<em>Diet.example.org</em>, <em>Energy.example.org</em>) of these use OWL1 features,
and are available in RDF/XML,
and one (<em>Comestibles.example.org</em>) of which is only available in the 
Manchester OWL Syntax,
and one of which (<em>Beverages.example.org</em>) is only available 
in <code>application/owl+xml</code>. Both of these
last two use OWL2 features, but have some useful information in their OWL1 subset.
<br/>
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).
<br/>
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.
<br/>
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.
<br />
They experience a variety of problems related to OWL2, including:
<ol>
<li>
Various OWL2 constructs (from 
<em>Diet.example.org</em>, <em>Energy.example.org</em>)
are meaningless in OWL1, and the OWL1 implications are lost.
</li>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.
</li>
</ol>
</blockquote>
<p>
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.
</p>
<p>
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.
</p>
<p>
We ask that many under-motivated new features should be dropped, 
including all unmotivated new features.
</p>
<p>
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".
</p>
<h3>Other comments</h3>
<dl>
<dt>Danger of bias</dt>
<dd>We believe that at all stages in the development of the OWL2 specification
that the interests of the DL community, such as tableau reasoner vendors, and that part of the academic community
concerned with tableau reasoner design, has been over-represented, and the interests of the wider
semantic web community (particularly RDF users) has been under-represented.
This is not intended as a procedural criticism.
We trust that during periods of public review, and during the call for implementations,
the WG will be mindful of the need to see active support from the wider semantic web community,
and not be satisfied with passive acceptance.
</dd>
<dt>RDF interoperability</dt>
<dd>Since almost all TopQuadrant's business uses both RDF and OWL together the implicit requirement in OWL 1.0
that OWL and RDF should work well together, remains a critical requirement for OWL2.
We do not see this listed as a requirement, and believe that several of the new features added are 
in practice in conflict with this requirement.
</dd>
<dt>effective?</dt>
<dd>In the abstract we are highly unconvinced by the scoping to <em>effective</em> reasoning algorithms.
To the expert reader this appears to be a highly technical sense of the word <q>effective</q>, which is likely 
to confuse the more general reader. Our customers are interested in software that returns results
in reasonable time, typically within a few seconds, but maybe with some offline computation of a few hours,
effective algorithms can take an unbounded length of time, and ineffective algorithms can be quick in most cases
of interest. Thus, the scoping to effective algorithms is simply a religious allegiance and has no business sense.
</dd>
<dt>OWLED</dt>
<dd>
In the overview, a key part of the rationale is expressed as:
<q>as part of the <a href="http://www.webont.org/owled/">OWLED Workshop Series</a></q>.
The OWLED process while open to all, unfortunately did not, in our opinion, 
achieve what we believe to be the organizers' goals of representing a broad spectrum of the OWL community.
It was only the first two meetings (Nov 2005, Nov 2006)
that played into the member submission,
and had significant impact on the design. The attendance and presenters at these meetings seem to, from our perspective,
under-represent the many OWL users, who use mainly RDF with a little bit of OWL etc.
The ordering "real applications, user and tool developer experience" 
reflects a desire that new features are gated by business motivations.
A frequent pattern with hi-tech innovation is that developer excitement at "oh wow! we can do this"
(even if prompted by discussion with end users) can lead to
inappropriate investments that do not make wider business sense.
Our questioning of the representativeness of the use cases is intended to 
probe this point.
</dd>
<dt>manchester syntax</dt>
<dd>
In section 2  Features &amp; Rationale,
the manchester syntax is not mentioned or justified as a new feature.
Since this introduces additional costs, and is apparently unmotivated, we suggest it is dropped.
</dd>
<dt>OWL/XML</dt>
<dd>
In section 2  Features &amp; Rationale,
the OWL/XML syntax is not mentioned or justified as a new feature.
Since this introduces additional costs, and is apparently unmotivated, we suggest it is dropped.
</dd>
<dt>Links to Wiki should be links to TRs</dt>
<dd>The syntax and semantic links for features discussed in section 2, should link to the TRs
and not to the Wiki.</dd>
<dt>Syntax examples should include RDF</dt>
<dd>The lack of RDF triples in the syntax examples hindered our review effort.</dd>
<dt>DisjointUnion subPropertyof UnionOf</dt>
<dd>The new features introduced as syntactic sugar introduce dangers of interoperability
failure between OWL1 and OWL2.
Some simple steps should be taken to reduce such risks, such as adding the assertion
that <code>owl:disjointUnionOf rdfs:subPropertyOf owl:unionOf.</code>
</dd>
<dt>DisjointUnion and DisjointClasses</dt>
<dd>Being syntactic sugar, these new primitives are strictly speaking unnecessary.
There form in RDF triples is very different from the equivalent disjointWith statements
and are significantly harder to process for OWL implementations that work natively over RDF,
rather than by first translating into OWL axioms. It seems unlikely that many
RDF based OWL implementations (OWL Full implementations) will correctly implement these
constructs. Hence these constructs are likely to lead to interoperability failure between OWL Full
and OWL DL systems. The costs of such failure are much higher than the costs
of requiring users who need such constructs to use the somewhat funky styles 
required by OWL1. These features should be dropped.
</dd>
<dt>Negative*PropertyAssertion</dt>
<dd>
These features are highly problematic for RDF interoperability.
While, technically, from an OWL DL implementation perspective, these are merely macros
for membership of complements of hasValue restrictions, the promotion of this from
an esoteric construct, to a first class axiom, changes their implicit status. 
RDF systems are simply not geared up to support negative triples as well as positive
ones. The negative assertion of the reified triple, while technically faultless, is a
practical disaster in terms of setting user expectations that RDF based OWL tool vendors are
unlikely to meet.
For the SemanticWeb community as a whole, interoperability between RDF and OWL is much more valuable
than ease of use of an advanced OWL construct. The WG has made a bad design choice by including
these.
</dd>
<dt>SelfRestriction and the Schneider variant of the Patel-Schneider paradox</dt>
<dd>As the WG is well aware, the self-restriction increases expressive power in
ways that introduced further paradoxes with OWL Full semantics. While
these are addressed in the WG's technical work, the use cases motivating the new
construct fall well short of what we would expect as needed for motivating risky theoretical
changes.
</dd>
<dt>QCRs</dt>
<dd>We believe these to be a useful addition to OWL. Several TopQuadrant customers would use this feature.</dd>
<dt>reflexive, irreflexive, asymmetric and disjoint properties</dt>
<dd>Our general comment concerning failure to consider the cost of change applies to these features.</dd>
<dt>Property chain inclusion axioms</dt>
<dd>
These appear to be quite widely useful. We have some concerns with the use of blank nodes 
in the subPropertyOf triple corresponding to a RIA.
These are likely to cause problems for RDF implementations which expect all predicates to be URI nodes.
We think that drilling down and fixing all instances where RDF software makes this assumption is costly
and unlikely to happen and to introduce incompatibility between OWL2 and RDF.
We believe introducing a new property in the RDF mapping for RIA and avoiding the use of subPropertyOf
is probably a better trade off here.
We are not wholly convinced that such behaviors are best addressed in the reasoner
rather than using some other approach, such as rules.
</dd>
<dt>EasyKeys</dt>
<dd>explicitly no opinion</dd>
<dt>unary datatype</dt>
<dd>Many TopQuadrant customers require these features.
These make sense as part of the main SemanticWeb Recommendations</dd>
<dt>N-ary datatype</dt>
<dd>This feature appears to have been dropped, and to be in this document by accident, if not we would like to comment.</dd>
<dt>Punning</dt>
<dd>We have mixed opinions ... and make no formal comment, but we are uneasy with this change.</dd>
<dt>Annotations</dt>
<dd>In general, improvements in the expressiveness of the OWL1 annotation system are to be welcomed.
However, the detail of the solution in OWL2, is worrying.
The use of reification for mapping some of the axioms is suspect.
The change form RDF reification to OWL2 reification is unmotivated.
The underlying problems with reification are not addressed by renaming.
A practical worry for a Semantic Web editor (supporting both RDF and OWL) as opposed to an OWL editor or an RDF editor,
is that maintaining the link between the reified triple and the triple itself is another indirection point
that must be considered in many places. Thus, with the implementation of extended annotations embedded within
the current OWL2 design will likely lead to further bifurcation of OWL from RDF, with people either using OWL tools (that support
such features) or RDF tools (that do not, and are likely to interoperate poorly with the OWL tools, e.g. by renaming a triple
without considering the impact on the reified triple).
In some of our consultancy engagements we have been applying annotations to any convenient blank node,
e.g. the blank node of a restriction: we believe this is a better compromise between the needs to annotate ontologies
and the need for RDF interop.
</dd>
<dt>Profiles</dt>
<dd>We are generally supportive, but would not oppose a scaling back of this effort
in light of <a href="http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0042">comments</a> 
from other consortium members.</dd>
<dt>Appendix</dt>
<dd>
Many of the use cases come from the HCLS domain.
<br/>
TopQuadrant has several HCLS customers. We do not, in general, find
their needs qualitatively different from our other customer needs,
and find the choice of HCLS applications referenced from this document
to not reflect our experience of the business area.
<br/>
Thus, we guess that the HCLS applications discussed might be characterized
as <em>scientific</em> HCLS apps, as opposed to the more business focussed
apps which typically motivate our customers.
<br/>
We believe it would be a mistake to impose significant costs on the whole Semantic Web
community because to support use cases from a relatively narrow subsection
of one business segment.
</dd>
<dt>Tables - dependency on HCLS</dt>
<dd>Without the HCLS use cases, (UC#1, UC#2, UC#3, UC#5, UC#, UC#8, UC#9),
the first table seems much closer to our experience of the need for new general
purpose constructs
within OWL.
Essentially there isn't much: QCRs and datatype improvements seem to be it.
Thus, we find the tables to reveal a lack of motivation for change, and so OWL2
is a change we can't believe in.
</dd>
<dt>UC#11, UC#10</dt>
<dd>Presumably are legacy and need deleting.</dd>
</dl>
<h2>Comments on Manchester Syntax</h2>
<p>
Document reviewed: <a href="http://www.w3.org/TR/2008/WD-owl2-manchester-syntax-20081202/">Manchester Syntax</a>
</p>
<dl>
<dt>
Typo: TopBraid Composer
</dt>
<dd>Please capitalize correctly on all uses (TBC all in caps).</dd>
<dt>
Trademark
</dt>
<dd>please acknowledge our trade mark in TopBraid Composer</dd>
<dt>Error in Appendix</dt>
<dd>
TopBraid Composer does not, and does not intend, to support Manchester Syntax as an I/O format,
and so should not be referenced in the IETF application.
The earlier statement correctly expresses the intent:
TopBraid Composer uses Manchester Syntax for  displaying and entering descriptions associated with classes.
</dd>
<dt>
Informative?
</dt>
<dd>
Given that the Manchester Syntax should not be normative (by W3C process)
it seems mistaken to put it through an IETF process that would make it so.
Please drop the mimetype registration.
</dd>
</dl>
<h2>Comments on OWL/XML</h2><p>
Document reviewed: <a href="http://www.w3.org/TR/2008/WD-owl2-xml-serialization-20081202/">XML Serialization</a>
</p>
<dl>
<dt>GRDDL</dt>
<dd>Our understanding of the WG charter is that a GRDDL transform, in XSLT1,
will be provided.
We will raise this issue again at PR review if necessary.
Our preferred fix to the lack of a GRDDL transform, is to drop the OWL/XML serialization.
</dd>
<dt>
Informative?
</dt>
<dd>
Our view, expressed elsewhere, is that this document is unmotivated and
divisive, and has unconsidered costs; and it should simply be dropped.
We note that Frank van Harmelen suggests downgrading it to informative.
While this would be an improvement,
it would then be mistaken to put it through an IETF process that would make 
it normative by IETF.
Please drop the mimetype registration.
</dd>
</dl>
<h2>Comments on datatypes in Structural Specification</h2>
<p>
These comments are on
<a href="http://www.w3.org/TR/2008/WD-owl2-syntax-20081202/">Structural Specification and Functional-Style Syntax</a>;
and concern the datatype mapping section, and the features at risk.
</p>
<dl>
<dt>Lack of rationale and motivation</dt>
<dd>
The changes in the approach to XSD datatypes (such as introduction of owl:real, and
the redefinition of the value spaces of the XSD built in datatypes) is not motivated
in the Rationale document. Since this change risks interoperability failure this seems
like a significant oversight.
</dd>
<dt>owl:real</dt>
<dd>
A possible motivation for owl:real is to allow a property which can be used with any numeric datatype.
TopQuadrant customers have such use cases, when merging data from various sources: however,
the use of a simple XSD union datatype is an alternative solution, which we prefer.
</dd>
<dt>owl:real</dt>
<dd>
A possible motivation for use of owl:real is to permit integration of numeric reasoning services in
with ontological reasoning services. While this may be useful for some Semantic Web application, 
we do not find this to be useful for our business. We do find it critical that numbers in semantic web
applications interoperate with numbers in databases, and with numbers in programming languages.
We hence suspect that this proposed change to the semantics of datatypes in OWL is a further example
of a clean theoretical solution that does not make practical business sense.
We suggest that the value spaces of the XSD datatypes should remain unchanged from OWL1.
</dd>
<dt>owl:rational</dt>
<dd>
There is a typo (owl:datetime) in the description of this datatype.
Otherwise, we explicitly have no comment.
</dd>
<dt> rdf:XMLLiteral </dt>
<dd>
While we have no comment at this time, please let us know if the WG is minded to drop
support for this datatype; we may wish to speak up in its defence.
</dd>
</dl>
</html>
|-
|}
Template used on this page:
Template:LCreply (view source)
Return to LC Responses/JC1a.
Retrieved from "https://www.w3.org/2007/OWL/wiki/LC_Responses/JC1a"
View source for LC Responses/JC1a

Navigation menu

Personal tools

Namespaces

Variants

Views

More

OWL Working Group

Tools
