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 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 Use Cases and User Scenarios. In addition, an Epic requires multiple constructs to satisfy the domain concerns.
...
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.
...
What do we do when we don’t have adequate business value statements?
Competency questions may not be evident?If .
Why do we do this 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, But we should still be able to support some business needs for other domains
SysML 2.0 must have engineering use cases
...
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 expressed as a paragraph or two describing a situation where in which a user intends to use the ontology to answer some questions. It provides additional context to augment the ontology to 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. 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
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.
...
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).
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.
...