Overview

The abridged version of the development process specifies the steps necessary to create ontologies based on an agile, iterative process. The process begins with collecting epics from working groups, users, and domain experts to guide development.

The initial draft of this document focuses on the first phases of the development process.

Roles

• Doman or Subject Matter Expert

  • Professional in a specific domain related to the ontology

• Ontologist

  • Person knowledgeable in the construction of ontologies

• Working Group Chair

  • Person who presides over a working group meeting

• Business Architect

  • Person who works with the domain experts to capture use cases and domain terminology.

•  TOB Member

  • Person who is part of the TOB either as a Working Group Chair or as an invited expert

•  Release Manager

  • Person who is responsible for tagging releases and managing the maturity levels of ontologies.  

Technical Oversight Board

Open

Epics

Working groups create or add Epics to the TOB and MAY add an Epic to the Working Group to organize user scenarios for each area of concern. The TOB checks cross-cutting concerns with each working group. The working group WG MUST link Epics to the TOB Epics.

Epics MUST have the following roles:

• Sufficient individuals are available to work on ontology, with the following mandatory roles filled:

  • Domain experts to provide business cases and industry terminology

  • Business architect to develop the use cases and scenarios

  • Ontologists to develop the ontology

• Adequate definition of the Epic.

Creating an Epic

An Epic is a significant development initiative that may span multiple releases and working groups. It aligns with the industry's high-level need to provide some capability in the standard. It must also align with business objectives and provide value or solve problems requiring an ontological approach.

The Epic may also span multiple working groups in parallel or serially, depending on the nature of the work. Epics are created in Jira for IOF as the top-level issue in the timeline for tracking all related parts. An Epic has multiple User Scenarios. In addition, an Epic requires multiple constructs to satisfy the domain concerns.

The Epic must also have the following information:

• The high-level topics and concerns the working groups need to address.

• Known dependencies on this Epic by other groups and if other Epics are blocked.

• An estimate of the complexity of the Epic.

• The necessary stakeholders in each domain to create use cases.

Examples

• Title: Supply chain resistance. The manufacturing supply chain needs to reduce the dependency on a single source of parts because of areas of vulnerability that prevent a surge in production or incur delays due to a lack of available capabilities. To address this problem, standards are needed to provide capability-based agile manufacturing support for dynamic just-in-time sourcing, planning, scheduling, and executing from the supply chain, engineering, and manufacturing processes across the industrial base.

• Title: Lifecycle product data. The current manufacturing information systems cannot capture the lifecycle of products and all their parts to support the archival and retrieval of products across their complex mereological structure. To address this, the industry requires information across the entire product and lifecycle, including design, manufacturing, maintenance, and end-of-life, to understand how something was made and the provenance of the parts.

• Title: inferred process steps from geometric primitives. Creating a set of axioms to provide inferred process engineering steps to manufacture a set of design features using geometric primitives in ISO AP 242 (geometric interchange standard).

Prioritizing Epics 

The TOB reviews the Epics in the backlog and decides, through deliberation, the priority of each Epic and the availability of resources to perform the work. When considering scheduling, the TOB must consider the Epic's dependencies and complexity.

Since Epics can span multiple working groups and releases, a preliminary decomposition may be necessary to evaluate whether Working Groups can develop a valuable subset of constructs to satisfy the epic's needs.

Activities of the Working Groups

• What do we do when we don’t have adequate business value statements?

• Competency questions may not be evident.

• Why do we do this if we don’t have a business reason?

• We need domain experts to validate the business reasons

• Systems engineering spans multiple working groups

• But we should still be able to support some business needs for other domains

• SysML 2.0 must have engineering use cases

Open

Creating a Usage Scenario

A usage scenario is a narrative providing a business need statement in the domain expert's language with additional context. All use scenarios in the issue repository are related as sub-issues of the Epic.

A domain expert must be part of the team to derive Usage Scenarios. The domain expert is assumed to have little knowledge of ontologies or ontological development. Domain experts can be invited as guests where what they provide is considered open IP usable by IOF. Any content that is copyright or protected must be disclosed by the domain expert to the IOF and will not be used unless licensed to the IOF.

Break them down from the domain expert scenarios to a level that we can address. Usage Scenarios can have sub-Scenarios that are more focused on specific areas of the ontology. The solutions must address the business needs for the domain experts.

For stakeholders to avoid purely academic activities, all usage scenarios must reference a business-related need statement. A business value statement indicates how addressing the use case will increase profit, reduce pain points, and improve efficiency, safety, or security.

A scenario is typically a paragraph or two describing a situation in which a user intends to use the ontology to answer some questions. It provides additional context to augment the ontology and achieve the stated goals. Every usage scenario may, however, encompass one or more traditional user stories and should enable the development of at least one, but typically several, competency questions.

Examples

• scenario 1:

  • When I’m trying to schedule a job to run on my shop floor, I have some process requirements, designs, and equipment, but I need to find the right machine and make sure it’s available, in a usable state, and has tooling, and someone isn’t using it for some other process.

• scenario 2:

  • As a supply chain manager, I need to find a company with an NAICS code to find a company with a certain classification to produce a part.

  • I need to find a pipe bending company certified for 3D bending of an O2 pipe in a submarine.

  • Competency questions associated with this story:

    • Find a company C that has NAICS code N for pipe bending capability P for 3D bending with attestation A from organization O that has evidence that the attention process verified capability P against standard S

      • SPARQL: …

      • Individuals: C, P, S, A, O

• As a supply chain manager, what companies manufacture jet engine parts in my supply chain? I have an agile supply chain and want to find new companies that may not be in my current set of suppliers. How do I find a new company?

• As a supply chain manager, I want to evaluate supplier efficiency and quality.

Competency Questions

A competency question is associated with one usage scenarios with one or more sample answers and a description of how you expect to get that answer, including but not limited to the relevant resources. The details provided for any competency question should describe at least one way you expect to use the semantics and/or provenance to propose an answer to the questions. Include an initial description of why the semantics and/or provenance representation and reasoning provide an advantage over other obvious approaches to the problem. (optional–depending on the use case and need for supporting business case).

If competency question maps to more than one usage scenario, then the usage scenario has not been correctly factored and the usage scenarios should be separated.

A competency question is a statement that can be translated into SPARQL to validate that the
resulting ontology can satisfy the usage scenario. The competency question must have associated
data to validate it. The data should come from real data sources identified by the domain experts.
Simulated data may be used but is of lesser quality since it will be made to fit the requirements
of the ontology.

A competency question without data will be considered non-viable.

Ontologies: Principles, Methods, and Applications

Scoping Requirements

This provides scope for developing the user scenarios, focusing on what part of the Epic we are addressing in the current development cycle and any constraints on the development process that may need to be considered when selecting the terms and ontological constructs. The requirements will not replace user scenarios or competency questions.

The scope provides the context and the rational for what we will be addressing.

Examples

• What ontology terms are necessary for manufacturing a jet engine in my supply chain referring to User Scenario X

• What terms are necessary for evaluating supplier efficiency?

Process for drilling down to scoping requirements.

We need to clearly differentiate competency questions from requirements. We should not use requirements as a replacement for competency questions.

Capture decisions made by the working group to scope and slice the ontology.

Specification of developing constructs. Functional and non-functional requirements regarding the development of the ontology.

• Scoping decisions

• What level of detail and constructs are available to meet the competency questions

Terminology Development

Construct Excerption

Extraction of keywords and key phrases from the vocabularies, glossaries, policies, procedures, process, and business architecture artifacts, standards, best practices, and other documentation available to create a preliminary term list, with preliminary definitions and other annotations. Note that natural language processing tools can extract key terms from a corpus of documents. Terms are also solicited from domain experts.

It is of the utmost importance to record the source and context for every term to support provenance, traceability, and explanation generation. Traceability from the original source for a term, as well as for the source of the definition of that term, in the form of annotations, is essential to the ontology development process.

Note: If the source of the data is a working group activity, the source of the data must be stated as the working group.

Domain Expert Definitions

From the initial phase collecting usage scenarios and reviewing terminology from domain experts and subject matter experts using the domain language vocabulary.

In the second phase, the terms are further refined using rules from ISO 704 and related standards (e.g., ISO 1087) to present a curated set of vetted definitions.

Constructs in Jira

The WG groups the constructs into Jira issues based on relations and dependencies. The Jira issues are assigned to the ontology developers to begin creating OWL ontology and SPARQL queries.

Ontology Development

Issue and GitHub Workflow

Development Process

Concept Diagram