In description logics, default knowledge is exclusively treated as incidental rules. However, as few concepts are definable using only strict knowledge, imposing strict definitions leads to terminological knowledge bases that mostly contain partially defined concepts. This is a real problem because such concepts can only be inserted as leaves of the terminology. Moreover, instance recognition is biased as these concepts must be explicitly mentioned as properties of these instances. It follows that partially defined concepts are described with necessary but not sufficient conditions. As a solution to these problems, we propose to integrate defaults in concept definitions and we argue that this is essential for our diagnosis application. We introduce a description language AL δ with default(δ) and exception( ) connectives. The cornerstone of our approach is the introduction of a definitional point of view where a default can be part of a concept definition, whereas in the classical inheritance one it is only viewed as a weak implication. We go on to describe a map between the definition of a concept and its inherited properties, and we show that the combination of these definitional and inheritance levels considerably improves the capabilities of classification processes. In particular this allows us to distinguish sure from probable instances and typical from exceptional instances. Finally we provide a specific operation, object refinement, which consists in enlarging object descriptions with exceptions in order to find additional concepts the object is an instance of. This operation is useful for our diagnosis application.

We present a formal correspondence between Conceptual Graphs and Description Logics. More precisely, we consider the Simple Conceptual Graphs model provided with type definitions (which we call TSC~) and the .Af~,f.O7. standard Description Logic. We prove an equivalence between a subset of TSC~ and a subset of .AEF_.OZ. Based on this equivalence, we suggest extensions of both formalisms while preserving the equivalence. In particular, regarding to standard Description Logics where a concept can be defined by the conjunction of any two concepts, we propose an extension of type definition in CGs allowing type definitions from the "conjunction" of any two types and consequently partial type definitions. Symmetrically, regarding generalization/specialization operations in Conceptual Graphs, we conclude by suggesting how Description Logics could take advantage of these correspondences to improve the explanation of subsumption computation.

No abstract

No abstract

We propose a component programming language called FLAC, Functional Language for Adaptable Components, on top of a functional programming language which authorizes full adaptability of components while ensuring type safety. The langage is given together with a type system that offers a complete static type ckecking of any programs (including adaptations) to ensure error-free run-time adaptations. Dynamic adaptability and static type checking might seem at first sight paradoxical, but our approach allows it because, first, we use a single language for traditional services and control services (i.e., services for adaptations), and secondly, a specific merge operation takes care of adaptations. IntroductionComponent-based programming is like a construction game: programs are assembled out of black boxes called components. The term 'black box' is justified by the fact that only the interfaces of components are publicly available. Such an interface characterizes the signatures of services the component offers or needs. The basic construct plug assembles a component that provides a service to a component that needs it. The domain of component-based systems (CBS) is mature enough to actually endorse the benefits of such a paradigm [12]. Safety and adaptativity are the two main requirements for such systems. Safety is ensured when execution is errorfree. For that purpose, most CBSs expect each required service used by a component to be satisfied by a service provided by another component (soundness) and any service offered by a component to be concretely defined (completeness) [7,9]. Obviously, type checking must be done accordingly. Adaptative capabilities are required to fit the evolution of the environment, software or hardware. Hence it is often given as an important goal for CBSs [3]. It may be minimal as in works of Aldrich [1]