wp4 – manufacturing virtualisation& interoperability d4.1 ... · manufacturing domain...

Cloud-based Rapid Elastic MAnufacturing

WP4 – Manufacturing Virtualisation& Interoperability

D4.1: CREMA Data Model, Model Library and Profiles Prototype I

Deliverable Lead: DFKI

Contributing Partners: DFKI, TANet, IKER, TCO, FAGOR, GOIZ

Delivery Date: 12/2015

Dissemination Level: Public

Version 1.0

This document contains the definition of the first version of the semantic CREMA data model framework. It consists of the semantic CREMA data model library, and the CREMA component DLP which maintains the library and makes it accessible to other CREMA components. The library includes the public shared CREMA manufacturing domain ontology CDM-Core, its user profiles and metadata. In CREMA, the CDM-Core is used to semantically annotate process models, services and data of the CREMA use cases.

CREMA WP4 Public CREMA Data Model

T4.1 - D4.1 - Data Model, Model Library and Profiles Prototype I

Document Version: 1.0

Date: 2015-12-29 Status: For Approval Page:

2 / 72 http://www.crema-project.eu Copyright © CREMA Project Consortium. All Rights Reserved. Grant Agreement No.: 637066

Document Status

Deliverable Lead Matthias Klusch, DFKI

Internal Reviewer 1 A. Karim El Moussaoui, ASC

Internal Reviewer 2 Philipp Hoenisch, TUV

Type OTHER

Work Package WP4: Manufacturing Virtualisation & Interoperability

ID D4.1: CREMA Data Model, Model Library and Profiles Prototype I

Due Date 31.12.2015

Delivery Date 29.12.2015

Status For Approval

Note This deliverable is subject to final acceptance by the European Commission.

Disclaimer The views represented in this document only reflect the views of the authors and not the views of the European Union. The European Union is not liable for any use that may be made of the information contained in this document. Furthermore, the information is provided “as is” and no guarantee or warranty is given that the information is fit for any particular purpose. The user of the information uses it at its sole risk and liability.






Project Partners

Ascora GmbH, Germany

Dot NET IT, United Kingdom

Technische Universität Wien, Austria

Technology Application Network Limited,

United Kingdom

German Research Center for Artificial

Intelligence, Germany

IKERLAN S. Coop., Spain

Ubisense, United Kingdom

Tenneco-Walker (U.K.) Limited, United Kingdom

FAGOR ARRASATE S. Coop., Spain

Goizper, Spain

Information Catalyst, United Kingdom






Executive Summary This deliverable describes the semantic CREMA data model (CDM) framework in support of the semantic description, annotation, and handling of manufacturing related process models, services, and data in the CREMA use cases. This framework consists of the semantic CREMA data model library, and the CREMA component DLP which maintains the library and makes it accessible to other CREMA components. The library contains the semantic CREMA data model, which is the public shared CREMA manufacturing domain ontology CDM-Core in the W3C standard ontology language OWL2, as well as metadata on the CDM-Core and user-specific CDM-Core profiles. The first basic version of the CDM-Core represents domain knowledge of both CREMA use cases in the automotive and machinery maintenance domains (see D7.2 and D8.2). The CDM-Core allows to semantically annotate the selected process models and sensor data of these use cases. Examples of these semantic annotations and their usage in CREMA for semantic data harmonisation, process service selection, and data stream processing are provided. The public CDM-Core bases in part on relevant standard semantic data models that are available for public reuse. Finally, this deliverable gives an overview of the CREMA component DLP to be developed in Task 4.1. Technical diagrams of this document including the current version of the public shared CREMA manufacturing domain ontology CDM-Core and annotated process models are available at https://go.ascora.de/d41diags Ongoing work is concerned with the finalisation of the CDM framework. That includes (a) an update of the first basic version of the CDM-Core ontology, and (b) the prototypical implementation of the CREMA component DLP. The CDM-Core update mainly concerns the extension and refinement of domain knowledge for semantic annotation of (a) process services to be developed and (b) changes of current process models and sensor data schemas by user partners in the CREMA use cases. The results will be reported in the deliverable CREMA Data Model, Model Library and Profiles Prototype II (D4.2, T4.1) at M18 (June 2016).






Table of Contents

1 Introduction ..................................................................................................................... 8

1.1 CREMA Project Overview ...................................................................................... 81.2 Deliverable Purpose, Scope and Context .............................................................. 81.3 Document Status and Target Audience ................................................................. 81.4 Abbreviations and Glossary ................................................................................... 91.5 Document Structure ............................................................................................... 9

2 CREMA Data Model Library .......................................................................................... 102.1 Requirements ....................................................................................................... 102.2 CDM Library Overview ......................................................................................... 112.3 Semantic CREMA Data Model CDM-Core ........................................................... 13

2.3.1 CDM-Core Engineering ............................................................................. 132.3.2 CDM-Core Description .............................................................................. 20

2.4 CDM-Core Profiles ............................................................................................... 282.5 CDM-Core Metadata ............................................................................................ 292.6 CDM-Core Ontology Usage ................................................................................. 32

2.6.1 Semantic Annotation ................................................................................. 322.6.2 Optimal Semantic Selection of Process Services ..................................... 392.6.3 Semantic Data Stream Processing ........................................................... 412.6.4 Semantic Data Harmonization .................................................................. 42

3 CREMA Data Model Library Software .......................................................................... 434 Summary ....................................................................................................................... 45






List of Figures, Tables and Listings

Figures Figure 1: CDM library content model in UML ..................................................................... 12Figure 2: Distributed CDM-Core ontology engineering process ......................................... 14Figure 3: Abstract view of CDM-Core knowledge graph with share of reuse of public semantic data models (in black) and CREMA extensions (in blue) .................................... 20Figure 4: Part of CDM-Core for CREMA use case I ........................................................... 22Figure 5: Part of CDM-Core for condition monitoring in CREMA use case I ...................... 23Figure 6: Semantic description of concept “Alarm” in the CDM-Core knowledge graph (bottom), description logic OWL2-DL (middle), and OWL2 abstract syntax (top) .............. 25Figure 7: Part of CDM-Core for CREMA use case II .......................................................... 26Figure 8: Semantic description of a TCO shopfloor robot in the CDM-Core knowledge graph (top), description logic OWL2-DL (middle) and OWL2 abstract syntax (bottom) ..... 27Figure 9: Example of CDM-Core profile creation by user ................................................... 28Figure 10: Update of CDM-Core based on user-specific CDM-Core profile ...................... 29Figure 11: Relational schema for CDM-Core metadata ..................................................... 30Figure 12: CDM-Core part for provenance and domain metadata definition ...................... 31Figure 13: Example of semantic annotation of a process model of CREMA use case I .... 34Figure 14: Example of semantic annotation of a process model of CREMA use case II ... 35Figure 15: Example of semantic annotation of service “Pick Robot Cell” ........................... 36Figure 16: Example of semantic data stream annotation in CREMA use case I ................ 38Figure 17: Example of logical IOPE-plugin match of annotated service with process task 40Figure 18: Architecture of CREMA Data Model Library Component DLP (from D3.2) ....... 43Figure 19: Software technologies for DLP implementation ................................................ 44Figure 20: BPMN process models of CREMA use case I .................................................. 49Figure 21: Annotated process model of CREMA use case I (1) ......................................... 50Figure 22: Annotated process model of CREMA use case I (2) ......................................... 51Figure 23: Annotated process model of CREMA use case I (3) ......................................... 52Figure 24: Annotated process model of CREMA use case I (4) ......................................... 53Figure 25: Annotated process model of CREMA use case I (5) ......................................... 54Figure 26: Annotated process model of CREMA use case I (6) ......................................... 55Figure 27: Annotated process model of CREMA use case I (7) ......................................... 56Figure 28: Annotated process model of CREMA use case I (8) ......................................... 57Figure 29: Annotated process model of CREMA use case I (9) ......................................... 58Figure 30: Annotated process model of CREMA use case I (10) ....................................... 59Figure 31: BPMN process models of CREMA use case II (1) ............................................ 61Figure 32: BPMN process models of CREMA use case II (2) ............................................ 62Figure 33: Annotated process model of CREMA use case II (1) ........................................ 63Figure 34: Annotated process model of CREMA use case II (2) ........................................ 64Figure 35: Overview of metal press system and sensory at FAGOR ................................. 65Figure 36: Sensor data schema from data log provided by FAGOR .................................. 66Figure 37: Syntax and semantics of description logic SROIQ (OWL2-DL) ........................ 68Figure 38: Relations between OWL2 dialects (expressiveness, complexity) ..................... 69Figure 39: MASON overview [LSDS06] ............................................................................ 71






Tables Table 1: Selected non-semantic standard data models for CREMA use cases ................. 16Table 2: Selected semantic data models and extensions for CREMA use cases .............. 18Table 3: Statistics of CDM-Core ......................................................................................... 21Table 4: Semantic mapping of sensor data schema to concepts in CDM-Core ................. 67

Listings Listing 1: BPMN XML source code of an annotated process task ..................................... 33Listing 2: Logic-based plugin matching of semantic services ............................................. 39






1 Introduction CREMA – Cloud-based Rapid Elastic MAnufacturing – is a project funded by the Horizon 2020 Programme of the European Commission under Grant Agreement No. 637066.

1.1 CREMA Project Overview CREMA aims at simplifying the establishment, management, adaptation, and monitoring of dynamic, cross-organisational manufacturing processes following Cloud manufacturing principles. CREMA will also provide the means to integrate data from distributed locations as if the complete manufacturing was carried out on the same shop floor, by integrating extra- and inter-plant manufacturing assets and making them “mobile”. CREMA will be built upon concepts and methods from the fields of Virtual Factories, Service-oriented Computing, Ubiquitous Computing, Cyber-Physical Systems, the Internet of Things and the Internet of Services, and naturally and most importantly Cloud computing. To achieve its goals, the project will define tools and approaches in these areas:

• Manufacturing Virtualisation & Interoperability • Cloud Manufacturing Process and Optimisation Framework • Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction

Framework Thus, to achieve its goals, CREMA conducts original research and applies technologies from the fields of full end-to-end integration of Cloud manufacturing, integration of manufacturing assets and corresponding data sources, the design and execution of manufacturing processes, to the end user support via collaboration and interaction tools. For more information, please refer to the project Website1.

1.2 Deliverable Purpose, Scope and Context The purpose of this deliverable is to introduce the semantic CREMA data model (CDM) framework and to act as a guideline to its implementation work and usage.

1.3 Document Status and Target Audience This public document is listed in the Description of Action (DoA) as “PU” (public) and “OTHER” (technical diagrams). It mainly provides the description and respective diagrams of the first version of the public CREMA manufacturing domain ontology CDM-Core. It also presents diagrams of examples of using the CDM-Core for semantic annotation and handling of given process models and sensor data in the CREMA use cases. Finally, the document briefly summarizes the planned CREMA software component DLP for managing and querying the CDM-Core by other CREMA components. This document will be updated in M18 with an extended and refined final version of the CDM-Core and the prototypical implementation of the component DLP. While the document is primarily aimed at the project partners and the CDM-Core usage for the CREMA use cases, this public deliverable can also be useful for the wider scientific

1 http://www.crema-project.eu/






and industrial community. The adoption of the CDM-Core for other domains and use cases may require respective efforts in its appropriate refinement and extension. Software support for CDM-Core profiling will be provided to the user by the CREMA components DLP and DHS. This includes other publicly funded projects, which may be interested in collaboration activities.

1.4 Abbreviations and Glossary A glossary of common terms and roles related to the realisation of CREMA as well as a list of abbreviations is provided as an online glossary2 / abbreviations list3.

1.5 Document Structure This deliverable is broken down into the following sections:

• Section 1: Provides an introduction for this deliverable, including a general overview of the project, and outlines the purpose, scope, context, status, and target audience of this deliverable

• Section 2: Describes the development process and first version of the semantic CREMA data model CDM-Core. It also provides examples of its usage for the semantic annotation and reasoning on process models, services, and sensor data in the CREMA use cases.

• Section 3: Provides a brief overview of the CREMA component DLP • References: Provides the details of the references mentioned in the document • Annexes:

• Annex 1 contains the BPMN notation and informal description of the current process models that are selected for the first CREMA use case

• Annex 2 contains the semantic annotation of the process models in Annex 1 based on the CDM-Core ontology

• Annex 3 contains the BPMN notation and informal description of the current process models that are selected for the second CREMA use case

• Annex 4 contains the semantic annotation of the process models in Annex 3 based on the CDM-Core ontology

• Annex 5 contains the TSV-encoded schema for sensor data streams in the second CREMA use case

• Annex 6 contains the syntax and formal logic-based semantics of the standard W3C ontology language OWL2-DL of the CDM-Core

• Annex 7 contains a short description of general, not CREMA use case specific parts of the CDM-Core

2 http://crema-project.eu/glossary 3 http://crema-project.eu/abbreviations





10 / 72

http://www.crema-project.eu Copyright © CREMA Project Consortium. All Rights Reserved. Grant Agreement No.: 637066

2 CREMA Data Model Library As a main prerequisite for semantic interoperability and management of service-based manufacturing processes and data in the CREMA use cases, the Task 4.1 partners developed the first version of a semantic CREMA data model framework. This framework consists of the so called CDM (CREMA Data Model) library and the CREMA component DLP (see Section 4.1 in D3.1 Global Architecture Definition), which maintains the CDM library and makes it accessible to other CREMA components. The CDM library contains the semantic CREMA data model, which is the public shared CREMA manufacturing domain ontology CDM-Core, as well as metadata on the CDM-Core and user-specific profiles. The general requirements for the CDM framework are described in Section 2.1 of this document, followed by an overview of the CDM library content in Section 2.2. The distributed engineering and description of the first version of the CDM-Core ontology are presented in Section 2.3. The user-specific CDM-Core ontology profiling, and CDM-Core usage related metadata are described in Sections 2.4 and 2.5. Examples of semantic annotation of process models, services, and sensor data with the CDM-Core ontology, as well as the usage of such annotations for different kinds of semantic processing in CREMA are given in Section 2.6.

2.1 Requirements The first version of the CDM framework is supposed to satisfy the following requirements: 1. The public shared CREMA manufacturing domain ontology CDM-Core

a) is representing domain knowledge of both CREMA use cases such that the semantics of given process models (see Annexes 1 and 3) and sensor data (see Annex 5), as well as services, can be basically described. The semantic annotation with CDM-Core supports functional optimisation of service-based processes, and semantic data harmonisation in CREMA.

b) is consistent, i.e. the formal definitions in the ontology are logically consistent. This requirement is evaluated by an ontology engineer with standard means for ontology consistency checking.

c) is modeled in a standard W3C ontology language which is sufficiently expressive and supports formal logic-based semantic reasoning on concepts and relations defined in the CDM-Core. Candidates are RDFS and OWL2 dialects.

d) Is partly based on selected relevant and freely available standard non-semantic4 and semantic data models, in particular in compliance with their copyright and licensing models.

2. The CDM library contains information about user contributions to the CDM-Core. These user-specific CDM-Core profiles are the result of the modifying, subsetting and updating of (parts of) the CDM-Core by users. The access to CDM-Core profiles can either be public or restricted to the respective creator.

4 Data models in a data modeling or markup language like XMLS which have no formal logic-based semantics are commonly considered as non-semantic.





11 / 72


3. The CDM library contains metada on the CDM-Core usage and history of CDM-Core profiles for metadata querying.

4. The CREMA component DLP maintains the CDM library and makes it accessible to other CREMA components via its RESTful API. The functional architecture of the DLP is described in the Functional Specification (D3.2, T3.2) and Technical Specification (D3.3, T3.3). In general, the DLP

a) offers functions for semantic querying of the CDM-Core and metadata. That includes semantic similarity functions as required by the CREMA component DHS for the purpose of semantic data harmonisation (Task 4.2).

b) offers simple CRUD-based functions for the CDM-Core management and profiling by multiple users without advanced versioning, recovery and access control.

c) supports crowd-sourced CDM-Core development in the sense that open web-based contributions to the CDM-Core can be made via the CDM-Core profiling functions of the RESTful API of DLP.

d) does not provide an user interface by itself. The functionalities for CDM-Core profiling and query-answering for semantic data harmonisationare accessible to users in the respective part of the DHS user interface (Task 4.2).

In the subsequent sections, it is shown how the first three requirements are satisfied by the CDM library. The fourth requirement will be satisfied by the CREMA component DLP to be developed in the next reporting period and briefly summarised in Section 3.

2.2 CDM Library Overview The CDM library consists of the following parts:

1. the public shared CDM-Core (see Section 2.3.2), which represents manufacturing domain knowledge in OWL2 such that the given process models, and sensor data of the CREMA use cases can be semantically annotated,

2. a set of CDM-Core profiles (see Section 2.4), which are user-specific contributions to the CDM-Core, and

3. metadata on the CDM-Core and profiles (see Section 2.5). The UML structure diagram of the CDM library content is shown in Figure 1. The CDM-Core ontology (UML class “CDM core”) is an aggregation of multiple ontologies (UML class “ONT”) in the W3C standard OWL2 (see Section 2.3 and Annex 1) which can be interlinked, modified, and queried. Each aggregation element is a named graph with metadata on provenance and covered domains. Currently, the CDM-Core aggregates (a) the top-level manufacturing ontology MASON [LSDS06], (b) the standard W3C SSN ontology for sensory and sensor networks, (c) the DUL ontology for physical and social context, (d) the standard-based CM ontology for condition monitoring and maintenance, and (e) the CREMA use case specific ontologies CDM-UC1 and CDM-UC2. The CDM-Core is described in Section 2.3, and MASON, SSN, CM and DUL are summarized in Annex 7. The definition of the CDM-Core in OWL2 and its knowledge graph are available at https://go.ascora.de/d41_CDM-Core.owl, respectively, https://go.ascora.de/d41_CDM-Core_kgraph_2015_12_14.png





12 / 72


Users can contribute to the CDM-Core ontology (UML class “User contribution”) in terms of extending, modifying, and subsetting it with respect to at least one or all domains covered. These contributions can be performed with CRUD operations (CRUD operations of “CDM core”), that is, users can read and make changes to the full or domain-specific parts (subsets) of the CDM-Core ontology. In any case, the result of such changes is a named graph (UML subclass of “ONT”) with metadata on its creation and domain. A composition of user contributions is called a profile of the CDM-Core ontology (UM class “CDM profiles”).

Figure 1: CDM library content model in UML

The CDM-Core ontology and the user-specific contributions (profiles) to the CDM-Core are separately stored and maintained by the CREMA component DLP. From the set of user contributions, only those which are most recent and marked as “public” by their creators are committed for integration into a respectively new version of the CDM-Core. Details of CDM-Core profiling are given in Section 2.4. The CDM library also contains metadata on the usage of the CDM-Core ontology (UML class “CDM Usage”) in terms of statistical information (UML class “Ontology statistics”), the history of user contributions to the CDM-Core (UML class “User contribution history”), and user ratings of semantic relations in the ontology (UML class “User Ratings”). Details of CDM-Core metadata are given in Section 2.5. The CDM library will be part of the CREMA software package DLP and planned to be publicly available under an open source license such as Apache License v2.0. A brief overview of this component to be developed by task partners until M18 (June 2016) is given in Section 3.





13 / 72


2.3 Semantic CREMA Data Model CDM-Core The semantic CREMA data model is the public shared CREMA manufacturing domain ontology CDM-Core. The CDM-Core is modeled in the standard W3C ontology language OWL2-DL (see Appendix 6). The CDM-Core has been developed by the task partners according to the distributed ontology engineering methodology DILIGENT (see Section 2.3.1). As required, the CDM-Core represents knowledge of the CREMA use cases (see Section 2.3.2) such that the semantics of given process models and sensor data can be basically described (see Section 2.6). The current version of CDM-Core will be extended and refined in a final version to be released at M18.

2.3.1 CDM-Core Engineering Ontology engineering in a nutshell. Ontology engineering (OE) is the set of activities that concern the ontology development process, the ontology life cycle, and the methodologies, tools and languages for building ontologies [GFC03]. Main types of activities which are recommended by an OE methodology to be carried out in an ontology life cycle in general are the following [GFC03, SSS09, SMB10]:

1. Domain analysis: These activities concern the identification of use case scenarios and relevant information sources for the considered domains, the agreement on the requirements for the shared ontology, as well as the search, assessment and selection of relevant semantic data models which are available for public reuse.

2. Conceptualisation of knowledge: These activities refer to the development of a semi-formal conceptual model (e.g. mind maps) of objects and concepts that are organised into taxonomic (hierarchical) relations. The elements of the conceptual model are typically semi-automatically extracted from relevant information sources, ontologies and standards.

3. Formalisation of the conceptual model: These activities concern the translation of the conceptual model into a knowledge representation language with formal semantics like RDFS and OWL2.

4. Evaluation of the formal ontology: The evaluation of the formalised ontology is performed by (a) the users and domain experts with respect to the sufficient coverage and description of the domains, and (b) the ontology engineer with respect to the syntactic correctness, consistency and normalisationof the ontology.

Current state of the art in OE methodologies in general differ in the coordination of and the extent to which these activities are performed. Several methodologies for centralised and decentralised OE have been proposed in the past two decades [SMB10]. Most of them focus on the centralised development of static ontologies by a small ontology engineering team, which includes an ontology engineer and domain experts from one or different stakeholders as users. Examples are METHONTOLOGY, IDEF5 and OTK [IAMS13]. Recent work in this area suggests the development and usage of domain-specific ontology design patterns [VIK15], though there are no best practices of OE available yet for the manufacturing domain. In case of decentralised or distributed OE, the OE team is dispersed over several geographic locations and affiliated to different organizations like in CREMA. The distributed development is typically supported by web-based tools such as OntoLingua Server [FFR97], WebProtégé [TNNM13], wikis, and tagging [BSW07]. Prominent example





14 / 72


of a methodology for distributed OE is DILIGENT [PST04], which in particular recommends an argumentation model for concensus finding on the conceptual model. Approaches to iterative crowd-sourced OE are still rare [MMN13, NMAM13]. A critical account on ontology engineering with linked data sets is in [CPG15]. Distributed engineering of the CDM-Core. The distributed engineering of the shared CDM-Core ontology has been performed by task partners according to the DILIGENT methodology [PST04]. In addition to the usual digital communication means (E-Mail, Skype), the partners also used the web-based OE tool WebProtégé [TNNM13]5 in virtual meetings for their collaborative development of CDM-Core. Figure 2 shows the distributed and cyclic development process of the CDM-Core with its main activities and roles of partners involved.

Figure 2: Distributed CDM-Core ontology engineering process

The roles of the task partners in this OE development process are as follows: The role of ontology engineer taken by DFKI includes (a) the support of domain analysis and conceptualisationof knowledge, (b) the formalisationof the conceptual model in OWL2, and (c) technological evaluation of the CDM-Core. The partners IKER, FAGOR, GOIZ, TCO and TANet act as domain experts and users of the CDM-Core. All task partners are members of the control board for ontology analysis, revision and evaluation. The formalisationof conceptual models was done by the ontology engineer. The ontology engineering team members come from all task partners. The CDM-Core ontology engineering process is cyclic and comprises the following steps and activities (see Figure 2):

1. Build: The ontology engineering team builds a very small and basic consensual version of the CDM-Core ontology. Main activities are an initial domain analysis for both use cases and creation of an initial conceptual model of CDM-Core. These initial activities are carried out by the domain experts intensively supported by the ontology engineer. The resulting conceptual model is a knowledge graph together

5 http://protegewiki.stanford.edu/wiki/WebProtege





15 / 72


with its abstract OWL notation, and formalisationin logic-based OWL2-DL. This basic shared CDM-Core is evaluated by domain experts and ontology engineer.

2. Local refinement: The domain experts perform an in-depth refinement of the shared CDM-Core version at their local site. Main activities concern the more detailed domain analysis and refinement of the conceptual model of CDM-Core per use case. These activities are carried out concurrently and at geographically dispersed sites by partners IKER, FAGOR, GOIZ for CREMA use case I and TCO and TANet for CREMA use case II. The result is a set of two local ontologies, each of which created independently by domain experts for the individual use cases by means of CDM-Core profiling (see Section 2.4). These ontologies are formalised by the ontology engineer during or immediately after each local refinement. Both local ontologies are evaluated by domain experts and ontology engineer.

3. Analysis and revision: The control board analyses the two locally refined ontologies and revises the shared CDM-Core ontology accordingly. Main activities are the manual identification of similarities between elements in both local ontologies and their respective alignment in the CDM-Core. Examples of alignments are equivalence statements (owl:EquivalenceClass, owl:SameAs) and the merging of concept definitions into one. This analysis is jointly done by the domain experts, while the ontology engineer formalises and technically evaluates the new consensual version of the shared CDM-Core.

4. Local update: Once a new CDM-Core version is released, the domain experts update their local ontologies and perform a further local refinement (step 2.).

During the domain analysis in the first process step the task partners

• agreed on the requirements for the CDM-Core (see Section 2.1), in particular to focus on a first, coarse-grained but correct modeling of the semantics of given process models and sensor data of the CREMA use cases (see deliverables D7.1, D7.2 and D8.1, D8.2), and,

• developed and discussed the process models of the CREMA use cases in BPMN and their informative descriptions (see Annexes 1 and 3),

• checked relevant technical specifications of machines, sensor data log and schema (see Annex 5), and

• searched for and selected relevant standard data models and ontologies. As mentioned above, main requirement of the current version of the CDM-Core is to represent domain knowledge for describing the semantics of given process models and sensor data of the CREMA use cases (see Annexes 1, 3, 5). The user partners informed that for the considered processes and sensor data in the use cases currently no standard data models are used at their sites. Process services which implement the given process models of are still to be described by user partners. Semantic annotation of process models and services based on the CDM-Core is supported by CREMA components PDE and CVA (see deliverables D3.2, D3.3). The result of the initial search and assessment of relevant non-semantic standard data models carried out by the task partners is shown in Table 1. In particular, the main domains of listed data models according to their public description are shown in the column “Domain Coverage”, and their potential relevance for the semantic description of





16 / 72


the given process models for the two use cases in the column “Use Case”. Besides, in column “Public Reuse” the availability of these data models for their translation (e.g. to OWL2) and inclusion into the publicly available semantic data model CDM-Core is shown.

Table 1: Selected non-semantic standard data models for CREMA use cases Data Model Standard

Org Modeling Language

Domain Coverage Use Case

Public Reuse

ISO 13372:20126

[ISO 2041,

17359:2011]

ISO/IEC UML

Txt/Tab

Condition monitoring and diagnostics of machines, predictive maintenance

1, (2) (Y):

Informative sections

ISO 10303 (STEP) APs7

ISO UML

EXPRESS8

EXPRESS-G

AP214 in AP242:2104 - Core data for automotive mechanical design processes9

AP239 - Product Life Cycle Support

AP224 - Mechanical product definition for process plans

AP240 - Process plans for machined products

2

1, 2

N

ISO STEP PDM Schema V1.210

ISO

PDM Implementor Forum

Graphical notation, Txt/Tab

Product data management (common subset extracted from STEP APs 214, 203, 212, 232)

1, 2 (Y)

UN/CEFACT CCL11, UNTDED-ISO 7372

UN/CEFACT,

ISO

Graphical notation, Txt/Tab, XML(S)

Supply chain and cross-border trading transaction messages for buy, ship and pay business processes

1 Y

ASD S-2000M12 V6.013

ASD UML

Txt/Tab

Material management incl. spare parts, focus on aerospace

(1, 2) N

6 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52256 7 https://en.wikipedia.org/wiki/ISO_10303#Coverage_of_STEP_Application_Protocols_.28AP.29 8 https://en.wikipedia.org/wiki/EXPRESS_(data_modeling_language) 9 http://www.ap242.org/pdm-interoperability 10 http://www.steptools.com/support/stdev_docs/express/pdm/pdmug_release4_3.pdf 11 http://tfig.unece.org/contents/uncefact-ccl.htm, http://tfig.unece.org/contents/semantic-harmonisation-standards.htm 12 http://www.s2000m.org/ 13 http://www.s2000m.org/S2000M_V6.0/PreRelease%20Issue%206.0%20--%2012122013.pdf





17 / 72


industry

ISA-8814 UML

Txt/Tab

B2MML15

Batch control configuration and communication between components in batch manufacturing plants

(2) N

ISA-9516

ANSI/ISA UML

Txt/Tab

B2MML

Business logistics and manufacturing control incl. production scheduling, maintenance management - at the level of enterprise, site, area

1, (2) N

ISO 316617

ISO 421718

ISO Txt/Tab, XML

Country and currency codes

1, 2 Y

Many of them are not available for public reuse in the public shared CDM-Core (see Section 2.1, requirement 1d): Their access to and usage are bounded by strict copyright protection and availability for a purchase fee. Examples are the renown ISO STEP (Standard for the Exchange of Product model data) 10303 data models (so called application protocols AP) for the manufacturing domain, the ASD S2000M data model series for describing material management processes, and the ISA (International Society for Automation)-95 data model series which defines activity models of manufacturing operations management. Each of these standard data models is copyrighted by its standardisation organisation and not freely available. As mentioned above, the user partners so far do not use any standard data model for describing the process models and sensor data of the CREMA use cases. In regard to the first use case, the task partners initially selected and translated relevant public parts of the ISO/IEC 13372 standard for machine condition monitoring and predictive maintenance to OWL2. The resulting standard-based semantic data model, called CM, is included in the CDM-Core (see Table 2). The EXPRESS schemas of ISO 10303 are freely available19 but the semantics of all labels in these schemas are defined in the respective copyrighted standard documents. A selection of elements from EXPRESS schemas translated to OWL2 for a more fine-grained modeling of process and sensor data of the CREMA use cases in an updated CDM-Core is under discussion between the task partners. The same holds for the publicly available parts of (a) the ISO 10303 STEP PDM (Product Data Management) schema and (b) the UN/CEFACT standard model CCL (Core Component Library20 with TDED Trade

14 https://www.isa.org/isa88/, https://en.wikipedia.org/wiki/ISA-88 15 http://www.mesa.org/en/B2MML.asp 16 https://www.isa.org/isa95/, https://en.wikipedia.org/wiki/ANSI/ISA-95 17 http://www.iso.org/iso/country_codes 18 http://www.iso.org/iso/home/standards/currency_codes.htm 19 http://www.steptools.com/support/stdev_docs/index.html 20 http://tfig.unece.org/contents/uncefact-ccl.htm,





18 / 72


data elements directory21 for semantics of supply chain messages). For example, the STEP PDM standard could be used to detail the basic concepts in the CDM-Core for products of user partners in the CREMA use cases like “Exhaust” and spare parts. The TDED vocabulary could be used to detail, for example, the concept “Supplier” (see Annex 1, process task SB7). In any case, that would require a manual or tool-supported translation of informal and EXPRESS schema descriptions into the formal semantic data modeling language OWL2 of the CDM-Core by the task partners. Approaches and examples for the (partial) translation of standard data models in UML and STEP-EXPRESS to OWL2 are presented in [KP14, ZL14, ZJL12]. Tools for translating XML to OWL2 [KMSBKP15], and EXPRESS schemas to OWL2 are available such as the UniSTEP22 toolbox and OntoSTEP23 with Protégé plug-in24. In [KPEZW12], the informal semantics of EDIFACT message schemas are manually transformed into business information ontologies and metadata ontologies in OWL2-DL but not yet publicly available. The results of the initial search, assessment and selection of relevant semantic data models carried out by the task partners are shown in Table 2. Many of these ontologies are available for public reuse and have been properly integrated in the current version of the CDM-Core. Examples are the standard ontology W3C SSN [C+11] for sensory and sensor networks, the upper ontology MASON [LSDS06] for the manufacturing domain in general, as well as the quasi-standard upper ontology DUL for concepts of physical entities, temporal and spatial relations, and the W3C standard ontology GeoNames for geolocation information. There are several other relevant manufacturing domain ontologies [MD08] in OWL2 such as the SCORVoc and ONTO-PDM [PDC12]. SCORVoc is a translation of the SCOR M standard for supply chain management related concepts to OWL2. ONTO-PDM is a translation of the IEC 62264 and ISO STEP 10303 standards for manufacturing product management into OWL2. The inclusion of (parts of) these standard translations in the public CDM-Core is prohibited by the copyright protection of the standards25; responses from APICS and ISO to our requests in this regard are still pending. The three domain ontologies CM, CDM-UC1 and CDM-UC2 listed in Table 2 have been developed by the task partners especially for describing the semantics of the given process models and sensor data of both CREMA use cases.

Table 2: Selected semantic data models and extensions for CREMA use cases Ontology Language Type Relevant Domain

Coverage Standard Extens. Use

Case Public Reuse

SSN26 OWL2 Domain Sensory, Sensor Networks

W3C DUL27 1, (2) Y

MASON28 OWL2 Upper Manufacturing 1, 2 Y

http://tfig.unece.org/contents/semantic-harmonisation-standards.htm 21 http://www.unece.org/fileadmin/DAM/trade/untdid/UNTDED2005.pdf 22 http://gris-public.uninova.pt:8080/funStepServices/EXP2OWL.jsp 23 http://www.nist.gov/el/msid/ontostep.cfm 24 http://sourceforge.net/projects/osexpress/?source=typ_redirect 25 In only very few cases minor parts of these ontologies were published in research papers 26 http://www.w3.org/2005/Incubator/ssn/ssnx/ssn 27 http://www.w3.org/2005/Incubator/ssn/wiki/DUL_ssn 28 http://sourceforge.net/projects/mason-onto/





19 / 72


DUL29 (DOLCE+DnS Ultralite)

OWL2

Upper

Concepts of physical and social context, temporal and spatial relations

W3C

1, 2

Y

GeoNames30

OWL2 Domain Geolocation W3C 1, 2 Y

ONTO-PDM [PDC12]

OWL2 Upper Manufacturing product data

IEC 62264, ISO 10303

(2) N

SCORVoc31 OWL2 Domain Supply chain operations reference (SCOR)

APICS32 (1) (N)

CM OWL2 Domain Condition Monitoring, Machinery Maintenance

ISO/IEC 13372

SSN 1, (2) Y

CDM-UC1 OWL2 Domain Machinery Maintenance at FAGOR

CM

MASON

DUL

1

Y

CDM-UC2 OWL2 Domain Robotic production of car exhausts at TCO

SSN

MASON

DUL

2

Y

For the conceptual modeling of the two main use case-specific domains in the CDM-Core, the partners applied an integrated top-down, middle-out and bottom-up approach [SSS09]. In particular, the domain experts first manually extracted relevant basic concepts and relations from their informal descriptions of process models and machines of the CREMA use cases (bottom-up). For these words, the selected ontologies (see Table 2) were manually analysed in order to either identify semantically matching concepts, or to newly define such concepts (top-down) and refine them later on by means of generalisation and specialisation (middle-out). During the second step, the initial CDM-Core was locally refined by the domain experts from the user partners FAGOR, GOIZ, and TCO for the two CREMA use cases. As mentioned above, the resulting two local ontologies (CDM-UC1 and CDM-UC2) were analysed by the control board. In particular, the board tried to find similarities in both ontologies and to make a balanced decision for the revision of the shared CDM-Core. As usual, the necessary communication among the geographically dispersed partners was realised with means for virtual meetings (GotoMeeting, Skype, E-Mail) and physical face- 29 http://ontologydesignpatterns.org/wiki/Ontology:DOLCE+DnS_Ultralite 30 http://www.geonames.org/ontology/documentation.html 31 https://github.com/vocol/scor 32 http://www.apics.org/sites/apics-supply-chain-council/frameworks/scor





20 / 72


Figure 3: Abstract view of CDM-Core knowledge graph with share of reuse of public semantic data models (in black) and CREMA extensions (in blue)

to-face meetings at project meetings. Collaborative modeling and analysis of the CDM-Core was done partly by using the tools MS-Visio, MS-PPT, WebProtégé. In regard to the choice of the modeling language for the CDM-Core ontology, it turned out that the semantic description of some concepts in the CREMA use case domains require the expressiveness of the standard W3C OWL2 dialect OWL2-DL (see Annex 6). An example of such a concept in the CDM-Core is given in the next Section in Figure 9. The following Section describes the first version of the CDM-Core, which is the result of several rounds of the distributed ontology engineering process as described above.

2.3.2 CDM-Core Description Overview. The public shared CREMA manufacturing domain ontology CDM-Core represents domain knowledge of both CREMA use cases. It allows to describe the semantics of the current process models (see Annexes 1 to 4) and sensor data (see Annex 5) of the CREMA use cases. The CDM-Core is specified in the standard W3C ontology language OWL2, specifically in its dialect OWL2-DL (see Annex 6), which is expressive enough for this purpose. It extends and bases on selected relevant public standard data models (see Tables 1 and 2). Besides, the CDM-Core is consistent and has been positively evaluated by the user partners with respect to its use for semantic annotation of given process models and sensor data. In this respect, the current version of the CDM-Core satisfies all of its requirements (see Sect 2.1, requirements 1a)-d)) and will be updated in a final version at M18.

This technical diagram is available at https://go.ascora.de/d41_Figure-3.png





21 / 72


Figure 3 provides an abstract view of the knowledge graph of the mid-sised CDM-Core and the extent to which relevant data models are reused. The CDM-Core contains about 1000 concepts and relations, and 140 individuals. More than half of the concepts were defined by task partners specifically for the semantic annotation of the process models and sensor data of the CREMA use cases. More statistics on the CDM-Core and its parts or sub-ontologies (named graphs) are provided in Table 3. It provides the number of axioms (SubClassOf, EquivalentClass, DisjointClass), classes (concepts), object properties (relations), individuals, and expressiveness of description logic-based definitions of concepts (DL exp.), as well as the size of the RDF encoding before and after the logical materialization33 of CDM-Core in a triple store.

Table 3: Statistics of CDM-Core and its parts

The CDM-Core contains a) the top-level manufacturing ontology MASON [LSDS06], (b) the standard W3C SSN ontology for sensory and sensor networks, (c) the DUL ontology for physical and social context, (d) the standard-based CM ontology for condition monitoring and maintenance, and (e) the CREMA use case specific ontologies CDM-UC1 (Fagor/Goizper) and CDM-UC2 (Tenneco). The SSN, MASON, and DUL are summarized in Annex 7 and the remaining parts of CDM-Core are presented in the following.

33 Logical materialization of an ontology includes the logically deduced implicit knowledge (transitive closure).





22 / 72


CDM-Core part for condition monitoring. The CDM-Core includes a part which represents domain knowledge about machine condition monitoring and predictive maintenance (CM). This part was developed by the task partners based on (a) the input from domain experts of CREMA user partners, (b) the standard semantic data models W3C SSN for sensory and sensor networks, and (c) the public informative sections of the standard data model ISO 13372 (ISO 2041, 17359:2011) for condition monitoring and predictive maintenance (see Table 2). The CM part of CDM-Core represents general domain knowledge on (a) machine components, sensors and measured properties, (b) machine condition, faults, symptoms, and their causal relations. It is used for modeling domain knowledge on condition monitoring in both CREMA use cases. CDM-Core part for CREMA use case I. The CDM-Core represents domain knowledge of condition monitoring and predictive maintenance in the CREMA use case I (see D7.2). This part of the CDM-Core is called CDM-UC1. For modeling the CDM-UC1, task partners identified the main concepts and relations that are needed to describe the semantics of process models (see Annex 1) and the sensor data of the sensory attached to the metal press (see Annex 5). As a result, the CDM-UC1 contains about 750 concepts and relations in total. Of these, about 80 specifically describe the metal press system and its sensory, maintenance actions and entities involved in them in CREMA use case I. Figure 4 shows a representative part of the CDM-UC1 with respect to its share of reused concepts from other relevant ontologies. In this figure34 the concepts colored in orange are reused from the ontology MASON, in yellow from the own developed ontology CM, in green from the W3C SSN, and the newly defined for the use case-specific part are colored in light blue.

34 This technical diagram is available at https://go.ascora.de/d41_Figure-4.png

Figure 4: Part of CDM-Core for CREMA use case I





23 / 72


The semantic annotation of the given process models and sensor data of this use case based on the CDM-UC1 of CDM-Core is described in Section 2.6.1. Figure 5 shows some of the condition monitoring related part of CDM-UC1.35

Figure 5: Part of CDM-Core for condition monitoring in CREMA use case I

For example, the causal relations between the general concepts of machine component conditions, faults and observable symptoms per machine working cycle interval are modeled according to the relevant ISO13372 standard. The shown machine component in Figure 5 is an oil pump of a hydraulic drive system of machines like the metal press at FAGOR in CREMA use case I (see Annex 5). A typical fault of a hydraulic machine in a bad condition is an internal oil pump leakage. This fault is indicated by the occurrence of several symptoms such as insufficient static pressure after load of the system. The values for the property “Pressure” related (“hadMonitoredProperty”) to this symptom “Static_Pressure_After_Load” are observed by an instance of class “Pressure_Sensor”, that is the specific pressure sensor “fag:Pressure_sensor_APPLICATION_3”.






24 / 72


Use case-specific definitions of conditions, faults, and symptoms for the metal press system are not yet available from FAGOR/GOIZ. However, the given sensor data schema for the sensory of the metal press system is represented in the CDM-UC1; the respective mapping of sensor and property names is shown in Table 4 in Annex 5. According to the given use case-specific process models (see Annex 1), the condition-based maintenance of a metal press at FAGOR is carried out by a so called TAS (Technical Assistance Service) team if an alarm is triggered by the detection of some fault symptom. hese and other relevant concepts and relations are modeled in the CDM-UC1. In particular, a metal “Press” has a component “Clutch_brake”, which is a main type of “Spare parts” for FAGOR. If required, the clutch brakes of presses are maintained by a “subcontractor” of FAGOR such as GOIZ. To detect a critical “Condition” of these machine components, the monitored data of a set of “Sensors” that are attached to the components is analysed with respect to given “Thresholds” and “KPIs” that are calculated according to so called “Business rules”. These rules are restricted to the user partner GOIZ. Therefore, the public CDM-Core includes an example of conditions, fault and related symptoms of a typical hydraulic drive of which the one of the metal press is a special case. The scheduling of maintenance is triggered only if a reported “Alarm” gets confirmed by the “TAS_Manager” as a “Real_Alarm”. The concept of “Maintenance” covers different aspects such as its regulating “Contract”, the “Requirements” expressed by the “Customer” that owns the press, the human resource “TAS_team” for maintenance actions according to an agreed “Schedule” which depends also on the availability of the required “Spare part”. After the maintenance has been carried out a “Report” is filed in order to inform the involved “Stakeholders”, that are the TAS_Manager and the customer, about the result.





25 / 72


Figure 6: Semantic description of concept “Alarm” in the CDM-Core knowledge graph (bottom), description logic OWL2-DL (middle), and OWL2 abstract syntax (top)





26 / 72


Figure 6 shows the definition of the concept of an “Alarm” in abstract OWL2 syntax (see the part of Figure 6 on page 24), in formal logic-based OWL2-DL notation, and its context in the knowledge graph of CDM-UC1. CDM-Core part for CREMA use case II. The CDM-Core also represents domain knowledge of the CREMA use case II (see deliverable D8.2). This part of the CDM-Core is called CDM-UC2. For modeling the CDM-UC2, task partners identified the main concepts and relations that are needed to describe the semantics of process models for car exhaust production and testing at the shop floor of TCO (see Annex 3). The semantic annotation of the given process models is described in Section 2.6.1. The current version of the CDM-UC2 is shown in Figure 736, where concepts colored in orange are reused from MASON, in green from W3C SSN, and the use case-specific part is colored in light blue.

Figure 7: Part of CDM-Core for CREMA use case II

In particular, the CDM-UC2 describes concepts and relations of robot cells, robots and sensory for condition monitoring, KPI computation, and other operations of the TCO manufacturing line for exhaust production and testing. Sensors are attached to a robot or robot cells. For the robot, a welding temperature sensor is modeled according to its specification. Additionally, the rotation speed (rpm) of robot motors is sensed. Both, motors






27 / 72


and temperature sensor are defined in the CDM-UC2 by specialising from concepts in the W3C-SSN part of CDM-Core. Besides, sensors and tags required to enable location tracking are also modeled. The functionality of a robot in terms of its operations is defined with appropriately extended concepts and relations taken from the manufacturing upper ontology MASON. These extensions were done by means of sub-classing and introducing new relation types for covering the special robots, the welding process and related physical objects, as well as abstract concepts. In addition, the Tenneco organisation and locations are modeled in CDM-UC2 in order to support location-based decision-making in the context of the CREMA use case I later on.

Figure 8: Semantic description of a TCO shopfloor robot in the CDM-Core knowledge graph (top), description logic OWL2-DL (middle) and OWL2 abstract syntax (bottom)





28 / 72


The definition of KPIs, in particular OEE (Overall Equipment Effectiveness), are also modeled in the CDM-UC2. They will serve the ODERU component as a basis for optimisation of robot cell allocation according to a production schedule. Figure 8 shows an example of different notations of a semantic description of a domain-specific concept in the CREMA use case II. In particular, the semantics of a robot concept can be described (a) in graphical notation as part of the CDM-Core knowledge graph, (b) in abstract OWL2 syntax, and (c) the corresponding formal notation in the description logic OWL2-DL (see Annex 6). Besides, the alternative standard modeling languages RDF and RDFS are not sufficiently expressive for the definition of this concept (see Section 2.1, requirement 1c).

2.4 CDM-Core Profiles Users of the CDM library can contribute to the CDM-Core ontology in terms of so called CDM-Core profiles (see Figure 1, Section 2.1). These profiles represent individual views on the domains that are represented in the CDM-Core. A profile is created by an user through means of individual subsetting, modifying, and updating of the public shared CDM-Core. These means for CDM-Core profiling are implemented by the CDM library component, that is the CREMA component DLP (see Section 3.2.1). An example sequence of actions for user-specific CDM-Core profiling is shown in Figure 9.

Figure 9: Example of CDM-Core profile creation by user

In the example of Figure 9, a user is interested in contributing to the part of the CDM-Core which represents knowledge about the condition monitoring domain. For this purpose, the





29 / 72


user selects the keyword “CM” for condition monitoring from a keyword list provided by the DHS user interface. This list contains the domain keywords of all named graphs in the CDM-Core. The DLP returns for one or multiple named graphs stored in the central triple store for the CDM-Core37 which domain keywords are (exactly) matching the given one. The relevant graphs are automatically wrapped in one special named graph, which is the initial user-specific CDM-Core profile and non-persistently stored in a separate triple store. The user then can perform a sequence of CRUD operations on this profile and commit the result back to the CDM-Core. In the example, the user first adds some instances and concepts, then modifies the definition of a concept, deletes some concept properties, and finally commits the resulting named graph to the CDM-Core. For the commitment of CDM-Core profiles of multiple users to the CDM-Core, the DLP follows a simple MRU (most recent update) policy. In addition, the CDM-Core profile metadata is either newly created or updated in a separate database (see Section 2.5). Figure 10 shows the committed update of CDM-Core by one user from the perspective of another user (Figure 10: ORIGINAL, FINAL).

2.5 CDM-Core Metadata The CDM library contains two types of CDM-Core metadata (see Figure 1 in Section 2.1):

(1) Provenance and domain about each named graph of the CDM-Core and the user-specific CDM-Core profiles

37 Note that the CDM-Core is an aggregation of named graphs (see Figure 1 in Section 2.1) each of which attributed with a list of keywords for domains it represents knowledge about.

Figure 10: Update of CDM-Core based on user-specific CDM-Core profile





30 / 72


(2) CDM-Core statistics and history of CDM-Core profiling The CDM-Core and the CDM-Core profiles are stored in separate triple stores each of which are accessible via a SPARQL endpoint (see Section 2.4). Since any update of the first type of metadata causes a computationally expensive materialisation of the respective triple store, this metadata is considered rather static. The second type of metadata is considered more dynamic with high frequency of updates. For reasons of efficiency, this metadata is stored in a standard high-performance relational SQL database like Postgres. The simple relational schema and example for the metadata on the CDM-Core statistics and profiling is shown in Figure 11. The relation Ontologies_Statistics stores the current size of the CDM-Core in terms of the number of concepts and properties and triples. The relation Users_Contributions informs about the user contributions to the CDM-Core (history of changes done by the user): It identifies the changed element (URI, Subject_type) of a named graph (Ontology_ID) in the CDM-Core, and the respective profiling operation, such as addition, modification or removal (Contrib_type) that has been performed at a specific time (Timestamp). The status of the element before and after the operation is indicated. Finally, the relation Users_Ratings provides information on the individual rating of relations between concepts of the CDM-Core by users. That can be used, for example, to determine some kind of “popularity” value for relations of type (A owl:sameAs B) or EquivalentClass(C1, C2) by users, and for user-biased semantic similarity computations (see Section 2.6.4). Metadata about provenance and domain of each of the named graphs that are aggregated in the CDM-Core are described in its properties with the standard metadata vocabulary DublinCore (DC)38 encoded in OWL239. Figure 12 shows a part of this kind of metadata definition in the CDM-Core knowledge graph. This technical diagram is available at https://go.ascora.de/d41_Figure-12.png 38 http://dublincore.org/documents/dcmi-terms/ 39 More concretely in OWL2 under OWL-Horst semantics, i.e. the OWL2-compatible part of RDFS.

Figure 11: Relational schema for CDM-Core metadata





31 / 72


Figure 12: CDM-Core part for provenance and domain metadata definition





32 / 72


2.6 CDM-Core Ontology Usage The main purpose of the first basic version of the CDM-Core is to represent manufacturing domain knowledge for the semantic description of given process models (see Annexes 1 and 3) and sensor data (see Annex 5) of both CREMA use cases (see Section 2.1, requirement 1a). According to the user partners, the represented domain knowledge in the CDM-Core and the semantic annotation of the process models based on the CDM-Core (see Annexes 2 and 4) are correct. This section presents examples of semantic annotations of process models, services, and sensor data of the CREMA use cases based on the CDM-Core. This is complemented with examples of how these semantic annotations can be used by other CREMA components in the CREMA use cases.

2.6.1 Semantic Annotation Semantic annotation of process models. In CREMA, the process models are denotated in the standard BPMN (Business Process Model Notation). The formal semantics of a process model in BPMN can be described by means of its annotation with elements of formal ontologies that are defined, for example, in standard OWL2. Such annotation allows applications to semantically reason on them in general, and assist process managers in their semantic service-based implementation in particular. Services can be more precisely selected and automatically composed for implementig a given process model based on its semantic annotation (see Section 2.6.2). This is in line with the well-known semantic SOA paradigm and reference model [O08]40. In CREMA, the component ODERU performs an optimal service-based implementation of given process models with advanced means of semantic service selection and planning. That requires the semantic annotation of both process models and available services. The semantic annotation of process models based on the CDM-Core is manually done by the process manager with the PDE with support of the SVA. There is no standard format for the semantic annotation of process models in BPMN yet [BBLP15]. On an abstract level, the semantics of processes and services can be basically described in terms of their input (I), output (O), precondition (P) and effect (E) of their execution. The result is a so called black-box view or semantic IOPE-based description of processes. In particular, the task partners first informally described the basic IOPE semantics of all process tasks of given process models in the CREMA use cases. These informal semantic descriptionsemi-formal description consists of text including relevant main concepts which were either identified in or newly added to the CDM-Core for this purpose. Next, these semi-formal descriptions were manually transformed into the formal semantic IOPE-based annotations with CDM-Core. The process models of both CREMA use cases with semantic annotations based on the CDM-Core are provided in the Annexes 1 and 2, respectively, 3 and 4. Figure 13 shows an example of a semantic IOPE-based annotation of two process tasks of the first process model of the CREMA use case I (see Annex 1) with concepts that are defined in the CDM-Core. The first task, named SA1, captures the activity of collecting the machine data, in

40 Semantic SOA is considered key to the development of semantics-empowered intelligent applications for the future Internet in various domains including manufacturing 4.0, and supported by an increasing number of industrial stakeholders such as Software AG, SAP, IBM, Siemens.





33 / 72


particular, the sensor data of the monitored metal press system at FAGOR. The data collection requires the considered metal press system as an input and returns the raw sensor data as output. As a precondition of the data collection, the metal press has to be in a working status, while the task itself has no specified effect on the process environment. The second task, named SA2, takes the raw data produced by the first task and a data processing algorithm as input and returns the result of the data processing as an output, subject to the executability of the chosen algorithm with the given data. This semantic annotation was made with the CDM-UC2 of CDM-Core (see also Figure 5). Figure 14 shows an example of a semantic IOPE-based annotation of one process task of the second process model in the CREMA use case II. In particular, this process task is concerned with the resource allocation of a suitable robot (see Annex 3, Process model “Resource Allocation”). Given a production schedule containing a list of orders to be fulfilled by user partner TCO, this task identifies a robot cell and corresponding robot, and blocks it for the schedule. A robot must be able to perform welding operations and has to be equipped with particular clamps to hold a certain type of exhaust as specified in the tasks of the schedule. Besides the production schedule input, the robot cell and robot outputs, and a range of internal variables are included in order to specifiy the requirements described above. This semantic annotation was made with the use case specific part CDM-UC2 of CDM-Core (see Figure 7). Listing 1 provides an example of the semantic annotation of the process task in Figure 14 as BPMN XML extension in the BPMN source code. Additional attributes named inputs, outputs, preconditions and effects are used to attach the semantic annotations to the standard BPMN definitions.

Listing 1: BPMN XML source code of an annotated process task

<?xml version="1.0" encoding="UTF-8"?> <bpmn:definitions …> … <bpmn:task id="Task_1w5d3zt" name="Select Robot Cell" xmlns:tco=http://www.crema-project.eu/ontology/wp8/tenneco.owl# xmlns:mas="http://www.owl-ontologies.com/mason.owl#" inputs="tco:ProductionSchedule :PS" preconditions="tco:includes(:PS,:T) and tco:ProductionTask(:T) and tco:includes(:T,:OP) and mas:requiresTool(:OP,:TOOL) and tco:Welder(:TOOL) and tco:produces(:OP,:EX) and tco:Exhaust(:EX)" outputs="tco:RobotCell :CELL (tco:Robot and tco:supports some tco:ExhaustClamp and tco:supports some tco:Welder) :R" effects="tco:isAllocatedFor(:CELL,:PS) and tco:includes(:CELL,:R) and tco:supports(:R,:TOOL)"> <bpmn:incoming>SequenceFlow_0egvn5w</bpmn:incoming> <bpmn:outgoing>SequenceFlow_03haiqx</bpmn:outgoing> </bpmn:task> … </bpmn:definitions>





34 / 72


Figure 13: Example of semantic annotation of a process model of CREMA use case I





35 / 72


Figure 14: Example of semantic annotation of a process model of CREMA use case II





36 / 72


Semantic annotation of process services. According to the semantic SOA paradigm, process models can be implemented with executable services which semantics are described with a shared formal ontology. The implementation of each step or task of a process model with a relevant single or composite service by a process designer can be supported by means of automated high-precision semantic selection and planning of annotated services (see Section 2.6.2). Services which are assigned to a process task or a whole process model are called process services. Depending on the nature of a process service, it can run either fully automated without any user interaction, or semi-automated with user interaction. Semantic services are services whose functional and non-functional semantics are described with formal ontology-based annotations. On an abstract level, a semantic service description includes a semantic IOPE-based profile and a semantic process model that describe what this service does and how it actually works [K08]. In CREMA, services can encapsulate any kind of functionality ranging from a robot control to a sensor device. Services are stored in a directory of the CREMA service marketplace component MPM. Since the CDM-Core is defined in OWL2, one natural choice of the semantic service description format would be OWL-S (Web Ontology Language for Web Services) which allows a grounding of semantic services in WSDL or REST services.41 As mentioned above, semantic service descriptions are used by the CREMA component ODERU to determine a functionally optimal assignment of services to given annotated process models at design time and runtime on request by the PDE and PRU component.

41 Alternatives are the W3C standard SA-WSDL (Semantic Annotations for WSDL and XML Schema), WSML (Web Service Modeling Language), USDL (Unified Service Description Language), Linked USDL, as well as the microformats hRESTS, SA-REST, and MicroWSMO [K08].

Figure 15: Example of semantic annotation of service “Pick Robot Cell”





37 / 72


The set of potential process services for both CREMA use case scenarios still has to be identified by the user partners. Figure 15 shows an example of an abstract IOPE description of the semantics of a possible service “Pick Robot Cell”. The service annotations are based on the CDM-Core, in particular the CDM-UC2 part of it (see Section 2.3.2). This service accepts as input a production schedule and returns as an output a TCO manufacturing plant cell that hosts a robot which is capable of welding exhaust clamps. The precondition of its execution is that the considered schedule includes a task of producing an exhaust with required tool for welding. The effect of executing this service would be that a cell which is located in the TCO manufacturing plant and equipped with the requested robot is allocated to the received production schedule. How this semantic service can be automatically selected as functionally most relevant for the annotated process task shown in Figure 14 is explained in Section 2.6.3. This selection is based on the comparison of their formal semantic annotations with CDM-Core. Semantic annotation of sensor data. In CREMA, the CDM-Core can also be used to semantically annotate sensor data of CREMA use case I. As mentioned above, the user partner FAGOR provided very general information about the metal press system, its components and attached sensors, as well as the sensor data schema (see Annex 5). The given data schema for the stream of timestamped and sequentially ordered data buckets is in the format TSV (Tab Separated Values)42. In particular, each sensor observes or measures one property such as pressure or temperature. The semantic annotation or RDF-encoding of streamed sensor data is automatically done by the ODERU component with the CDM-Core. That requires the mapping of the sensor measurement label to the concept in the CDM-Core ontology, which defines the formal semantics of this label in XML-RDF encoded OWL2. As a result, the data item is described by a set of RDF triples as an instance of the corresponding concept in the ontology. This mapping table and respective naming of sensor classes and measurements in the CDM-UC1 part of CDM-Core is given in Annex 5. Figure 16 presents an example of semantic annotation of multi-variate sensor data from eight sensors attached to the hydraulic drive system of a metal press at FAGOR in CREMA use case I. Regarding CREMA use case II, there is currently no sensor data schema given by the user partner TCO. The project partner Ubisense plans to produce some location-based sensor data stream for tagged assets (robot, machine, tool) of the shop floor at TCO. However, the schema and semantics of this sensor data stream have not been defined yet by TCO and Ubisense. The potential usage of the location-based sensory of Ubisense also in the CREMA use case I has to be investigated. The semantic annotation of sensor data with the CDM-Core allows for a qualitative, that is domain knowledge-based, rather than quantitative statistics-based data interpretation. The combination of qualitative and quantitative sensor data analysis is a topic of research on intelligent condition monitoring in general and semantic fault diagnosis online, in particular. Research on using means for semantic sensor data processing to support process optimisation at runtime is carried out in Task 5.5 (see also Section 2.6.3) . 42 http://www.cs.tut.fi/~jkorpela/TSV.html. An alternative to TSV is the W3C standard data model for CSV (Comma Separated Values); W3C RFC4180; http://www.w3.org/TR/tabular-data-model/:





38 / 72


Figure 16: Example of semantic data stream annotation in CREMA use case I





39 / 72


2.6.2 Optimal Semantic Selection of Process Services In CREMA, the ODERU component provides means for optimising service-based manufacturing processes at design time and runtime. An optimal implementation of BPMN process models with services can be realised with respect to functional and non-functional aspects. Functional optimisation of a given annotated process model is performed with means of high-precision semantic selection and automated composition planning of services [KKZSZ15, K08b]. Non-functional optimisation of process models concerns the process KPI-driven optimisation of their service plan with respect to given objective function (min/max) and constraints on its (KPI) variables like cost, time, and OEE (Overall Equipment Effectiveness). The ODERU can assist the process designer (PDE) in the optimal implementation of BPMN process models with services at design time. In addition, ODERU supports the process execution environment PRU by trying to find an optimal replacement of services which execution failed. Semantic selection of services encompasses (a) the pairwise semantic matching of the given annotated process with each annotated service that is registered in the service directory of the MPM component, and (b) the semantic relevance ranking of these services for the process. There are several means for high-precision semantic selection of services available, in particular for semantic services in OWL-S. More details are given in, for example, the survey of the field in [KKSLB15]. In general, semantic service selection encompasses (a) the pairwise semantic matching of a given service request with services in a service directory, and (b) the semantic relevance ranking of these services. Listing 2 shows the definitions of three prominent types of logic-based plugin matching of a service request Q with a service offer S. These matching filters are inspired by the classical plugin matching of components in software engineering.

Figure 17 shows an example of a successful logic-based IOPE-plugin match of an annotated concrete service “Pick Robot Cell” (see Section 2.6.1, Figure 15) with an annotated process task (also called abstract service) of the CREMA use case II (see Section 2.6.1, Figure 14). Both process task and semantic service are annotated with concepts defined in the CDM-Core. The successful plugin match of the service with the task means that the latter can be functionally implemented with the first.

Listing 2: Logic-based plugin matching of semantic services





40 / 72


Figure 17: Example of logical IOPE-plugin match of annotated service with process task





41 / 72


Though, a plugin match is commonly considered near-optimal, since an available service which annotation is logically equivalent with that of the process task is more optimal than a plugin match. An example rank list of logic-based semantic matching filters is given in [KK12]. Alternative approaches to semantic service selection learn the optimal weighted aggregation of different types of non-logic-based and logic-based semantic matching filters [K12].

2.6.3 Semantic Data Stream Processing In general, semantic data stream processing (also called RDF stream processing, RSP) is the “making sense of multiple, heterogeneous, large-size and noisy data streams in real time in order to support the decision process of a large number of concurrent users”43. The main idea is to extend the capability of classical stream processing systems for detection of temporally interrelated events with reasoning on domain-specific semantics of streamed data. An appropriate domain ontology is used to annotate the data items. The resulting set of RDF triples encodes each data item as an instance of the concept which formally defines its semantics. This semantic sensor data set is stored and materialised by an appropriate semantic triple store, and can then be queried with stream query languages like C-SPARQL44 and reasoned upon with reasoners like Pellet45, Hermit46 and STAR [K09]. There exist several approaches and tools for semantic stream annotation and processing such as C-SPARQL, Sparkwave and SPARQLstream. More details and a survey of RSP are available in, for example, [MUHB14]. Current applications of RSP are ranging from traffic control and crowd monitoring in smart cities to intelligent condition monitoring of hydraulic machines for predictive maintenance [KMSH15]. An example of semantic annotation of streamed sensor data for monitored clutch-brakes of metal presses in the CREMA use case I (see also Annex 5) is given in Section 2.6.1 (Figure 16). The CREMA component ODERU uses the CDM-Core for automatically annotating the received sensor data. The ODERU module for RSP then concurrently queries and reasons on these annotated data in order to detect pre-defined events, which are relevant for the optimisation of processes at runtime.47 Related research on the above topics will be performed in Task 5.5 for process optimisation at runtime. There are several options of exploiting means for RSP for this purpose. For example, the set of candidate services for machine process services can be pruned with RSP as follows. Available services of monitored machines are filtered out if the RSP of their sensor data indicates the onset of a machine fault with high probability. Besides, the semantic diagnosis of this fault may lead to other affected machine components which are not yet faulty but which services could be lower prioritised for the actual service request. Currently, concept definitions for machine conditions, faults and symptoms in the CREMA use case I by the user partner FAGOR and GOIZ are (a) not publicly available in general and (b) not defined according to the relevant ISO13372 standard used in the public CDM-Core. However, as mentioned above, the task partners included basic concepts for a 43 http://streamreasoning.org/ 44 http://streamreasoning.org/download 45 https://github.com/complexible/pellet 46 http://www.hermit-reasoner.com/ 47 In one CREMA use case scenario, the ODERU component is requested by the process execution environment PRU for an optimal alternative for a service which implements some process task but which execution failed. In this case, the ODERU tries to find a service which is optimal with respect to required functionality and KPI constraints.





42 / 72


typical hydraulic drive system of which the metal press at FAGOR is a special case. For CREMA use case II, there are no sensor data schemas defined yet by the user partner TCO.

2.6.4 Semantic Data Harmonisation In CREMA, semantic harmonisation of heterogeneous data is performed by the CREMA component DHS in close interaction with the user and based on the CDM-Core. In particular, the DHS issues the following two types of semantic similarity requests to the CREMA component DLP for this purpose (see deliverable D3.2): (1) Given a single word k, return a rank list [sim(c, k)] of concepts c in the CDM-Core

which are semantically similar to k. (2) Given a pair of words (k1, k2), return for each of them a rank list [sim(c, k)] of

semantically similar concepts c in the CDM-Core and a semantic similarity value sim(k1, k2)

The DLP component can apply different means for non-logic-based semantic, logic-based semantic, and hybrid semantic similarity computation to answer these requests. In the following, these different types of similarity computations for semantic harmonisation based on the CDM-Core are briefly sketched.

• Non-logic-based semantic similarity computation is usually performed with means for text-based or ontology-based structural similarity. For example, for a given word k, the text-based most similar concept names c in the CDM-Core can be determined. For a given pair of words (k1, k2), their ontology-based structural similarity can be computed via the path length or edit distance between the concepts c1 and c2 in the CDM-Core which names are respectively textual most similar to k1 and k2, respectively. Not just the names but the logical expressions of the concept definitions of c1 and c2 in CDM-Core can be treated as text for text-based similarity computation of sim(k1, k2). In any case, no logical reasoning on the concept definitions is performed.

• Logic-based semantic similarity computation relies on the computation of logical subsumption relations between concepts based on their formal logic-based definition, not their names. This can be used to compute sim(c, k) if the given word k is (a) the name of a concept that has been either newly defined and not yet classified into the CDM-Core, or (b) the name of an existing concept in the CDM-Core. In both cases, the result could be, for example, a list of most specific parent or child concepts in the CDM-Core.

• Hybrid semantic similarity combines the above mentioned types of semantic similarity. One simple example is, for a given pair of words (k1, k2), to first compute the two rank lists of text-based similar concepts c1 for k1 and c2 for k2 in the CDM-Core. This is complemented with computing for one or all concepts c1 the rank list of logic-based semantic similar concepts c2. There are more advanced means for hybrid semantic similarity computation available in the literature.

The concrete set of semantic similarity functions that will be offered by the DLP to the DHS for its semantic data harmonisation will be defined in the second reporting period in Tasks 4.1 and 4.2.





43 / 72


3 CREMA Data Model Library Software The software component of the CDM library is the CREMA component DLP. This section provides only a very brief overview of the DLP. More details on the functional and technical specification of the CREMA component DLP are given in the relevant sections of the deliverables D3.2 and D3.3. The DLP will be implemented in Task 4.1 in the second reporting period until M18. The CREMA component DLP provides other CREMA components with RESTful API functions that allow to manage and query the CDM-Core and metadata (see also Section 2.1, requirements 4a)-d)). The DLP provide its functionalities to human users in the user interface of the CREMA component DHS. These DLP-related user interface, part of the DHS, will be implemented in Task 4.2. An overview of DLP modules and interaction with other CREMA components, and the software technologies planned for implementing the DLP are shown in Figures 18 and 19.

The DLP component is composed of the following three main modules (see D3.2, Section 4.1.1).

• The module “Data Model Framework API” encapsulates the internal structure of the component in terms of a RESTful API, exposing all the functions to other components.

• The module “Semantic Data Manager System” is the core module of the component and is responsible for the semantic data management (CRUD) operations and execution of query processing workflows over the CDM content in the cloud storage layer (realised by the CRI component).

• The module “Semantic Data Manipulation” supports the Semantic Data Manager Sysem with various kinds of predefined semantic data operations, such as the computation of the semantic similarity of two concepts, and popularity of relations between given entities (e.g. owl:sameAs). The predefined functions are

Figure 18: Architecture of CREMA Data Model Library Component DLP (from D3.2)





44 / 72


implemented within the module and used by CREMA components such as the DHS component, which in particular makes use of semantic and non-semantic similarity measures for the purpose of data harmonisation. The module provides access to the actual version of the public shared CDM-Core ontology, which is stored in the CRI component, based on native query interfaces.

The software technologies planned to be used for implementing the DLP are indicated in Figure 19. In particular, an Apache HTTP Webserver gets enhanced with server-side scripts in PHP which implement the application logic, connects with the local relational database and executes the calls to external services in cURL48. The DLP functionalities will be provided to other CREMA components through RESTful API services. The CDM-Core will be stored in a cloud-based triple store for OWL2 with SPARQL endpoint and OWL reasoning support via OWL-API49. To this end, the Apache Jena TDB store with Apache Fuseki250 add-on for SPARQL over HTTP (SOH) is one candidate to install in the cloud storage which is made accessible by the CREMA component CRI. The CDM-Core metadata are stored in a relational (MySQL or PostgreSQL) database with PHP interface to the DLP application logic. The semantic similarity functions of the DLP which shall be used for the interactive process of semantic data harmonisation by the DHS component will be implemented in Java. In particular, the appropriate use of relevant tools such as semantic reasoners Hermit, Pellet and STAR, and the text similarity library Apache lucene library51 are planned.

48 http://curl.haxx.se/ 49 http://owlapi.sourceforge.net/ 50 https://jena.apache.org/documentation/fuseki2/ 51 https://lucene.apache.org/

Figure 19: Software technologies for DLP implementation





45 / 72


4 Summary This document presented the semantic CREMA data model framework which consists of the CDM library and the software component DLP for its management and querying. The CDM library includes the first version of the public shared CREMA manufacturing domain ontology CDM-Core and metadata. This is complemented with examples of using the CDM-Core for semantic annotation of process models, services, and sensor data in the CREMA use cases. Semantic annotations with concepts and their relations which are defined in the CDM-Core enable other CREMA components to automatically understand and reason on the semantics of annotated processes, services and sensor data. The CDM-Core has been engineered in close collaboration with and validated by the user partners in this task 4.1. Finally, this deliverable also provided an overview of the CREMA component DLP to be implemented in this task. The first basic version of the public shared CREMA manufacturing domain ontology CDM-Core and annotated BPMN process models of CREMA use cases are available at

• CDM-Core specification in OWL2: https://go.ascora.de/d41_CDM-Core.owl

• CDM-Core knowledge graph: https://go.ascora.de/d41_CDM-Core_kgraph_2015_12_14.png

• BPMN process models of CREMA use case I annotated with CDM-Core: https://go.ascora.de/d41_UC1_BPMN_ProcessModel_annotated.bpmn See Annexes 1 and 2 for informal description and figures.

• BPMN process models of CREMA use case II annotated with CDM-Core: https://go.ascora.de/d41_UC2_BPMN_ProcessModel_annotated.bpmn See Annexes 3 and 4 for informal description and figures.

Ongoing work. The semantic CREMA data model framework will be updated in the subsequent deliverable CREMA Data Model, Model Library and Profiles Prototype II (D37, T4.1) at M18 in June 2016. This update includes (a) the first prototypical software implementation of the CREMA component DLP, and (b) the release of the final version of the CDM-Core. The update of the CDM-Core ontology concerns its extension and refinement for the semantic annotation of (a) process services to be developed and (b) changes or addition of process models and sensor data schemas by user partners in the CREMA use cases until June 2016 (M18).





46 / 72


References • [BBW15] A. Ballatore, M. Bertolotto, D.C. Wilson (2015) "A Structural-Lexical Measure of

Semantic Similarity for Geo-Knowledge Graphs." In: Journal of Geo-Information, 4(2), ISPRS • [B03] C. Bizer (2003) “D2R MAP: A database to RDF mapping language”. In: Proc. 12th

International world wide web conference, Budapest, Hungary. • [BS04] C. Bizer, A. Seaborne (2004) “D2RQ–treating non-RDF databases as virtual RDF

graphs”. In: S.A. McIlraith, D. Plexousakis, F. van Harmelen (Eds.), Proc. 3rd International Semantic Web Conference, LNCS 3928, Springer.

• [BBLP15] N. Boissel-Dallier, F. Benaben, J-P. Lorre, H. Pingaud (2015) “Mediation Information System Engineering based on Hybrid Service Composition Mechanism”. In: Journal of Systems and Software, 108, Elsevier

• [BSW07] S. Braun, A. Schmidt, A. Walter (2007) “A Collaborative Web 2.0 Approach to Ontology Engineering”. In: Proc. World Wide Web Conference (WWW), Banff, Canada. [SSN12] M. Compton, P. Barnaghi, L. Bermudez, R. García-Castrod, O. Corchod, S. Coxe, J. Graybealf, M. Hauswirth, C. Henson, A. Herzog, V. Huang, K. Janowiczk, W.D. Kelseym, D. Le Phuoc, L. Lefort, M. Leggieri, H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, K. Taylor (2012) “The SSN ontology of the W3C semantic sensor networks incubator group”, In: Journal of Web Semantics, 17, Elsevier.

• [CPG15] O. Corcho, M. Poveda-Villalon, A. Gomez-Perez (2015) “Ontology Engineering in the Era of Linked Data”, In: Bulletin of Association for Information Science and Technology, 41(4).

• [FFR97] A. Farquhar, R. Fikes, J. Rice (1997) “The Ontolingua Server: a tool for collaborative ontology construction”, In: Journal of Human-Computer Studies, 46(6), Elsevier.

• [GFC03] A. Gomez-Perez, M. Fernandez-Lopez, O. Corcho (2003) “Ontological Engineering”, Springer

• [HKS06] I. Horrocks, O. Kutz, U. Sattler (2006) “The even more irresistible SROIQ”, In: Proc. International Conference on Knowledge Representation (KR), pp. 57-67, AAAI Press

• [IAMS13] R. Iqbal, M.A.A. Murad, A. Mustapha, N. M. Sharef (2013) “An Analysis of Ontology Engineering Methodologies: A Literature Review”, In: Research Journal of Applied Sciences, Engineering and Technology 6(16).

• [KP14] A.H. Khan, I. Porres (2014) “Consistency of UML class, object and statechart diagrams using ontology reasoners”, In: Journal of Visual Languages and Computing, Elsevier.

• [K08] M. Klusch (2008) “Semantic web service description”. In: Schumacher M, Helin H, Schuldt H (eds) CASCOM: intelligent service coordination in the semantic web, Chap 3. Birkhäuser.

• [K08b] M. Klusch (2008) “Semantic web service coordination”. In: Schumacher M, Helin H, Schuldt H (eds) CASCOM: intelligent service coordination in the semantic web, Chap 4. Birkhäuser.

• [K09] G. Kasneci et al. (2009) “STAR: Steiner Tree Approximation in Relationship-Graphs”. In: Proc. 25th IEEE International Conference on Data Engineering (ICDE).

• [K12] M. Klusch (2012) “The S3 Contest: Performance Evaluation of Semantic Service Matchmakers”. In: Blake, M.B.; Cabral, L.; König-Ries, B.; Küster, U.; Martin, D. (Eds.): Semantic Web Services – Advancement through Evaluation; Springer

• [KK12] M. Klusch, P. Kapahnke (2012) “The iSeM Matchmaker: A Flexible Approach For Adaptive Hybrid Semantic Service Selection”, In: Journal of Web Semantics, 15, Elsevier.

• [KKZSZ15] G. Kahl, M. Klusch, I. Zinnikus, J. Schimmelpfennig, M. Zapp (2015) “ADIGE: Semantic Business Process Management for Smart Retail Environments”, In: Proc. 17th ACM International Conference on Information Integration and Web-based Applications and Services (iiWAS), Brussels, Belgium; ACM

• [KKSLB15] M. Klusch, P. Kapahnke, S. Schulte, F. Lecue, A. Bernstein (2016) “Semantic Web Service Search: A Brief Survey”. In: Kuenstliche Intelligenz, 2/16, Springer.

• [KMSH15] M. Klusch, A. Meshram, A. Schuetze, N. Helwig (2015) “ICM-Hydraulic: Semantics-Empowered Condition Monitoring of Hydraulic Machines.” Proc. 11th International Conference on Semantic Systems (SEMANTiCS); Vienna, Austria; ACM

• [KMSBKP15] T.R. Kramer, B.H. Marks, C.I. Schlenoff, S.B. Balkirsky, Z. Kootbally, A. Pietromartire (2015) “Software Tools for XML to OWL Translation”, In: NIST Interagency/Internal Report (NISTIR) - NIST IR 8068





47 / 72


• [KPEZW12] W. Krathu, C. Pichler, R. Engel, M. Zapletal, H. Werthner (2012) "Semantic Interpretation of UN/EDIFACT Messages for Evaluating Inter-organizational Relationships"; In: Proc. 5th International Conference on Advances in Information Technology (IAIT)

• [KLIP15] B. Kulvatunyou, Y. Lee, N. Ivezic, Y. Peng (2015) “A framework to canonicalize manufacturing service capability models”. In: Computers & Industrial Engineering, 83.

• [LSDS06] S. Lemaignan, A. Siadat, J.Y. Dantan, A. Semenenko (2006) “MASON: A Proposal For An Ontology Of Manufacturing Domain”, In: Proc. IEEE Workshop on Distributed Intelligent Systems: Collective Intelligence and Its Applications; IEEE Press.

• [MUHB14] A. Margara, J. Urbani, F. van Harmelen, H. Bal (2014) “Streaming the Web: Reasoning over Dynamic Data” In: Journal of Web Semantics, 25, Elsevier.

• [MMN13] J.M. Mortensen, M.A. Musen, N.F. Noy. (2013) "Developing Crowdsourced Ontology Engineering Tasks: An iterative process." In: Proc. 1st International Workshop on Crowdsourcing the Semantic Web (CrowdSem); CEUR volume 1030.

• [NMAM13] N.F. Noy, J.M. Mortensen, P.R. Alexander, M.A. Musen (2013) “Mechanical Turk as an Ontology Engineer? Using Microtasks as a Component of an Ontology-Engineering Workflow”. In: Proc. 5th Annual ACM Web Science Conference (WebSci).

• [O08] OASIS (2008) “Reference Model for Semantic Services Oriented Architecture”. http://docs.oasis-open.org/semantic-ex/ro-soa/v1.0/pr01/see-rosoa-v1.0-pr01.html Latest access: 4.12.2015

• [PDT12] H. Panetto, M. Dassisti, A. Tursi (2012) “ONTO-PDM: Product-driven ONTOlogy for Product Data Management interoperability within manufacturing process environment”. Journal of Advanced Engineering Informatics, 26(2), Elsevier.

• [PST04] H.S. Pinto, S. Staab, C. Tempich (2004) “DILIGENT: Towards a fine-grained methodology for DIstributed, Loosely-controlled and evolvInG Engineering of oNTologies”, In: Proc. European Conference on Artificial Intelligence (ECAI).

• [P13] A. Polleres (2013). OWL vs. Linked Data: Experiences and Directions. Invited talk at 10th International Workshop on OWL - Experiences and Directions (OWLED). Available at https://ai.wu.ac.at/~polleres/presentations//20130527OWLED2013_Invited_talk.pdf Last access on 26.11.2015

• [SMB10] E. Simperl, M. Mochol, . Bürger (2010) “Achieving Maturity: The State of Practice in Ontology Engineering in 2009”. In: Journal of Computer Science and Applications, 7(1).

• [SSS09] Y. Sure, S. Staab, R. Studer (2009) “Ontology Engineering Methodology” In: S. Staab and R. Studer (eds.), Handbook on Ontologies, International Handbooks on Information Systems, Springer.

• [TNNM13] T. Tudorache, C.I. Nyulas, N.F. Noy, M.A. Musen (2013) “WebProtégé: A Collaborative Ontology Editor and Knowledge Acquisition Tool for the Web”. In: Semantic Web Journal, 4 (1), IOS Press.

• [VIK15] M. Vujasinovic, N. Ivezic, B. Kulvatunyou (2015) “A Survey and Classification of Principles for Domain-Specific Ontology Design Patterns Development”. In: Journal of Applied Ontology, 10(1), IOS Press

• [ZJL12] J. Zedlitz, J. Jörke, N. Luttenberger (2012) “From UML to OWL2”, In: Communications in Computer and Information Science Series, 295, Springer

• [ZL14] J. Zedlitz, N. Luttenberger (2014) “Conceptual Modelling in UML and OWL-2”, In: Advances in Software, 7(1&2), IARIA

• [ZSSD12] D. Zhang, T. Song, J. He, X. Shi, Y. Dong (2012) “A similarity-oriented RDF graph matching algorithm for ranking linked data” In: Proc. IEEE 12th International Conference on Computer and Information Technology (CIT), IEEE.





48 / 72


Annex 1: Process Models of Use Case I This Annex contains the informal description and BPMN of the first versions of the process models that were selected for the first CREMA use “Use Case I: Machinery maintenance” (see deliverables D7.1 and D7.2) and provided by user partners FAGOR and GOIZ with support by IKER. Informal description of process models: The first process model for data acquisition (monitoring) is composed of the following four steps or tasks: The first task SA1 (“Get press machine data”) is in charge of connecting to the metal press machine of FAGOR (through the Task T4.4, CVA), and starts receiving data from the CPS services. The second task (SA2: transform data) transforms the raw monitoring data for the press machine into the internal format of the CREMA component CRI for data storage in the cloud. It is foreseen to call some service from T4.2 (CREMA component DHS) that will be stored in the Marketplace. The third task (SA3: execute the GOIZ algorithm) uses raw data for computing aggregated information for specific KPIs with algorithms provided by the user partner GOIZ. The process task SA4 stores the computed results from tasks SA2 (transformed raw data) and SA3 (calculated data) in the cloud managed by the CREMA component CRI for checking of business rule definitions later on. The second process model is devoted to the KPI comparison/maintenance process. It is a compound task that will be implemented directly inside the CREMA component MON. It is composed of the following four tasks: The task SB1 (select business rules) will select one or more business rules already present in CRI to start business rule-based monitoring. The task SB2 will then check the KPI value for thresholds, i.e. the Rule Engine in MON will monitor the selected business rules. When one or more thresholds are exceeded, the task SB3 is in charge of notifying the TAS (Technical Assistance Service) manager of this event. MON will show generate alarms to the user. Eventually, in the task SB4 (check alarm), the user checks whether the specific alarm needs maintenance or not. In case of maintenance is needed, MON will notify the CREMA component PRU to start executing the maintenance process.52 The third process model concerns the maintenance process: It is initiated by PRU, when a notification for an Alarm is raised as a result of executing the second process model. It is composed by five process tasks. The first one (SB5: get customer requirements) is expected to call an internal service for obtaining customer-specific requirements such as those on specific maintenance contract, location and type of machines. On the basis of this information, the following two tasks shall find a correct (and optimised) combination of spare-part provider and TAS team. Process task SB6 searches in the marketplace for a suitable TAS service, whether SB7 associates one suitable spare-part supplier. Based on the outcomes of the two latter tasks, the task SB8 schedules an onsite maintenance. In particular, it will notify the user via the CREMA Dashboard about a possible maintenance schedule depending on the availability of TAS team and spare-part supplier selection. SB9 is an information task wrapper over the manual task of onsite maintenance. Eventually, SB10 will notify involved stakeholders. It will call a feedback service to notify involved stakeholders about the maintenance intervention. After this, the press machine should start operating again as expected. The BPMN notation of the process models is available at https://go.ascora.de/d41_UC1_BPMN_ProcessModel.bpmn 52 This process part will be implemented as part of the MON internal behaviour.





49 / 72


Process models in BPMN:

Figure available at https://go.ascora.de/d41_Figure-20.png

Figure 20: BPMN process models of CREMA use case I





50 / 72


Annex 2: Annotated Process Models of Use Case I This Annex contains the semantic annotation of the process models of CREMA use case I (see Annex 1) with the CDM-Core ontology. The annotated BPMN source of the process models is available at: https://go.ascora.de/d41_UC1_BPMN_ProcessModel_annotated.bpmn


Figure 21: Annotated process model of CREMA use case I (1)





51 / 72








52 / 72








53 / 72








54 / 72








55 / 72








56 / 72








57 / 72


Figure available at https://go.ascora.de/d41_Figure-28.png Figure 28: Annotated process model of CREMA use case I (8)





58 / 72








59 / 72








60 / 72


Annex 3: Process Models of Use Case II This Annex contains the informal description and BPMN denotation of the process models that were selected for the second CREMA use case “Use Case II - Automotive” provided by the user partner TCO with support by TANet. Informal description of process models: The process models for CREMA use case II all deal with exhaust manufacture in Tenneco UK and are orchestrated in terms of a master process model, which coordinates the selection of orders to be executed, the allocation of robot cells based on this selection and the production start itself. The selection of orders is implemented by IndustreWeb. The remaining tasks refer to subprocesses as detailed in the following. The resource allocation process model starts with calculating the number of required robots. This is followed by a loop, which performs the actual allocation by picking suitable robots until the number of required robots is reached. Robots are either available in the Tenneco UK plant or remotely accessible through Tenneco Europe. In any case, they are envisioned to be available at the CREMA Marketplace. Additionally, one branch of this workflow inside the loop allows the removal of allocated robots, in case that the running process receives an online update about changes in the collection of orders to be fulfilled. According to D72, this process model is forseen to make use of optimisation at runtime (ODERU). The goal is to maximise OEE (Overall Equipment Effectiveness) and to minimise costs, while maintaining a set of strict deadlines for the order items. The process model for starting the production receives the result of the previously computed robot allocation and kicks off the actual production process per robot cell. For each allocated robot, it either runs the exhaust manufacture process or requests production start, if the robot is not under the control of Tenneco UK. The communication to the physical installations and robot operators is handled by IndustreWeb Global and in turn the robot controller software. The exhaust manufacture process model focuses on the production of exhausts itself. In general, it includes the welding process performed by the robot, which is followed by a testing procedure to assure high quality results. In parallel, the whole workflow is monitored using the CREMA MON component. After the operator picks a production job according to the previously selected orders, the process model checks, if the tools required for the particular exhaust model of the job are in place. Tools in this use case refer to particular clamps that fix the exhaust parts to be welded to the robot. The check is implemented using IndustreWeb and Ubisense Smart Factory. The former delivers information on the required tools, while the latter is able to identify the location of tools inside the robot cell. Checking is performed until all required tools according to a tool receipe for an exhaust are correctly in place. After this, the operator is instructed to load all exhaust components (e.g. pipe, flanges, catalysator) and to launch the welding process. The production cycle is performed and checking errors always lead to a restart. Problem resolution is either done by the operator directly or by the engineering staff. After welding, the exhaust gets annotated with production information by using a Smart Factory tag, followed by a test in a pressure test cell. Exhausts that did not pass this test are sent for quality inspection. Finally, the exhaust is annotated again by adding test results, gets unloaded and transported to the goods out zone.





61 / 72


Process models in BPMN:

Figure 31: BPMN process models of CREMA use case II (1) Figure available at https://go.ascora.de/d41_Figure-31.png





62 / 72



Figure 32: BPMN process models of CREMA use case II (2)





63 / 72


Annex 4: Annotated Process Models of Use Case II This Annex contains the semantic annotation of selected representative process tasks of the BPMN process models of CREMA use case II (see Annex 3) with the CDM-Core ontology. The annotation of the remaining process tasks is ongoing work with the user partner TCO. The sources of these annotated BPMN process models are available at https://go.ascora.de/d41_UC2_BPMN_ProcessModel_annotated.bpmn


Figure 33: Annotated process model of CREMA use case II (1)





64 / 72



Figure 34: Annotated process model of CREMA use case II (2)





65 / 72


Annex 5: Sensor Data Schema in Use Case I This Annex contains (a) an overview of the metal press and sensors attached to it, and (b) the corresponding TSV-encoded data schema for (streamed) sensor data. This information was provided by user partners FAGOR and GOIZ (see also D7.2). Overview of metal press and sensory: The overall system is composed of two main parts: the hydraulic drive system of the metal press, and the metal press itself. The first part generates the power and controls its transmission to the second part. In CREMA use case I, condition monitoring and maintenance focuses on the hydraulic drive system with several components including clutch-brake, oil (hydraulic fluid) collector and pump, gas accumulator, control valve, and power pack/elctro motor. The listed sensors are all concerned with measuring various operational and process parameters of the drive system, one parameter measured per sensor. The sensor data stream is the time-stamped and ordered, multi-variate stream of data for these eight sensors. The TSV-encoded schema given by FAGOR and the correlation with the system sensors shown above are as follows. Sensor data stream schema: The sensor data stream schema is a relation that represents each of the timestamped data buckets with their sequentially ordered sensor measurement values from eight sensors (channels) as shown below:

Figure 35: Overview of metal press system and sensory at FAGOR





66 / 72


This figure is available at https://go.ascora.de/d41_Figure-36.png The first sensor is a optocoupler that generates a trigger signal to activate a valve commutation. At the second and third position of the schema are the signals from two pressure transducers measuring the oil pressure in bar (which is generated by the hydraulic subsytem by gas-pressurising the oil) before and after the clutch-brake. At the fourth position is the value of the oil flow meter measuring the flow of the cooled oil in grades. At the fifth and sixth position are the values for speed (in rotation per minute, rpm

Figure 36: Sensor data schema from data log provided by FAGOR





67 / 72


but traduced in tension - Volts) of the motor axis (flywheel) and of the application (crankshaft), respectively. The first uses a linear encoder in terms of an inductive sensor, whereas the latter is a tachometer using a rotary encoder. Eventually, the two last sensor measurements in the schema are (cooler) oil temperatures measured by two sensors before and after its passage into the clutch-brake of the hydraulic drive of the metal press. The sensor measurements are sampled in intervals. This sensor data schema is represented in the CDM-Core based on the W3C-SSN part with following names of sensor and measurement classes, specific sensors, and units of measurements.

Table 4: Semantic mapping of sensor data schema to concepts in CDM-Core Sensor

ID in Fig. 35

Sensor class names

in CDM-Core

Measurement class name

in CDM-Core and <position in stream bucket>

Sensor names (names of sensor class instances)

in CDM-Core

Unit of measure

ment

Physical sensor type

A SSN:SensingDevice

SSN:Property <1>

fag:Trigger_sensor_1

Volts Optocoupler

B CM:Pressure_sensor

CM:Pressure <2> fag:Pressure_sensor_LINE_2

bar Pressure Transducer

C CM:Pressure_sensor

CM:Pressure <3> fag:Pressure_sensor_APPLICATION_

3

bar Pressure Transducer

G CM:Flow_sensor

CM:Flow <4> fag:Flow_sensor_4 grades Flow Meter

E fag:Speed_sensor

fag:Speed <5> fag:Speed_sensor_APPLICATION_5

Volts Inductive Sensor (linear

encoder) F fag:Speed_sen

sor fag:Speed <6> fag:Speed_sensor_

MOTOR_6 Volts Tachometer

(rotary encoder)

H CM:Temperature_sensor

CM:Temperature <7>

fag:Temperature_sensor_IN_7

graduak (Kelvin)

Temperature Sensor

I CM:Temperature_sensor

CM:Temperature <8>

fag:Temperature_sensor_OUT_8

graduak (Kelvin)

Temperature Sensor





68 / 72


Annex 6: Formal Ontology Language OWL2-DL This Annex contains the syntax and formal logic-based semantics of the standard modeling language OWL2-DL53 of the CDM-Core ontology (Figure 37). OWL2-DL is a subset of OWL2. This is complemented with descriptions of the relation of OWL2-DL to alternative standards RDF and RDFS, and to Linked Data. OWL2-DL corresponds to the decidable description logic SROIQ54 [HKS06], where

• R stands for the description logic ALC extended with property chain inclusion axioms and transitive property axioms,

• S stands for property characteristics (e.g., reflexive and symmetric)

• O stands for nominals/singleton classes

• I stands for inverse roles

• Q stands for qualified number restrictions

53 The XML-RDF serialisation of OWL2 is specified in http://www.w3.org/TR/owl2-xml-serialization/ 54 The predecessor OWL-DL corresponds to the tractable, less expressive description logic SHOIN with support of data values, data types and datatype properties, i.e., SHOIN(D).

Figure 37: Syntax and semantics of description logic SROIQ (OWL2-DL)





69 / 72


Figure 38 summarises the expressiveness and reasoning complexity of the different dialects (or profiles) of the W3C ontology language OWL2. More details on their syntax and semantics is available at http://www.w3.org/TR/owl2-profiles/

Figure 38: Relations between OWL2 dialects (expressiveness, complexity)

Relation to RDF and RDFS: The RDF (Resource Description Framework) language correspond to an first-order assertional logic in which each triple expresses a simple proposition. This imposes a fairly strict monotonic discipline on the language, so that it cannot express closed world assumption, local default preferences, and several other commonly used non-monotonic constructs like multiple inheritance and overriding. RDF describes assertional but not conceptual knowledge. In other words, its describes the set of facts about objects in terms of their class membership or type, their properties and relations (called ABox of an ontology) but does not define the relations between classes and their definitions (called the TBox of an ontology). RDF Schema (RDFS) extends RDF by allowing to define hierarchies of classes (concepts) and properties (roles), domain and ranges of properties, property restrictions, containers, and some metadata like with elements rdfs:comment, rdfs:seeAlso. RDFS statements are equivalent to DL axioms of the form





70 / 72


RDFS semantics can be translated to function-free, negation-free definite-Horn rules and consider RDF statements as facts in the resulting plain Datalog program of which its minimal Herbrand model then is a correct, smallest possible interpretation that satisfies the given RDF graph. RDFS differs from OWL2-DL mainly in that RDFS does not offer operators for conjunction, disjunction, negation, existential qualification and role cardinalities (N, Q). Like OWL2-Full, RDFS extends OWL2-DL by allowing higher-order logic statements on meta-classes or derived classes. OWL2-Full is an undecidable higher-order logic that covers RDFS and the expressiveness of SHOIQ(D). Relation to Linked Data: The following description of Linked Data (LD) is taken from http://linkeddata.org/faq: The term Linked Data refers to a set of best practices for publishing and connecting structured data on the Web. Key technologies that support Linked Data are URIs (a generic means to identify entities or concepts in the world), HTTP (a simple yet universal mechanism for retrieving resources, or descriptions of resources), and RDF (a generic graph-based data model with which to structure and link data that describes things in the world). RDFa enables RDF data to be embeded in HTML documents which makes it very useful for publishing RDF in contexts where Web publishing is limited to HTML. Linked Data that is explicitly published under an open license is called Linked Open Data (LOD). Not all Linked Data will be open, and not all Open Data will be linked. Therefore care should be taken to use the appropriate term, depending on the licensing terms of the data in question. Linked Data can be automatically created by converting existing structured data sources such as relational databases into RDF, using an ontology, more precisely a concept base or vocabulary, that closely matches the schema of the original data source.55 As of today, only a small fraction of Linked Open Data is ontologies defined in RDFS or OWL2. Examples are the vocabularies GeoNames in OWL, and SKOS in OWL2-DL. In most cases the RDF object types (see rdf:type) in openly published Linked (RDF) Data sets are defined in and (xmlns-)imported from non-formal vocabularies. Examples are the standard metadata vocabulary Dublin Core56, the non-standard vocabularies of schema.org57 and those which are created by means of personal or social free tagging of information (folksonomies). Roughly speaking, most of the shared non-formal vocabularies for RDF object types are attributed term or “type” hierarchies with informal textual definition of their semantics in English. More information on Linked Data in general is available at http://www.w3.org/TR/ld-glossary/, and http://linkeddata.org/. The tutorial in [P13] gives a comprehensive account of using OWL2 for linked (RDF) data.

55 RDF is used to represent and to exchange assertional knowledge on objects, their poperties and types (in a so called ABox or fact base of an ontology), while RDFS and OWL are used to represent and share terminological knowledge on concepts, properties and relations (in a so called TBox, vocabulary or concept base of an ontology). An ontology may have an empty ABox. Unfortunately, in the literature the term ontology often only captures the latter aspect of an ontology. 56 http://dublincore.org/documents/dcmi-terms/; a not authoritative definition of Dublin Core in RDFS is given in http://www.w3.org/TR/WD-rdf-schema/#dublincore 57 The used proprietary data model for these vocabularies (schemas) is derived from RDFS but not formally defined; a deprecated, incomplete version in OWL is available at http://schema.org/docs/schemaorg.owl





71 / 72


Annex 7: General Parts of CDM-Core This Annex contains very brief descriptions of the imported or newly developed parts of the public CREMA manufacturing ontology CDM-Core which are rather general and not exclusively CREMA use case specific. W3C SSN is a W3C standard ontology in OWL for sensory and sensor networks. It describes sensors and observations, and related concepts. It does not describe domain concepts, time, locations, etc. these are intended to be included from other ontologies via OWL imports. Available: http://www.w3.org/2005/Incubator/ssn/ssnx/ssn MASON [LSDS06] is an upper (top-level) ontology for the manufacturing domain covering mainly product, process and resource concepts. For this purpose, it contains the main classes of Entity (such as administrative, cost and technological ones), Operation (Human, logistic and Manufacturing) and Resource (Human, Material and Geographic). Resource stands for the whole set of manufacturing linked resource, like machine-tools, tools, human resources, and geographic resources like plants and workshops. Entities aim to provide concepts to specify and given an abstract view of the product. Operations relate to processes and cover manufacturing. Logistic, human and launching operations. Available: http://sourceforge.net/projects/mason-onto/

Figure 39: MASON overview [LSDS06] MASON is used to root the CREMA use case I related concepts for companies, intervention conditions, maintenance and its contract, location, press and clutch brake, in addition to some properties such as "includes". MASON is also used to map general properties like properties of "isLocatedIn", or "isMachinableWithTool" and "toolUsableOn"





72 / 72


to equivalent ones used in the CRMEA use case II specific part. The rooting of the concept “Catalyzer” in the “Part of Tester into Machine” and stated equivalence of “Employee” with “Human_resource” are other examples. CM has been newly developed in CREMA Task 4.1. It is a machine condition monitoring domain ontology in OWL2, developed on top of W3C SSN and based on the ISO standard ISO-3372 for condition monitoring and predictive maintenance. The CM of CDM-Core represents general domain knowledge on (a) machine components, sensors and measured properties, (b) machine condition, faults, symptoms, and their causal relations. It can be used as a basis for semantic fault detection and diagnosis. The CM defines some types of sensors and measured properties as commonly used for condition monitoring of hydraulic and mechanic systems. In CREMA, the CM is mainly used as a basis for defining particular sensors instances such as those of the metal presses of FAGOR (see Annex 5), after some small use case-specific extensions. DUL (DOLCE+DnS Ultralite) is an upper ontology in OWL for modeling either physical or social contexts. It is a simplification of some parts of DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering)58, and the Descriptions and Situations ontology DnS. It defines space and time locations, physical and non-physical endurants, etc. DUL is in part used by the Condition Monitoring (CM) ontology, and also by the two CREMA use case specific sub-ontologies CDM-UC1/2 of CDM-Core. Available: http://www.loa.istc.cnr.it/ontologies/DUL.owl, http://lov.okfn.org/dataset/lov/vocabs/dul

58 http://www.loa.istc.cnr.it/old/DOLCE.html

wp4 – manufacturing virtualisation& interoperability d4.1 ... · manufacturing domain...

Documents