=Paper=
{{Paper
|id=Vol-2900/WS5Summary
|storemode=property
|title=Summary Report
|pdfUrl=https://ceur-ws.org/Vol-2900/WS5Summary.pdf
|volume=Vol-2900
|authors=Dimitris Kiritsis,Neil Otte
|dblpUrl=https://dblp.org/rec/conf/iesa/KiritsisO20
}}
==Summary Report==
https://ceur-ws.org/Vol-2900/WS5Summary.pdf
Workshop Discussion Report – Industrial Ontology Foundry (IOF) –
Achieving Data Interoperability
Dimitris Kiritsisa, J. Neil Otteb
a
EPFL, Switzerland
b
Johns Hopkins University Applied Physics Laboratory, USA
This workshop, involving around forty participants from industry and academia, focused on
ontology-based data interoperability in the industrial domain. The purpose of the workshop was to
inform the audience about the mission, objectives, approach, and current activities of the Industrial
Ontology Foundry (IOF) (https://www.industrialontologies.org/) and to discuss progress, issues, and
future plans, as well as methods for coordinated ontology development for industry and associated
standards and tools for industrial data interoperability.
The workshop was conducted in two parts: (i) discussions around presentations of four papers
reporting in the progress of respective IOF Working Groups (WG) and (ii) detailed discussions around
the current status and operations of IOF and its perspectives.
In the first part of the workshop presentations were provided by the moderators of the IOF WG on
IOF Architecture, IOF Maintenance Ontology, IOF Production Planning and Scheduling Ontology and
Supply Chain Ontology. The key outcomes from these presentations were:
The IOF architecture proposes five types of ontologies including: 1) Foundational Ontology
(FO); 2) Domain Independent Reference Ontologies (DIROs); 3) Domain Specific Reference
Ontologies (DSROs); 4) Domain Dependent Ontologies (DDOs); and 5) Application Ontologies
(AOs). The IOF intends to produce and curate the first three types. The IOF charter describes
these different ontology types. The intent of these reference ontologies is to allow extensions
that represent more specific or constrained sub-domains (e.g., particular industry ‘verticals’ or
applications). To meet this intent, the IOF ontologies are expected to have an architecture that
starts from alignment with a domain neutral ontology, also referred to as a Top-Level Ontology
(TLO) or Foundational Ontology, from which subsequent IOF ontologies can be developed
(newly minted or adapted from existing ones) that are logically consistent, coherent, and
modular, allowing for reusability.
In the domain of maintenance, several ontological quandaries are still under discussion as the
group endeavors to create a maintenance ontology. The notion of a Failure Event is one example.
There is a need to differentiate between two kinds of failure event. The first kind occurs when a
failure event results in the termination of a process. The second kind occurs when there is
deviation from a desired output; for example, a partial loss of pumping ability without total
failure of the pump. Other challenges are associated with the sequencing of activities and events
in the maintenance work management process where there are different sequences and activities
depending on whether work is unexpected (a maintenance notification following a failure event)
or a planned process as part of maintenance strategy. Future work will concentrate on these
questions.
The draft reference PPS ontology presented in the first part of the workshop is the result of the
work of several researchers. They have so far completed a treatment of design specification,
process and resource capability, and resource function. This approach was recently tested in
applying this ontology for a machining process planning application. This work is ongoing.
Another of issues are outstanding, including: (i) the demarcation between functions and
capabilities in order to represent how various resources contribute to part quality (from the
specification) during manufacturing processes (e.g. what is the function of a machine and what
Proceedings of the Workshops of I-ESA 2020, 17-11-2020, Tarbes, France
EMAIL: r.i.young@lboro.ac.uk
©️ 2020 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
is the function of a tool?); (ii) discussion of form feature and manufacturing feature concepts, as
they are fundamental elements in some common design and manufacturing activities; (iii) levels
of granularity in representing manufacturing processes for different planning and scheduling
tasks, for example, process planning is concerned with many details of each manufacturing
operation on a single product, whereas scheduling deals with higher level operations on several
products; (iv) the formalization of manufacturing resources in different phases of product and
manufacturing system design, planning and execution; (v) the formalization of scheduling
optimization related terms for representing entities such as equations, sequences, problems,
constraints, objectives, and performance measurements.
In the context of the group’s effort to create a reference ontology for the supply chain domain,
several ontological challenges or “quandaries” were encountered. For example, it is not yet
verified if using the Process Aggregate class is the right approach for representing the collection
of processes that occurs in a supply chain. The notion of Service, and its sub-types including
Manufacturing Service, also needs further formalization and axiomatization since most suppliers
in a supply chain are service providers in essence. The taxonomy of supply chain roles also
needs further expansion. In modeling the notions and requirements gathered from the
traceability use case, ontological quandaries include providing a better means for constructing
the history of supply chain that can capture the flow of materials across various geospatial and
temporal regions. Furthermore, representing supplier capabilities also poses a host of challenges
since capability is a complex and multi-faceted notion that can be attributed to multiple resources
in an organization. With respect to scope, the current draft focuses mainly on the supply chain
planning phase. As a next step, scope will be expanded to include more use cases from the supply
chain execution phase.
In part two of the workshop, a panel composed of the Chairs of the IOF Governance Board (GB)
and the Technical Oversight Board (TOB) and the Moderators of the current IOF WGs presented the
State of Play of IOF so far. The main points of the following up discussion were as follows:
IOF approaches on modularization: since its earliest days, the IOF has been considering such
questions. Barry Smith’s experience from the biomedical community indicates that one must
always think about the more general domain that informs the domain in which one is working.
Hence, domains like food, construction, etc are in the backs of our minds even as we focus on
manufacturing. Then, having worked at this level of generality all along, we are enabled to later
to help people in neighboring domains.
Can BFO be used for everything? We should look at The Common Core Ontology (CCO) as an
extension of BFO to see the additional expressivity available within it. CCO has been extended
for the space manufacturing domain, for example.
A better guidance for using the IOF ontologies should be provided, and we need a common
vocabulary across the domain, though it’s not the purpose of the IOF to provide a vocabulary
for ALL terms.
Concerning the many meanings of terms and the ability to capture these under BFO: BFO is
neutral with respect to mathematics, but it does allow people to make statements about shapes,
inviting topologists and mereologists to represent the qualities they are describing
mathematically.
BFO-2020 addresses vagueness of temporal and spatial boundaries by providing a
representation that can facilitate reasoning about regions. This is particularly difficult, given the
limitations of OWL2, which does not allow for three place predicates.
About possible conflict and overlap between the CCO time ontology and BFO-2020: CCO time
is an extension of BFO that provides additional or supplementary resources that are useful for
representing time. Hence, they are not in conflict with each other. BFO provides high-level terms
such as process, temporal region, and temporal instance, whereas CCO has time-related terms
such as Day, Week, Year, Temporal Region Identifier, and Calendar. Furthermore, like the
W3C’s Time Ontology and the GeoSparql standard, the temporal relations within CCO
implement the Allen Interval Calculus.