Ontological Modeling Language v2

1. Document Organization

This document describes the syntax, notation, semantics, and API of the Ontological Modeling Language (OML). The section named Getting Started walks the reader through and demonstrates the use cases of working with OML.

The section Language Reference describes how to use OML to create a DSL for a given domain and what it means in terms of what system modelers in that domain would be able to model.
The section Textual BNF describes the BNF grammar of OML. This can help readers understand textual OML models and create them using an OML text editor.
The section Grahical BNF describes the graphical BNF grammar of OML. This can help readers understand standard OML diagrams.
The section Abstract Syntax describes the concepts that make up the OML syntax, along with their attibutes and relations. Hyperlinks are provided to help the reader navigate the concepts.
The section Public API describes the OML public API that can be used to create tools that read or write OML models. Some of the public API maps directly from the corresponding OML abstract syntax. Other API adds useful functions that make working with OML easier programmatically.
The section Mapping to OWL2 and SWRL 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.

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:

expression : the expression is required
expression ? : the expression is optional
expression * : the expression repeats zero or more times
expression + : the expression repeats one or more times
( expression ) : the expression is delineated

Moreover, BNF grammar rules can compose other rules. In the following example, Rule1 is composed of Rule2.

<Rule1>: Rule2
<Rule2>: ...

Rules may also cross reference other rules. In the following example, Rule1 cross references Rule2 using its IRI token.

<Rule1>: [Rule2|IRI]
<Rule2>: IRI ...
<Rule3>: IRI ...
<IRI>: ...

This allows more precision than saying <Rule1>: IRI, which could ambiguously refer to the IRI of Rule2 or Rule3.

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.omljson
|
├── 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.xml 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 mapped 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:

OML Tools: a set of tools that work on the OML format
OWL Tools: a set of tools that work on the OWL format
OWL Adapter: a set of tools that convert between OML and OWL formats

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.

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.

<ontology> NAMESPACE as ID {
    <import>*
    <statement>*
}

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:

Vocabulary: allows definition of ontological terms and rules for a domain with open-world semantics
Vocabulary Bundle: allows combining vocabularies into a DSL with closed-world semantics
Description: allows definition of systems as instances characterized using some vocabulary
Description Bundle: allows combining descriptions into a dataset that can be reasoned on.

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 a (preix) ID.

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

Note: An (prefix) 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 imports for each one of its ontology kinds:

Vocabulary: extends Vocabulary, uses Description
Vocabulary Bundle: extends VocabularyBundle, includes Vocabulary
Description: extends Description, uses Vocabulary
Description Bundle: extends DescriptionBundle, includes Description, uses Vocabulary, uses VocabularyBundle

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 are defined by their own ontology and referenced by 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:

Vocabulary:
Description:
- Concept Instance
- Relation Instance

3.1.6. Reference

An ontology can reference local or imported members in order to add extra statements on them. Unlike a new member that is defined syntactically with a <member> keyword and an ID, a reference is defined syntatically with the keyword ref followed by a <member> keyword then the existing member’s IRI, as follows:

<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 most cases, those statements are the same kinds that can be added to a member definition. In few cases, they are only a subset of them. Sections on the specific member kinds will outline the statements that cannot be added to a reference.

3.1.7. IRI

Ontologies and their members have globally unique IRIs. 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
}

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 one or more values for an annotation property (defined by a vocabulary) in the context of an identified element (an ontology or a member,. The general syntax of an annotation consists of a @ symbol followed by an IRI to the an annotation property then zero or more comma-separated (literal or member reference) values. If no value is specified, it is interpreted as a boolean true literal value.

@[AnnotationProperty|IRI] (Literal (, Literal)*)?
@[AnnotationProperty|IRI] ([Member|IRI] (, [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 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 has an annotation with viewpoint:show (notice that there is no literal value, which will be interpreted as a Boolean true literal).

@dc:title "Example1 Ontology"
@dc:date "2/15/2021"^^xsd:dateTime
<ontology> <http://company.com/example1#> as example1 {
    <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, "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 {
  Import*
  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. Import

This section outlines the kind of imports (extension and usage) that can be added to a vocabulary.

3.2.1.1. Extension

An 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 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 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 entities (structured types) or scalars (primitive types). Entities (Aspect, Concept and Relation Entity) classify instances (named or anonymous). Scalars (Scalar) classify literals.

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 is declared with the keyword aspect followed by an ID. An existing (local or imported) aspect can be referenced by the keywords ref aspect followed by its IRI. Moreover, an spect can specify between a pair of [ ] brackets a set of KeyAxioms. It can also be followed by an optional EntitySpecializationAxiom, and an optional EntityEquivalenceAxiom, using the following syntax:

  Annotation*
(aspect ID | ref aspect [Aspect|Ref]) ([
  (KeyAxiom)* 
])? (EntitySpecializationAxiom)? (EntityEquivalenceAxiom)?

The following example vocabulary defines an aspect: IdentifiedElement, and references an imported aspect base:Container to add some axioms to it.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends  <http://com.xyz/methodology/base#> as base
    aspect IdentifiedElement
    ref aspect base:Container [ .. ]
}

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 is declared with the keyword concept followed by an ID. An existing (local or imported) concept can be referenced by the keywords ref concept followed by an existing IRI. Moreover, a concept can specify between a pair of [ ] bracketsa a set of [KeyAxioms](#KeyAxiom-RL] and an optional InstanceEnumerationAxiom. It can also be followed by an optional EntitySpecializationAxiom and an optional EntityEquivalenceAxiom, using the following syntax.

  Annotation*
(concept ID | ref concept [Concept|IRI]) ([
  (KeyAxiom)* 
  (InstanceEnumerationAxiom)?
])? (EntitySpecialization)? (EntityEquivalence)?

The following example vocabulary defines a concept Component, and references an imported concept base:Package to add some axioms to it.

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends  <http://com.xyz/methodology/base#> as base
    concept Component
    ref concept base:Package [ .. ]
}

3.2.2.3. Relation Entity

A relation entity is an entity defined in a vocabulary and represents a reified relation between two entities in a modeled domain. A relation entity is declared with the keyword relation entity followed by an ID. An existing (local or imported) relation entity can be referenced by the keywords ref relation entity followed by its IRI. A relation entity can specify between [ ] some more details like optional from (domain) entities and optional to (range) entities that represent types of instances related by this relation, optional names for non-reified forward relation (with the same domains and ranges) and non-reified reverse relation (with the opposite domains and ranges), various DL flags (functional, inverse functional, symmetric, assymetric, reflective, irreflexive, and transitive), as well as a set of KeyAxioms. A relation entity definition can also be followed by an optional EntitySpecializationAxiom and an optional EntityEquivalenceAxiom, using the following syntax.

Annotation*
(relation entity ID | ref relation entity [RelationEntity|IRI]) ([
  (from [Entity|IRI] (, [Entity|IRI])*)?
  (to [Entity|IRI] (, [Entity|IRI])*)?
  (ForwardRelation)?
  (ReverseRelation)?
  (functional)?
  (inverse functional)?
  (symmetric)?
  (asymmetric)?
  (reflexive)?
  (irreflexive)?
  (transitive)?
  (KeyAxiom)*
])? (EntitySpecialization)? (EntityEquivalence)?

The optional forward relation and reverse relation are specified by ID as part of the textual syntax of a relation entity as shown belpw. When both are specified, the forward and reverse relations become inverse of each other, meaning if one is asserted (from instance A to B), the other is inferred (from instance B to A).

Annotation*
forward ID

Annotation*
reverse ID

The DL flags that can be specified on a relation entity have the following logical semantics:

The functional flag implies that a source instance can be related to a maximum of 1 target instance.
The inverse functional flag implies that a target instance can be related to a maximum of 1 source instance.
The symmetric flag implies that if a source instance is related to a target instance, then the target must also be related to the source.
The asymmetric flag implies that if a source instance is related to a target instance, then the target cannot be related to the source.
The reflexive flag implies that a source instance must be related to itself.
The irreflexive flag implies that a source instance cannot be related to itself.
The transitive flag implies if instance A is related to instance B, and instance B is related to instance C, then A is also related to C.

The following example vocabulary defines a relation entity named Performs from concept Component to concept Function. In this case a forward relation performs as well as a reverse relation isPerformedBy are also named. The flag inverse functional specifies that a function can be performed by a maximum of one component, the flag asymmetric specifies that a function cannot perform a component, and the flag irreflexive specifies 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. Scalar

A scalar is a type defined in a vocabulary and represents a primitive type that classifies a set of literals. A scalar is declared with the keyword scalar followed by an ID. An existing (local or imported) scalar can be referenced by the keywords ref scalar followed by its IRI. A scalar can also specify between a pair of [ ] brackets an optional LiteralEnumerationAxiom. It can also be followed by an optional ScalarSpecializationAxiom and an optional ScalarEquivalenceAxiom using the following syntax:

Annotation*
(scalar ID | ref scalar [Scalar|IRI]) ([
   (LiteralEnumerationAxiom)?
])? (ScalarSpecialization)? (ScalarEquivalence)?

The following example vocabulary defines a scalar named SSN.

vocabulary <http://example.com/primitive-types#> as primitives {
scalar SSN
}

OML considers the following set of scalars, defined in the owl spec, as standard:

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

// rdfs
http://www.w3.org/2000/01/rdf-schema#literal

// rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#Plainliteral
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLliteral

// owl
http://www.w3.org/2002/07/owl#real
http://www.w3.org/2002/07/owl#rational

// xsd
// Decimal Numbers and Integers
http://www.w3.org/2001/XMLSchema#decimal
http://www.w3.org/2001/XMLSchema#integer
http://www.w3.org/2001/XMLSchema#long
http://www.w3.org/2001/XMLSchema#int
http://www.w3.org/2001/XMLSchema#short
http://www.w3.org/2001/XMLSchema#byte
http://www.w3.org/2001/XMLSchema#nonNegativeInteger
http://www.w3.org/2001/XMLSchema#positiveInteger
http://www.w3.org/2001/XMLSchema#unsignedLong
http://www.w3.org/2001/XMLSchema#unsignedInt
http://www.w3.org/2001/XMLSchema#unsignedShort
http://www.w3.org/2001/XMLSchema#unsignedByte
http://www.w3.org/2001/XMLSchema#nonPositiveInteger
http://www.w3.org/2001/XMLSchema#negativeInteger
// Floating-Point Numbers
http://www.w3.org/2001/XMLSchema#double
http://www.w3.org/2001/XMLSchema#float
// Strings
http://www.w3.org/2001/XMLSchema#string
http://www.w3.org/2001/XMLSchema#normalizedString
http://www.w3.org/2001/XMLSchema#token
http://www.w3.org/2001/XMLSchema#language
http://www.w3.org/2001/XMLSchema#Name
http://www.w3.org/2001/XMLSchema#NCName
http://www.w3.org/2001/XMLSchema#NMTOKEN
// Boolean
http://www.w3.org/2001/XMLSchema#boolean
// Binary Data
http://www.w3.org/2001/XMLSchema#hexBinary
http://www.w3.org/2001/XMLSchema#base64Binary
// IRI
http://www.w3.org/2001/XMLSchema#anyURI
// Time
http://www.w3.org/2001/XMLSchema#dateTime
http://www.w3.org/2001/XMLSchema#dateTimeStamp

Note: for the standard scalars above to be used (cross-referenced) in a project, their respective vocabularies must be mapped by the project’s catalog.xml file. To achieve that, the project can specify a direct (or transitive) dependency on the core-vocabularies library (from Maven Central) in the project’s build.gradle file. An example of this can be seen in the oml-template project.

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 any identified element (ontology or member). On the other hand, a semantic property (Scalar Property or UnreifiedRelation) has logical semantics and is specified with one or more domains representing entities whose instances can be characterized by such property, and one or more ranges representing types of values for the property.

3.2.3.1. Annotation Property

An annotation property is a property defined in a vocabulary, has no logical-semantics, can be used in annotations on identified elements (ontology or member), and can have values that are either literals or references to members. An annotation property is defined with the keywords annotation property followed by a name ID. An existing (local or imported) annotation property can be referenced by the keywords ref annotation property followed by its IRI. It can also be followed by an optional PropertySpecializationAxiom and an optional PropertyEquivalenceAxiom using the following syntax:

Annotation*
(annotation property ID | ref annotation property [AnnotationProperty|IRI])
  (PropertySpecialization)? (PropertyEquivalence)?

The following example shows two vocabularies: viewpoint and mission. The former defines an annotation property visualizeAs, and the latter defines two concepts 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):

// rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#about

// rdfs
http://www.w3.org/2000/01/rdf-schema#comment
http://www.w3.org/2000/01/rdf-schema#isDefinedBy
http://www.w3.org/2000/01/rdf-schema#label
http://www.w3.org/2000/01/rdf-schema#seeAlso

// owl
http://www.w3.org/2002/07/owl#backwardCompatibleWith
http://www.w3.org/2002/07/owl#deprecated
http://www.w3.org/2002/07/owl#incompatibleWith
http://www.w3.org/2002/07/owl#priorVersion
http://www.w3.org/2002/07/owl#versionInfo

// dc
http://purl.org/dc/elements/1.1/contributor
http://purl.org/dc/elements/1.1/coverage
http://purl.org/dc/elements/1.1/creator
http://purl.org/dc/elements/1.1/date
http://purl.org/dc/elements/1.1/description
http://purl.org/dc/elements/1.1/format
http://purl.org/dc/elements/1.1/identifier
http://purl.org/dc/elements/1.1/language
http://purl.org/dc/elements/1.1/publisher
http://purl.org/dc/elements/1.1/relation
http://purl.org/dc/elements/1.1/rights
http://purl.org/dc/elements/1.1/source
http://purl.org/dc/elements/1.1/subject
http://purl.org/dc/elements/1.1/itle
http://purl.org/dc/elements/1.1/type
http://purl.org/dc/elements/1.1/hasVersion

3.2.3.2. Scalar Property

A scalar property is a semantic property defined in a vocabulary, whose domains can be entities (Aspects, Concepts, or Relation Entities) and whose ranges can be (Scalars. This means the values of a scalar property are literals of those scalar ranges. A scalar property is defined with the keywords scalar property followed by a name ID. An existing (local or imported) scalar property can be referenced by the keywords ref scalar property followed by its IRI. It can also specify between a pair of [ ] brackets optional domain entities and optional range scalars that can be inferred as types of values related by this property. When either is omitted, no type can be inferred for the value in that position. It can slso specify an optional DL flag functionalthat specifies that this property can relate an instance of its domains to a maximum of one literal of its ranges. The property can also be followed an optional PropertySpecializationAxiom and an optional PropertyEquivalenceAxiom, using the following syntax:

Annotation*
(scalar property ID | ref scalar property [ScalarProperty|IRI]) ([
  (domain [Entity|IRI] (, [Entity|IRI])*)?
  (range [Scalar|IRI] (, [Scalar|IRI])*)?
  (functional)?
])? (PropertySpecialization)? (PropertyEquivalence)?

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.3. Unreified Relation

An unreified relation is an relation defined in a vocabulary between two entities, a source entity and a target entity . An unreified relation is declared with the keyword relation followed by an ID. An existing (local or imported) unreified relation can be referenced by the keywords ref relation followed by its IRI. An unreified relation specifies between a pair of [ ] brackets optional from (domain) entities and optional to (range) entities that can be inferred as types of instances related by this relation. When either is omitted, no type can be inferred for a related instance in that position. An unreified relation can also specify an optional name for a non-reified reverse relation (with the opposite domains and ranges). Moreover, It can specify various DL flags (functional, inverse functional, symmetric, assymetric, reflective, irreflexive, and transitive). It can also be followed by an optional PropertySpecializationAxiom and an optional PropertyEquivalenceAxiom, using the following syntax.

Annotation*
(relation ID | ref relation [Relation|IRI]) ([
  (from [Entity|IRI] (, [Entity|IRI])*)?
  (to [Entity|IRI] (, [Entity|IRI])*)?
  (ReverseRelation)?
  (functional)? 
  (inverse functional)?
  (symmetric)?
  (asymmetric)?
  (reflexive)?
  (irreflexive)?
  (transitive)?
])? (PropertySpecialization)? (PropertyEquivalence)?

The DL flags that can be specified on an unreified relation have the following logical semantics:

The functional flag implies that a source instance can be related to a maximum of 1 target instance.
The inverse functional flag implies that a target instance can be related to a maximum of 1 source instance.
The symmetric flag implies that if a source instance is related to a target instance, then the target must also be related to the source.
The asymmetric flag implies that if a source instance is related to a target instance, then the target cannot be related to the source.
The reflexive flag implies that a source instance must be related to itself.
The irreflexive flag implies that a source instance cannot be related to itself.
The transitive flag implies if instance A is related to instance B, and instance B is related to instance C, then A is also related to C.

The following example vocabulary defines an unreified relation named presents from the concept Component to the concept Interface. It also has a reverse relation called isPresentedBy.

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

Note: A vocabulary author has the freedom to define a relation as a relation entity or an unreified relation. The downside of choosing the unreified option is the inability of describing relation instances and characterizing them with property values.

3.2.4. Axioms

Axioms are statements about terms in a vocabulary that enrich their logical semantics. This section describes the supported axioms for term kinds.

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 [Property|IRI] (, [Property|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. Instance Enumeration Axiom

An Instance Enumeration Axiom is an axiom that can be specified within the [ ] brackets of a Concept to enumerate certain Concept Instances, defined in a description ontology, as its only instances. The syntax of the axiom is as follows:

oneOf [ConceptInstance|IRI] (, [ConceptInstance|IRI])*

The following example vocabulary defines a concept SolarSystemPlanet with ss:Earth, ss:Mars, and ss:Mercurity ...etc. as its only enumerated planets.

vocabulary <http://example.com/planets#> as planets {
    uses <http://example.com/solarsystem#> as ss
    concept SolarSystemPlanet [
      oneOf ss:Earth , ss:Mars , ss:Mercury , ...
    ]
}
description <http://example.com/solarsystem#> as ss {
    instance Earth
    instance Mars
    instance Mercury
    ...
}

3.2.4.3. Literal Enumeration Axiom

A Literal Enumeration Axiom is an axiom that can be specified within the [ ] brackets of a Scalar to enumerate certain Literals as its only literals. The syntax of the axiom is as follows:

oneOf Literal (, Literal)*

The following example vocabulary defines a scalar RGB with Red, Green, and Blue as the only enumerated literals.

vocabulary <http://example.com/primitive-types#> as primitives {
    scaler RGB [
        oneOf "Red", "Green", "Blue"
    ]
}

3.2.4.4. Entity Specialization Axiom

An Entity Specialization Axiom is one that can be specified on an Entity to specify that it specializes other Entities and/or has PropertyRestrictionAxioms. Its syntax starts with < then a list of comma-separated Entities and/or a list of PropertyRestrictionAxioms as follows:

< ([Entity|IRI] (, [Entity|IRI])* 
  |
  ([Entity|IRI] (, [Entity|IRI])*)? [
    PropertyRestrictionAxiom*
  ])

Examples of using Entity Specialization Axioms can be seen in the following:

aspect Component < IdentifiableElement
concept MechanicalComponent < Component [
    restricts all contains to MechanicalComponent
]

Entities can only specialize entities of the same kind (e.g., concept specializes concept, scalar specializes scalar, etc.). The only exception to this is Aspect which can be specialized by any entity (Aspect, Concept, RelationEntity).

A RelationEntity, being a kind of Entity, can also specialize another [-RelationEntity=]. This case has the following extra semantics:

The intersection of the from entities of a sub relation entity specializes the intersection of the from entities of the super relation entity.
The intersection of the to entities of a sub relation entity specializes the intersection of the to entities of the super relation entity.
The forward relation (when named) of the sub relation entity specializes the forward relation of the super relation entity.
The reverse relation (when named) of the sub relation entity specializes the reverse relation of the super relation entity.

An example of RelationEntity specialization is given below. In this case, what is inferred is the following a) entity Assembly specializes entity component, entity Power specializes entity Function, relation provides specializes performs, and relation isProvidedBy specializes isPerformedBy.

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
   ]
}

3.2.4.5. Entity Equivalence Axiom

An Entity Equivalence Axiom is one that can be specified on an Entity to specify that it is equivalent to the intersection of other Entities and/or PropertyRestrictionAxioms. The syntax starts with = then a list of comma-separated EntityEquivalenceAxiom, each of which consists of a & separated list of entities and/or a list of PropertyRestrictionAxioms between [ ] brackets as follows:

= EntityEquivalenceAxiom (, EntityEquivalenceAxiom)*

<EntityEquivalenceAxiom>:
  [Entity|IRI] (& [Entity|IRI])*
  |
  ([Entity|IRI] (& [Entity|IRI])*)? [
    PropertyRestrictionAxiom*
  ]

Examples of using Entity Equivalence Axioms can be seen in the following:

concept FunctionalComponent = Component [
    restricts some hasRequirement to FunctionalRequirement
]
concept HawaianPizza = CheesyPizza & SaucyPizza [
    restricts some hasTopping to Ham
    restricts some hasTopping to Pineapple
]

Saying that entity A is equivalent to B is like saying that A specializes B and B specializes A. Therefore, the semantic of entity specialization described for [=EntitySpecializationAxiom] hold in both directions. This means if an instance is asserted to be typed by A, it will be inferred to be typed by B as well and vice versa (bidirectional inferencing). However, if B is an intersection of multiple Entities and/or PropertyRestrictionAxioms then the inverse specialization is not inferred until an instance of A is an instance of each of the intersecting components. In the example above, if an instance is a Component and has some of its requirements as FunctionalRequirement, then the instance can be inferred to be a FunctionalComponent.

Note: that equivalent classes must be of the same kind (e.g., concept is equivalent to concepts). The only exception is when an entity A is equivalent to an intersection of Entities and/or PropertyRestrictionAxioms, in which case some of the equivalent entities could be Aspects.

3.2.4.6. Scalar Specialization Axiom

A Scalar Specialization Axiom is one that can be specified on a Scalar to specify that it specializes other Scalars. Its syntax starts with < then a list of comma-separated Scalars as follows:

< Scalar (, Scalar)*

Note: a Scalar Specialization Axiom is only allowed on OML’s standard scalars. Non-standard scalars can only specify ScalarEquivalenceAxioms.

An example of a Scalar Specialization Axiom is as follows:

scalar rational < real

3.2.4.7. Scalar Equivalence Axiom

A Scalar Equivalence Axiom is one that can be specified on a Scalar to specify that it is equivalent to other Scalars optionally with some facets (value restrictions). The syntax starts with = then a list of comma-separated ScalarEquivalenceAxiom, each of which consists of a Scalar reference and optionally between [ ] bracketszero or more value-restricting faceets, as follows:

= ScalarEquivalenceAxiom (, ScalarEquivalenceAxiom)*;

<ScalarEquivalenceAxiom>:
  [Scalar|IRI] ([
     (length UnsignedInteger)? 
     (minLength UnsignedInteger)?
     (maxLength UnsignedInteger)?
     (pattern STRING)?
     (language ID)?
     (minInclusive Literal)?
     (minExclusive Literal)?
     (maxInclusive Literal)?
     (maxExclusive Literal)?
  ])?

Note: When facets are specified on a Scalar Equivalence Axiom, the referenced equivalent Scalar must be one of the standard scalars of OML.

The facets have the following semantics (and applicability to certain kinds of standard scalars):

Facet length specifies the exact length of the lexical representation (of strings and literals)
Facet minLength specifies the minimum length of the lexical representation (of strings and literals)
Facet maxLength specifies the maximum length of the lexical representation (of strings and literals)
Facet pattern specifies a regular expression of the lexical representation (of strings and literals)
Facet language specifies a natural language for the lexical representation (of strings and literals)
Facet minInclusive specifies the minimum inclusive value (of numbers)
Facet minExclusive specifies the minimum exclusive value (of numbers)
Facet maxInclusive specifies the maximum inclusive value (of numbers)
Facet maxExclusive specifies the maximum exclusive value (of numbers)

The following is an example of a Scalar Equivalence Axiom:

scalar SSN = xsd:string [
    pattern "^\d{3}-?\d{2}-?\d{4}$"
]

3.2.4.8. Property Specialization Axiom

A Property Specialization Axiom is one that can be specified on a Property to specify that it specializes other Properties of the same kind (e.g., scalar property speciailzes scalar property). Its syntax starts with < then a list of comma-separated Properties as follows:

< Property (, Property)*

Examples of using Property Specialization Axioms can be seen in the following:

scalar property hasEnglishName [
    domain Person
    range rdf:PlainLiteral
] < hasName
relation joins1 [
    from Interface
    to Interface
    reverse isJoinedBy1
] < joins

Note: a relation is a kind of property.

3.2.4.9. Property Equivalence Axiom

A Property Equivalence Axiom is one that can be specified on a Property to specify that it is equivalent to one or more other Properties. The syntax starts with = then a list of comma-separated PropertyEquivalenceAxiom, each of which has a reference to a Property.

= PropertyEquivalenceAxiom (, PropertyEquivalenceAxiom)*

<PropertyEquivalenceAxiom>:
  [Property|IRI]

Examples of using Property Equivalence Axioms can be seen in the following:

scalar property hasRational = hasObjective
relation hasUncle [ 
    from Person
    to Person
    forward hasUncle
] = hasParentBrother

Saying that property a is equivalent to b is like saying that a specializes b and b specializes a. Therefore, the semantic of property specialization described for PropertySpecializationAxiom hold in both directions. This means if an instance is asserted to have a value of property a, it will be inferred to have the same value for property b well and vice versa (bidirectional inferencing).

Note: that equivalent properties must be of the same kind (e.g., scalar property is equivalent to scalar property).

3.2.4.10. Property Value Restriction Axiom

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

Property Range Restriction Axioms

A range restriction axiom restricts the range of a property in the context of some entity. The axiom specifies a restricted range that is a subtype of the property’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 property (scalar property, or relation) then a reference to the property by IRI. Finally, the keyword to is used followed by a reference to the restricted range (a scalar or an entity) by IRI. The following shows the three supported syntaxes:

restricts [ all | some ] [ScalarProperty|IRI] to [Scalar|IRI]
restricts [ all | some ] [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 hasId to ten-chars          // the hasId value must be 10-char strings
        restricts some hasPin to InputPin     // there must be at least one input pin
        restricts all performs to Power                  // power is the only performed function 
    ]
    concept Power < Function
    scalar ten-chars < xsd:string [
        length 10
    ]
    concept Pin
    concept InputPin < Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    relation hasPin [
        from Component
        to Pin
        functional
   ]
}

Property Cardinality Restriction Axioms

A cardinality restriction axiom restricts the cardinality of a property in the context of some entity. 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 property can have in that context. The syntax of a cardinality restriction axioms starts with the keyword restricts followed by the kind of property (scalar property or relation) then a reference to the property 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 or an entity) by IRI. The following shows the three supported syntaxes:

restricts [ScalarProperty|IRI] to [ max | min | exactly ] UnsignedInteger [Scalar|IRI]?
restricts [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 hasId to exactly 1              // hasId must have a single value only
        restricts hasPin to max 2 InputPin    // there must be at most two input pins
        restricts performs to min 5                      // a minimum of 5 functions must be performed
    ]
    concept Pin
    concept InputPin < Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    relation hasPin [
        from Component
        to Pin
        functional
   ]
}

Property Value Restriction Axioms

A value restriction axiom restricts the value of a property in the context of some entity. 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 a reference to the property by IRI. Then, the keyword to is used followed by a value that is suitable for each case (a literal, an anonymous instance, or a reference to a named instance by IRI). The following shows the three supported syntaxes:

restricts [SemanticProperty|IRI] to Literal
restricts [SemanticProperty|IRI] to Anonymousnstance
restricts [SemanticProperty|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 hasId to "ABC"                          // hasId must have a value of "ABC"
        restricts hasPin to Pin [ hasNumber 1 ]   // hasPin must have a Pin with hasNumber of 1
        restricts performs to functions:F1                         // the performed function must be functions:F1
    ]
    concept Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    relation hasPin [
        from Component
        to 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
    instance F1 : mission:Function
}

Property Self Restriction Axioms

A self restriction axiom restricts the value of a relation in the context of some entity to the context itself. In other words, it restricts the instance that is the target of a relation to be the same one as the source of the relation. The syntax of a self restriction axioms starts with the keyword restricts followed by a reference to the relation by IRI, followed by the keyword to then finally the keyword self. The following shows the supported syntaxes:

restricts [Relation|IRI] to self

The following example shows a concept Person with a self restrictions on relation reliesOn:

concept Person [
    restricts reliesOn to self   // A person only relies on themselves
]

3.2.5. BuiltIn

A builtin is a standard function that can be invoked from a Rule's BuiltInPredicate. The syntax of a builtin starts with the keyword builtin followed by a name ID. An existing (local or imported) builtin can be referenced by the keywords ref builtin followed by its IRI as follows:

Annotation*
(builtin ID | ref builtin [BuiltIn|IRI])

Note: OML supports all the stadard builtins from the swrlb vocabulary. This vocabulary is included in the core-vocabularies library (from Maven Central) which is a project declare a dependency on in its build.gradle file.

An example of some of those builtins include:

vocabulary <http://www.w3.org/2003/11/swrlb#> as swrlb {
    builtin equal
    builtin notEqual
    builtin lessThan
    builtin lessThanOrEqual
}

3.2.6. 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:

Note: all the arguments to the predicats below can be one of three values: a) a variable ID (e.g., x, y), b) a literal (e.g., 3, "hello"), or c) a member reference (e.g., solar:Sun).

Type Predicate

Matches an instance of a given type (specified by its IRI) and binds it to the argument.
```
[Type|IRI] ( Argument )
```
Relation Entity Predicate

Matches a instance of a given relation entity (specified by its IRI) and binds it to argument0, its source to argument1, and its target to argument2.
```
[RelationEntity|IRI] ( Argument1 , Argument0 , Argumen2 )
```
Property Predicate

Matches an assertion of a given property (specified by its IRI) and binds its subject to argument1 and its object to argument2.
```
[Property|IRI] ( Argument1 , Argument2 )
```
Same As Predicate

Matches when the value bound to argument1 is the same as the value bound to argument2 or a specific instance.
```
sameAs ( Argument1 , Argument2 )
```
Different From Predicate

Matches when the value bound to argument1 is different from the value bound to argument2.
```
differentFrom ( Argument1 , Argument2 )
```
BuiltIn Predicate

Matches when the first argument is the result of invoking the referenced builtin function with the remaining arguments bound to its parameters.
```
builtIn ( [BuiltIn|IRI] , Argument (, Argument)* )
```

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
    extends <http://www.w3.org/2003/11/swrlb#> as swrlb
    concept Component
    concept AComponent < 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 )
   ]
   rule R3 [
       hasId(x, y) & builtin ( swrlb:startsWith, y, "a" ) -> AComponent ( x )
   ]
}

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 {
  Import*
  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 (extension, usage) that can be added in a description’s body.

3.3.1.1. Extension

An 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

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

3.3.1.2. Usage

A 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

    instance System1 : mission:Component     // a cross-reference to concept Component
}

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 properties 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 (Anonymous Concept Instance and Anonymous Relation Instance), in which case they defined as values of semantic 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 instance and a name ID. It can optionally be followed by a : and the IRIs of one or more concepts (or aspects) 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*
instance 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
    instance component1 : mission:Component
    instance 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 relation instance 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.

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.

Annotation*
relation instance 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
    instance component1 : mission:Component
    instance function1 : mission:Function
    instance function2 : mission:Function
    relation instance perform1 : mission:Performs [
        from component1
        to function1, function2
    ]
}

3.3.2.3. Anonymous Concept Instance

An anonymous concept instance is an anonymous instance that can be defined as a value of a relation. Such value can either be specified in a property value assertion, defined in the context of some instance, or in a property value restriction axiom on some relation in the context of some entity. An anonymous concept instance is declared with an optional type, represented by a colon (:) followed by a concept (or aspect) IRI , followed by a pair of square brackets ([ ]) that holds assertions about the instance. Note that if a type is omitted, it will be inferred to be the target of the relation that defines the anonymous concept instance.

(: [Entity|IRI])? [
  Assertion*
]

The following example shows .

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Component [
        restricts hasPin to : Pin [ hasNumber 1 ]   // anonymous concept instance used as restricted value
    ]
    concept Pin
    relation hasPin [
        from Component
        to 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
    instance C1 : mission:Component [
        mission:hasPin : Pin [ mission:hasNumber 2 ]                    // anonymous concept instance used in value assertion
    ]
}

3.3.2.4. Anonymous Relation Instance

An anonymous relation instance is an anonymous instance of a relation entity that can be defined as a value of a forward or a reverse relation. Such value can either be specified in a property value assertion, defined on some forward or reverse relation in the context of a (source) named instance, or in a property value restriction axiom on some forward or reverse relation in the context of an entity (representing the type of source of the relation). An anonymous relation instance is declared with the IRI of a (target) named instance followed by a pair of square brackets ([ ]) that holds assertions about the relation instance.

[NamedInstance|IRI] [
  Assertion*
]

The following example shows .

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    uses <http://com.xyz/system/functions#> as functions
    concept Component [
        restricts performs to function1 [ hasPriority 3 ]   // any component performs function1 with a priority of 3
    ]
    concept Function
    relation entity Performs [
        from Component
        to Function
        forward performs
        inverse functional
   ]
    scalar property hasPriority [
        domain Performs
        range xsd:int
        functional
   ]
}

description <http://com.xyz/system/components#> as components {
    extends <http://com.xyz/system/functions#> as functions
    uses <http://com.xyz/methodology/mission#> as mission
    instance C1 : mission:Component [
        mission:performs functions:function2 [ mission:priority 2 ]  // C1 performs function2 with a priority of 2
    ]
}

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 property value assertion that can be specified on named or anonymous (concept or relation) instances.

3.3.3.1. Property Value Assertion

A value for a semantic property can be asserted on an instance (Concept Instance, Relation Instance, Anonymous Concept Instance or Anonymous Relation 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 semantic property from some vocabulary followed by one or more values, which could be literals, anonymous instances, or IRIs of named instances.

[ScalarProperty|IRI] Literal (, Literal)*
[Relation|IRI] [NamedInstance|IRI] (, [NamedInstance|IRI])*

The following example description defines two concept instances that each makes a number of property assertions. Specifically, instance component1 asserts that the mission:hasId scalar property has a string value of C1, the mission:hasPin relation as an anonymous concept instance (whose mission:hasNumber property value is asserted to be 2) as a value, and the mission:performs relation has the IRI of instance function1 as a value. Also, instance function1 asserts that its mission:hasName property has a string value of F1.

description <http://com.xyz/system/components#> as components {
    uses <http://com.xyz/methodology/mission#> as mission
    instance component1 : mission:Component [
        mission:hasId 'C1'                      // scalar property value assertion
        mission:hasPin Pin [ mission:hasNumber 2 ]      // anonymous concept property value assertion
        mission:performs function1                // relation value assertion
    ]
    instance function1 : mission:Function [
        mission:hasName 'F1'                    // scalar property value assertion
    ]
}

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. Extension

An extension 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.4.1.2. Inclusion

An 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.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. Extension

An 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#>
}

3.5.1.2. Usage

A 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. Inclusion

An 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#>
}

4. Textual BNF

Ontology ::=
  VocabularyBox |
  DescriptionBox

Annotation ::=
  "@" [AnnotationProperty|IRI] ((Literal | [Member|IRI]) ("," (Literal | [Member|IRI]))*)?

VocabularyBox ::=
  Vocabulary |
  VocabularyBundle

Vocabulary ::=
  Annotation*
  "vocabulary" NAMESPACE "as" ID  "{"
    (Extension|Usage)*
    VocabularyStatement*
  "}"

VocabularyBundle ::=
  Annotation*
  "vocabulary" "bundle" NAMESPACE "as" ID "{"
    (Extension|Inclusion)*
  "}"

DescriptionBox ::=
  Description |
  DescriptionBundle
	
Description ::=
  Annotation*
  "description" NAMESPACE "as" ID "{"
    (Extension|Usage)*
    DescriptionStatement*
  "}"

DescriptionBundle ::=
  Annotation*
  "description" "bundle" NAMESPACE "as" ID "{"
    (Extension|Usage|Inclusion)*
  "}"

SpecializableTerm ::=
  Type |
  AnnotationProperty |
  ScalarProperty |
  UnreifiedRelation

Type ::=
  Entity |
  Scalar  
	
Entity ::=
  Aspect |
  Concept |
  RelationEntity

Aspect ::=
  Annotation*
  ("aspect" ID | "ref" "aspect" [Aspect|IRI]) ("["
    (KeyAxiom)* 
  "]")? (EntitySpecialization)? (EntityEquivalence)?

Concept ::=
  Annotation*
  ("concept" ID | "ref" "concept" [Concept|IRI]) ("["
    (InstanceEnumerationAxiom)?
    (KeyAxiom)* 
  "]")? (EntitySpecialization)? (EntityEquivalence)?
	
RelationEntity ::=
  Annotation*
  ("relation" "entity" ID | "ref" "relation" "entity" [RelationEntity|IRI]) ("["
    ("from" [Entity|IRI] ("," [Entity|IRI])*)?
    ("to" [Entity|IRI] ("," [Entity|IRI])*)?
    (ForwardRelation)?
    (ReverseRelation)?
    ("functional")?
    ("inverse" "functional")?
    ("symmetric")?
    ("asymmetric")?
    ("reflexive")?
    ("irreflexive")?
    ("transitive")?
    (KeyAxiom)*
  "]")? (EntitySpecialization)? (EntityEquivalence)?
	
EntitySpecialization ::=
  "<" (Entity ("," Entity)* 
    |
    (Entity ("," Entity)*)? "["
      PropertyRestrictionAxiom*
    "]")

EntityEquivalence ::=
  "=" EntityEquivalenceAxiom ("," EntityEquivalenceAxiom)*

EntityEquivalenceAxiom ::=
  [Entity|IRI] ("&" [Entity|IRI])*
  |
  {EntityEquivalenceAxiom} 
  ([Entity|IRI] ("&" [Entity|IRI])*)? "["
    PropertyRestrictionAxiom*
  "]"

Scalar ::=
  Annotation*
  ("scalar" ID | "ref" "scalar" [Scalar|IRI]) ("["
     (LiteralEnumerationAxiom)?
  "]")? (ScalarSpecialization)? (ScalarEquivalence)?

ScalarSpecialization ::=
  "<" Scalar ("," Scalar)*

ScalarEquivalence ::=
  "=" ScalarEquivalenceAxiom ("," ScalarEquivalenceAxiom)*;

ScalarEquivalenceAxiom ::=
  [Scalar|IRI] ("["
     ("length" UnsignedInteger)? 
     ("minLength" UnsignedInteger)?
     ("maxLength" UnsignedInteger)?
     ("pattern" STRING)?
     ("language" ID)?
     ("minInclusive" Literal)?
     ("minExclusive" Literal)?
     ("maxInclusive" Literal)?
     ("maxExclusive" Literal)?
  "]")?

Property ::=
  AnnotationProperty |
  SemanticProperty

AnnotationProperty ::=
  Annotation*
  ("annotation" "property" ID | "ref" "annotation" "property" [AnnotationProperty|IRI])
    (PropertySpecialization)? (PropertyEquivalence)?

SemanticProperty ::=
  ScalarProperty |
  Relation

ScalarProperty ::=
  Annotation*
  ("scalar" "property" ID | "ref" "scalar" "property" [ScalarProperty|IRI]) ("["
    ("domain" [Entity|IRI] ("," [Entity|IRI])*)?
    ("range" [Scalar|IRI] ("," [Scalar|IRI])*)?
    ("functional")?
  "]")? (PropertySpecialization)? (PropertyEquivalence)?

Relation ::=
  ForwardRelation |
  ReverseRelation |
  UnreifiedRelation

ForwardRelation ::=
  Annotation*
  "forward" ID

ReverseRelation ::=
  Annotation*
  "reverse" ID

UnreifiedRelation ::=
  Annotation*
  ("relation" ID | "ref" "relation" [Relation|IRI]) ("["
    ("from" [Entity|IRI] ("," [Entity|IRI])*)?
    ("to" [Entity|IRI] ("," [Entity|IRI])*)?
    (ReverseRelation)?
    ("functional")? 
    ("inverse" "functional")?
    ("symmetric")?
    ("asymmetric")?
    ("reflexive")?
    ("irreflexive")?
    ("transitive")?
  "]")? (PropertySpecialization)? (PropertyEquivalence)?

PropertySpecialization ::=
  "<" Property ("," Property)*

PropertyEquivalence ::=
  "=" PropertyEquivalenceAxiom ("," PropertyEquivalenceAxiom)*

PropertyEquivalenceAxiom ::=
  [Property|IRI]

Rule ::=
  Annotation*
  ("rule" ID | "ref" "rule" [Rule|IRI]) ("["
    (Predicate ("&" Predicate)* "->" Predicate ("&" Predicate)*)?
  "]")?

BuiltIn ::=
  Annotation*
  ("builtin" ID | "ref" "builtin" [BuiltIn|IRI])

AnonymousInstance ::=  
  AnonymousConceptInstance |
  AnonymousRelationInstance

AnonymousConceptInstance ::=  
  (":" [Entity|IRI])? "["
    PropertyValueAssertion*
  "]"
	
AnonymousRelationInstance ::=  
  [NamedInstance|IRI] "["
    PropertyValueAssertion*
  "]"

NamedInstance ::=
  ConceptInstance |
  RelationInstance

ConceptInstance ::=
  Annotation*
  ("instance" ID | "ref" "instance" [ConceptInstance|IRI]) (":" ConceptTypeAssertion ("," ConceptTypeAssertion)*)? ("["
    PropertyValueAssertion*
  "]")?
	
RelationInstance ::=
  Annotation*
  ("relation" "instance" ID | "ref" "relation" "instance" [RelationInstance|IRI]) (":" RelationTypeAssertion ("," RelationTypeAssertion)*)? ("["
    ("from" [NamedInstance|IRI] ("," [NamedInstance|IRI])*)? 
    ("to" [NamedInstance|IRI] ("," [NamedInstance|IRI])*)?
    PropertyValueAssertion*
  "]")?

Member ::=
  VocabularyMember |
  DescriptionMember |
  Statement

VocabularyMember ::=
  VocabularyStatement |
  Term

DescriptionMember ::=
  DescriptionStatement

Statement ::=
  VocabularyStatement |
  DescriptionStatement

VocabularyStatement ::=
  Rule |
  BuiltIn |
  SpecializableTerm
	
DescriptionStatement ::=
  NamedInstance

Term ::=
  Property |
  SpecializableTerm

Import ::=
  Extension |
  Usage |
  Inclusion

Extension ::=
  Extends NAMESPACE ("as" ID)?
    	
Usage ::=
  Uses NAMESPACE ("as" ID)?
    	
Inclusion ::=
  Includes NAMESPACE ("as" ID)?

PropertyRestrictionAxiom ::=
  PropertySelfRestrictionAxiom |
  PropertyRangeRestrictionAxiom |
  PropertyCardinalityRestrictionAxiom |
  PropertyValueRestrictionAxiom

PropertyRangeRestrictionAxiom ::=
  "restricts" RangeRestrictionKind [SemanticProperty|IRI] "to" [Type|IRI]

PropertyCardinalityRestrictionAxiom ::=
  "restricts" [SemanticProperty|IRI] "to" CardinalityRestrictionKind UnsignedInteger ([Type|IRI])?

PropertyValueRestrictionAxiom ::=
  "restricts" [SemanticProperty|IRI] "to" (Literal | AnonymousInstance | [NamedInstance|IRI])

PropertySelfRestrictionAxiom ::=
  "restricts" [SemanticProperty|IRI] "to" "self"

KeyAxiom ::=
  "key" [Property|IRI] ("," [Property|IRI])*

InstanceEnumerationAxiom ::=
  "oneOf" [ConceptInstance|IRI] ("," [ConceptInstance|IRI])*

LiteralEnumerationAxiom ::=
  "oneOf" Literal ("," Literal)*

ConceptTypeAssertion ::=
  [Concept|IRI]

RelationTypeAssertion ::=
  [RelationEntity|IRI]

PropertyValueAssertion ::=
  [SemanticProperty|IRI] (Literal | AnonymousInstance | [NamedInstance|IRI])  ("," (Literal | AnonymousInstance | [NamedInstance|IRI]))*

Predicate ::=
  UnaryPredicate |
  BinaryPredicate |
  BuiltInPredicate

UnaryPredicate ::=
  TypePredicate |
  RelationEntityPredicate
	
BinaryPredicate ::=
    PropertyPredicate |
    SameAsPredicate |
    DifferentFromPredicate

TypePredicate ::=
  [Type|IRI] "(" Argument ")"
	
RelationEntityPredicate ::=
    [RelationEntity|IRI] "(" Argument "," Argument "," Argument ")"

PropertyPredicate ::=
  [Property|IRI] "(" Argument "," Argument ")"

SameAsPredicate ::=
    "sameAs" "(" Argument "," Argument ")"

DifferentFromPredicate ::=
    "differentFrom" "(" Argument "," Argument ")"

BuiltInPredicate ::=
    "builtIn" "(" [BuiltIn|IRI] "," Argument ("," Argument)* ")"

Argument ::=
  ID | Literal | [NamedInstance|REF]


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

Extends ::=
  "extends"

Uses ::=
  "uses"

Includes ::=
  "includes"

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 ::= 
  NUMERIC+

INTEGER_STR ::= 
  ("+"|"-")? NUMERIC+

DECIMAL_STR ::= 
  ("+"|"-")? (NUMERIC+("."NUMERIC*)? | ("."NUMERIC+))

DOUBLE_STR ::= 
  ("+"|"-")? (NUMERIC+("."NUMERIC*)? | ("."NUMERIC+)) (("e"|"E") ("+"|"-")? NUMERIC+)?

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

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

IRI ::= 
  ID | REF

REF ::=
  FULL_IRI | ABBREVIATED_IRI

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

ABBREVIATED_IRI ::= 
  ID ":" ID

ID ::= 
  "^"? (ALPHA|NUMERIC|SPECIAL) (ALPHA|NUMERIC|SPECIAL|"$")*

ALPHA ::= 
  "a".."z" | "A".."Z"

NUMERIC ::= 
  "0".."9"

SPECIAL ::= 
  "_"|"-"|"."|"~"|"%"

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:

        

Scalar:

        

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

6.1.1. Annotation

Annotation is an element that specifies non-semantic information on an IdentifiedElement. An annotation is specified with an AnnotationProperty and either Literal values or Member (referenced) values. When no value is specified, the boolean literal true is assumed to be the value.

Super classes	Element
Properties	property : AnnotationProperty [1] The annotation property specified by this annotation literalValues : Literal [] The literal values specified by this annotation referencedValues : Member [] The referenced values (iris of members) specified by this annotation owningElement : IdentifiedElement [0..1] The identified element that owns this annotation

6.1.2. Element

Element is the root supertype in OML. All objects in an OML ontology are elements.

Sub classes	Annotation Argument Assertion Axiom IdentifiedElement Import Instance Literal Predicate

6.1.3. IdentifiedElement

IdentifiedElement is an element that has a unique IRI (Internationalized Resource Identifier). It can be annotated by a set of Annotations.

Super classes	Element
Sub classes	Member Ontology
Properties	ownedAnnotations : Annotation [*] The set of annotations directly owned by this element

6.1.4. Import

Import is an element owned by an ontology and specifies that it imports another ontology. The imported ontology is referenced by its namespace and an optional prefix that is locally unique within the importing ontology. Import can be of several ImportKind based on the following rules:

Vocabulary (extends Vocabulary, uses Description)
Description (extends Description, uses Vocabulary)
VocabularyBundle (extends VocabularyBundle, includes Vocabulary)
DescriptionBundle (extends DescriptionBundle, includes Description, uses VocabularyBundle, uses Vocabulary)

Super classes	Element
Properties	kind : ImportKind [1] The kind of this import namespace : Namespace [1] The namespace of the imported ontology prefix : ID [0..1] The (locally unique) namespace prefix of the imported ontology owningOntology : Ontology [1] The ontology that owns this import

6.1.5. ImportKind

ImportKind is an enumeration that specifies the kind of =[import=].

Literals	extension Extension is an import that allows an ontology to extend another of the same type. inclusion Inclusion is an import that allows a bundle ontology to include a non-bundle ontology of the same box type. usage Usage is an import that allows an ontology to use another of a different box type.

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	IdentifiedElement
Sub classes	DescriptionMember Statement VocabularyMember
Properties	name : ID [0..1] A unique name for the member within its ontology

6.1.7. Ontology

Ontology is an identified element that represents a namespace for its members. It is defined by a globally unique namespace (an iri followed by either # or /) and an abbreviated prefix. An ontology can import other ontologies, and can make statements about its own as well as imported members.

Super classes	IdentifiedElement
Sub classes	DescriptionBox VocabularyBox
Properties	namespace : Namespace [1] The globally unique namespace of this ontology prefix : ID [1] The prefix of this ontology’s namespace ownedImports : Import [*] The set of imports this ontology has to other ontologies

6.1.8. SeparatorKind

SeparatorKind is an enumeration that specifies the separator character of an ontology’s namespace. It can be one of two values: # or /.

Literals	hash slash

6.1.9. Statement

Statement is a member that is owned by an ontology.

Super classes	Member
Sub classes	DescriptionStatement VocabularyStatement

6.2. Literals

6.2.1. BooleanLiteral

BooleanLiteral is a literal that represents the boolean values true and false.

Super classes	Literal
Properties	value : EBooleanObject [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	Literal
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	Literal
Properties	value : Double [0..1] The double value of this literal

6.2.4. IntegerLiteral

IntegerLiteral is a literal that represents a 32-bit integer value.

Super classes	Literal
Properties	value : Integer [0..1] The int value of this literal

6.2.5. Literal

Literal is an element that represents a literal value classified by a scalar.

Super classes	Element
Sub classes	BooleanLiteral DecimalLiteral DoubleLiteral IntegerLiteral QuotedLiteral

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	Literal
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

6.3.1. BuiltIn

BuiltIn is a member of a vocabulary that represents a builtin function

Super classes	VocabularyStatement
Properties	ref : BuiltIn [0..1] A ref to another builtin

6.3.2. Rule

Rule is a member of a vocabulary that adds a new inference rule to the set supported natively by DL. A rule must specify a set of one or more antecedent predicates that forms a conjunction that infers, when it holds, a set of one or more consequent predicates.

Super classes	VocabularyStatement
Properties	ref : Rule [0..1] A ref to another rule antecedent : Predicate [] The set of predicates that form the antecedent of this rule consequent : Predicate [] The predicate that is the consequent of this rule

6.3.3. SpecializableTerm

SpecializableTerm is a term that can be specialized by another term. It can have zero or more SpecializationAxioms.

Super classes	Term VocabularyStatement
Sub classes	RelationBase SpecializableProperty Type
Properties	ownedSpecializations : SpecializationAxiom [*] The specialization axioms owned by this term

6.3.4. Term

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

Super classes	VocabularyMember
Sub classes	Property SpecializableTerm

6.3.5. Vocabulary

Vocabulary is a vocabulary box whose statements specify terms and rules in a given domain.

Super classes	VocabularyBox
Properties	ownedStatements : VocabularyStatement [*] The set of statements contained by this vocabulary

6.3.6. VocabularyBox

VocabularyBox is the supertype of Vocabulary and VocabularyBundle.

Super classes	Ontology
Sub classes	Vocabulary VocabularyBundle

6.3.7. VocabularyBundle

VocabularyBundle is a vocabulary box that closes the world on its imported vocabularies by considering their =terms=] that do not have common specializations to be disjoint.

Super classes	VocabularyBox

6.3.8. VocabularyMember

VocabularyMember is a member of a vocabulary.

Super classes	Member
Sub classes	Term VocabularyStatement

6.3.9. VocabularyStatement

VocabularyStatement is a statement owned by a vocabulary.

Super classes	Statement VocabularyMember
Sub classes	BuiltIn Rule SpecializableTerm
Properties	owningVocabulary : Vocabulary [1] The vocabulary that owns this statement

6.4. Types

6.4.1. Aspect

Aspect is an =[entity=] that represents a capability that may be specified on multiple concepts. An aspect can only specialize other aspects. It can also be specified as a type of NamedInstances. Aspects are not considered disjoint in a vocabulary bundle.

Super classes	Entity
Properties	ref : Aspect [0..1] A ref to another aspect

6.4.2. Concept

Concept is an entity that represents a concept in some domain. It can only specialize other concepts of aspects. It can also be specified as a type of ConceptInstances. Concepts with no common subtypes are considered disjoint in a vocabulary bundle.

Super classes	Entity
Properties	ref : Concept [0..1] A ref to another concept ownedEnumeration : InstanceEnumerationAxiom [0..1] An enumeration of instances of this concept

6.4.3. Entity

Entity is a structured type that represent a set of Instances. it can specify a set of PropertyRestrictionAxioms, set of EntityEquivalenceAxioms, and a set of KeyAxioms.

Super classes	Type
Sub classes	Aspect Concept RelationEntity
Properties	ownedEquivalences : EntityEquivalenceAxiom [] The set of entity equivalence axioms of this entity ownedPropertyRestrictions : PropertyRestrictionAxiom [] The set of property restriction axioms of this entity ownedKeys : KeyAxiom [*] The unique keys of this entity

6.4.4. Scalar

Scalar is a primitive type that represents a set of literals. Some scalars are considered standard (see below).

A standard scalar can have specialization axioms to other standard scalars.

Non-standard scalars cannot have specialization axioms, but can have scalar equivalence axioms.

The standard scalars are:

Numeric scalars: 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: xsd:dateTime xsd:dateTimeStamp

Plain scalars: rdf:PlainLiteral String scalars: xsd:string, xsd:normalizedString, xsd:token, xsd:language, xsd:Name, xsd:NCName, xsd:NMTOKEN xsd:anyURI

Boolean scalars: xsd:boolean

Binary scalars}: xsd:hexBinary xsd:base64Binary

XML scalars: rdf:XMLLiteral

Super classes	Type
Properties	ref : Scalar [0..1] A ref to another scalar ownedEnumeration : LiteralEnumerationAxiom [0..1] An enumeration of literals of this scalar ownedEquivalences : ScalarEquivalenceAxiom [*] The set of scalar equivalence axioms of this scalar

6.4.5. Type

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

Super classes	SpecializableTerm
Sub classes	Entity Scalar

6.5. Properties

6.5.1. AnnotationProperty

AnnotationProperty is a SpecializableProperty with no DL semantics.

Super classes	SpecializableProperty
Properties	ref : AnnotationProperty [0..1] A ref to another annotation property

6.5.2. CardinalityRestrictionKind

CardinalityRestrictionKind is an enumeration that specifies the kind of PropertyCardinalityRestrictionAxiom on a property.

Literals	exactly The cardinality must match this max The cardinality is at most this min The cardinality is at least this

6.5.3. Property

Property is a term that relates an instance to a value. It is the super type of all property types.

Super classes	Term
Sub classes	SemanticProperty SpecializableProperty

6.5.4. RangeRestrictionKind

RangeRestrictionKind is an enumeration that specifies the scope of a PropertyRangeRestrictionAxiom.

Literals	all All values are restricted to the range some Some values are restricted to the range

6.5.5. Relation

Relation is a SemanticProperty whose domain is an Entity and whose range is also an Entity. It can be characterized by DL flags and can have an inverse Relation.

Super classes	SemanticProperty
Sub classes	ForwardRelation ReverseRelation UnreifiedRelation

6.5.6. ScalarProperty

ScalarProperty is a SemanticProperty whose range is a Scalar. It can specialize other ScalarProperties.

Super classes	SemanticProperty SpecializableProperty
Properties	ref : ScalarProperty [0..1] A ref to another scalar property functional : Boolean [0..1] Whether this property is functional (has a max of one value per instance) domains : Entity [] The entity that is the domain of this property ranges : Scalar [] The scalar that is the range of this property

6.5.7. SemanticProperty

SemanticProperty is a property with DL semantics that relates a entity acting as its domain to a type acting as its range.

Super classes	Property
Sub classes	Relation ScalarProperty

6.5.8. SpecializableProperty

SpecializableProperty is a property that can be specialized. It can also specify PropertyEquivalenceAxioms.

Super classes	Property SpecializableTerm
Sub classes	AnnotationProperty ScalarProperty UnreifiedRelation
Properties	ownedEquivalences : PropertyEquivalenceAxiom [*] The set of property equivalence axioms of this property

6.6. Relations

6.6.1. ForwardRelation

ForwardRelation is a Relation that is defined by a RelationEntity. Its domains are the sources of the RelationEntity, and its ranges are the targets of the RelationEntity. The DL semantics of a forward property are the same as those of its RelationEntity.

Super classes	Relation
Properties	relationEntity : RelationEntity [1] The relation entity that owns this forward property

6.6.2. RelationBase

RelationBase is a specializable term that is the abstract superclass of a relation from a source entity to a target entity. It can optionally name a ReverseRelation(on a relation base definition not a ref) whose domain is the target and whose range is the source. A relation base can be characterized with several boolean flags that represent its DL semantics. Such flags apply conversely to the ReverseRelation (if named).

Super classes	SpecializableTerm
Sub classes	RelationEntity UnreifiedRelation
Properties	sources : Entity [] The entities that represent the sources of this relation base targets : Entity [] The entities that represent the targets of this relation base reverseRelation : ReverseRelation [0..1] The optional reverse relation of this relation base functional : Boolean [0..1] Whether this relation base is functional (i.e., {@code A -> B and A->C => B=C}) inverseFunctional : Boolean [0..1] Whether this relation base is inverse functional (i.e., {@code B->A and C->A => B=C}) symmetric : Boolean [0..1] Whether this relation base is symmetric (i.e., {@code A->B => B->A}) asymmetric : Boolean [0..1] Whether this relation base is asymmetric (i.e., {@code A->B => !(B->A)}) reflexive : Boolean [0..1] Whether this relation base is reflexive (i.e., {@code A => A->A}) irreflexive : Boolean [0..1] Whether this relation base is irreflexive (i.e., {@code A => !(A->A)}) transitive : Boolean [0..1] Whether this relation base is transitive (i.e., {@code A->B and B->C => A->C})

6.6.3. RelationEntity

RelationEntity is an entity that represents a reified relation from a source entity to a target entity. It names a ForwardRelation (only on a relation entity definition not a ref) whose domain is the source and whose range is the target.

Super classes	Entity RelationBase
Properties	ref : RelationEntity [0..1] A ref to another relation entity forwardRelation : ForwardRelation [0..1] The optional forward relation of this relation entity

6.6.4. ReverseRelation

ReverseRelation is a Relation that is defined by a RelationBase and represents its inverse relation. Its domain is the target of the RelationBase, and its range is the source of the RelationBase. The DL semantics of a reverse property are derived from those of its RelationBase.

Super classes	Relation
Properties	relationBase : RelationBase [1] The relation that owns this reverse property

6.6.5. UnreifiedRelation

UnreifiedRelation is a simple relation from a source entity to a target entity.

Super classes	Relation RelationBase SpecializableProperty
Properties	ref : Relation [0..1] A ref to another relation

6.7. Predicates

6.7.1. Argument

Argument is an element that represents a variable name, a Literal, or an NamedInstance specified in a predicate.

Super classes	Element
Properties	variable : ID [0..1] An optional variable specified by this argument literal : Literal [0..1] An optional literal specified by this argument instance : NamedInstance [0..1] An optional instance specified by this argument

6.7.2. BinaryPredicate

BinaryPredicate is a Predicate that has two arguments: argument1 and argument2

Super classes	Predicate
Sub classes	DifferentFromPredicate PropertyPredicate RelationEntityPredicate SameAsPredicate
Properties	argument1 : Argument [1] An argument of the predicate argument2 : Argument [1] An argument of the predicate

6.7.3. BuiltInPredicate

BuiltInPredicate is a Predicate that has two arguments: argument1 and argument2

Super classes	Predicate
Properties	builtIn : BuiltIn [1] The called builtin arguments : Argument [*] An argument of the predicate

6.7.4. DifferentFromPredicate

DifferentFromPredicate is a BinaryPredicate that holds when its two arguments are bound to different NamedInstances.

Super classes	BinaryPredicate

6.7.5. Predicate

Predicate is an element that represents a component of a rule's antecedent or consequent. It specifies (one or more) arguments based on the specific subtype of predicate.

Super classes	Element
Sub classes	BinaryPredicate BuiltInPredicate UnaryPredicate
Properties	antecedentRule : Rule [0..1] The rule' antecedent that this predicate is owned by consequentRule : Rule [0..1] The rule' consequent that this predicate is owned by

6.7.6. PropertyPredicate

PropertyPredicate is a BinaryPredicate that holds when its argument1 is bound to an NamedInstance and its argument2 is bound to a a value of a given property on that instance.

Super classes	BinaryPredicate
Properties	property : Property [1] The property of an instance

6.7.7. RelationEntityPredicate

RelationEntityPredicate is a UnaryPredicate and BinaryPredicate that holds when its argument is bound to an RelationInstance typed by the given RelationEntity, its argument1 is bound to the source of that RelationInstance and its argument2 is bound to the target of that RelationInstance .

Super classes	BinaryPredicate UnaryPredicate
Properties	type : RelationEntity [1] The type of a relation instance

6.7.8. SameAsPredicate

SameAsPredicate is a BinaryPredicate that holds when its two arguments are bound to the same NamedInstance.

Super classes	BinaryPredicate

6.7.9. TypePredicate

TypePredicate is a UnaryPredicate whose argument is bound to a value typed by a given type.

Super classes	UnaryPredicate
Properties	type : Type [1] The type of a value

6.7.10. UnaryPredicate

UnaryPredicate is a Predicate that has one argument.

Super classes	Predicate
Sub classes	RelationEntityPredicate TypePredicate
Properties	argument : Argument [1] An argument of the predicate

6.8. Axioms

6.8.1. Axiom

Axiom is an element that characterizes a term in some way.

Super classes	Element
Sub classes	EntityEquivalenceAxiom InstanceEnumerationAxiom KeyAxiom LiteralEnumerationAxiom PropertyEquivalenceAxiom PropertyRestrictionAxiom ScalarEquivalenceAxiom SpecializationAxiom

6.8.2. EntityEquivalenceAxiom

EntityEquivalenceAxiom is an Axiom specified on a subject Entity that states that it is equivalent to the intersection of Entities and/or PropertyRestrictionAxioms. This axiom implies that the entities are super types of the subject entity. It also implies that when an instance is classified by this intersection, then it follows that it is also classified by the subject entity. Conversely, when an instance is classified by the subject entity, then it follows that it is also classified by the intersection. In other words, this axiom enables bi-directional (or two-way) inferencing.

Super classes	Axiom
Properties	superEntities : Entity [] The super entity specified by this axiom ownedPropertyRestrictions : PropertyRestrictionAxiom [] The property restrictions specified by this axiom owningEntity : Entity [0..1] The owning entity specified by this axiom

6.8.3. InstanceEnumerationAxiom

InstanceEnumerationAxiom is an Axiom specified on a Concept that states that it classifies an enumerated set of instances.

Super classes	Axiom
Properties	instances : ConceptInstance [*] The set of enumerated instances specified by this axiom owningConcept : Concept [0..1] The owning concept specified by this axiom

6.8.4. KeyAxiom

KeyAxiom is an Axiom that specifies that a set of properties form a unique key for an entity. This means that all instances of that entity must have unique values for those keys.

Super classes	Axiom
Properties	properties : Property [*] The set of key properties specified by this axiom owningEntity : Entity [0..1] The owning entity specified by this axiom

6.8.5. LiteralEnumerationAxiom

LiteralEnumerationAxiom is an Axiom specified on a Scalar that states that it classifies an enumerated set of Literals.

Super classes	Axiom
Properties	literals : Literal [*] The set of enumerated literals specified by this axiom owningScalar : Scalar [0..1] The owning scalar specified by this axiom

6.8.6. PropertyCardinalityRestrictionAxiom

PropertyCardinalityRestrictionAxiom is a PropertyRestrictionAxiom that restricts the cardinality of a property to an exact value, a minimum value or a maximum value. This restrictions can apply either to all values of the property in the restricting Entity, or only to those values classified by a specific subtype of the range.

Super classes	PropertyRestrictionAxiom
Properties	kind : CardinalityRestrictionKind [1] The kind of cardinality restriction specified by this axiom (default is exactly) cardinality : UnsignedInt [1] The value of the cardinality specified by this axiom (default is 1) range : Type [0..1] The optional restricted range specified by this axiom

6.8.7. PropertyEquivalenceAxiom

PropertyEquivalenceAxiom is an Axiom specified on a subject Property that states that it is equivalent to another property. This axiom implies that the equivalent properties are super properties of the subject property (and vice versa).

Super classes	Axiom
Properties	superProperty : Property [1] The super property specified by this axiom owningProperty : SpecializableProperty [0..1] The owning property specified by this axiom

6.8.8. PropertyRangeRestrictionAxiom

PropertyRangeRestrictionAxiom is a PropertyRestrictionAxiom that restricts the range of a property to a type that specializes the original range. This restrictions may apply to all or to some values of the property that have the restricting Entity as a domain.

Super classes	PropertyRestrictionAxiom
Properties	kind : RangeRestrictionKind [1] The range restriction kind specified by this axiom (default is all) range : Type [1] The restricted range specified by this axiom

6.8.9. PropertyRestrictionAxiom

PropertyRestrictionAxiom is an Axiom specified on a Entity that places some restriction on the value of a SemanticProperty in the context of the entity.

Super classes	Axiom
Sub classes	PropertyCardinalityRestrictionAxiom PropertyRangeRestrictionAxiom PropertySelfRestrictionAxiom PropertyValueRestrictionAxiom
Properties	property : SemanticProperty [1] The restricted property specified by this axiom owningEntity : Entity [0..1] The owning entity specified by this axiom owningAxiom : EntityEquivalenceAxiom [0..1] The owning entity equivalence axiom specified by this axiom

6.8.10. PropertySelfRestrictionAxiom

PropertySelfRestrictionAxiom is a PropertyRestrictionAxiom that restricts a property in a given domain to be related to itself only.

Super classes	PropertyRestrictionAxiom

6.8.11. PropertyValueRestrictionAxiom

PropertyValueRestrictionAxiom is a PropertyRestrictionAxiom that restricts a property in a given domain to a specific value. The value is either a literal value, a contained AnonymousInstance value, or a referenced (NamedInstance value.

Super classes	PropertyRestrictionAxiom
Properties	literalValue : Literal [0..1] A restricted literal value containedValue : AnonymousInstance [0..1] A restricted contained value referencedValue : NamedInstance [0..1] A restricted referenced value

6.8.12. ScalarEquivalenceAxiom

ScalarEquivalenceAxiom is an Axiom specified on a subject Scalar that states that it is equivalent to another Scalar. When the equivalent scalar is one of the standard scalars (see {@link Scalar}), the equivalence may specify some restriction facets. The applicable facets depend on the restricted standard scalar (see below).

This axiom implies that the subject scalar is a subtype of the equivalent scalar. When there are no facets specified, then it also implies that the equivalent scalar is also a subtype of the subject scalar.

The following is the set of allowed facets for each standard scalar:

Numeric scalars (facets: minInclusive, maxInclusive, minExclusive, maxExclusive, literals): Time scalars (facets: minInclusive, maxInclusive, minExclusive, maxExclusive, literals): Plain scalars (facets: length, minLength, maxLength, pattern, language, literals): String scalars (facets: length, minLength, maxLength, pattern, literals) Binary scalars (facets: length, minLength, maxLength, literals):

Super classes

Axiom

Properties

superScalar : Scalar [1]
The super scalar specified by this axiom
owningScalar : Scalar [1]
The owning scalar specified by this axiom
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.8.13. SpecializationAxiom

SpecializationAxiom is an Axiom specified on a SpecializableTerm that states that it specializes another Term.

Super classes	Axiom
Properties	superTerm : Term [1] The super term specified by this axiom owningTerm : SpecializableTerm [0..1] The owning term specified by this axiom

6.9. Descriptions

6.9.1. Description

Description is a description box whose statements specify instances in a given system.

Super classes	DescriptionBox
Properties	ownedStatements : DescriptionStatement [*] The set of statements contained by this description

6.9.2. DescriptionBox

DescriptionBox is the supertype of Description and DescriptionBundle.

Super classes	Ontology
Sub classes	Description DescriptionBundle

6.9.3. DescriptionBundle

DescriptionBundle is a description box that closes the world on its imported descriptions by considering their instances and their assertions to be the only ones available.

Super classes	DescriptionBox

6.9.4. DescriptionMember

DescriptionMember is a member of a description.

Super classes	Member
Sub classes	DescriptionStatement

6.9.5. DescriptionStatement

DescriptionStatement is a statement owned by a description.

Super classes	DescriptionMember Statement
Sub classes	NamedInstance
Properties	owningDescription : Description [1] The description that owns this statement

6.10. Instances

6.10.1. AnonymousConceptInstance

AnonymousConceptInstance is an AnonymousInstance that is typed by a Concept or an Aspect.

Super classes	AnonymousInstance
Properties	type : Entity [0..1] The type of this instance

6.10.2. AnonymousInstance

AnonymousInstance is an Instance that is anonymous and can be owned by a PropertyValueAssertion or PropertyValueRestrictionAxiom.

Super classes	Instance
Sub classes	AnonymousConceptInstance AnonymousRelationInstance
Properties	owningAssertion : PropertyValueAssertion [0..1] The property value assertion that owns this instance as a value owningAxiom : PropertyValueRestrictionAxiom [0..1] The property value restriction axiom that assigns this instance as a restricted value

6.10.3. AnonymousRelationInstance

AnonymousRelationInstance is an AnonymousInstance of a RelationEntity that reifies the forward or reverse relation referenced by the owning assertion or axiom. The anonymous relation instances specifies a target instance. The source is assumed to be either the instance that owns the owningAssertion, or any instance typed by the owningAxiom’s restricted entity.

Super classes	AnonymousInstance
Properties	target : NamedInstance [1] An instance that is the target of this relation instance

6.10.4. ConceptInstance

ConceptInstance is a NamedInstance that can be typed by Concepts or Aspects.

Super classes	NamedInstance
Properties	ref : ConceptInstance [0..1] A ref to another concept instance

6.10.5. Instance

Instance is an element that represents a instance of one or more Entities. It can assert a set of values for those entities' properties.

Super classes	Element
Sub classes	AnonymousInstance NamedInstance
Properties	ownedPropertyValues : PropertyValueAssertion [*] The property value assertions owned by this instance

6.10.6. NamedInstance

NamedInstance is an Instance that is a member of a description.

Super classes	DescriptionStatement Instance
Sub classes	ConceptInstance RelationInstance
Properties	ownedTypes : TypeAssertion [*] The types of this instance

6.10.7. RelationInstance

RelationInstance is a NamedInstance that can be typed by RelationEntities and represents a link from one or more NamedInstances as sources to one or more NamedInstances as targets.

Super classes	NamedInstance
Properties	ref : RelationInstance [0..1] A ref to another relation 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.11. Assertions

6.11.1. Assertion

Assertion is an element that characterizes an instance by specifying values of one of its properties.

Super classes	Element
Sub classes	PropertyValueAssertion TypeAssertion

6.11.2. PropertyValueAssertion

PropertyValueAssertion is an Assertion that specifies values for a property on an instance. The values are either literal values, contained AnonymousInstance values, or referenced NamedInstance values.

Super classes	Assertion
Properties	property : SemanticProperty [1] The property referenced by this assertion literalValues : Literal [] The literal values of this assertion containedValues : AnonymousInstance [] The contained values of this assertion referencedValues : NamedInstance [*] The referenced values of this assertion owningInstance : Instance [0..1] The instance that owns this assertion

6.11.3. TypeAssertion

TypeAssertion is an Assertion that specifies a type for a NamedInstance.

Super classes	Assertion
Properties	type : Entity [1] The type of the instance owning this assertion owningInstance : NamedInstance [0..1] The instance that owns this assertion

7. Public API

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

8. Common Libraries

The following are the common libraries expressed in OML 2 and their minimum versions:

Library	Min Version
core-vocabularies	4.0.0
metrologiy-vocabularies	6.0.0
provenance-vocabularies	3.0.0
imce-vocabularies	4.0.0

9. Mapping to OWL and SWRL

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.

10. Version Migration

The OML syntax and APIs have significantly changed from v1 to v2. This section summarizes these changes and provides guidance on migration.

Syntax Changes

In v1 ontologies, only a subset of details could be specified on a ref to a <Member>. In v2, (almost) all details can be specified on a ref. This widens significantly the ability to split statements about a member in different ontologies, which better supports the ability to federate and extend descriptions. This also means that (most of) the previously required details of members have been relaxed to be optional. For example:
```
ref relation entity R1 [
  from C1 // this adds C1 as another source of R1
]

ref scalar property name [
  domain Pet // this adds Pet as another domain of name
  functional // this adds the fsunctional flag
]
```
In v2 ontologies, an annotation have now specify a value that is either a literal (as before) or an IRI of a member (new capability). For example:
```
@rdfs:label "Aggregates" // literal
@rdfs:seeAlso base:Contains // reference to base:Contains
relation entity Aggregtes
```
In v2 vocabularies, the specialization axiom symbol :> has changed into < to better align with the semantics that a subclass is a subset of its superclass.
In v2 vocabularies (since v2.3), the restricts statement syntax does not have property kind (scalar property, structured property, and relation) keywords any longer. For example:
```
restricts all performs to mission:Function
```

In v2 vocabularies, it has been clarified that the restricts statements, which used to be placed with other details about a term between [], actually belong to the specialization axiom.

This has caused the general term syntax to change from:

Term ::=  NAME (< Specializations)? ([ Details? Restrictions? ])?
Specializations ::= REF (, REF)*

to:

Term ::=  NAME ([ Details ])? (< Specializations)?
Specializations ::= (REF (, REF)*)? ([ Restriction*])?

For example:

aspect A1 [
  key id // detail
] < A2

concept C1 [
  oneOf c11, c12, c13 // detail
] < C2, C3 [
  restricts all p1 to "abc"
]

concept C2 < C3, C4, C5 [
  restricts all p1 to "abc"
  restricts p2 to 2.0
]

relation entity R1 [ 
  from C1    // detail
  to A1     // detail
  forward r1  // detail
] < R2 [
  restricts some p2 to 2.0
]

scalar S1 [
  oneOf "abc", "xyz" // detail
] < S2

scalar property p1 [
  domain D1  // detail
  range R1   // detail
] < p2

In v2 vocabularies, a new equivalence axiom (=) has been added to the term syntax in addition to the specialization axiom (<). While a specialization axiom says that a term is a sub of another term, an equivalence axiom says that the term is both a sub and a super of another term. The general term’s syntax is now:

Term ::=  NAME ([ Details ])? (< Specializations)? (= Equivalences)?
Specializations ::= (REF (, REF)*)? ([ Restriction*])?
Equivalences ::= Equivalence (, Equivalance)*

In the case of classifiers, a single equivalence has the syntax:

Equivalence ::= (REF (& REF)*)? ([ Restriction*])  // equals the intersection of other named terms and restrictions

In the case of scalars and properties, a single equivalence has the syntax:

Equivalence ::= REF // equals another named term

For example:

// A pizza that has a spicy topping is classified as a spicy pizza
concept SpicyPizza = Pizza [
  restricts some hasTopping to SpicyTopping
]
// A woman that is married is classified as a married woman
aspect MarriedWoman = Married & Woman
// A string that has a particular pattern is an SSN
scalar ssn = xsd:string [
  pattern "[0-9]{3}-[0-9]{2}-[0-9]{4}"
]
// Saying food is spicy is the same as saying that it is hot and vice versa
scalar property isSpicy [
  domain Food
  range xsd:boolean
  functional
] = isHot

In v2 vocabularies, a concept or scalar enumeration can now be specified consistently with a oneOf statement in the the details between []. This also removes the special type enumerated scalar in v1 and retains only the scalar type.

For enumerated literals, the syntax has changed from:

EnumeratedScalar ::= enumerated scalar NAME [
  Literal (, Literal)*
]

Scalar ::= scalar NAME [
  (oneOf Literal (, Literal)*)?
  // other details ...
]

For enumerated concept instances, the syntax has changed from:

Concept ::= concept NAME [
  (enumerates REF (, REF)*)?
  // other details ...
]

Concept ::= concept NAME [
  (oneOf REF (, REF)*)?
  // other details ...
]

For example:

scalar RGB [
  oneOf "Red", "Green", "Blue" // literals
]

concept RockyPlanet [
  oneOf Mercury, Venus, Earth, Mars // instances
]

In v2 vocabularies, it has been clarified that scalar facets (e.g., length, pattern, etc.) do not belong to the scalar’s details between [], but rather to the new scalar equivalence axiom. This allows such facets to be specified on a per equivalence basis.

For example:
```
scalar ssn = xsd:string [
  pattern "[0-9]{3}-[0-9]{2}-[0-9]{4}"
]

scalar positiveReal = xsd:real [
  minInclusive 0
], xsd:real [
  maxInclusive 9999
]
```
In v2 vocabularies, a new (unreified) relation can now be specified as an alternative to a (refieid) relation entity. This supports cases where instances of the relation are not foreseen in descriptions. It also helps avoid synthesizing relation entity names when mapping vocabularies from other formats that do not natively support reified relations. The syntax of an unreified relation resembles closely that of a relation entity (except for the forward statement). The syntax of an unreieifed relation is (partially) as follows:
```
Relation ::= relation NAME ([
  from REF
  to REF
  (reverse NAME)? // notice there is no forward NAME statement
  // other details in a relation entity
])? // specialization and equivalence axioms to other relations
```
For example:
```
relation isHusbandOf [
  from Man
  to Woman
  reverse isWifeOf
]

relation entity IsTeacherOf [
  from Teacher
  to Student
  forward isTeacherOf
  reverse isStudentOf
]
```
In v2 vocabularies, an unreified relation can now be referenced anywhere other relations (like forward, reverse) can. This includes restriction statements (restricts REL_REF), specialization statements (< REL_REF), equivalence statements (= REL_REF), rule predicates (REL_REF(ARG1, ARG2)), assertion axioms (REL_REF TARGET_REF), etc. Also, a relation is a kind of property in v2, whereas a relation entity is a kind of type. Therefore, a relation cannot be a supertype of a relation entity (and vice versa). But, an unreified relation can have any relation (including forward and reverse) as a super relstion.
In v2 vocabularies, the from and to statements (of relations), as well as the domain and range statements (of properties), can now specify more than one type as a value (both on the original definition or on a ref of the member). The semantics of having multiple types is equivalent to the intersection of those types. This makes a value asserted as a subject (or object) of a property (or relation) to be classified by all the types at once.

For example:
```
// In a vocabulary
relation isBoxedIn [
  from Red, Ball
  to Box
]
relation isPetOf [
  from Cat, Dog
  to Person
]
// In a description
instance Ball1 [
  isBoxedIn Box1 // this will cause Ball1 to be classified by both Red and Ball
]
instance Tom [
  isPetOf Jack // this will cause Tom to be classified by both Cat and Dog
]
```
In v2 vocabularies, the symbol ^ separating rule predicates has changed to & to better reflect the AND semantics between predicates.

In v2 vocabularies, a new term builtIn has been added to define a builtin function that can be referenced by a rule antecedant predicate. A standard set of builtins has been added to the core-vocabularies library in the <http://www.w3.org/2003/11/swrlb#> vocabulary. Note that a custom builtIn function cannot be specified yet.

// in the "http://www.w3.org/2003/11/swrlb#" vocabulary
	 
@rdfs:comment "Satisfied iff the first argument is equal to the string ..."
builtin stringConcat

// in a vocabulary
	 
rule FullName [
    firstName(?x, ?first) & 
    lastName(?x, ?last) &
    swrlb:stringConcat(?full, ?first, " ", ?last) // builtins can only be referenced in antecedent
    -> fullName(?x, ?full)
]

In v2 descriptions, the symbol ci for a concept instance has now changed to the more readable instance. Also, such instances can also now be typed by both Concepts and Aspects (whereas only Concepts were the only valid types in v1).
In v2 descriptions, the symbol ri for a relation instance has now changed to the more readable relation instance. Also, such instances can also now be typed by both Relation Entities and Aspects (whereas only Relation Entities were the only valid types in v1).

API Changes

The above changes to the OML textual syntax have induced some changes to the OML Java API. Other changes were done done to simplify the API. The following is a list of main changes to the OML API:

Merged (and removed) class AnnotatedElement into class IdentifiedElement (the impact is that Import statements can no longer be annotated).
Collapsed the Import class hierarchy into a single Import class with an enumeration kind that has literals: extends, uses, and includes.
Renamed class Feature to Property, made the latter the supertype of classes AnnotatedProperty and SemanticProperty, and made class Relation extend from SemanticProperty.
Collapsed the Restriction class hierarchy into 3 subclasses restricting range, cardinality, or value of a property, and made class Entity has a single collection for restrictions.
Removed class LinkAssertion (replaced by PropertyValueAssertion) and made class NamedInstance has a single collection of property value assertions.
Moved the types collection (now of concrete type TypeAssertion) from both classes ConceptInstance and RelationInstance into their superclass NamedInstance.
Made class RelationEntityPredicate a subclass of both UniaryPredicate and BinaryPredicate.
Removed the Reference class hierarchy entirely and merged it into the Member class hierarchy (a member can have either a name or a ref to another member).

Migration Guide

Migrating OML v1 textual syntax to that of v2 can be done in a text editor using the following process:

Replace the symbol :> by <.
Replace the symbol ci by instance.
Replace the symbol ri by relation instance.
Replace the syntax keyword NAME < REFS [Details] by the syntax keyword NAME [Details] < REFs.
Replace the syntax keyword NAME [Restrictions] by the syntax keyword NAME < [Restrictions].
Replace the syntax keyword NAME < REFS [Details Restrictions] by the syntax keyword NAME [Details] < REFS [Restrictions].
Replace the syntax concept NAME [ enumerates REFS ] by the syntax concept NAME [ oneOf REFS ].
Replace the syntax enumerated scalar NAME < REFS [ LITERALS ] by the syntax scalar NAME [ oneOf LITERALS ].
Replace the syntax scalar NAME < REFS [ FACETS ] by the syntax scalar NAME = REFS [ FACETS ].

Migrating OML v1 XMI syntax for Descriptions to that of v2 can be done in a text editor using the following process:

Replace ConceptTypeAssertion by TypeAssertion.
Replace ScalarPropertyValueAssertion by PropertyValueAssertion.
Replace LinkAssertion by PropertyValueAssertion.
Replace <value by <literalValue.
Replace <ownedLinks by <ownedPropertyValues.
Replace <relation by <property.
Replace target= by referencedValue=.

Note: some of the above steps can be automated by the use of this script.

Ontological Modeling Language v2

Living Standard, 13 August 2024

Abstract

1. Document Organization

1.1. Document Conventions

1.2. BNF Conventions

2. Getting Started

2.1. OML Project

2.2. OML File

2.3. Catalog File

2.4. Build File

3. Language Reference

3.1. OML Idioms

3.1.1. White Space

3.1.2. Comment

3.1.3. Ontology

3.1.4. Import

3.1.5. Member

3.1.6. Reference

3.1.7. IRI

3.1.8. Literal

3.1.9. Annotation

3.2. Vocabulary

3.2.1. Import

3.2.1.1. Extension

3.2.1.2. Usage

3.2.2. Types

3.2.2.1. Aspect

3.2.2.2. Concept

3.2.2.3. Relation Entity

3.2.2.4. Scalar

3.2.3. Properties

3.2.3.1. Annotation Property

3.2.3.2. Scalar Property

3.2.3.3. Unreified Relation

3.2.4. Axioms

3.2.4.1. Key Axiom

3.2.4.2. Instance Enumeration Axiom

3.2.4.3. Literal Enumeration Axiom

3.2.4.4. Entity Specialization Axiom

3.2.4.5. Entity Equivalence Axiom

3.2.4.6. Scalar Specialization Axiom

3.2.4.7. Scalar Equivalence Axiom

3.2.4.8. Property Specialization Axiom

3.2.4.9. Property Equivalence Axiom

3.2.4.10. Property Value Restriction Axiom

3.2.5. BuiltIn

3.2.6. Rule

3.3. Description

3.3.1. Imports

3.3.1.1. Extension

3.3.1.2. Usage

3.3.2. Instances

3.3.2.1. Concept Instance

3.3.2.2. Relation Instance

3.3.2.3. Anonymous Concept Instance

3.3.2.4. Anonymous Relation Instance

3.3.3. Assertions

3.3.3.1. Property Value Assertion

3.4. Vocabulary Bundle

3.4.1. Imports

3.4.1.1. Extension

3.4.1.2. Inclusion

3.5. Description Bundle

3.5.1. Imports

3.5.1.1. Extension

3.5.1.2. Usage

3.5.1.3. Inclusion

4. Textual BNF

5. Graphical BNF

6. Abstract-Syntax

6.1. Elements

6.1.1. Annotation

6.1.2. Element

6.1.3. IdentifiedElement

6.1.4. Import

6.1.5. ImportKind

6.1.6. Member

6.1.7. Ontology

6.1.8. SeparatorKind