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 16:38:16 -0500
Message-ID: <3C152B48.2F84FD51@cse.lehigh.edu>
To: Pat Hayes <phayes@ai.uwf.edu>
CC: Deborah McGuinness <dlm@ksl.stanford.edu>, ned.smith@intel.com, jeremy_carroll@hp.com, 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 terse descriptions in the table, I had assumed that people
could match these back to the documents that Deborah and I sent out
earlier. Details on my list can be found at
http://www.cse.lehigh.edu/~heflin/webont/reqs.html while information
about Deborah's can be found in
Unfortunately the original list was created by Jim from the various use
cases requested as "homework" so I don't think there is a single place
that provides details on all of them. Of course, you may say that some
of what we have is still vague, but that's actually part of our job.

That being said, I'm will to clarify a little bit about what I think
some of these mean. I simply see shared meaning as the requirement that
we have shared ontologies, and that different sources can commit to the
same ontology to express that they share definitions for terms. As for
ontology reusue, I simply see this as the ability to have ontologies
reuse or extend other ontologies. As for ontology evolution, I see this
as dealing more with changing an ontology. For example, if the old
ontology said that "A whale is a fish" then we might want to change the
ontology to fix our mistake. I see this requirement driving the need for
distinguishing between different versions of ontologies and for data
sources to commit to specific versions.

I agree that expressiveness is important, but wonder if that might be
too vague to be useful.


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.
> Sorry, I know we are in a hurry, but I have to ask for clarification.
> Could we have just a word or two about what these very cryptic terms
> are intended to mean? "Shared meaning" for example could mean
> anything from the sociology of semiotics to some language feature for
> referring to a reference ontology, or anything in between.  I have
> trouble seeing the exact intended difference between 'ontology reuse'
> and 'ontology evolution' (presumably, re-use is supposed to mean more
> than just 'use more than once without change', right?).
> I would add simple expressiveness. Seems to me that the most basic
> requirement of any ontology language is expressiveness, and that
> DAML+OIL miserably fails to provide enough of it.  I wonder also if
> issues like being able to convey proofs for subsequent checking, and
> the associated requirement that they stay checkable (one might call
> it monotonicity of verifiability), should be thought of as a
> requirement.
> >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,
> ? How about DAML+OIL, for example?
> >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.
> OK, but what *features* are needed to support this? One might after
> all respond that once ontologies are on web sites and have URIs, all
> this will just kind of happen , pretty much by itself, although in a
> rather disorganized way perhaps.  That is, those ontologies will in
> fact get changed, be re-used, get extended, and so on, much in the
> way that HTML web pages point to one another. What else needs to be
> said or done about this? (Im sure the question has an answer, but Id
> like to see a sketch of what it is :-)
> >  >
> >>  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.
> Doesnt this presuppose a level of security in web transactions that
> does not yet exist? The web provides no way (beyond conventional file
> protection schemes) to even allow anyone to modify information, and
> the only security over viewing is of the all-or-nothing kind embodied
> in https. So what else is there to be said about this topic here?
> >  >
> >>  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.
> >>
> This presupposes that there are clear notions of 'definition'
> available. As far as I can see, neither RDF nor DAML provides such a
> notion, so what do you have in mind here?
> Pat
> --
> ---------------------------------------------------------------------
> IHMC                                    (850)434 8903   home
> 40 South Alcaniz St.                    (850)202 4416   office
> Pensacola,  FL 32501                    (850)202 4440   fax
> phayes@ai.uwf.edu
> http://www.coginst.uwf.edu/~phayes
Received on Monday, 10 December 2001 16:38:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:39 UTC