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

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. The Epic aligns with a high-level need by the industry to provide some capability in the standard. It must be aligned with business objectives and provide someone with 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 for tracking all related parts. An Epic has multiple Use Cases and 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.

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?

• If we don’t have a business reason, then why do we do this?

• 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

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 cases in the issue repository are related as sub-issues of the Epic.

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 or improve efficiency, safety, or security.

A scenario is typically expressed as a paragraph or two describing a situation where a user intends to use the ontology to answer some questions. It provides additional context to augment the ontology to 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. A use case should include at least three to five usage scenarios.

Cloud to clam level of scenarios.

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

Competency Questions

A competency question is associated with one of the usage scenarios expressed in the use case,
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).

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

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