This section is intended to provide background material for MBSE ontology development.
In common usage, a model is anything used to represent anything else. Scientific models are used represent physical objects and factual relationships. Engineering models represent some part of the physical universe, such as a physical system or manufactured product. A thing or system can be represented by many different models. Models may have different levels of abstraction and purposes.
A model may have multiple interpretations, where an interpretation is anything that satisfies the model. Building a model for a product does not itself guarantee that any implementations of the model exist. In logic, terminology regarding models is reversed; a model is an interpretation of the representation. However, the concepts of representation and implementation are similar.
Figure 1 Composite Model air system and a visualization of its realization as an airsystem operating to perform ISR mission
When we use a model to specify a new system, describe systems to be analyzed, or how a system being specified will perform in its physical operating environment, issues of the relationship of the model to its possible realizations become critical. Is the model sufficiently precise and constraining to eliminate unintended realizations?
When using models represented within a modeling domain to design or analyze a system, one uses the knowledge of control theory, aircraft dynamics, and other engineering disciplines to establish the control laws and to model the physical environment. When the concepts used by the models are identified and made precise they become an ontology. An ontology defines the concepts and their relationships within a language. The concepts, relationships, and constraints related to a specific product domain such as ‘car,’ ‘axle,’ or ‘bolt,’ used within a product modeling language are ontology candidates. Physical environment models, including aircraft body dynamics, actuator dynamics, etc., are ontology candidates The term “ontology” in its modern information science usage refers to a formal, explicit specification of a shared terminology. A domain ontology is one which can be used for modeling a specific domain such as engineering. An engineering domain ontology provides terminology for modeling physical objects, their properties such as parts and connections as well as properties which are observed and measured. For example, candidate terminology for an engineering domain might include physical object for entities as vehicles. The types used by measurable properties, such as location for a physical object, are complex and must account for different kinds of measurements and units. In domains such as biomedicine, which construct and use ontologies, multiple ontologies are generally used. Physical object properties such as weight, shape, color that are observed or measured become standardized which enables better sharing of the models. The distinction between an ontology and a model is imprecise. An ontology is viewed as a Knowledge Base (KB) within the knowledge representation community and is defined as an axiom set within OWL2 and other logic based approaches. OMG defines an ontology as a data model. In MBSE, a model is a representation of a system. A SysML model can be viewed as an ontology. Concepts used by a model are often viewed as an ontology. For example, when one wants to standardize concepts such as an electronic emitter with defined properties, then these would be candidates for an ontology for MBSE use. The ontology might be in the form of a SysML model that would be included by a model describing a specific system. For a candidate ontology to be useful and become generally accepted and dominant, it must be used and reused across different applications, as well as having been designed according to best practices. The issues facing the development of system engineering languages and ontologies with a formal semantics are similar to issues in other scientific domains, such as cell biology. Many of the solutions for system engineering are likely applicable to other domains. Conversely, solutions developed in these other domains are likely applicable in system engineering. In “Toward Principles for the Design of Ontologies Used for Knowledge Sharing” Tom Gruber is credited with a definition of ontology as a specification of a conceptualization for a domain. This definition has been the starting point for the development of modern ontologies. An ontology then defines the common terms and concepts (meaning) used to describe and represent an area of knowledge. An ontology can range in precision from a Taxonomy (knowledge with minimal hierarchy or a parent/child structure), to a Thesaurus (words and synonyms), to a Conceptual Model (with more complex knowledge), to a Logical Theory (with very rich, complex, consistent, and meaningful knowledge).
Contemporary ontologies share many structural similarities, regardless of the language in which the constructions are expressed. Common ontology and modeling languages include some or all of the following concepts:
A domain ontology (or domain-specific ontology) models a specific domain, or part of the world. It represents the particular meanings of terms as they apply to that domain. An upper ontology (or foundation ontology) is a model of the common objects that are generally applicable across a wide range of domain ontologies. It contains a core glossary in which a set of domains can be described. There are several standardized upper ontologies available, including Dublin Core, GFO, OpenCyc/ResearchCyc, SUMO, and DOLCE.
As the domain of engineering is exceptionally broad, including not only the descriptions of products but also the environments in which they operate multiple ontologies will almost certainly be required to obtain coverage of the domain. A mathematical model of a physical system uses physical quantities such as space (length, breadth, and depth), mass, force, temperature, and energy as values for properties of physical objects. Gruber notes that a mathematical model of a physical system uses variables to represent physical quantities. A physical quantity is a measure of some quantifiable aspect of the modeled world. Physical quantities come in several types, such as the mass of a body (a scalar quantity), the displacement of a point on the body (a vector quantity), the altitude of the particle as a function of time (a unary scalar function quantity), and the stress at a particular point in a deformed body (a second order tensor quantity). What makes quantities “quantifiable” is the ability to combine them with algebraic operations. The types of quantities determine the conditions under which operations are allowed and the types of the results. For example, it does not make sense to add a mass quantity and a displacement quantity, and the result of multiplying a length and a length—(an area). His ontology specifies conditions under which various algebraic operations on quantities make sense. The concepts the ontology DOLCE Ultra Lite (DUL), derived from the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) align naturally with systems engineering concepts as multiple authors have observed the DUL class hierarchy has a number of classes useful for systems engineering including classes for Physical Object, Quality (similar to physical quantity), Event, and Region. Physical objects exist in time and have qualities such as weight, shape, color that are observed or measured. Physical Object is used to classify objects that occupy space and have mass. Qualities classify the entities measured characteristics, such as weight and color. Quality is used to classify properties that are perceived or measured about some other entity. Examples of qualities are color, length, mass, and shape. Region is used to classify the actual value of qualities associated with particular entities. Regions are data types that coordinitize the space of measurement values. Qualities classify the entities measured such as weight and color.
Some ontologies make a distinction between objects and their substrates, e.g. the space they occupy and the matter they are made of. The reason of this distinction lies in the different identity criteria of the entities involved. For example, a solid block is recognized in a given situation on the basis of properties, like having a certain shape and size, and being made of a certain material. By verifying these properties one can recognize the same block.
In order for an ontology to be used in a computing application, it must be represented in a computer-readable form. There are several approaches to representing ontologies in computer-readable form. Ontologies are commonly encoded using ontology languages. An ontology language is a language used to encode the ontology. There are a number of such languages for ontologies, both proprietary and standards-based. Some examples are:
A language, to be implemented either for computation or communications, is a mapping from the abstract syntax to specific machine representations. Encodings must be defined; these may be called the “concrete syntax” (in language implementation) or the “transfer syntax” (in communications). A computer’s internal representation of a model will typically be specified by an abstract syntax in terms of categories such as “statement”, “expression” and “identifier”. This is independent of the source syntax (concrete syntax) of the language being compiled (though it will often be very similar). A language description includes the syntactical rules which define syntactically correct sentences. However, syntax can be divided into two: the concrete syntax and the abstract syntax. Languages can have, and often do have, multiple concrete syntaxes. Languages that have a separate interchange format (often XML-based) means that they have multiple concrete syntaxes a ’normal’ syntax and an interchange syntax. The formal structure is called abstract syntax and the representations concrete syntaxes. Any syntax must be formally equivalent to the syntax in which the system is specified.
In OMG terminology, a metamodel is a specification for an ontology and the modeling language in which the ontology is expressed. A metamodel represents the abstract syntax of the language. A metamodel is intended to provide an unambiguous specification of an ontology in terms of its structure.
Figure 2.Models are expressed in a modeling language that is described by a metamodel. The model conforms to the metamodel. The terms are used according to [Bézivin, Favre].Metamodels can be expressed using another (meta) modeling language that is described by a meta-model (sometimes referred to as meta-metamodel).
OMG has created a set of metamodels in the meta metamodel Meta-Object Facility (MOF). The Meta Object Facility (MOF), an OMG standard, provides a metadata management framework, and a set of metadata services to enable the development and interoperability of model and metadata driven systems. MOF is a subset of the UML class metamodel, itself expressed in UML. MOF is a meta metamodel with roughly the expressive power of BNF???. What differentiates MOF from other meta metamodels, though, is the visual syntax used as a concrete syntax in representing the abstract syntax of the system to be modeled. One of the advantages of UML, and hence the MOF, is that there is a well-established relationship between UML Class diagrams and database schemas, implemented by many more-or-less automatic tools. As the framework used for defining specific modeling languages, the MOF specification adopts a four-layer metamodeling architecture:
If the metamodel is itself expressed in a widely-used meta metamodel, there is the potential for software to be created by configuring a standard set of tools for/to? the meta metamodel. BNF is an example of a meta metamodel that is a metamodel for developing metamodels. The most prominent example of a Layer 2 MOF model is the UML metamodel. The model that describes this M3-model is the language used by MOF to build metamodels, called M2-models. the UML itself???. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe real-world objects. The Ontology Definition Metamodel (ODM), as defined in http://www.omg.org/spec/ODM/1.0, is a family of MOF metamodels, mappings between those metamodels as well as mappings to and from UML, and a set of profiles that enable ontology modeling through the use of UML-based tools. The metamodels that comprise the ODM reflect the abstract syntax of several standard knowledge representation and conceptual modeling languages that have either been recently adopted by other international standards bodies. MOF OWL2 metamodel describes the canonical structure of OWL 2 ontologies in a way that is independent of the syntax used to serialize the ontologies. The specification consists of 22 UML class diagrams. The MOF OWL2 meta model defines an ontology as consisting of a set of axioms and of a set of annotations; furthermore, it shows that an ontology can import a set of ontologies and that each axiom can contain a set of annotations. OWL 2 axioms are defined as subclasses of the abstract class Axiom within a metamodel specification.
However, a metamodel does not in itself provide semantics for a modeling language and the ontologies and models represented within it.
When a formal language is used for modeling, i.e., representing domains of interest, then in addition to the syntax which defines all the (syntactically) correct sentences of the language, the language has semantic specification which is used to convey the meaning of sentences in the language. Formal semantics for an axiom system within a language may be defined in terms of its interpretations or in terms of an inference mechanism.
In logic and mathematics, a formal system consists of a formal language plus a set of inference rules for deriving new knowledge from previously derived knowledge. For example, a metamodel may be used to specify the formulas of the language. An axiom is a formula language asserted as a priori knowledge about the domain of application. Theorems are assertions derived from axioms using inference rules. The theorems include all the axioms, plus all formulas which can be derived from previously-derived theorems by means of inference rules. When ontologies and models are represented within a logical system such as OWL2, the ontology is an axiom set. For example, DUL has been isolated and axiomatized in OWL and can be downloaded and used in Protégé, the OWL tool.
An interpretation of an axiom system in a domain is a mapping which preserves typing operations. A model of an axiom system is an interpretation in which the axioms are true in the interpretation. An axiom system is said to be satisfiable if it has a model in the logician’s sense of the word model.
SysML plays a benchmark role in the MBSE ontology activity. SysML has been designed to have the expressivity needed to model systems. In this sense SysML is an ontology language. SysML contains the first six of these language constructions. It is the most wide spread general purpose system modeling language. However, there are no established ontologies for use in building SysML models and SysML does not have a recognized formal semantics.
Ontology engineering (or ontology building) is a subfield of knowledge engineering that studies the methods and methodologies for building ontologies. Guidelines for how to use UML constructions in modeling have been addressed in [Guizardi, Herre, Wagner]. OntoClean, a formal methodology for ontology engineering developed by Nicola Guarino and Chris Welty, has been used to analyze and develop ontologies for physical objects. OntoClean is based on met properties of classes such as identity, unity, rigidity, and dependence. These met properties can be used for example, to analyze concepts such as wholes. The intuitive of a whole is an individual all of whose parts are related to each other, and only to each other, by some distinguished relation which can be viewed as a generalized connection relation.
Domain ontologies may represent concepts in very specific and often incompatible ways. As systems that rely on domain ontologies expand, they often need to merge domain ontologies into a more general representation. At present, merging ontologies that are not developed from a common foundation ontology is a largely manual time-consuming process. Domain ontologies that use the same foundation ontology to provide a set of basic elements can be merged automatically.