Re: WebOnt General Requirements Subgroup - Initial E-mail

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 McGuinness wrote:
> 
> 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 Friday, 7 December 2001 10:06:09 UTC