- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Fri, 18 Jul 2003 10:31:33 -0400
- To: Jeff Heflin <heflin@cse.lehigh.edu>
- Cc: webont <www-webont-wg@w3.org>
At 10:20 AM -0400 7/18/03, Jeff Heflin wrote: >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 > good points - I'll make these changes. -JH >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 -- 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:31:43 UTC