W3C home > Mailing lists > Public > www-archive@w3.org > December 2001

Re: WebOnt General Requirements Subgroup - Initial E-mail

From: Jeff Heflin <heflin@cse.lehigh.edu>
Date: Mon, 10 Dec 2001 10:58:20 -0500
Message-ID: <3C14DB9C.9409AB4A@cse.lehigh.edu>
To: Deborah McGuinness <dlm@ksl.stanford.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
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. Right now, this indicates that we have 13
requirements. The next step is to decide if we want to collapse two or
more into single requirements. Also, take a hard look and decide if you
think all of these are actual requirements for us. Personally, I think
"ontology-based search" and "ontology querying" might be use cases
instead of requirements, and fairly broad use cases at that. I don't see
how one could create an ontology language that doesn't support search
and querying, so I'm not sure anything is gained by making these
explicit. As always, I'd like to have a group debate on the issue.
Finally, once we've identified what our requirements are, I'd like to
come to agreement on what their names should be. The table above
proposes two and sometimes three different names for the same
requirement. My goal is to have a requirements list by tomorrow, so that
we can begin working on rough drafts of each requirement for our
Thursday telecon.

Jeff

Deborah McGuinness wrote:
> 
> 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
>
Received on Monday, 10 December 2001 10:58:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:15 GMT