language requirements

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