Re: WebOnt General Requirements Subgroup - Initial E-mail

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

Received on Thursday, 6 December 2001 15:22:06 UTC