Re: WebOnt General Requirements Subgroup - Initial E-mail

agreed that there was a slightly different slant to that paper but i think at least most
(which you pointed out) and actually I would claim all of the points still carry over.
you mention not scalability for a web ontology language.  i would dispute this - i think if
the language can not scale, then we can not use it for representation on the web.   the thing
i would agree with is that scalability is not a thrust of our work and is almost "motherhood
and apple-pie" for any language  thus not worth making an issue of.

i would add conceptual search to my list.

d

Jeff Heflin wrote:

> 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

--
 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 12:27:50 UTC