OWL-based reasoning with retractable inference

Transcription

1 OWL-based reasoning with retractable inference Carlo Jelmini and Stéphane Marchand-Maillet Viper Group CVML University of Geneva 1211 Geneva 4 Switzerland {jelmini, marchand}@cui.unige.ch Abstract As a solution to maintain, process and enrich knowledge in the multimedia description framework we are constructing, we propose a forward chaining knowledge base and reasoning engine, supporting RDF documents and OWL Lite ontologies, with the ability to perform non-monotonic, retractable inference. Within our framework, the knowledge over the media collection can be collected in several ways. As we cannot wait for the system to reach an hypothetical state where full knowledge is available, the system has to be able to reason over incomplete knowledge and produce tentative conclusions. As more knowledge is collected over the collection, some of the conclusions need to be retracted from the knowledge base and other conclusions inferred. Introduction Content-Based Retrieval (CBR) systems aim at helping users to manage large collections of multimedia documents. By automated inspection of their content, CBR systems target document classification and should respond accurately to queries. While visual document retrieval and classification can be achieved up to some degree, careful inspection of results show that no technique can yet provide satisfactory results for the common end-user. The main reason of this failure is that the CBR community has not yet been successful at bridging the semantic gap, i.e. the discrepancy between automated low-level content characterization and high-level semantic interpretation of this content (Marchand-Maillet & Bruno, 2004; Smeulders et al., 2000). One of the main research directions is currently in knowledge-enhanced indexing and retrieval, by using domain ontologies and reasoning to help bridging the gap. An ontology is a consensual and formal description of the concepts and relations in a domain, that help human communication and allows to achieve shared understanding. The OWL Ontology Web Language 1 is a language for defining and instantiating Web ontologies. An OWL ontology may include descriptions of classes, properties and their instances. Given such an ontology, the OWL formal semantics specifies how to derive its logical consequences, i.e. facts not literally present in the ontology, but inferred from the semantics. OWL has just reached W3C Recommandation status and will gain more and more support by the Semantic Web community. In this paper, we propose a dynamic reasoning engine supporting the OWL Ontology Web Language. Inference is accomplished through a forward chaining production system that automatically generates the new facts inferred by the semantics of the OWL, RDF and XSD specifications. It supports non-monotonic reasoning as the ability to draw tentative conclusions from available facts and then possibly retract them as the knowledge evolves. Our reasoning engine has been designed to be efficient (inference is performed in real time), dynamic (can cope with evolving knowledge) and flexible (can be easily extended and embedded). 1

2 Reviewing related work, other reasoning engines supporting OWL or DAML+OIL can be found. They can be divided into three categories: Description logics classifiers: OWL DL has been designed to be equivalent to a Description Logics(Baader et al., 2003) language, called SHIQ(D+). Some existing DL reasoners add OWL support simply by translating the OWL definitions into their supported DL. The FaCT (Horrocks, 1999) and RACER (Haarslev & Möller, 2001) reasoners fall into this category. They both are efficient DL reasoners using the tableaux algorithms. However, dynamic online reasoning is not possible or not practical with current DL reasoners. Theorem provers: These systems are designed to prove theorems stated in first-order logic. This involves translating an OWL ontology into a collection of axioms suitable for a first order prover. Class references are translated to unary predicates and properties are translated to binary predicates. The Surnia and JTP provers are members of this category. Again, these systems are not well suited for dynamic online reasoning, as they cannot deal directly with the RDF/OWL model, but only on a translation of it. Rule-based engines: DAMLJessKB and Triple (Sintek & Decker, 2002) are members of this category. Most of the rule engines are based on the logic programming paradigm, thus using Horn rules or derivatives. These rule-based engines are therefore not expressive enough to capture the full semantics of even OWL Lite. However, DAMLJessKB benefits from the power of the Jess rule language and does not suffer these limitations. Moreover, rule-based engines are well-suited for dynamic environments as they reason directly within the RDF/OWL model. DAMLJessKB was close to the engine we need for our framework. Unfortunately, it has severe limitations that prevents its use in our context, namely the absence of direct support for real-time reasoning. This motivated the development of our own engine, the Semantic Web Knowledge Base (SWKB). Our engine concretizes into a library with a modern object-oriented Java API allowing to assert, retract, access and query facts in the knowledge base. It features also namespace prefixes, RDF serialization and rule logging. It is currently embedded into an ontology-based annotation tool for image collections. Its implementation is built on top of Jess, a Java forward chaining knowledge base using an efficient RETE-derived algorithm. Our design adds all the necessary mechanisms to deal with OWL semantics, mainly implemented by a set of carefully designed facts and rules. RDF/S semantics The RDF/S layer is implemented with facts and rules defining the vocabulary and semantics as in (Brickley & Guha, 2003) and (Hayes, 2003). The underlying structure of any expression in RDF is a collection of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph. Each triple represents a statement of a relationship between the things denoted by the nodes that it links. The assertion of an RDF triple says that some relationship, indicated by the predicate, holds between the items denoted by the subject and the object of the triple. The assertion of an RDF graph amounts to asserting all the triples in it, so the meaning of an RDF graph is the conjunction (logical AND) of the statements corresponding to all the triples it contains. A formal account of the meaning of RDF graphs is given in (Hayes, 2003). In our engine, a RDF triple is defined internally as follows: (deftemplate Triple "RDF triple container" (slot subj) (slot pred) (slot obj) (slot source (default SWKB)))

3 The Triple template (the class of all triple facts) contains four slots. The subj, pred, obj slots follow from the previous definition of a RDF triple and the source slot allows our engine to remember the origin of a triple (from user, document, ontology, or inferred). RDF triples can then be asserted in the knowledge base under the form: (Triple (subj <subject>) (pred <predicate>) (obj <object>) (src <source>)) All the information is thus stored as triples, including some implementation details concerning the management of literals, RDF lists and anonymous resources. For example, the rdfs:datatype class is defined as follow: (Triple (subj rdfs:datatype) (pred rdf:type) (obj rdfs:class)) (Triple (subj rdfs:datatype) (pred rdfs:subclassof) (obj rdfs:class)) From its specification, rdfs:datatype is both an instance of and a subclass of rdfs:class. Asserting such static facts about the vocabulary is not sufficient, though. The semantics need to be enforced with dynamic rules capable of producing the necessary entailments. Basic rules In RDF/S, the rdfs:subclassof and rdfs:subpropertyof properties are transitive. By example, the rule implementing transitive subclassing is given as: (defrule subclassof-transitivity (Triple (subj?x) (pred rdfs:subclassof) (obj?y)) (Triple (subj?y) (pred rdfs:subclassof) (obj?z)) => (assert (Triple (subj?x) (pred rdfs:subclassof) (obj?z)))) Additionally, the rdfs:subclassof property implies that instances of the child class are also instances of the parent class. This entailment is implemented with the following rule: (defrule instance-subclassof-typing (Triple (subj?class) (pred rdfs:subclassof) (obj?parent)) (Triple (subj?instance) (pred rdf:type) (obj?class)) => (assert (Triple (subj?instance) (pred rdf:type) (obj?parent)))) So that if (Dog rdfs:subclassof Animal) and (dogbert rdf:type Dog), then (dogbert rdf:type Animal). Similarly, the property rdfs:subpropertyof is a rdf:property used to state that all resources related by the child property are also related by the parent property. This is given by the rule: (defrule subproperty-entailement (Triple (subj?prop) (pred rdfs:subpropertyof) (obj?parent)) (Triple (subj?subj) (pred?prop) (obj?obj)) => (assert (Triple (subj?subj) (pred?parent) (obj?obj)))) So that, if (fatherof rdfs:subpropertyof relativeof) and (Phil fatherof James), then (Phil relativeof James).

4 Domain and range typing rules The rdf:domain property is used to assign a domain to another property, specifying that only instances of the domain class may appear within a triple as a subject of this property. Many would make the assumption, based on their expertise with traditional programming languages, that if an instance has been asserted as the subject for such a constrained property, but is not a member of the domain, then there is an error in the data. In fact, the actual inference in such a situation is that if an instance, not otherwise of the domain, has been explicitly asserted as the subject for the constrained property, then it is actually a member of the domain (Kopena & Regli, 2003). The same holds for rdf:range property. The domain typing rule is implemented as follows: (defrule domain-typing (Triple (subj?pred) (pred rdfs:domain) (obj?class)) (Triple (subj?instance) (pred?pred) (obj?obj)) => (assert (Triple (subj?instance) (pred rdf:type) (obj?class)))) Note that using OWL DL and Full, it is possible to enforce type-checking semantics by defining disjoint classes, so that it would be an inconsistency if an instance belong to disjoint domains. rdf:list augmented implementation The rdf:list classes and properties describe a closed collection, i.e. one that cannot have anymore members. As OWL uses rdf:list to describe collections, several rules implementing the OWL semantics need to test the list content. However, its representation is not well-suited to check lists for membership. Hence our engine implements an augmented representation with this feature. Lists are traversed and for each element a triple of the form (<list> swkb:item <element>) is asserted. Checking for membership is then possible by just looking for the presence of this kind of triples in the knowledge base. Blank nodes The RDF specification allows for blank nodes, or anonymous resources. A blank node is one that is not a URI reference or a literal. Within our framework, blank nodes are skolemized by assigning them a unique internal identifier for easy reference. To distinguish between named resources and blank nodes, the latter are identified by setting them as instances of the swkb:anonymous class. In theory, this could be exploited to incorporate some amount of reasoning about the existential nature of these nodes, as per the RDF specification. This marking also proves useful in practice for doing such things as determining the relative importance of the object to the ontology designer or input source. For example, when generating class diagrams, anonymous classes may be removed to reduce clutter as they are typically simply a means to the end of describing another class (Kopena & Regli, 2003). RDF Literals and Literal Datatypes Literals are used to identify values such as numbers and dates via a lexical representation. Anything represented by a literal could also be represented by a URI, but it is often more convenient or intuitive to use literals. A literal may be the object of an RDF triple, but not its subject or predicate. Literals may be plain or typed. A plain literal is a string combined with an optional language tag. This may be used for plain text in a natural language. A typed literal is a string combined with a datatype URI. It denotes the member of the identified datatype value space obtained by applying the lexical-to-value mapping to the literal string. Datatypes

5 are used by RDF in the representation of values such as integers, floating point numbers and dates. A datatype consists of a lexical space, a value space and a lexical-to-value mapping. The lexical space of a datatype is a set of Unicode strings. There is no built-in concept of numbers or dates or other common values. Rather, RDF defers to datatypes that are defined separately in the XML Schema datatypes specification (Biron & Malhotra, 2001), and identified with URI references. In our framework, literals are implemented internally as blank nodes of type rdf:literal 2. Even if strictly speaking, RDF literals cannot appear as subjects of triples, we permit this in the following restricted cases (i) storing the actual literal value: (_:lit1 swkb:value "34.5") (ii) setting the datatype: (_:lit1 rdf:type xsd:decimal) (iii) setting the language: tag (_:lit2 swkb:lang en). The swkb:value and swkb:lang properties are part of our literal implementation. Their application domain is restricted to rdf:literals. Some XSD Datatypes are already predefined in our engine (e.g. xsd:string, xsd:integer and its derived datatypes, etc). Definition of new datatypes is possible through a simple API provided by the abstract class DatatypeSupport. An implementation of DatatypeSupport must return the canonical representation of each value in the lexical space 3. Only the canonical value is then used in the knowledge base to ensure the uniqueness of the literal object. Our engine also provides datatype subsumption and literal classification for datatypes defined using the xsd:mininclusive and xsd:maxinclusive facets. OWL Lite semantics OWL Lite was designed for easy implementation and to provide users with a functional subset that will get them started in the use of OWL (Bechhofer et al., 2003). It does not have the expressive power of OWL DL, but it is sufficient for many real applications. With respect to OWL DL, OWL Lite forbids the use of the owl:oneof, owl:unionof, owl:complementof, owl:hasvalue, owl:disjointwith and owl:datarange constructs and requires the use of named classes or restrictions in class descriptions. The language constructs of OWL Lite provide the basics for subclass hierarchy construction: subclasses and property restrictions. In addition, OWL Lite allows properties to be made optional or required. These restrictions place OWL Lite at a lower complexity level than that of OWL DL. This has a positive impact on the efficiency of complete reasoners for OWL Lite. The OWL Lite layer is implemented with facts and rules defining the vocabulary and semantics as in (Bechhofer et al., 2003) and (Patel-Schneider, Hayes, & Horrocks, 2003). Several rules enforce the syntax and the semantics associated to these concepts. Entailment rules produce the facts entailed by the semantics. Similarly, syntax checking rules ensure that some constructs are correctly formed. Finally, inconsistency checking rules detect contradictions between facts in the knowledge base. Intersection rules Class descriptions in OWL Lite can only use the rdfs:subclassof and owl:intersectionof properties. The rdfs:subclassof semantics is already enforced by the RDF/S rules. The owl:intersectionof is used for necessary and sufficient descriptions of classes. This means that we need two rules, for the direct and the reverse implications (note that some of the reverse implications are valid only under a closed world assumption). Here is the direct implication rule for owl:intersectionof: (defrule intersectionof-implication 2 see for reasons allowing this representation. 3 see for a definition of canonical representation.

6 (Triple (subj?class) (pred owl:intersectionof) (obj?list)) (Triple (subj?list) (pred swkb:item) (obj?class2 => (assert (Triple (subj?class) (pred rdfs:subclassof) (obj?class2)))) It states that, given the following OWL class description: <owl:class rdf:id="whitewine"> <owl:intersectionof rdf:parsetype="collection"> <owl:class rdf:about="#wine" /> <owl:class rdf:about="#whitething" /> </owl:intersectionof> </owl:class> then the WhiteWine class is a subclass of all the members of the intersection list, i.e. Wine and WhiteThing in the example (note the use of our augmented rdf:list implementation to easily find members of the intersection list). The reverse implication for owl:intersectionof implies that an individual, which is an instance of exactly all the members of the intersection list, is an instance of the defined class. So, an individual of type Wine and WhiteThing must be a classified as a WhiteWine. (defrule intersectionof-reverse-implication (Triple (subj?rootclass) (pred owl:intersectionof) (obj?list)) (Triple (subj?list) (pred swkb:item) (obj?class)) (Triple (subj?instance) (pred rdf:type) (obj?class)) (not (and (Triple (subj?list) (pred swkb:item) (obj?anotherclass)) (not (Triple (subj?instance) (pred rdf:type) (obj?anotherclass))))) => (assert (Triple (subj?instance) (pred rdf:type) (obj?rootclass)))) This rule contains a (not (and (...) (not (...)))) pattern, that corresponds to the universal quantifier. It translates to It is not true that there is a class in the list, and the individual is not an instance of it. Additionally, a subsumption rule is defined to cope with subclass relationships between classes defined with owl:intersectionof. If all classes in an intersection list A are rdfs:subclassof the classes in an intersection list B, then A rdfs:subclassof B. (defrule intersectionof-subsumption (Triple (subj?supclass) (pred owl:intersectionof) (obj?suplist)) (Triple (subj?subclass&~?supclass) (pred owl:intersectionof) (obj?sublist)) (not (and (Triple (subj?suplist) (pred swkb:item) (obj?class)) (not (or (Triple (subj?sublist) (pred swkb:item) (obj?class)) (and (Triple (subj?sublist) (pred swkb:item) (obj?othclass)) (Triple (subj?othclass) (pred rdfs:subclassof) (obj?class))))))) => (assert (Triple (subj?subclass) (pred rdfs:subclassof) (obj?supclass)))) This rule fires if there is two different classes described by owl:intersectionof and, for all classes in one list, the classes in the other list are either the same class or a subclass. Restriction rules Another important concept used in class descriptions is the owl:restriction class. Restrictions allow to define precisely the characteristics necessarily attached to a class. Restrictions apply one

7 constraint to exactly one property. The owl:onproperty element indicates the restricted property, and the constraints are specified with one of the following properties: owl:somevaluesfrom, owl:allvaluesfrom, owl:cardinality, owl:mincardinality and owl:maxcardinality. For each of these constraints there are two corresponding rules, for direct and reverse implication. Also some rules check that restrictions are correctly formed, i.e. that there is only one owl:onproperty statement and only one constraint defined for a restriction. Similarly, some rules check for statements not allowed by OWL Lite: the owl:hasvalue constraint in restrictions is forbidden, and the only valid values for cardinality constraints are 0 and 1. The owl:allvaluesfrom and owl:somevaluesfrom constraints are similar to the universal and the existential quantification, respectively. The owl:allvaluesfrom constraint requires that for every instance of the class that has instances of the specified property, the values of the property are all members of the class indicated by the owl:allvaluesfrom clause. This implies that if (ParentWithDaughtersOnly owl:onproperty haschild) and (ParentWithDaughtersOnly owl:allvaluesfrom Female), and the knowledge base contains the facts (Philippe rdf:type ParentWithDaughtersOnly) and (Philippe haschild Suzanne) then it will be inferred that Suzanne must be female. The reverse implication rule, on the other hand, will classify an individual with female-only children as a member of the ParentWithDaughtersOnly class. The owl:somevaluesfrom constraint requires that for every instance of the class that has instances of the specified property, at least one value of the property is a member of the class indicated by the owl:somevaluesfrom clause. This implies that if we have the following restriction: (ParentWithDaughters owl:onproperty haschild) and (ParentWithDaughters owl:somevaluesfrom Female), and in the knowledge base there is an individual of type ParentWithDaughters, then our engine will infer that this individual must have a daughter. It will then create an anonymous Female resource and state it as the individual s daughter. The reverse implication rule, on the other hand, will classify an individual with at least one daughter as a member of the ParentWithDaughters class. The cardinality constraints require that for every instance of the restricted class, there is at least owl:mincardinality instances of the specified property, and at most owl:maxcardinality instances. The owl:cardinality constraint is in fact redundant as it can always be replaced by a pair of matching owl:mincardinality and owl:maxcardinality constraints with the same value, and this is the way it is actually implemented in our framework. Property characteristics rules In OWL Lite, it is possible to specify characteristics for a property, which provides a powerful mechanism for enhanced reasoning about a property. Properties can be transitive, symmetric, functional and inverse functional. A property can also be defined as the inverse of another. The case of symmetric and transitive properties (instances of owl:symmetricproperty and owl:transitiveproperty, respectively) is straightforward. An inverse property is defined using the owl:inverseof property. The rule enforces for example that if the hasmother property is the inverse of the motherof property, then (Philippe hasmother Suzanne) implies that (Suzanne motherof Philippe), and vice versa. A functional property is an instance of owl:functionalproperty, meaning that it can take at most one value. If the hasmother property is functional then the facts (Philippe hasmother Suzanne) and (Philippe hasmother Sissi) imply that (Suzanne owl:sameindividualas Sissi). If Suzanne and Sissi were previously known to be different individuals (with the owl:differentfrom property), our engine will throw an inconsistency error. Similarly, an inverse functional property is an instance of owl:inversefunctionalproperty, meaning that the inverse of the property denotes exactly one value.

8 Identity and equivalence rules The OWL model does not have a unique name assumption. Just because two names are different does not mean that they refer to different individuals. Therefore their identity or difference has to be stated explicitly, or inferred in some other way, as with the functional properties seen above. To explicitly declare that two names denote the same individual, the owl:sameindividualas (or the equivalent owl:sameas) symmetric property is used. An internal rule ensures that attributes defined using one name will be applied to the other name, and vice versa. Conversely, to explicitly declare two names as denoting different individuals, the owl:differentfrom symmetric property is used. OWL offers a convenient mechanism to define a set of mutually distinct individuals. The following asserts that Philippe, Suzanne, and Jacques are pairwise distinct: <owl:alldifferent> <owl:distinctmembers rdf:parsetype="collection"> <Person rdf:about="#philippe" /> <Person rdf:about="#suzanne" /> <Person rdf:about="#jacques" /> </owl:distinctmembers> </owl:alldifferent> Our engine will therefore generate all the necessary owl:differentfrom statements implied by this definition. To tie together a set of component ontologies as part of another, it is frequently useful to be able to indicate that a particular class or property in one ontology is equivalent to a class or property in a second ontology. The owl:equivalentclass and owl:equivalentproperty properties serve this purpose. Non-monotonic reasoning The main design decision influencing the design of our engine is its expected ability to cope with evolving knowledge in a dynamic environment. We are working in a content description framework where the knowledge over the media collection can be collected in several ways (mainly from user interaction or other strategies) during his online lifespan (Marchand-Maillet & Bruno, 2004). We cannot wait for the system to reach an hypothetical state where full knowledge is available: the system has to be able to reason over incomplete knowledge and produce tentative conclusions. As more knowledge is collected over the collection, some of these conclusions need to be retracted from the knowledge base and other conclusions inferred. When a user enters a query about flying animals, a knowledge-based system could return images of penguins, as birds usually fly. When more knowledge about penguins is injected in the system, saying in particular that penguins cannot fly, the system would be able to answer with higher precision to the query. Such ability is called non-monotonic reasoning because the set of conclusions warranted on the basis of a given knowledge base does not increase (in fact, it can shrink) with the size of the knowledge base itself. This is in contrast to classical (first-order) logic, whose inferences, being deductively valid, can never be undone by new information. In our framework, we have implemented the concept of retractable reasoning whereby an inferred fact relies on the facts that brought it to life. If one of this facts is later retracted from the knowledge base, the dependent fact will be retracted as well. Note that inference can be done on the absence of a given fact, so the assertion of a fact in the knowledge base can result in the retraction of conclusions based on its absence. This leads us to another design choice of our engine. It is built around a closed world assumption. If a fact is not present in the knowledge base, it is assumed to be false (following the

9 negation as failure rule). Our non-monotonic implementation relies on closed world assumption, as the retraction of a fact will be considered as asserting it false. However, OWL relies on the open world assumption, where the additional state of unknown is available. Therefore negation cannot be computed by simply using the complement and all facts have to be proven either true or false. Our closed world assumption has both positives and negatives consequences. Some inferences may seem unfounded as they do not follow the exact RDF and OWL semantics. However, a closed world is often a reasonable assumption in practice: one can ask and answer many practical questions under the assumption that applications using our engine will include all required data for making the needed inferences. If data is unknown, the external application can find out its value and assert it. Indeed, we believe that many real world Semantic Web-related applications will have to follow similar assumptions to be viable (Kopena & Regli, 2003). Retractable reasoning is implemented using the Jess logical conditional element in the antecedent of a rule. The logical conditional element lets one specify logical dependencies among facts. All the facts asserted on the antecedent of a rule thus become dependent on the matches to the logical patterns on the consequence of that rule. If any of the matches later become invalid, the dependent facts are retracted automatically. A fact may receive logical support from multiple sources, i.e. it may be asserted multiple times with a different set of logical supports each time. Such a fact is not automatically retracted unless each of its logical supports is removed. If a fact is asserted without explicit logical support, it is said to be unconditionally supported. If an unconditionally supported fact also receives explicit logical support, removing that support will not cause the fact to be retracted (Friedman-Hill, 2003). The following example shows the rule implementing the reverse implication for the owl:allvaluesfrom constraint: (defrule allvaluesfrom-restriction-reverse-implication (logical (Triple (subj?restriction) (pred owl:allvaluesfrom) (obj?class)) (Triple (subj?restriction) (pred owl:onproperty) (obj?property)) (Triple (subj?instance) (pred?property)) (not (and (Triple (subj?instance) (pred?property) (obj?obj)) (not (Triple (subj?obj) (pred rdf:type) (obj?class)))))) => (assert (Triple (subj?instance) (pred rdf:type) (obj?restriction)))) This rule will fire if an individual is found to always be linked by a restricted property to a value of the type specified by owl:allvaluesfrom. Referring to a previous example, this rule will classify an individual with female-only children as a member of the ParentWithDaughtersOnly class. If this individual later has a male child, this conclusion cannot hold any longer and will be retracted. Note that a fact can be dependent on the non-existence of another fact, and generally on arbitrary complex conjunctions, disjunctions and negation of facts. Conclusion In this paper, we have detailed our dynamic reasoning engine supporting the OWL Ontology Web Language. A forward chaining production system generates the conclusions inferred by the OWL semantics from a set of appropriate facts and rules. Our engine features non-monotonic reasoning, as it makes a closed world assumption: conclusions are drawn tentatively and can later be retracted if the support of such conclusions becomes invalid. This work is part of our wider Intelligent Annotation and Retrieval Framework project, a semantic content-based media retrieval framework combining knowledge-based approaches and

10 low-level statistical approaches, with the ultimate goal of bridging the semantic gap. Our reasoning engine, as a core component for this framework has been designed to be efficient, dynamic and flexible. Real-time reasoning and online retractable inference are the main contributions proposed in this development, since, to the best of our knowledge, no other system has this abilities. This development is an ongoing project and we are currently working on the support for the OWL DL layer. OWL Lite has too many limitations on expressiveness and thus supporting OWL DL will open more opportunities to our knowledge-based activities. Currently, we rely on the assumption of a closed world and this is in contradiction with OWL semantics and could bring to some incompatibilities with other tools, thus preventing full interoperability. We are therefore willing to add the option to choose between an open world mode and a closed world mode to our framework. The open world mode will be entirely compatible with OWL, with monotonic reasoning only. The closed world mode will be used when compatibility is not a concern, and where the retractable reasoning feature and the additional conclusions that negation as failure allows are needed. Acknowledgments This work is supported by the Swiss National Science Foundation, under grant n in the frame of the ANGEL! project. References Baader, F., Calvanese, D., McGuinness, D., Nardi, D., & Patel-Schneider, P. (2003). The description logic handbook: Theory, implementation and applications. Cambridge University Press. Bechhofer, S., Harmelen, F. van, Hendler, J., Horrocks, I., McGuinness, D. L., Patel-Schneider, P. F., & Stein, L. A. (2003). OWL Web Ontology Language Reference. W3C. ( Biron, P. V., & Malhotra, A. (2001, May). XML Schema part 2: Datatypes. W3C. ( Brickley, D., & Guha, R. (2003, October). RDF Vocabulary Description Language 1.0: RDF Schema. W3C. ( Friedman-Hill, E. J. (2003). Jess, the rule engine for the Java platform. (herzberg.ca.sandia.gov/jess/) Haarslev, V., & Möller, R. (2001). Description of the RACER system and its applications. In Description logics workshop dl2001 (p ). Stanford, CA. Hayes, P. (2003). RDF Semantics. W3C. ( Horrocks, I. (1999). FaCT and ifact. In Description logics. Kopena, J., & Regli, W. (2003). DAMLJessKB: A tool for reasoning with the Semantic Web. IEEE Intelligent Systems, 18 (3), Marchand-Maillet, S., & Bruno, E. (2004). Exploiting user interaction for semantic contentbased image retrieval. In Trends and advances in content-based image and video retrieval. Springer. Patel-Schneider, P. F., Hayes, P., & Horrocks, I. (2003). OWL Web Ontology Language semantics and abstract syntax. W3C. ( Sintek, M., & Decker, S. (2002). TRIPLE a query, inference, and transformation language for the Semantic Web. In International semantic web conference (iswc). Smeulders, A. W. M., Worring, M., Santini, S., Gupta, A., & Jain, R. (2000). Content-based image retrieval at the end of the early years. IEEE Trans. Pattern Analysis and Machine Intelligence, 22 (12),