Ontological Modeling Language v2

Living Standard,

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

Abstract

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

1. Document Organization

This document 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.

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:

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:

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:

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:

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:

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
}

ID

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

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

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

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

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

3.1.8. Literal

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

Quoted Literal

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

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

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

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

Examples of quoted literals with different delimiters:

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

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

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

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

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

Abbreviated Literal

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

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

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

3.1.9. Annotation

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

An Annotation describes a value for an annotation property (defined by a vocabulary) in the context of 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 an optional (literal or member reference) value. If the value is missing, it is interpreted as a boolean true literal.

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

The following example shows several annotations. The ontology itself has a dc:title annotation as well as a dc:date annotation (notice how the value is a xsd:date literal). The 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
    @rdfs:comment "C’est member1"$fr
  @rdfs:seeAlso example2:Member2
    <member> Member1
    @viewpoint:show  // a missing literal is interpreted as Boolean true literal
    ref <member> example2:Member2
}

3.2. Vocabulary

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

Annotation*
vocabulary NAMESPACE as ID {
  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 classifiers (structured types) or scalars (primitive types). Some classifiers (Aspect, Concept and Relation Entity) are entities, meaning they can classify named instances (that are unique by reference). Other classifiers (Structure) can only classify anonymous instances (that are unique by value). Also, scalars (Scalar) can 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 ClassifierSpecializationAxiom, and an optional ClassifierEquivalenceAxiom, using the following syntax:

  Annotation*
(aspect ID | ref aspect [Aspect|Ref]) ([
  (KeyAxiom)* 
])? (ClassifierSpecializationAxiom)? (ClassifierEquivalenceAxiom)?

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 ClassifierSpecializationAxiom and an optional ClassifierEquivalenceAxiom, using the following syntax.

  Annotation*
(concept ID | ref concept [Concept|IRI]) ([
  (KeyAxiom)* 
  (InstanceEnumerationAxiom)?
])? (ClassifierSpecialization)? (ClassifierEquivalence)?

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 ClassifierSpecializationAxiom and an optional ClassifierEquivalenceAxiom, 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)*
])? (ClassifierSpecialization)? (ClassifierEquivalence)?

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

A structure is a classifier defined in a vocabulary and represents a structured datatype with anonymous instances in a modeled domain. A structure is declared with the keyword structure followed by an ID. An existing (local or imported) structure can be referenced by the keywords ref structure followed by its IRI. Moreover, a structure can be followed by an optional ClassifierSpecializationAxiom and an optional ClassifierEquivalenceAxiom, using the following syntax.

Annotation*
(structure ID | ref structure [Structure|IRI])
(ClassifierSpecialization)? (ClassifierEquivalence)?

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

vocabulary <http://com.xyz/methodology/mission#> as mission {
     structure Point
}
3.2.2.5. 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, Structured Property) or UnreifiedRelation) has logical semantics and is specified with one or more domains representing classifiers (or entities in the case of a relation) 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 classifiers (Aspects, Concepts, Relation Entities, or Structures) 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 classifiers 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 [Classifier|IRI] (, [Classifier|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. Structured Property

A structured property is a semantic property defined in a vocabulary, whose domains can be classifiers (Aspects, Concepts, Relation Entities, or Structures) and whose ranges can be (Structures. This means the values of a structured property are instances of those structures. A stuctured property is defined with the keywords structured property followed by a name ID. An existing (local or imported) structured property can be referenced by the keywords ref structured property followed by its IRI. It can also specify between a pair of [ ] brackets optional domain classifiers and optional range structures 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 instance of its ranges. The property can also be followed an optional PropertySpecializationAxiom and an optional PropertyEquivalenceAxiom, using the following syntax:

Annotation*
(structured property ID | ref structured property [StructuredProperty|IRI]) ([
  (domain [Classifier|IRI] (, [Classifier|IRI])*)?
  (range [Structure|IRI] (, [Structure|IRI])*)?
  (functional)?
])? (PropertySpecialization)? (PropertyEquivalence)?

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

vocabulary <http://com.xyz/methodology/graphics#> as graphics {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    concept Shape
    structure Point
    structured property hasLocation [
        domain Shape
        range Point
        functional
    ]
    scalar property hasX [
        domain Point
        range xsd:int
        functional
    ]
    scalar property hasY [
        domain Point
        range xsd:int
        functional
    ]
}
3.2.3.4. 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 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. Classifier Specialization Axiom

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

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

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

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

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

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

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. Classifier Equivalence Axiom

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

= ClassifierEquivalenceAxiom (, ClassifierEquivalenceAxiom)*

<ClassifierEquivalenceAxiom>:
  [Classifier|IRI] (& [Classifier|IRI])*
  |
  ([Classifier|IRI] (& [Classifier|IRI])*)? [
    PropertyRestrictionAxiom*
  ]

Examples of using Classifier 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 classifier A is equivalent to B is like saying that A specializes B and B specializes A. Therefore, the semantic of classifier specialization described for [=ClassifierSpecializationAxiom] 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 Classifiers 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 Classifiers and/or PropertyRestrictionAxioms, in which case some of the equivalent classifiers 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):

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 a classifier (Aspect, Concept, Relation Entity and Structure) that restricts a semantic property in some way in the classifier’s context. This property can be (Scalar Property, Structured 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.

Note: a structure can specify property value restriction axioms only on scalar and structures properties, but not relations (forward, reverse, or unreified) since a structure cannot be a source (domain) or target (range) of a relation.

Property Range Restriction Axioms

A range restriction axiom restricts the range of a property in the context of some classifier. 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, structured 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, a structure, or an entity) by IRI. The following shows the three supported syntaxes:

restricts [ all | some ] [ScalarProperty|IRI] to [Scalar|IRI]
restricts [ all | some ] [StructuredProperty|IRI] to [Structure|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
    ]
    structure Pin
    structure InputPin < Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    structured property hasPin [
        domain Component
        range Pin
        functional
   ]
}

Property Cardinality Restriction Axioms

A cardinality restriction axiom restricts the cardinality of a property in the context of some classifier. The axiom specifies a minimum, a maximum, or an exact number of values, conforming to the original range, or to a specified restricted range, that a 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, structured 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, a structure, or an entity) by IRI. The following shows the three supported syntaxes:

restricts [ScalarProperty|IRI] to [ max | min | exactly ] UnsignedInteger [Scalar|IRI]?
restricts [StructuredProperty|IRI] to [ max | min | exactly ] UnsignedInteger [Structure|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
    ]
    structure Pin
    structure InputPin < Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    structured property hasPin [
        domain Component
        range Pin
        functional
   ]
}

Property Value Restriction Axioms

A value restriction axiom restricts the value of a property in the context of some classifier. In the case of a relation, the restricted value represents the relation’s target instance. The syntax of a value restriction axioms starts with the keyword restricts followed by 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 for a scalar property, a structure instance for a structured property, or a reference to a named instance by IRI for a relation). The following shows the three supported syntaxes:

restricts [ScalarProperty|IRI] to Literal
restricts [StructuredProperty|IRI] to StructureInstance
restricts [Relation|IRI] to [NamedInstance|IRI]

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

vocabulary <http://com.xyz/methodology/mission#> as mission {
    extends <http://www.w3.org/2001/XMLSchema#> as xsd
    uses <http://com.xyz/methodology/functions#> as functions
    concept Component
    concept Function
    concept Assembly < Component [
        restricts 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
    ]
    structure Pin
    relation entity Performs [
        from Component
        to Function
        forward performs
        reverse isPerformedBy
   ]
    scalar property hasId [
        domain Component
        range xsd:string
        functional
   ]
    structured property hasPin [
        domain Component
        range Pin
        functional
   ]
    scalar property hasNumber [
        domain Pin
        range xsd:int
        functional
   ]
}

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

Property Self Restriction Axioms

A self restriction axiom restricts the value of a relation in the context of some classifier 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).

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

    ci 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

    ci 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 (Structure Instance), in which case they defined as values of properties (e.g., structured properties) in the context of other (named or anonymous) instances.

3.3.2.1. Concept Instance

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

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

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

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

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

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*
ri ID (: [RelationEntity|IRI] (, [RelationEntity|IRI])*)? [
  from [NamedInstance|IRI] (, [NamedInstance|IRI])* 
  to [NamedInstance|IRI] (, [NamedInstance|IRI])*
  Assertion*
]

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

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

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

[Structure|IRI] [
  Assertion*
]

The following example shows .

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

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

3.3.3. Assertions

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

3.3.3.1. Property Value Assertion

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

[ScalarProperty|IRI] Literal
[StructuredProperty|IRI] StuctureInstance
[Relation|IRI] [NamedInstance|IRI]

Note: a structure instance can specify property value assertion only for scalar and structures properties, but not relations (forward, reverse, or unreified) since a structure cannot be a source (domain) or target (range) of a relation.

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 structured property as a structure 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
    ci component1 : mission:Component [
        mission:hasId 'C1'                      // scalar property value assertion
        mission:hasPin Pin [ mission:hasNumber 2 ]      // structure property value assertion
        mission:performs function1                // relation value assertion
    ]
    ci 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])?

<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 |
  StructuredProperty |
  UnreifiedRelation

<Type>:
  Classifier |
  Scalar  

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

<Aspect>:
  Annotation*
  (aspect ID | ref aspect [Aspect|IRI]) ([
    (KeyAxiom)* 
  ])? (ClassifierSpecialization)? (ClassifierEquivalence)?

<Concept>:
  Annotation*
  (concept ID | ref concept [Concept|IRI]) ([
    (InstanceEnumerationAxiom)?
    (KeyAxiom)* 
  ])? (ClassifierSpecialization)? (ClassifierEquivalence)?
	
<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)*
  ])? (ClassifierSpecialization)? (ClassifierEquivalence)?
	
<Structure>:
  Annotation*
  (structure ID | ref structure [Structure|IRI])
    (ClassifierSpecialization)? (ClassifierEquivalence)?

<ClassifierSpecialization>:
  < (Classifier (, Classifier)* 
    |
    (Classifier (, Classifier)*)? [
      PropertyRestrictionAxiom*
    ])

<ClassifierEquivalence>:
  = ClassifierEquivalenceAxiom (, ClassifierEquivalenceAxiom)*

<ClassifierEquivalenceAxiom>:
  [Classifier|IRI] (& [Classifier|IRI])*
  |
  {ClassifierEquivalenceAxiom} 
  ([Classifier|IRI] (& [Classifier|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 |
  StructuredProperty |
  Relation

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

<StructuredProperty>:
  Annotation*
  (structured property ID | ref structured property [StructuredProperty|IRI]) ([
    (domain [Classifier|IRI] (, [Classifier|IRI])*)?
    (range [Structure|IRI] (, [Structure|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])

<StructureInstance>:  
  [Structure|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 | StructureInstance | [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 | StructureInstance | [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>: 
  DIGIT+

<INTEGER_STR>: 
  (+|-)? DIGIT+

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

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

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

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

<IRI>: 
  ID | REF

<REF>:
  FULL_IRI | ABBREVIATED_IRI

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

<ABBREVIATED_IRI>: 
  ID : ID

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

<ALPHA>: 
  a..z | A..Z

<DIGIT>: 
  0..9

5. Graphical BNF

Convensions

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

Concept:

        

Aspect:

        

Structure:

        

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

Annotation property : AnnotationProperty [1] referencedValue : Member [0..1] owningElement : IdentifiedElement [0..1] Literal Element IdentifiedElement Import kind : ImportKind namespace : Namespace prefix : ID owningOntology : Ontology [1] ImportKind extension usage inclusion Member name : ID Ontology namespace : Namespace prefix : ID SeparatorKind hash slash Statement literalValue 0..1 ownedAnnotations * ownedImports *

6.1.1. Annotation

Annotation is an element that specifies non-semantic information on an IdentifiedElement. An annotation is specified with an AnnotationProperty and an optional Literal or Member (referenced) value. When no value is specified, the boolean literal true is assumed to be specified.
Super classes
Properties
  • property : AnnotationProperty [1]

    The annotation property specified by this annotation

  • literalValue : Literal [0..1]

    The literal value specified by this annotation

  • referencedValue : Member [0..1]

    The referenced value (of a member) 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

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
Sub classes
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:
Super classes
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
Sub classes
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
Sub classes
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
Sub classes

6.2. Literals

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

6.2.1. BooleanLiteral

BooleanLiteral is a literal that represents the boolean values true and false.
Super classes
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
Properties
  • value : Decimal [1]

    The decimal value of this literal

6.2.3. DoubleLiteral

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

    The double value of this literal

6.2.4. IntegerLiteral

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

    The int value of this literal

6.2.5. Literal

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

6.2.6. QuotedLiteral

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

    The value of this literal represented as a string

  • langTag : String [0..1]

    The langTag of this literal

  • type : Scalar [0..1]

    The scalar that is the type of this literal

6.3. Vocabularies

BuiltIn ref : BuiltIn [0..1] VocabularyStatement owningVocabulary : Vocabulary [1] Rule ref : Rule [0..1] Predicate SpecializableTerm SpecializationAxiom Term VocabularyMember Vocabulary VocabularyBox Ontology VocabularyBundle Member Statement antecedent * consequent * ownedSpecializations * ownedStatements *

6.3.1. BuiltIn

BuiltIn is a member of a vocabulary that represents a builtin function
Super classes
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
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
Sub classes
Properties

6.3.4. Term

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

6.3.5. Vocabulary

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

6.3.6. VocabularyBox

VocabularyBox is the supertype of Vocabulary and VocabularyBundle.
Super classes
Sub classes

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

6.3.8. VocabularyMember

VocabularyMember is a member of a vocabulary.
Super classes
Sub classes

6.3.9. VocabularyStatement

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

    The vocabulary that owns this statement

6.4. Types

Aspect ref : Aspect [0..1] Entity Classifier ClassifierEquivalenceAxiom PropertyRestrictionAxiom Type Concept ref : Concept [0..1] InstanceEnumerationAxiom KeyAxiom Scalar ref : Scalar [0..1] LiteralEnumerationAxiom ScalarEquivalenceAxiom Structure ref : Structure [0..1] SpecializableTerm ownedEquivalences * ownedPropertyRestrictions * ownedEnumeration 0..1 ownedKeys * ownedEnumeration 0..1 ownedEquivalences *

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
Properties
  • ref : Aspect [0..1]

    A ref to another aspect

6.4.2. Classifier

Classifier is a type that classifies a set of instances and characterizes them with properties (where it becomes a domain of these properties). it can also own a set of PropertyRestrictionAxioms as well as set of ClassifierEquivalenceAxioms.
Super classes
Sub classes
Properties

6.4.3. 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
Properties

6.4.4. Entity

Entity is a classifier whose instances are NamedInstances. It can also specify a set of KeyAxioms.
Super classes
Sub classes
Properties
  • ownedKeys : KeyAxiom [*]

    The unique keys of this entity

6.4.5. 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
Properties

6.4.6. Structure

Structure is a classifier whose instances are anonymous and assignable as values to StructuredProperties.
Super classes
Properties
  • ref : Structure [0..1]

    A ref to another structure

6.4.7. Type

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

6.5. Properties

AnnotationProperty ref : AnnotationProperty [0..1] SpecializableProperty CardinalityRestrictionKind exactly min max Property Term RangeRestrictionKind all some Relation SemanticProperty ScalarProperty functional : Boolean ref : ScalarProperty [0..1] domains : Classifier [*] ranges : Scalar [*] SpecializableTerm PropertyEquivalenceAxiom StructuredProperty functional : Boolean ref : StructuredProperty [0..1] domains : Classifier [*] ranges : Structure [*] ownedEquivalences *

6.5.1. AnnotationProperty

AnnotationProperty is a SpecializableProperty with no DL semantics.
Super classes
Properties

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
Sub classes

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
Sub classes

6.5.6. ScalarProperty

ScalarProperty is a SemanticProperty whose range is a Scalar. It can specialize other ScalarProperties.
Super classes
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 : Classifier [*]

    The classifier 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 classifier acting as its domain to a type acting as its range.
Super classes
Sub classes

6.5.8. SpecializableProperty

SpecializableProperty is a property that can be specialized. It can also specify PropertyEquivalenceAxioms.
Super classes
Sub classes
Properties

6.5.9. StructuredProperty

StructuredProperty is a SemanticProperty whose range is a Structure. It can specialize other StructuredProperties.
Super classes
Properties
  • ref : StructuredProperty [0..1]

    A ref to another structured property

  • functional : Boolean [0..1]

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

  • domains : Classifier [*]

    The classifiers that are the domains of this property

  • ranges : Structure [*]

    The structures that are the range of this property

6.6. Relations

ForwardRelation relationEntity : RelationEntity [1] Relation RelationBase functional : Boolean inverseFunctional : Boolean symmetric : Boolean asymmetric : Boolean reflexive : Boolean irreflexive : Boolean transitive : Boolean sources : Entity [*] targets : Entity [*] SpecializableTerm ReverseRelation relationBase : RelationBase [1] RelationEntity ref : RelationEntity [0..1] Entity UnreifiedRelation ref : Relation [0..1] SpecializableProperty reverseRelation 0..1 forwardRelation 0..1

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
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 whose domain is the target and whose range is the source. Such relation can only be specified on a relation base definition not a ref to an existing one. 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
Sub classes
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
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
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
Properties
  • ref : Relation [0..1]

    A ref to another relation

6.7. Predicates

Argument variable : ID instance : NamedInstance [0..1] Element Literal BinaryPredicate Predicate antecedentRule : Rule [0..1] consequentRule : Rule [0..1] BuiltInPredicate builtIn : BuiltIn [1] DifferentFromPredicate PropertyPredicate property : Property [1] RelationEntityPredicate type : RelationEntity [1] UnaryPredicate SameAsPredicate TypePredicate type : Type [1] literal 0..1 argument1 1 argument2 1 arguments * argument 1

6.7.1. Argument

Argument is an element that represents a variable name, a Literal, or an NamedInstance specified in a predicate.
Super classes
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
Sub classes
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
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

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
Sub classes
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
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
Properties

6.7.8. SameAsPredicate

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

6.7.9. TypePredicate

TypePredicate is a UnaryPredicate whose argument is bound to a value typed by a given type.
Super classes
Properties
  • type : Type [1]

    The type of a value

6.7.10. UnaryPredicate

UnaryPredicate is a Predicate that has one argument.
Super classes
Sub classes
Properties
  • argument : Argument [1]

    An argument of the predicate

6.8. Axioms

Axiom Element ClassifierEquivalenceAxiom superClassifiers : Classifier [*] owningClassifier : Classifier [0..1] PropertyRestrictionAxiom property : SemanticProperty [1] owningClassifier : Classifier [0..1] owningAxiom : ClassifierEquivalenceAxiom [0..1] InstanceEnumerationAxiom instances : ConceptInstance [*] owningConcept : Concept [0..1] KeyAxiom properties : Property [*] owningEntity : Entity [0..1] LiteralEnumerationAxiom owningScalar : Scalar [0..1] Literal PropertyCardinalityRestrictionAxiom kind : CardinalityRestrictionKind cardinality : UnsignedInt range : Type [0..1] PropertyEquivalenceAxiom superProperty : Property [1] owningProperty : SpecializableProperty [0..1] PropertyRangeRestrictionAxiom kind : RangeRestrictionKind range : Type [1] PropertySelfRestrictionAxiom PropertyValueRestrictionAxiom referencedValue : NamedInstance [0..1] StructureInstance ScalarEquivalenceAxiom length : UnsignedInteger minLength : UnsignedInteger maxLength : UnsignedInteger pattern : String language : String superScalar : Scalar [1] owningScalar : Scalar [1] SpecializationAxiom superTerm : Term [1] owningTerm : SpecializableTerm [0..1] ownedPropertyRestrictions * literals * literalValue 0..1 containedValue 0..1 minInclusive 0..1 minExclusive 0..1 maxInclusive 0..1 maxExclusive 0..1

6.8.1. Axiom

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

6.8.2. ClassifierEquivalenceAxiom

ClassifierEquivalenceAxiom is an Axiom specified on a subject Classifier that states that it is equivalent to the intersection of Classifiers and/or PropertyRestrictionAxioms. This axiom implies that the classifiers are super types of the subject classifier. It also implies that when an instance is classified by this intersection, then it follows that it is also classified by the subject classifier. Conversely, when an instance is classified by the subject classifier, 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
Properties
  • superClassifiers : Classifier [*]

    The super classifiers specified by this axiom

  • ownedPropertyRestrictions : PropertyRestrictionAxiom [*]

    The property restrictions specified by this axiom

  • owningClassifier : Classifier [0..1]

    The owning classifier 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
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
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
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 classifier, or only to those values classified by a specific subtype of the range.
Super classes
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
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 classifier as a domain.
Super classes
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 Classifier that places some restriction on the value of a SemanticProperty in the context of the classifier.
Super classes
Sub classes
Properties
  • property : SemanticProperty [1]

    The restricted property specified by this axiom

  • owningClassifier : Classifier [0..1]

    The owning classifier specified by this axiom

  • owningAxiom : ClassifierEquivalenceAxiom [0..1]

    The owning classifier 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

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 in the case of a ScalarProperty, a contained StructureInstance value in the case of a StructuredProperty, or a referenced (NamedInstance value in the case of a Relation.
Super classes
Properties
  • literalValue : Literal [0..1]

    A restricted literal value (of a scalar property)

  • containedValue : StructureInstance [0..1]

    A restricted contained value (of a structured property)

  • referencedValue : NamedInstance [0..1]

    A restricted referenced value (of a relation)

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

Description DescriptionBox DescriptionStatement owningDescription : Description [1] Ontology DescriptionBundle DescriptionMember Member Statement ownedStatements *

6.9.1. Description

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

6.9.2. DescriptionBox

DescriptionBox is the supertype of Description and DescriptionBundle.
Super classes
Sub classes

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

6.9.4. DescriptionMember

DescriptionMember is a member of a description.
Super classes
Sub classes

6.9.5. DescriptionStatement

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

    The description that owns this statement

6.10. Instances

ConceptInstance ref : ConceptInstance [0..1] NamedInstance Instance Element PropertyValueAssertion DescriptionStatement TypeAssertion RelationInstance ref : RelationInstance [0..1] sources : NamedInstance [*] targets : NamedInstance [*] StructureInstance type : Structure [1] owningAxiom : PropertyValueRestrictionAxiom [0..1] owningAssertion : PropertyValueAssertion [0..1] ownedPropertyValues * ownedTypes *

6.10.1. ConceptInstance

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

6.10.2. Instance

Instance is an element that represents a instance of one or more classifiers. It can assert a set of values for those classifiers' properties.
Super classes
Sub classes
Properties

6.10.3. NamedInstance

NamedInstance is an Instance that is a member of a description.
Super classes
Sub classes
Properties

6.10.4. 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
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.10.5. StructureInstance

StructureInstance is an Instance that can be typed by a Structure. It is anonymous and gets assigned as a value of a StructuredProperty either in a PropertyValueRestrictionAxiom or a PropertyValueAssertion.
Super classes
Properties
  • type : Structure [1]

    The type of this instance

  • owningAxiom : PropertyValueRestrictionAxiom [0..1]

    The property value restriction axiom that assigns this instance as a restricted value

  • owningAssertion : PropertyValueAssertion [0..1]

    The property value assertion that assigns this instance as a value

6.11. Assertions

Assertion Element PropertyValueAssertion property : SemanticProperty [1] referencedValue : NamedInstance [0..1] owningInstance : Instance [0..1] Literal StructureInstance TypeAssertion type : Entity [1] owningInstance : NamedInstance [0..1] literalValue 0..1 containedValue 0..1

6.11.1. Assertion

Assertion is an element that characterizes an instance by specifying the value of one of its properties.
Super classes
Sub classes

6.11.2. PropertyValueAssertion

PropertyValueAssertion is an Assertion that specifies a value for a property on an instance. The value is either a literal value in the case of a ScalarProperty, a contained StructureInstance value in the case of a StructuredProperty, or a referenced NamedInstance value in the case of a Relation.
Super classes
Properties
  • property : SemanticProperty [1]

    The property referenced by this assertion

  • literalValue : Literal [0..1]

    An asserted literal value of a scalar property

  • containedValue : StructureInstance [0..1]

    An asserted contained value of a structured property

  • referencedValue : NamedInstance [0..1]

    An asserted referenced value of a relation

  • owningInstance : Instance [0..1]

    The instance that this property value assertion is about

6.11.3. TypeAssertion

TypeAssertion is an Assertion that specifies a type for a NamedInstance.
Super classes
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

  1. 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
    ]
    
  2. 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
    
  3. 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.

  4. 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
    
  5. 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
    
  6. 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
    
  7. 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)*
    ]
    

    to

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

    to

    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
    ]
    
  8. 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
    ]
    
  9. 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
    ]
    
  10. 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.

  11. 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
    ]
    
  12. In v2 vocabularies, the symbol ^ separating rule predicates has changed to & to better reflect the AND semantics between predicates.

  13. 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)
    ]
    
  14. 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).

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

  1. Merged (and removed) class AnnotatedElement into class IdentifiedElement (the impact is that Import statements can no longer be annotated).

  2. Collapsed the Import class hierarchy into a single Import class with an enumeration kind that has literals: extends, uses, and includes.

  3. Renamed class Feature to Property, made the latter the supertype of classes AnnotatedProperty and SemanticProperty, and made class Relation extend from SemanticProperty.

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

  5. Removed class LinkAssertion (replaced by PropertyValueAssertion) and made class NamedInstance has a single collection of property value assertions.

  6. Moved the types collection (now of concrete type TypeAssertion) from both classes ConceptInstance and RelationInstance into their superclass NamedInstance.

  7. Made class RelationEntityPredicate a subclass of both UniaryPredicate and BinaryPredicate.

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

  1. Replace the symbol :> by <.

  2. Replace the symbol ci by instance.

  3. Replace the symbol ri by relation instance.

  4. Replace the syntax keyword NAME < REFS [Details] by the syntax keyword NAME [Details] < REFs.

  5. Replace the syntax keyword NAME [Restrictions] by the syntax keyword NAME < [Restrictions].

  6. Replace the syntax keyword NAME < REFS [Details Restrictions] by the syntax keyword NAME [Details] < REFS [Restrictions].

  7. Replace the syntax concept NAME [ enumerates REFS ] by the syntax concept NAME [ oneOf REFS ].

  8. Replace the syntax enumerated scalar NAME < REFS [ LITERALS ] by the syntax scalar NAME [ oneOf LITERALS ].

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

  1. Replace ConceptTypeAssertion by TypeAssertion.

  2. Replace ScalarPropertyValueAssertion by PropertyValueAssertion.

  3. Replace LinkAssertion by PropertyValueAssertion.

  4. Replace <value by <literalValue.

  5. Replace <ownedLinks by <ownedPropertyValues.

  6. Replace <relation by <property.

  7. Replace target= by referencedValue=.

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

Index

Terms defined by this specification