Ontological Modeling Language 1.4

This version:
https://www.opencaesar.io/oml/v1
Issue Tracking:
GitHub
Editors:
Maged Elaasar (JPL)
Nicolas Rouquette (JPL)

Copyright © 2019 California Institute of Technology. Government sponsorship acknowledged.

Abstract

This document describes the Ontological Modeling Language (OML). This language enables defining systems engineering vocabularies and using them to describe systems. OML is inspired by the Web Ontology Language 2 (OWL2) and the Semantic Web Rule Language (SWRL) and can be considered a gentler and more disciplined way of using these standards in the context of Systems Engineering. By mapping the OML constructs to a number of patterns expressed in subsets of OWL2 and SWRL, OML inherits its expressivity, modularity, extensibility, and description logic (DL) semantics, but also provides a concise and user-friendly syntax. Moreover, OML is implementd using the Eclipse Modeling Framework (EMF), which gives it a Java API and integration with a large ecosystem of modeling frameworks that has been used to develop useful tools, many of which are provided by the openCAESAR project.

1. Document Organization

This document is targetted at system engineering methodologists, engineers, as well as toolsmiths who are interested in OML.

The section named Getting Started is targetted at any reader. It walks the reader through and demonstrates the use cases of working with OML.

The section named Language Reference is mostly targetted at methodlogists. It describes how to use OML to create vocabularies for a systems engineering methodology and what it means in terms of what the systems engineers would be able to describe with it. While it can also read by systems engineers, it would only serve the purpose of teaching the general OML idioms, and not the specific systems engineering methodology that the systems engineer need to learn to be effectively. For that, the systems engineer should read the methodology’s own documentation.

The section named Textual BNF is targetted mostly at methodlogists but can also be used by engineers. It describes the BNF grammar of OML. This can help readers understand textual OML models and create them using an OML text editor. In practice, OML vocabularies and example system descriptions are typically created using a text editor, but real sytem descriptions are typically created using methodology-specific higher level UI that is described iin the methodology’s own documentation.

The section named Grahical BNF is targetted mostly at methodlogists but can also be used by engineers. It describes the graphical BNF grammar of OML. This can help readers understand standard OML diagrams and visualize them using graphical viewers. In practice, OML vocabularies and example system descriptions are typically visualized using this notation, but real sytem descriptions are typically visualized using methodology-specific notation that is described in the methodology’s own documentation.

The section named Abstract Syntax is targetted mostly at toolsmiths but can also be used by methodologists. It describes the constructs that make up the language, along with their attibutes, relations and constraints. Each set of related constructs are listed under a sub heading, visualized using a UML class diagram under that sub heading, where they appear in white color (other related constructs appear in grey color), and described in details including their super classes, subclasses, properties and constrainsts. Various hyperlinks are provided to help the reader navigate the constructs.

The section named Public API is targetted at toolsmiths. It describes the Java API of OML that can be used to create language tools, including adapters (transformations between OML and other languages and formats), interfaces (to other tools) and UI tools (viewers/editors). Some of the public API maps directly from the corresponding OML abstract syntax. Other API adds useful functions that make working with OML programmatically easier.

The section named Mapping to OWL2 and SWRL is targetted at both methodologists and toolsmiths. It describes the semantics of OML by mapping them to the semantics of OWL2 and SWRL. It accomplishes that by giving the mapping of every OML construct to a pattern defined in a subset of OWL2 and SWRL. This can help a methodologist understand the semantics of OML constructs. It can also help a toolsmith define new tools for OML.

1.1. Document Conventions

1.2. BNF Conventions

The document uses BNF notation to specify allowed expression syntax in the textual and graphical notation. The following BNF symbols are used:

2. Getting Started

2.1. OML Project

An OML project is a root folder that typically nests OML files, a catalog file, and a build file as follows:

.
├── build
│   └── oml
│       └── www.w3.org
│           └── 2001
│               └── XMLSchema.oml
│           └── 2002
│               └── 07
│                   └── owl.oml
├── src
│   └── oml
│       ├── imce.jpl.nasa.gov
│       │    └── foundation
│       │      ├── base.oml
│       │      ├── analysis.oml
│       │      └── mission.oml
│       └── europa.jpl.nasa.gov
│           └── lander
│             ├── assemblies.omlxmi
│             ├── endcircuits.omlxmi
│             └── functions.omlxmi
|
├── catalog.xml
└── build.gradle

2.2. OML File

An OML file has the extension oml (if it uses the OML textual syntax), omlxmi (if it uses the OML XMI syntax)or omljson (if it uses the OML Json syntax). It can be directly at the root of an OML project or nested in sub folders. OML files that are manually authored are typiclally nested under a src sub folder, while those that are machine produced are typically nested under a build sub folder. Each OML file defines a single OML ontolopgy which has a unique hierarchical IRI. The nesting path of an OML file typically corresponds to the nesting path of its ontology IRI. For example, an ontology with an IRI http://imce.jpl.nasa.gov/foundation/base# is persisted in a file with a path imce.jpl.nasa.gov/foundation/base.oml. The syntax of an OML file is discussed in the language reference section.

2.3. Catalog File

A catalog file provides a mapping from the OML ontology IRIs to their corresponding file paths under the project. This enables an OML ontology to import another ontology using the latter’s logical IRI, without worrying where the file physically exists under the project. The catalog file is defined based on the OASIS XML Catalog standard. The standard allows defining the mapping rules in several ways. One common way is using a rewriteURI rule, which has an attribute uriStartString that specifies a prefix for an IRI, and attribute rewritePrefix that specifies the corresponding file path prefix. For example, using the first rewriteURI rule in the catalog below, the IRI http://imce.jpl.nasa.gov/foundation/base would be mapped to the file path src/oml/imce.jpl.nasa.gov/foundation/base.oml, whle using the second rewriteURI rule, the IRI http://www.w3.org/2002/07/owl would be mapped to the file path build/oml/www.w3.org/2002/07/owl.oml.

<?xml version='1.0'?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public">
  <rewriteURI uriStartString="http://imce.jpl.nasa.gov/" rewritePrefix="src/oml/imce.jpl.nasa.gov/" />
  <rewriteURI uriStartString="http://" rewritePrefix="build/oml/" />
</catalog>

Note: If an IRI is mappable by more than one catalog rule, the most specific rule is used.

Note: Catalog IRI resolution checks the existence of files with OML extensions in this order: oml, omlxmi, then omljson.

Note: To be considered a valid OML file, the file needs to be mappable by some rule in a catalog file.

2.4. Build File

The build file is a standard Gradle file that describes an analysis pipeline for the OML project. In addition to plethora of gradle plugins/tasks that can be used to construct the pipeline, the [openCAESAR] project (the home of OML) provides some addiional ones that are particulary useful for OML analysis. The following is a list of links to those tools for additional information:

3. Language Reference

This section presents the OML language features using its textual syntax as a notation. All the presented features exist in the other syntaxes except when noted otherwise. It is recommended that a reader starts with the common idioms section to gain an understanding of the language’s basics, before reading the other sections.

Note: This document frequently uses BNF grammar to specify OML’s textual syntax. In such grammar, terminals like IRI and NAMESPACE, representing features of OML elements, may be used. To be more precise, we use the syntax [Type|Terminal] to indicate that a terminal represents a feature of a particular type . For example, [Concept|IRI] means the IRI of a Concept, and [Vocabulary|NAMESPACE] means the NAMESAPCE of a Vocabulary.

3.1. OML Idioms

3.1.1. White Space

Whitespace can be freely placed in the OML textual syntax (only) to delimit tokens, but otherwise has no other significance.

3.1.2. Comment

Comments with the following syntaxes can be freely placed in the OML textual syntax:

// single-line-comment

/* possibly
  multi-line
  comment */

Note: A comment is a textual-syntax feature only, hence will not be preserved when a model is converted to OML’s other syntaxes.

3.1.3. Ontology

An ontology is the root element of an OML model and the unit of organizing ontological statements. It is defined with one of the <ontology> keywords (see ontology syntax for details), a globally unique NAMESPACE, a locally unique ID (representing a NAMESPAC prefix), a set of imports (of other ontologies), and a set of statements (members and/or references).

<ontology> NAMESPACE as ID {
    <import>*
    <member|reference>*
}

An ontology’s NAMESPACE is made up of an IRI and a separator character (either # or /). For example, http://www.w3.org/2002/07/owl# is a logical NAMESPACE that consists of IRI http://www.w3.org/2002/07/owl and separator character #. An ontology’s IRI can be any opaque string but is usually specified as a URL in the format http://<organization>/<path>. An ontology’s ID is a short name that is used as a NAMESPACE prefix (e.g., owl is a prefix for http://www.w3.org/2002/07/owl#) when referencing an ontology member using the ABBREVIATED_IRI syntax (see section IRIs below).

OML supports 4 kinds of concrete ontologies that address different use cases:

3.1.4. Import

An ontology can import zero or more other ontologies, which allows it to cross-reference the imported ontologies' members. This is accomplished by an ontology adding an import statement in its body (before other kinds of statements). An import statement is declared using one of the <import> keywords (see import syntax for details) followed by the imported ontology’s NAMESPACE and optionally its ID.

<ontology> NAMESPACE as ID {
    <import> [Ontology|NAMESPACE] (as ID)?
}

Note: An ID is required in the import syntax only when imported members are cross-referenced using the ABBREVIATED_IRI syntax.

Note: An ontology’s import closure is defined as all the ontologies that are imported directly or indirectly by the ontology

Note: An ontology whose members are referenced by another ontology needs to be directly imported by it (it is not enough to be indirectly imported).

OML supports several kinds of concret imports for each one of its ontology kinds:

3.1.5. Member

An ontology can define zero or more members, which are named elements whose IRIs consist of their ontology’s NAMESPACE concatenated to their own (name) IDs. For example, a member whose name ID is AggregatedElement, and is defined in an ontology with the IRI http://imce.jpl.nasa.gov/foundation/base#, has a member IRI http://imce.jpl.nasa.gov/foundation/base#AggregatedElement.

<ontology> NAMESPACE as ID {
    <member> ID
}

Members can only be defined by their own ontology but can be referenced by other importing ontologies. Different ontology kinds define different member kinds (see the various ontology sections for details). The syntax for declaring members vary depending on the member kind, but at least consists of one of the <member> keywords (see members for details) followed by the member’s ID that must be unique within the ontology.

OML supports several kinds of concrete members for each of its ontology kinds:

3.1.6. Reference

An ontology can have zero or more references, which are constructs that allow adding extra statements about existing members (as opposed to defining new ones). The referenced members may either be local to the ontology or external (i.e., defined by another ontology in its import closure). A syntax of a reference consists of the keyword ref followed by the one of the <member> keywords and then the member’s IRI. The IRI can either be the member ID (when it is local to the ontology only), its FULL_IRI or its ABBREVIATED_IRI.

<ontology> NAMESPACE as ID {
    ref <member> IRI
}

An example of an extra statement that can be added on any reference is an annotation. However, other statement kinds may vary based on the kind of the referenced member. In many cases, those statements are the same kinds that can be added to a member definition. In other cases, they are only a subset of them. Sections on the specific member kinds will outline the statements that can or cannot be added to a reference (refer to the Reference syntax for all the details).

3.1.7. IRI

Ontologies and their members have globally unique IRIs within a given context (an ontology and its import closure). The IRI of an ontology is equivalent to its NAMESPACE minus its separator character (# or /). For example, an ontology with NAMESPACE http://imce.jpl.nasa.gov/foundation/base# has IRI http://imce.jpl.nasa.gov/foundation/base. The IRI of an ontology member consists of its ontology’s NAMESPACE concatenated to its ID. For example, a member with ID AggregatedElement in an ontology with a NAMESPACE http://imce.jpl.nasa.gov/foundation/base# has IRI http://imce.jpl.nasa.gov/foundation/base#AggreagedElement. This is called the full IRI of a member. Such IRI can be written in an abbreviated syntax using the ontology’s namespace prefix. It can also be shortened further to the simple ID of the member when used in the context of its defining ontology. The following is an elaboration of the three possible syntaxes for IRIs.

Full IRI

The full IRI syntax in OML conforms to a subset of the standard IRI syntax. However, the OML textual syntax only, it is surrounded by < > (e.g., < http://www.w3.org/2002/07/owl#Thing >). Also, the syntax of an ontology’s NAMESPACE is surrounded by < > (e.g., <http://www.w3.org/2002/07/owl#>).

Note: the < > are stripped off when the value is parsed from the OML textual syntax.

Abbreviated IRI

OML also supports an ABBREVIATED_IRI syntax for ontology members. The syntax consists of the defining ontology’s (prefix) ID and the member’s (name) ID, delimited by the : character. For example, owl:Thing is an ABBREVIATED_IRI for a member with the IRI of http://www.w3.org/2002/07/owl#Thing when the ontology has a prefix ID of owl.

The ontology’s prefix ID that can be used in a member’s ABBREVIATED_IRI either comes from the ontology definition (if the member is local to the ontology) or an import statement (if the member is imported). For example:

<ontology> NAMESPACE1 as X {
    <import> NAMESPACE2 as Y
    <member> M
    ref <member> M                     // reference to a local member
    ref <member> X:M                   // reference to a local member
    ref <member> Y:N                   // reference to an imported member
}

<ontology> NAMESPACE2 as Y {
    <member> N
}

Moreover, while the prefix ID used in an import statement typically matches the prefix ID specified in the imported ontology’s definition, it does not have to match. In fact, the ability to use a different prefix ID in an import statements allows disambiguating a prefix when it is already used by another import in the context. For example:

<ontology> NAMESPACE1 as X {
    <import> NAMESPACE2 as Y
    <import> NAMESPACE3 as Z         // the prefix is different from the definition’s prefix below
    ref <member> Y:N2                // reference to a imported member from NAMESPACE2
    ref <member> Z:N3                // reference to a imported member from NAMESPACE3
}

<ontology> NAMESPACE2 as Y {
    <member> N2
}

<ontology> NAMESPACE3 as Y {
    <member> N3
}

ID

IDs are strings used to specify the prefixes of ontologies and the names of ontology members. The syntax of an ID consists of a sequence of letters, digits, and some other characters.

A simple ID of a member can be used as an IRI for the member when the member is local, i.e., defined as a member in the same ontology. In the following example, the ref statement is referencing member Y by its simple ID, since the member is defined in the same ontology X.

<ontology> NAMESPACE1 as X {
    <member> Y
    ref <member> Y          // the simple ID is used as an IRI of a locally defined member
}

In the OML textual syntax only, when a reserved keyword is used as an ID, it needs to escaped by ^ (e.g., ^concept). For example, the member named concept has its name escaped since concept is a keyword in OML. When used as an IRI, the ^ has to be used as well.

<ontology> NAMESPACE1 as X {
    <member> ^concept                 // a ^ is used since concept is a keyword in OML
    ref <member> ^concept           // a ^ is used since concept is a keyword in OML
}

3.1.8. Literal

A literal represents a value typed by a scalar type (defined by a vocabulary). OML supports specifying a literal as a quoted literal or as an abbreviated literal (for some specific scalars).

Quoted Literal

A quoted literal is a generic way of specifying a literal. It consists of the lexical form followed by a language tag, a scalar IRI, or neither.

The lexical form consists of a set of characters surrounded by a pair of delimiters, which can be single quotes ('value'), double quotes, ("value"), three single quotes ('''value'''), or three double quotes ("""value""").

Note: The last two types of delimiters allow line break characters in the lexical form, while the first two do not.

Note: A delimiter can appear within a lexical form that is delimited by a different delimiter (e.g., "It’s my responsibility")

Examples of quoted literals with different delimiters:

"The system should be responsive"
'''First paragraph
Second Paragraph'''
'true'
"""This is really the engineer’s fault"""

The optional language tag is typically used with translatable string. It allows specifying the natural language the lexical form should be interpreted with. It is specified by appending the $ character to the lexical form followed by one of the language tags specified in BPB 47 - Tags for Identifying Languages. Examples of quoted literals with language tags:

"This is good"$en
"Ca va bien"$fr

The optional scalar IRI is used to specify the scalar that a literal belongs to (xsd:string by default). However, the reference can be to any of OML’s standard scalars only (i.e., not their specializations). It is specified by appending the ^^ characters to the lexical form followed by an IRI to the scalar. Examples of quoted literals with scalar references:

"Component"^^xsd:string
"2.0"^^xsd:double
'true'^^xsd:boolean

Abbreviated Literal

In addition to the quoted literal syntax, OML supports abbreviated syntaxes for some of the standard scalar types: xsd:integer, xsd:decimal, xsd:double, and xsd:boolean. The abbreviated syntax consists only of an undelimited lexical form that gets interpreted as belonging to one of the supported scalars. Example abbreviated literals:

123         // xsd:integer
-123.4      // xsd:decimal
.827        // xsd:decimal
123E+45     // xsd:double
true        // xsd:boolean

Note: if an abbreviated literal belongs to multiple scalars, it gets interpreted as belonging to the least precise scalar.

3.1.9. Annotation

An annotation allows describing information about an ontology, or one of its members, that does not have associated description logic (DL) semantics. Such information can be notational (e.g., how an element is to be displayed), tool-specific (e.g., how to export an element), or for any other purpose (e.g., who authored the ontology).

An Annotation describes a value for an annotation property (defined by a vocabulary) in the context of the annotated element (an ontology, a member, a reference, or an import). The general syntax of an annotation consists of a @ symbol followed by an IRI to the an annotation property then an optional (literal or member reference) value. If the value is missing, it is interpreted as a boolean true literal.

@[AnnotationProperty|IRI] (Literal | [Member|IRI])?

The following example shows several annotations. The ontology itself has a dc:title annotation as well as a dc:date annotation (notice how the value is a xsd:date literal). The first import statement of the ontology has a rdfs:comment annotation. Also, the member Member1 has two annotations, both of them are rdfs:comment but one has an English (en) literal while the other has a French (fr) literal. Finally, the imported member example2:Member2 is annotation with viewpoint:show (notice that there is no literal value, which will be interpreted similar to a Boolean true literal).

@dc:title "Example1 Ontology"
@dc:date "2/15/2021"^^xsd:dateTime
<ontology> <http://company.com/example1#> as example1 {
    @rdfs:comment "This is needed to reference dc annotation properties"
    <import> <http://purl.org/dc/elements/1.1/> as dc
    <import> <http://www.w3.org/2000/01/rdf-schema#> as rdfs
    <import> <http://www.w3.org/2001/XMLSchema#> as rdfs
    <import> <http://io.opencaesar/viewpoint#> as viewpoint
    <import> <http://company.com/example2#> as example2
    @rdfs:comment "This is member1"$en
    @rdfs:comment "C’est member1"$fr
  @rdfs:seeAlso example2:Member2
    <member> Member1
    @viewpoint:show  // a missing literal is interpreted as Boolean true literal
    ref <member> example2:Member2
}

3.2. Vocabulary

A vocabulary is an ontology that defines a set of terms and rules for a given domain and has open world semantics. A vocabulary is declared with the keyword vocabulary as its ontology kind, followed by its NAMESPACE, the keyword as, and its prefix ID. It also has a body consisting of zero or more vocabulary imports and statements between two braces { }, as follows:

Annotation*
vocabulary NAMESPACE as ID {
  VocabularyImport*
  VocabularyStatement*
}

For example, the following vocabulary allows describing a mission. It has the namespace http://com.xyz/methodology/mission# and the prefix mission.

vocabulary <http://com.xyz/methodology/mission#> as mission {
}

3.2.1. Imports

This section outlines the kind of import statements that can be added to a vocabulary.

3.2.1.1. Extension

A vocabulary extension is a kind of import statement that can be added to a vocabulary to specify that it extends another vocabulary. This is typically needed when members of the extended vocabulary are cross-reference by the local members of the extending vocabulary. A vocabulary extension is defined with the keyword extends followed by the extended vocabulary’s NAMESPACE, followed by the keyword as and a unique prefix ID.

Annotation*
extends [Vocabulary|NAMESPACE] as ID

For example, the mission vocabulary extends the xsd vocabulary (in order to cross reference its scalars).

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component
    scalar property hasId [
        domain Component
        range xsd:string    // a cross-reference to scalar string
    ]
}
3.2.1.2. Usage

A vocabulary usage is a kind of import statement that can be added to a vocabulary to specify that it uses a description. This is typically needed when the vocabulary uses one or more of the description’s instances in its restriction axioms. A vocabulary usage is defined with the keyword uses followed by the used description’s NAMESPACE, followed by the keyword as and a unique prefix ID.

Annotation*
uses [Description|NAMESPACE] as ID

For example, the mission vocabulary uses the organizations description (in order to cross-reference its instances).

vocabulary <http://com.xyz/methodology/mission1#> as mission1 {
    extends <http://com.xyz/methodology/mission#> as mission
    uses <http://com.xyz/methodology/organizations#> as organizations
    concept Spacecraft [
        restricts relation mission:isResponsibilityOf to organization:NASA   // a cross-reference to instance NASA 
    ]
}

Note: descriptions that are used by a vocabulary typically define notable instances that are cross-referenced by other descriptions using this vocabulary.

3.2.2. Types

Types that can be defined in a vocabulary are either classifiers (structured types) or scalars (primitive types). Some classifiers (Aspect, Concept and Relation Entity)) are entities, meaning they can classify named instances (that are unique by reference). Other classifiers (Structure) can only classify anonymous instances (that are unique by value). Also, some scalars (Faceted Scalar) can classify an unlimited set of literals, while other scalars (Enumerated Scalar) can only classify a limited set of literals.

A type can specialize other types of the same kind only. This is done by following the type’s name by the :> symbol then a list of comma-separated supertype IRIs. While a classifier can specialize one or more classifiers (multiple-inheritance), a scalar can only specialize one scalar (single-inheritance). Specialization semantics are further constrained for each type as discussed below.

3.2.2.1. Aspect

An aspect is an entity defined in a vocabulary and represents a mixin type (or a capability) in a modeled domain. An aspect can only specialize other aspects, but can be specialized by any entity. An Aspect cannot be asserted as a type of instances in a description (there is no aspect instance), but can be inferred (by a DL reasoner) as such, if it is one of the supertypes of an asserted type.

An aspect is declared with the keyword aspect followed by the aspect’s name ID. It can optionally specialize other aspects by following its name ID by the :> symbol then a comma-separated list of those supertypes' IRIs. An aspect can also optionally specify a list of axioms enclosed within a pair of square brackets [ ].

 Annotation*
aspect ID (:> [Aspect|IRI] (, [Aspect|IRI])*)? ([
     Axiom*
 ])?

The following example vocabulary defines two aspects: IdentifiedElement and NamedElement where the latter specializes the former (notice how IdentifiedElement is referenced by its ID as a supertype, since it is defined locally within the same vocabulary).

vocabulary <http://com.xyz/methodology/mission#> as mission {
    aspect IdentifiedElement
    aspect NamedElement :> IdentifiedElement
}

Two special aspects defined by the owl vocabulary are: owl:Thing and owl:Nothing. Aspect owl:Thing represents the top of the specialization hierarchy and the implicit supertype of all entities. This means if an entity is declared with no supertype, then it has owl:Thing as its implicit supertype. On the other hand, aspect owl:Nothing is the bottom of all specialization hierarchies and the implicit subtype of all entities. It represents the empty set (has no instances).

vocabulary <http://www.w3.org/2002/07/owl#> as mission {
    aspect Thing
    aspect Nothing
}
3.2.2.2. Concept

A concept is an entity defined in a vocabulary and represents a concrete type in a modeled domain. A concept can specialize other concepts or aspects, but can be specialized by other concepts only. It can also be asserted as a type of a concept instance.

A concept is declared with the keyword concept followed by the concept’s name ID. It can optionally specialize other concepts or aspects by following its name ID by the :> symbol then a comma-separated list of those supertypes' IRIs. A concept can also have a body enclosed by a pair of square brackets [ ] and specify a list of axioms, as well as a comma-separated list of enumerated instances' IRIs preceded by the keyword enumerates.

Annotation*
concept ID (:> [Concept|Aspect|IRI] (, [Concept|Aspect|IRI])*)? ([
    Axiom*
    (enumerates [ConceptInstance|IRI] (, [ConceptInstance|IRI])*)?
])?

The following example vocabulary defines two concepts: Component and Function, where the former specializes two aspects IdentifiedElement and ContainedElement.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    aspect IdentifiedElement
    aspect ContainedElement
    concept Component :> IdentifiedElement, ContainedElement
    concept Function
}
3.2.2.3. Relation Entity

A Relation Entity is an entity defined in a vocabulary and represents a type of reified relation between two other entities, a source entity and a target entity. A relation entity is defined with the keywords relation entity followed by a name ID. It can optionally specialize other relation entities or aspects by following its name ID by the :> symbol then a comma-separated list of those supertypes' IRIs. A relation entity also has a body, which is a pair of square brackets [ ] that specify by IRI the relation’s from (source) entity and to (target) entity, and optionally the names of unreified relations, semantic flags, and/or axioms.

 Annotation*
 relation entity ID (:> [RelationEntity|Aspect|IRI] (, [RelationEntity|Aspect|IRI])*)? [
     from [Entity|IRI]                 // the relation entity’s source
     to [Entity|IRI]                   // the relation entity’s target
     Annotation*
     (forward ID)?                     // an unreified relation from source to target
     Annotation*
     (reverse ID)?                     // an unreified relation from target to source
     functional?                       // each source can be related to a maximum of 1 target
     (inverse functional)?             // each target can be related to a maximum of 1 source
     symmetric?                        // if a source is related to a target, then the target must also related to the source
     asymmetric?                       // if a source is related to a target, then the target cannot be related to the source
     reflexive?                        // a source must be related to itself
     irreflexive?                      // a source cannot be related to itself
     transitive?                       // if A is related to B, and B is related to C, then A is related to C
     Axiom*                            // zero or more axioms of the relation entity
]

The following example vocabulary defines a relation entity named Performs from the concept Component to the concept Function.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    concept Component
    concept Function
    relation entity Performs [
        from Component
        to Function
    ]
}

Since a relation entity is a reified relation, it can be asserted as a type of a relation instance between one or more source instances, and one or more target instances. Such instance can be annotated and characterized with assertions. However, a relation entity can also optionally specify (in its body) one or two companion unreified relations that can be asserted as simple (uncharacterized) links between a source and a target instance. One of those unrefied relations is declared with the keyword forward followed by a name ID, while the other is declared with the keyword reverse followed by a name ID. The forward relation has the from entity as its domain, and the to entity as its range, while the reverse relation has the opposite. When both are declared, the forward and reverse relations become inverse of each other, meaning if one is used to link a source instance to a target instance, the other is inferred as a link from the target to the source. Also, when a relation instance is typed by a relation entity, which has one ore more unreifed relations, such relations are inferred as links between the set of related sources and target instances. The following diagram depicts the design pattern implied by a relation entity.

The example vocabulary below refines the Performs relation entity with two unreifed relations: performs (as forward) and isPerformedBy (as reverse).

vocabulary <http://com.xyz/methodology/mission#> as mission {
    concept Component
    concept Function
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
}

When a relation entity has supertypes, its source entity becomes a subtype of the super relations' source, and its target entity becomes a subtype of the super relation’s target. Also, when named, its forward and reverse relations become sub relations of the supertype’s forward and reverse relations.

The following example vocabulary defines two relation entities, Performs and Provides, where the latter specializes the former. In this case, what is infererd is that Assembly specializes Component, Power specializes Function, provides specializes performs, and lastly, isProvidedBy specializes isPerformedBy. Some of these inferred specializations can also be specified explicitly (e.g., Assembly :> Component).

vocabulary <http://com.xyz/methodology/mission#> as mission {
    concept Component
    concept Function
    concept Assembly
    concept Power
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    relation entity Provides :> Performs [
        from Assembly
        to Power
        forward provides
        reverse isProvidedBy
   ]
}

A relation entity can optionally specify one or more semantic flags (within its body) that define its logical semantics:

The example vocabulary below refines the Performs relation to add the flag inverse functional (to specify that a function can be performed by a maximum of one component), the flag asymmetric (to specify that a function cannot perform a component), and the flag irreflexive (to specify that a component cannot perform itself).

vocabulary <http://com.xyz/methodology/mission#> as mission {
    concept Component
    concept Function
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
        inverse functional
        asymmetric
        irreflexive
   ]
}
3.2.2.4. Structure

A structure is a classifier defined in a vocabulary and represents a structured datatype with anonymous instances in a modeled domain. A structure can specialize and be specialized by other structures. It can also be asserted as a type of a structure instance, which can be used as a value of a structured property.

A structure is declared with the keyword structure followed by the structure’s name ID. It can optionally specialize other structures by following its name ID by the :> symbol then a comma-separated list of those supertypes' IRIs. A structure can also optionally specify a list of axioms enclosed within a pair of square brackets [ ].

Annotation*
structure ID (:> [Structure|IRI] (, [Structure|IRI])*)? ([
    Axiom*
])?

The following example vocabulary defines the structure Point whose instances are anonymous points on a grid.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    structure Point
}
3.2.2.5. Faceted Scalar

A scalar is a type defined in a vocabulary and represents a primitive type that classifies an unlimited set of literals. A faceted scalar is declared with the keyword scalar followed by the scalar’s name ID. It can optionally specialize other faceted scalars as supertypes by following its name ID by the :> symbol then the IRIs of the supertypes.

  Annotation*
scalar ID (:> [Scalar|IRI] (, [Scalar|IRI])*)? ([
   (length UnsignedInteger)?
   (minLength UnsignedInteger)?
   (maxLength UnsignedInteger)?
   (pattern STRING)?
   (language ID)?
   (minInclusive Literal)?
   (minExclusive Literal)?
   (maxInclusive Literal)?
   (maxExclusive Literal)?
])?

OML considers a following set of faceted scalars, from the owl spec, as standard:

vocabulary <http://www.w3.org/2000/01/rdf-schema#> as rdfs {
  // Literals
  scalar Literal
}

vocabulary <http://www.w3.org/1999/02/22-rdf-syntax-ns#> as rdf {
  extends <http://www.w3.org/2000/01/rdf-schema#> as rdfs

  // Literals
  scalar PlainLiteral :> rdfs:Literal
  scalar XMLLiteral :> rdfs:Literal
}

vocabulary <http://www.w3.org/2002/07/owl#> as owl {
  extends <http://www.w3.org/2000/01/rdf-schema#> as rdfs

  // Literals
  scalar real :> rdfs:Literal
  scalar rational :> real
}

vocabulary <http://www.w3.org/2001/XMLSchema#> as xsd {
  extends <http://www.w3.org/2000/01/rdf-schema#> as rdfs
  extends <http://www.w3.org/2002/07/owl#> as owl

  // Decimal Numbers and Integers
  scalar decimal :> owl:Rational
  scalar integer :> decimal
  scalar long :> integer
  scalar int :> long
  scalar short :> int
  scalar byte :> short
  scalar nonNegativeInteger :> integer
  scalar positiveInteger :> nonNegativeInteger
  scalar unsignedLong :> nonNegativeInteger
  scalar unsignedInt :> unsignedLong
  scalar unsignedShort :> unsignedInt
  scalar unsignedByte :> unsignedShort
  scalar nonPositiveInteger :> integer
  scalar negativeInteger :> nonPositiveInteger
	
  // Floating-Point Numbers
  scalar double :> rdfs:Literal
  scalar float :> rdfs:Literal
	
  // Strings
  scalar string :> rdfs:Literal
  scalar normalizedString :> string
  scalar token :> normalizedString
  scalar ^language :> token
  scalar Name :> token
  scalar NCName :> Name
  scalar NMTOKEN :> token

  // Boolean
  scalar boolean :> rdfs:Literal

  // Binary Data
  scalar hexBinary :> rdfs:Literal
  scalar base64Binary :> rdfs:Literal
	
  // IRI
  scalar anyURI :> rdfs:Literal
	
  // Time Instants
  scalar dateTime :> rdfs:Literal
  scalar dateTimeStamp :> dateTime
}

Note: the lexical and value spaces for these standard scalars are described in the (xsd, and owl) standards.

Note: for the standard vocabularies above to be used (cross-referenced) in a project, they must exist as OML files that are mapped by the project’s catalog.xml file. One way to achieve that is to create such files directly under the src/oml folder. However, a simpler approach is to specify a direct or transitive Maven dependency on the core-vocabularies library (in Maven Central) in the project’s build.gradle and invoking the OmlMergeTask on it. This would result in the standard vocabularies getting downloaded to the oml\build folder. An example of doing this can be seen in the oml-template project.

Furthermore, other non-standard faceted scalars can be defined as specializations of standard ones with optional facets (restrictions on the lexical or value space) enclosed within a pair of square brackets [ ].

The following facets are supported:

When a non-standard faceted scalar specifies facets, it must have a single supertype and that supertype must be one of the standard ones. Otherwise, it must have at least one supertype (considered as an alias).

The following example vocabulary defines two faceted scalars: SSN (representing strings with the social security number pattern) and TeenAge (representing positive integers from 13 and 19 inclusive).

vocabulary <http://example.com/primitive-types#> as primitives {
  extends <http://www.w3.org/2001/XMLSchema#> as xsd
  scalar SSN :> xsd:string [
    pattern "^\d{3}-?\d{2}-?\d{4}$"
  ]
  scalar TeenAge :> xsd:positiveInteger [
    minInclusive 13
    maxInclusive 19
  ]
  scalar SocialSecurityNumber :> SSN // alias case
}
3.2.2.6. Enumerated Scalar

An enumerated scalar is a type defined in a vocabulary and represents a primitive type that classifies a limited set of literals. An enumerated scalar is declared with the keywords enumerated scalar followed by the scalar’s name ID. It can also optionally specialize another enumerated scalar as a supertype by following its name ID by the :> symbol then the IRI of the supertype. It can also optionally specify a list of one or more comma-separated literals enclosed within a pair of square brackets [ ]. Those literals represent the limited set that is classified by the scalar. Although both are optional, an enumerated scalar cannot specify a set of literals and a supertype at the same time. if a supertype is specified, the subtype is considered simply as an alias of the supertype and inherits its set of literals.

Annotation*
enumerated scalar ID (:> [EnumeratedScalar|IRI] (, [EnumeratedScalar|IRI])*)? ([
    (Literal (, Literal)*)?
])?

The following example vocabulary defines an enumerated scalar RGB that enumerates three string literals for the colors: Red, Green, and Blue.

enumerated scalar RGB [
      "Red",
      "Green",
      "Blue"
]

3.2.3. Properties

Properties are characteristics of model elements. Two categories of properties can be defined in a vocabulary: annotation properties and semantic properties. An Annotation Property has no logical semantics and can characterize an annotated element (ontology, import, or member) with non-semantic information. On the other hand, a semantic property (Scalar Property or Structured Property) has logical semantics and can characterize classifiers. A semantic property is specified with a domain representing a classifier whose instances can be characterized by such property, and a range representing a type for the values of the property.

A property can specialize other properties of the same kind only. This is done by following the property’s name by the :> symbol then a list of comma-separated super-property IRIs.

3.2.3.1. Scalar Property

A scalar property is a semantic property defined in a vocabulary, whose domain is a classifier (Aspect, Concept, Relation Entity, or Structure) and whose range is a scalar (Faceted Scalar or Enumerated Scalar). This means the values of a scalar property are literals of that scalar range. A scalar property is defined with the keywords scalar property followed by a name ID. It can also optionally specialize other scalar properties by following its name ID by the :> symbol then a comma-separated list of those super properties' IRIs. It also has a pair of square brackets [ ] that contain the property’s domain (referencing a classifier), range (referencing a scalar), and optionally a semantic flag (functional) that specifies whether instances of the domain can have a single value maximum for this property.

Annotation*
scalar property ID (:> [ScalarProperty|IRI] (, [ScalarProperty|IRI])*)? [
  domain [Classifier|IRI]
  range [Scalar|IRI]
  functional?                // each instance can have a maximum of 1 value for this property
]

The following example vocabulary defines three scalar properties named hasId, hasName, and isAbstract. The hasId property is functional and has a domain of Component and a range of xsd:string. The hasName property has a domain of Function and a range of xsd:string. Finally, the isAbstract property is functional and has the domain of Function and the range of xsd:boolean.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component
    concept Function
    scalar property hasId [
        domain Component
        range xsd:string
        functional
    ]
    scalar property hasName [
        domain Function
        range xsd:string
    ]
    scalar property isAbstract [
        domain Function
        range xsd:boolean
        functional
    ]
}
3.2.3.2. Structured Property

A structured property is a semantic property defined in a vocabulary, whose domain is a classifier (Aspect, Concept, Relation Entity, or Structure) and whose range is a Structure. This means the values of a structured property are anonymous Structure Instances. A structured property is defined with the keywords structured property followed by a name ID. It can also optionally specialize other structured properties by following its name ID by the :> symbol then a comma-separated list of those super properties' IRIs. It also has a pair of square brackets [ ] that contain the property’s domain (referencing a classifier), range (referencing a structure), and optionally a semantic flag (functional) that specifies whether instances of the domain can have a single value maximum for this property.

Annotation*
structure property ID (:> [StructuredProperty|IRI] (, [StructuredProperty|IRI])*)? [
  domain [Classifier|IRI]
  range [Structure|IRI]
  functional?                // each instance can have a maximum of 1 value for this property
]

The following example vocabulary defines a structured property named hasLocation whose domain is concept Shape and whose range is structure Point. The latter is the domain of two scalar properties hasX and hasY that have a range of xsd:int.

vocabulary <http://com.xyz/methodology/graphics#> as graphics {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Shape
    structure Point
    structured property hasLocation [
        domain Shape
        range Point
        functional
    ]
    scalar property hasX [
        domain Point
        range xsd:int
        functional
    ]
    scalar property hasY [
        domain Point
        range xsd:int
        functional
    ]
}
3.2.3.3. Annotation Property

An annotation property is a property defined in a vocabulary, whose domain is implicitly any annotated element (ontology, import, or member) and whose range is implicitly any literal. An annotation property is defined with the keywords annotation property followed by a name ID. It can also optionally specialize other annotation properties by following its name ID by the :> symbol then a comma-separated list of those super properties' IRIs.

Annotation*
annotation property ID (:> [AnnotationProperty|IRI] (, [AnnotationProperty|IRI])*)?

An annotation property is a non-semantic property, meaning that it has no logical semantics and thus is ignored by a logical reasoner. However, it allows specifying annotations on elements like ontologies, their imports, and their members.

The following example shows two vocabularies: viewpoint and mission. The former defines an annotation property visualizeAs, and the latter defines two concept Component and Function, and annotates them using the visualizeAs annotation.

vocabulary <http://com.xyz/methodology/viewpoint#> as viewpoint {
    annotation property visualizeAs
}

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://com.xyz/methodology/viewpoint#> as viewpoint
    @viewpoint:visualizeAs "Rectangle"
    concept Component
    @viewpoint:visualizeAs "Circle"
    concept Function
}

It is common to define libraries of annotation properties for tooling purposes to enable building generic tools. The following are some of the standard annotation properties (more information about them can be found in the rdf, rdfs, owl, and dc specifications):

vocabulary <http://www.w3.org/1999/02/22-rdf-syntax-ns#> as rdf {
    annotation property about
}

vocabulary <http://www.w3.org/2000/01/rdf-schema#> as rdfs {
    annotation property comment
    annotation property isDefinedBy
    annotation property label
    annotation property seeAlso
}

vocabulary <http://www.w3.org/2002/07/owl#> as owl {
    annotation property backwardCompatibleWith
    annotation property deprecated
    annotation property incompatibleWith
    annotation property priorVersion
    annotation property versionInfo
}

vocabulary <http://purl.org/dc/elements/1.1/> as dc {
    annotation property contributor
    annotation property coverage
    annotation property creator
    annotation property date
    annotation property ^description
    annotation property format
    annotation property identifier
    annotation property ^language
    annotation property publisher
    annotation property ^relation
    annotation property rights
    annotation property ^source
    annotation property subject
    annotation property title
    annotation property type
    annotation property hasVersion
}

3.2.4. Axioms

Axioms are statements about terms in a vocabulary that enrich their logical semantics. They appear in the body of a term between its two brackets [ ]. This section describes the supported axioms, which include a key axiom (specified on entities) and a restriction axioms (specified on classifiers).

Note: that a term that has supertypes semantically inherits axioms defined on its supertypes in addition to its own axioms.

3.2.4.1. Key Axiom

A key axiom is an axiom defined on an entity (Aspect, Concept, and Relation Entity) that specifies a set of properties that together represent a unique key (id) for the entity. This means if two named instances have the same values of those properties, then they can be inferred to be aliases of the same instance. The syntax of a key axiom starts with the keyword key followed by one or more comma-separated properties specified by their IRIs.

key [Feature|IRI] (, [Feature|IRI])*

The following example vocabulary defines a key, consisting of scalar property hasId, for concept Component. This means any two differently named components with the same value for hasId will be inferred to be the same component.

vocabulary <http://www.w3.org/1999/02/22-rdf-syntax-ns#> as rdf {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component [
        key hasId
    ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
    ]
}

An entity can define zero or more keys. When multiple keys are defined, the value of each key (a tuple of values of the key properties) must be unique for an instance of the entity. In the following example, concept Component has two keys, one key consists of the hasUUID property, while the other consists of both the hasName and the hasAcroname properties. This means for each unique component, the value of hasUUID has to be unique, as well as the value of a tuple made of the values of hasName and hasAcroname together.

vocabulary <http://www.w3.org/1999/02/22-rdf-syntax-ns#> as rdf {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component [
        key hasUUID
        key hasName, hasAcroname
    ]
}
3.2.4.2. Restriction Axioms

A restriction axiom is an axiom defined on a classifier (Aspect, Concept, Relation Entity and Structure) that restricts a feature (a property or a relation) in some way in the classifier’s context. This feature can be a property (Scalar Property or Structured Property) whose domain is the context classifier or one of its supertypes, or a relation (Forward Relation or Reverse Relation) whose source is the context entity or one of its supertypes. The facets that can be restricted about those features vary (like their range, cardinality, or value) resulting in different subtypes of restriction axioms.

Range Restriction Axioms

A range restriction axiom restricts the range of a feature in the context of some classifier. The axiom specifies a restricted range that is a subtype of the feature’s original range. The syntax of a range restriction axioms starts with the keyword restricts followed by a restriction kind, which can either be all (requiring all values to conform to the restricted range) or some (requiring at least one value to conform to the restricted range). This is followed by the kind of feature (scalar property, structured property, or relation) then a reference to the feature by IRI. Finally, the keyword to is used followed by a reference to the restricted range (a scalar, a structure, or an entity) by IRI. The following shows the three supported syntaxes:

restricts [ all | some ] scalar property [ScalarProperty|IRI] to [Scalar|IRI]
restricts [ all | some ] structured property [StructuredProperty|IRI] to [Structure|IRI]
restricts [ all | some ] relation [Relation|IRI] to [Entity|IRI]

The following example shows a vocabulary that defines a concept Assembly with some range restrictions.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component
    concept Function
    concept Assembly :> Component [
        restricts all scalar property hasId to ten-chars          // the hasId value must be 10-char strings
        restricts some structured property hasPin to InputPin     // there must be at least one input pin
        restricts all relation performs to Power                  // power is the only performed function 
    ]
    concept Power :> Function
    scalar ten-chars :> xsd:string [
        length 10
    ]
    structure Pin
    structure InputPin :> Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    structured property hasPin [
        domain Component
        range Pin
        functional
   ]
}

Cardinality Restriction Axioms

A cardinality restriction axiom restricts the cardinality of a feature in the context of some classifier. The axiom specifies a minimum, a maximum, or an exact number of values, conforming to the original range, or to a specified restricted range, that a feature can have in that context. The syntax of a cardinality restriction axioms starts with the keyword restricts followed by the kind of feature (scalar property, structured property, or relation) then a reference to the feature by IRI. Then, the keyword to is used followed by a cardinality kind (min, max, or exactly), a cardinality value (positive integer), and finally an optional reference to a restricted range (a scalar, a structure, or an entity) by IRI. The following shows the three supported syntaxes:

restricts scalar property [ScalarProperty|IRI] to [ max | min | exactly ] UnsignedInteger [Scalar|IRI]?
restricts structured property [StructuredProperty|IRI] to [ max | min | exactly ] UnsignedInteger [Structure|IRI]?
restricts relation [Relation|IRI] to [ max | min | exactly ] UnsignedInteger [Entity|IRI]?

The following example shows a vocabulary that defines a concept Assembly with some cardinality restrictions.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component
    concept Function
    concept Assembly :> Component [
        restricts scalar property hasId to exactly 1              // hasId must have a single value only
        restricts structured property hasPin to max 2 InputPin    // there must be at most two input pins
        restricts relation performs to min 5                      // a minimum of 5 functions must be performed
    ]
    structure Pin
    structure InputPin :> Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    structured property hasPin [
        domain Component
        range Pin
        functional
   ]
}

Value Restriction Axioms

A value restriction axiom restricts the value of a feature in the context of some classifier. In the case of a relation, the restricted value represents the relation’s target instance. The syntax of a value restriction axioms starts with the keyword restricts followed by the kind of feature (scalar property, structured property, or relation) then a reference to the feature by IRI. Then, the keyword to is used followed by a value that is suitable for each case (a literal for a scalar property, a structure instance for a structured property, or a reference to a named instance by IRI for a relation). The following shows the three supported syntaxes:

restricts scalar property [ScalarProperty|IRI] to Literal
restricts structured property [StructuredProperty|IRI] to StructureInstance
restricts relation [Relation|IRI] to [NamedInstance|IRI]

The following example shows a vocabulary that defines a concept Assembly with some value restrictions.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    uses <http://com.xyz/methodology/functions#> as functions
    concept Component
    concept Function
    concept Assembly :> Component [
        restricts scalar property hasId to "ABC"                          // hasId must have a value of "ABC"
        restricts structured property hasPin to Pin [ hasNumber 1 ]   // hasPin must have a Pin with hasNumber of 1
        restricts relation performs to functions:F1                         // the performed function must be functions:F1
    ]
    structure Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    structured property hasPin [
        domain Component
        range Pin
        functional
   ]
    scalar property hasNumber [
        domain Pin
        range xsd:int
        functional
   ]
}

description <http://com.xyz/methodology/functions#> as functions {
    uses <http://com.xyz/methodology/mission#> as mission
    ci F1 : mission:Function
}

3.2.5. Rule

A rule is a member of a vocabulary and represents an additional inference rule in the domain that can be used by a reasoner to generate entailments. A rule has two sets of predicates (patterns that must hold); the first set is called the rule’s antecedent (predicates to match for the rule to trigger), and the second set is called the rule’s consequent (predicates that are inferred once the antecedent is matched). The syntax of a rule starts with the keyword rule followed by a name ID, then a pair of square brackets [ ] that holds the rule’s predicates. The antecedent predicates are specified first separated by the ^ symbol (which means a logical AND), followed by an implication arrow ->, then the consequent predicates separated also by the ^ symbol.

Annotation*
rule ID [
  Predicate (^ Predicate)* -> Predicate (^ Predicate)*
]

A predicate represents a pattern in the model that can be matched or inferred, depending on whether it appears in a rule’s antecedent or consequent, respectively. The set of supported predicates are the following:

The following example vocabulary shows a couple of rules, R1 and R2:

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component
    concept Function
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    relation entity Invokes [
        from Function
        to Function
        forward invokes
        reverse isInvokedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    // if a component performs a function that invokes another function, then the component invokes the latter too
   rule R1 [
        Component ( c ) ^ performs ( c, f1 ) ^ invokes ( f1, f2 ) -> performs ( c, f2 )
   ]
    // if a component has a different id from another component, then they must be different components
   rule R2 [
        hasId ( c1, i1 ) ^ hasId ( c2, i2 ) ^ differentFrom ( i1, i2 ) -> differentFrom ( c1, c2 )
   ]
}

3.3. Description

A description is an ontology that uses vocabularies to describe named instances in a given domain. A description is declared with the keywords description as its ontology kind, followed by its NAMESPACE, the keyword as, and its prefix ID. It also has a body consisting of zero or more description imports and statements between two braces { }, as follows:

Annotation*
description NAMESPACE as ID {
  DescriptionImport*
  DescriptionStatement*
}

The following example description is meant to describe the components of a system. It has the namespace http://com.xyz/system/components# and the prefix components.

description <http://com.xyz/system/components#> as components {
}

3.3.1. Imports

This section outlines the kind of import statements that can be added in a description’s body.

3.3.1.1. Usage

A description usage is a kind of import statement that can be added to a description to specify a vocabulary that it uses. This is typically needed in order to use the terms (types and properties) of the vocabulary in the description’s instance definitions. A description usage is defined with the keyword uses followed by the used vocabulary’s NAMESPACE, followed by the keyword as and a unique prefix ID.

Annotation*
uses [Vocabulary|NAMESPACE] as ID

In the following example description, the mission vocabulary is used to describe components of a system.

description <http://com.xyz/system/components#> as components {
    uses <http://com.xyz/methodology/mission#> as mission

    ci System1 : mission:Component     // a cross-reference to concept Component
}
3.3.1.2. Extension

A description extension is a kind of import statement that can be added to a description to specify that it extends another description. This can be used to split a system description into fragments that focus on different concerns or are contributed by different authorities. In this case, a description may extend other descriptions that it depends on. A description extension is defined with the keyword extends followed by the extended description’s NAMESPACE, followed by the keyword as and a unique prefix ID.

Annotation*
extends [Description|NAMESPACE] as ID

The following example description subsystem1 extends two other descriptions, subsystem1 and subsystem2, and defines component System1 that aggregates components Subsystem1 and Subsystem2 defined in these descriptions, respectively.

description <http://com.xyz/system/system1#> as system1 {
    uses <http://com.xyz/methodology/mission#> as mission
    extends <http://com.xyz/methodology/system1/subsystem1#> as subsystem1
    extends <http://com.xyz/methodology/system1/subsystem2#> as subsystem2

    ci System1 : mission:Component [
        mission:aggregates subsystem1:Subsystem1    // a cross-reference Subsystem subsystem1
        mission:aggregates subsystem2:Subsystem2    // a cross-reference Subsystem subsystem2
    ]
}

3.3.2. Instances

Instances represent objects or data in a given system. They are described using terms (types and properties) from some vocabulary. Specifically, they can be given types and have assertions on features in the domain of those types. Instances can either be named (Concept Instance and Relation Instance), in which case they are specified as members of some description, or they can be anonymous (Structure Instance), in which case they defined as values of features (e.g., structured properties) in the context of other (named or anonymous) instances.

3.3.2.1. Concept Instance

A concept instance is a named instance defined as a member of a description and can be typed by concepts (from some imported vocabulary). The concept instance is declared with the keyword ci and a name ID. It can optionally be followed by a : and the IRIs of one or more concepts that are considered types of the instance. It can also optionally be followed by a pair of square brackets [ ] that holds assertions about the instance.

Annotation*
ci ID (: [Concept|IRI] (, [Concept|IRI])*)? ([
      Assertion*
  ])?

The following example description defines two concept instances: one named component1 and typed by concept mission:Component, while the other is named function1 and typed by concept mission:Function.

description <http://com.xyz/system/components#> as components {
    uses <http://com.xyz/methodology/mission#> as mission
    ci component1 : mission:Component
    ci function1 : mission:Function
}
3.3.2.2. Relation Instance

A relation instance is a named instance defined as a member of a description and can be typed by relation entities (from some imported vocabulary). The relation instance is declared with the keyword ri and a name ID. It can optionally be followed by a : and the IRIs of one or more relation entities that are considered types of the instance. It is also followed by a pair of square brackets [ ] that allows specifying the sources and targets of the relation instance and holds assertions about the instance. The sources of the relation instance are specified with the keyword from followed by one or more IRIs of named instances. Similarly, the targets of the relation instance are specified with the keyword to followed by one or more IRIs of named instances.

Annotation*
ri ID (: [RelationEntity|IRI] (, [RelationEntity|IRI])*)? [
  from [NamedInstance|IRI] (, [NamedInstance|IRI])* 
  to [NamedInstance|IRI] (, [NamedInstance|IRI])*
  Assertion*
]

The following example description defines three concept instances: component1 typed by concept mission:Component, and function1 and function2 typed by concept mission:Function. It also defines a relation instance performs1 typed by the mission:Performs relation entity that has component1 as a source, and both function1 and function2 as targets.

description <http://com.xyz/system/components#> as components {
    uses <http://com.xyz/methodology/mission#> as mission
    ci component1 : mission:Component
    ci function1 : mission:Function
    ci function2 : mission:Function
    ri perform1 : mission:Performs [
        from component1
        to function1, function2
    ]
}
3.3.2.3. Structure Instance

A structure instance is an anonymous instance that can be defined as a value of a structured property. Such value can either be specified in a structured property value assertion, defined in the context of some instance, or in a value restriction axiom on some structured property in the context of some classifier. A structure instance is declared with the IRI of a structure followed by a pair of square brackets [ ] that holds assertions about the instance.

[Structure|IRI] [
  Assertion*
]

The following example shows .

vocabulary <http://com.xyz/system/components#> as components {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    uses <http://com.xyz/methodology/functions#> as functions
    concept Component [
        restricts structured property hasPin to Pin [ hasNumber 1 ]   // structure instance used as restricted value
    ]
    structure Pin
    structured property hasPin [
        domain Component
        range Pin
        functional
   ]
    scalar property hasNumber [
        domain Pin
        range xsd:int
        functional
   ]
}

description <http://com.xyz/methodology/functions#> as functions {
    uses <http://com.xyz/methodology/mission#> as mission
    ci C1 : mission:Component [
        mission:hasPin Pin [ mission:hasNumber 2 ]                    // structure instance used in value assertion
    ]
}

3.3.3. Assertions

Assertions are statements about instances that enable characterizing them. They appear in the body of an instance (either named or anonymous) between its two brackets [ ]. This section describes the supported assertions, which include a scalar property value assertion (specified on instances), structured property value assertion (specified on instances), and a link assertion (specified on named instances).

3.3.3.1. Scalar Property Value Assertion

A value for a scalar property can be asserted on an instance (Concept Instance, Relation Instance, or Structure Instance). Such assertion can be added as one of the assertions between the square brackets [ ] of the instance. Its syntax consists of an IRI to a scalar property from some vocabulary followed by a literal.

[ScalarProperty|IRI] Literal

The following example description defines two concept instances that each makes a number of scalar property assertions. Specifically, instance component1 asserts that its mission:hasId property has a string value of C1, while instance function1 asserts that its mission:hasName property has a string value of F1 and its mission:isAbstract property has a Boolean value of true.

description <http://com.xyz/system/components#> as components {
    uses <http://com.xyz/methodology/mission#> as mission
    ci component1 : mission:Component [
        mission:hasId 'C1'        // property value assertion
    ]
    ci function1 : mission:Function [
        mission:hasName 'F1'      // property value assertion
        mission:isAbstract true   // property value assertion
    ]
}
3.3.3.2. Structured Property Value Assertion

A value for a structured property can be asserted on an instance (Concept Instance, Relation Instance, or Structure Instance). Such assertion can be added as one of the assertions between the square brackets [ ] of the instance. Its syntax consists of an IRI to a structured property from some vocabulary followed by a structure instance.

[StructuredProperty|IRI] StuctureInstance

The following example description defines a concept instance C1 which asserts a value for structured property mission:hasPin to have a structure instance whose mission:hasNumber property value is asserted to be 2.

description <http://com.xyz/methodology/functions#> as functions {
    uses <http://com.xyz/methodology/mission#> as mission
    ci C1 : mission:Component [
        mission:hasPin Pin [ mission:hasNumber 2 ]       // structure instance used in value assertion
    ]
}
3.3.3.3. Link Assertion

A named instance can be asserted as a target of a link typed by an unreified relation (Forward Relation or Reverse Relation) on a named instance representing the link’s source. A link is a light-weight alternative to a relation instance in the sense that it relates two named instances but does not define a new instance for the relation itself. Therefore, unlike a relation instance, a link cannot be characterized by assertions. Also, unlike a relation instance, which can relate one or more sources or one or more targets, a link can only relate a single source to a single target. A link assertion can be added between the square brackets [ ] of a named instance (the source). Its syntax consists of an IRI to a relation followed by an IRI of a named instance (the target).

[Relation|IRI] [NamedInstance|IRI]

The following example description defines two concept instances with a link asserted between them. Specifically, instance component1 asserts a link of type mission:performs (the forward relation of relation entity mission:Performs) to instance function1.

description <http://com.xyz/system/components#> as components {
    uses <http://com.xyz/methodology/mission#> as mission
    ci component1 : mission:Component [
        mission:hasId 'C1'
        mission:performs function1    // link assertion
    ]
    ci function1 : mission:Function [
        mission:hasName 'F1'
        mission:isAbstract true
    ]
}

3.4. Vocabulary Bundle

A vocabulary bundle is an ontology that bundles a set of vocabularies and allows description logic (DL) reasoning with closed-world semantics using them (in contrast to a vocabulary that has open-world semantics). A vocabulary bundle is declared with the keywords vocabulary bundle as its ontology kind, followed by its NAMESPACE, the keyword as, and its prefix ID. It also has a body consisting of zero or more vocabulary bundle imports between two braces { }, as follows:

Annotation*
vocabulary bundle NAMESPACE as ID {
}

For example, the following vocabulary bundle has the namespace http://com.xyz/methodology/foundation# and the prefix foundation.

vocabulary bundle <http://com.xyz/methodology/foundation#> as foundation {
  VocabularyBundleImport*
}

3.4.1. Imports

This section outlines the kind of import statements that can be added in a vocabulary bundle’s body.

3.4.1.1. Inclusion

An vocabulary bundle inclusion is a kind of import statement that can be added to a vocabulary bundle to specify that it includes a vocabulary. A vocabulary bundle inclusion is defined with the keyword includes followed by the included vocabulary’s NAMESPACE.

Annotation*
includes [Vocabulary|NAMESPACE]

For example, the foundation vocabulary bundle includes two vocabularies: mission and project.

vocabulary bundle <http://com.xyz/methodology/foundation#> as foundation {
    includes <http://com.xyz/methodology/mission#> as mission
    includes <http://com.xyz/methodology/project#> as project
}
3.4.1.2. Extends

An vocabulary bundle extends is a kind of import statement that can be added to a vocabulary bundle to specify that it extends another vocabulary bundle. This can be used to organize vocabulary bundles in layers that build on each other. Each bundle inherits the vocabularies contributed by its extended bundles and may optionally add to them other included vocabularies. This can, for example, be used to define a family of related vocabulary bundles that build on each other by tackling different incremental concerns. A vocabulary bundle extension is defined with the keyword extends followed by the extended vocabulary bundle’s NAMESPACE.

Annotation*
extends [VocabularyBundle|NAMESPACE]

For example, the cyber-physical vocabulary bundle extends the foundation vocabulary bundle (which includes the mission vocabulary) to include two other vocabularies: electrical and mechanical, which are two disciplines used when describing cyber-physical systems.

vocabulary bundle <http://com.xyz/methodology/cyber-physical#> as cyber-physical {
    extends <http://com.xyz/methodology/foundation#>
    includes <http://com.xyz/methodology/electrical#>
    includes <http://com.xyz/methodology/mechanical#>
}

3.5. Description Bundle

A description bundle is an ontology that bundles a set of descriptions and allows them to be reasoned on as a dataset using description logic (DL). A description bundle is declared with the keywords description bundle as its ontology kind, followed by its NAMESPACE, the keyword as, and its prefix ID. It also has a body consisting of zero or more description bundle imports between two braces { }, as follows:

Annotation*
description bundle NAMESPACE as ID {
  DescriptionBundleImport*
}

For example, the following description bundle has the namespace http://com.xyz/missions/mission1# and the prefix mission1.

description bundle <http://com.xyz/missions/mission1#> as mission1 {
}

3.5.1. Imports

This section outlines the kind of import statements that can be added in a description bundle’s body.

3.5.1.1. Inclusion

A description bundle inclusion is a kind of import statement that can be added to a description bundle to specify that it includes a description. A description bundle inclusion is defined with the keyword includes followed by the imported description’s NAMESPACE.

Annotation*
includes [Description|NAMESPACE]

For example, the mission1 description bundle includes two descriptions: components and masses.

description bundle <http://com.xyz/missions/mission1#> as mission1 {
    includes <http://com.xyz/system/components#>
    includes <http://com.xyz/system/masses#>
}
3.5.1.2. Usage

A description bundle usage is a kind of import statement that can be added to a description bundle to specify that it uses either a vocabulary bundle or a vocabulary. A description bundle should use at least one vocabulary bundle (to import its world-closure statements). In this case, the usage is defined with the keyword uses followed by the imported vocabulary bundle’s NAMESPACE. The same syntax is used when a description bundle uses a vocabulary, except that the vocabulary’s NAMESPACE can optionally be followed by the as keyword and a unique prefix ID, when a member of the used vocabulary (typically an annotation property) is cross-referenced.

Annotation*
uses ( ([VocabularyBundle|NAMESPACE]) | ([Vocabulary|NAMESPACE] (as ID)?) )

For example, the mission1 description bundle uses the dc vocabulary and the foundation vocabulary bundle.

@dc:title "Mission1 Bundle"
description bundle <http://com.xyz/missions/mission1#> as mission1 {
    uses <http://purl.org/dc/elements/1.1/> as dc // vocabulary
    uses <http://com.xyz/methodology/foundation#> // vocabulary bundle
    includes <http://com.xyz/system/components#> as components
    includes <http://com.xyz/system/masses#> as masses
}
3.5.1.3. Extension

An description bundle extension is a kind of import statement that can be added to a description bundle to specify that it extends another description bundle. This can be used to organize description bundles into layers that build on each other. Each bundle inherits the descriptions contributed by its extended bundles and optionally adds to them other descriptions. This can, for example, be used to define alternative datasets (e.g., representing alternative system designs) that extend a common dataset. A description bundle extension is defined with the keyword extends followed by the extended description bundle’s NAMESPACE.

Annotation*
extends [DescriptionBundle|NAMESPACE]

For example, the design1 description bundle extends the mission1 description bundle and includes two additional descriptions: electrical1 and mechanical1, which specify the details of this design variant.

description bundle <http://com.xyz/missions/mission1/design1#> as design1 {
    extends <http://com.xyz/missions/mission1#>
    includes <http://com.xyz/missions/mission1/electrical1#>
    includes <http://com.xyz/missions/mission1/mechanical#>
}

4. Textual BNF

Ontology:
  VocabularyBox |
  DescriptionBox

VocabularyBox:
  Vocabulary |
  VocabularyBundle

Vocabulary:
  Annotation*
  vocabulary NAMESPACE as ID  {
    VocabularyImport*
    VocabularyStatement*
  }

VocabularyBundle:
  Annotation*
  vocabulary bundle NAMESPACE as ID {
    VocabularyBundleImport*
  }

DescriptionBox:
  Description |
  DescriptionBundle

Description:
  Annotation*
  description NAMESPACE as ID {
    DescriptionImport*
    DescriptionStatement*
  }

DescriptionBundle:
  Annotation*
  description bundle NAMESPACE as ID {
    DescriptionBundleImport*
  }

Import:
  VocabularyImport |
  DescriptionImport

VocabularyImport:
  VocabularyExtension |
  VocabularyUsage

VocabularyExtension:
  Annotation*
  extends NAMESPACE (as ID)?
    	
VocabularyUsage:
  Annotation*
  uses NAMESPACE (as ID)?
    	
VocabularyBundleImport:
  VocabularyBundleExtension |
  VocabularyBundleInclusion

VocabularyBundleInclusion:
  Annotation*
  includes NAMESPACE (as ID)?

VocabularyBundleExtension:
  Annotation*
  extends NAMESPACE (as ID)?

DescriptionImport:
  DescriptionExtension |
  DescriptionUsage

DescriptionUsage:
  Annotation*
  uses NAMESPACE (as ID)?

DescriptionExtension:
  Annotation*
  extends NAMESPACE (as ID)?

DescriptionBundleImport:
  DescriptionBundleExtension |
  DescriptionBundleInclusion |
  DescriptionBundleUsage

DescriptionBundleInclusion:
  Annotation*
  includes NAMESPACE (as ID)?

DescriptionBundleExtension:
  Annotation*
  extends NAMESPACE (as ID)?

DescriptionBundleUsage:
  Annotation*
  uses NAMESPACE (as ID)?

Member:
  SpecializableTerm |
  Property |
  Relation |
  Rule |
  NamedInstance |

Term:
  SpecializableTerm |
  Feature

VocabularyStatement:
  SpecializableTerm |
  SpecializableTermReference |
  Rule |
  RuleReference |
  RelationReference

SpecializableTerm:
  Type |
  AnnotationProperty |
  ScalarProperty |
  StructuredProperty
	
Type:
  Classifier |
  Scalar  

Classifier:
  Entity |
  Structure
	
Entity:
  Aspect |
  Concept |
  RelationEntity

Aspect:
  Annotation*
  aspect ID (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    (KeyAxiom | PropertyRestrictionAxiom | RelationRestrictionAxiom)*
  ])?

Concept:
  Annotation*
  concept ID (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    (KeyAxiom | PropertyRestrictionAxiom | RelationRestrictionAxiom)*
    (enumerates ConceptInstance (, ConceptInstance)*)?
  ])?
	
RelationEntity:
  Annotation*
  relation entity ID (:> SpecializationAxiom (, SpecializationAxiom)*)? [
    from [Entity|IRI]
    to [Entity|IRI]
    ForwardRelation?
    ReverseRelation?
    functional?
    (inverse functional)?
    symmetric?
    asymmetric?
    reflexive?
    irreflexive?
    transitive?
    (KeyAxiom | PropertyRestrictionAxiom | RelationRestrictionAxiom)*
  ]

Feature:
  Relation |
  Property

Relation:
  ForwardRelation |
  ReverseRelation

ForwardRelation:
  Annotation*
  forward ID

ReverseRelation:
  Annotation*
  reverse ID

Structure:
  Annotation*
  structure ID (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    PropertyRestrictionAxiom*
  ])?

Scalar:
  FacetedScalar |
  EnumeratedScalar

FacetedScalar:
  Annotation*
  scalar ID (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
     (length UnsignedInteger)?
     (minLength UnsignedInteger)?
     (maxLength UnsignedInteger)?
     (pattern STRING)?
     (language ID)?
     (minInclusive Literal)?
     (minExclusive Literal)?
     (maxInclusive Literal)?
     (maxExclusive Literal)?
  ])?

EnumeratedScalar:
  Annotation*
  enumerated scalar ID (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    (Literal (, Literal)*)?
  ])?

Property:
  AnnotationProperty |
  SemanticProperty

AnnotationProperty:
  Annotation*
  annotation property ID (:> SpecializationAxiom (, SpecializationAxiom)*)?

SemanticProperty:
  ScalarProperty |
  StructuredProperty

ScalarProperty:
  Annotation*
  scalar property ID (:> SpecializationAxiom (, SpecializationAxiom)*)? [
    domain [Classifier|IRI]
    range [Scalar|IRI]
    functional?
  ]

StructuredProperty:
  Annotation*
  structured property ID (:> SpecializationAxiom (, SpecializationAxiom)*)? [
    domain [Classifier|IRI]
    range [Structure|IRI]
    functional?
  ]

Rule:
  Annotation*
  rule ID [
    Predicate (^ Predicate)* -> Predicate (^ Predicate)*
  ]

Predicate:
  UnaryPredicate |
  BinaryPredicate

UnaryPredicate:
  TypePredicate
	
TypePredicate:
  [Type|IRI] ( ID )
	
BinaryPredicate:
  RelationEntityPredicate |
    FeaturePredicate |
    SameAsPredicate |
    DifferentFromPredicate

RelationEntityPredicate:
  [RelationEntity|IRI] ( ID , ID , (ID | [NamedInstance|IRI]) )

FeaturePredicate:
  [Feature|IRI] ( ID , (ID | Literal | [NamedInstance|IRI]) )

SameAsPredicate:
  sameAs ( ID , (ID | [NamedInstance|IRI] )

DifferentFromPredicate:
  differentFrom ( ID , (ID | [NamedInstance|IRI] )

DescriptionStatement:
  NamedInstance |
  NamedInstanceReference
	
NamedInstance:
  ConceptInstance |
  RelationInstance

ConceptInstance:
  Annotation*
  ci ID (: ConceptTypeAssertion (, ConceptTypeAssertion)*)? ([
    (PropertyValueAssertion | LinkAssertion)*
  ])?
	
RelationInstance:
  Annotation*
  ri ID (: RelationTypeAssertion (, RelationTypeAssertion)*)? [
    from [NamedInstance|IRI] (, [NamedInstance|IRI])* 
    to [NamedInstance|IRI] (, [NamedInstance|IRI])*
    (PropertyValueAssertion | LinkAssertion)*
  ]

StructureInstance:
  [Structure|IRI] [
    PropertyValueAssertion*
  ]

Reference:
  SpecializableTermReference |
  RelationReference |
  RuleReference |
  NamedInstanceReference


SpecializableTermReference:
  ClassifierReference |
  FacetedScalarReference |
  EnumeratedScalarReference |
  AnnotationPropertyReference |
  ScalarPropertyReference |
  StructuredPropertyReference

ClassifierReference:
  EntityReference |
  StructureReference

EntityReference:
  AspectReference |
  ConceptReference |
  RelationEntityReference
	
AspectReference:
  Annotation*
  ref aspect [Aspect|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    (KeyAxiom* | PropertyRestrictionAxiom | RelationRestrictionAxiom)*
  ])?

ConceptReference:
  Annotation*
  ref concept [Concept|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    (KeyAxiom | PropertyRestrictionAxiom | RelationRestrictionAxiom)*
  ])?

RelationEntityReference:
  Annotation*
  ref relation entity [RelationEntity|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    (KeyAxiom | PropertyRestrictionAxiom | RelationRestrictionAxiom)*
  ])?

StructureReference:
  Annotation*
  ref structure [Structure|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)? ([
    PropertyRestrictionAxiom*
  ])?

AnnotationPropertyReference:
  Annotation*
  ref annotation property [AnnotationProperty|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)?

ScalarPropertyReference:
  Annotation*
  ref scalar property [ScalarProperty|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)?

StructuredPropertyReference:
  Annotation*
  ref structured property [StructuredProperty|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)?

FacetedScalarReference:
  Annotation*
  ref scalar [FacetedScalar|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)?

EnumeratedScalarReference:
  Annotation*
  ref enumerated scalar [EnumeratedScalar|IRI] (:> SpecializationAxiom (, SpecializationAxiom)*)?

RelationReference:
  Annotation*
  ref relation [Relation|IRI]
	
RuleReference:
  Annotation*
  ref rule [Rule|IRI]

NamedInstanceReference:
  ConceptInstanceReference |
  RelationInstanceReference

ConceptInstanceReference:
  Annotation*
  ref ci [ConceptInstance|IRI] (: ConceptTypeAssertion (, ConceptTypeAssertion)*)? ([
    PropertyValueAssertion*
    LinkAssertion*
  ])?

RelationInstanceReference:
  Annotation*
  ref ri [RelationInstance|IRI] (: RelationTypeAssertion (, RelationTypeAssertion)*)? ([
    PropertyValueAssertion*
    LinkAssertion*
  ])?

SpecializationAxiom:
  [SpecializableTerm|IRI]
	
RestrictionAxiom:
  PropertyRestrictionAxiom |
  RelationRestrictionAxiom

PropertyRestrictionAxiom:
  ScalarPropertyRestrictionAxiom |
  StructuredPropertyRestrictionAxiom

ScalarPropertyRestrictionAxiom:
  ScalarPropertyRangeRestrictionAxiom |
  ScalarPropertyCardinalityRestrictionAxiom |
  ScalarPropertyValueRestrictionAxiom

ScalarPropertyRangeRestrictionAxiom:
  restricts RangeRestrictionKind scalar property [ScalarProperty|IRI] to [Scalar|IRI]

ScalarPropertyCardinalityRestrictionAxiom:
  restricts scalar property [ScalarProperty|IRI] to CardinalityRestrictionKind UnsignedInteger ([Scalar|IRI])?

ScalarPropertyValueRestrictionAxiom:
  restricts scalar property [ScalarProperty|IRI] to Literal

StructuredPropertyRestrictionAxiom:
  StructuredPropertyRangeRestrictionAxiom |
  StructuredPropertyCardinalityRestrictionAxiom |
  StructuredPropertyValueRestrictionAxiom

StructuredPropertyRangeRestrictionAxiom:
  restricts RangeRestrictionKind structured property [StructuredProperty|IRI] to [Structure|IRI]

StructuredPropertyCardinalityRestrictionAxiom:
  restricts structured property [StructuredProperty|IRI] to CardinalityRestrictionKind UnsignedInteger [Structure|IRI]?

StructuredPropertyValueRestrictionAxiom:
  restricts structured property [StructuredProperty|IRI] to StructureInstance

RelationRestrictionAxiom:
  RelationRangeRestrictionAxiom |
  RelationCardinalityRestrictionAxiom |
  RelationTargetRestrictionAxiom
	
RelationRangeRestrictionAxiom:
  restricts RangeRestrictionKind relation [Relation|IRI] to [Entity|IRI]

RelationCardinalityRestrictionAxiom:
  restricts relation [Relation|IRI] to CardinalityRestrictionKind UnsignedInteger [Entity|IRI]?

RelationTargetRestrictionAxiom:
  restricts relation [Relation|IRI] to [NamedInstance|IRI]

KeyAxiom:
  key [Feature|IRI] (, [Feature|IRI])*

ConceptTypeAssertion:
  [Concept|IRI]

RelationTypeAssertion:
  [RelationEntity|IRI]

PropertyValueAssertion:
  ScalarPropertyValueAssertion |
  StructuredPropertyValueAssertion

ScalarPropertyValueAssertion:
  [ScalarProperty|IRI] Literal

StructuredPropertyValueAssertion:
  [StructuredProperty|IRI] StructureInstance

LinkAssertion:
  [Relation|IRI] [NamedInstance|IRI]

Annotation:
  @ [AnnotationProperty|IRI] (Literal | [Member|IRI])?

Literal:
  IntegerLiteral |
  DecimalLiteral |
  DoubleLiteral |
  BooleanLiteral |
  QuotedLiteral

IntegerLiteral:
  Integer

DecimalLiteral:
  Decimal

DoubleLiteral:
  Double

BooleanLiteral:
  Boolean

QuotedLiteral:
  STRING ((^^ [Scalar|IRI]) | ($ ID))?

RangeRestrictionKind: 
  all | some

CardinalityRestrictionKind: 
  exactly | min | max

Boolean: 
  BOOLEAN_STR

UnsignedInteger: 
  UNSIGNED_INTEGER_STR

Integer: 
  UNSIGNED_INTEGER_STR | 
  INTEGER_STR

Decimal: 
  DECIMAL_STR

Double: 
  DOUBLE_STR

BOOLEAN_STR: 
  false | true

UNSIGNED_INTEGER_STR: 
  DIGIT+

INTEGER_STR: 
  (+|-)? DIGIT+

DECIMAL_STR: 
  (+|-)? (DIGIT+(.DIGIT*)? | (.DIGIT+))

DOUBLE_STR: 
  (+|-)? (DIGIT+(.DIGIT*)? | (.DIGIT+)) ((e|E) (+|-)? DIGIT+)?

STRING: 
  (" -> ") | (' -> ') | (''' -> ''') | (""" -> """)

NAMESPACE: 
  < (!(>|\s|#))* (#|/) >

IRI: 
  FULL_IRI | ABBREVIATED_IRI | ID

FULL_IRI: 
  < (!(>|\s|#))* >

ABBREVIATED_IRI: 
  ID : ID

ID: 
  ^? (ALPHA|DIGIT|_) (ALPHA|DIGIT|_|-|.|$)*

ALPHA: 
  a..z | A..Z

DIGIT: 
  0..9

5. Graphical BNF

Convensions

BNF symbols are colored in orange and will not show up in actual rendering of OML diagrams. Elements with a hyperlink can be clicked on to navigate to a detailed description of their abstract syntax. Shares are laid freely on diagrams. List compartments (within shapes) are always laid out in a vertical stack.

Concept:

        

Aspect:

        

Structure:

        

FacetedScalar:

        

EnumeratedScalar:

        

Rule:

6. Abstract-Syntax

This Ecore package specifies the syntax (metamodel) of the Ontological Modeling Language. OML models are instances of this metamodel and can be manipulated using its API.

6.1. Elements

AnnotatedElement Element Annotation property : AnnotationProperty [1] referenceValue : Member [0..1] owningElement : AnnotatedElement [0..1] owningReference : Reference [0..1] Literal IdentifiedElement Import namespace : Namespace prefix : ID Member name : ID Ontology namespace : Namespace prefix : ID SeparatorKind hash slash Statement ownedAnnotations * value 0..1

6.1.1. AnnotatedElement

AnnotatedElement is an element that can own a set of Annotations.
Super classes
Sub classes
Properties
  • ownedAnnotations : Annotation [*]

    The set of annotations owned directly by this element

6.1.2. Annotation

Annotation is an element that specifies additional non-semantic information on an annotated element. It can also be specified on a reference to an ontology member, in which case it is interpreted as if it was specified on the member itself. An annotation is specified with an annotation property and an optional literal or reference value. When no value is specified, it is interpreted as a boolean true literal.
Super classes
Properties
  • property : AnnotationProperty [1]

    The annotation property specified by this annotation

  • value : Literal [0..1]

    The literal value specified by this annotation.

  • referenceValue : Member [0..1]

    The reference value (to a member) specified by this annotation

  • owningElement : AnnotatedElement [0..1]

    The annotated element that owns this annotation

  • owningReference : Reference [0..1]

    The reference that owns this annotation

6.1.3. Element

Element is the most general type in the OML metamodel. All objects in an OML model are elements.
Sub classes

6.1.4. IdentifiedElement

IdentifiedElement is an annotated element that is identified by an IRI.
Super classes
Sub classes

6.1.5. Import

Import is an annotated element owned by an ontology to specify that it imports another ontology. The imported ontology is specified by its IRI, and optionally a separator character and local prefix if members of the imported ontology will also be referenced by the importing ontology
Super classes
Sub classes
Properties
  • namespace : Namespace [1]

    The namespace of the imported ontology

  • prefix : ID [0..1]

    The local prefix of the imported ontology’s namespace

6.1.6. Member

Member is an identified element defined by an ontology. Its IRI is unique and derived by concatenating the globally unique namespace of its ontology with its locally unique name (i.e., member.iri=ontology.namespace+member.name).
Super classes
Sub classes
Properties
  • name : ID [1]

    The name of this member, which is unique within its ontology’s namespace

6.1.7. Ontology

Ontology is an identified element that represents a namespace for its members. The namespace is defined by a globally unique namespace (an iri and a namespace separator that can be # or /) and can be abbreviated with a prefix. An ontology can import other ontologies, and can make statements about its own as well as imported members.
Super classes
Sub classes
Properties
  • namespace : Namespace [1]

    The globally unique namespace of this ontology

  • prefix : ID [1]

    The prefix of this ontology’s namespace

6.1.8. SeparatorKind

SeparatorKind is an enumeration that specifies the separator character of an ontology’s namespace. It can either be only of two values: a hash '#' or a slash '/'.
Literals
  • hash
  • slash

6.1.9. Statement

Statement represents an expression of information in an ontology.
Super classes
Sub classes

6.2. Literals

BooleanLiteral value : Boolean Literal DecimalLiteral value : Decimal DoubleLiteral value : Double IntegerLiteral value : Integer Element QuotedLiteral value : String langTag : String type : Scalar [0..1]

6.2.1. BooleanLiteral

BooleanLiteral is a literal that represents the boolean values true/false
Super classes
Properties
  • value : Boolean [0..1]

    The boolean value of this literal

6.2.2. DecimalLiteral

DecimalLiteral is a literal that represents an arbitrary precision decimal value
Super classes
Properties
  • value : Decimal [1]

    The decimal value of this literal

6.2.3. DoubleLiteral

DoubleLiteral is a literal that represents a 64-bit double precision floating point value
Super classes
Properties
  • value : Double [0..1]

6.2.4. IntegerLiteral

IntegerLiteral is a literal that represents a 32-bit integer value
Super classes
Properties
  • value : Integer [0..1]

    The int value of this literal

6.2.5. Literal

Literal is an element that represents a specific literal value classified by a scalar.
Super classes
Sub classes

6.2.6. QuotedLiteral

QuotedLiteral is a literal that specifies its lexical value as a quoted string along with a language tag, a scalar type, or neither.
Super classes
Properties
  • value : String [1]

    The value of this literal represented as a string

  • langTag : String [0..1]

    The langTag of this literal

  • type : Scalar [0..1]

    The scalar that is the type of this literal

6.3. Vocabularies

SpecializableTerm SpecializationAxiom Term VocabularyStatement owningVocabulary : Vocabulary [1] Member Vocabulary VocabularyBox VocabularyImport owningVocabulary : Vocabulary [1] Ontology VocabularyBundle VocabularyBundleImport owningVocabularyBundle : VocabularyBundle [1] VocabularyBundleExtension Import VocabularyBundleInclusion VocabularyExtension Statement VocabularyUsage ownedSpecializations * ownedImports * ownedStatements * ownedImports *

6.3.1. SpecializableTerm

SpecializableTerm is a term that can specialized in a taxonomy. It can have zero or more specializations.
Super classes
Sub classes
Properties

6.3.2. Term

Term is a member of a vocabulary that provides a particular semantic meaning when used in an assertion.
Super classes
Sub classes

6.3.3. Vocabulary

Vocabulary is a vocabulary box that allows making statements about its own terms and rules or about others that are imported.
Super classes
Properties
  • ownedImports : VocabularyImport [*]

    The set of imports this vocabulary has to other ontologies

  • ownedStatements : VocabularyStatement [*]

    The set of statements contained by this vocabulary

6.3.4. VocabularyBox

VocabularyBox is an ontology whose members are terms and rules.
Super classes
Sub classes

6.3.5. VocabularyBundle

VocabularyBundle is a vocabulary box that allows importing other vocabulary boxes and flagging them as disjoint from one another.
Super classes
Properties
  • ownedImports : VocabularyBundleImport [*]

    The set of imports this vocabulary bundle has of other vocabularies

6.3.6. VocabularyBundleExtension

VocabularyBundleExtension is an import that allows a vocabulary bundle to extend another vocabulary bundle.
Super classes

6.3.7. VocabularyBundleImport

VocabularyBundleImport is an import owned by a vocabulary bundle.
Super classes
Sub classes
Properties
  • owningVocabularyBundle : VocabularyBundle [1]

    The vocabulary bundle that contains this import

6.3.8. VocabularyBundleInclusion

VocabularyBundleInclusion is an import that allows a vocabulary bundle to include a vocabulary.
Super classes

6.3.9. VocabularyExtension

VocabularyExtension is an import that allows a vocabulary to extend another vocabulary.
Super classes

6.3.10. VocabularyImport

VocabularyImport is an import owned by a vocabulary.
Super classes
Sub classes
Properties
  • owningVocabulary : Vocabulary [1]

    The vocabulary that owns this import

6.3.11. VocabularyStatement

VocabularyStatement is a statement owned by a vocabulary.
Super classes
Sub classes
Properties
  • owningVocabulary : Vocabulary [1]

    The vocabulary that owns this statement

6.3.12. VocabularyUsage

VocabularyUsage is an import that allows a vocabulary to use a description box.
Super classes

6.4. Types

Aspect Entity Classifier PropertyRestrictionAxiom Type Concept enumeratedInstances : ConceptInstance [*] RelationRestrictionAxiom KeyAxiom EnumeratedScalar Literal Scalar FacetedScalar length : UnsignedInteger minLength : UnsignedInteger maxLength : UnsignedInteger pattern : String language : String RelationEntity functional : Boolean inverseFunctional : Boolean symmetric : Boolean asymmetric : Boolean reflexive : Boolean irreflexive : Boolean transitive : Boolean source : Entity [1] target : Entity [1] ForwardRelation ReverseRelation Structure SpecializableTerm ownedPropertyRestrictions * ownedRelationRestrictions * ownedKeys * literals * minInclusive 0..1 minExclusive 0..1 maxInclusive 0..1 maxExclusive 0..1 forwardRelation 0..1 reverseRelation 0..1

6.4.1. Aspect

Aspect is an entity that represents a concern that cuts across multiple entities. It does not directly classify instances, but it does so indirectly by being specialized by other entities. However, an aspect can only specialize other aspects.
Super classes

6.4.2. Classifier

Classifier is a type that classifies a set of instances and characterizes them with properties (i.e., becomes a domain of these properties). It also inherits properties in the domain of its specialized types. In addition, it can specify constraints on (direct or inherited) properties in its domain.
Super classes
Sub classes
Properties
  • ownedPropertyRestrictions : PropertyRestrictionAxiom [*]

    The set of restriction axioms on properties of this classifier

6.4.3. Concept

Concept is a concrete entity that classifies a (possibly enumerated) set of concept instances. It can also specialize other concepts and/or aspects.
Super classes
Properties
  • enumeratedInstances : ConceptInstance [*]

    The set of enumerated instances of this concept

6.4.4. Entity

Entity is a characterizable type whose instances can be interrelated by relations (that have the entity or one of its specialized entities as their domain). It can also specify constraints on relations in its domain.
Super classes
Sub classes
Properties
  • ownedRelationRestrictions : RelationRestrictionAxiom [*]

    The set of restriction axioms on relations in this entity’s domain

  • ownedKeys : KeyAxiom [*]

    The unique keys of this entity

6.4.5. EnumeratedScalar

EnumeratedScalar is a scalar that represents a finite set of literals. It can specialize another enumerated scalar, but in this case, it cannot define its own literals; rather, it will simply be considered an alias to the specialized scalar.
Super classes
Properties
  • literals : Literal [*]

    The set of enumerated literals that are represented by this scalar

6.4.6. FacetedScalar

FacetedScalar is a scalar that represents a (possibly infinite) set of literals and can constrain them with some facets. It can also specialize other faceted scalars. OML considers some faceted scalars, those defined by the OWL2 specification (https://www.w3.org/TR/owl2-syntax/#Datatype_Maps) and listed below, as standard. Other non-standard scalars can specialize directly or transitively from this standard set and optionally specify facets (restrictions on their lexical or value spaces). A scalar that specifies facets can only have a single supertype, which must be a standard one. Otherwise, it must have at least one supertype that is considered to be an alias.

Numeric scalars (facets: minInclusive, maxInclusive, minExclusive, maxExclusive): owl:real owl:rational xsd:decimal xsd:integer xsd:nonNegativeInteger xsd:nonPositiveInteger xsd:positiveInteger xsd:negativeInteger xsd:long xsd:int xsd:short xsd:byte xsd:unsignedLong xsd:unsignedInt xsd:unsignedShort xsd:unsignedByte xsd:double xsd:float

Time scalars (facets: minInclusive, maxInclusive, minExclusive, maxExclusive): xsd:dateTime xsd:dateTimeStamp

Plain scalars (facets: length, minLength, maxLength, pattern, language): rdf:PlainLiteral String scalars (facets: length, minLength, maxLength, pattern) xsd:string, xsd:normalizedString, xsd:token, xsd:language, xsd:Name, xsd:NCName, xsd:NMTOKEN xsd:anyURI

Boolean scalars (no facets): xsd:boolean

Binary scalars (facets: length, minLength, maxLength): xsd:hexBinary xsd:base64Binary

XML scalars (no facets): rdf:XMLLiteral

Super classes
Properties
  • length : UnsignedInteger [0..1]

    The exact length of the literals of this scalar

  • minLength : UnsignedInteger [0..1]

    The minimum length of the literals of this scalar

  • maxLength : UnsignedInteger [0..1]

    The maximum length of the literals of this scalar

  • pattern : String [0..1]

    The pattern that the literals of this scalar conforms to

  • language : String [0..1]

    The language range that the literals of this scalar belong to (based on http://www.rfc-editor.org/rfc/bcp/bcp47.txt)

  • minInclusive : Literal [0..1]

    The minimum inclusive value of numeric literals of this scalar

  • minExclusive : Literal [0..1]

    The minimum exclusive value of numeric literals of this scalar

  • maxInclusive : Literal [0..1]

    The maximum inclusive value of numeric literals of this scalar

  • maxExclusive : Literal [0..1]

    The maximum exclusive value of numeric literals of this scalar

6.4.7. RelationEntity

RelationEntity is a concrete entity that can classify a set of relation instances in a description. It can also specialize other relation entities and/or aspects. A relation entity relates two entities, a source and a target by a forward relation (from the source to the target). The forward relation can optionally be named, otherwise the default name '[relationEnity]Forward' is assumed. An optional reverse relation (from the target to the source) can also be named.A relation entity can also be characterized with several boolean flags, representing DL semantics, that apply to the forward relation, and conversely to the reverse relation (if any).
Super classes
Properties
  • source : Entity [1]

    The entity that represents the source of this relation entity

  • target : Entity [1]

    The entity that represents the target of this relation entity

  • forwardRelation : ForwardRelation [0..1]

    The optional forward relation of this relation entity

  • reverseRelation : ReverseRelation [0..1]

    The optional reverse relation of this relation entity

  • functional : Boolean [0..1]

    Whether this relation entity is functional (i.e., {@code A -> B and A->C => B=C})

  • inverseFunctional : Boolean [0..1]

    Whether this relation entity is inverse functional (i.e., {@code B->A and C->A => B=C})

  • symmetric : Boolean [0..1]

    Whether this relation entity is symmetric (i.e., {@code A->B => B->A})

  • asymmetric : Boolean [0..1]

    Whether this relation entity is asymmetric (i.e., {@code A->B => !(B->A)})

  • reflexive : Boolean [0..1]

    Whether this relation entity is reflexive (i.e., {@code A => A->A})

  • irreflexive : Boolean [0..1]

    Whether this relation entity is irreflexive (i.e., {@code A => !(A->A)})

  • transitive : Boolean [0..1]

    Whether this relation entity is irreflexive (i.e., {@code A->B and B->C => A->C})

6.4.8. Scalar

Scalar is a primitive type that represents a set of literals. It is the super type of all scalar types.
Super classes
Sub classes

6.4.9. Structure

Structure is a characterizable type that represents a structured datatype whose instances are anonymous and assignable as values to structured properties.
Super classes

6.4.10. Type

Type is a specializable term that classifies a set of instances or literals.
Super classes
Sub classes

6.5. Features

AnnotationProperty SpecializableTerm Property Feature Term ForwardRelation relationEntity : RelationEntity [1] Relation domain : Entity [1] range : Entity [1] inverse : Relation [0..1] ReverseRelation relationEntity : RelationEntity [1] ScalarProperty functional : Boolean domain : Classifier [1] range : Scalar [1] SemanticProperty StructuredProperty functional : Boolean domain : Classifier [1] range : Structure [1]

6.5.1. AnnotationProperty

AnnotationProperty is a property with no DL semantics that relates an annotated element to a literal value.
Super classes

6.5.2. Feature

Feature is a a term that can be restricted in a given classifier context
Super classes
Sub classes

6.5.3. ForwardRelation

ForwardRelation is a relation that is defined along side a relation entity, whose domain is the source of the relation entity, and whose range is the target of the relation entity. A forward relation has DL semantics that are specified by the boolean flags of its relation entity.
Super classes
Properties
  • relationEntity : RelationEntity [1]

    The relation entity that owns this relation as forward

6.5.4. Property

Property is a specializable feature that relates an element to a value. It is the super type of all property types.
Super classes
Sub classes

6.5.5. Relation

Relation is a feature that represents a relation from its domain entity to its range entity. It is the super type of two concrete relations: ForwardRelation and [=ReverseRelation] that are specified by a relation entity. When a relation entity specifies both kinds of relations, they become inverse of each other.
Super classes
Sub classes
Properties
  • domain : Entity [1]

    The entity that represents the domain of this relation

  • range : Entity [1]

    The entity that represents the range of this relation

  • inverse : Relation [0..1]

    The relation (if any) that is the inverse of this relation

6.5.6. ReverseRelation

ReverseRelation is a relation that is defined along side a relation entity, whose domain is the target of the relation entity, and whose range is the source of the relation entity. A reverse relation has DL semantics that are the inverse of its entity’s forward relation.
Super classes
Properties
  • relationEntity : RelationEntity [1]

    The relation entity that owns this reverse relation

6.5.7. ScalarProperty

ScalarProperty is a semantic property whose range is a scalar. It can specialize other scalar properties. It can also be flagged as a key property (among possibly several) that specifies the unique id of its domain.
Super classes
Properties
  • functional : Boolean [0..1]

    Whether this property is functional (has a max of one value per instance)

  • domain : Classifier [1]

    The classifier that is the domain of this property

  • range : Scalar [1]

    The scalar that is the range of this property

6.5.8. SemanticProperty

SemanticProperty is a property with DL semantics that relates instances of a classifier acting as its domain to a value typed by either a scalar or a structure representing its range.
Super classes
Sub classes

6.5.9. StructuredProperty

StructuredProperty is a semantic property whose range is a structure. It can specialize other structured properties.
Super classes
Properties
  • functional : Boolean [0..1]

    Whether this property is functional (has a max of one value per instance)

  • domain : Classifier [1]

    The classifier that is the domain of this property

  • range : Structure [1]

    The structure that is the range of this property

6.6. Rules

BinaryPredicate variable1 : ID variable2 : ID instance2 : NamedInstance [0..1] Predicate antecedentRule : Rule [0..1] consequentRule : Rule [0..1] DifferentFromPredicate FeaturePredicate feature : Feature [1] Literal Element RelationEntityPredicate entityVariable : ID entity : RelationEntity [1] Rule Member VocabularyStatement SameAsPredicate TypePredicate type : Type [1] UnaryPredicate variable : ID literal2 0..1 antecedent * consequent *

6.6.1. BinaryPredicate

BinaryPredicate is a predicate that takes two arguments: the first is a variable1 to match to some instance, and the second is either a variable2 to match to some instance or a specific instance2.
Super classes
Sub classes
Properties
  • variable1 : ID [1]

    The variable1 specified by the predicate

  • variable2 : ID [0..1]

    The optional variable2 specified by the predicate

  • instance2 : NamedInstance [0..1]

    The optional instance2 specified by the predicate

6.6.2. DifferentFromPredicate

DifferentFromPredicate is a binary predicate that checks that its two arguments bind to different instances
Super classes

6.6.3. FeaturePredicate

FeaturePredicate is a binary predicate that binds its variable1 to an instance (subject), and either its variable2, instance2, or literal2 as the value (object) of a specific feature (predicate).
Super classes
Properties
  • feature : Feature [1]

    The feature of the named instance whose value is bound or matched

  • literal2 : Literal [0..1]

    The optional literal2 that is matched as a value of the feature

6.6.4. Predicate

Predicate is an element that represents an ontology statement to match, when used in a rule’s antecedent, or to infer, when used in a rule’s consequent.
Super classes
Sub classes
Properties
  • antecedentRule : Rule [0..1]

    The rule that specifies this predicate in its antecedent

  • consequentRule : Rule [0..1]

    The rule that specifies this predicate in its consequent

6.6.5. RelationEntityPredicate

RelationEntityPredicate is a binary predicate that binds its entityVariable to a relation instance, its variable1 to the source of that relation instance, and either its variable2 or instance2 as the target of that relation instance.
Super classes
Properties
  • entity : RelationEntity [1]

    The type of the relation instance

  • entityVariable : ID [1]

    The entity variable specified by the predicate

6.6.6. Rule

Rule is a member of a vocabulary that adds a new inference rule to the set supported natively by DL. A rule specifies a set of antecedent predicates that forms a conjunction that infers, when it holds, a single consequent (relation) predicate. Each predicate in a rule may specify (one or two) variables. Those with the same name refer to the same variable, and hence must be bound to the same value from the model for the rule to trigger during reasoning.
Super classes
Properties
  • antecedent : Predicate [*]

    The set of predicates that form the antecedent of this rule

  • consequent : Predicate [*]

    The relation predicate that is the consequent of this rule

6.6.7. SameAsPredicate

SameAsPredicate is a binary predicate that checks that its two arguments bind to the same instance
Super classes

6.6.8. TypePredicate

TypePredicate is a unary predicate that binds its variable to an instance with a specific type.
Super classes
Properties
  • type : Type [1]

    The type of the instance

6.6.9. UnaryPredicate

UnaryPredicate is a predicate that binds one variable
Super classes
Sub classes
Properties
  • variable : ID [1]

    The variable name specified by the predicate

6.7. Axioms

Axiom Element CardinalityRestrictionKind exactly min max KeyAxiom properties : Feature [*] owningEntity : Entity [0..1] owningReference : EntityReference [0..1] PropertyRestrictionAxiom owningClassifier : Classifier [0..1] owningReference : ClassifierReference [0..1] RestrictionAxiom RangeRestrictionKind all some RelationCardinalityRestrictionAxiom cardinality : UnsignedInt kind : CardinalityRestrictionKind range : Entity [0..1] RelationRestrictionAxiom relation : Relation [1] owningEntity : Entity [0..1] owningReference : EntityReference [0..1] RelationRangeRestrictionAxiom kind : RangeRestrictionKind range : Entity [1] RelationTargetRestrictionAxiom target : NamedInstance [1] ScalarPropertyCardinalityRestrictionAxiom cardinality : UnsignedInt kind : CardinalityRestrictionKind range : Scalar [0..1] ScalarPropertyRestrictionAxiom property : ScalarProperty [1] ScalarPropertyRangeRestrictionAxiom kind : RangeRestrictionKind range : Scalar [1] ScalarPropertyValueRestrictionAxiom Literal SpecializationAxiom specializedTerm : SpecializableTerm [1] owningTerm : SpecializableTerm [0..1] owningReference : SpecializableTermReference [0..1] StructuredPropertyCardinalityRestrictionAxiom cardinality : UnsignedInt kind : CardinalityRestrictionKind range : Structure [0..1] StructuredPropertyRestrictionAxiom property : StructuredProperty [1] StructuredPropertyRangeRestrictionAxiom kind : RangeRestrictionKind range : Structure [1] StructuredPropertyValueRestrictionAxiom StructureInstance value 1 value 1

6.7.1. Axiom

Axiom is an annotated element that represents a statement about a term in a vocabulary.
Super classes
Sub classes

6.7.2. CardinalityRestrictionKind

CardinalityRestrictionKind is an enumeration that specifies the kind of cardinality restriction on a property or relation
Literals
  • exactly

    The cardinality must match this

  • max

    The cardinality is at most this

  • min

    The cardinality is at least this

6.7.3. KeyAxiom

KeyAxiom is an axiom that states that a set of features form a unique key for an entity. This means that all instances of that entity must have unique values for those keys.
Super classes
Properties
  • properties : Feature [*]

    The set of features specified by this axiom as a key

  • owningEntity : Entity [0..1]

    The entity that owns this axiom

  • owningReference : EntityReference [0..1]

    The reference to an entity that owns this axiom

6.7.4. PropertyRestrictionAxiom

PropertyRestrictionAxiom is an axiom that places some restriction on the value of a property in the context of the restricting classifier domain. It can be specified directly on the classifier or indirectly on a reference to it.
Super classes
Sub classes
Properties
  • owningClassifier : Classifier [0..1]

    The restricting classifier specified by this axiom

  • owningReference : ClassifierReference [0..1]

    The reference to a restricting classifier specified by this axiom

6.7.5. RangeRestrictionKind

RangeRestrictionKind is an enumeration that specifies the scope of a range restriction on a property or a relation
Literals
  • all

    All values are restricted to the range

  • some

    Some values are restricted to the range

6.7.6. RelationCardinalityRestrictionAxiom

RelationCardinalityRestrictionAxiom is a relation restriction axiom that restricts the cardinality of a relation’s range to an exact number, a minimum number or a maximum number. This restrictions may either apply generally to all targets of of the relation that have instances of the restricting entity as sources, or to those classified by a specific range subtype.
Super classes
Properties
  • cardinality : UnsignedInt [1]

    The value of the cardinality specified by this axiom (default is 1)

  • kind : CardinalityRestrictionKind [1]

    The kind of cardinality restriction specified by this axiom (default is exactly)

  • range : Entity [0..1]

    The restricted range specified by this axiom

6.7.7. RelationRangeRestrictionAxiom

RelationRangeRestrictionAxiom is a relation restriction axiom that restricts the range of a relation to specific subtype. This restrictions may apply to all or to some instances of the relation that have an instance of the restricting entity as a source.
Super classes
Properties
  • range : Entity [1]

    The restricted range specified by this axiom

  • kind : RangeRestrictionKind [1]

    The range restriction kind specified by this axiom (default is all)

6.7.8. RelationRestrictionAxiom

RelationRestrictionAxiom is an axiom that places some restriction on the target of a relation in the context of the restricting classifier domain. It can be specified directly on the classifier or indirectly on a reference to it.
Super classes
Sub classes
Properties
  • relation : Relation [1]

    The restricted relation specified by this axiom

  • owningEntity : Entity [0..1]

    The restricting entity specified by this axiom

  • owningReference : EntityReference [0..1]

    The reference to a restricting entity specified by this axiom

6.7.9. RelationTargetRestrictionAxiom

RelationTargetRestrictionAxiom is a relation restriction axiom that restricts the target of the relation to a specific named instance.
Super classes
Properties
  • target : NamedInstance [1]

    The named instance specified as a restricted relation target by this axiom

6.7.10. RestrictionAxiom

RestrictionAxiom is an axiom that states that a term restricts another term.
Super classes
Sub classes

6.7.11. ScalarPropertyCardinalityRestrictionAxiom

ScalarPropertyCardinalityRestrictionAxiom is a scalar property restriction axiom that restricts the cardinality of a scalar property to an exact number, a minimum number or a maximum number. This restrictions can apply to all values of the property that have the restricting classifier as a domain, or to those values classified by a specific range subtype.
Super classes
Properties
  • cardinality : UnsignedInt [1]

    The value of the cardinality specified by this axiom (default is 1)

  • kind : CardinalityRestrictionKind [1]

    The kind of cardinality restriction specified by this axiom (default is exactly)

  • range : Scalar [0..1]

    The restricted range specified by this axiom

6.7.12. ScalarPropertyRangeRestrictionAxiom

ScalarPropertyRangeRestrictionAxiom is a scalar property restriction axiom that restricts the range of a property to a scalar that specializes the original range. This restrictions may apply to all or to some values of the property that have the restricting classifier as a domain.
Super classes
Properties
  • range : Scalar [1]

    The restricted range specified by this axiom

  • kind : RangeRestrictionKind [1]

    The range restriction kind specified by this axiom (default is all)

6.7.13. ScalarPropertyRestrictionAxiom

ScalarPropertyRestrictionAxiom is a property restriction axiom that is specified on a scalar property.
Super classes
Sub classes
Properties
  • property : ScalarProperty [1]

    The restricted scalar property specified by this axiom

6.7.14. ScalarPropertyValueRestrictionAxiom

ScalarPropertyValueRestrictionAxiom is a scalar property restriction axiom that restricts the value of the property that has the restricting classifier as a domain to a specific literal.
Super classes
Properties
  • value : Literal [1]

    The literal specified as a restricted property value by this axiom

6.7.15. SpecializationAxiom

SpecializationAxiom is an axiom that states that one specializable term specializes another. It can be specified directly on a specializing term or indirectly on a reference to one.
Super classes
Properties

6.7.16. StructuredPropertyCardinalityRestrictionAxiom

StructuredPropertyCardinalityRestrictionAxiom is a structured property restriction axiom that restricts the cardinality of a structured property to an exact number, a minimum number or a maximum number. This restrictions can apply to all values of the property that have the restricting classifier as a domain, or to those values classified by a specific range subtype.
Super classes
Properties
  • cardinality : UnsignedInt [1]

    The value of the cardinality specified by this axiom (default is 1)

  • kind : CardinalityRestrictionKind [1]

    The kind of cardinality restriction specified by this axiom (default is exactly)

  • range : Structure [0..1]

    The restricted range specified by this axiom

6.7.17. StructuredPropertyRangeRestrictionAxiom

StructuredPropertyRangeRestrictionAxiom is a structured property restriction axiom that restricts the range of a property to a structure that specializes the original range. This restrictions may apply to all or to some values of the property that have the restricting classifier as a domain.
Super classes
Properties
  • range : Structure [1]

    The restricted range specified by this axiom

  • kind : RangeRestrictionKind [1]

    The range restriction kind specified by this axiom (default is all)

6.7.18. StructuredPropertyRestrictionAxiom

StructuredPropertyRestrictionAxiom is a property restriction axiom that is specified on a structured property.
Super classes
Sub classes
Properties
  • property : StructuredProperty [1]

    The restricted structured property specified by this axiom

6.7.19. StructuredPropertyValueRestrictionAxiom

StructuredPropertyValueRestrictionAxiom is a structured property restriction axiom that restricts the value of the property that has the restricting classifier as a domain to a specific structure instance.
Super classes
Properties
  • value : StructureInstance [1]

    The structure instance specified as a restricted property value by this axiom

6.8. Descriptions

Description DescriptionBox DescriptionImport owningDescription : Description [1] DescriptionStatement owningDescription : Description [1] Ontology DescriptionBundle DescriptionBundleImport owningDescriptionBundle : DescriptionBundle [1] DescriptionBundleExtension Import DescriptionBundleInclusion DescriptionBundleUsage DescriptionExtension Statement DescriptionUsage ownedImports * ownedStatements * ownedImports *

6.8.1. Description

Description is a description box that allows making statements about its own instances or about others that are imported.
Super classes
Properties
  • ownedImports : DescriptionImport [*]

    The set of imports this description has to other ontologies

  • ownedStatements : DescriptionStatement [*]

    The set of statements contained by this description

6.8.2. DescriptionBox

DescriptionBox is an ontology whose members are instances (of terms defined in vocabulary boxes)
Super classes
Sub classes

6.8.3. DescriptionBundle

DescriptionBundle is a description box that allows importing other description boxes and flagging them as a set that is analyzed together for consistency and satisfiabilty.
Super classes
Properties

6.8.4. DescriptionBundleExtension

DescriptionBundleExtension is an import that allows a description bundle to extend another description bundle.
Super classes

6.8.5. DescriptionBundleImport

DescriptionBundleImport is an import owned by description bundle.
Super classes
Sub classes
Properties
  • owningDescriptionBundle : DescriptionBundle [1]

    The description bundle that owns this import

6.8.6. DescriptionBundleInclusion

DescriptionBundleInclusion is an import that allows a description bundle to include a description.
Super classes

6.8.7. DescriptionBundleUsage

DescriptionBundleUsage is an import that allows a description bundle to use a vocabulary box.
Super classes

6.8.8. DescriptionExtension

DescriptionExtension is an import that allows a description to extend another description.
Super classes

6.8.9. DescriptionImport

DescriptionImport is an import owned by a description.
Super classes
Sub classes
Properties
  • owningDescription : Description [1]

    The description that owns this import

6.8.10. DescriptionStatement

DescriptionStatement is a statement owned by a description.
Super classes
Sub classes
Properties
  • owningDescription : Description [1]

    The description that owns this statement

6.8.11. DescriptionUsage

DescriptionUsage is an import that allows a description to use a vocabulary box.
Super classes

6.9. Instances

ConceptInstance ConceptTypeAssertion NamedInstance Instance Element PropertyValueAssertion Member DescriptionStatement LinkAssertion RelationInstance sources : NamedInstance [*] targets : NamedInstance [*] RelationTypeAssertion StructureInstance type : Structure [1] owningAxiom : StructuredPropertyValueRestrictionAxiom [0..1] owningAssertion : StructuredPropertyValueAssertion [0..1] ownedTypes * ownedPropertyValues * ownedLinks * ownedTypes *

6.9.1. ConceptInstance

ConceptInstance is a named instance that can be typed by concepts.
Super classes
Properties

6.9.2. Instance

Instance is an element that represents an instance of a classifier. It can specify a set of values for the classifier’s (direct or inherited) properties.
Super classes
Sub classes
Properties

6.9.3. NamedInstance

NamedInstance is an instance that is a member of a description. It can specify links to other named instances.
Super classes
Sub classes
Properties
  • ownedLinks : LinkAssertion [*]

    The links specified by this named instance to other named instances

6.9.4. RelationInstance

RelationInstance is a named instance that can be typed by relation entities and that goes from one or more named instances as sources to one or more named instances as target.
Super classes
Properties
  • ownedTypes : RelationTypeAssertion [*]

    The types of this instance

  • sources : NamedInstance [*]

    The named instances that are the sources of this relation instance

  • targets : NamedInstance [*]

    The named instances that are the targets of this relation instance

6.9.5. StructureInstance

StructureInstance is an instance that can be typed by a structure. It is anonymous and gets assigned as a value for structured properties, either as part of value restrictions on entities, or value assertions on instances.
Super classes
Properties

6.10. Assertions

Assertion Element ConceptTypeAssertion type : Concept [1] owningInstance : ConceptInstance [0..1] owningReference : ConceptInstanceReference [0..1] TypeAssertion LinkAssertion relation : Relation [1] target : NamedInstance [1] owningInstance : NamedInstance [0..1] owningReference : NamedInstanceReference [0..1] PropertyValueAssertion owningInstance : Instance [0..1] owningReference : NamedInstanceReference [0..1] RelationTypeAssertion type : RelationEntity [1] owningInstance : RelationInstance [0..1] owningReference : RelationInstanceReference [0..1] ScalarPropertyValueAssertion property : ScalarProperty [1] Literal StructuredPropertyValueAssertion property : StructuredProperty [1] StructureInstance value 1 value 1

6.10.1. Assertion

Assertion is an element that represents a statement about an instance in a description.
Super classes
Sub classes

6.10.2. ConceptTypeAssertion

ConceptTypeAssertion is a type assertion specifying a type for a concept instance. It can be specified directly on an concept instance, or indirectly on a reference to one.
Super classes
Properties
  • type : Concept [1]

    The concept specified as the type of the instance

  • owningInstance : ConceptInstance [0..1]

    The instance that this type assertion is about

  • owningReference : ConceptInstanceReference [0..1]

    The reference to a concept instance that this type assertion is about

6.10.3. LinkAssertion

LinkAssertion is an assertion that specifies a link from the asserting named instance as a source to another named instance as a target. Unlike a relation instance, which is typed by a relation entity, a link references a relation that has the type of the source instance as a conforming domain and the type of the target instance as a conforming range.
Super classes
Properties
  • relation : Relation [1]

    The relation referenced by this link

  • target : NamedInstance [1]

    The named instance that is target of this link

  • owningInstance : NamedInstance [0..1]

    The named instance that is the source of this link

  • owningReference : NamedInstanceReference [0..1]

    The reference to a named instance that this the source of this link

6.10.4. PropertyValueAssertion

PropertyValueAssertion is an assertion that specifies a value for a property on an instance.
Super classes
Sub classes
Properties
  • owningInstance : Instance [0..1]

    The instance that this property value assertion is about

  • owningReference : NamedInstanceReference [0..1]

    The reference to an instance that this property value assertion is about

6.10.5. RelationTypeAssertion

RelationTypeAssertion is a type assertion specifying a relation entity as a type of a relation instance. It can be specified directly on a relation instance, or indirectly on a reference to one.
Super classes
Properties
  • type : RelationEntity [1]

    The relation entity that is the type of the relation instance

  • owningInstance : RelationInstance [0..1]

    The relation instance that this type assertion is about

  • owningReference : RelationInstanceReference [0..1]

    The reference to a relation instance that this type assertion is about

6.10.6. ScalarPropertyValueAssertion

ScalarPropertyValueAssertion is a property value assertion for a scalar property, where the specified value is a literal.
Super classes
Properties
  • property : ScalarProperty [1]

    The scalar property specified by this assertion

  • value : Literal [1]

    The literal specified by this assertion as a value

6.10.7. StructuredPropertyValueAssertion

StructuredPropertyValueAssertion is a property value assertion for a structured property, where the specified value is a structure instance.
Super classes
Properties
  • property : StructuredProperty [1]

    The structured property specified by this assertion

  • value : StructureInstance [1]

    The structure instance specified by this assertion as a value

6.10.8. TypeAssertion

TypeAssertion is an assertion that specifies a type for an instance
Super classes
Sub classes

6.11. References

AnnotationPropertyReference property : AnnotationProperty [1] SpecializableTermReference AspectReference aspect : Aspect [1] EntityReference ClassifierReference PropertyRestrictionAxiom ConceptInstanceReference instance : ConceptInstance [1] ConceptTypeAssertion NamedInstanceReference ConceptReference concept : Concept [1] RelationRestrictionAxiom KeyAxiom EnumeratedScalarReference scalar : EnumeratedScalar [1] FacetedScalarReference scalar : FacetedScalar [1] DescriptionStatement PropertyValueAssertion LinkAssertion Reference Element Annotation RelationEntityReference entity : RelationEntity [1] RelationInstanceReference instance : RelationInstance [1] RelationTypeAssertion RelationReference relation : Relation [1] VocabularyStatement RuleReference rule : Rule [1] ScalarPropertyReference property : ScalarProperty [1] SpecializationAxiom StructureReference structure : Structure [1] StructuredPropertyReference property : StructuredProperty [1] ownedPropertyRestrictions * ownedTypes * ownedRelationRestrictions * ownedKeys * ownedPropertyValues * ownedLinks * ownedAnnotations * ownedTypes * ownedSpecializations *

6.11.1. AnnotationPropertyReference

AnnotationPropertyReference is a reference to an annotation property.
Super classes
Properties

6.11.2. AspectReference

AspectReference is a reference to an aspect.
Super classes
Properties
  • aspect : Aspect [1]

    The aspect referenced by this reference

6.11.3. ClassifierReference

ClassifierReference is a reference to a classifier that can be used to add other property restrictions to it.
Super classes
Sub classes
Properties
  • ownedPropertyRestrictions : PropertyRestrictionAxiom [*]

    The set of property restriction axioms added to the referenced classifier by this reference

6.11.4. ConceptInstanceReference

ConceptInstanceReference is a reference to a concept instance that can be used to add other types to it
Super classes
Properties

6.11.5. ConceptReference

ConceptReference is a reference to a concept.
Super classes
Properties
  • concept : Concept [1]

    The concept referenced by this reference

6.11.6. EntityReference

EntityReference is a reference to an entity that can be used to add other relation restrictions to it.
Super classes
Sub classes
Properties
  • ownedRelationRestrictions : RelationRestrictionAxiom [*]

    The set of relation restriction axioms added to the referenced entity by this reference

  • ownedKeys : KeyAxiom [*]

    The keys of the referenced entity specified by this reference

6.11.7. EnumeratedScalarReference

EnumeratedScalarReference is a reference to an enumerated scalar.
Super classes
Properties
  • scalar : EnumeratedScalar [1]

    The enumerated scalar referenced by this reference

6.11.8. FacetedScalarReference

FacetedScalarReference is a reference to a faceted scalar.
Super classes
Properties
  • scalar : FacetedScalar [1]

    The faceted scalar referenced by this reference

6.11.9. NamedInstanceReference

NamedInstanceReference is a reference to an named instance that can be used to add other property value and links to it.
Super classes
Sub classes
Properties
  • ownedPropertyValues : PropertyValueAssertion [*]

    The property value assertions added to referenced named instance by this reference

  • ownedLinks : LinkAssertion [*]

    The link assertions added to the referenced named instance by this reference

6.11.10. Reference

Reference is an element that references a member of an ontology, in order to add other annotations to it.
Super classes
Sub classes
Properties
  • ownedAnnotations : Annotation [*]

    A set of annotations added to the referenced member by this reference

6.11.11. RelationEntityReference

RelationEntityReference is a reference to a relation entity.
Super classes
Properties
  • entity : RelationEntity [1]

    The relation entity referenced by this reference

6.11.12. RelationInstanceReference

RelationInstanceReference is a reference to a relation instance that can be used to add other types to it.
Super classes
Properties

6.11.13. RelationReference

RelationReference is a reference to an relation.
Super classes
Properties
  • relation : Relation [1]

    The relation referenced by this reference

6.11.14. RuleReference

RuleReference is a reference to a rule.
Super classes
Properties
  • rule : Rule [1]

    The rule referenced by this reference

6.11.15. ScalarPropertyReference

ScalarPropertyReference is a reference to an scalar property.
Super classes
Properties
  • property : ScalarProperty [1]

    The scalar property referenced by this reference

6.11.16. SpecializableTermReference

SpecializableTermReference is a reference to a specializable term that can be used to add other specializations to it.
Super classes
Sub classes
Properties
  • ownedSpecializations : SpecializationAxiom [*]

    The set of specialization axioms added to the referenced term by this reference

6.11.17. StructureReference

StructureReference is a reference to a structure.
Super classes
Properties
  • structure : Structure [1]

    The structure referenced by this reference

6.11.18. StructuredPropertyReference

StructuredPropertyReference is a reference to an structured property.
Super classes
Properties

7. Public API

Click this link to browse the OML Java API in a separate page.

8. Mapping to OWL2 and SWRL

8.1. Description Logic Semantics

Description Logic (DL) is a class of logic that is sufficiently expressive (between propositional and first-order logic) and decidable (in finite time). Since OML is mappable to OWL2-DL, which is a subset of OWL2 that has DL semantics, OML models can be reasoned on with DL reasoners. Sevral over-the-shelf DL reasoner implementations exist such as Pellet. There are two kinds of DL reasoning that can be performed on OML models: satisfiability analysis and consistency analysis.

Satisfiability analysis can be run on a vocabuly bundle to check that the types defined by that bundle are instantiable, i.e., valid instances can be created for each of them. The concern checked here is whether any type is over constrained (e.g. specializes two disjoint types) such that valid instances of the type cannot be created.

Consistency analysis can be run on a description bundle to check that the instances defined by that bundle are consistent with the rules of the used vocabularies. The concern checked here is whether any instance is involved in a logical contradition (e.g., two unequal instances assert different values to a functional property).

The reasoning process relies heavily on the inference semantics of the OML elements. These semantics are described by mapping OML elements to corresponding OWL2-DL elements, which have DL semantics described in the OWL2 standard. The DL semantics allow generating inferred statements (called entailments) from asserted statements (defined in OML models). Such inference process is run repeatedly until all possible entailments are generated or until a contradiction is detected. In the latter case, a proof of the contradiction (a minimum set of statements exemplifying the contradiction) is emitted for the user to inspect.

The openCAESAR project provides tools that enables running DL reasoning on OML models. The first tool, called OWL Adapter, maps OML models to correspond OWL2-DL models. The second tool, called OWL Reason, runs a DL reasoner on the resulting OWL2-DL models and generates a reasoning report that report on reasoning problems if any.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119