- From: <ruediger.klein@daimlerchrysler.com>
- Date: Thu, 13 Dec 2001 18:29:16 +0100
- To: www-webont-wg@w3.org
Dear all: in the following I want to make some remarks about language considerations from our engineering applications' perpective. Deliberately we take a pragmatic approach which is (hopefully) not unsound and open for future improvements. 1) meta level -------------------- In typical engineering applications, ontologies tend to be large and complex. Many different aspects are to be modeled in a consistent way. And problem solving using these complex information models needs a lot information about information in order to be effective. The ability to express meta level information is a key requirement for applications in engineering. This has mainly four aspects: 1a) filtering: Typically, for a certain task, only parts of this knowledge is relevant. For instance, when starting with crank shaft design, the designer is interested in geometrical shapes, then she will consider forces, speeds, and momentum, and then material properties, heating and heat distribution, etc. The manufacturing technology engineer has to consider geoemtry in relation to machining constraints, etc. So, we have to provide each of them with the necessary amount of information - not bothering them with irrelevant stuff. 1b) structuring This is especially useful for modeling support: a meta level allows the KE to apply the "modeling guidelines" explicitly represented (!!) on the meta level. For instance, functional descriptions of a large technical system are always (or should be) related to structural descriptions. So, on a meta level, we relate the meta class ' function' to the meta class 'structure' by a meta relation 'provided-by'. Each generic (!) function (like accelerate, decelerate, etc.) has to be connected to a generic structural class (like motor, brake, etc.) by a corresponding function-structure relation (provides-acceleration, provides-deceleration, etc.). This is not really the same as to have superclasses and super relations because here you can say that for each functional class there has to be such a (more special) relation connecting this generic function to an appropriate structure - on a generic level, not only on an instance level. And these class-specific generic relations carry a lot of semantics (provides-acceleration and provides-deceleration have quite different meanings... with lots of consequences to be modeled). 1c) behaviour A third useful aspect of meta-level information is control of user interaction: depending on the kind of information the information system should behave in different ways. 1d) problem solving related meta information: Engineering problem solving typically is also quite complex. In order to keep control, to follow decisions and their consequences, to manage rationale, etc. information about information is needed. The first three points (a, b, c) can be achieved, for instance, by tagging each piece of information in an ontology with meta-level information: - the meta level: physical-property, geometric-property, manufacturing, structure, function etc. are "meta-classes"; - the class level: each element at the class-level may be assigned to such meta classes: length:geometric-property , diameter:geometric-property etc. belong to the geometric-property meta class; density:physical-property ; thermal-conductivity:physical-property to the physical-property meta class, etc. motor:structure; accelerate: function; Even more fine-grained meta information could be useful: thermal-property, torsion-property etc. can be modeled as sub-classes of the meta class physical-property. To be a little more formal, this is quite close to what we have in FLogic: the ability to tag each class and attribute/relation with metal-level information. This is much less then a full "meta-level theory" - but nevertheless very useful and (as I hope) sufficiently well formalizable. The point 1d) goes beyond tagging, but is less ontological and more problem solving oriented (I'm quite sure this needs more explanation and discussion...). 2) rules ----------- Rules can be used for two different purposes: - inside a conceptual modeling framework (ontology); and - in order to map one ontology to an other one. The first point is, as we know, quite challenging: description logics including rules are not easy. I hope they are also not really necessary. The second purpose may result in a hybrid approach: rules are not integrated into the DL framework but some extra description facility. The semantics of terms in each ontology is represented in a language without rules. Rules ONLY allow us to formulate mappings between ontologies - a very necessary facility - where the semantics of this mapping is defined on each side of the transformation within the DL formalism. I'm quite sceptical if such a mapping can be achieved (mainly) automatically - i.e., that the rules can be deduced from the concept definitions in each ontology. Ontology mapping for large and complex ("industry-strength") ontologies which had been design independently is something which will at best be partially (or better to say point-wise) be automated. Take alone the different upper level descriptions applied in each ontology, or take the different modelings applied to attributes and relations (which are typically much weaker then their conceptual counterparts). 3) relations ----------------- In engineering, relations tend to be as complex as concepts: to have the right relationships between entities is as important for overall consistency as having the right entities. Consequently, relations carry much more semantics as in other domains (though even there we typically reduce the semantic content of relations considerably). Relations are a kind of interface between entities - described generically as part of the overall information model. To connect a motor to a gear has a lot of implications for both entities: geometrical attributes, forces, velocities, etc. are related, too. In order to do so we need non-binary relations as well as the ability to tag relational information with other kinds of information (probabilities, level of confidence, etc.). 4) (dis) agreements ---------------------------- A feature which is very useful and popular in many DLs is agreement and disagreement. If restricted to functional roles, it is computationally not worse then other language constructs. I would strongly recommend to include this feature into our language. 5) external constraints ------------------------------- In engineering as in many other domains we have constraints which go beyond the expressivity provided by the core (DL) language: arithmetics, geometry and topology, finite domain constraints, etc. The language should be open for such extensions. To summarize: ----------------------- The consequence for our language design is "simply" that we should provide sufficient expressivity for the aspects mentioned (even if this goes beyond a formal semantics?!). Can we find a hybrid approach with a well founded kernel language and a more expressive overall language where the semantics is only partially defined? Looking forward to get your comments! Kind regards Ruediger
Received on Thursday, 13 December 2001 12:30:31 UTC