General Requirements Subgroup - Progress Report

The General Requirement Subgroup consists of the following individuals:

Jeff Heflin (co-chair)          heflin@cse.lehigh.edu
Deborah McGuinness (co-chair)   dlm@ksl.stanford.edu
Ned Smith                       ned.smith@intel.com
Jeremy Carroll                  jeremy_carroll@hp.com
Pat Hayes                       phayes@ai.uwf.edu
Dan Connolly                    connolly@w3.org
Jos De Roo                      jos.deroo.jd@belgium.agfa.com
Herman ter Horst		herman.ter.horst@philips.com

Our mission is to identify requirements that are either too general to
result from any single use case area or are not directly related to the
existing use cases, but nonetheless important.

We have identified a number of candidate requirements and provided
initial descriptions of them and their related issues. The following six
requirements have broad support from members of the working group.

R1. Shared ontologies
R2. Ontology extension
R6. Scalability
R7. Ease of use
R10. XML Syntax
R14. Expressiveness

The following ten requirements are still under discussion. Some of them
are questioned because their meaning is unclear, others might be out of
scope for the WebOnt effort or too "researchy" for us to expect to
accomplish in the work group.

R3. Ontology evolution
R4. Ontology interoperability
R5. Inconsistency
R8. Data persistence (aka data lifetime)
R9. Security
R11. Internationalization
R12. Ontology-based search
R13. Ontology querying
R15. Proof checking
R16. Trust

Details of each of the requirements are attached at the end of this
message.

Our next step is to come to a final decision on these requirements, in
particular identifying which ones are perhaps more appropriate for other
"layers" of the semantic web. We will then begin fleshing out the
remaining requirements, and in particular determine what influence they
have on language design. The format of our detailed requirements will be
different from that proposed by Guus Schreiber for use cases, since
requirements are fundamentally different from use cases. We are
considering 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?

I will also provide a summary at the telecon today. If you have
questions, concerns, or suggestions, please bring them up during the
telecon, or send them to the mailing list.

Jeff Heflin
Lehigh University

------------------------------------------------------------------------

Candidate Requirements

R1. Shared ontologies
Ontologies are publicly available and different data sources can commit
to the same ontology for shared meaning.

R2. Ontology extension
Ontologies can be extended by other ontologies in order to provide
additional definitions.
Issues:
a) What does this mean? Import all axioms wholesale into new ontology?
Include definitions but don't allow them to be redefined or restricted?
Simply reuse names but not definitions?
b) How does this relate to inheritance?

R3. Ontology evolution
Ontologies can be changed over time and data sources can specify which
version of the ontology they commit to.
Issues:
a) How does this differ from ontology extension (R2)? In R2, the
original ontology is unchanged.
b) Pat believes that this needs a deeper analysis of the meanings of
URIs

R4. Ontology interoperability
Different ontologies may model the same concepts in different ways. The
language should provide primitives for relating different
representations, thus allowing data to be converted to different
ontologies, and enabling a "web of ontologies."
a) This requirement needs to be balanced with scalability (R6).
b) Pat believes this is beyond state of the art.

R5. Inconsistency
Different ontologies may be contradictory, or different data sources may
be contradictory. It should be possible to detect inconsistencies. 
Issues:
a) Since inconsistency will probably be inevitable on the Web, we should
probably also provide means for continuing reasoning in the face of
inconsistency. However there is disagreement about this issue.

R6. Scalability
The language should be able to be used with large ontologies and large
data sets.

R7. Ease of Use
The language should provide a low-learning barrier and have clear
concepts and meaning. The concepts should be independent from syntax.

R8. Data persistence
The Web is constantly changing, so it would be useful to know the
lifetime of information. This will be useful for agents to know when
they must refresh their knowledge bases.
Issues:
a) Should this be specified for a fact in a data source, or for a
property in an ontology?
b) How is this different from R8? Ontologies changes have deeper
repercussions than data source changes, because many sources may depend
on a single ontology for definitions. Furthermore, ontologies change
more slowly than data.
c) Perhaps rename requirement to time validity?

R9. Security
Ability to specify who can view and modify information. Have ontologies
that can specify access control information.
Issues:
a) Web typically doesn't allow update (except via file update) and
viewing web pages is typically all or nothing, so how is this relevant?
b) Some have argued that security is essential and should be seen as a
vertical slice in the "layer cake"
c) Is it possible that future protocols will allow the delivery of parts
of ontologies, to which access control can be applied?

R10. XML syntax
The language should have an XML serialization.
Issues:
a) Must it also build on RDF?

R11. Internationalization
The language should support ontologies in multiple languages.
Issues:
a) Is this already covered by interoperability (R4)? There has been a
suggestion to remove this requirement and mention it as an issue under
R4.
b) Character set issues are already handled by XML

R12. Ontology-based search
Ability to locate information using the ontology to structure queries?
Or is this something else?
Issues:
a) Is this searching for content (information retrieval) or for valid
inferences (logical deduction)?
b) Proposal to define this as "the ontology language offers a semantic 
level of description of information on the Web that allows queries to be 
formulated independently from XML serialization, on the basis of the 
meaning of the information."

R13. Ontology querying
Ability to ask questions about the logical structure of the ontology? Or
is this something else?
Issues:
a) Are R12 and R13 the same requirement? Maybe R12 is information
retrieval and R13 is question answering? There is some support for the
later idea.
b) Is this maybe the need for a standard query language?
c) Need to distinguish between asking questions about the structure of
an ontology and asking questions about what follows from the ontology

R14. Expressiveness
What can be expressed in the language and what reasoning capabilities
should be expected in systems that fully implement it.
Issues:
a) What is the right balance between expressiveness and scalability
(R6)?

R15. Proof checking
Proofs can be described in the language and will be checkable.

R16. Trust
How to determine which information is reliable and/or believable. Must
be able to know the sources of information and to express what
supporting information is needed to believe something.

Received on Thursday, 13 December 2001 10:42:03 UTC