A mapping of ISO 15926-2 in EXPRESS to OWL

Status of this document: Working draft

This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.


  • Martin G. Skjæveland, DNV
  • Johan W. Klüwer, DNV


  1. Abstract
  5. ONE OF
  6. EXPRESS attributes
    1. Attribute value = Entity
    2. Attribute value = EXPRESS datatype
    3. Mapping of EXPRESS datatypes to XSD datatypes
  8. WHERE
  10. ANDOR


This article describes a mapping of selected EXPRESS constructs to OWL 1.0 DL needed to translate the EXPRESS file lifecycle_integration_schema.exp downloaded from http://www.tc184-sc4.org/EXPRESS/ which ISO 15926-2 (2003) annex B references, to an XML serialization of OWL. The result of this translation is the file http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003

Note: The EXPRESS file is a computer-interpretable of ISO 15926-2 and therefore a good starting-point for an OWL representation of ISO 15926-2, but it does not capture all the information in the ISO 15926-2 (2003) pdf document, which is the normative definition of ISO 15926-2 (2003). Examples of what the EXPRESS file does not include is that instances of the entity abstract_object should be classified by a member of the entity class_of_abstract_object, and that classification (relation) is not transitive.

Note: In the code snippets of OWL in this document we use the Manchester syntax, while the file http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003 is expressed using RDF/XML. We have chosen Manchester syntax because it is much more compact and readable, and RDF/XML in the OWL implementation as this is a W3C Recommendation and likely to be supported by every implementation.

The EXPRESS constructs used in the EXPRESS implementation of the ISO 15926-2:


EXPRESS entities (EXPRESS word: ENTITY) are translated to owl:Class. Names are translation from '_'-divided words to UpperCamelCase.


The entity class_of_abstract_object is translated to an owl:class.

  ENTITY class_of_abstract_object 

translates to

  Class: ClassOfAbstractObject

Note: The EXPRESS file defines 201 ENTITYs. All these are translated to owl:Class. This includes e.g. the entities specialization and classification.


Abstract EXPRESS entities (EXPRESS word: ABSTRACT) are translated to OWL by declaring the class which represents the abstract entity equivalent (owl:equivalentClass) to the union (owl:unionOf) of all its immediate subclasses (rdfs:subClassOf).

The concept "abstract class" does not exist in OWL, so there is no one-to-one translation. However, we are able to translate large parts of the intended meaning of the construct to OWL. In EXPRESS an abstract entity means that the entity may not have any "direct" instances:

EXPRESS allows for the declaration of supertypes that are not intended to be directly instantiated. An entity data type shall include the phrase abstract supertype in a supertype constraint for this purpose. An abstract supertype shall not be instantiated except in conjunction with at least one of its subtypes. (ISO 10303-11, p. 56)

An EXPRESS entity data type is abstract if every instance of that entity data type must be an instance of some subtype of it. (ISO 10303-28, p. 21)

In OWL, by declaring that a class as equivalent to the union of all it's immediate subclasses we state that a member of the class must also be a member of at least one of the class' subclasses. However, due to the open world assumption made by OWL the information of which subclass(es) this is may not exist. Read protege-owl: "Abstract" class in OWL for more information.


The entity thing is the abstract supertype entity of the entities abstract_object and possible_individual.

  ENTITY thing

  ENTITY abstract_object
    SUBTYPE OF (thing);

  ENTITY possible_individual
    SUBTYPE OF (thing);

translates to

  Class: Thing
        or PossibleIndividual

In Description Logic notation,


Subtyping of entities (EXPRESS word: SUBTYPE OF) are translated to OWL as rdfs:subClassOf axioms. This is an accurate translation of this EXPRESS construct:

EXPRESS allows for the specification of entities as subtypes of other entities, where a subtype entity is a specialization of its supertype. This establishes an inheritance (that is, subtype/supertype) relationship between the entities in which the subtype inherits the properties (that is, attributes and constraints) of its supertype. Successive subtype/supertype relationships establish an inheritance graph in which every instance of a subtype is an instance of its supertype(s). (ISO 10303-11, p. 48)


The entity activity is a subtype of the entity possible_individual.

  ENTITY activity
  SUBTYPE OF (possible_individual);

translates to

  Class: Activity

In Description Logic notation,


The EXPRESS construction ONE OF (...), which is found in the SUPERTYPE OF (...) construct, translates to disjoint axioms (owl:disjointWith) in OWL. The EXPRESS construct ONEOF is explained in ISO 10303-11 as follows:

The ONEOF constraint states that the populations of the operands in the ONEOF list are mutually exclusive; no instance of any of the populations of the operands in the ONEOF list shall appear in the population of any other operand in the ONEOF list. The ONEOF constraint may be combined with the other supertype constraints to enable the writing of complex constraints. When an ONEOF constraint occurs as an operand in another constraint, it represents the set of entity instances that is the union of the populations of the operands in the ONEOF list. NOTE: The phrase ONEOF(a,b,c) reads in natural language as "an instance shall consist of at most one of the entity data types a,b,c." (ISO 10303-11, p. 57)


The following EXPRESS listing is collected from the EXPRESS implementation of ISO 15926-2 (2003). The entity possible_individual is declared as disjoint with abstract_object.

  ENTITY thing
    ABSTRACT SUPERTYPE OF (ONEOF (possible_individual,abstract_object));

Important things to note from the example:

  • From the EXPRESS code the following data is ignored in the translation to disjoint axioms in OWL:
    • ENTITY thing

What remains is:

  ONEOF (possible_individual,abstract_object)

which translates to

  Class: PossibleIndividual

  Class: AbstractObject    

In Description Logic notation,

EXPRESS attributes

EXPRESS attributes are translated to properties in OWL. There are different types of properties in OWL; in this translation we make use of owl:ObjectProperty and owl:DatatypeProperty. These require different treatment which is explained in separate sections below.

The following apply to the translation all EXPRESS attributes:

  • All attribute names are, as entity names, translated from '_'-divided words to UpperCamelCase, and is prefixed with 'has'. The latter is to make all names unique; there are attributes and entities in the EXPRESS schema with the same name.
  • The domain (rdfs:domain) of the property in OWL is set to the union of all the classes/(entities) which contain the attribute.
  • The range (rdfs:range) of the property is set by using an owl:allValuesFrom restriction on the class/(entity) which contain the property.
  • If an attribute is marked as OPTIONAL, then the the minimum cardinality is set to 0. If the attribute is not specified as OPTIONAL the minimum cardinality is 1. The maximum cardinality is always 1. This complies with ISO 10303-11:

Unless an explicit attribute is declared OPTIONAL, every instance of the entity data type shall have a value for that attribute. (ISO 10303-11, p. 41)

The keyword OPTIONAL indicates that, in a given entity instance, the attribute need not have a value. If the attribute has no value, the value is said to be indeterminate (?). (ISO 10303-11, p. 42)

Attribute value = Entity

EXPRESS attributes where the type, i.e., the allowed value type of the attribute, is an EXPRESS entity the attribute is translated in OWL to an owl:ObjectProperty.


Two entities containing each one attribute where the attribute has the same name in both entities, but the allowed values the attribute may hold are different.

Important things to note in this example:

  • Two entities contain the same attribute (class_of_part), but different with different type: (class_of_individual, class_of_information_representation).
  • In the resulting owl code, note:
    • the domain of the owl:ObjectProperty (the union of the classes ClassOfCompositionOfIndividual and ClassOfNamespace)
    • the allValuesFrom restriction in the owl:classes ClassOfCompositionOfIndividual and ClassOfNamespace is set to ClassOfIndividual and ClassOfInformationRepresentation respectively.
  • None of the attributes are declared as OPTIONAL, so the cardinality is set to exactly 1; this is short for saying that minimum cardinality = maximum cardinality = 1.
  ENTITY class_of_composition_of_individual
    class_of_part  : class_of_individual;

  ENTITY class_of_namespace
    class_of_part           : class_of_information_representation;

translates to

  ObjectProperty: hasClassOfPart
        or ClassOfCompositionOfIndividual

  Class: ClassOfCompositionOfIndividual
        hasClassOfPart only ClassOfIndividual
        hasClassOfPart exactly 1 owl:Thing

  Class: ClassOfNamespace
        hasClassOfPart only ClassOfInformationRepresentation
        hasClassOfPart exactly 1 owl:Thing

In Description Logic notation (tentative),

Attribute value = EXPRESS datatype

If the type of an EXPRESS attribute is an EXPRESS simple datatype, e.g., STRING, BOOLEAN, LOGICAL, then the attribute is translated to an owl:DatatypeProperty.


Important things to note in this example:

  • The attribute month is OPTIONAL, so the corresponding property in OWL has minimum cardinality 0. The default minimum cardinality for properties in OWL is 0, so there is no need to assert this fact explicitly.
  • The mapping of primitive EXPRESS datatypes to XSD datatypes is described below.
  ENTITY representation_of_gregorian_date_and_utc_time
      year   : INTEGER;
      month  : OPTIONAL INTEGER;

translates to

  DataProperty: hasYear

  DataProperty: hasMonth

  Class: RepresentationOfGregorianDateAndUtcTime
        hasYear only long,
        hasYear exactly 1 Literal,
        hasMonth only long,
        hasMonth max 1 Literal

Mapping of EXPRESS datatypes to XSD datatypes

The EXPRESS datatypes are mapped to XSD datatypes as follows:

EXPRESS datatype -> XSD datatype
BINARY xsd:hexBinary
BOOLEAN xsd:boolean
INTEGER xsd:long
LOGICAL {"false", "unknown", "true"}, i.e., a set of three strings, see example below.
REAL xsd:double
STRING xsd:normalizedString

The mapping is done as according to the default values specified in ISO 10303-28:

The EXPRESS BINARY data type is mapped to the exp:hexBinary data type. Exception: If the EXPRESS BINARY data type specifies a maximum or FIXED length, it shall be mapped as specified in (...) The EXPRESS BOOLEAN data type is mapped to the xs:boolean data type. (...) The EXPRESS INTEGER data type is mapped to the xs:long data type. (...) The EXPRESS LOGICAL data type is mapped to the exp:logical data type. The exp:logical data type is defined in the Base XML Schema (see Annex C) as follows:

 <xs:simpleType name = "logical">
   <xs:restriction base = "xs:string">
    <xs:enumeration value = "false"/>
    <xs:enumeration value = "true"/>
    <xs:enumeration value = "unknown"/>

(...) The EXPRESS REAL data type is mapped to the xs:double data type. EXPRESS REAL data type with precision shall be mapped without restriction of the precision. (...) The EXPRESS STRING data type is mapped to the xs:normalizedString data type. Exception: If the EXPRESS data type is declared to have a maximum length or a FIXED length, the EXPRESS data type shall be mapped as specified in (ISO 10303-28 ("XML representations of EXPRESS schemas and data, using XML schemas") p. 23--28.)

Note: In the mappings of the simple EXPRESS datatypes BINARY and STRING to an XML representation in ISO 10303-28 there are exceptions. The exceptions are ignored in the translation to XSD datatypes.


The translation of the EXPRESS datatype LOGICAL.

  ENTITY express_logical
    content : LOGICAL;

translates to

  Class: ExpressLogical
        hasContent only {"false" , "unknown" , "true"},
        hasContent exactly 1 Literal


The EXPRESS datatype LIST is a bit trickier to translate OWL than the rest of the EXPRESS datatypes as there is no sequence datastructure defined in OWL. A good proposal for representing lists in OWL is found in the paper Putting OWL in Order: Patterns for Sequences in OWL (http://owl-workshop.man.ac.uk/acceptedLong/submission_12.pdf) by Drummond et. al; here the class OWLlist is defined. The OWLlist is defined using the pattern of the well-known datastructure linked list.

Note: An OWLlist is a chain of OWLlists formed by the ObjectProperty hasNext where the contents in an OWLlist is found at the end of the ObjectProperty hasContents. Since the hasContents property is an ObjectPropery OWLlists cannot contain datatype values without exceeding the expressiveness of OWL DL. To overcome this we have mapped the contents of a list of simple EXPRESS datatypes, e.g., a LIST OF INTEGERs, to an OWLlist only containing the corresponding Express class, in this case ExpressInteger.


The entity multidimensional_object contains two lists, one list of things and one list of INTEGERs.

  ENTITY multidimensional_object
    elements : LIST [1:?] OF thing;
    position : OPTIONAL LIST [1:?] OF INTEGER;

translates to

  ObjectProperty: hasElements

  ObjectProperty: hasPosition

  Class: MultidimensionalObject
        hasElements exactly 1 owl:Thing,
        hasPosition max 1 owl:Thing,
        hasElements only (list:OWLList
          that list:hasContents only Thing
          and list:isFollowedBy only (list:OWLList
            that list:hasContents only Thing))

        hasPosition only (list:OWLList
          that list:hasContents only ExpressInteger
          and list:isFollowedBy only (list:OWLList
            that list:hasContents only ExpressInteger))


The EXPRESS construct UNIQUE specifies that the values of an attribute is unique "within its context", e.g., just like a unique key in a database table:

The uniqueness rules follow the unique keyword, and specify either a single attribute name or a list of attribute names. A rule which specifies a single attribute name, called a simple uniqueness rule, specifies that no two instances of the entity data type in the domain shall use the same instance for the named attribute. A rule which specifies two or more attribute names, called a joint uniqueness rule, specifies that no two instances of the entity data type shall have the same combination of instances for the named attributes. (ISO 10303-11, p. 46)

This is captured in OWL by defining the property as an inverse functional property. However, declaring datatype properties in OWL as inverse functional is not allowed in OWL DL, so this is EXPRESS construct is ignored in the translation. In OWL 2 there is an proposal on how to implement keys, see Easy Keys - OWL. Below is how the translation would have been using inverse functional property.


The attribute id in the entity thing is declared as UNIQUE.

  ENTITY thing
      id  : STRING;
      ur1 : id;


The EXPRESS filtering construct WHERE is ignored in the translation to OWL. This translation requires the strenght of OWL 2 where user-defined datatype properties is an new feature, e.g., one can define the range of hasHumanAge to the interval [0, 150]. OWL DL is not capable of expressing user-defined datatypes.


The following is ignored in the translation to OWL.

  ENTITY representation_of_gregorian_date_and_utc_time
      valid_month: ((1 <= month) AND (month <= 12));
      valid_day: ((1 <= day) AND (day <= 31));
      valid_hour: ((0 <= hour) AND (hour <= 23));
      valid_minute: ((0 <= minute) AND (minute <= 59));
      valid_second: ((0 <= second) AND (second < 61));


The SUPERTYPE OF EXPRESS construct is ignored in the translation to OWL. The SUPERTYPE OF statements are made superfluous by the SUBTYPE OF statements, at least in this particular EXPRESS file.


The ANDOR EXPRESS construct is ignored in the translation to OWL. This construct is used to declare conjunctions of axioms, e.g., that both possible_individual and abstract_object are SUPTYPE OF the entity thing. In OWL there is no need for a conjunction construct; multiple statements are "naturally" interpreted conjunctively.


You have no rights to see this discussion.

About PCA
Reference Data Services