Re: comments on OWL Last Call drafts

Jim,

Thank you for your email of 9 June 2003 which responds to comments I 
submitted during the OWL Last Call and my apologies for taking so long in 
responding back.  As you noted, we had extensive discussions during the WWW 
conference in Budapest and in consideration of those discussions, I would 
like to make some specific suggestions beyond the more general nature of my 
previous comments.  These suggestions, which currently focus on the use 
cases,  address what I feel are gaps to which I alluded more generally in 
my previous comments.  My intent in making these suggestions is to 
establish a more complete context for the current OWL contributions and (as 
my Ph.D. advisor always demanded) the significance of those contributions 
in advancing the Semantic Web.

My suggestions also represent an evolution in the use cases from a set of 
relevant challenges to a statement which includes how the current work 
provides an enabler to eventual solutions.  I have found this useful in 
other work because it maintains a clear connection between the initial 
motivators and the current state of advancement.  Also, I believe this is 
important because while the use cases are comprehensive in illustrating the 
challenges, it is a disservice to give the impression that OWL in and of 
itself will provide the solution.  Rather, OWL is seen as a critical 
enabling technology and the distinct OWL contributions should be made clear.

The following are specific edits and additions which I propose:

<original section="2"  paragraph="1">
Ontologies can be used to improve existing Web-based applications and may 
enable new uses of the Web. In this section we describe six representative 
use cases of Web ontologies. Note that this is not an exhaustive list, but 
instead a cross-section of interesting use cases.
</original>

<comment>
Add to the end of the paragraph:

Also note that the present OWL charter bounds the scope to that necessary 
to capture sufficient information to support reasoning applications but 
does not in itself include the complete semantics required to capture 
probablistic or conditional aspects which these use cases may imply.
</comment>


<original section="2.1" paragraph="3">
Of course, such a technique relies on content providers annotating their 
pages with the web ontology language, but if we assume that these owners 
will try to distribute their content as widely as possible, then we can 
expect that they would be willing to do this.
</original>

<comment>
This is a questionable assumption because providers are notoriously bad at 
creating useful metadata and thus I believe this undercuts your overall 
argument.  Suggested alternate text:

Such a technique relies on content providers using the Web ontology 
language to capture high-quality ontology relationships, and an objective 
of OWL is to enable sufficiently rich and useful metadata content to 
motivate the necessary effort.  It is a separate challenge to minimize this 
effort and an ontology language will likely have a greater impact if it can 
facilitate metadata capture as an nonintrusive part of any information 
creation process.
</comment>


<original section="2.2" paragraph="3">
An example of such knowledge would be that a "Late Georgian chest of 
drawers" is typically made of mahogany. This knowledge is crucial for real 
semantic queries, e.g. a user query for "antique mahogany storage 
furniture" could match with images of Late Georgian chests of drawers, even 
if nothing is said about wood type in the image annotation.
</original>

<comment>
OWL supports equivalence relationships but not probablistic relationships 
such as "typically made of mahogany".  The concept "typically"would likely 
be application-specific reasoning which might be supported by a value 
mapping ontology, but this logic goes beyond OWL capabilities.  Suggest 
adding to the end of the paragraph:

While OWL in its present form does not intrinsically support such 
probablistic or conditional associations useful in real semantic queries, 
application-specific semantics could be encoded in OWL to support such 
functionality.
</comment>


<original section="2.3" paragraph="1">
A single taxonomy is often limiting because many things can fall under 
multiple categories.
</original>

<comment>
The limitation of a single ontology is not in the possibility of multiple 
categories (relevant multiple categories can coexist in a single ontology) 
but that the categories included in any single ontology represent the view 
which the ontology author needed to capture.  As a more accurate statement 
of the problem, I suggest the following be substituted for the original:

A single ontology is often limiting because the constituent categories are 
likely constrained to those representing one view and one granularity of a 
domain, and the ability to simultaneously work with multiple ontologies 
increases the richness of description.
</comment>


<original section="2.3" paragraph="3">
A typical problem for each of these types of users is that they may not 
share terminology with the authors of the desired content. The salesperson 
may not know the technical name for a desired feature or technical people 
in different fields might use different terms for the same concept. For 
such problems, it would be useful for each class of user to have different 
ontologies of terms, but have each ontology interrelated so translations 
can be performed automatically.
</original>

<comment>
In many situations, the usage of terminology within an ontology may not be 
exact in existing data stores, and we need to leverage existing resources 
rather than implying that these must be repairedto enable conclusive 
translation.  To encompass this need, I suggest adding the following to the 
end of the paragraph:

OWL does not account for fuzzinessin the alignment of terms in different 
vocabularies but it can capture sufficient usage examples to support 
application-specific processing.
</comment>


<original section="2.5" paragraph="2">
This type of agent requires domain ontologies that represent the terms for 
restaurants, hotels, etc. and service ontologies to represent the terms 
used in the actual services. When building the actual services, the 
information may come from a number of sources, such as portals, 
service-specific sites, reservation sites and the general Web.
</original>

<comment>
The discussion of agents and services switches the focus a bit from 
information to the applications.  A noncritical suggestion is to add the 
following text at the end of the paragraph:

For a service environment, an ontology language will enable information 
capture necessary for applications to discriminate and balance among user 
preferences.
</comment>


<original section="2.6" paragraph="4">
The interoperation scenarios are dynamic in nature (i.e., devices appear 
and disappear at any moment as their owners carry them from one room or 
building to another) and do not involve humans in the loop as far as 
(re-)configuration is concerned.

Given that device functionality can be modeled as web services, the needs 
for this use case are somewhat similar to the needs for DAML-S 
(particularly the issues surrounding the expressiveness of the language).

The tasks involved in the utilization of services involve discovery, 
contracting, and composition. The contracting of services may involve 
representing information about security, privacy and trust, as well as 
about compensation-related details (the provider of a service may have to 
be compensated for services rendered). In particular, it is a goal that 
corporate or organizational security policies be expressed in 
application-neutral form, thus enabling constraint representation across 
the diversity of enforcement mechanisms (e.g., firewalls, filters/scanners, 
traffic monitors, application-level routers and load-balancers).

Given that RDF-based schemes for representing information about device 
characteristics have started to be adopted (namely, W3C's Composite 
Capability/Preference Profile (CC/PP) and WAP Forum's User Agent Profile or 
UAProf), an additional need is compatibility with RDF at some level.
</original>

<comment>
In reading paragraphs 4 through 7, paragraphs 5 and 7 feel like disjointed 
inserts and do not provide significant context or motivation.  I suggest 
combining paragraphs 4 and 6, and incorporating elements of paragraphs 5 
and 7 to give the following:

The interoperation scenarios are dynamic in nature (i.e., devices appear 
and disappear at any moment as their owners carry them from one room or 
building to another) and do not involve humans in the loop as far as 
(re-)configuration is concerned. The tasks involved in the utilization of 
services involve discovery, contracting, and composition. The contracting 
of services may involve representing information about security, privacy 
and trust, as well as about compensation-related details (the provider of a 
service may have to be compensated for services rendered). In particular, 
it is a goal that corporate or organizational security policies be 
expressed in application-neutral form, thus enabling constraint 
representation across the diversity of enforcement mechanisms (e.g., 
firewalls, filters/scanners, traffic monitors, application-level routers 
and load-balancers).

Thus, an ontology language will be used to describe the characteristics of 
devices, the means of access to such devices, the policy established by the 
owner for use of a device, and other technical constraints and requirements 
that affect incorporating a device into a ubiquitous computing 
network.  The needs established for DAML-S (particularly the issues 
surrounding the expressiveness of the language) and the RDF-based schemes 
for representing information about device characteristics (namely, W3C's 
Composite Capability/Preference Profile (CC/PP) and WAP Forum's User Agent 
Profile or UAProf) directly relate to this use case and the resource 
infrastructure which will support applications which will negotiate and 
dynamically configure ad hoc networks.
</comment>


<original section="3" paragraph="1">
Design goals describe general motivations for the language that do not 
necessarily result from any single use case. In this section, we describe 
eight design goals for the Web ontology language. For each goal, we 
describe the tasks it supports and explain the rationale for the goal. We 
also describe the degree to which RDF and RDF Schema supports the goal.
</original>

<comment>
This comment generally relates to all subsections of Section 3.  The design 
goals need to address what the Web language will contribute to a perceived 
challenge and not just what the high-level challenge is.  Why is a 
particular design goal important enough to include and what is OWLs 
intended contribution to meeting the challenge?  To this end, I suggest 
each design goal include a section for OWL approach and current 
contributionbefore the RDF(S) Support.  This improves the description of 
where we would like to be (the design goal), how far we had come (the 
RDF(S) contribution so far), and how the present work (the OWL 
contribution) moves us forward.  Note, in the interest of not delaying this 
response further, I have not provided suggested text for each section but 
would be willing to discuss details later.

Additionally, the chosen design goals have an uneven connection between 
them.  As a reader, I am looking for a common thread and the presentation 
does not provide this.  I suggest the following replace the current paragraph:

Design goals describe general motivations for the language that do not 
necessarily result from any single use case. In this section, we describe 
eight design goals for the Web ontology language, in particular those 
dealing with
- using established ontologies
- changing established ontologies
- interacting established ontologies
- detecting inconsistencies across ontologies and instances of use
- providing a balance between expressivity and scalability when creating 
ontologies
- avoiding unnecessary complexity which may discourage widespread adoption
- maintaining compatibility with other standards
- supporting internationalization

For each goal, we describe the tasks it supports and explain the rationale 
for the goal. We also describe the OWL approach in advancing these goals 
and the degree to which RDF and RDF Schema currently provides support.
</comment>


<original section="3.1" paragraph="1">
Ontologies should be publicly available and different data sources should 
be able to commit to the same ontology for shared meaning. Also, ontologies 
should be able to extend other ontologies in order to provide additional 
definitions.
</original>

<comment>
In my suggested wording for Section 3, I more generally describe the focus 
of this section as using established ontologies.  The current wording only 
includes shared use of the same snapshot of an ontology or defining 
ontology extensions, but general examples of use and extension quickly 
require the sibling concepts of pruning/contraction, reorganization, and 
combinations.  The need for versioning to track such changes is alluded to 
in Section 3.2, but acknowledging these capabilities seems an obvious 
omission here.  I suggest the following wording replace the original:

Ontologies should be publicly available and different data sources should 
be able to commit to the same ontology for shared meaning. To ensure the 
maximum degree of semantic capture, support is needed to identify ontology 
extensions to provide additional definitions, ontology reorganization to 
modify the view of a domain without reinventing existing concepts, 
combining multiple ontologies to allow higher level views to use more 
detailed descriptions, and locally pruning shared ontologies to eliminate 
overlap in combined ontologies or to reduce overhead in dealing with 
ontology details that are not needed for the application at hand.
</comment>


<original section="3.4" paragraph="3">
Justification:
The Web is decentralized, allowing anyone to say anything. As a result, 
different viewpoints may be contradictory, or even false information may be 
provided. In order to prevent agents from combining incompatible data or 
from taking consistent data and evolving it into an inconsistent state, it 
is important that inconsistencies can be detected automatically.
</original>

<comment>
Adding a section following this on the OWL contribution is especially 
important because the solution space is not obvious.  The author examples 
(Bucky Beaver or Penelope Ashe) I previously used may be a good basis for 
discussion of how OWL would support detecting and responding to such 
inconsistency.  It is an extremely important concept because it deals 
directly with using Web resources as these exist (now and in the future) 
and does not just put the onus on the resource owner to redo things 
"correctly".
</comment>


<original section="3.5" paragraph="3">
Justification:
There are over one billion pages on the Web, and the potential application 
of the Semantic Web to embedded devices and agents poses even larger 
amounts of information that must be handled. The web ontology language 
should support reasoning systems that scale well. However, the language 
should also be as expressive as possible, so that users can state the kinds 
of knowledge that is important to their applications.
</original>

<comment>
The first four design goals describe realproblems which this and the 
following, while certainly as important, are less concrete situations.  An 
OWL contribution section following the justification would be useful to 
indicate how the OWL 1.0 spec is believed to have accomplished a reasonable 
balance.  I understand OWL Lite, OWL DL, and OWL Full, but a few words here 
would provide context and continuity.
</comment>


<original section="3.6" paragraph="3">
Justification:
Although ideally most users will be isolated from the language by front end 
tools, the basic philosophy of the language must be natural and easy to 
learn. Furthermore, early adopters, tool developers, and power users may 
work directly with the syntax, meaning human readable (and writable) syntax 
is desirable.
</original>

<comment>
Much the same as I said for Section 3.5.  Something more germane to OWL is 
needed rather than a general motherhood statement that ease of use is 
good.  In addition, OWL will require a firmer grounding in the underlying 
concepts than say did XML because for OWL the encoding of tag syntax is a 
trivial problem compared with organizing ontology concepts in a 
domain.  While tool support will be important, keeping the underlying 
concepts accessible will be much more critical.
</comment>



At this stage, I have not gone into detailed comments on OWL syntax because 
I see no need to create further delay that would be introduced by 
suggesting revisions of existing syntax and the associated implementations 
to incorporate noncritical changes.  However, the one shortcoming that 
seems to be easily addressed is in the area of disjoint classes.  In 
section 5.3 of the OWL Language Guide, it notes that "the number of 
disjointness assertions grows proportionally to n^2".  The rationale that 
"n is typically small" is the sort that is often quickly proved wrong.  I 
would suggest the addition of a mutallyDisjointWith syntax something like

             <owl:mutuallyDisjointWith>
                         <owl:disjointClass rdf:resource=class1/>
                         <owl:disjointClass rdf:resource=class2/>
                         <owl:disjointClass rdf:resource=class3/>
                         <...>
             </owl:mutallyDisjointWith>


Again, I apologize for the delay in submitting this response but my 
organization change has proven to be time consuming and I believe the 
changes I propose here are consistent with the issues we have previously 
discussed.  I would be open to discussing these further as would be useful.


Ken


   -------------------------------------------------------------------------------------
/   Ken 
Laskey                                                                   \
|   MITRE Corporation, M/S H305        phone: 703-883-7934   |
|   7515 Colshire Drive                        fax: 703-883-1379        |
\   McLean VA 22102-7508                                                  /
    ------------------------------------------------------------------------------------

Received on Friday, 4 July 2003 17:22:17 UTC