- From: Deborah McGuinness <dlm@ksl.stanford.edu>
- Date: Fri, 07 Dec 2001 09:31:31 -0800
- To: Jeff Heflin <heflin@cse.lehigh.edu>
- CC: ned.smith@intel.com, jeremy_carroll@hp.com, phayes@ai.uwf.edu, connolly@w3.org, jos.deroo.jd@belgium.agfa.com, hendler@cs.umd.edu, www-archive@w3.org
agreed that there was a slightly different slant to that paper but i think at least most (which you pointed out) and actually I would claim all of the points still carry over. you mention not scalability for a web ontology language. i would dispute this - i think if the language can not scale, then we can not use it for representation on the web. the thing i would agree with is that scalability is not a thrust of our work and is almost "motherhood and apple-pie" for any language thus not worth making an issue of. i would add conceptual search to my list. d Jeff Heflin wrote: > Deborah, > > Thanks for the requirements. However, they raise an interesting > question. It appears that your requirements were specifically designed > for an ontology management system, but I believe we were charged to > develop requirements for a web ontology language. Clearly, there is some > overlap, but if our mission is the later, then perhaps not all of your > requirements apply. For example, I believe the following requirements > are too system-oriented: > > 1) reliability, availability and performance (but not scalability!) > 4) security management > 5) multi-user collaboration (I'm not sure how language design can impact > this, except for at the interoperability level) > 6) difference and merging > > I think the following can be cast (perhaps with a little rewriting) as > language requirements: > 1) scalability (but not reliability, availability, or performance) > 2) ease of use (user-friendly) > 3) extensible and flexible knowledge rep. > 7) XML interfaces (perhaps rename as XML syntax?) > 8) internationalization > 9) versioning > > Note that 1,2, and 9 are similar to requirements I mentioned in my > document. > > Of course, I'd like to hear the opinions of the rest of the group before > we proceed with merging the two sets of requirements that we have. > > Jeff > > Deborah McGuinness wrote: > > > > please respond to this message instead of my previous message if you are looking for the > > updated mailing list since this has www-archive@w3.org on the mailing list instead of > > web-archive@w3.org. > > sorry for the typo. > > > > Deborah McGuinness wrote: > > > > > I have used cut and paste to take a synopsis of the requirements for > > > industrial strength ontology mgmt that were presented in the paper. [1] > > > There is additional information in the paper about details of inconsistency > > > checking etc. > > > This paper does not not address search much but I also address > > > ontology-enhanced search in some FindUR papers and in particular in a paper > > > [2] where i discuss conceptual modeling in distributed web environments. > > > > > > [1] > > > http://www.ksl.stanford.edu/people/dlm/papers/ontologyBuilderVerticalNet-abstract.html > > > > > > [2] http://www.ksl.stanford.edu/people/dlm/papers/iccs00-abstract.html > > > > > > synopsis of requirements from paper 1 follow: > > > > > > note to jeff - i added web-archive@w3.org to my to-list. I *think* that > > > meets dan's suggestion of making sure this discussion gets archived. I > > > think we definitely want that property. > > > > > > Deborah > > > > > > 1 Scalability, Availability, Reliability and Performance - These > > > were considered essential for any ontology management solution in the > > > commercial industrial space, both during the development and maintenance > > > phase and the ontology deployment phase. The ontology management solution > > > needed to allow distributed development of large-scale ontologies > > > concurrently and collaboratively by multiple users with a high level of > > > reliability and performance. For the deployment phase, this requirement was > > > considered to be even more important. Applications accessing ontological > > > data need to be up 365x24x7, support thousands of concurrent users, and be > > > both reliable and fast. > > > > > > 2 Ease of Use - The ontology development and maintenance process > > > had to be simple, and the tools usable by ontologists as well as domain > > > experts and business analysts. > > > > > > 3 Extensible and Flexible Knowledge Representation - The knowledge > > > model needed to incorporate the best knowledge representation practices > > > available in the industry and be flexible and extensible enough to easily > > > incorporate new representational features and incorporate and interoperate > > > with different knowledge models such as RDF(S) [2, 15] or DAML [11]/DAML+OIL > > > [8]. > > > > > > 4 Distributed Multi-User Collaboration - Collaboration was seen as > > > a key to knowledge sharing and building. Ontologists, domain experts, and > > > business analysts need a tool that allows them to work collaboratively to > > > create and maintain ontologies even if they work in different geographic > > > locations. > > > > > > 5 Security Management - The system needed to be secure to protect > > > the integrity of the data, prevent unauthorized access, and support multiple > > > access levels. Supporting different levels of access for different types of > > > users would protect the integrity of data while providing an effective means > > > of partitioning tasks and controlling changes. > > > > > > 6 Difference and Merging - Merging facilitates knowledge reuse and > > > sharing by enabling existing knowledge to be easily incorporated into an > > > ontology. The ability to merge ontologies is also needed during the > > > ontology development process to integrate versions created by different > > > individuals into a single, consistent ontology. > > > > > > 7 XML interfaces - Because XML is becoming widely-used for > > > supporting interoperability and sharing information between applications, > > > the ontology solution needed to provide XML interfaces to enable interaction > > > and interoperability with other applications. > > > > > > 8 Internationalization - The World Wide Web enables a global > > > marketplace and e-commerce applications using ontological data have to serve > > > users around the world. The ontology management solution needed to allow > > > users to create ontologies in different languages and support the display or > > > retrieval of ontologies using different locales based on the user?s > > > geographical location. (For example, the transportation ontology would be > > > displayed in Japanese, French, German, or English depending on the > > > geographical locale of the user.) > > > > > > 9 Versioning - Since ontologies continue to change and evolve, a > > > versioning system for ontologies is critical. As an ontology changes over > > > time, applications need to know what version of the ontology they are > > > accessing and how it has changed from one version to another so that they > > > can perform accordingly. (For example, if a supplier?s database is mapped to > > > a particular version of an ontology and the ontology changes, the database > > > needs to be remapped to the updated ontology, either manually or using an > > > automated tool.) > > > > > > Jeff Heflin wrote: > > > > > > > Welcome to the subgroup on General Requirements (formerly called > > > > technical issues or cross-cutting issues) for WebOnt. I have gotten your > > > > names from today's telecon, but if you do not wish to participate, > > > > please let me know and I'll remove you from the list. > > > > > > > > Just to review, the purpose of this group is to prepare a document that > > > > describes in detail the requirements for a web ontology language that > > > > may result from multiple use cases. We are expected to have a draft of > > > > this document ready in time for the telecon on Thursday, Dec. 13. > > > > > > > > Jim's original list included the following requirements for us to > > > > consider: > > > > - versioning > > > > - ontology-based search > > > > - domain-mapping/ ontology linking > > > > - ontology querying > > > > - rapid creation of large ontologies > > > > - inconsistency/contradiction (added as a result of mailing list > > > > discussion) > > > > > > > > Given this as a starting point, I'd like to solicit feedback on the > > > > following issues: > > > > > > > > 1) Is the name "General Requirements" appropriate? Do we prefer > > > > something else? Perhaps "Core Requirements?" Other suggestions? > > > > > > > > 2) How should we proceed? I recommend that Deborah and I merge our > > > > initial requirements and then present these to the rest of the group as > > > > a straw man. For those interested, my initial sketch of requirements for > > > > a Web Ont language can be found at > > > > http://www.cse.lehigh.edu/~heflin/webont/reqs.html > > > > > > > > 3) What format should the detailed requirements take? Guus Schreiber's > > > > suggestion for Use Case format doesn't fit, since we are describing > > > > requirements. I propose the following format: > > > > > > > > ---------------------------------------------------------------------- > > > > REQUIREMENT: > > > > A short name for the requirement > > > > > > > > SUPPORTED TASKS: > > > > Which use cases (or classes of use cases) will benefit from this > > > > requirement? > > > > > > > > JUSTIFICATION: > > > > Why is the requirement important? What will it achieve? > > > > > > > > POSSIBLE APPROACH: > > > > How might our language design satisfy or support the requirement? > > > > ---------------------------------------------------------------------- > > > > > > > > Please respond to these issues as soon as possible, since we have a > > > > pretty short turn-around time. I look forward to working closely with > > > > all of you. > > > > > > > > Jeff > > > > > > -- > > > Deborah L. McGuinness > > > Knowledge Systems Laboratory > > > Gates Computer Science Building, 2A Room 241 > > > Stanford University, Stanford, CA 94305-9020 > > > email: dlm@ksl.stanford.edu > > > URL: http://ksl.stanford.edu/people/dlm > > > (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 > > > 705 0941 > > > > -- > > Deborah L. McGuinness > > Knowledge Systems Laboratory > > Gates Computer Science Building, 2A Room 241 > > Stanford University, Stanford, CA 94305-9020 > > email: dlm@ksl.stanford.edu > > URL: http://ksl.stanford.edu/people/dlm > > (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 705 0941 -- Deborah L. McGuinness Knowledge Systems Laboratory Gates Computer Science Building, 2A Room 241 Stanford University, Stanford, CA 94305-9020 email: dlm@ksl.stanford.edu URL: http://ksl.stanford.edu/people/dlm (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 705 0941
Received on Friday, 7 December 2001 12:27:50 UTC