- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 10 Dec 2001 15:20:21 -0600
- To: Pat Hayes <phayes@ai.uwf.edu>
- CC: Jeff Heflin <heflin@cse.lehigh.edu>, Deborah McGuinness <dlm@ksl.stanford.edu>, ned.smith@intel.com, jeremy_carroll@hp.com, jos.deroo.jd@belgium.agfa.com, herman.ter.horst@philips.com, hendler@cs.umd.edu, www-archive@w3.org
Pat Hayes wrote: > > >Deborah, > > > >Thanks, your arguments have convinced me. In fact, I now think the > >multi-user issues and difference and merging are closely related to > >requirements I had listed. > > > >Everyone, I think it would be helpful if we can try to identify how the > >various candidate requirements (original list from Jim, Deborah's list, > >my list) are related. Here is my first cut at such a mapping: > > > >Jeff's Deborah's Original list > >------------------- -------------------- ------------------- > >shared meaning multi-user > >ontology reuse extensible > >ontology evolution versioning versioning > >interoperability diff and merge domain mapping > >inconsistency inconsistency > >scalability scalability large ontologies > >user-friendly ease of use > >data persistence > > security > > XML interfaces > > internationalization > > ontology-based search > > ontology querying > > > >Although this table only shows Deborah's "multiple users" requirement > >mapped to my "shared meaning" requirement, I think it also maps to my > >"ontology reuse" and "ontology evolution" requirements. > > > >Everyone, I'd like you to look at this table and decide if you agree > >with my mappings. That's a lot of stuff. Do I agree that "security" is a requirement? er... in some form, yes, of course. I have a couple/three suggestions: (1) make sure the requirements are testable. how do you do that? (2) make sure the requirements are connected to use cases, so that if we don't meet requirement R6, it's clear that we won't be able to deal with use cases UC4 and UC7, say. and how do we do all that with so little time? (3) shoot for the intersection of everybody's requirements, not the union. Shoot for things that *the group* will agree are requirements; i.e. things that if our language doesn't meet them, the group will agree that we're not done. If we end up with things that seem important but aren't really agreed as requirements, I'd suggest listing them as goals or something. Coming back from the meta-discussion... About inconsistency... I'm happy with a requirement that our language should (a) have the ability to express inconsistent facts (e.g. using disjoint) and (b) the specification should have clear semantics for what's an inconsistency and what's not, but I don't want to go as far as (c) that it be straightforward, computationally, to determine, given any two expressions in our language, whether they're consistent. i.e. the sort of use cases I have in mind for a requirement about inconsistencies are, for example, catching common ontology-design errors (flag empty classes, flag empty classes that have things in them ;-), or well-known errors in the use of some ontology, like perhaps units mismatches in a space-ship-parts ontology. But I don't have any use cases that motivate a general decidability requirement. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 10 December 2001 16:21:49 UTC