- From: Jeff Heflin <heflin@cse.lehigh.edu>
- Date: Fri, 18 Jul 2003 10:20:12 -0400
- To: Jim Hendler <hendler@cs.umd.edu>
- CC: webont <www-webont-wg@w3.org>
Jim, This seems fine to me, but I have to minor points: 1) You should probably change "We do not believe the Use Cases and Requirements is the right place for the discussion you desire." to "We do not believe the body of the Use Cases and Requirements is the right place for the discussion you desire." since you have proposed that an appendix regarding this be added 2) at the end of the message, change "Jeff" to "Jeff and Jim" (or "Jim and Jeff", I don't care) Jeff Jim Hendler wrote: > > 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 - if not, please > let us know which things in particular you feel we would need to > change before you would feel comfortable with our moving to Candidate > Recommendation. > 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 one of our > 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> > As mentioned earlier, we do not believe 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 > > 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
Received on Friday, 18 July 2003 10:20:18 UTC