Presentation on theme: "OWL General Goals and Requirements W3C Face to Face Web Ontology Meeting January 2002 Murray Hill, NJ Jeff Heflin and Deborah McGuinness."— Presentation transcript:
OWL General Goals and Requirements W3C Face to Face Web Ontology Meeting January 2002 Murray Hill, NJ Jeff Heflin and Deborah McGuinness
Committee + F2F Input Jeff Heflin (co-chair) Deborah McGuinness (co-chair) Jeremy Carroll Dan Connolly Jos De Roo Pay Hayes Ned Smith Herman ter Horst Dieter Fensel Ziv Hellman Jim Hendler Ian Horrocks Libby Miller Laurent Olivry Peter Patel-Schneider
Format Name and number Supported tasks –What does requirement allow us to do? Justification –Why is this requirement needed? Possible approach –How can the language support the requirement? DAML support –To what extent does DAML+OIL support it?
What is a Requirement? Possible criteria –if we dont meet it, we arent done – Dan C. –must result in language primitives –must be implemented in all OWL systems? –appropriate for the ontology layer of the Semantic Web? –critical for some very important use cases? –… Some of these are debatable!
R1. Shared Ontologies Ontologies are publicly available (at least read only (possibly read- write later)) and different data sources can commit to the same ontology for shared meaning. Requirements –Unambiguous term referencing (Use URIs to name terms; some debate on whether the URI is unique) –Commitment to (portions of) ontologies needs to be stateable (possibly through imports with better documentation) –A solution to tagging/grouping problem for term definitions (this may be a syntactic solution; could be a new page published in byte-size chunk) Possible Approach/issues: –Question about whether one can use a term from an ontology without agreeing to ALL terms in that ontology and possibly ALL terms in ontologies imported by that ontology –Syntax for defining ontologies –Syntax for committing to ontologies –Syntax for disambiguating terms from different ontologies –Sharing by reference or by value –Imports may be a solution but not necessarily THE soln.
R2. Ontology Extension Ontologies can be extended by other ontologies in order to provide additional definitions Possible Approach: –Explicit representation of extension Dolphin FishMammal Flipper subClassOf type good-schema bad-schema orig-schema my-doc Multiple Schemas in RDF
R3. Ontology Evolution Ontologies can be changed over time and data sources can specify which version of the ontology they commit to Possible Approach: –Revisions are separate documents –Explicit links to prior versions –Explicit backwards- compatibility –Deprecation of terms Dolphin Fish Mammal subClassOf subClassOf? schema-v1 schema-v2 Revision in RDF
Ontology evolution Requirements – –Language features that specify a recommended way of relating different versions of ontologies (these may be mostly extralogical) Issues/Actions **Get heflins 3ish requirements for software mgmt. –Backwards compatibility –… Should we consider this JUST documentation or can you infer anything Granularity of evolution – may be on a per term basis/per document Action – laurent will send mail with his experiences and their view-based solutions
R4. Ontology Interoperability Different ontologies may model the same concepts in different ways Requirements – delegate to leos interoperability group Possible Approach: –primitives for mapping –consider some of (but not all) the following subclass/superclass inverses equivalence implication, arithmetic, aggregation, string manipulation, procedural attachments?
R5. Detect Inconsistency Different ontologies or data sources may be contradictory Requirements – –Decidability discussion later Possible Approach: –allow language to express inconsistency –theory supports efficient detection of inconsistency –provide mechanism for reporting inconsistencies
R6. Scalability Language can be used with large ontologies and large data sets Requirements – –Results influenced by decidability discussion Issues –** This may rule out some language features –** Implicit closed world assumptions need to be made explicit and should NOT be language features – reference classic experience –Dan C says it could be a language feature; discussion about ordering of the statement and time of processing of the statement Must balance with R10. Expressiveness Possible Approach: –restrict language for efficient reasoning description logic datalog
R7. Ease of Use Language should provide a low learning barrier and have clear concepts and meaning Requirement Issues/discussion –presentation syntax –Agreement concerning daml+oil unpleasant syntax Possible Approach: –When possible, use concepts and idioms familiar to average software engineers object-oriented? relational databases?
R8. XML Syntax The language should have an XML serialization Open Issue: –Must the language also build on RDF/RDFS? In favor of RDF –W3C standard –Existing software support Against RDF –Does not have same acceptance as XML –Led to an awkward syntax for DAML+OIL
R9. Ontology-based Search Search that exploits the meaning of terms instead of just the syntax Issues – needs new name R0? – Ontologies include term definitions, Possible Approach: –use background ontologies for: query expansion understanding of term relationships identify parameters and value restrictions
R10. Expressiveness The language should be as expressive as possible, given a balance with R6. Scalability Should probably combine this with R6 for: –Balance of Expressiveness and Scalability
Internationalization (elevated to goal) Definition by use Case– develop multi-lingually, presentation in the language of each user (thus presentation in many languages where language is chosen by user) Requirements –Character Model Character set support (from XML unicode) Uniqueness of unicode strings (unicode normal form c solution from w3c internationalization group c cedilla – jeremy provides details) –Localized display of an ontology (display ontology in language foreign to viewer) URI is a bit string (not human text) yet terms from an ontology need to be displayed in localized terms. RDFS label is a proposal – it *MAY* solve the problem Potential issues possible representation/structure changes based on language of presentation (possible reclassification - things are surgical procedures in UK but not viewed as such in say France) Multilingual search / various query languages/ real translation
Other candidates (Open Issues) C1. Explainability - got support from floor of meeting C3. Ontology querying C4. Tagging C5. Proof checking C6. Security C7. Trust C8. Data persistence *c2 internationalization elevated to goal