Semantic interoperability has been acknowledged as a challenge for industrial engineering due to the heterogeneity of data models in the involved software tools. In this paper, we show how to learn declarative class definitions of engineering objects in the XML-based data format AutomationML (AML). Specifically, we transform AML document to the description logic OWL 2 DL and use the DL-Learner framework to learn the concepts of named classes. Moreover, we extend the ALC refinement operator in DL-Learner by exploiting the syntax specification of AML and show significant better learning performance.
Engineering is referred to as the activities for designing, testing and
commissioning complex industrial plants [
The motivation of AML is to neutralize tool-specific data using the
aforementioned conceptual models. Nevertheless, the standardized role and interface
classes can not satisfy individual modeling requirements, since they lack of
sufficient semantic expressiveness for describing tool-specific engineering objects. In
practice, the user has to extend these classes and leave the semantic
interpretation as a functionality of the data importer. This problem encourages the study
of concept learning from engineering data in AML [
Semantic web technologies such as RDF(S) and OWL are popular tools to
achieve interoperability in the World Wide Web. Several studies from the
engineering domain have shown that transforming XML-based data to RDF(S)/OWL
ontologies enhances the semantic interoperability with automated reasoning [
Figure 1 shows the main components of AML. Modeling in AML usually begins with the hierarchy of user-specific roles and interfaces. Subsumption relations can be defined among these classes using the XML attribute RefBaseClassPath. The next step is the modeling of system units which represent reusable engineering objects, for example the robot model kr5 from the manufacturer KUKA. Each system unit may consist of interfaces (called as external interfaces) and nested internal structures (called as internal elements). The composition is illustrated by the connections with a filled diamond endpoint in figure 1. The star symbol over
Role + Name: String + RefBaseClassPath: String
references *
SystemUnit + Name: String hasInternalElement hasAttribute hasInterface *
Attribute + Name: String * hasAttribute
InterfaceClass + Name: String + RefBaseClassPath: String
references *
ExternalInterface + Name: String one connection means that the cardinality of the composition is unlimited. Optionally, the semantics of a system unit or an external interface can be specified as a reference to an AML role or interface class respectively. While an internal element and an external interface can reference only one single class, a system unit can reference more than one to allow the modeling of multi-functional devices. Finally, attributes can be added to describe properties of objects, e.g. kr5.weight.
In order to learn concepts from AML, we firstly need a formal semantic representation of the XML-based data. The Web Ontology Language (OWL) is the W3C standard for knowledge representation on the web and its subset OWL 2 DL is semantically compatible with the SROIQ description logic. Besides of its decidability, OWL 2 DL provides a rich vocabulary for complex class expressions, making it a rational choice for the semantic lifting. In particular, the support of nominals and concrete roles allows us to describe meaningful engineering concepts. For example, robots which have at least 6 axis from the manufacturer KUKA can be stated as:
Robot ⊓ ∃hasManufacturer.[”KUKA”] ⊓ ∃hasNumAxis.[≥ 6] (1)
Table 1 shows the mapping strategy from AML to OWL 2 DL. Specifically, AML role and interface classes are mapped to OWL classes, while system units and external interfaces are mapped to OWL individuals. Intuitively, relations between objects are mapped to object properties, and attributes are mapped to data properties. In this paper, we restrict the scope of the lifted AML ontology and focus on just two object properties: hasInternalElement (hasIE in short) and hasExternalInterface (hasEI in short). Because internal elements and external interfaces can be independent of any AML class, both hasIE and hasEI have the range as OWL : Thing. The abstract conceptual model of AML is not transformed since it does not carry useful semantics for engineering. However, we add an annotation to each lifted AML entity to indicate its role in the XML schema. For example, each lifted system unit has an annotation of SystemUnit. After the transformation, we obtain a knowledge base K = (T , A) including a terminological part T (T-Box) and an assertional part A (A-Box). The T-Box contains the concept definitions of AML role and interface classes, and the A-Box contains
AML role class interface class system unit external interface relationship attribute
OWL 2 DL DL class concept class concept individual object individual object object property abstract role data property concrete role
Example
Robot SignalInterface
kr5 kr5 digitalIn1 hasIE, hasEI hasWeight the ground facts, i.e. system units and their internal structures. For example, following assertions are generated for the system unit kr5: hasManufacturer(kr5, ”KUKA”) hasExternalInterface(kr5, kr5 digitalIn1) hasInternalElement(kr5, kr5 arm)
(2) 3
Concept Learning is a subfield of machine learning which aims to induce a
concept description for a set of positive and negative examples. In this paper, we
focus on concept learning in description logics, and follow the definition of a
learning problem as proposed in [
Definition 1 (concept learning in description logics). Let Target be a concept name and K be a knowledge base (not containing Target). Let E = E+ ∪ E− be a set of examples, where E+ are the positives examples and E− are the negative examples. The learning problem is to find a concept C ≡ Target with K ∪ C |= E+ and K ∪ C 6|= E−.
In the context of AML, the ultimate goal is to learn the description of a named class from a set of AML system units, since they are models of engineering objects that we are interested in. Figure 2 illustrates the learning procedure. While the AML data is mapped to an OWL 2 DL ontology as described before, the user is expected to select some AML system units as positive examples E+, while leaving the rest as the negatives E−. Afterwards, a configuration file has to be generated for the learning system.
Concept Learning methods often employ refinement operators to reduce the search space of concept hypotheses. The essential property of the refinement operator ρ in DL-Learner is its completeness in ALC. That means, starting from any concept C (including ⊤), ρ will reach the target concept with sufficient time. Although the support of concrete roles makes ρ incomplete because of AML
select map to
OWL pos pos pos neg
neg Background Knowledge
Config
setting DL-Learner the infiniteness of real numbers, ρ is capable of finding proper concrete roles by computing splits in the space of real numbers. However, the direct use of ρ would be inefficient, because it does not take into account the syntactic constraints defined in the underlying XML schema of AML. Specifically, figure 1 shows that only external interfaces can reference interface classes and each external interface can only reference one interface class. These constraints can be integrated into the refinement operator to improve the performance of learning, especially for a large T-Box. Therefore, we divide the set of named concepts NC into two subsets Nar and Nai, where Nar is the set of all AML role classes and Nai is the set of all AML interface classes. Then we define the sets Mop, Mie and Mei as follows: Mop = {∃hasIE.⊤, ∃hasEI.⊤, ∀hasIE.⊤, ∀hasEI.⊤} Mie = {A | A ∈ Nar, ∄A′ ∈ Nar : A ⊏ A }
′ Mei = {A | A ∈ Nai, ∄A′ ∈ Nai : A ⊏ A } ′ (3) (4) (5)
Mie is the set of top level AML role classes, and Mei is the set of top level AML interface classes. Further, let Uie = {C1 ⊔ C2 ⊔ ... | Ci ∈ Mie ∪ Mop}, Uei = {C1 ⊔ C2 ⊔ ... | Ci ∈ Mei} and sh↓(C) be the set of direct sub classes of a named concept C ∈ NC , we extend ρ in the following cases: – ρ(C) = Uei, if C = ⊤ and C is a filler of hasEI – ρ(C) = Uie, if C = ⊤ and C is not a filler of hasEI – ρ(C) = sh↓(C), if C ∈ NC is a filler of hasEI – ρ(C) = sh↓(C) ∪ {C ⊓ D|D ∈ ρ(⊤)}, if C ∈ NC is not a filler of hasEI
In the other cases, we keep ρ as it was in DL-Learner and omit the details
of it in this paper for brevity. We call the new refinement operator ρaml and
implemented it based on ρ in the DL-Learner framework. Notice that negated
atomic concepts such as ¬A are ignored in both Mie and Mei, since negations are
not preferred in engineering and are not used in practice. Moreover, we do not
refine the filler of hasEI with concept intersections, because one external interface
can reference only one interface class and does not have nested structures. As a
result, ρaml would generate far less refinements than ρ. For example, a refinement
chain ⊤ ∃hasEI.⊤ ∃hasEI.C1 ∃hasEI.(C1 ⊓ C2) could be produced by ρ
but not by ρaml, since (C1 ⊓ C2) is not a proper refinement of the filler of hasEI.
In this section, we compare learning results using the refinement operator ρ
from DL-Learner and the extended one ρaml as described above. Specifically, we
measure the time required until the first 100% accurate solution is found. The
raw AML document comes from the research project ReApp which was
originally used for modeling industrial robot systems [
RobotWithServoMotors ≡ ∃hasIE.(ArticulatedRobot ⊓ ∃hasIE.ServoMotor) (6) Table 2 summarizes the results of five representative experiments of varying complexity, while the rest ones share similar characteristics and are omitted for brevity. The column Concepts is the number of tested concept hypotheses. The column Overall is the overall time needed to find the first correct solution, and the column Reasoning is the time spent for reasoning, both timers are in milliseconds. All measurements in the table are taken from ρaml, while the percentages in parentheses represent the ratio in the form of ρaml/ρ. Unknown values of the ratio means that no solution was found within 10 minutes with ρ. The results show that ρaml is significant faster than ρ (the ratios are much smaller than 100%), since ρaml generates much less concept hypotheses for testing. However, for some cases no solution was found within 10 minutes with either ρ or ρaml, so learning in AML still remains a challenging task2. 5
In this paper, we studied concept learning from engineering data stored in the
XML-based data format AML. We showed how to use the DL-Learner framework
2 By reducing the expansion penalty of CELOE, we were able to find a solution with
the extended refinement operator ρaml for some of these hard cases.
to learn engineering concepts in description logic, by transforming an AML
document to an OWL 2 DL ontology. We proposed an extension of the ALC downward
refinement operator ρ in DL-Learner to exploit the syntactic constraints defined
in the XML schema of AML. Experimental results show that the extended
operator ρaml has a significant performance improvement in all test cases. However,
learning is still very challenging in some cases and could be worse if the size
of the T-Box grows further. In future work, we want to investigate whether we
can achieve better learning results using a semantic language other than OWL
2 DL, for example the hybrid system AL-log that merges ALC and DATALOG.
In particular, an ideal refinement operator for AL-log was proposed in [