- From: Jeff Heflin <heflin@cse.lehigh.edu>
- Date: Thu, 13 Dec 2001 10:41:59 -0500
- To: WebOnt <www-webont-wg@w3.org>
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