Ontology-based applications can support the reuse of corporate-knowledge in engineering environments. In order to streamline the harnessing of semantics, problems of integration and of coverage assessment of ontologies need to be addressed. This paper provides examples of such problems when applying Semantic Technology in the aviation sector and outlines a strategy towards their solution. The paper also provides a preliminary discussion of how knowledge management architectures such as the one presented may be positioned in the wider research area of Industrie 4.0.
In the context of the German high-tech strategic program Industrie 4.0, which promotes research on the ongoing fourth industrial revolution yielded by the digitization of products, processes and organizations, we are investigating the application of Semantic Technology to the reuse of corporateknowledge in the aviation sector.
This research focuses on how semantics could be harnessed by the information systems employed during the conceptual design of aeronautical components. The key idea, akin to examples of Knowledge-based Engineering such as [9] or [11], is that engineering-projects in their early stages would bene t from semantic search, as this would expand access to existing corporate-knowledge (e.g. legacy-data from previous projects) as well as make search-results more relevant. The types of corporate-knowledge being considered include two main categories of information sources: textual data sources and non-textual data sources. © 2017 Copyright held by the author/owners.
SEMANTiCS 2017 workshops proceedings: LIDARI September 11-14, 2017, Amsterdam, Netherlands
The core Semantic Technology applied to increase access and relevance is ontology. This makes it possible, on the one hand, to relate non-matching information that conceptually belongs together and, on the other hand, to lter matching information that is conceptually unrelated.
Section 2 of this paper describes an ontology-based software architecture for the support of knowledge reuse in the aviation sector. Section 3 provides examples of the problems raised by the harnessing of the needed semantics. Section 4 outlines a strategy towards the solution of such problems. Section 5 provides a preliminary discussion of how knowledge management architectures such as the one presented should be positioned with respect to the wider research area of Industrie 4.0, in particular with respect to subareas that involve Linked Data and Robotics applications. 2.
Figure 1 shows the software architecture being researched and developed to support knowledge reuse. The architecture attempts to combine two pre-existing architectures and legacy-data (all in gray areas). The pre-existing architectures are based on divergent ontological commitments, especially di erent representational choices (regarding, for instance, what to model as a class and what as an individual, how many di erent properties to use in the ontology, whether to represent constraints, etc.). Such pre-existing representational commitments are conveyed by the two main ontological modules being only partially in a gray area of
The top part of Figure 1 illustrates a proprietary ontologybased Natural Language Processing software that classi es word and phrase occurrences in text using DocO, which contains aliases as well as disambiguation terms in multiple languages. As exempli ed in Figure 31, DocO's terminol1As in the Web Ontology Language (owl), in this paper ogy box (TDocO) is simple, as it includes a limited number of owl classes of things likely to be mentioned in aviationrelated texts, e.g. names of aviation companies, of company management, of aircraft families, models or components. For the most part, DocO contains individuals in its assertion box (ADocO), which are related to one another by assertions of a single type of object-property akin to the narrower -than relation between a hyponym and its hypernym in linguistics. For instance, the individual representing a given aircraft model (e.g. A320 -100 ) has a narrower scope than the individual representing such model's aircraft family (i.e. A320 ). Similarly, both individuals representing the model and the family have a narrower scope than the individual representing the airframer (i.e. Airbus). As explained in Section 3.1.2, this design choice allows greater representational freedom, by supporting for instance metaclassi cations. Also note that at present this ontology is not publicly available.
TDocO ::= f
ADocO ::= f
A320 : AircraftFamily; A320 -100 : AicraftModel; SingleAisle : AircraftClass; Airbus : Airframer ; narrower -than(A320 -100 ; A320 ); narrower -than(A320 -100 ; SingleAisle); narrower -than(A320 ; Airbus) narrower -than(A320 -100 ; Airbus)g the description logic (dl) notion of concept is called class. dl's logical constants have their standard meaning, i.e.: C1 v C2, C1 is a subclass of C2; i : C, i is an individual of class C; 9 R.C, all individuals of a given class are in a relation R with individuals of class C. 2.2
The central bottom part of Figure 1, shows the model
extraction and management software that supports the
integration of technical model data, based on a system proposed
in [
aircraft model: A320-100
(30)
(31)
(32)
(33)
(34)
(35)
(36)
(37)
(38)
(39)
(40)
(41)
(42)
(43)
(44)
(45)
Ontology2 proposed in [
TDesO ::= f
SubComponentDescribingParameter ;
hasFuselage v v hasPart ; isDescribedByHeight v v isDescribedByParameter ;
FuselageDescribingParameter ;
ADesO ::= f
A320 -100 : Aircraft g
ModO is mapped onto a reference design ontology DesO. In the present case-study DesO builds on the Aircraft (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (28) (29)
TModO ::= TModO [ TDesO AModO ::= AModO [ f
geom:fuselage:height : DistanceParameter g 2https://github.com/astbhltum/Aircraft-Ontology 3http://www.w3.org/2005/Incubator/ssn/ssnx/qu/qu 4http://www.w3.org/2005/Incubator/ssn/ssnx/qu/ qu-rec20 ontology integration: given ontologies, each separately representing knowledge relevant to the aviation sector, how can they be combined? As mentioned, their di erences should be resolved in a way that preserves each component's representational requirements. On the other hand, there are challenges of coverage: do the integrated ontologies adequately represent the aviation sector or should their content be enriched? 3.1
DocO, ModO and DesO need to be integrated in two
ways: terminology alignments should be found by means of
ontology matching techniques [8], di erence in abstraction
levels should be resolved by meta-modeling [
DocO contains individuals for measurement-related notions, although not organized in any structure. On the other hand, the measurement-related modules of ModO and DesO largely overlap as apparent in the similarities between Axioms (27) and (38), or Axioms (28) and (39), or Axioms (29) and (42), all of which make Axiom (45) plausible. The challenge is to nd a general approach to resolve the modeling di erences between ModO and DesO. Without such alignment between AModO and TDesO, the consequences of classifying geom:fuselage:height as a DistanceParameter cannot be tested by a reasoner based on individual's and class' properties, thereby limiting the main feature of ontological modeling. 3.1.2
DocO contains meta-classi cations. Axiom (8) asserts an individual aircraft model (class introduced in Axiom (1)). Axiom (9) asserts an individual aircraft class (class introduced in Axiom (4)). Yet, an A320-100 is often classi ed as an instance of (in owl: an individual of class) single-aisle. This would require to assert in dl a higher-order axiom like the following: A320 -100 : SingleAisle : AircraftClass.
Of course, that is not possible, as an individual in dl (a fragment of rst-order logic) cannot on its turn classify other individuals. DocO mimics such encapsulated classi cation between individuals by asserting a narrower -than relation, as in combined Axioms (9) and (12). 3.2
While the ontology resulting from the integration of the ontologies shown in Figure 2 would include many notions relevant to aviation, they would miss modules usually included in multi-disciplinary engineering ontologies.
One way of assessing ontology coverage is to compare a
given group of ontological modules with benchmarks
proposed in the relevant ontological literature. For instance,
[10] discusses the range of notions comprised in such
multidisciplinary engineering domains. According to this
proposal, DesO misses conceptualizations for: physical objects
(though implied by part-of relationships between
components), functionality (partly implicit in aircraft aspects),
processes and materials. Also, DocO contains many
individuals representing agents (e.g., persons, organizations).
DesO does not provide any conceptualization of agents,
given its focus on preliminary design. For a wider scope,
though, at least one agent may become relevant: the pilot.
(a) Matching
(b) Meta-modeling
Automatic or human, the pilot has control functions that
require agent-like properties. Finally, as described in [
The system being developed based on the proposed architecture attempts to tackle the challenges described above by providing operational de nitions of the arrows References and Mappings in Figure 1. This should result in the following operations.
Match: To integrate taxonomical structures and parametric data, alignments between DocO, DesO and ModO need to be established. Recommender systems are being tested to support this operation, which present complexities, for instance when matching ModO with DesO. As shown in Figure 8a, the former entangles in a single individual the notions of: distance parameter, measure of height, fuselage parameter; the latter, on the other hand, separates these notions. The matching mechanism may need to be complemented with the creation of individuals or property assertions (e.g. between FuselageDescribingParameter and geom:fuselage:height ).
Meta-model: To make available for DocO the result of the match operation at the appropriate level of abstraction, relevant classes in DesO need to be modeled as individuals, i.e. meta-modeled or, more speci cally, rei ed in DocO. As shown in Figure 8b, the resulting version of ADesO would contain the same knowledge as the three original matched ontologies, although extra classes would be added to classify the meta-modeled (rei ed) classes.
Assess Coverage: To estimate to which extent the matched DocO, DesO, ModO contain the terminology found in a corpus and point out missing notions, coverage assessment technique will be tested focusing on the automated testing of mereological and functional properties.
This section provides a preliminary methodological discussion of how knowledge management architectures, such as the one presented above, should be positioned with respect to the wider research area of Industrie 4.0, in particular with respect to subareas that involve Linked Data and Robotics applications.
In our present working de nition of the relationships between the di erent research-areas that contribute to the vision of Industrie 4.0 we are assuming a fairly rigid partition between: Pre-production processes (or work phases) which, for the most part, are based on intellectual or experimental activities (i.e. the part of the process chain from Conceptual Design to Prototyping).
Production processes (or work phases) which have at their core physical activities or transformations (i.e. the part of the process chain from Mass Production and Assembly to Quality Assurance).
Questions about production processes are investigated in the subarea of Industrie 4.0 usually referred to as Smart Factory. Here Robotics plays a central role, as a means to reduce production costs by more e cient and e ective adjustment of production lines. Alongside Robotics, Cyberphysical Systems and the Internet of Things are key-ingredients in achieving interoperability and decentralization on the oor of the Smart Factory.
On the other hand, questions about pre-production processes are investigated in a subarea of Industrie 4.0 that, by analogy, could be called Smart Studio. Here Robotics plays, if any, a less important role, whereas Knowledge Management and Arti cial Intelligence are more prominent. The architecture presented in Figure 1, contributes to achieving interoperability in the Smart Studio.
In this context Linked Data, i.e. the result of interlinking
structured data coming from di erent sources (as proposed
in 2006 by Tim Berners-Lee5 or in [
What still needs to be clari ed, though, is the extent to which Linked Data (or any other integration approach) can deliver results across the Smart Factory and the Smart Studio. Is it possible to blur the distinction between data used or generated during pre-production and data used or generated during production?
Ideally, (i) knowledge that is gained during the production of a product would be fed back to previous phases (e.g. the design of a new version of that same product): such feedback loop would allow to modify the design of a product based on data generated during its production or its quality 5W3C recommendation https://www.w3.org/DesignIssues/ LinkedData.html assessment; (ii) conversely, knowledge that is gained during the pre-production of a product may be fed forward to later phases (e.g. scheduling or con guration): such feed{ forward loop would directly impact the production line and the robots operating in it.
Also, the increasing role of virtualization is an additional motivation for researching if it is possible to blur the distinction between data generated in the Smart Factory and in the Smart Studio. On the one hand, the Smart Factory needs virtual representations of physical products for new production techniques (e.g. 3D Printing). On the other hand, the Smart Studio applies virtual design approaches (e.g. virtual testing or hardware-in-the-loop testing). As both the Smart Factory and the Smart Studio will increasingly be working on virtual representations of the same nal physical product, linking the data underlying those representations would translate into increased agility throughout the product lifecycle.
As a nal (counter)point on what discussed in this Section, it should be noted that the possibility of blurring the distinction between data generated in the Smart Factory and in the Smart Studio, even if eventually viable, may not be unconditionally welcome by practitioners. The aviation industry, for instance, is subject to the strictest design certi cation requirements, which entail long and costly certi cation procedures. As a result, designs in Aviation are rather stable in time. Therefore, the advantages of a feedback loop, such as (i) above, may not be obvious, because putting e ort into an automated Knowledge Management infrastructure to achieve ne-grained changes to product designs based on feedback from the production line may not be considered cost-e ective. 6.
Research supported by German program LUFOV2, project
EFFPRO 4.0, grant no. 20Y1509E.
International Computer Software and Applications
Conference, pages 239{244. IEEE Computer Society,
2011.
[8] O. Kovalenko and J. Euzenat. Semantic matching of
engineering data structures. In Bi and Sabou [
Semantics to the shop oor: towards ontology modularization and reuse in the automation domain.
IFAC Proceedings Volumes, 47(3):3444{3449, 2014. [11] T. Moser. The engineering knowledge base approach.
In Bi and Sabou [