Re: comments on OWL Last Call drafts

Ken - as your comments mostly address the Requirements document, I 
asked Jeff Heflin, the editor, to write the response.  However, there 
were a couple of things where he felt the chair needed to be 
involved, so I've done some editing and am sending this - consider it 
a joint effort (but he did most of the work)
  please let us know if you'll accept this response.
Jim H


Ken Laskey wrote:
>
>  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.

Ken,

We'd like to thank you for your thorough review and detailed suggestions.

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

We do not believe the Use Cases and Requirements is the right place for
the discussion you desire. To truly explain how OWL meets a particular
requirement would require a detailed description of the relevant
features, duplicating much material from other OWL documents. However, we
can understand how the document might be read in such a way as to lead
to a false impression of the intended capabilities of OWL. In some cases
below, I suggest alternative wordings that should help prevent this
confusion.


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

Instead, we propose to add:

"These use cases served as a guideline in choosing requirements for the
OWL language (see Section 4). The requirements were chosen based on the
aspects of the use cases that the working group considered most
important, while considering the scope of the OWL charter and other
design constraints. As such, one should not assume that OWL will
directly support every aspect of the use cases."


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

Okay, we will make this change.

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

Actually, the use case was talking about defeasible inheritance
reasoning, not probability. Although probability can be clearly of use
in some use cases, the working group did not consider it an important
requirement, although support for probabilistic information is implied
by Requirement R12. Attaching Information to Statements. However, 
you are right that the "typically" is misleading here, and therefore 
we will change this to read
"...a `Late Georgian chest of drawers', in the absence of other 
information, would be assumed to be `made of mahogany.'  This 
knowledge ... "
which we agree will be less misleading.


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

Good suggestion. We will make the change.

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

Given our revised statement to the opening of section 2 and the fact that
fuzzy reasoning is not in the list of requirements, we'd prefer not 
to add such a statement.

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

We will change the paragraph to:

"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. These ontologies will enable the capture of
information necessary for applications to discriminate and balance among
user preferences. Such information may be provided by a number of
sources, such as portals, service-specific sites, reservation sites and
the general Web."

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

Excellent change. We will make it.

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

We agree that doing what you ask here would be a useful thing to 
have, but doing it right would go well beyond the scope of this 
requirements document (and will be the job of those who write the 
eventual OWL books).   However, it is the case that a way to track 
where each of our objectives and requirements are discussed in our 
documents would be useful.  During the CR period we will endeavor to 
produce this mapping and consider including it in as an Appendix to 
this or one of our other documents.

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

This is a good idea, we'll accept it although slightly changing the 
wording to be more consistent with the remainder of our document:

"Design goals describe general motivations for the language that do not
necessarily result from any single use case. Along with the use cases,
these motivate the requirements and objectives in Sections 4 and 5. In
this section, we describe eight design goals for the Web ontology
language, in particular those dealing with:
  - using established ontologies
  - changing established ontologies
  - integrating 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 degree to which RDF and RDF
Schema supports the goal."


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

We think this is redundant with sections 3.2 and 3.3 and would prefer 
not to add it.

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

The degree to which this design goal influenced our design can be
discovered by looking at what requirements it motivated. In this case it
is: R7. Class definition primitives, R8. Property definition primitives,
and R14. Cardinality constraints. It also motivates objectives O3, O4,
and O14.

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

For this particular case, we do not believe that the Requirements 
document is the right place for this discussion.  In particular, the 
intent of the overview document was to provide more of such 
discussion, and we think that it is addressed well there.  Thus, we'd 
prefer not to add this discussion again here.

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

The details of how we meet this objective are discussed in great 
detail throughout the guide and the overview document - thus, what we 
proposed above, tracking which requirements and objectives are 
handled where, should help with this.

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

The working group did consider adding this in response to an earlier 
comment , but decided not to (see the reply Dan Connolly sent at 
[1]).  There are some syntax issues that make it difficult to express 
the way you propose above.  However, there is a workaorund where one 
does not need the N^2 statements, as described by Ian Horrocks in 
[2], and we will add a pointer to that to our issues list to make it 
clearer what to do when the number of classes is large.



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

Thank you again for your comments. Please respond to
public-webont-comments@w3.org to let us know if our responses are
satisfactoy.

Jeff and Jim

>  Ken
>

[1] 
http://lists.w3.org/Archives/Public/public-webont-comments/2003Jun/0038.html
[2] http://lists.w3.org/Archives/Public/www-webont-wg/2003Jul/0157.html

-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  *** 240-277-3388 (Cell)
http://www.cs.umd.edu/users/hendler      *** NOTE CHANGED CELL NUMBER ***

Received on Friday, 18 July 2003 10:53:46 UTC