New member of General Requirements subgroup

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.
> > >
Everyone, I'd like to welcome Herman ter Horst to our subgroup. His
e-mail address is herman.ter.horst@philips.com. Please include him on
any future e-mail for the group. If you wish, you can simply use the
address list from this message. Thanks

Jeff

Received on Friday, 7 December 2001 12:05:37 UTC