Proposed (parital) response to Ken Laskey and questions for WG

Hello everyone,

Jim asked me to compose a response to this message since most of it
concerns the Requirements document. However there are two issues that
need general consideration by the working group.

First, Ken wants the Requirements document to state how OWL meets the
requirements or use case specified. I do not think this is appropriate
for the requirements document, particularly since it would require
duplication of many of the other documents to explain the features. I'd
like WG input on this. I see two options:

1) choose to decline the suggestion

2) add a summary of how we meet the requirements in another document,
perhaps Overview  or reference

Second, there is a comment at the end of Ken's e-mail that requests a
mutuallyDisjointWith feature. Since this is not a requirements document
issue, I'd like someone else to take it on.

The rest of my response is inline below. I have indicated where the
response would depend on our decision on the point raised above.

Jeff

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,

Since most of these comments address the OWL Use Cases and Requirements,
I have been asked to respond to you. I'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.

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

*** discuss WG decision on whether to say OWL meets requirements
elsewhere ***

> 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, I 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, I 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. Therefore, I
decline the change.



> <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. I 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 my revised statement to the opening of section 2 and the fact that
fuzzy reasoning is not in the list of requirements, I think this
statement is unnecessary.

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

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

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

As mentioned earlier, I do not believe the Requirements document is the
right place to discuss how OWL meets the requirements. Therefore, I do
not plan to add an "OWL approach" section.

*** Discuss WG decision on whether or not to include this in some other
document ***

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

I will replace the first paragraph with:

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

I think this is redundant with sections 3.2 and 3.3.

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

As mentioned earlier, I do not believe the Requirements document is the
right place for this discussion.

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

Again, I do not believe the Requirements document is the right place for
this discussion. 

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

Since this is not a question about the Requirements document, I will
leave it to another WG member to respond to.

> 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 my responses are
satisfactoy.

Jeff

> 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 Monday, 14 July 2003 15:14:01 UTC