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.