- From: Deborah McGuinness <dlm@ksl.stanford.edu>
- Date: Sun, 09 Dec 2001 10:00: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, herman.ter.horst@philips.com, hendler@cs.umd.edu, www-archive@w3.org
sorry for the slow response. in terms of requirements for ontology languages based on use cases, given that we are to come up with things that emerge across many (expected) use cases, i still would claim that the three issues in question below fit. first multi-user issues - i expect many use cases to include: 1- multiple users modifying background ontologies 2 - multiple users viewing background ontologies 3 - multiple users using background ontologies that possibly will be updated given this, i think it is important that there is some support for allowing multiple users to (re)use ontologies that others may change, browse ontologies that are evolving, extend ontologies (that others may be extending), and all of this may need to be done by multiple people simultaneously. second security mgmt - once more than one person is using knowledge that is evolving, it is important to be able to specify who can 1 - view information 2 - modify information also, particularly for govt applications, it becomes important to allow levels of granularity that people (like generals vs. civilians) can see. some levels of specification may be classified about tanks but general information about tanks may be unclassified. third difference and merging - i expect many use cases to include using either an upper level ontology that might need extension or multiple ontologies. given this, it is important to be able to find out how one term definition differs from another definition and also to support putting definitions together. d Jeff Heflin wrote: > Actually, I agree that scalability is a requirement for web ontology > langauge, I just didn't make it very clear in my previous message. What > I was trying to say was that from your requirement #1, I thought > scalability was the only one with impact on the language, while the > other three topics (reliability, availability, and performance) were > more system oriented. In fact, I believe we should make scalability one > of our requirements (of course with the realization that some > requirements may be in conflict with each other and we will have to > strike some balances in the eventual language). > > If you don't mind, I'd like to ask for some clarification on how you > think some of the remaining points carry over. In particular, could you > explain how you would describe > > - security management > - multi-user collaboration > - difference and merging > > in terms of language requirements? Thanks! > > Jeff > > Deborah McGuinness wrote: > > > > 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 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 Sunday, 9 December 2001 12:57:05 UTC