Ontologies
MBE Ontology
The MBE (Model Based Engineering) Ontology is SBE’s default ontology, which enables the integration and of engineering data and tools, that ships with the software.
The goals of the MBE ontology are as follows - in priority order:
Provide the ability to have the SBE system become functional immediately after installation and setup for SBE customers for both basic interoperability and reporting & analytics use cases.
To provide 80% metaclass coverage across all SBE adapters so that nothing “typically important” that published to the digital thread is just completely dropped.
To provide built-in guidance to customers about how digital thread entities fit into a larger, more universal ontological structure.
Upper Level Ontologies
MBE extends two upper level ontologies in order to prepare for the future day where the engineering information artifacts SBE manages will be correlated with the real-world instances of things the information is “about”.
To learn more about these upper level ontologies read more here.
Here is a list of key classes from the upper level ontologies that are relevant to MBE.
BFO
Entity – The root level class. Everything in the universe is an entity.
Continuant – An Entity that exists independent of time, as opposed to an “Occurrent” which is dependent on time. Continuants could be books, ideas, or information. Occurrents could be a process step, a time frame, or an instant in time.
Generically Dependent Continuant – A Continuant that depends, in a generic way, on something else for it’s existence.
IEO
Information Content Entity (nickname “ICE”) – A Generically Dependent Continuant whose existence is dependent on some other Entity that the ICE is “about”. Information is always “about” something. For information to exist, the thing it is about must exist first. Because an ICE “is about” any Entity, an ICE can be about other Information Content Entities.
Containment: SBE’s MBE Ontology adds the notion of containment to ICE. An ICE has a “contains” relationship (and it’s inverse “contained-by”) to indicate that it can contain any number of other ICEs.
At this time, all classes in the MBE ontology are Information Content Entities. Additional key subclasses below ICE are as follows.
Descriptive Information Content Entity – An Information Content Entity that holds information that describes whatever the Descriptive Information Content Entity is about. That is, whatever the Descriptive Information Content Entity it is related to via it’s “is about” ontological relation.
Directive Information Content Entity** – An Information Content Entity that holds information that is intended to directs an agent of some kind to perform an action. That said, it has not locally defined relational restrictions at this time.
Descriptive vs Directive Controversy
There has been much discussion about this break between Descriptive ICE and Directive ICE. This is in part because whether a piece of information is describing something or providing direction is largely a matter of perspective – that is, it is a role-based concept. One man’s description is another man’s directions.
In engineering, one could argue that every piece of information is directive because the entire purpose of engineering is to provide specific directions to an organization so that it can create a system. On the other hand, one could argue that all engineering information is descriptive because everything is always “about” a system – either one created in the past, one that already exists, or a notional one that might exist in the future.
There is even a third perspective which is that some engineering information can be created as a model for it’s own sake, for it’s own purpose – not unlike art. In which case it is neither describing anything or directing anyone.
Looking at the subclasses that CUBRIC have provided within IEO does not really resolve this problem as they don’t appear to have been carefully curated. Since this controversy is not likely to be settled anytime soon, and since it does not impact SBE interoperability a practical guideline needed to be established:
If the ICE is predominantly concerned with providing instructions to readily identifiable agents for action in the near term it is considered a Directive ICE. If the ICE is describing a past, present, or notional future system or any aspect of it, it is a Descriptive ICE. If we are unsure, it if a Descriptive ICE.
MBE URI Schema
Classes
http://www.sbevision.com/MBE/Class#class_name
Properties
http://www.sbevision.com/MBE/property#has_property
If the property is Class-specific
http://www.sbevision.com/MBE/property/Class#has_property
If the property is a relation
http://www.sbevision.com/MBE/relation#has_relation
Annotations
http://www.sbevision.com/MBE/annotation#annotation_name
MBE Modularity
At some point in the future, it may make sense to have MBE broken up into multiple independently lifecycled ontologies. This would avoid the problem of having to version a monolithic ontology whenever SBE wants to add a class to a lower level ontology. Important goals here include:
Maintain high cohesion within a sub-ontology. That is, all the classes within a sub-ontology should go together because they serve the same purpose and/or are frequently interrelated.
To have relatively loose coupling between modules where inter-class relationships are kept to a minimum.
A logical approach to the divisions of MBE would be to slice along the lines of the “roles” of the digital tools that are the source of the information artifacts of the digital thread. Based on the current set of adapters the set of roles include:
Requirements & Use Case Management
Project & Change Management
Model-Based Systems Engineering
Electrical / Electronics Design
Mechanical Design
Simulation & Analysis
Functional Safety
Software Engineering
Product Structure Management
Manufacturing Planning & Execution
Verification & Testing
These 10+ roles could inform the choices of how the MBE ontology should be broken up into modules.
Best Practices
Limit the taxonomy of classes to single inheritance
Do not modify or enhance imported classes in OWL/Protege (not possible in SBE)
Always use the MBE URI schema
Use underscores as spaces in OWL URIs
Add a human readable label annotation to every class, object property, and data property.
OWL is open world, SBE is closed world, thus every thing that should be the case must be expressed in OWL as a subclass restriction
Avoid the trap of spending too much time on any one issue. Remember that ontologies serve a purpose and they are not an end in themselves.
Classes
At every level of the taxonomy, make sure there is a consistent difference between all the child classes
For MBSE classes, document your thinking in the MBSE mapping spreadsheet
OWL Data Properties
Every datatype property should be set to be a functional property.
All optional properties have min cardinality 0
All required properties have ‘some’ cardinality.
OWL Object Properties (Relations)
When creating a new object property, always first try to reuse an existing object property instead. If a new one must be created, always try to first extend from an already extant object property.
Avoid the trap of creating object properties (i.e. relations) with the name of a class in the relation (e.g. has_issue, has_priority, has_status, etc.) - just reuse/overload an appropriate relation.
Most, if not all, object properties should have inverse of defined denoting directionality.
Object properties should annotated with omnidirectional name in order for the OWL Importer to process directional relationships.
"omnidirectional_name" is a custom annotation from MBE (http://www.sbevision.com/MBE/annotation#omnidirectionalName)
Suppose there are two object properties that are inverse of each other
Satisfies By
Satisfies
The omnidirectional name could be annotated as "Satisfies" on both of the object properties. This is for SBE to distinguish which inverse relations represent a single relation, so there's no rule for deciding the omnidirectional name, just choose what makes the most sense.
Object properties (relations) can be either functional or non-functional depending on their multiplicity.
Optionally, directionality may be defined for directed relationships. (inbound/outbound)
Open Issues
We have not yet decided on a way to handle complex data types (Point 3d, lists, maps, arrays, etc.)
Current thinking: Complex datatypes could be represented as object property values using a class containing the predicate propertyOf and associated values, describing the datatype (list, set, dictionary…).
Updating OWL ontology files in Gitlab/Postman
Let your changes to MBE be driven from a ticket on the JIRA board
All changes to MBE should go through the merge request (MR) process in Gitlab
Checkout a new branch from develop, name the branch based on the ticket.
Pull from develop frequently, prior to starting a ticket and prior to finally merging your branch to develop, merge from develop to your branch if necessary.
Create a merge request
Assign the approver and resolve merge conflicts.
Once approved, merge the branch to develop.
Don't approve your own merge request
Release Notes
2.2.0
ONTO-84 Remove Model Full Proxy / Model Full Port
ONTO-85 Move Model Component to inherit from from Descriptive Information Content Entity
ONTO-86 Add name property to all Aggregate Information Contentity Entities
ONTO-87 Add Name property to Use Case
ONTO-90 Add ID Property to Digital Thread Information Content Entity