Disclaimer

This document is the copyrighted property of ASAM e. V. In alteration to the regular license terms, ASAM allows unrestricted distribution of this standard. §2 (1) of ASAM’s regular license terms is therefore substituted by the following clause: "The licensor grants everyone a basic, non-exclusive and unlimited license to use the standard ASAM OpenXOntology".

1. Foreword

ASAM e.V. (Association for Standardization of Automation and Measuring Systems) is a non-profit organization that promotes standardization of tool chains in automotive development and testing. Our members are international car manufacturers, suppliers, tool vendors, engineering service providers, and research institutes. ASAM standards are developed by experts from our member companies and are thus based on real use cases. They enable the easy exchange of data or tools within a tool chain. ASAM is the legal owner of these standards and responsible for their distribution and marketing.

ASAM standards define file formats, data models, protocols, and interfaces for tools that are used for the development, test, and validation of electronic control units (ECUs) and of the entire vehicle. The standards enable easy exchange of data and tools within a tool chain. They are applied worldwide.

2. Introduction

2.1. Overview

This guide is the specification and user guide for ASAM OpenXOntology, an ASAM standard that defines central concepts, properties, and relations between the concepts of the ASAM OpenX standards, including OpenDRIVE, OpenSCENARIO, OpenODD, OSI, and OpenLABEL.

2.1.1. Motivation

All OpenX standards come from the same domain: road traffic. However, they are not founded on a common domain model. Thus, central concepts are redundantly defined and described in each of the standards. Definitions sometimes contradict each other. Overlapping definitions currently exist, for example, for lane references in OpenSCENARIO and OpenDRIVE. This causes the following issues:

  • Linking data created with different OpenX standards is difficult.

  • It is not easily possible to guarantee compatibility within data sets complying to the same standard, but coming from different suppliers. Examples are scenario labels for driving simulations.

Furthermore, the concepts used in scenarios, their parameters, and their relations are not standardized. This makes it considerably more difficult to:

  • Extract scenarios from logged data in a standardized way.

  • Manually create unambiguous scenarios.

  • Automatically generate synthetic scenarios in a traceable manner.

  • Use common labels for objects and scenes.

  • Retrieve scenarios based on common queries.

These difficulties apply to both humans and machines responsible for defining, labeling, and retrieving scenarios. They also apply to both existing and future standards related to road traffic.

An ASAM ontology that describes, among others, the concepts of traffic infrastructure, interactions of traffic participants, and environmental conditions can fill this gap by providing a standardized vocabulary, and a domain model for the OpenX standards. This might also facilitate the use of artificial intelligence for OpenX applications.

More on the advantages of an ontology can be found in the chapter on the benefits of an ontology.

2.1.2. What is ASAM OpenXOntology

The OpenX standards describe traffic participants, road networks, driving maneuvers, and test scenarios for driving and traffic simulation, labeling sensor data, and other use cases. The standards share concepts from the domain of road traffic, such as road, lanes, and traffic participants. ASAM OpenXOntology provides an ontology-based architecture for these concepts and thus a common definition of the domain model for the OpenX standards.

ASAM OpenXOntology covers the following concepts from the domain of road traffic:

  • Road infrastructure, meaning roads, lanes, junctions, etc.

  • Traffic infrastructure, meaning traffic signs, signals, etc.

  • Temporal changes in the road and traffic infrastructures, meaning road constructions, diversions, etc.

  • Dynamic traffic participants, such as cars, pedestrians, and cyclists.

  • Environment, meaning weather, time of day, etc.

  • Communication conditions, such as vehicle-to-vehicle communication or GPS localization.

2.1.3. Deliverables of ASAM OpenXOntology

This release contains the following:

  • Core ontology, which contains a set of basic concepts and relationships.

  • Domain ontology, which describes concepts relevant to road traffic.

  • The connected ontology of core and domain parts.

In order to cover specific use cases on application level with the help of ASAM OpenXOntology, developers extend the domain ontology with their application-specific concepts. Application-specific concepts are not part of ASAM OpenXOntology. However, this document describes a method that allows users to incorporate a new concept into ASAM OpenXOntology using the domain ontology, see How to incorporate a new concept into ASAM OpenXOntology.

Furthermore, this document provides concrete examples of using ASAM OpenXOntology for specific application scenarios, see Data journey with ASAM OpenXOntology and related OpenX standards. This serves as a reference as well as a demonstrator of the functionality of ASAM OpenXOntology.

This version of ASAM OpenXOntology contains the following deliverables:

  • OWL files for the core and domain ontologies that are part of ASAM OpenXOntology.

  • The ASAM OpenXOntology user guide.

  • The model reference.

Due to missing object properties and SWRL rules in the domain ontology, reasoning and inference are currently not possible. That means that the domain ontology of this version is mainly a taxonomy, but there are practical examples in the data journey to demonstrate inference and reasoning. ASAM pursues the goal of further developing ASAM OpenXOntology based on user feedback.

2.2. Normative and non-normative statements

This documentation uses a standard information structure. The following rules apply regarding normativity of sections:

  • Statements expressed as requirements, permissions, or prohibitions according to the use of modal verbs, as defined in Modal verbs, are normative.

  • Architecture diagrams from the OpenXOntology OWL model are normative.

  • Code samples and use case descriptions are non-normative.

2.3. Conventions

2.3.1. Units

All numeric values within this standard are using SI units, unless explicitly stated otherwise. Table 1 presents details of the used units.

Table 1. Units
Unit of Unit Symbol

Length

Meter

m

Duration, (relative) time

Second

s

Speed

Meters per second

m/s

Acceleration

Meters per second squared

m/s²

Mass

Kilogram

kg

Angle

Radians

rad

Light intensity

Lux

lx

Geographic positions are stated in the unit defined by the spatial coordinate system, for example, in accordance with WGS 84 – EPSG 4326 [1].

2.3.2. Modal verbs

To ensure compliance with the ASAM OpenXOntology standard, users need to be able to distinguish between mandatory requirements, recommendations, permissions, as well as possibilities and capabilities.

The following rules for using modal verbs apply:

Table 2. Rules for using modal verbs
Provision Verbal form

Requirements
Requirements shall be followed strictly in order to conform to the standard. Deviations are not allowed.

shall
shall not

Recommendations
Recommendations indicate that one possibility out of the several available is particularly suitable, without mentioning or excluding the other possibilities.

should
should not

Permissions
Permissions indicate a course of action permissible within the limits of ASAM OpenXOntology deliverables.

may
need not

Possibilities and capabilities
Verbal forms used to state possibilities or capabilities, whether technical, material, physical, etc.

can
cannot

Obligations and necessities
Verbal forms used to describe legal, organizational, or technical obligations and necessities that are not regulated or enforced by the ASAM OpenXOntology standard.

must
must not

2.3.3. Typographic conventions

This documentation uses the following typographical conventions:

Table 3. Typographical conventions
Mark-up Definition

Code elements

This format is used for code elements, such as technical names of classes.

<owl:NamedIndividual rdf:about="http://www.asam.net/ontologies/ABoxMWP#lane1">

This format is used for excerpts of code that serve as an implementation example.

Terms

This format is used to introduce glossary terms, new terms and to emphasize terms.

2.4. Contributing to ASAM OpenXOntology

ASAM OpenXOntology is maintained by ASAM e.V. For detailed information about the project, working group, and ways to participate in the standard’s development, refer to the ASAM website.

3. Terms, definitions, and abbreviated terms

3.1. Terms and definitions

ABox

Type of statements in a knowledge graph. An ABox is formed by individuals and their relationships established by object properties. The individuals and object properties from a directed graph, in which the individuals are the nodes and the specific relationships are the edges. The A can stand for "assertion".

ADS

Automated driving system.

Application ontology

Type of ontology in the context of ASAM OpenX. Application ontologies contain concepts that a particular ASAM OpenX standard is allowed to modify without consulting any other standard working group. Application concepts are only used in that specific standard.

Assertion

A triple where the subject and object are both individuals. In this case, the triple expresses a fact about those particular individuals.

Axiom

A triple where the subject and object are both classes. In this case, the triple expresses a constraint on the definition of both classes.

Class

Ontology class that represents a set of actual things in the domain that have common characteristics. These things are not just physical things that people can touch. In addition to physical objects, they include any things that exist in time and space, for example, events and activities.

Core ontology

Type of ontology in the context of ASAM OpenX. The core ontology defines basic concepts, such as physical objects, states, and events. The core ontology of ASAM OpenXOntology corresponds to a top-level ontology or upper ontology. The core ontology of ASAM OpenXOntology is based on HQDM.

Domain ontology

Type of ontology in the context of ASAM OpenX. The domain ontology defines central concepts of the road traffic domain, for example, lane, road, and vehicle. It contains only concepts that are shared by multiple ASAM OpenX standards using the ASAM OpenXOntology and that are not controlled by a single standard.

Ego vehicle

The vehicle that is the focus of a scenario, meaning the vehicle under test.

HQDM

High-Quality Data Model framework

Individual

Member (or object) of an ontology class.

Inference

Process of deducing new knowledge from existing knowledge and axioms. In an OWL database, inference is used for deducing further knowledge based on the existing OWL data and a formal set of inference rules.

ODD (Operational Design Domain)

Source: SAE J3016 (2021) [2]

Operating conditions under which a given driving automation system or feature thereof is specifically designed to function, including, but not limited to, environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics.

Ontology

Formal and machine-readable representation of knowledge in a specific domain. ASAM OpenXOntology refers to the traffic domain. Ontologies contain standardized definitions of concepts and describe how the defined concepts relate to and differ from each other. In this way, ontologies enable both humans and machines to have a shared understanding of the meaning of the concepts. Logically formalized ontologies use predicate logic to describe these relations and thus facilitate logical reasoning in order to infer additional knowledge about the data that is exchanged. In the context of this specification, the term ontology refers to logically formalized ontologies, particularly ontologies that are based on a description logic.

Property

Expresses the type of relationship between members of ontology classes.

Reasoning

Inference of logical consequences from a set of asserted facts or axioms.

Reasoner

An application that is able to perform reasoning.

Relationship/Relation

A typed, directed connection between two classes or two individuals of an ontology that expresses that these classes or individuals have a semantic link. The combination of subject-relationship-object is called triple.

SWRL

Semantic Web Rule Language, a proposed language for the Semantic Web that combines OWL with a subset of the Rule Markup Language (RuleML).

TBox

Type of statements in a knowledge graph. A TBox is formed by classes that are related by object properties. The classes and properties form a directed graph, in which the classes are the nodes and the specific relationships are the edges. The T can stand for "terminological".

Temporal part: During its lifetime, a whole-life physical object, such as a car, takes part in different activities. For each participation in an activity, ASAM OpenXOntology uses a member of the class State to model a temporal part that represents the thing during the activity or event.

Triple

Describes the concrete relationships between two classes or individuals. It is the combination of a subject, an object, and a relationship between them that expresses a statement in the form subject-predicate-object.

Generic example: Car-driveOn-Road.

Triples may be formed with classes or individuals.

  • If the subject and object of a triple are both classes, the triple expresses a constraint on the definition of both classes. Such a constraint is called an axiom.

  • If the subject and object are both individuals, the triple expresses a fact about those particular individuals. Such an expression is called an assertion.

4. Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes some of the requirements set out in this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

  • ASAM OpenDRIVE, version 1.7.0 [3]

  • ASAM OpenSCENARIO, version 1.1.1 [4]

  • ASAM OpenSCENARIO, version 2.0.0 [5]

  • ASAM OpenLABEL, version 1.0.0 [6]

  • ASAM OpenODD Concept Paper, version 1.0.0 [7]

  • ASAM Open Simulation Interface (OSI), version 3.3 [8]

  • SAE J3016 (2021) [2]

  • BSI PAS 1883 [9]

  • ISO TC33 SC33 WG9 [10]

  • ISO 704: Terminology work — Principles and methods [11]

  • ISO 3450x series (in development)

    • ISO 34501: terms and definitions [12]

    • ISO 34502: engineering framework [13]

    • ISO 34503: ODD taxonomy [14]

    • ISO 34504: Scenario categorization [15]

  • ISO TC22 SC32 WG8 [16]

    • SAFAD2 [17]

    • SOTIF [18]

5. Relation to ASAM OpenX

Relation of OpenXOntology to other OpenX standards
Figure 1. ASAM OpenXOntology and its relation to other ASAM standards

Figure 1 shows the interdependencies between ASAM OpenXOntology and the OpenX standards.

The following sections describe the relation between ASAM OpenXOntology and each of the contributing ASAM OpenX standards using this patterns:

  • What does [ASAM OpenX standard] define?

  • How can [ASAM OpenX standard] use ASAM OpenXOntology?

  • How would ASAM OpenXOntology affect [ASAM OpenX standard]?

5.1. ASAM OpenDRIVE

5.1.1. What does ASAM OpenDRIVE define?

ASAM OpenDRIVE specifies an exchange format for static road networks that can be used by driving simulation applications. ASAM OpenDRIVE focuses on static road infrastructure elements, such as roads, lanes, junctions, and signals. The standard does not cover dynamic content.

5.1.2. How can ASAM OpenDRIVE use ASAM OpenXOntology?

ASAM OpenDRIVE can use ASAM OpenXOntology definitions for static road infrastructure elements that are shared with other OpenX standards. Examples are lanes and roads. Also, ASAM OpenDRIVE can use connective and spatial relationships between the elements that are defined in ASAM OpenXOntology.

5.1.3. How would ASAM OpenXOntology affect ASAM OpenDRIVE?

Harmonization with different ASAM projects is ongoing.

5.2. ASAM OpenLABEL

5.2.1. What does ASAM OpenLABEL define?

ASAM OpenLABEL standardizes the annotation format and the labeling methods for multi-sensor data streams and scenario files. Using a standardized format helps cut costs and save resources used in creating, converting, and transferring annotated and tagged data. ASAM OpenLABEL is represented in a JSON format and can therefore be easily parsed by tools and applications.

5.2.2. How can ASAM OpenLABEL use ASAM OpenXOntology?

The labels in ASAM OpenLABEL define:

  • Entities within the road traffic domain.

  • Types of geometrical constructs that are adequate to capture those entities in multi-sensor data streams, for example, Lidar 3D bounding boxes, 2D image boxes, and polygons.

ASAM OpenXOntology represents knowledge about the road traffic domain and can thus provide a richer description of the labels. Ontology-based label descriptions are grounded in logic, enabling use of reasoning applications. Finally, ASAM OpenXOntology can support the harmonization of the ASAM OpenLABEL standard with other OpenX standards that exchange information with it.

5.2.3. How would ASAM OpenXOntology affect ASAM OpenLABEL?

The ASAM OpenLABEL project is closely connected to ASAM OpenXOntology because ASAM OpenXOntology can provide the object descriptions for the labels. On the other hand, the ASAM OpenLABEL project delivers requirements to the ontology project with respect to the relevant entities that need to be labeled and their relationships.

The development phases of ASAM OpenLABEL and ASAM OpenXOntology took place in parallel which provided opportunities for alignment. The ASAM OpenLABEL scenario tagging model shares the same structure as the ASAM OpenXOntology domain ontology. At a high level, they both utilize an ODD-based umbrella structure (referenced to BSI PAS 1883) for the environmental conditions and the road topology and infrastructures. For the traffic participant and activity aspect, a one-to-one mapping can be established between the ASAM OpenLABEL scenario tagging model and the ASAM OpenXOntology domain ontology. One of the future alignments between the two standards will focus on how to deal with multiple inheritance for the ASAM OpenLABEL scenario tagging use case, since currently the tagging semantic only consider single inheritance. Furthermore, minor alignments on the class names and definitions between the two standards are also needed in the near future. The goal would be to have a harmonized domain ontology which will be hosted only in ASAM OpenXOntology, and ASAM OpenLABEL scenario tagging will only host application level ontology instead of its own separate domain model.

5.3. ASAM OpenSCENARIO

5.3.1. What does ASAM OpenSCENARIO define?

ASAM OpenSCENARIO 1.1.1 defines a data model and a derived file format for the description of scenarios used in driving and traffic simulators, as well as in automotive virtual development, testing, and validation.

5.3.2. How can OpenSCENARIO use ASAM OpenXOntology?

ASAM OpenSCENARIO 1.1.1 retrieves definitions for spatial and temporal relationships between both dynamic and static traffic participants from ASAM OpenXOntology.

OpenSCENARIO 2.0.0 was developed in parallel with ASAM OpenXOntology. Initial interaction and alignment between the projects took place, but future revisions require further harmonization.

5.3.3. How would ASAM OpenXOntology affect ASAM OpenSCENARIO?

Harmonization with different ASAM projects is ongoing.

5.4. ASAM Open Simulation Interface (OSI)

5.4.1. What does ASAM OSI define?

ASAM OSI is a specification for interfaces between models and components of a distributed simulation. OSI is strongly focused on the environmental perception of automated driving functions.

ASAM OSI contains an object-based environment description that uses the message format of the Protocol Buffer library. Google developed and maintains the Protocol Buffer library. ASAM OSI defines top-level messages that are used to exchange data between separate models. Top-level messages define the GroundTruth interface, the SensorData interface, and – since ASAM OSI version 3.0.0 – the interfaces SensorView, SensorViewConfiguration, and FeatureData.

5.4.2. How can ASAM OSI use ASAM OpenXOntology?

ASAM OSI can use concepts and relationships of ASAM OpenXOntology to generate ground truth messages as input to sensor and sensor fusion models.

5.4.3. How would ASAM OpenXOntology affect ASAM OSI?

OSI currently defines a fixed message structure, entity classifications, and maneuver actions in order to guarantee connectivity and compatibility with existing sensor models. This requires careful consideration of specifications with regard to the protocol definitions. ASAM OpenXOntology will help to close the gap between scenario engine, environment simulator, and the sensor model using input and output messages from OSI.

5.5. ASAM OpenODD

5.5.1. What does ASAM OpenODD define?

An operational design domain (ODD) refers to the operating environment in which vehicles are designed to operate safely. A more formal definition of an operational design domain as defined by SAE J3016 (2018) [2] states the following:

"Operating conditions under which a given driving automation system or feature thereof is specifically designed to function, including, but not limited to, environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics".

The operational design domain impacts the design of the vehicle, its capabilities as well as its respective validation, particularly with respect to safety. The operational design domain shall be valid throughout the whole vehicle lifetime.

ASAM OpenODD aims at defining a format that represents an abstract operational design domain for a vehicle that is both machine-readable and human-readable. It will enable stakeholders to share, compare, and reuse data. The ASAM OpenODD format will be designed to be machine-processable throughout the vehicle development and lifecycle. Furthermore, it shall be measurable and verifiable. This requires well-defined syntax and semantics.

5.5.2. How can ASAM OpenODD use ASAM OpenXOntology?

Currently, the ASAM OpenODD project is at the concept development stage.

The base set of concepts is referenced to the existing operational design domain standards. For example, BSI PAS 1883 serves as a basis for instantiating individual operational design domain specifications. In the coming phases of the ASAM OpenXOntology harmonization, such standards will be aligned with the concepts at the domain ontology level. ASAM OpenODD will then be able to use concepts and relationships from the ASAM OpenXOntology to build specific operational design domains.

Furthermore, in ASAM OpenODD, one of the key language concpets focuses on the extensibility of the underlying ontology. While the syntax for such extension of ontology has been developed in the ASAM OpenODD project, ASAM OpenXOntology provides the necessary mechanism from an ontological and operational perspectives.

5.5.3. How would ASAM OpenXOntology affect ASAM OpenODD?

Harmonization with different ASAM projects is ongoing. ASAM OpenXOntology will also set out the available relationships to be used when constructing the ASAM ODD specification. This could include the following:

  • Specify conditional operational design domain statements: For example, a motorway is only suitable when there is no rain. For an example, see phase 5 of the example data journey.

  • Error checking for wrong relations: For example, rain intensity is sunny.

  • Wrong keywords used without pre-specifying: For example, rain intensity is my special rain.

In addition, as mentioend in the earlier section, ASAM OpenXOntology will enable methods to extend the underlying terminology of ASAM OpenODD, for example, adding a new subclass to rain intensity.

6. Introduction to ontologies

6.1. What is an ontology

The class and property names in this chapter are examples and used for illustration purposes. They do not necessarily represent the naming of classes and properties in ASAM OpenXOntology.

Ontologies are used to represent knowledge in a way that computers can understand. Like a terminology, as defined in ISO 704 [11], an ontology contains standardized definitions of concepts that are used in a particular domain of knowledge, such as road traffic. These standardized definitions are used when data is exchanged by human parties and computer programs working independently. In this way, ontologies and terminologies enable both humans and machines to have a shared understanding of the meaning of the concepts.

Unlike terminologies and taxonomies, ontologies also describe how the defined concepts relate to and differ from each other.

Logically formalized ontologies use predicate logic to describe these relations. In this way, ontologies enable humans and machines to use logical reasoning in order to infer additional knowledge about the data that is exchanged. In the context of this specification, the term ontology refers to logically formalized ontologies, particularly ontologies that are based on a description logic.

Classes, properties, and triples

An ontology defines concepts as classes. A class represents a set of actual things in the domain that have common characteristics. These things are not just physical things that people can touch. They include any things that exist in time and space, such as:

  • Activities and maneuvers, such as walking and overtaking another vehicle.

  • Events and decisions, such as the instance that a collision occurs and the decision of a driver to turn left.

  • Places, such as junctions, lanes, and connections between road segments.

  • Physical objects, such as humans and motor vehicles.

The members of classes are called individuals. Individuals may be members of a single class or several different classes.

In addition to the classes, ontologies define properties, which express the types of relationships between members of classes. The concrete relationship or predicate between two particular members is a member of a property set, in the same way that individuals are members of classes.

spo
Figure 2. A directed relationship from subject to object

Relationships are directed, meaning they point from a subject to an object. The combination of a subject individual, an object individual, and a relationship between them results in a triple that expresses an assertion in the form subject-predicate-object, as shown in Figure 2.

Example:

  • A member of the property hasPart (predicate) connects a member of the class RoadVehicles (subject) to a member of the class Wheels (object).

  • This relationship can be described by the natural language assertion "This road vehicle has parts that are wheels."

Triples are the method used in ontologies for encoding information. Each triple consists of three parts:

  • Predicate: a typed, directed binary relation describing some specific relationship between two things in the domain.

  • Subject: the thing in the domain that has the relationship. Example: The thing that "has" a hasPart relationship.

  • Object: the thing in the domain that is had by the relationship. Example: The thing that "is had by" a hasPart relationship.

Triples may be formed with classes or individuals. If the subject and object of a triple are both classes, the triple expresses a constraint on the definition of both classes. Such a constraint is called an axiom. If the subject and object are both individuals, the triple expresses a fact about those particular individuals. Such an expression is called an assertion. In general, it is not possible to create a triple to relate a class and an individual.

Inference and logical constructs

Like classes, properties are first-class constructs, meaning that a particular relationship exists independently of the actual things that it relates. Because of the "open-world assumption" in ontologies, this means that a computer can infer the class membership of the two things that are related by a particular relationship.

Example: The hasPart property is defined such that the subject is a member of the class PhysicalObject. If an individual "X" has a hasPart relationship with another individual "Y", the computer program can infer that "X" must be a member of the class PhysicalObject.

If such an inference leads to a contradiction, an ontology reasoner can identify this as a semantic error. For example, if another inference has the result that "X" must be a member of the class Activity, and the classes PhysicalObject and Activity are defined as disjoint, then a semantic error is concluded. However, the reasoner cannot decide automatically which of the class memberships is actually correct.

The characteristics of an ontology class are expressed using properties together with a set of logical constructs, such as cardinality and value restrictions, that are provided by the ontology modeling language. ASAM OpenXOntology uses OWL as modeling language. These logical constructs restrict the way that properties may be used with members of the defined class.

For example, the ontology may define that a member of the class Bicycles, which is a subclass of the class RoadVehicles, shall be related by the property hasPart to exactly two members of the class Wheels.

Related topics

TBox and ABox

The classes and properties of an ontology form a directed graph, with the classes as nodes and the properties as edges. The graph made up of classes and properties is called a TBox, where the T can stand for "terminological". Semantic applications can transverse the graph and additionally evaluate the logical characteristics defined for the classes and properties in the ontology. In this way, the applications can identify conflicts and logical incoherencies. For example, if RoadVehicles was defined to have as parts exactly four Wheels, an ontology reasoner will identify that defining Bicycles as a subclass of RoadVehicles that have as parts exactly two Wheels is a contradiction.

Another graph is formed when particular individuals are connected with directed relationships to other individuals. The individuals are members of classes and the relationships are members of properties. In this graph, the individuals are the nodes and the specific relationships are the edges. These graphs are called ABoxes, where the A can stand for "assertion". By applying logical reasoning to an ABox, semantic applications can usually infer the existence of additional relationships and even other individual things from the asserted information.

Abox tbox
Figure 3. TBox and a possible ABox

To summarize: Triples in the TBox connect classes, whereas triples in the ABox connect individuals, as shown in Figure 3.

Deriving facts from the web of knowledge

An ontology can be viewed as specifying the conceptualization of a particular knowledge domain as a logically formalized graph or web of knowledge.

This web of knowledge enables computer programs to reason about assertions that are made according to an ontology, for example, to derive new facts about things that are not explicitly expressed in the assertions. In addition, an ontology reasoner can be used to check a particular expression for logical incoherencies, which may indicate a misunderstanding or simply a semantic error.

Rule-based languages for ontologies

Many characteristics that one might want to declare between things are too complex to be readily expressed using logical constructors only. For example, it would be difficult to create a purely logical expression of the definition of "Overtaking" as an "Activity" in which the subject vehicle starts in the same lane behind the object vehicle and ends up in the same lane in front. The combination of logical reasoning and rule-based reasoning enables a computer program to make complex inferences from a particular expression, thereby realizing a high level of computer understanding. For this reason, an ontology modeling language, such as OWL, is often used together with a rule-based language, such as SWRL (Semantic Web Rule Language).

Related topics

6.2. What are the benefits of an ontology?

The ASAM OpenXOntology project started to address a need identified for common definitions to be used by the ASAM OpenX standards. There are several reasons why an ontology is beneficial to reach this goal.

Common definition of concepts

In a domain such as road traffic, concept definitions are often unclear or they require some special knowledge to interpret. The result is that different people working in the same domain but having different areas of expertise may not understand each other’s definitions of a concept. Typical problems are:

  • Polysemy, where one term is used to refer to several different concepts

  • Homonymy, where several terms are used to refer to the same concept

In the development of technical standards, it is particularly important to address these issues.

A formal theory, which is grounded in some form of logic, makes it possible to create concept definitions in a formalized way. Ontologies provide a base theory for making definitions of concepts used in a particular knowledge domain. This guarantees that all participants, including humans and machines, using the concept definitions will have the same understanding of the concepts. The logical constructs that an ontology facilitates can be used to constrain relationships between concepts. Examples for constraints are:

  • The logical construct some-values-from can be used to define that ElectricVehicles must have at least one value from ElectricEngines for the hasPart relationship.

  • The logical construct cardinality = 2 may be used to define that Bicycles must have exactly two values from Wheels for the hasPart relationship.

Extensibility

For the formal definition of ontologies, semantic web standards and formats are available, for example, Resource Description Framework Schema (RDFS) and Web Ontology Language (OWL). By adhering to the mechanisms of these standards, different participants of a domain may extend the ontology, for example by introducing a new concept definition, and be assured that other participants will interpret the extension correctly. In the context of ASAM, users of the ASAM OpenSCENARIO 1.1.1 standard who write an expression for Overtaking in a particular road traffic scenario can be sure that ASAM OpenDRIVE or ASAM OpenLABEL users understand the intended meaning of the expression.

Both RDFS and OWL are based on XML. For this reason, an ontology can be easily split into multiple files hosted by different web servers.

Rules and reasoning

An ontology that is based on some form of logic or that utilizes some kind of theory for expressing rules (Horn clauses) enables a computer program that implements an ontology reasoner to infer relationships between ontology classes and individuals that are not explicitly stated. Inference can be used to assess the coverage or to extract common patterns shared by different concepts, and even to find semantic errors in the ontology.

Reasoning is especially useful when applied automatically. Applications that are able to read and understand the underlying theory of the ontology can reason about knowledge expressed in some assertion (ABox), make inferences, and assert new knowledge. Furthermore, machine learning can be used to train applications to find new knowledge in an ontology from induction.

Related topics

Determining semantic proximity and similarities

Ontologies make it possible to assess the semantic proximity of different concepts in a domain that are defined by different participants. Finding these proximities enables richer classification of concepts. For example, a participant can identify that a particular concept is in fact a subclass of another concept even if that is not explicitly stated. A richer classification makes the ontology more useful.

Furthermore, ontologies can be used to evaluate the semantic similarity of different assertions (ABoxes comprised of multiple individuals and relationships) made in the domain. In this way, ontologies enable humans and machines to understand that two assertions mean the same thing even if they do not say the same thing. For example, an ontology reasoner could discover similarities between different assertions about road traffic situations or scenarios by finding similarities particularly in the relationships between types of things that are otherwise hidden.

The following are some typical use cases that utilize calculation of semantic similarity:

  • Semantic searching and matching to find records in a database that semantically are most similar. Example: Find scenario descriptions in a scenario repository that are similar to the scenario that is currently edited.

  • Find clusters by semantic similarity. Example: Identify groups of scenarios that have similar chains of events and relationships between traffic participants.

  • Classify large numbers of scenarios according to patterns of relationships between concepts that define different operational design domains.

7. Architecture of ASAM OpenXOntology

7.1. Architectural overview

ASAM OpenXOntology aims to structure and formalize knowledge about the existence of things in the domain of road traffic. This is done as independently as possible of the intended applications in ASAM standard development so that the ontology can be reused for different types of applications.

The architecture of ASAM OpenXOntology intends to ensure flexibility of use, both for ontology developers and ontology users. The following aspects were considered:

  • Knowledge comes from different sources.

  • Ontologies grow rapidly and can become too large to be easily visualized and managed.

  • Different ontologies need to be merged to get new knowledge.

The complexity of creating and using domain-specific ontologies can be reduced by dividing knowledge into multiple areas. The following technical approaches are used for that:

  • Modularization: Divide the ontology into individual modules for independent subject areas.

  • Configuration management: Provide mechanisms for ontology users to generate a merged ontology from source modules that contains sufficient information for the application.

ASAM OpenXOntology uses modularization and is divided into the following modules:

  • Core ontology (deliverable of this release) which is based on the HQDM framework

  • Domain ontology (delivered as taxonomy in this release)

  • Application ontologies (not yet implemented)

  • Application integration ontology for end use (not yet implemented)

architecture overview
Figure 4. Example visualization of core, domain, and application ontologies

Figure 4 shows how core, domain, and application ontologies interact with each other. The application ontologies will use concepts from both domain ontology and core ontology, as indicated by the overlap of circles.

The application integration ontology will be a dedicated ontology file for the ontology user. This ontology will be the result of merging the core and domain ontologies and one or several application ontologies according to the user requirements. An application integration ontology enables users to use all concepts and properties from the merged ontologies.

Other modules that will be considered in future versions include:

  • Parameters and constraints

  • Semantic rules

Parameters, constraints, semantic rules, and the application ontology layer are still in development.

Related topics

7.1.1. Core ontology

The core ontology describes the top-level ontology, a framework of classes and properties that are used as a foundation for the domain-specific content in the domain ontology. These concepts include:

  • Physical objects, including both dynamically changing and static unchanging objects. Domain concepts inheriting from these core concepts include vehicles, roads, and traffic signs.

  • States of physical objects that correspond to temporal parts of the objects' lifetime. These states have single valued state parameters, such as speed.

  • Activities, including actions and behaviors that involve the physical objects in active and passive roles.

  • Events that mark the changes in states of physical objects, critical points in time, and triggers or decisions for the start or end of activities.

The object properties defined in the core ontology provide meta models for describing basic compositional, spatial, and temporal relationships between individuals in the domain.

architecture core ontology
Figure 5. Simplified representation of the core ontology

Figure 5 shows the core ontology.

Related topics

7.1.2. Domain ontology

The domain ontology of ASAM OpenXOntology defines central concepts of the road traffic domain, for example, lane, road, and vehicle. These central concepts are summarized in the domain ontology to provide a consistent and expressive underlying language for the ASAM OpenX standards. The domain ontology currently only includes concepts that are not controlled by any single OpenX standard.

The domain ontology includes the following main concepts:

  • Road topology and traffic infrastructure. Examples: road, junction, lane marking, toll plaza, construction signs, and traffic signs

  • Traffic participants and their behavior. Examples: activities, such as starting, stopping and overtaking; vehicle and pedestrian.

  • Ambient conditions. Examples: rain, fog, lighting condition, road surface condition, V2V communication condition.

The domain ontology does not yet feature object properties that can be used to establish relationships between individuals. These will be added in future releases. In the current release, the domain ontology can mainly be used as a taxonomy.

Related topics

7.1.3. Application ontology

ASAM plans to develop one application ontology for every ASAM OpenX standard, for example, OpenDRIVE and OpenLABEL. The application ontology will contain concepts that the particular standard is allowed to modify without consulting any of the other standards. These are normally concepts that are only used in that specific standard.

Application ontologies will import all concepts and properties from the core and domain ontologies, while using only the ones that fit for them.

7.2. Ontology language and rule language

ASAM OpenXOntology uses OWL as ontology language and SWRL as rule language.

The process that led to the decisions to use OWL and SWRL is documented in the appendix.

Web Ontology Language (OWL)

OWL [19] is a semantic markup language for publishing and sharing ontologies on the Web. OWL builds on RDF and RDFS and is part of the W3C recommendations related to the Semantic Web.

OWL goes beyond the basic semantics that can be expressed with RDF Schema. The data described by an ontology in the OWL family is interpreted as a set of individuals and a set of property assertions that relate these individuals to each other. An ontology consists of a set of axioms which place constraints on sets of individuals, meaning classes, and the types of relationships permitted between them. These axioms provide semantics by allowing computers to infer additional information based on the data explicitly provided.

Semantic web rule language (SWRL)

SWRL [20] combines OWL with a subset of the Rule Markup Language (RuleML). It is a proposed rule language for the Semantic Web. SWRL adds rules at the cost of undecidability and lack of complete implementation. A SWRL rule consists of an antecedent (body) and a consequent (head).

7.3. SWRL rules

ASAM OpenXOntology uses the Semantic Web Rule Language (SWRL) to express rules for inference and reasoning.

7.3.1. Function of the SWRL rules

A SWRL rule enables a reasoner to derive a new fact from facts that have been expressed explicitly in the ontology. Furthermore, a SWRL rule acts as a constraint if a derived fact contradicts pre-existing facts. For example, if a SWRL rule states that the subject of a driving activity is a vehicle, and an ABox asserts that the subject of a driving activity is a pedestrian, the reasoner decides that the subject of the driving activity is both a pedestrian and a vehicle. If the ontology states that pedestrians are not vehicles, this results in a contradiction and the reasoner indicates a semantic error.

SWRL rules combine a set of preconditions with usually just one consequence condition. In ASAM OpenXOntology, there shall be at least one and a maximum of ten preconditions. There shall be only one resultant consequence condition.

In the examples below, preconditions are enclosed in curved brackets and consequence conditions are enclosed in square brackets.

7.3.2. How to write rules

The following rules apply to writing SWRL rules for ASAM OpenXOntology:

  1. The SWRL rules shall comply to this format:

    if conditionA1 and conditionA2 ... and conditionAn, then conditionC.

    conditionAx is a single precondition. conditionC is a single consequence condition.

  2. An OR relation between two conditions shall be expressed with two separate rules.

    Example 1. OR relationship

    A SWRL rule that states that if vehicleX is the subject of either an overtake activity or a following activity with the object of the activity being vehicleY, then vehicleX is behind vehicleY could be expressed as follows:

    if (activityZ is an overtake activity) or (activityZ is a following activity) and (vehicleX is the subject of activityZ) and (vehicleY is the object of activityZ), then [vehicleX is behind vehicleY]

    To comply with the ASAM OpenXOntology specification, this SWRL rule shall be split in two as follows:

    if (activityZ is an overtake activity) and (vehicleX is the subject of activityZ) and (vehicleY is the object of activityZ), then [vehicleX is behind vehicleY].
    
    if (activityZ is a following activity) and (vehicleX is the subject of activityZ) and (vehicleY is the object of activityZ), then [vehicleX is behind vehicleY].
  3. Each condition shall express a relationship between two ontology entities. An ontology entity may be any concept or individual in the ontology.​ In most cases in the OpenX domain, at least one of the concepts is some physical object, for example, a vehicle, a pedestrian, a road, a stop sign, or some rain.

    The following are all valid examples of conditions:

    Table 4. Valid conditions and descriptions
    Condition Description

    vehicleX is a Ambulance; laneY is a Lane

    Stating the type of an individual.

    vehicleX has location laneY

    Relates an actor to a location.

    vehicleX has speed greater than 100 km/h

    Relates a physical object to some state parameter.

    vehicleX is in front of vehicleY

    Relates two actors.

    vehicleX is subject of an overtaking activity

    Relates an actor to some activity it does.

    vehicleX is not a truck

    Expresses a negation.

    roadA is not icy

    Expresses a negation of characteristic.

  4. Anything that cannot be expressed using these rules shall be written in natural language and stored in the annotations of ASAM OpenXOntology. The description in natural language should be clear and concise. Each condition should be described separately.

    Examples:

    • If a lane is connected to a center lane, then it must be to the right of any other lane that is part of the same road segment and has the same direction​.

    • If Y is the subject of activity A and X is a temporal part of Y, then X is also the subject of activity A​.

    • If Y is the object of activity A and X is a part of Y, then X is also the object of activity A​.

    • If two vehicles are driving straight at the same time and vehicle A is in front of vehicle B, then vehicle B’s driving activity is also a following activity​.

    • If X is the subject of an activity whose object is lane L, then X is located on L.

7.3.3. SWRL rules in ASAM OpenXOntology

Table 5. SWRL rules
Name Rule

behind transitivity

autogen1:behind(?x, ?y) ^ autogen1:behind(?y, ?z) → autogen1:behind(?x, ?z)

front of transitivity

autogen1:inFrontOf(?x, ?y) ^ autogen1:inFrontOf(?y, ?z) → autogen1:inFrontOf(?x, ?z)

greater than or equal to

autogen1:PhysicalQuantity(?q1) ^ autogen1:PhysicalQuantity(?q2) ^ autogen1:hasValue(?q1, ?q1val) ^ autogen1:hasValue(?q2, ?q2val) ^ swrlb:greaterThanOrEqual(?q1val, ?q2val) → autogen1:quantityGreaterThanOrEqualTo(?q2, ?q1)

left of transitivity

autogen1:leftOf(?x, ?y) ^ autogen1:leftOf(?y, ?z) → autogen1:leftOf(?x, ?z)

new behind

autogen1:PhysicalObjectState(?p1) ^ autogen1:PhysicalObjectState(?p2) ^ autogen1:DirectionQuantity(?p1h) ^ autogen1:hasHeading(?p1, ?p1h) ^ autogen1:SpatialRelation(?r) ^ autogen1:hasSpatialSubject(?r, ?p1) ^ autogen1:hasSpatialObject(?r, ?p2) ^ autogen1:DirectionQuantity(?rdir1) ^ autogen1:DirectionQuantity(?rdir2) ^ autogen1:hasRelationDirection(?r, ?rdir1) ^ autogen1:hasValue(?p1h, ?p1hvalue) ^ autogen1:hasValue(?rdir1, ?rdir1value) ^ swrlb:subtract(?dirDiff, ?rdir1value, ?p1hvalue) ^ swrlb:lessThan(?dirDiff, 195) ^ swrlb:greaterThan(?dirDiff, 165) → autogen1:behind(?p2, ?p1)

new in front of

autogen1:PhysicalObjectState(?p1) ^ autogen1:PhysicalObjectState(?p2) ^ autogen1:DirectionQuantity(?p1h) ^ autogen1:hasHeading(?p1, ?p1h) ^ autogen1:SpatialRelation(?r) ^ autogen1:hasSpatialSubject(?r, ?p1) ^ autogen1:hasSpatialObject(?r, ?p2) ^ autogen1:DirectionQuantity(?rdir1) ^ autogen1:DirectionQuantity(?rdir2) ^ autogen1:hasRelationDirection(?r, ?rdir1) ^ autogen1:hasValue(?p1h, ?p1hvalue) ^ autogen1:hasValue(?rdir1, ?rdir1value) ^ swrlb:subtract(?dirDiff, ?rdir1value, ?p1hvalue) ^ swrlb:lessThan(?dirDiff, 15) ^ swrlb:greaterThan(?dirDiff, -15) → autogen1:inFrontOf(?p2, ?p1)

new left of

autogen1:PhysicalObjectState(?p1) ^ autogen1:PhysicalObjectState(?p2) ^ autogen1:DirectionQuantity(?p1h) ^ autogen1:hasHeading(?p1, ?p1h) ^ autogen1:SpatialRelation(?r) ^ autogen1:hasSpatialSubject(?r, ?p1) ^ autogen1:hasSpatialObject(?r, ?p2) ^ autogen1:DirectionQuantity(?rdir1) ^ autogen1:DirectionQuantity(?rdir2) ^ autogen1:hasRelationDirection(?r, ?rdir1) ^ autogen1:hasValue(?p1h, ?p1hvalue) ^ autogen1:hasValue(?rdir1, ?rdir1value) ^ swrlb:subtract(?dirDiff, ?rdir1value, ?p1hvalue) ^ swrlb:lessThan(?dirDiff, -75) ^ swrlb:greaterThan(?dirDiff, -105) → autogen1:leftOf(?p2, ?p1)

new right of

autogen1:PhysicalObjectState(?p1) ^ autogen1:PhysicalObjectState(?p2) ^ autogen1:DirectionQuantity(?p1h) ^ autogen1:hasHeading(?p1, ?p1h) ^ autogen1:SpatialRelation(?r) ^ autogen1:hasSpatialSubject(?r, ?p1) ^ autogen1:hasSpatialObject(?r, ?p2) ^ autogen1:DirectionQuantity(?rdir1) ^ autogen1:DirectionQuantity(?rdir2) ^ autogen1:hasRelationDirection(?r, ?rdir1) ^ autogen1:hasValue(?p1h, ?p1hvalue) ^ autogen1:hasValue(?rdir1, ?rdir1value) ^ swrlb:subtract(?dirDiff, ?rdir1value, ?p1hvalue) ^ swrlb:lessThan(?dirDiff, 105) ^ swrlb:greaterThan(?dirDiff, 75) → autogen1:rightOf(?p2, ?p1)

occurs after transitivity

autogen1:occursAfter(?x, ?y) ^ autogen1:occursAfter(?y, ?z) → autogen1:occursAfter(?x, ?z)

occurs before transitivity

autogen1:occursBefore(?x, ?y) ^ autogen1:occursBefore(?y, ?z) → autogen1:occursBefore(?x, ?z)

quantity approximately equal to

autogen1:PhysicalQuantity(?q1) ^ autogen1:PhysicalQuantity(?q2) ^ autogen1:hasValue(?q1, ?q1val) ^ autogen1:hasValue(?q2, ?q2val) ^ swrlb:subtract(?qdiff, ?q2val, ?q1val) ^ swrlb:multiply(?qmax, ?q2val, 0.1) ^ swrlb:multiply(?qmin, ?q2val, -0.1) ^ swrlb:lessThan(?qdiff, ?qmax) ^ swrlb:greaterThan(?qdiff, ?qmin) → autogen1:approximatelyEqualTo(?q2, ?q1)

quantity equal to

autogen1:PhysicalQuantity(?q1) ^ autogen1:PhysicalQuantity(?q2) ^ autogen1:hasValue(?q1, ?q1val) ^ autogen1:hasValue(?q2, ?q2val) ^ swrlb:add(?q2val, ?q1val, 0.0) → autogen1:quantityEqualTo(?q2, ?q1)

quantity greater than

autogen1:PhysicalQuantity(?q1) ^ autogen1:PhysicalQuantity(?q2) ^ autogen1:hasValue(?q1, ?q1val) ^ autogen1:hasValue(?q2, ?q2val) ^ swrlb:greaterThan(?q1val, ?q2val) → autogen1:quantityGreaterThan(?q2, ?q1)

quantity less than

autogen1:PhysicalQuantity(?q1) ^ autogen1:PhysicalQuantity(?q2) ^ autogen1:hasValue(?q1, ?q1val) ^ autogen1:hasValue(?q2, ?q2val) ^ swrlb:lessThan(?q1val, ?q2val) → autogen1:quantityLessThan(?q2, ?q1)

quantity less than or equal to

autogen1:PhysicalQuantity(?q1) ^ autogen1:PhysicalQuantity(?q2) ^ autogen1:hasValue(?q1, ?q1val) ^ autogen1:hasValue(?q2, ?q2val) ^ swrlb:lessThanOrEqual(?q1val, ?q2val) → autogen1:quantityLessThanOrEqualTo(?q2, ?q1)

quantity not equal to

autogen1:PhysicalQuantity(?q1) ^ autogen1:PhysicalQuantity(?q2) ^ autogen1:hasValue(?q1, ?q1val) ^ autogen1:hasValue(?q2, ?q2val) ^ swrlb:notEqual(?q1val, ?q2val) → autogen1:quantityNotEqualTo(?q2, ?q1)

right of transitivity

autogen1:rightOf(?x, ?y) ^ autogen1:rightOf(?y, ?z) → autogen1:rightOf(?x, ?z)

ASAM OpenXOntology contains SWRL rules on the core level, as shown in Table 5. To get an overview of the existing SWRL rules, you can use an appropriate ontology editor.

This version of ASAM OpenXOntology does not contain SWRL rules on the domain level.

Related topics

7.4. Quantities and parameters

This section explains how quantities and parameters are expressed and stored in ASAM OpenXOntology.

How to describe quantities

The current version of ASAM OpenXOntology provides a simple mechanism to describe quantities:

  1. The datatype property hasValue assigns a float value to a PhysicalQuantity.

  2. Each subclass of Quantity is defined to have a particular unit, usually the corresponding SI unit. For example, LengthQuantity is a subclass of PhysicalQuantity that represent lengths in the unit meters.

Example:

A particular road (roadA) is meant to have a width of 3 meters.

  1. A LengthQuantity, widthOfRoadA, is declared to be the width of roadA. roadA is a member of the class Road.

  2. A hasValue datatype property is declared to assign a float value of 3.0 to widthOfRoadA.

widthOfRoadA is the set of all things in the universe that have a length of 3 meters. That means, if vehicleX has a length of 3 meters, then lengthOfVehicleX, which is a member of LengthQuantity, is the same individual as widthOfRoadA. lengthOfVehicleX and widthOfRoadA are two different names for the same thing: the set of all things in the universe that have a length of 3 meters.

How to use quantities

Perform the following steps to use quantities:

  1. Define a quantity (for example, LengthQuantity, WidthQuantity) as subclass of PhysicalQuantity, if there is no existing one.

  2. Define a unit, for example, meter, as subclass of Unit, if there is no existing one.

  3. Optional: Define an object property, for example, hasLength or hasWidth, as subproperty of hasProperty.

  4. Assert quantities with values and units.

8. The core ontology

8.1. HQDM as the basis for the core ontology

ASAM OpenXOntology uses a well-proven architecture that supports semantic interoperability of ontologies: the division into top-level ontology (TLO), domain ontology, and application ontology.

The top-level ontology comprises classes for general concepts, such as physical objects, activities, and events, that are common across all domains. Each domain concept of ASAM OpenXOntology, for example, vehicle, scenario, and traffic participants, is based on one or more top-level level concept. The core ontology of ASAM OpenXOntology represents the top-level ontology.

ASAM OpenXOntology uses HQDM, the High-Quality Data Models Framework, as core ontology. HQDM represents a four-dimensional top-level ontology that is based on ISO 15926 [21].

8.1.1. Use of HQDM in ASAM OpenXOntology

The ASAM OpenXOntology core classes and relationships use the HQDM data model [22]. They represent a selection of HQDM elements that are required as a foundation for the concepts of the traffic domain that ASAM OpenXOntology represents. That means that HQDM is not fully included in ASAM OpenXOntology. Rather, selected HQDM concepts are used to model underlying concepts for the traffic domain, such as physical objects, events, activities, and states.

8.1.2. Set-based approach of HQDM

HQDM uses a set-based approach to ontology modeling, which means that classes are defined by their extension over a set of actual individuals. This allows for the use of set-based logical inference, for example, by first-order logic. In HQDM, everything is one of these:

  • Something that exists in time and space, like a vehicle. These are called spatio-temporal extents.

  • A set or tuple that groups things, like the ordered pair of one vehicle that is in front of another. These are called abstract objects.

HQDM does not use attributes to describe characteristics. Instead, all characteristics, specifications, and state variables that need to be represented in the ontology are represented using sets or tuples. That means that characteristics are defined as membership to sets. The characteristic “My car is red” means that the individual “My car” is a member of the set of all red things.

The actual sets are not defined in the ABox, but will be defined in the TBox as instances of the abstract object classes that ASAM OpenXOntology provides in the core ontology, for example, Set. HQDM uses multiple inheritance, so an individual can be part of more than one set.

Sample sets for cars
Figure 6. Sample sets for cars

Figure 6 shows the set-based approach of HQDM. It shows sets for cars, things with a specific color, and things with doors. All individuals, that is, car1, car2, and car3, belong to several sets. car1, for example, has 4 doors and is red. Because of these characteristics, it belongs to the sets Cars, Red Things, and Things with 4 doors.

8.2. Overview of the core classes

The ASAM OpenXOntology core classes and relationships use the HQDM data model. They represent a selection of HQDM elements that are required as a foundation for the concepts of the traffic domain that ASAM OpenXOntology represents.

All things modeled in ASAM OpenXOntology are divided into 2 fundamental concepts: spatio-temporal extents and abstract objects.

Spatio-temporal extents

Spatio-temporal extents are things that exist in space and time. They represent the reality, meaning the things that exist in the domain of road traffic. They are represented by the core class SpatioTemporalExtent, which includes the following concepts:

  • Physical objects: cars, roads, clouds, signs, buildings, people, engines, rain drops, etc.

  • Activities: moving, changing state, communicating, and weather phenomena like rain, snow, and wind.

  • Events: everything that occurs in an instance, such as the beginning or ending of an activity.

  • Periods of time the entire universe over a finite time.

  • Possible worlds: mechanism that HQDM uses to handle logical modality.

Abstract objects

Abstract objects are things that do not exist in space and time. They reflect our understanding of the real things. Abstract objects are represented by the core class AbstractObjects.

Abstract objects include:

  • Sets: A group of things, which can both spatio-temporal extents, sets, and/or tuples. Used to represent types or kind of things, for example, by common characteristics of set members.

  • Tuples: An ordered group of things (usually two), which may be spatio-temporal extents, sets, and/or tuples. Used to represent relationships, meaning the way that the first thing is related to the second, and so on. Tuples containing two things are most common and represent binary relationships between the two things, for example, that the first thing is a part of the second thing.

Related topics

8.2.1. Spatio-temporal extents as 4D representation of things

In HQDM, all things that exist in space and time are extended in four dimensions: three spatial and one temporal. ASAM OpenXOntology uses the class SpatioTemporalExtent to represent those things. This core class subsumes all other classes of actual things.

All spatio-temporal extents have a start event and an end event. An example is a vehicle whose lifetime starts when its manufacturing is complete and ends when the vehicle is dismantled.

There are two kinds of spatio-temporal extents: states and events.

OWL definition of SpatioTemporalExtent

The following model provides an overview of SpatioTemporalExtent:

Diagram
Element Description

Type

Class

Name

SpatioTemporalExtent

IRI

http://ontology.asam.net/ontologies/Core#SpatioTemporalExtent

Subclass of

CoreConcepts

Restriction

partOfPossibleWorld some PossibleWorld

Restriction

memberOf only SetOfSpatioTemporalExtents

Restriction

hasBeginning exactly 1 Event

Restriction

hasEnding exactly 1 Event

Comments

DEF: A thing that exists in time and space, meaning in four dimensions. Each spatio-temporal extent has a start event and an end event.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

Related topics

8.2.2. Events

Events are spatio-temporal extents with a time extension of zero, but with an extension in space. Events are represented by the core class Event. Events describe something that occurs in an instance, such as the beginning or ending of an activity or the lifetime of a physical object.

An example of an event is the instant when a vehicle stops moving.

OWL definition of Event

The following model provides an overview of Event:

Diagram
Element Description

Type

Class

Name

Event

IRI

http://ontology.asam.net/ontologies/Core#Event

Subclass of

SpatioTemporalExtent

Restriction

memberOf only SetOfEvents

Disjoint with

State

Comments

DEF: A SpatioTemporalExtent with a time extension of zero, but with an extension in space. Events mark changes in states and are used for something instantaneous.

EXAMPLES:

USAGE: Use this class to specify the state and/or end of activities and temporal parts of physical objects.

The subclass PointInTime is defined as an event that is the whole of space. Therefore, a PointInTime is the entire universe at an instant in time.

Example 2. Events

A particular time, such as 13:32 July 2, 2021, is a member of the class PointInTime.

A PointInTime can also be defined relative to another point in time, so the instant that occurs 5 seconds after a collision is also a PointInTime. This point in time covers the entire universe at that instant.

8.2.3. States and temporal parts of things

States are spatio-temporal extents with non-zero extension in both space and time. All things that have non-zero extension in space and time are states. This includes physical objects, such as vehicles, and activities, such as overtaking maneuvers.

A state may also represent a temporal part of a thing, meaning the thing over a particular time period. During that time period, the thing is characterized by a specific condition that does not change. Once the condition changes, a new temporal part is created. Thus, temporal parts are used to handle the identity of things through change. An example of a temporal part is a vehicle driving at 60 km/h on a specific road for 5 minutes.

Example 3. States and temporal parts of things

The vehicle V1 is waiting at a red line and therefore not moving until some point in time, at which point it starts moving. The instant in time when the vehicle starts moving may be represented as event t1. ASAM OpenXOntology uses states to represent temporal parts of the vehicle V1 for the event t1:

  • State V1notmoving is the temporal part of V1 from its beginning to t1. The fact that it is not moving is asserted by making it a member of the set of all non-moving things.

  • State V1moving is the temporal part of V1 from t1 to its end. The fact that it is moving is asserted by making it a member of the set of all moving things.

The event t1 represents the boundary in time between the two temporal parts of V1.

8.2.4. The state concepts of ASAM OpenXOntology

All things that have non-zero extension in space and time are states. The core class State provides multiple subclasses to model kinds of states, such as periods of time, physical objects, activities, and more.

OWL definition of State

The following model provides an overview of State:

Diagram
Element Description

Type

Class

Name

State

IRI

http://ontology.asam.net/ontologies/Core#State

Subclass of

SpatioTemporalExtent

Restriction

temporalPartOf some WholeLifeIndividual

Restriction

memberOf only SetOfStates

Comments

DEF: A SpatioTemporalExtent with non-zero extension in both space and time. Used to describe, for example, the state of a vehicle, a person, or a manufactured system like a factory. States can apply to the whole life of a thing or represent temporal parts of a thing,

EXAMPLES:

USAGE: Use this class to describe the temporal part of a whole-life individual to which some property applies or to describe the temporal part of a whole-life individual that participates in an activity.

The core ontology of ASAM OpenXOntology contains the following subclasses for State:

  • PeriodOfTime: Analogous to PointInTime in Event, PeriodOfTime is a subclass of State that is the whole of space. Therefore, PeriodOfTime is the entire universe over a particular period of time. A particular time interval, such as June 21, 2011, is a member of the class PeriodOfTime.

    • PossibleWorld: A PeriodOfTime that covers all of time. Therefore, PossibleWorld is the entire universe for all of time. This is then the universe we live in. However, possible worlds may also represent different possible universes with pasts or futures that differ from the one we experience.

      This class shall be used to model modality, such as several possible planned futures. Example: a description could contain two possible worlds. The possible world where carA stopped at the pedestrian crossing and where carA did not stop.

  • PhysicalObjectState: represents all physical objects, including temporal parts of physical objects.

    Examples of PhysicalObjectState include just about all tangible things that are modeled in ASAM OpenXOntology, such as vehicles, pedestrians, roads, and trees. The actual classes for these specific things, for example, for vehicles are created in the domain ontology as subclasses of the corresponding core ontology class.

  • SpatialLocation: represents all spatio-temporal extents that have continuity of relative position. A SpatialLocation describes a position, an area, or a space that is important in a defined context. A SpatialLocation can be described in various ways, such as by topology, topography, or coordinates. Examples of SpatialLocation are the position of an object, a zoning area, or a country where certain traffic regulations apply.

  • ActivityState: Represents activities that consists of their participants and cause some Event. Participants are individuals of PhysicalObjectState that participate in activities. The end event of an activity is caused by that activity, which implies that the activity describes some change between the start event and end event. That means that an activity describes what changes in a state over time. Examples of activities are lane changes, rain falling, and gathering of sensor information.

  • IntentionallyConstructedObjectState: HQDM defines intentionally constructed objects as states that exist because of an act of will or agreement. That means that individuals of IntentionallyConstructedObjectState are constructed intentionally by one or more things that have intent, usually humans or robots. Examples of intentionally constructed objects are vehicles, roads, road regulations, and a plan to turn left.

    Because many physical objects and even activities are constructed by humans, those things are also members of the class IntentionallyConstructedObjectState.
    • SociallyConstructedObjectState: HQDM defines socially constructed objects as intentionally constructed objects that are necessarily constructed by agreement of or acceptance by many people in a social community. Examples of socially constructed objects are contracts, companies, and money.

    • IntentionallyConstructedActivityState: An activity that is also an IntentionallyConstructedObjectState and describes planned activities by single persons or intelligent devices.

      Examples are the changing of a signal state by a device in an intelligent transportation system and the plan of a driver to make a right turn at a junction.

    • SociallyConstructedActivityState: An activity that is also a SociallyConstructedObjectState. It describes planned activities by a group of persons or intelligent devices.

      Examples are planned activities between multiple people such as meetings and the coordination of multiple traffic signals in an intelligent transportation system.

  • WholeLifeIndividual: HQDM differs between the whole life of things and temporal parts. Therefore, a whole-life individual represents the whole life of a particular thing, for example, of a physical object like a car.

Related topics

8.2.5. Temporal parts of things and the whole life of things

HQDM differs between the whole life of things and temporal parts.

Whole-life individual

A whole-life individual is a state that is not a temporal part of any other state that is of the same kind. Therefore, a whole-life individual represents the whole life of a particular thing, for example, of a physical object like a car or an activity like a car making a right turn.

To represent whole-life individuals, ASAM OpenXOntology uses the HQDM concept WholeLifeIndividual.

PhysicalObjectState, ActivityState and IntentionallyConstructedObjectState have corresponding WholeLifeIndividual subclasses: WholeLifePhysicalObject, WholeLifeActivity, WholeLifeIntentionallyConstructedObject and WholeLifeSociallyConstructedObject.

OWL definition of WholeLifeIndividual

The following model provides an overview of WholeLifeIndividual:

Diagram
Element Description

Type

Class

Name

WholeLifeIndividual

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeIndividual

Subclass of

State

Comments

DEF: A State that is not a proper temporalPartOf any other individual of the same kind.

EXAMPLES:

USAGE: Use this class in combination with others to designate that a particular spatio-temporal extent is "its whole life"

WholeLifeIndividual may be used in an ABox to indicate the thing that has states participating in various ways in a particular situation. An example is a truck that has a State of moving at 100 km/h on the motorway and a State of crashed into the side of the road.

Temporal parts (states)

During its lifetime, a whole-life physical object like a car takes part in different activities.

For each participation in an activity, ASAM OpenXOntology uses a member of the class State to model a temporal part that represents the thing during the activity or event.

Usually, in the traffic domain, a physical object of interest, such as a vehicle making a left turn, is almost always not the complete whole life individual. In most cases, those individuals should be modeled as members of the class State, rather than WholeLifeIndividual.

In the following, physical object is used in the context that anything is a WholeLifePhysicalObject and/or a PhysicalObjectState. Activity is used in the context that anything is a WholeLifeActivity and/or an ActivityState.

Example 4. Temporal parts

The individual that is the complete lifespan of a traffic sign from the instant it is manufactured to the instant that it is disassembled is a member of WholeLifeIndividual.

It is not a temporal part of any other individual representing some temporal part of that traffic sign.

On the other hand, the individual that is the traffic sign for the duration that it is installed on a particular intersection is a temporal part of the whole-life individual that does not include the manufacture of the sign at the factory and the shipping of the sign to the installation site. The second individual is modeled as a state.

8.2.6. Interaction of events, physical objects, and activities

During its lifetime, a whole-life physical object, such as a vehicle, takes part in different activities. For each participation in an activity, ASAM OpenXOntology models a temporal part of the particular whole-life thing that represents the thing during the activity or event.

Example: The whole-life thing can be a specific car. The temporal part is this car making a left turn.

Temporal parts are represented by the class State. Temporal parts of whole-life physical objects that participate in activities are also members of the class Participant, which is a subclass of State > PhysicalObjectState.

When describing the dynamics of something like a car using a series of states, each state is related to the thing (usually a WholeLifeIndividual) by temporalPartOf. This makes it clear that those states are all temporal parts of the thing whose dynamics are being described.

The participantOf object property, which is a subproperty of partOf, is a relationship pair that indicates that the first thing in the pair is a temporal part of a whole-life object that is participating in the second thing in the pair, which is an activity. The subproperties of participantOf - subjectOf and objectOf - indicate whether the participant is the subject or object of the activity, respectively.

Unlike temporalPartOf and its subproperties beginningOf and endingOf, participantOf and its subproperties do not describe a temporal division, meaning the participants of an activity are not temporal parts of that activity.
Example 5. Example of physical objects, events, and activities

An example of the interaction of whole-life objects, temporal parts of physical objects, and activities is an overtaking maneuver on a motorway. This maneuver may be described in an OpenSCENARIO 1.1.1 file as scenario0.

800
Figure 7. Sample scenario

Figure 7 shows the maneuver.

The maneuver is a member of WholeLifeActivity, and several members of WholeLifePhysicalObjects participate in the scenario, such as cars, motorcycles, lanes, and more. The temporal parts of those physical objects are represented as members of Participant, which is a subclass of State > PhysicalObjectState. Events determine the start and end of the activities.

The activities specify what changes between the events:

  • In the activity drivingStraight0_0, the temporal part motorcycleQ0_0 of motorcycleQ passes the temporal part carL1_0 of carL.

    Event pass1to0 is the end event of the activity.

  • In the activity laneChange0_1, the temporal part motorcycleQ0_1 of motorcycleQ changes the lane.

    Event pass2to0 is the end event of the activity.

  • In the activity drivingStraight0_2, the temporal part motorcycleQ0_2 of motorcycleQ drives in front of carL and increases the distance between both vehicles.

8.2.7. Physical objects

The PhysicalObjectState class and its subclasses represent physical objects, such as cars, functional objects, such as traffic signs, and installed systems, such as the road infrastructure.

According to HQDM, a PhysicalObjectState is a state that “consists of a distribution of matter and/or energy”. A PhysicalObjectState is understood to have a bounded distribution; it can be identified as that parcel of matter and/or energy over time. A PhysicalObjectState is characterized by what does not change over time.

A PhysicalObjectState may be divided into parts:

  • Spatial parts (composition) using the partOf object property.

  • Temporal parts using the temporalPartOf object property.

OWL definition of PhysicalObjectState

The following model provides an overview of PhysicalObjectState:

Diagram
Element Description

Type

Class

Name

PhysicalObjectState

IRI

http://ontology.asam.net/ontologies/Core#PhysicalObjectState

Subclass of

State

Restriction

memberOf only SetOfPhysicalObjectStates

Restriction

temporalPartOf only WholeLifePhysicalObject

Comments

DEF: A State that consists of a distribution of matter and/or energy. A PhysicalObjectState is understood to have a bounded distribution, and so it can be identified as that parcel of matter and/or energy over time. A PhysicalObjectState can be thought of as characterizing what does not change over time of a State.

EXAMPLES:

USAGE: Generally use a subclass of this class.

PhysicalObjectState contains the following subclasses:

  • Participant: Participants are physical object states that participate in one or more activities. Examples of participants are the temporal parts of some whole-life individual, such as a pedestrian or a car, that are doing some action, such as walking across the street.

    A Participant can usually also be classified as an OrdinaryBiologicalObjectState or OrdinaryFunctionalObjectState.
  • BiologicalObjectState: Biological objects are physical objects that sustain themselves and reproduce. Examples of biological objects are humans, animals, trees.

  • FunctionalObjectState: Functional objects are physical objects and intentionally constructed objects that are constructed with a particular function in mind. This function is represented by the intended role of that physical object. The role is assigned with the intendedRole object property. In particular, any artifact that is manufactured for a purpose is a functional object. This includes roads, vehicles, traffic signals, buildings, engines, and ADS controllers.

    An example of a thing that is PhysicalObjectState but not FunctionalObjectState or a BiologicalObjectState is a thing that was not created by humans for some purpose, such as a rock, a cloud, or a piece of garbage.
  • OrdinaryPhysicalObjectState: HQDM defines ordinary physical objects as physical objects that do not survive changing all their parts at once. This is usually true for the physical objects in the ASAM OpenXOntology domain. In general, all physical objects of the core ontology are also ordinary physical objects.

    An example of a thing that is PhysicalObjectState but not OrdinaryPhysicalObjectState is a system component, because a system component, such as a car’s engine, does survive changing all of its parts at once, for example, if the engine is replaced completely.
  • WholeLifePhysicalObject: Physical objects that are not temporal parts of any other physical object. This class may be used to represent a physical object that is its temporal whole. In most cases, however, one of the subclasses should be used.

Related topics

8.2.8. Systems and system components

ASAM OpenXOntology differentiates between the function of objects, including their membership in a functional system as a system component, and the actual materialized physical object itself. This makes it possible to define components of the traffic infrastructure, such as signs, for example, with a focus on their function. When the actual, tangible object is replaced, because a new sign is installed, the system component stays the same, but the ordinary physical object changes.

The following subclasses of PhysicalObjectState are used to model systems and their components:

  • SystemState: A OrdinaryPhysicalObjectState that represents a concrete materialized system.

    Systems are ordinary in the sense that they cease to exist when all of their parts are removed.

    They may be combined with OrdinaryBiologicalObjectState to represent biological systems, such as humans, trees, and forests.

    Systems are defined as an organized or connected group of physical objects, each of which comprises a component that plays a specific role in how the system functions.

    A SystemState may represent the whole life of the system or a temporal part of it.

    It is usually preferable to use the subclass FunctionalSystemState for intentionally constructed systems that have specific functions. An example of a SystemState that is not a FunctionalSystemState is a natural weather system.

    Most physical objects of the OpenX domain are systems, including cars, pedestrians, and roads. Exceptions might include things like road barriers and pylons, which are not meaningfully comprised of connected physical objects.
  • FunctionalSystemState: A OrdinaryFunctionalObjectState that is also a SystemState.

    This is the preferred class for representing temporal parts of concrete (actual, materialized) systems that cease to exist when all of their parts are removed, such as vehicles, traffic infrastructure, buildings, and traffic lights. They are often combined with OrdinaryBiologicalObjectState or OrdinaryFunctionalObjectState.

  • WholeLifeSystem: A SystemState that is also a WholeLifeOrdinaryPhysicalObject.

    This class may be used to represent a system that is its temporal whole. However, usually it is preferable to use the subclass WholeLifeFunctionalSystem for intentionally constructed systems that have specific functions.

    An example of a WholeLifeSystem that is not a WholeLifeFunctionalSystem is the entire life of a hurricane from when it is formed to when it ceases to exist.

  • WholeLifeFunctionalSystem: A FunctionalSystemState that is also a WholeLifeSystem.

    This class is the preferred way to represent a functional system that is its temporal whole, such as a vehicle from when it is manufactured to when it is destroyed.

  • SystemComponentState: A PhysicalObjectState that represents a component of a system. HQDM defines system component as a physical object that is a component of a system and that can be completely replaced without losing its identity.

    A SystemComponentState may represent the whole life of the component or a temporal part of it.

    The existence of a SystemComponentState depends on the system it is a component of. This is unlike ordinary whole-life physical objects that may be installed as the component during a part of their lifetime. A SystemComponentState may be completely replaced without losing its identity, so it is not an OrdinaryPhysicalObjectState.

    It is generally preferable to use the subclass FunctionalSystemComponentState for physical objects that are components of systems that have specific functions, meaning they are functional systems.
    System components are usually not OrdinaryPhysicalObjects because they retain their identity even if all of their parts are replaced simultaneously. An example is a speed limit traffic sign next to a motorway: the actual signal can be replaced but the new signal is still the speed limit signal at this point of the motorway.
  • FunctionalSystemComponentState: A FunctionalObjectState that is also a SystemComponentState. Represents a replaceable component of a FunctionalSystem.

    The object property componentOf is used to relate the object to the FunctionalSystem.

    A FunctionalSystemComponentState may be the whole life of the component or a temporal part of it.

    This class is the preferred way to represent the components of systems that were created for a specific purpose, for example markings of road or engines of vehicles, that is, as components, not as installed material objects - see InstalledObject below.

  • WholeLifeSystemComponent: A SystemComponentState that is also a WholeLifePhysicalObject. This class may be used to represent a system component that is its temporal whole, meaning the whole life of a system component, which normally has the same duration as the system it is a component of.

    However, usually the subclass WholeLifeFunctionalSystemComponent should be used for components of intentionally constructed systems that have specific functions.

    An example of a WholeLifeSystemComponent that is not a WholeLifeFunctionalSystemComponent is the eye of a hurricane.

  • WholeLifeFunctionalSystemComponent: A FunctionalSystemComponentState that is also a WholeLifeSystemComponent. This class is the preferred way to represent the whole life of a component of a functional system, such as the component of a junction that is a traffic light, which functions as a signal at a junction, meaning not the individual traffic lights with their serial numbers and dates of production, but the traffic light as a functional component.

    A WholeLifeSystemComponent may be temporarily divided into FunctionalSystemComponentStates for each of the InstalledObjects that acted as the component over the lifetime of the functional system.

  • InstalledObject: An OrdinaryPhysicalObjectState that is installed in a system, meaning that is also a SystemComponentState.

    Represents the state of the ordinary physical object that is the temporal part covering the time from when the ordinary physical object is actually installed in the system to when it is removed.

    An example is the temporal part of the traffic sign with the serial number 42 that is installed at a specific location on highway 66.

    The class InstalledFunctionalSystemComponent, which is a subclass of InstalledObject, should be used in this case, because it indicates that the object is installed in a functional system, and the highway is a functional system.
  • InstalledFunctionalSystemComponent: A FunctionalSystemComponentState that is also a InstalledObject. This class is the preferred way to represent the actual, materialized installed components of a functional system, such as the individual traffic lights with their serial numbers and dates of production when they are actually installed and functioning as components of a junction.

Example 6. System and system components

This example illustrates how the classes FunctionalSystemComponentState and OrdinaryPhysicalObjectState are used to describe the dynamics of a traffic signal that is located at a motorway and is replaced.

The traffic signal exists in the following two aspects:

  1. As a component of the traffic infrastructure, meaning it is a functional system component (member of FunctionalSystemComponentState).

  2. As an ordinary physical object that was manufactured somewhere and has a particular mass, color, etc. (member of OrdinaryPhysicalObjectState).

The functional system component is an integral component of the traffic infrastructure system. This means, the component exists in some form as long as the traffic infrastructure exists and has the traffic signal as a component. However, the particular "materialized" ordinary physical object that is acting as the system component may change many times over the systems lifetime. For example, if the installed signal is destroyed, a new signal must be installed. The new signal still works in the same system component, but it becomes a new ordinary physical object with possibly different manufacturer, color, size, etc.

1000
Figure 8. Example of traffic light as functional system component

Figure 8 shows the traffic light as functional system component and physical object.

8.2.9. Abstract objects

The second fundamental class of the ASAM OpenXOntology core is AbstractObject. Abstract objects are all things that are not spatio-temporal extents, which means all things that do not exist in space and time. Abstract objects are used to express facts about spatio-temporal extents, such as physical properties, physical quantities, roles, and relationships.

AbstractObject has two subclasses: Set and Relationship.

OWL definition of AbstractObject

The following model provides an overview of AbstractObject:

Diagram
Element Description

Type

Class

Name

AbstractObject

IRI

http://ontology.asam.net/ontologies/Core#AbstractObject

Subclass of

CoreConcepts

Disjoint with

SpatioTemporalExtent

Comments

DEF: A thing that does not exist in space or time. Abstract objects are used to express characteristics of spatio-temporal extents, such as properties and roles.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

8.2.10. Sets

HQDM defines a Set as an abstract object that “has members and whose identity is defined by its members”. The members may be relationships or other sets as well as specific spatio-temporal extents.

Subclasses of Set are generally available for all subclasses of SpatioTemporalExtent. However, the ASAM OpenXOntology core currently only includes subclasses of Set for SpatioTemporalExtent and its main subclasses: Event, State, ActivityState, PhysicalObjectState, Participant and WholeLifeIndividual. That means, SetOfSpatioTemporalExtents is a set whose members are all spatio-temporal extents. SetOfStates is a set whose members are all states, and so on.

Members of these classes are used to describe specific sets of the corresponding things that are not already defined as subclasses of that thing in the ontology. For example, use a member of the class SetOfPhysicalObjects to describe specific sets or kinds of PhysicalObjectStates that are not available already as subclasses of PhysicalObjectState.

OWL definition of Set

The following model provides an overview of Set:

Diagram
Element Description

Type

Class

Name

Set

IRI

http://ontology.asam.net/ontologies/Core#Set

Subclass of

AbstractObject

Comments

DEF: An AbstractObject that has members and whose identity is defined by those members. The members may be other sets as well as specific spatio-temporal extents.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

The subclasses of Set include:

  • Role is a SetOfParticipants where all participants in the set share some particular kind of role by participating in the same way in an activity.

    Examples of Role are purposes, such as being for transportation or agriculture use, as well as more general roles, such as creator, owner, consumer, controller, asset, and more.

  • PhysicalProperty is a SetOfStates that represents some characteristic that each of the member states possesses. Member states may be activities, events, or physical objects.

    More accurately, a PhysicalProperty is a Set that groups states by a specific characteristic, but PhysicalProperty is understood to be the specific characteristic shared by its members. That means, a member of PhysicalProperty is just a characteristic of all states that are members of the PhysicalProperty as a SetOfStates.

    Examples of PhysicalProperty are the color red, a triangle shape, the material surface characteristic of being rough, or the particular duration of an acceleration activity.

  • Geometry is a PhysicalProperty that describes a spatial characteristic of an object in a 1D, 2D, or 3D space.

    While shape only refers to the outer surface, Geometry includes other spatial characteristics, for example different kinds of projection, such as cross section and road geometry.
    According to ISO 15926, shape is a property that depends on constant relations of position and proportionate distance among all the points composing its outline or its external surface.
  • PhysicalQuantity is a PhysicalProperty that is a measurable quantity of some kind of physical quantity. This is similar to the model of quantities used by QUDT [23], which defines quantity as “a measure of an observable phenomenon, that, when associated with something, becomes a property of that thing; a particular object, event, or physical system.”

    Examples of PhysicalQuantity are the velocity of a particular car, the distance between two cities, and the width of a particular road segment.

    ASAM OpenXOntology provides subclasses of PhysicalQuantity for common quantities, such as DirectionQuantity, LengthQuantity, SpeedQuantity, and AngleQuantity.

8.2.11. Relationships

Members of the Relationship class are abstract objects that represent the relations between things, that is, what one thing has to do with one or more other things.

OWL definition of Relationship

The following model provides an overview of Relationship:

Diagram
Element Description

Type

Class

Name

Relationship

IRI

http://ontology.asam.net/ontologies/Core#Relationship

Subclass of

AbstractObject

Comments

DEF: Relationships form the basis for many object properties.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

The following relationship classes are available:

  • Aggregation: A Relationship where the whole is at least the sum of the parts. Basis for object property aggregatedInto.

    • Composition: An Aggregation where the whole is an arrangement of the parts that results in emergent properties. Basis for object properties partOf and hasPart.

    • TemporalComposition: A Composition where the part is the entire whole spatially, but part of the whole temporally. Basis for object properties temporalPartOf and hasTemporalPart.

  • Classification: A Relationship where a thing is a member of a class. Basis for object properties memberOf and hasMember.

  • DefinedRelationship: A class provided by HQDM to express relationships of a particular kind. In the OpenX domain, the following kinds of relationships are identified to be important in addition to composition and classification:

    • TemporalRelation: A DefinedRelationship that describes a temporal relationship between two things, usually between events. Basis for the object properties occursBefore, occursAfter, and similar.

    • ConnectionRelation: A DefinedRelationship for relations between things that are connected in any way, physically or otherwise. Basis for the object property connectedTo. Use this class to express a connection between two things as a reified relationship, for example, in order to specify characteristics, such as the angle of the connection.

    • SpatialRelation: A DefinedRelationship between two physical objects that describes their directional relationship, not the distance. Basis for object properties such as rightOf, leftOf, inFrontOf, behind, and more. A SpatialRelation must have a direction that is a DirectionQuantity, a spatial object that is a PhysicalObjectState, and a spatial subject that is a PhysicalObjectState. A SpatialRelation is not a TemporalRelation because the classes are disjoint. Use this class to express a general spatial relation between two things as a reified relationship, giving only the direction of the relationship.

8.3. Core properties

There are two types of property in an ontology:

  • Object properties specify how things are related to each other. They are the predicate in triples that have the form subject-predicate-object.

  • Datatype properties to assign datatypes to classes.

Related topics

8.3.1. Object properties in the ASAM OpenXOntology core

Object properties are a fundamental part of an ontology that supports logical inference. Object properties in the ASAM OpenXOntology are all binary tuples, meaning pairs. Therefore, an object property always specifies in an ordered pair how the first element of the pair relates to the second element of the pair. Examples:

  • hasPart specifies that the first element has the second element as a part.

  • behind specifies that the first element is located behind the second element.

Object properties may be assigned logical characteristics, such as transitivity and symmetry to reflect the underlying nature of the relationships that they represent. For example, partOf is transitive, while connectedTo is symmetric.

In addition, the classes of things that may be the first (domain) and second (range) elements of the binary tuple for a particular object property may be specified. So for the object property causes, the domain is ActivityState and the range is Event. Finally, object properties may be declared to be functional or inverse functional:

  • Functional: an individual may only be the first element of one instance of the object property

    An example of a functional object property is componentOf because a component can only be the component of one system.

  • Inverse functional: an individual may only be the second element of one instance of the object property.

    An example of an object property that is both functional and inverse functional is hasSpatialSubject, which connects a SpatialRelation to the thing that is the subject of the relation.

HQDM provides a minimal set of object properties mainly for specifying compositional and classification relationships. Compositional relationships are usually between spatio-temporal extents. For example, temporalPartOf connects a state to its whole-life individual, and componentOf connects a component of a system to the system that it is a component of. However, HQDM does not provide object properties for specifying participation relationships, spatial relationships, temporal ordering relationships, and connective relationships. The ASAM OpenXOntology core provides object properties for these kinds of relationships as well as for other basic relationships that are important in the OpenX domain. The ASAM OpenXOntology core also provides a set of object properties for relating the values of physical quantities.

8.3.2. Datatype properties in the core ontology

OWL uses datatype properties to assign datatypes to classes. The only datatype property defined in ASAM OpenXOntology is hasValue, which assigns a float value to each member of the class PhysicalQuantity.

Related topics

8.4. SWRL rules in the core ontology

ASAM OpenXOntology uses SWRL to define logical conditions (Horn clauses) that cannot be specified by only using the DL operators provided by OWL. HQDM does not use SWRL, the SWRL content in the ASAM OpenXOntology core has been added.

The following SWRL rules have been defined in the ASAM OpenXOntology core:

  • Transitivity of the object properties for spatial relationships: inFrontOf, behind, leftOf, rightOf, etc.

  • Transitivity of the object properties for temporal ordering: occursBefore, occursAfter

  • Definitions of the object properties for spatial relationships in terms of SpatialRelation

  • Definitions of the object properties for physical quantity relationship using the float values given by the hasValue datatype property

  • Definition of approximatelyEqualTo object property to accept values that are within 10% of each other

Related topics

9. The domain ontology

9.1. The harmonization process for the domain ontology

This section explains the harmonization process that the ASAM OpenXOntology domain group followed during the development of the domain ontology. The following questions are answered:

  • Which standards did the group consider?

  • How did the group extract the domain concepts from these standards?

  • How was an umbrella structure for the domain ontology chosen?

  • How did the group harmonize the extracted domain concepts and organize them within the umbrella structure?

  • How were new domain concepts identified?

  • How did the group use multiple inheritance of concepts to accommodate different classification methods?

  • How did the group decide on classification methods and the selection of domain classes?

9.1.1. Extraction of concepts for the domain ontology

At the beginning of the harmonization process, the group researched standards in order to decide which of them could serve as a basis for the ASAM OpenXOntology domain ontology. These included released ASAM standards, published non-ASAM standards, and work-in-progress (WIP) ASAM standards and concepts. For the WIP standards and concepts, communication and alignment were established between the ASAM OpenXOntology domain group and the standard/concept development groups.

There are additional standards that the ASAM OpenXOntology domain group has sought to harmonize with ASAM OpenXOntology. However, due to the scope and resources required, the ASAM OpenXOntology domain group did not choose to incorporate them in this version. Any results from such efforts are included as suggestions for future ASAM OpenXOntology versions.
Table 6. Alignment with other standards
Name ASAM standard/concept Still WIP? In alignment?

ASAM OpenSCENARIO 1.0.0

Yes

No

Yes

ASAM OpenSCENARIO 2.0.0

Yes

Yes

Not yet

ASAM OpenDRIVE 1.6.0

Yes

No

Yes

ASAM OpenODD Concept

Yes

Yes

Yes

ASAM OpenLABEL 1.0.0

Yes

Yes

Yes

ASAM OSI 3.3.0

Yes

No

Not yet

ASAM ODS

Yes

No

Not yet

BSI PAS 1883

No

No

Yes

ISO 34503

No

Yes

Yes

Table 6 shows the complete list of standards that were used during the harmonization phase.

General remarks

  • ASAM OpenSCENARIO 2.0, ASAM OSI, and ASAM ODS [24] have been taken into consideration, but not yet harmonized with ASAM OpenXOntology.

  • The final input to the ASAM OpenXOntology domain group is ASAM OpenSCENARIO 1.0, ASAM OpenDRIVE 1.6, and standards/concepts that take an operational domain design based approach: ASAM OpenODD, ASAM OpenLABEL 1.0, BSI PAS 1883, and ISO 34503.

On the use of BSI PAS 1883

  • BSI PAS 1883 introduces a taxonomy for describing the ODD of automated driving systems.

  • ISO 34503 is based on BSI PAS 1883 to further develop the taxonomy. Both the scenario-tagging domain model of OpenLABEL 1.0 and the domain model of OpenODD strongly reference BSI PAS 1883. Therefore, among the four ODD-based standards/concepts, there are coherent contributions to the ASAM OpenXOntology that follow the ODD taxonomy of BSI PAS 1883.

On the difference to standards at application level

  • ASAM OpenSCENARIO 1.0, ASAM OpenDRIVE 1.6, and ASAM OpenLABEL 1.0 are application-level standards whereas ASAM OpenODD is a domain-level standard. Application- level concepts, such as bounding box or simulation time, are not domain-related. Therefore, the first task in the harmonization process was to filter and extract the domain concepts from the application-level standards. Because operational domain design related standards are already targeting at the domain level, their concepts have been preserved during this stage.

The process of extracting domain concepts

To extract the domain concepts from ASAM OpenSCENARIO 1.0, ASAM OpenDRIVE 1.6, and ASAM OpenLABEL 1.0, the domain group was divided into several subgroups, each consisting of experts for these standards. Each subgroup extracted domain concepts from the standards that were easy to identify.

Some concepts, however, were difficult to identify during this first stage. For such concepts, three methods were applied to determine their domain relevance.

  1. Assume that if a concept appears in more than one application standard, it must be considered until other methods exclude it.

  2. A vote within the project group. If the majority classifies a concept as an application-level concept, that concept is removed from the domain ontology.

  3. Construct a hypothetical driving context of interest and then select the concepts from the other standards that can be used to describe the driving context.

    Three driving contexts were constructed at the beginning of the project for such purpose. In addition, the group developed the minimum-working-product (MWP) example that uses a series of examples to demonstrate the capability of the ontology.

In this way, the group was able to fill in any missing concepts that were not in the ontology at that time.

In addition to these methods, the project groups had several discussions with the members of the other project group about the mentioned standards and received confirmation from them.

9.1.2. Integration of domain concepts into the umbrella structure

After extracting the domain concepts, the next step was to organize them and fit them into an umbrella structure.

Operational domain design and a behavior-based approach

An operational domain design and a behavior-based approach to describe road-traffic situations in the automated driving system environment have gained popularity in industry and academia. The important role of the operational domain design within the safety assurance of automated driving systems is widely recognized. The objective of the ASAM OpenODD concept project highlights the importance, as does the operational domain design-based and behavior-based approach for the ASAM OpenLABEL scenario-tagging model.

Structure of the extracted domain concepts

The previously extracted domain concepts are not organized in a structure because the application-level standards are not structured according to domain classification.

Structure of the operational domain design-based domain model

The operational domain design-based domain model or taxonomy provides a good domain classification for road topology, traffic infrastructure, and environmental conditions. The only elements that are not reflected completely by the operational domain design-based model are traffic participant and dynamic behavior. For that reason, the group voted to use the operational domain design-based classification as umbrella structure for sorting the extracted domain concepts. A bottom-up approach was developed for the behavioral-domain concepts to define their structure. The umbrella structure contains:

  • Road topology and traffic infrastructure

  • Traffic participants and dynamic behavior

  • Environmental conditions, which include weather-related environmental conditions and connectivity characteristics

This high-level structure is also in line with the proposal made during the concept phase of the project. The only difference is that environmental conditions and connectivity have been merged into one environmental condition branch.

9.1.3. Sorting of the extracted concepts

The extracted concepts were sorted based on these three main categories. However, an ODD-based umbrella structure does not fully reflect dynamic aspects, especially regarding the categorization of behavior and traffic participants.

To address this issue, the group started to gather input from ASAM OpenX members on behavioral concepts, resulting in an extensive list of behavioral concepts.

The domain group then collected suggestions within the group to establish possible structures for organizing these behavioral concepts. More than twenty different proposals for potential organizational structures were received. A voting process was initiated to select the best structures for these behavioral concepts, resulting in a set of final structures.

For example, a behavior, such as making a turn, can be categorized in the following ways:

  • By the type of state changing, in this case a moving activity.

  • By its relation to other participants, in this case a single-participant activity.

  • By the type of participant, in this case a vehicle activity.

With traditional modeling approaches, incorporating multiple categorization approaches can be challenging. However, OWL allows assigning multiple parent classes to the same concept. In this case, all completed structures are modeled as different inheritance branches for the same set of concepts. Ontology users can decide during the usage time which method they prefer.

9.2. Overview of the domain classes

ASAM OpenXOntology has the goal to provide a foundation of common definitions, attributes, and relationships for ASAM OpenX standards, such as ASAM OpenDRIVE, ASAM OpenSCENARIO, ASAM OpenLABEL, ASAM OpenODD, and others. All these standards deal with different aspects of a common domain: road traffic.

9.2.1. ASAM OpenXOntology as OpenX domain model

The domain ontology of ASAM OpenXOntology represents the common domain model for the OpenX standards. To ensure an efficient use of the ASAM OpenXOntology domain model in the OpenX standards, the following aspects are important:

  • Domain concepts shall be separated from application concepts. Application concepts shall be defined in application ontologies.

    Application ontologies contain concepts that the particular standard is allowed to modify without consulting any of the other standards. These are normally concepts that are only used in that specific standard.

  • Identical concepts that are defined in more than one ASAM OpenX standard shall be extracted and added to the domain ontology.

  • Similar concepts that are defined in more than one ASAM OpenX standard shall be harmonized and added to the domain ontology.

  • New concepts shall be added continuously as part of the ASAM OpenX development.

The OpenX standards that have contributed to ASAM OpenXOntology cover the following areas:

  • Road topology and traffic infrastructure

  • Traffic participants and their behavior

  • Ambient conditions

Related topics

9.2.2. Concepts for road topology and traffic infrastructure

The RoadTopologyAndTrafficInfrastructure class represents the top-most parent class for road topology and traffic infrastructure concepts.

OWL definition of RoadTopologyAndTrafficInfrastructure

The following model provides an overview of RoadTopologyAndTrafficInfrastructure:

Diagram
Element Description

Type

Class

Name

RoadTopologyAndTrafficInfrastructure

IRI

http://ontology.asam.net/ontologies/Domain#RoadTopologyAndTrafficInfrastructure

Subclass of

DomainConcepts

Comments

DEF: A set of features for describing the logical road network, traffic infrastructure elements, and related conditions.

The RoadTopologyAndTrafficInfrastructure class contains the following main concepts:

  • DrivableAreaElement provides subclasses for areas in the traffic infrastructure that vehicles are supposed and permitted to drive in.

    Examples: road, lane, road marking.

  • FixedRoadStructure contains subclasses for built or natural elements of the traffic infrastructure that are located near a drivable area but are not approved for traffic.

    Examples: building, streetlight, traffic island.

  • The subclasses in Junction represent different intersection types and roundabouts.

    Examples: T-intersection, staggered intersection.

  • SpecialStructure contains subclasses for elements of the road infrastructure that are located on top of the road network and through or on which traffic participants are permitted to travel.

    Examples: bridge, pedestrian crossing, tunnel.

  • TemporaryRoadStructure represents elements of the road infrastructure that only temporarily exist on top of the road network.

    Examples: construction site detour, roadblock, traffic cone.

  • In TrafficSign, different types of traffic signals are categorized according to their state or function.

    Examples: dynamic traffic signal, static signal, warning signal.

  • The TrafficZone class provides subclasses for geographic areas with special road configurations, driving regulations, or environmental conditions.

    Examples: geo-fenced zone, school zone, traffic management zone.

9.2.3. Concepts for traffic participants and their behavior

The TrafficParticipantAndBehavior class represents the top-most parent class for the concepts for vehicle types, traffic participants, and maneuvers.

OWL definition of TrafficParticipantAndBehavior

The following model provides an overview of TrafficParticipantAndBehavior:

Diagram
Element Description

Type

Class

Name

TrafficParticipantAndBehavior

IRI

http://ontology.asam.net/ontologies/Domain#TrafficParticipantAndBehavior

Subclass of

DomainConcepts

Comments

DEF: A set of activities, physical objects, and functional objects that describe traffic participants and their dynamic behavior.

The TrafficParticipantAndBehavior class contains the following main concepts:

  • The TrafficActivity class and its subclasses represent actions performed by traffic participants during a traffic situation, typically to achieve a specific goal, like changing a lane. Activities are categorized as follows:

    • Complexity of the action, ranging from primitive to mission level.

    • The number of participants.

    • The state changes.

    • The traffic participant type.

    Examples: cutting in, overtaking, waving, using hazard light, accelerating.

  • The TrafficFunctionalObject class defines types of vehicles.

    Examples: truck, van, public bus.

  • The TrafficParticipant class defines types of traffic participant. The subclasses represent different sets:

    • Groups of traffic participants by type, like humans or animals.

    • Groups by vulnerability of the participant.

    Examples: pedestrian, driver, animal, agricultural vehicle, emergency vehicle.

9.2.4. Concepts for ambient conditions

The EnvironmentalCondition class represents the top-most parent class for the concepts for environmental conditions, such as weather, illumination, and communication.

OWL definition of EnvironmentalCondition

The following model provides an overview of EnvironmentalCondition:

Diagram
Element Description

Type

Class

Name

EnvironmentalCondition

IRI

http://ontology.asam.net/ontologies/Domain#EnvironmentalCondition

Subclass of

DomainConcepts

Comments

DEF: A set of environmental parameters that applies to a complete area, such as a town or a district. Conditions can have natural causes, for example rain or snowfall, or can be created artificially, for example by light sources or communication devices using specific methods like vehice-to-vehicle communication.

The EnvironmentalCondition class contains the following main concepts:

  • The subclasses in ConnectivityCondition represent a vehicle’s ability to receive and transmit data in order to identify its position or communicate with other traffic participants.

    Examples: GPS, vehicle-to-vehicle communication.

  • The subclasses in IlluminationCondition describe the effect of light within a specific traffic situation. The scene may be illuminated, for example, by artificial or natural light.

    Examples: daylight, streetlight, vehicle light.

  • ParticulatesCondition categorizes environmental conditions that are characterized by specific particles which lead to a limited visibility or obscuration of things. Particles may be, for example, water drops or sand.

    Examples: fog, smoke, dust.

  • TimeCondition gives information about the time at which a specific traffic situation occurs, for example, a specific time of the day or a specific date in the year.

  • WeatherCondition contains subclasses for specific weather situations.

    Examples: rainfall, snow, wind, cloud coverage of the sky.

10. Using ASAM OpenXOntology

10.1. How to incorporate a new concept

This section explains how new concepts that are developed by an ASAM simulation standard become part of ASAM OpenXOntology. The following questions are answered:

  • How to integrate a new concept in ASAM OpenXOntology.

  • How to determine whether to integrate the new concept on core, domain, or application level.

  • How to determine the correct parent class(es).

incorporate oxo.drawio
Figure 9. Incorporate a new concept into OpenXOntology

Figure 9 shows the workflow proposed by ASAM OpenXOntology to incorporate a new concept.

Proceed as follows to integrate a concept into ASAM OpenXOntology:

  1. Compare your concept with the specification of ASAM OpenXOntology and the corresponding OWL file. Check whether the new concept corresponds to an existing domain concept or not.

    1. If the answer is YES, you shall use the existing domain concept directly.

    2. If the answer is NO, proceed with step 2.

  2. Check whether you can find a suitable parent class for your concept in the domain ontology. Example: A suitable parent class for childPedestrian (your concept) would be the domain class TrafficParticipant.

    1. NO: If you cannot find a suitable parent class on domain level, check the core ontology for a suitable parent class. Submit a change request to the ASAM OpenXOntology group to enable a mapping of the identified parent core class to the new domain concept.

    2. YES: If you find a suitable parent class at domain level, compare your concept with the subclasses of this parent class. Check whether one of the subclasses would be better suited as parent class. Repeat this step until you find a suitable class at the lowest possible level within the class hierarchy of the domain ontology.

      Result: Once you identified the lowest possible domain concept that can serve as parent class, you need to determine whether the new concept belongs to the domain ontology or should be added at application level (see orange box).

  3. Research whether any other ASAM simulation standard has a similar concept at application level that is related to the new concept. These concepts may already be linked to the domain concept that you identified in the previous step.

    1. If the answer is NO, your concept belongs to the application level. A new concept at application level shall be created. This concept shall be a subclass of the domain concept selected as suitable parent.

    2. If the answer is YES, proceed with step 4.

  4. Research whether your concept and the related application concepts that you identified in the previous step are fully equivalent.

    1. If the answer is YES, the concepts from the different ASAM standards shall be harmonized and incorporated as a new concept at domain level. To start this process, submit a change request to the ASAM OpenXOntology group.

    2. If the answer is NO, proceed with step 5.

  5. Decide whether your concept can be used as parent class for the identified application-level concept(s).

    1. If the answer is YES, your concept needs to be at domain level. Submit a corresponding change request to the ASAM OpenXOntology group.

    2. If the answer is NO, your concept needs to be harmonized with the other application-level concepts. Submit a corresponding change request to the ASAM OpenXOntology group.

10.1.1. Examples

Example 1

An ASAM standard drafted the new concept passenger car and run the process:

  1. Step 1: The project group examines the ASAM OpenXOntology specification and finds the class Car in the domain ontology. That means that the concept passenger car is mapped to the car concept at the domain level. No further steps are needed.

Example 2

An ASAM standard drafted the new concept Segway and run the process:

  1. Step 1: The project group examines the ASAM OpenXOntology specification, but there is no direct equivalent domain concept for Segway. However, there are superordinate concepts, such as Traffic participant, vehicle, and VRU.

  2. Step 2: The project group chooses the lowest possible domain concept that can be used as parent class. In this case either vehicle or VRU.

  3. Step 3: The project group researches whether there are other application-level concepts that are similar to Segway. They find one concept called airwheel X3.

  4. Step 4: The project group considers Segway as a superordinate concept that is needed at domain level. They submit a change request to the ASAM OpenXOntology group for harmonization.

10.2. Sample data journey in ASAM OpenX

10.2.1. Data journey with ASAM OpenXOntology and related OpenX standards

An underlying formal representation of the taxonomy for OpenX standards has many advantages, as described in the chapter on the motivation to create an ontology for ASAM. ASAM OpenXOntology can also further enrich existing use cases that leverage ASAM OpenX standards. This section demonstrates various examples of such enriched workflows compiled into a Minimum Working Product (MWP).

These are highly simplified examples that use a small subset of ASAM OpenXOntology. Currently, the full ASAM OpenXOntology does not support inference or reasoning.
The content of the data journey is non-normative.

A data journey was defined to show how ASAM OpenXOntology helps to connect all areas of the scenario-based testing workflow. The data journey comprises five phases, starting with labeling sensor data and ending with checking a simulated scenario against an operational domain design.

data journey openx
Figure 10. Phases of the data journey in the OpenX standard framework

Figure 10 shows the position of the MWP phases in the standardized workflow based on the OpenX standards.

The data journey comprises the following phases:

  1. Label sensor data with OpenLABEL annotations, see phase 1 of the data journey: Label sensor data.

  2. Check the data with a semantic application and infer knowledge, see phase 2 of the data journey: Check data and infer knowledge.

  3. Generate scenario details and export OpenSCENARIO 1.1.1 and OpenDRIVE files, see phase 3 of the data journey: Detail the scenario.

  4. Simulate the scenario, see phase 4 of the data journey: Simulate the scenario.

  5. Check the OSI stream against an ODD, see phase 5 of the data journey: Check against ODD.

userJourneyOverview
Figure 11. Data journey through the OpenX standards

Figure 11 shows a detailed overview of the journey.

TBox used for the data journey

ASAM OpenXOntology provides the TBox for generating ontology-based scenario descriptions and other data.

Tbox mwp
Figure 12. TBox for the data journey

Figure 12 shows the ontology classes in the data journey.

The TBox contains a subset of the classes from the core, domain, and application levels of OpenXOntology, as described in Architectural overview.

10.2.2. Phase 1 of the data journey: Label sensor data

In phase 1, sensor data is processed to generate OpenLABEL annotations for the physical objects detected in the sensor data, such as vehicles, lanes, and lane dividers. Annotations are first generated by a tool and second by a human annotator.

The input sensor data can be of different types, such as video footage or images.

The data journey uses the following traffic situation as an example:

  • The situation occurs on a two-lanes road in the city on a sunny day.

  • An ego vehicle (yellow) drives parallel to an ambulance and a red car. The ambulance and the red car drive on the second lane.

  • Both the ambulance and the red car pass the ego vehicle.

  • The ego vehicle changes to the right lane and drives behind ambulance and red car.

The following figures show the start and end scenes of the traffic situation.

mwp example start v3
Figure 13. Start scene of the traffic situation
mwp example passing
Figure 14. Traffic situation during the passing event
mwp example end v3
Figure 15. End scene of the traffic situation
Steps in phase 1
  1. A label annotation software processes the sensor data and identifies the traffic participants, the involved road infrastructure, and the environmental conditions.

  2. The label annotation software creates object labels using OpenLABEL syntax. OpenXOntology provides descriptions for the terms in the OpenLABEL syntax.

  3. The label annotation software stores the labels in JSON files.

  4. The OpenLABEL-formatted JSON files are converted to OWL triples, which are grounded in OpenXOntology. This step usually requires the addition of individuals and relationships because the label annotation software cannot detect all of the information required to describe the full situation. Currently, this must be done manually. To assist the human annotator, an ABox editing tool, such as EKOSS, can be used.

    In particular, for WholeLifeFunctionalSystem such as Vehicle that change their states over the time duration of interest, temporal parts of those WholeLifeFunctionalSystem shall be created as members of the class FunctionalSystemState. For example, egoCar0 begins in one lane and later moves to the other lane. To represent this, the annotator creates three FunctionalSystemState:

    • egoCar0_0 is the temporal part of the egoCar0 that is in lane1

    • egoCar0_1 is the temporal part of the egoCar0 that is changing lanes

    • egoCar0_0 is the temporal part of the egoCar0 that is in lane2.

      The annotator specifies the beginning and ending for each of the FunctionalSystemState as one of the Event marking important points of time, such as the start or end of one of the ActivityState.

      scenario events activities
      Figure 16. Interactions of scenario components

      Figure 16 shows the interactions of the Event, ActivityState, and FunctionalSystemState.

  5. The label annotator stores the enriched descriptions as an OWL file. This OWL file represents a complete ABox expressing the road traffic situation.

In this phase, only basic consistency checks are conducted on the annotation information that is generated.
Output example
Data in JSON files used to create OWL triples. The example shows the statements about the lanes that are part of a road.
    "objects": {
      "9": {
        "name": "Lane1",
        "type": "Lane",
        "object_data": "{...}",
        "object_data_pointers": "{...}"
        }
      }
      "10": {
        "name": "Lane2",
        "type": "Lane",
        "object_data": "{...}",
        "object_data_pointers": "{...}"
      }
      "11": {
        "name": "Road1",
        "type": "Road",
        "object_data": "{...}",
        "object_data_pointers": "{...}"
      }

    "relations": {
      "0": {
        "name": "",
        "type": "partOf",
        "rdf_subjects": [
          {
            "uid": "9",
            "type": "object"
          }
        ]
        "rdf_objects": [
          {
            "uid": "11",
            "type": "object"
          }
        ]
      }
    }
Extract from the enriched OWL file, road definition with lanes
<owl:NamedIndividual rdf:about="ABoxMWP#road1">
    <rdf:type rdf:resource="Domain#Road"/>
    <core:hasPart rdf:resource="ABoxMWP#lane1"/>
    <core:hasPart rdf:resource="ABoxMWP#lane2"/>
    <domain:hasNumberOfLanes rdf:datatype="integer">2</domain:hasNumberOfLanes>
</owl:NamedIndividual>
Extract from the enriched OWL file, definition of lane1 and connections to lane dividers
<owl:NamedIndividual rdf:about="ABoxMWP#lane1">
    <rdf:type rdf:resource="Domain#Lane"/>
    <rdf:type>
        <owl:Restriction>
            <owl:onProperty rdf:resource="Core#connectedTo"/>
            <owl:maxQualifiedCardinality
                    rdf:datatype="nonNegativeInteger">2</owl:maxQualifiedCardinality>
            <owl:onClass rdf:resource="Domain#LaneDivider"/>
        </owl:Restriction>
    </rdf:type>
    <domain:connectedTo rdf:resource="ABoxMWP#laneDiv1"/>
    <domain:connectedTo rdf:resource="ABoxMWP#laneDiv2"/>
    <domain:objectOf rdf:resource="ABoxMWP#drivingStraight0_0"/>
</owl:NamedIndividual>
Role of OpenXOntology

OpenXOntology provides the TBox, meaning the terminological component for labeling the input data in the automatic processing step and enriching the labeling in the manual annotation step. For example, OpenXOntology provides the base classes and definitions for the physical objects to be labeled, such as Lane.

As for other ASAM standards, OpenLABEL is used in this phase.

10.2.3. Phase 2 of the data journey: Check data and infer knowledge

In phase 2, a semantic application parses and checks the triples created in phase 1 in order to infer new knowledge and identify semantic conflicts.

The input for phase 2 is the ABox generated in phase 1 and stored as OWL file. This ABox represents a functional scenario and contains the assertions on the identified traffic objects and road traffic situation.

Steps in phase 2
  1. A reasoner parses the data in the existing ABox and infers additional individuals and relationships from the ABox, based on OpenXOntology. The new data is added to the OWL file, resulting in an enriched OWL file.

    • In the example scenario, the RDF triples generated in phase 1 contain the information that lane 1 and lane 2 are both connected to lane divider 2, but only lane 1 is connected to lane divider 1. Knowing that lane divider 1 is the center lane divider and the traffic drives on the right side of the road, the reasoner can infer that lane 2 must be located to the right of lane 1.

    • For this inference, SWRL rules need to be used. Specifically, the following rule is used to identify the positioning of neighboring lanes belonging to the same road: domain:Road(?w) ^ domain:Lane(?x) ^ domain:Lane(?y) ^ core:hasPart(?w, ?x) ^ core:hasPart(?w, ?y) ^ differentFrom(?x, ?y) ^ domain:LaneDivider(?z0) ^ domain:SolidLine(?z1) ^ domain:connectedTo(?x, ?z0) ^ domain:connectedTo(?y, ?z0) ^ domain:connectedTo(?x, ?z1) → domain:RightOf(?x, ?y)

    • For the sample scenario, the HermiT reasoner is used.

  2. A reasoner checks the OWL file for semantic conflicts. The ontology gives logical and rule-based constraints on the concepts it defines. These constraints can be used to detect semantic conflicts in a description of a situation or scenario. If the reasoner identifies a conflict, it outputs an explanation of why the conflict has occurred, for example, which rules and logical characteristics were found to be in conflict. A human user can use that information to decide how to solve the conflicts.

    • In the example scenario, the OWL file generated in phase 1 contains incorrect information about the passing event. The ABox contains the assertion that vehicle2_2 passes egoCar0_2, which is in conflict with the assertion that egoCar0_2 is behind vehicle2_2:

      <owl:NamedIndividual rdf:about="AboxMWP#pass2to0">
          <rdf:type rdf:resource="ApplicationOSC#PassingEvents"/>
          <domain:hasObject rdf:resource="AboxMWP#egoCar0_2"/>
          <domain:hasSubject rdf:resource="AboxMWP#vehicle2_2"/>
      </owl:NamedIndividual>
    • A logical reasoner such as HermiT can provide information about what assertions may be contributing to this semantic conflict as shown in Figure 17.

      mwp box2 hermit
      Figure 17. Example of information provided by a logical reasoner about a semantic conflict
    • In this data journey, the human user could resolve this semantic conflict by switching the hasObject and hasSubject individuals or removing the assertion about the passing event completely.

  3. Once the human user has resolved the semantic conflicts, the reasoner application stores the results in an OWL file.

The output data of this phase is a functional scenario that is described in OWL.

Output examples

The reasoner adds a triple to the definition of lane 1 in the ABox for the position of lane 1 to the right of lane 2.

The logical reasoner also adds other inferences, such as the membership of lane 1 to the upper level classes RoadTopologyAndTrafficInfrastructure and FunctionalSystemState and the fact that because road 1 has part lane 1, lane 1 is part of road 1.

<owl:NamedIndividual rdf:about="AboxMWP#lane1">
    <rdf:type rdf:resource="Domain#Lane"/>
    <rdf:type rdf:resource="Domain#RoadTopologyAndTrafficInfrastructure"/>
    <rdf:type rdf:resource="Domain#FunctionalSystemState"/>
    <rdf:type>
        <owl:Restriction>
            <owl:onProperty rdf:resource="Domain#connectedTo"/>
            <owl:maxQualifiedCardinality
                    rdf:datatype="nonNegativeInteger">2</owl:maxQualifiedCardinality>
            <owl:onClass rdf:resource="Domain#LaneDivider"/>
        </owl:Restriction>
    </rdf:type>
    <domain:connectedTo rdf:resource="AboxMWP#laneDiv1"/>
    <domain:connectedTo rdf:resource="AboxMWP#laneDiv2"/>
    <core:isPartOf rdf:resource="AboxMWP#road1"/>
    <domain:isRightOf rdf:resource="AboxMWP#lane2"/>
    <domain:objectOf rdf:resource="AboxMWP#drivingStraight0_0"/>
</owl:NamedIndividual>
Role of OpenXOntology

The TBox and the SWRL rules of OpenXOntology are used to check the ABox for conflicts and infer new individuals and relationships. The resulting OWL file is more comprehensive and semantically correct.

10.2.4. Phase 3 of the data journey: Detail the scenario

Phase 3 details the functional scenario to a logical scenario and then to a concrete scenario. To detail a functional scenario to a logical scenario, parameters and parameter ranges have to be defined in a first step. In a second step, constraints between these parameters have to be identified to guarantee meaningful scenarios. Afterwards, this logical scenario can be used as a basis to set parameter values and generate the ASAM OpenDRIVE and ASAM OpenSCENARIO 1.1.1 files for the corresponding concrete scenario.

The input data of phase 3 is the functional scenario generated in phase 2 and stored as OWL file.

mwp example box3 overview
Figure 18. Overview of phase 3 and how it relates to phases 1 and 2

Figure 18 provides an overview of phases 1, 2, 3 and how they interact with each other.

Steps in phase 3

1. Define parameters and parameter ranges

In this step, a suitable computer program, for example, a python module working with ASAM OpenXOntology, identifies the parameter space for the scenario elements described in the functional scenario and adds the parameters to the OWL file (ABox).

The generation of the data formats for simulation, for example ASAM OpenDRIVE or ASAM OpenSCENARIO 1.1.1, requires that the parameters and their relations are defined in the ABox. ASAM OpenXOntology can be used to specify parameters for each class.

For example, in the MWP scenario, there are three traffic participants of the class Vehicle: egoCar0, vehicle1, and vehicle2. To generate ASAM OpenSCENARIO 1.1.1 data, the velocity of each vehicle must be known.

The definitions of the core ontology require that a physical object, such as a vehicle, shall be divided into temporal parts called states if the object has more than one value for a particular state parameter, for example velocity, over the time period of interest. Each state shall have a single parameter value. Following this modelling approach, ASAM OpenXOntology requires that every individual that is a member of the class WholeLifeFunctionalSystem, including FunctionalSystemState, shall have a maximum of one value for a particular state parameter, such as velocity.

For example, the egoCar0 is divided into three states:

  • egoCar0_0 for the temporal part that is driving initially.

  • egoCar0_1 for the temporal part that slows down before changing lanes.

  • egoCar0_2 for the temporal part that resumes the previous cruising speed.

<owl:Class rdf:about="Core#WholeLifeFunctionalSystem">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="Parameters#hasParameter"/>
      <owl:maxQualifiedCardinality rdf:datatype="nonNegativeInteger">1
        </owl:maxQualifiedCardinality>
      <owl:onClass rdf:resource="Parameters#Velocity"/>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

In addition, domain and application ontologies may contain further restrictions on the classes defined there. For example, the following definition restricts the maximum velocity that is allowable for an ambulance to 40 m/s.

The first axiom states that ambulances shall have at least one AmbulanceVelocity. Because Ambulances is a subclass of WholeLifeFunctionalSystem, it is defined that ambulances shall have a maximum of 1 Velocity, and because AmbulanceVelocity is a subclass of Velocity, it is defined that ambulances shall only have AmbulanceVelocity as their velocity.

<owl:Class rdf:about="ApplicationOL#Ambulances">
    <rdfs:subClassOf rdf:resource="Domain#Vehicle"/>
    <rdfs:subClassOf>
        <owl:Restriction>
            <owl:onProperty rdf:resource="Parameters#hasParameter"/>
            <owl:someValuesFrom rdf:resource="ApplicationOL#AmbulanceVelocity"/>
        </owl:Restriction>
    </rdfs:subClassOf>
</owl:Class>

The following axiom states that every individual that is an AmbulanceVelocity shall be less than the individual called AmbulanceVelocityMax:

<owl:Class rdf:about="ApplicationOL#AmbulanceVelocity">
    <rdfs:subClassOf rdf:resource="Parameters#Velocity"/>
    <rdfs:subClassOf>
      <owl:Restriction>
        <owl:onProperty rdf:resource="#lessThan" />
        <owl:hasValue rdf:resource="#AmbulanceVelocityMax" />
      </owl:Restriction>
    </rdfs:subClassOf>
</owl:Class>

Finally, the following axiom states that AmbulanceVelocityMax is a member of AmbulanceVelocity that has a maximum parameter value of 40.0. For this example, it is assumed that all parameters are given in SI units, but units may be added to the TBox as required.

<owl:NamedIndividual rdf:about="AboxMWP#AmbulanceVelocityMax">
    <rdf:type rdf:resource="Parameters#Velocity"/>
    <parameters:hasParameterValueMax rdf:datatype="float">40.0</asam:hasParameterValueMax>
</owl:NamedIndividual>

Based on this information in the TBox, the application automatically extends the ABox by adding a new individual for each parameter to be specified, together with the required relations to other individuals in the functional scenario level ABox. The following code sample shows the individual that is added to describe the velocity of the egoCar0_0.

<owl:NamedIndividual rdf:about="AboxMWP#egoCar0_0">
    <rdf:type rdf:resource="Core#FunctionalSystemState"/>
    <core:hasBeginning rdf:resource="AboxMWP#scenarioStart"/>
    <core:hasEnding rdf:resource="AboxMWP#pass1to0"/>
    <parameters:hasParameter rdf:resource="AboxMWP#egoCar0_0velocity"/>
    <core:isTemporalPartOf rdf:resource="AboxMWP#egoCar0"/>
</owl:NamedIndividual>

2. Identify parameter constraints

In this step, the application identifies additional constraints on each parameter based on ASAM OpenXOntology. The application adds the parameter constraints to the OWL file. The OWL file containing both parameters and parameter constraints represents a basic description of a logical scenario.

To ensure that the scenario remains valid when parameters and parameter values are specified in detail, parameter constraints need to be considered. These constraints shall be specified in the TBox and may be described by SWRL rules.

In the MWP scenario, each vehicle has a velocity parameter. However, the values for the velocities are sometimes constrained by other scenario elements, such as PassingEvents. In the example scenario, vehicle1 and vehicle2 pass egoCar0. Consequently, the velocity of vehicle1 and vehicle2 must be higher than the velocity of egoCar0. The following SWRL rule guarantees that the subject vehicle of a passing event must have a velocity that is greater than the object of the passing event.

SWRL rule:
ApplicationOSC:PassingEvents(?pe) ^ parameters:hasSubject(?pe, ?sub) ^ parameters:hasParameter(?sub, ?subVel) ^ parameters:Velocity(?subVel) ^ domain:hasObject(?pe, ?obj) ^ parameters:hasParameter(?obj, ?objVel) ^ parameters:Velocity(?objVel) -> parameters:greaterThan(?subVel, ?objVel)

The outcome of applying this rule to the ABox in the example is as follows:

<owl:NamedIndividual rdf:about="AboxMWP#egoCar0_1velocity">
    <rdf:type rdf:resource="Parameters#Velocity"/>
    <parameters:lessThan rdf:resource="AboxMWP#vehicle1_1velocity"/>
</owl:NamedIndividual>

3. Scenario concretization and export

In this step, a human scenario editor uses an appropriate application, for example, a python module, to define a discrete value for each parameter in the logical scenario. The tool supports the human editor by monitoring whether all parameter constraints are met.

After setting all parameter values, a suitable computer program, for example, a python module, converts the concrete scenario into a data format that can be used for simulation: ASAM OpenDRIVE and ASAM OpenSCENARIO 1.1.1. The resulting files represent standardized scenario descriptions (ASAM OpenSCENARIO 1.1.1) and road network definitions (ASAM OpenDRIVE).

Output example

In phase 3, the files that can be used for simulation (ASAM OpenDRIVE and ASAM OpenSCENARIO 1.1.1) are generated.

In this snippet, the initial velocity of vehicle_1 is set.

<Private entityRef="vehicle_1">
	<PrivateAction>
		<LongitudinalAction>
			<SpeedAction>
				<SpeedActionDynamics dynamicsDimension="time" dynamicsShape="step" value="0.0"/>
				<SpeedActionTarget>
					<AbsoluteTargetSpeed value="16.6666666667"/>
				</SpeedActionTarget>
			</SpeedAction>
		</LongitudinalAction>
	</PrivateAction>
</Private>
Role of ASAM OpenXOntology

ASAM OpenXOntology is used as a basis to specify the parameters for detailing the functional scenario. The explicit specification of parameters and constraints ensures consistent assumptions throughout the development process.

As other ASAM standards, ASAM OpenDRIVE and ASAM OpenSCENARIO 1.1.1 are used.

10.2.5. Phase 4 of the data journey: Simulate the scenario

In phase 4, the ASAM OpenDRIVE and ASAM OpenSCENARIO 1.1.1 data generated in phase 3 are executed within an environment simulator. ASAM OSI ground truth is generated from the simulator.

A environment simulator creates the ground truth, which contains the object list. This object list is compatible with ISO 23150 and is communicated to the sensor view via an ASAM OSI protobuf message. Currently, the protobuf message is converted to an ASAM OSI trace file.

Output example
Box2 example main v2 main
Figure 19. Animated traffic simulator results
Role of ASAM OpenXOntology
  • ASAM OpenXOntology is used to tag the object list within the ASAM OSI ground-truth trace file. It can further be used to tag the actions of each traffic participants that are present within the ground truth.

  • ASAM OpenXOntology provides the TBox for such tagging mechanism with common logical definitions and structure. An example of a logical definition is the following:

    The ontology classifies lane divider from the object list as static, non-changing object. Hence, ASAM OSI could choose to not update the lane divider frequently.

  • ASAM OpenXOntology will be a common basis for ASAM OpenLABEL and ASAM OpenSCENARIO 1.1.1. The subsequent phase 5, that is ASAMODD checking, also requires that the parameter spaces associated with ASAM OpenSCENARIO 1.1.1, ASAM OpenLABEL, ASAM OSI, and ASAMODD are harmonized. For example, if ASAM OSI has a smaller parameter space than ASAM OpenSCENARIO 1.1.1 for operational domain design related parameters, this simulation environment has an incomplete coverage.

  • Optionally, if ASAM OSI can write ground-truth trace files in ASAM OpenLABEL format then it can be useful to compare scene-by-scene simulation execution results with ground-truth data from real-word driving.

10.2.6. Phase 5 of the data journey: Check against ASAMODD

Phase 5 checks the concrete scenario generated in phase 3 for validity against an operational design domain, verifying that the scenario conditions are covered by the operational design domain.

The inputs for this phase are the ASAM OSI stream data from phase 4 together with the ASAM OpenDRIVE and ASAM OpenSCENARIO 1.1.1 files generated in phase 3.

Steps in phase 5
mwp box5 flowchart
Figure 20. Overview of phase 5

Figure 20 shows the steps in phase 5.

1. Receiving ASAM OSI ground-truth and converting into OWL format

  • The ground-truth data is received from phase 4. It contains the road information, including lanes, traffic participants, and environment conditions with the associated elements.

  • A python module filters the ground-truth data and outputs another ground-truth file that only contains domain elements.

  • Another python module converts the filtered ground-truth into OWL format using the ASAM OpenXOntology TBox: this corresponds to ABox1 in Figure 20.

  • The role of ASAM OpenXOntology is to provide the TBox to generate the ABox which contains only the domain elements used in the operational design domain.

2. Parsing and converting ASAMODD specification into OWL format

  • Example of the ASAMODD specification:

    ... UNSUITABLE InducedRoadSurfaceCondition WHEN Icy ...
  • A human expert or a python module parses the values in the ASAMODD specification.

  • A python module converts the parsing output into an OWL representation using the ASAM OpenXOntology TBox. This corresponds to ABox2 in in Figure 20.

  • The role of ASAM OpenXOntology is to provide the TBox to generate the ABox.

3. Performing inference on ABox1 and adding additional information

  • A semantic reasoner performs inference on the OWL file generated from the filtered ground-truth data (ABox 1 in the figure) in order to add missing information.

  • In this demonstration box, the goal of the reasoner is to infer InducedRoadSurfaceCondition based on Precipitation and Temperature. That is why the following three SWRL rules can be constrcuted:

    • Rule 1: Infer that when temperature is below zero and when precipitation is above zero, the induced road surface condition will be icy road

      InducedRoadSurfaceConditions(?x) ^ RainfallCondition(?r) ^ precipitationIntensity(?p) ^ has_property(?r, ?p) ^ has_real_value(?p, ?pvalue) ^ temperature(?t)^ has_real_value(?t, ?tvalue) ^ swrlb:lessThan(?tvalue, 0.0) ^ swrlb:greaterThan(?pvalue, 0.0)  -> IcyRoadCondition(?x)
    • Rule 2: Infer that when temperature is above zero and when precipitation is above zero, the induced road surface condition will be wet road

      InducedRoadSurfaceConditions(?x) ^ RainfallCondition(?r) ^ precipitationIntensity(?p) ^ has_property(?r, ?p) ^ has_real_value(?p, ?pvalue) ^ temperature(?t)^ has_real_value(?t, ?tvalue) ^ swrlb:greaterThan(?tvalue, 0.0) ^ swrlb:greaterThan(?pvalue, 0.0)  -> WetRoadCondition(?x)
    • Rule 3: Infer that when precipitation is equal to zero, the induced road surface condition will be dry road

      InducedRoadSurfaceConditions(?x) ^ RainfallCondition(?r) ^ precipitationIntensity(?p) ^ has_property(?r, ?p) ^ has_real_value(?p, ?pvalue) ^ swrlb:equal(?pvalue, 0.0)  -> DryRoadCondition(?x)
  • Example of rule-based inference on ground-truth data:

    Input from ASAM OSI ground-truth:

    {...​ "Temperature": "265",​
          "EnvironmentalConditions": {
                                      {​"Precipitation": “Light",​ ...​ }
                                                                     } } ...
  • Based on the specification that the temperature is "265" (in 'Kelvin' unit which corresponding to -8.15 degree C) and that the precipitation is "Light", the semantic tool could infer based on the SWRL rules that the InducedRoadSurfaceCondition is IcyRoadCondition. This IcyRoadCondition condition is an additional ground-truth.

  • The role of ASAM OpenXOntology is to enable a semantic reasoner to infer additional information about the ground-truth data.

4. Checking whether the ASAM OSI ground-truth data is covered by the operational design domain

  • A python module checks the operational design domain every time a new ASAM OSI ground-truth is received during runtime to determine whether the vehicle is within or outside the operational design domain.

  • There are two ways to achieve this comparison. In the first, a python module executes the content of ABox2 as a SPARQL query against ABox1. In the second, a python module consolidates ABox1 and ABox2 into one single file. For each individual in ABox1 that must match a particular individual in ABox2, the python module adds a sameAs relation. Then the python module uses a semantic reasoner to check for semantic conflicts causes by making the pairs of individuals from each ABox the same. If a semantic conflict occurs between a pair of individuals, then for the ASAMODD attribute represented by the individuals, the current ASAM OSI ground-truth is outside ASAMODD.

  • The role of ASAM OpenXOntology is to enable a semantic reasoner to infer additional information required to determine whether the ASAM OSI ground-truth is covered by the ASAMODD.

Bibliography

[1] EPSG 4326: World Geodetic System 1984 - https://epsg.io/4326. epsg, 2007.

[2] SAE J3016 - Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. SAE International, 2018.

[3] ASAM OpenDRIVE 1.6.0. ASAM e.V., 2020.

[4] ASAM OpenSCENARIO 1.1.1. ASAM e.V., 2021.

[5] ASAM OpenSCENARIO 2.0.0. ASAM e.V., 2021.

[6] ASAM OpenLABEL 1.0.0. ASAM e.V., 2021.

[7] ASAM Operational Domain Design Concept Paper 1.0.0. ASAM e.V., 2020.

[8] ASAM Open Simulation Interface 3.3.1. ASAM e.V., 2019.

[9] PAS 1883:2020 Operational design domain (ODD) taxonomy for an automated driving system (ADS). Specification. The British Standards Institution, 2020.

[10] ISO/TC 22/SC 33: Vehicle dynamics and chassis components. ISO, 2014.

[11] ISO 704:2009 Terminology work — Principles and methods. ISO, 2009.

[12] ISO 34501: Road vehicles — Terms and definitions of test scenarios for automated driving systems. ISO, under development.

[13] ISO 34502: Road vehicles — Scenario-based safety evaluation framework for Automated Driving Systems. ISO, under development.

[14] ISO 34503: Road vehicles — Taxonomy for operational design domain for automated driving systems. ISO, under development.

[15] ISO 34504: Road vehicles — Scenario attributes and categorization. ISO, under development.

[16] ISO TC22 SC32 WG8: Electrical and electronic components and general system aspects. ISO, 2014.

[17] Safety first for automated driving. SAFE group, 2019.

[18] ISO/PAS 21448:2019: Road vehicles — Safety of the intended functionality. ISO, 2019.

[19] OWL Web Ontology Language Guide - https://www.w3.org/TR/owl-guide/. W3C consortium, 2004.

[20] SWRL: A Semantic Web Rule Language Combining OWL and RuleML - https://www.w3.org/Submission/SWRL/. W3C consortium, 2004.

[21] Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities. ISO, 2018.

[22] HQDM Framework - http://www.informationjunction.co.uk/hqdm_framework/. Matthew West, 2009.

[23] Quantities, Units, Dimensions and Types; DOI: https://doi.org/10.25504/FAIRsharing.d3pqw7. FAIRsharing.org: QUDT, 2021.

[24] ASAM Open Data Services 6.1.1. ASAM e.V., 2021.

[25] Resource Description Framework (RDF) - https://www.w3.org/RDF/. W3C consortium, 2014.

[26] RDF Schema - https://www.w3.org/TR/rdf-schema/. W3C consortium, 2014.

[27] SKOS Simple Knowledge Organization System - https://www.w3.org/TR/skos-reference/. W3C consortium, 2009.

[28] OntoUML specification - https://ontouml.readthedocs.io/en/latest/. OntoUML community, 2018.

[29] Unified Font Object (UFO) - https://unifiedfontobject.org/. UFO specification group, 2012.

[30] RIF Rule interchange format - https://www.w3.org/TR/rif-overview/. W3C consortium, 2013.

[31] Rule markup language - http://wiki.ruleml.org/index.php/Specification_of_Deliberation_RuleML_1.0. RuleML Inc, 2012.

[32] R2RML: RDB to RDF Mapping Language - https://www.w3.org/TR/r2rml/. W3C consortium, 2012.

Appendix A: ASAM OpenXOntology: Model Reference

Ontology Version Information

ASAM OpenXOntology Version 1.0.0

A.1. Core

A.1.1. Classes

AbstractObject
Diagram
Element Description

Type

Class

Name

AbstractObject

IRI

http://ontology.asam.net/ontologies/Core#AbstractObject

Subclass of

CoreConcepts

Disjoint with

SpatioTemporalExtent

Comments

DEF: A thing that does not exist in space or time. Abstract objects are used to express characteristics of spatio-temporal extents, such as properties and roles.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

ActivityState
Diagram
Element Description

Type

Class

Name

ActivityState

IRI

http://ontology.asam.net/ontologies/Core#ActivityState

Subclass of

State

Restriction

causes some Event

Restriction

hasParticipant some Participant

Restriction

memberOf only SetOfActivityStates

Comments

DEF: A State that represents the whole life of an activity or a temporal part of an activity. Activities consist of their participants, which are members of PhysicalObjectState, and cause some event. The end event of an activity state is caused by that activity, which implies that the activity describes some change between the start event and end event.

EXAMPLES: the movements of a cloud or an animal crossing a road.

USAGE: Use this class for (temporal parts of) activities that are not the direct result of some intent, for example, a person’s intent.

Aggregation
Diagram
Element Description

Type

Class

Name

Aggregation

IRI

http://ontology.asam.net/ontologies/Core#Aggregation

Subclass of

Relationship

Comments

DEF: A Relationship where the whole is at least the sum of the parts. Basis for object property aggregatedInto.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

AngleQuantity
Diagram
Element Description

Type

Class

Name

AngleQuantity

IRI

http://ontology.asam.net/ontologies/Core#AngleQuantity

Subclass of

PhysicalQuantity

Comments

DEF: A PhysicalQuantity that is an angle value in degrees, between 0 and 360.

EXAMPLES:

USAGE: Use this class instead of DirectionQuantity when specifying angles that are not actual directions respective to some coordinate system.

BiologicalObjectState
Diagram
Element Description

Type

Class

Name

BiologicalObjectState

IRI

http://ontology.asam.net/ontologies/Core#BiologicalObjectState

Subclass of

PhysicalObjectState

Comments

DEF: A PhysicalObjectState that sustains itself and reproduces. A BiologicalObjectState may represent the whole life of the object or a temporal part of it.

EXAMPLES: a BiologicalObjectState that is not an OrdinaryBiologicalObjectState would be one that survives the replacement of all of its parts, so an example might be my dog (which might be a completely different dog over time).

USAGE: generally use OrdinaryBiologicalObjectState instead of this class

Classification
Diagram
Element Description

Type

Class

Name

Classification

IRI

http://ontology.asam.net/ontologies/Core#Classification

Subclass of

Relationship

Comments

DEF: A Relationship where a thing is a member of a class. Basis for object properties memberOf and hasMember.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

Composition
Diagram
Element Description

Type

Class

Name

Composition

IRI

http://ontology.asam.net/ontologies/Core#Composition

Subclass of

Aggregation

Comments

DEF: An Aggregation where the whole is an arrangement of the parts that results in emergent properties. Basis for object properties partOf and hasPart.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

ConnectionRelation
Diagram
Element Description

Type

Class

Name

ConnectionRelation

IRI

http://ontology.asam.net/ontologies/Core#ConnectionRelation

Subclass of

DefinedRelationship

Comments

DEF: A DefinedRelationship for relations between things that are connected in any way, physically or otherwise. Basis for the object property connectedTo.

EXAMPLES:

USAGE: Use this class to express a connection between two things as a reified relationship, e.g. in order to specify characteristics such as the angle of the connection.

CoreConcepts
Diagram
Element Description

Type

Class

Name

CoreConcepts

IRI

http://ontology.asam.net/ontologies/Core#CoreConcepts

Subclass of

Thing

Comments

DEF: Top-level container that separates core concepts in the OpenXOntology. The CoreConcepts define basic concepts, such as physical objects, states, and events. The core ontology of ASAM OpenXOntology corresponds to a top-level ontology or upper ontology. The core ontology of ASAM OpenXOntology is based on HQDM.

DefinedRelationship
Diagram
Element Description

Type

Class

Name

DefinedRelationship

IRI

http://ontology.asam.net/ontologies/Core#DefinedRelationship

Subclass of

Relationship

Comments

DEF: A Relationship of a certain kind. This may be temporal, spatial, compositional, or other other relationships.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

DirectionQuantity
Diagram
Element Description

Type

Class

Name

DirectionQuantity

IRI

http://ontology.asam.net/ontologies/Core#DirectionQuantity

Subclass of

PhysicalQuantity

Comments

DEF: A PhysicalQuantity that defines a direction in degrees, between 0 and 360. May be used to quantify the direction of a vector described by a SpatialRelation, a SeparationDistance, or similar.

EXAMPLES:

USAGE: Use this class instead of AngleQuantity when specifying actual directions respective to some coordinate system.

Event
Diagram
Element Description

Type

Class

Name

Event

IRI

http://ontology.asam.net/ontologies/Core#Event

Subclass of

SpatioTemporalExtent

Restriction

memberOf only SetOfEvents

Disjoint with

State

Comments

DEF: A SpatioTemporalExtent with a time extension of zero, but with an extension in space. Events mark changes in states and are used for something instantaneous.

EXAMPLES:

USAGE: Use this class to specify the state and/or end of activities and temporal parts of physical objects.

FunctionalObjectState
Diagram
Element Description

Type

Class

Name

FunctionalObjectState

IRI

http://ontology.asam.net/ontologies/Core#FunctionalObjectState

Subclass of

IntentionallyConstructedObjectState

Subclass of

PhysicalObjectState

Restriction

intendedRole some Role

Comments

DEF: An IntentionallyConstructedObjectState and PhysicalObjectState that has an intendedRole. A FunctionalObjectState may represent the whole life of the object or a temporal part of it.

EXAMPLES: a FunctionalObjectState that is not an OrdinaryFunctionalObjectState would be one that survives the replacement of all of its parts, so an example might be my car (which might be a completely different car over time).

USAGE: generally use OrdinaryFunctionalObjectState instead of this class

FunctionalSystemComponentState
Diagram
Element Description

Type

Class

Name

FunctionalSystemComponentState

IRI

http://ontology.asam.net/ontologies/Core#FunctionalSystemComponentState

Subclass of

FunctionalObjectState

Subclass of

SystemComponentState

Restriction

componentOf exactly 1 FunctionalSystemState

Comments

DEF: An IntentionallyConstructedObjectState that represents a replaceable component of a FunctionalSystem. The object property componentOf is used to relate the object to the FunctionalSystem. A FunctionalSystemComponentState may be the whole life of the component or a temporal part of it.

EXAMPLES: markings of road or engines of vehicles

USAGE: Use this class to represent the components of things that were created for a specific purpose, for example markings of road or engines of vehicles.

FunctionalSystemState
Diagram
Element Description

Type

Class

Name

FunctionalSystemState

IRI

http://ontology.asam.net/ontologies/Core#FunctionalSystemState

Subclass of

OrdinaryFunctionalObjectState

Subclass of

SystemState

Comments

DEF: An OrdinaryFunctionalObjectState that is also a SystemState.

EXAMPLES: Vehicles, traffic infrastructure, buildings, traffic lights.

USAGE: Use this class for describing (temporal parts) of concrete (actual, materialized) systems that cease to exist when all of their parts are removed. Often combined with OrdinaryBiologicalObjectState or OrdinaryFunctionalObjectState

Geometry
Diagram
Element Description

Type

Class

Name

Geometry

IRI

http://ontology.asam.net/ontologies/Core#Geometry

Subclass of

PhysicalProperty

Comments

DEF: A PhysicalProperty that describes a spatial characteristic of an Object in a 1D, 2D or 3D space. Unlike "shape", which only refers to the outer surface, "geometry" can include other characteristics, e.g. different kind of projections like cross section, road geometry.

EXAMPLES:

USAGE:

InstalledFunctionalSystemComponent
Diagram
Element Description

Type

Class

Name

InstalledFunctionalSystemComponent

IRI

http://ontology.asam.net/ontologies/Core#InstalledFunctionalSystemComponent

Subclass of

FunctionalSystemComponentState

Subclass of

InstalledObject

Subclass of

OrdinaryFunctionalObjectState

Comments

DEF: An InstalledObject that is also a OrdinaryFunctionalObjectState and a FunctionalSystemComponentState.

EXAMPLES: the particular tire that was installed on car42’s right front wheel between time1 and time2

USAGE: Use this class for describing the actual, materialized installed components of a system.

InstalledObject
Diagram
Element Description

Type

Class

Name

InstalledObject

IRI

http://ontology.asam.net/ontologies/Core#InstalledObject

Subclass of

OrdinaryPhysicalObjectState

Comments

DEF: An OrdinaryPhysicalObjectState that is installed in a system, meaning that is also a SystemComponentState. The state of the ordinary physical object is the temporal part that covers the time from when the ordinary physical object is installed in the system to when it is removed.

EXAMPLES: The time that the traffic sign with the serial number 42 is installed at a specific location on highway 66. (note that this would actually be an InstalledFunctionalSystemComponent because the highway is a FunctionalSystem).

USAGE: Use this class to describe the temporal part of a physical object when it is the actual component of a system.

IntentionallyConstructedActivityState
Diagram
Element Description

Type

Class

Name

IntentionallyConstructedActivityState

IRI

http://ontology.asam.net/ontologies/Core#IntentionallyConstructedActivityState

Subclass of

ActivityState

Subclass of

IntentionallyConstructedObjectState

Comments

DEF: An ActivityState that is also an IntentionallyConstructedObjectState.

EXAMPLES: the changing of a signal state by a device in an intelligent transportation system

USAGE: Use this class to describe planned activities by single persons or intelligent devices, such as the changing of a signal state by a device in an intelligent transportation system.

IntentionallyConstructedObjectState
Diagram
Element Description

Type

Class

Name

IntentionallyConstructedObjectState

IRI

http://ontology.asam.net/ontologies/Core#IntentionallyConstructedObjectState

Subclass of

State

Comments

DEF: A State that exists because of an act of will or agreement. That means that IntentionallyConstructedObjects are constructed intentionally by one or more things that have intent, usually humans or robots.

EXAMPLES: an idea, a design, or a component specification

USAGE: Generally use FunctionalObjectState or one of its subclasses rather than this class. However, a thing that was created by humans for some purpose but does not exist materially, such as an idea, a design, or a component specification, would be a IntentionallyConstructedObjectState but not a FunctionalObjectState.

LengthQuantity
Diagram
Element Description

Type

Class

Name

LengthQuantity

IRI

http://ontology.asam.net/ontologies/Core#LengthQuantity

Subclass of

PhysicalQuantity

Comments

DEF: A PhysicalQuantity that is a length value in meters.

EXAMPLES:

USAGE:

OrdinaryBiologicalObjectState
Diagram
Element Description

Type

Class

Name

OrdinaryBiologicalObjectState

IRI

http://ontology.asam.net/ontologies/Core#OrdinaryBiologicalObjectState

Subclass of

BiologicalObjectState

Subclass of

OrdinaryPhysicalObjectState

Comments

DEF: A BiologicalObjectState that describes biological objects that do not survive changing all their parts at once. An OrdinaryBiologicalObjectState may represent the whole life of the object or a temporal part of it.

EXAMPLES: humans, animals, and trees

USAGE: Use this class for describing temporal parts of living things that cease to exist when all of their parts are removed.

OrdinaryFunctionalObjectState
Diagram
Element Description

Type

Class

Name

OrdinaryFunctionalObjectState

IRI

http://ontology.asam.net/ontologies/Core#OrdinaryFunctionalObjectState

Subclass of

FunctionalObjectState

Subclass of

OrdinaryPhysicalObjectState

Comments

DEF: A FunctionalObjectState that describes functional objects that do not survive changing all their parts at once. An OrdinaryFunctionalObjectState may represent the whole life of the object or a temporal part of it.

EXAMPLES: A steel bar with no components and is not a component of any other thing but was created for a specific purpose could be an OrdinaryFunctionalObjectState.

USAGE: Use this class for temporal parts of manufactured things that were constructed for some purpose and that cease to exist when all of their parts are removed. However, if the thing is a system and/or a system component, it is preferable to use the corresponding subclass.

OrdinaryPhysicalObjectState
Diagram
Element Description

Type

Class

Name

OrdinaryPhysicalObjectState

IRI

http://ontology.asam.net/ontologies/Core#OrdinaryPhysicalObjectState

Subclass of

PhysicalObjectState

Comments

DEF: A PhysicalObjectState that describes physical objects that do not survive changing all their parts at once. An OrdinaryPhysicalObjectState may represent the whole life of the object or a temporal part of it.

EXAMPLES: cloud, raindrop, rock, sunlight

USAGE: Use this class for temporal parts of physical objects that cease to exist when all of their parts are removed and that are neither biological objects (OrdinaryBiologicalObjectState) nor manufactured things constructed for some purpose (OrdinaryFunctionalObjectState).

Participant
Diagram
Element Description

Type

Class

Name

Participant

IRI

http://ontology.asam.net/ontologies/Core#Participant

Subclass of

PhysicalObjectState

Restriction

memberOf only SetOfParticipants

Restriction

participantOf only ActivityState

Comments

DEF: A PhysicalObjectState that represents a participant of an ActivityState. The ActivityState consists of these Participants, where each Participant is a member of the Role in which it is participating.

EXAMPLES: The state (temporal part) of a vehicle that is making a left turn.

USAGE: Use this class for describing the temporal part of physical objects that are participating in activities. Usually combined with OrdinaryBiologicalObjectState or OrdinaryFunctionalObjectState

PeriodOfTime
Diagram
Element Description

Type

Class

Name

PeriodOfTime

IRI

http://ontology.asam.net/ontologies/Core#PeriodOfTime

Subclass of

State

Restriction

temporalPartOf only PossibleWorld

Comments

DEF: A State that is a temporal part of some PossibleWorld. That means the period of time is a temporal duration of some possible world, which could be the actual world.

EXAMPLES:

USAGE:

PhysicalObjectState
Diagram
Element Description

Type

Class

Name

PhysicalObjectState

IRI

http://ontology.asam.net/ontologies/Core#PhysicalObjectState

Subclass of

State

Restriction

memberOf only SetOfPhysicalObjectStates

Restriction

temporalPartOf only WholeLifePhysicalObject

Comments

DEF: A State that consists of a distribution of matter and/or energy. A PhysicalObjectState is understood to have a bounded distribution, and so it can be identified as that parcel of matter and/or energy over time. A PhysicalObjectState can be thought of as characterizing what does not change over time of a State.

EXAMPLES:

USAGE: Generally use a subclass of this class.

PhysicalProperty
Diagram
Element Description

Type

Class

Name

PhysicalProperty

IRI

http://ontology.asam.net/ontologies/Core#PhysicalProperty

Subclass of

SetOfStates

Comments

DEF: A SetOfStates is some characteristic that is the same for each state that possesses it (is a memberOf it). More accurately, a PhysicalProperty is a Set that groups states by a specific characteristic, but PhysicalProperty is understood to be the specific characteristic shared by its members.

EXAMPLES: The color red is a PhysicalProperty.

USAGE: Use this class for physical properties of both physical objects, for example mass and length, and activities, for example speed and duration.

PhysicalQuantity
Diagram
Element Description

Type

Class

Name

PhysicalQuantity

IRI

http://ontology.asam.net/ontologies/Core#PhysicalQuantity

Subclass of

PhysicalProperty

Comments

DEF: A PhysicalProperty that represents a measurable quantity of a characteristic.

EXAMPLES: length, speed, and angle.

USAGE:

PointInTime
Diagram
Element Description

Type

Class

Name

PointInTime

IRI

http://ontology.asam.net/ontologies/Core#PointInTime

Subclass of

Event

Comments

DEF: An Event that is the whole of space at an instant from some viewpoint.

EXAMPLES:

USAGE:

PossibleWorld
Diagram
Element Description

Type

Class

Name

PossibleWorld

IRI

http://ontology.asam.net/ontologies/Core#PossibleWorld

Subclass of

PeriodOfTime

Subclass of

WholeLifeIndividual

Comments

DEF: A WholeLifeIndividual that is a complete spatio-temporal history of some possible world. The actual world is one of the possible worlds.

EXAMPLES: a description could contain two PossibleWorlds, the possible world where carA stopped at the pedestrian crossing and where carA did not stop.

USAGE: Use this class to model modality (modal realism rather than modal logic), such as several possible planned futures or alternative pasts.

Relationship
Diagram
Element Description

Type

Class

Name

Relationship

IRI

http://ontology.asam.net/ontologies/Core#Relationship

Subclass of

AbstractObject

Comments

DEF: Relationships form the basis for many object properties.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

RelativeLocation
Diagram
Element Description

Type

Class

Name

RelativeLocation

IRI

http://ontology.asam.net/ontologies/Core#RelativeLocation

Subclass of

SpatialRelation

Comments

DEF: A SpatialRelation that describes that the subject is located on the object. Basis for the object property locatedOn.

EXAMPLES:

USAGE: Use this class to express the location of one thing with respect to another as a reified relationship, e.g. in order to specify characteristics such as the precise position of location.

Role
Diagram
Element Description

Type

Class

Name

Role

IRI

http://ontology.asam.net/ontologies/Core#Role

Subclass of

SetOfParticipants

Comments

DEF: A SetOfParticipants where each member participates in the same way in an ActivityState. In HQDM, a role is a kind of participant. So subclasses of Participant are members of the class Role, including TrafficParticipant, Owner, Employer, and Asset.

EXAMPLES: subclasses of Participant, including TrafficParticipant, Owner, Employer, and Asset

USAGE:

SeparationDistance
Diagram
Element Description

Type

Class

Name

SeparationDistance

IRI

http://ontology.asam.net/ontologies/Core#SeparationDistance

Subclass of

SpatialRelation

Restriction

hasDistance some LengthQuantity

Comments

DEF: A SpatialRelation that also describes a distance between two connected objects. Gives a complete description of a vector and an exact relative position.

EXAMPLES:

USAGE: Use this class to express the separation distance between two things as a reified relationship, e.g. in order to specify characteristics such as the distance and direction of the separation.

Set
Diagram
Element Description

Type

Class

Name

Set

IRI

http://ontology.asam.net/ontologies/Core#Set

Subclass of

AbstractObject

Comments

DEF: An AbstractObject that has members and whose identity is defined by those members. The members may be other sets as well as specific spatio-temporal extents.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

SetOfActivityStates
Diagram
Element Description

Type

Class

Name

SetOfActivityStates

IRI

http://ontology.asam.net/ontologies/Core#SetOfActivityStates

Subclass of

SetOfStates

Comments

DEF: A SetOfStates that groups activities.

EXAMPLES:

USAGE: Use this class to describe specific sets or kinds of ActivityStates that are not available already as subclasses of ActivityState.

SetOfEvents
Diagram
Element Description

Type

Class

Name

SetOfEvents

IRI

http://ontology.asam.net/ontologies/Core#SetOfEvents

Subclass of

SetOfSpatioTemporalExtents

Comments

DEF: A SetOfSpatioTemporalExtents that groups kinds of events.

EXAMPLES: triggered and absolute events, start and end events, etc.

USAGE: Use this class to describe specific sets or kinds of Events that are not available already as subclasses of Event.

SetOfParticipants
Diagram
Element Description

Type

Class

Name

SetOfParticipants

IRI

http://ontology.asam.net/ontologies/Core#SetOfParticipants

Subclass of

SetOfPhysicalObjectStates

Comments

DEF: A SetOfPhysicalObjectStates that groups participants of activities.

EXAMPLES:

USAGE: Generally use Role rather than this class.

SetOfPhysicalObjectStates
Diagram
Element Description

Type

Class

Name

SetOfPhysicalObjectStates

IRI

http://ontology.asam.net/ontologies/Core#SetOfPhysicalObjectStates

Subclass of

SetOfStates

Comments

DEF: A SetOfStates that groups physical object states.

EXAMPLES:

USAGE: Use this class to describe specific sets or kinds of PhysicalObjectStates that are not available already as subclasses of PhysicalObjectState.

SetOfSpatioTemporalExtents
Diagram
Element Description

Type

Class

Name

SetOfSpatioTemporalExtents

IRI

http://ontology.asam.net/ontologies/Core#SetOfSpatioTemporalExtents

Subclass of

Set

Comments

DEF: A Set whose members are spatio-temporal extents.

EXAMPLES:

USAGE: Use this class to describe specific sets or kinds of SpatioTemporalExtents that are not available already as subclasses of SpatioTemporalExtent.

SetOfStates
Diagram
Element Description

Type

Class

Name

SetOfStates

IRI

http://ontology.asam.net/ontologies/Core#SetOfStates

Subclass of

SetOfSpatioTemporalExtents

Comments

DEF: A SetOfSpatioTemporalExtents that groups states.

EXAMPLES:

USAGE: Use this class to describe specific sets or kinds of States that are not available already as subclasses of State.

SetOfWholeLifeIndividuals
Diagram
Element Description

Type

Class

Name

SetOfWholeLifeIndividuals

IRI

http://ontology.asam.net/ontologies/Core#SetOfWholeLifeIndividuals

Subclass of

SetOfStates

Comments

DEF: A SetOfStates that groups whole-life individuals.

EXAMPLES:

USAGE: Use this class to describe specific sets or kinds of WholeLifeIndividuals that are not available already as subclasses of WholeLifeIndividual.

SociallyConstructedActivityState
Diagram
Element Description

Type

Class

Name

SociallyConstructedActivityState

IRI

http://ontology.asam.net/ontologies/Core#SociallyConstructedActivityState

Subclass of

IntentionallyConstructedActivityState

Subclass of

SociallyConstructedObjectState

Comments

DEF: An ActivityState that is also a SociallyConstructedObjectState.

EXAMPLES: planned activities between multiple people such as meetings; the coordination of multiple traffic signals in an intelligent transportation system.

USAGE: Use this class to describe planned activities by a group of persons or intelligent devices.

SociallyConstructedObjectState
Diagram
Element Description

Type

Class

Name

SociallyConstructedObjectState

IRI

http://ontology.asam.net/ontologies/Core#SociallyConstructedObjectState

Subclass of

IntentionallyConstructedObjectState

Comments

DEF: An IntentionallyConstructedObjectState that is necessarily constructed by agreement of or acceptance by many people.

EXAMPLES: contracts, companies, and money

USAGE:

SpatialConnection
Diagram
Element Description

Type

Class

Name

SpatialConnection

IRI

http://ontology.asam.net/ontologies/Core#SpatialConnection

Subclass of

ConnectionRelation

Subclass of

SpatialRelation

Comments

DEF: A ConnectionRelation for relations between things that touch. Spatial connections create bridges for the transfer of energy or other things between the objects. Basis for the object property connectedTo.

EXAMPLES:

USAGE: Use this class to express a spatial connection between two things as a reified relationship, e.g. in order to specify characteristics such as the surface area of the connecting surface.

SpatialLocation
Diagram
Element Description

Type

Class

Name

SpatialLocation

IRI

http://ontology.asam.net/ontologies/Core#SpatialLocation

Subclass of

State

Comments

DEF: A State that describes the relative continuity of a position, an area or a space that is important in a defined context. The type of description of a SpatialLocation can be topological, topographical, coordinates, or any other type.

EXAMPLES: the position of an object, a country where certain regulations apply.

USAGE:

SpatialRelation
Diagram
Element Description

Type

Class

Name

SpatialRelation

IRI

http://ontology.asam.net/ontologies/Core#SpatialRelation

Subclass of

DefinedRelationship

Restriction

hasRelationDirection some DirectionQuantity

Restriction

hasSpatialObject some PhysicalObjectState

Restriction

hasSpatialSubject some PhysicalObjectState

Disjoint with

TemporalRelation

Comments

DEF: A DefinedRelationship between two physical objects that describes their directional relationship, not the distance. Basis for object properties such as rightOf, leftOf, inFrontOf, behind, etc.

EXAMPLES:

USAGE: Use this class to express a general spatial relation between two things as a reified relationship, giving only the direction of the relationship.

SpatioTemporalExtent
Diagram
Element Description

Type

Class

Name

SpatioTemporalExtent

IRI

http://ontology.asam.net/ontologies/Core#SpatioTemporalExtent

Subclass of

CoreConcepts

Restriction

partOfPossibleWorld some PossibleWorld

Restriction

memberOf only SetOfSpatioTemporalExtents

Restriction

hasBeginning exactly 1 Event

Restriction

hasEnding exactly 1 Event

Comments

DEF: A thing that exists in time and space, meaning in four dimensions. Each spatio-temporal extent has a start event and an end event.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

SpeedQuantity
Diagram
Element Description

Type

Class

Name

SpeedQuantity

IRI

http://ontology.asam.net/ontologies/Core#SpeedQuantity

Subclass of

PhysicalQuantity

Comments

DEF: A PhysicalQuantity that is a speed value in meters per second.

EXAMPLES:

USAGE:

State
Diagram
Element Description

Type

Class

Name

State

IRI

http://ontology.asam.net/ontologies/Core#State

Subclass of

SpatioTemporalExtent

Restriction

temporalPartOf some WholeLifeIndividual

Restriction

memberOf only SetOfStates

Comments

DEF: A SpatioTemporalExtent with non-zero extension in both space and time. Used to describe, for example, the state of a vehicle, a person, or a manufactured system like a factory. States can apply to the whole life of a thing or represent temporal parts of a thing,

EXAMPLES:

USAGE: Use this class to describe the temporal part of a whole-life individual to which some property applies or to describe the temporal part of a whole-life individual that participates in an activity.

SystemComponentState
Diagram
Element Description

Type

Class

Name

SystemComponentState

IRI

http://ontology.asam.net/ontologies/Core#SystemComponentState

Subclass of

PhysicalObjectState

Restriction

componentOf exactly 1 SystemState

Comments

DEF: A PhysicalObjectState that represents a component of a system. The state may represent the whole life of the component or a temporal part of it. The state can be completely replaced without losing its identity. A SystemComponentState can only exist when the System exists. On the other hand, the OrdinaryPhysicalObject that is installed as the component may exist before or after the System.

EXAMPLES: vehicles and pedestrians are components of the traffic system (actually FunctionalSystemComponentStates - not WholeLifeIndividuals because the whole life of a vehicle or pedestrian would include temporal parts that are not components of the same traffic system)

USAGE: Use this class only for physical objects that are components of systems that do not have specific functions (are not FunctionalSystems)

SystemState
Diagram
Element Description

Type

Class

Name

SystemState

IRI

http://ontology.asam.net/ontologies/Core#SystemState

Subclass of

OrdinaryPhysicalObjectState

Comments

DEF: An OrdinaryPhysicalObjectState that represents a concrete materialized system. Systems are defined as an organized or connected group of physical objects. A SystemState may represent the whole life of the system or a temporal part of it.

EXAMPLES: A natural weather system.

USAGE: Use this class only for systems that do not have specific functions

TemporalComposition
Diagram
Element Description

Type

Class

Name

TemporalComposition

IRI

http://ontology.asam.net/ontologies/Core#TemporalComposition

Subclass of

Composition

Comments

DEF: A Composition where the part is the entire whole spatially, but part of the whole temporally.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

TemporalRelation
Diagram
Element Description

Type

Class

Name

TemporalRelation

IRI

http://ontology.asam.net/ontologies/Core#TemporalRelation

Subclass of

DefinedRelationship

Comments

DEF: A DefinedRelationship that describes a temporal relationship between two things, usually between events. Basis for the object properties occursBefore, occursAfter, and similar.

EXAMPLES: not applicable.

USAGE: This class will generally not be used directly in the OpenX domain.

WholeLifeActivity
Diagram
Element Description

Type

Class

Name

WholeLifeActivity

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeActivity

Subclass of

ActivityState

Subclass of

WholeLifeIndividual

Comments

DEF: An ActivityState that represents the whole life of the activity.

EXAMPLES: the entire activity of overtaking another vehicle.

USAGE: Use this class for an activity that is its temporal whole.

WholeLifeBiologicalObject
Diagram
Element Description

Type

Class

Name

WholeLifeBiologicalObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeBiologicalObject

Subclass of

BiologicalObjectState

Subclass of

WholeLifePhysicalObject

Comments

DEF: A BiologicalObjectState that represents the whole life of the biological object.

EXAMPLES: a person from their birth to their death.

USAGE: Use this class for a biological object that is its temporal whole. Note that usually it is preferable to use the subclass WholeLifeOrdinaryBiologicalObject.

WholeLifeFunctionalObject
Diagram
Element Description

Type

Class

Name

WholeLifeFunctionalObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeFunctionalObject

Subclass of

FunctionalObjectState

Subclass of

WholeLifePhysicalObject

Comments

DEF: A FunctionalObjectState that represents the whole life of the functional object.

EXAMPLES:

USAGE: Use this class for a functional object that is its temporal whole. Note that usually it is preferable to use the subclass WholeLifeOrdinaryFunctionalObject.

WholeLifeFunctionalSystem
Diagram
Element Description

Type

Class

Name

WholeLifeFunctionalSystem

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeFunctionalSystem

Subclass of

FunctionalSystemState

Subclass of

WholeLifeSystem

Comments

DEF: A FunctionalSystemState that represents the whole life of the functional system.

EXAMPLES: A vehicle from when it is manufactured to when it is destroyed.

USAGE: Use this class for describing individual concrete (actual, materialized) systems that cease to exist when all of their parts are removed. Often combined with WholeLifeOrdinaryBiologicalObject or WholeLifeOrdinaryFunctionalObject

WholeLifeFunctionalSystemComponent
Diagram
Element Description

Type

Class

Name

WholeLifeFunctionalSystemComponent

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeFunctionalSystemComponent

Subclass of

FunctionalSystemComponentState

Subclass of

WholeLifeSystemComponent

Restriction

componentOf exactly 1 WholeLifeFunctionalSystem

Comments

DEF: A FunctionalSystemComponentState that represents the whole life of the functional system component.

EXAMPLES: The component of a junction that is the a traffic light, which functions as a signal at a junction (not the individual traffic lights with their serial numbers and dates of production, but the traffic light as a functional component).

USAGE: Use this class to specify the whole life of a component of a functional system, which could be temporally divided into FunctionalSystemComponentStates for each of the InstalledObjects that acted as the component over the lifetime of the functional system.

WholeLifeIndividual
Diagram
Element Description

Type

Class

Name

WholeLifeIndividual

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeIndividual

Subclass of

State

Comments

DEF: A State that is not a proper temporalPartOf any other individual of the same kind.

EXAMPLES:

USAGE: Use this class in combination with others to designate that a particular spatio-temporal extent is "its whole life"

WholeLifeIntentionallyConstructedActivity
Diagram
Element Description

Type

Class

Name

WholeLifeIntentionallyConstructedActivity

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeIntentionallyConstructedActivity

Subclass of

IntentionallyConstructedActivityState

Subclass of

WholeLifeActivity

Comments

DEF: A WholeLifeIntentionallyConstructedObject that is also a WholeLifeActivity.

EXAMPLES:

USAGE:

WholeLifeIntentionallyConstructedObject
Diagram
Element Description

Type

Class

Name

WholeLifeIntentionallyConstructedObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeIntentionallyConstructedObject

Subclass of

IntentionallyConstructedObjectState

Subclass of

WholeLifeIndividual

Comments

DEF: An IntentionallyConstructedObjectState that represents the whole life of the intentionally constructed object.

EXAMPLES:

USAGE: Use this class for an intentionally constructed object that is its temporal whole. Note that usually it is preferable to use one of the subclasses.

WholeLifeOrdinaryBiologicalObject
Diagram
Element Description

Type

Class

Name

WholeLifeOrdinaryBiologicalObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeOrdinaryBiologicalObject

Subclass of

OrdinaryBiologicalObjectState

Subclass of

WholeLifeBiologicalObject

Comments

DEF: An OrdinaryBiologicalObjectState that represents the whole life of the ordinary biological object.

EXAMPLES: a particular person from the instant that person was born to the instant that the person dies

USAGE: Use this class for describing individual living things that cease to exist when all of their parts are removed.

WholeLifeOrdinaryFunctionalObject
Diagram
Element Description

Type

Class

Name

WholeLifeOrdinaryFunctionalObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeOrdinaryFunctionalObject

Subclass of

OrdinaryFunctionalObjectState

Subclass of

WholeLifeFunctionalObject

Comments

DEF: An OrdinaryFunctionalObjectState that represents the whole life of the ordinary functional object.

EXAMPLES: a particular car (or traffic sign, road intersection, etc.) from the instant it is manufactured to the instant it is disassembled or otherwise ceases to be a car

USAGE: Use this class for describing individual manufactured things that were constructed for some purpose and that cease to exist when all of their parts are removed

WholeLifeOrdinaryPhysicalObject
Diagram
Element Description

Type

Class

Name

WholeLifeOrdinaryPhysicalObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeOrdinaryPhysicalObject

Subclass of

OrdinaryPhysicalObjectState

Subclass of

WholeLifePhysicalObject

Comments

DEF: A OrdinaryPhysicalObjectState that represents the whole life of the ordinary physical object.

EXAMPLES:

USAGE: Use this class for an ordinary physical object that is its temporal whole.

WholeLifePhysicalObject
Diagram
Element Description

Type

Class

Name

WholeLifePhysicalObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifePhysicalObject

Subclass of

PhysicalObjectState

Subclass of

WholeLifeIndividual

Comments

DEF: A PhysicalObjectState that represents the whole life of the physical object.

EXAMPLES:

USAGE: Use this class for a physical object that is its temporal whole. Note that it is generally preferable to use one of the subclasses.

WholeLifeSociallyConstructedActivity
Diagram
Element Description

Type

Class

Name

WholeLifeSociallyConstructedActivity

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeSociallyConstructedActivity

Subclass of

SociallyConstructedActivityState

Subclass of

WholeLifeIntentionallyConstructedActivity

Subclass of

WholeLifeSociallyConstructedObject

Comments

DEF: A WholeLifeSociallyConstructedObject that is also a WholeLifeActivity.

EXAMPLES:

USAGE: Use this class for an socially constructed activity that is its temporal whole.

WholeLifeSociallyConstructedObject
Diagram
Element Description

Type

Class

Name

WholeLifeSociallyConstructedObject

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeSociallyConstructedObject

Subclass of

SociallyConstructedObjectState

Subclass of

WholeLifeIndividual

Comments

DEF: A SociallyConstructedObjectState that represents the whole life of the socially constructed object.

EXAMPLES:

USAGE: Use this class for an socially constructed object that is its temporal whole.

WholeLifeSystem
Diagram
Element Description

Type

Class

Name

WholeLifeSystem

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeSystem

Subclass of

SystemState

Subclass of

WholeLifeOrdinaryPhysicalObject

Comments

DEF: An OrdinaryPhysicalObject that is an organized or connected group of PhysicalObjects that are SystemComponents and each have a role in how the overall system functions.

EXAMPLES: The entire life of a hurricane from when it was formed to when it ceases to exist.

USAGE: Use this class for a system that is its temporal whole. Note that usually it is preferable to use the subclass WholeLifeFunctionalSystem for systems that are intentionally constructed for some purpose.

WholeLifeSystemComponent
Diagram
Element Description

Type

Class

Name

WholeLifeSystemComponent

IRI

http://ontology.asam.net/ontologies/Core#WholeLifeSystemComponent

Subclass of

SystemComponentState

Subclass of

WholeLifePhysicalObject

Restriction

componentOf exactly 1 WholeLifeSystem

Comments

DEF: A SystemComponentState that represents the whole life of the system component.

EXAMPLES: the eye of a hurricane.

USAGE: Use this class to specify the whole life of a component of a system that is not functional.

A.1.2. Properties

aggregatedInto
Element Description

Type

ObjectProperty

Name

aggregatedInto

IRI

http://ontology.asam.net/ontologies/Core#aggregatedInto

Has domain

SpatioTemporalExtent

Has range

SpatioTemporalExtent

Characteristic

Asymmetric

Comments

DEF: A relationship type where a SpatioTemporalExtent may be aggregated into one or more others. This object property has the same meaning as the class Aggregation, but a different representation.

appliesTo
Element Description

Type

ObjectProperty

Name

appliesTo

IRI

http://ontology.asam.net/ontologies/Core#appliesTo

Comments

DEF: This relation is used to describe that a specification or regularity applies to a particular object. For example, this relation can be used to describe which lanes a speed limit sign applies to.

approximatelyEqualTo
Element Description

Type

ObjectProperty

Name

approximatelyEqualTo

IRI

http://ontology.asam.net/ontologies/Core#approximatelyEqualTo

Subproperty of

hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Characteristic

Symmetric

Comments

DEF: A hasQuantityRelation relationship type, where the value for the second quantity is within the range of the first quantity. The deviation between the values is no greater than +/- 10% of the first value.

beginningOf
Element Description

Type

ObjectProperty

Name

beginningOf

IRI

http://ontology.asam.net/ontologies/Core#beginningOf

Subproperty of

temporalPartOf

Has domain

Event

Inverse

hasBeginning

Comments

DEF: A temporalPartOf relationship type where a SpatioTemporalExtent has exactly one event that is its beginning.

behind
Element Description

Type

ObjectProperty

Name

behind

IRI

http://ontology.asam.net/ontologies/Core#behind

Subproperty of

hasRelativePosition

Inverse

inFrontOf

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is behind the second PhysicalObject.

behindConnectedTo
Element Description

Type

ObjectProperty

Name

behindConnectedTo

IRI

http://ontology.asam.net/ontologies/Core#behindConnectedTo

Subproperty of

longitudinalConnectedTo

Comments

DEF: A longitudinalConnectedTo relationship type where two PhysicalObjects are connected and the first PhysicalObject is behind the second PhysicalObject.

behindLeftOf
Element Description

Type

ObjectProperty

Name

behindLeftOf

IRI

http://ontology.asam.net/ontologies/Core#behindLeftOf

Subproperty of

hasRelativePosition

Inverse

frontRightOf

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is behind and to the left of the second PhysicalObject.

behindRightOf
Element Description

Type

ObjectProperty

Name

behindRightOf

IRI

http://ontology.asam.net/ontologies/Core#behindRightOf

Subproperty of

hasRelativePosition

Inverse

frontLeftOf

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is behind and to the right of the second PhysicalObject.

causes
Element Description

Type

ObjectProperty

Name

causes

IRI

http://ontology.asam.net/ontologies/Core#causes

Has domain

ActivityState

Has range

ActivityState

Comments

DEF: A relationship type where each activity is the cause of one or more events.

componentOf
Element Description

Type

ObjectProperty

Name

componentOf

IRI

http://ontology.asam.net/ontologies/Core#componentOf

Subproperty of

partOf

Has domain

SystemComponentState

Has range

SystemComponentState

Inverse

hasComponent

Characteristic

Functional

Comments

DEF: A partOf relationship type where each SystemComponent is partOf exactly one System.

connectedTo
Element Description

Type

ObjectProperty

Name

connectedTo

IRI

http://ontology.asam.net/ontologies/Core#connectedTo

Has domain

PhysicalObjectState

Has range

PhysicalObjectState

Characteristic

Symmetric

Comments

DEF: A relationship type where two physical object have a spatial connection and touch each other. Spatial connections create bridges for the transfer of energy or other things between the objects. This object property has the same meaning as the class SpatialConnection, but a different representation.

defines
Element Description

Type

ObjectProperty

Name

defines

IRI

http://ontology.asam.net/ontologies/Core#defines

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Characteristic

Transitive

Comments

DEF: A relationship type that relates two numeric parameters. It expresses that one parameter value is determined by the other parameter value.

endingOf
Element Description

Type

ObjectProperty

Name

endingOf

IRI

http://ontology.asam.net/ontologies/Core#endingOf

Subproperty of

temporalPartOf

Has domain

Event

Inverse

hasEnding

Comments

DEF: A temporalPartOf relationship type where a SpatioTemporalExtent has exactly one event that is its ending.

frontConnectedTo
Element Description

Type

ObjectProperty

Name

frontConnectedTo

IRI

http://ontology.asam.net/ontologies/Core#frontConnectedTo

Subproperty of

longitudinalConnectedTo

Comments

DEF: A longitudinalConnectedTo relationship type where two PhysicalObjects are connected and the first PhysicalObject is in front of the second PhysicalObject.

frontLeftOf
Element Description

Type

ObjectProperty

Name

frontLeftOf

IRI

http://ontology.asam.net/ontologies/Core#frontLeftOf

Subproperty of

hasRelativePosition

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is in front and to the left of the second PhysicalObject.

frontRightOf
Element Description

Type

ObjectProperty

Name

frontRightOf

IRI

http://ontology.asam.net/ontologies/Core#frontRightOf

Subproperty of

hasRelativePosition

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is in front and to the right of the second PhysicalObject.

hasAngle
Element Description

Type

ObjectProperty

Name

hasAngle

IRI

http://ontology.asam.net/ontologies/Core#hasAngle

Subproperty of

hasQuantity

Comments

DEF: A hasQuantity relationship type that specifies an angle quantity of something.

hasBeginning
Element Description

Type

ObjectProperty

Name

hasBeginning

IRI

http://ontology.asam.net/ontologies/Core#hasBeginning

Subproperty of

hasTemporalPart

Comments

DEF: Inverse relationship of beginningOf

hasColor
Element Description

Type

ObjectProperty

Name

hasColor

IRI

http://ontology.asam.net/ontologies/Core#hasColor

Subproperty of

hasProperty

Comments

DEF: A hasPropertyrelationship type that specifies the color of something.

hasComponent
Element Description

Type

ObjectProperty

Name

hasComponent

IRI

http://ontology.asam.net/ontologies/Core#hasComponent

Subproperty of

hasPart

Comments

DEF: Inverse relationship of componentOf

hasDirection
Element Description

Type

ObjectProperty

Name

hasDirection

IRI

http://ontology.asam.net/ontologies/Core#hasDirection

Subproperty of

hasQuantity

Comments

DEF: A hasQuantity relationship type that specifies a direction quantity of something.

hasDistance
Element Description

Type

ObjectProperty

Name

hasDistance

IRI

http://ontology.asam.net/ontologies/Core#hasDistance

Subproperty of

hasLength

Comments

DEF: A hasQuantity relationship type that specifies a distance quantity of something.

hasEnding
Element Description

Type

ObjectProperty

Name

hasEnding

IRI

http://ontology.asam.net/ontologies/Core#hasEnding

Subproperty of

hasTemporalPart

Comments

DEF: Inverse relationship of endingOf

hasGeometry
Element Description

Type

ObjectProperty

Name

hasGeometry

IRI

http://ontology.asam.net/ontologies/Core#hasGeometry

Subproperty of

hasProperty

Comments

DEF: A hasProperty relationship type that specifies the geometry of something, usually a physical object.

hasHeading
Element Description

Type

ObjectProperty

Name

hasHeading

IRI

http://ontology.asam.net/ontologies/Core#hasHeading

Subproperty of

hasDirection

Has domain

PhysicalObjectState

Comments

DEF: A hasQuantity relationship type that specifies a direction that a moving object is heading in. This property is required for defining leftOf, rightOf, etc.

hasLength
Element Description

Type

ObjectProperty

Name

hasLength

IRI

http://ontology.asam.net/ontologies/Core#hasLength

Subproperty of

hasQuantity

Comments

DEF: A hasQuantity relationship type that specifies the length quantity of something.

hasMember
Element Description

Type

ObjectProperty

Name

hasMember

IRI

http://ontology.asam.net/ontologies/Core#hasMember

Has domain

Set

Inverse

memberOf

Characteristic

Asymmetric

Comments

DEF: A relationship type stating that a Set has a particular thing as a member. A set can have anything of the respective type as a member.

hasObject
Element Description

Type

ObjectProperty

Name

hasObject

IRI

http://ontology.asam.net/ontologies/Core#hasObject

Subproperty of

hasParticipant

Inverse

objectOf

Comments

DEF: A hasParticipant relationship type that relates some activity to a physical object as object of the activity. The object is a non-actor participant. Inverse relationship of objectOf.

hasPart
Element Description

Type

ObjectProperty

Name

hasPart

IRI

http://ontology.asam.net/ontologies/Core#hasPart

Has domain

SpatioTemporalExtent

Has range

SpatioTemporalExtent

Inverse

partOf

Characteristic

Asymmetric

Comments

DEF: A relationship type where a SpatioTemporalExtent may consist of one or more others. Inverse relationship of partOf.

hasParticipant
Element Description

Type

ObjectProperty

Name

hasParticipant

IRI

http://ontology.asam.net/ontologies/Core#hasParticipant

Subproperty of

hasPart

Has domain

ActivityState

Has range

ActivityState

Inverse

participantOf

Comments

DEF: A hasPart relationship type where an ActivityState hasPart one or more Participants.

hasProperty
Element Description

Type

ObjectProperty

Name

hasProperty

IRI

http://ontology.asam.net/ontologies/Core#hasProperty

Comments

DEF: Relationship type for specifying properties of particular things

hasQuantity
Element Description

Type

ObjectProperty

Name

hasQuantity

IRI

http://ontology.asam.net/ontologies/Core#hasQuantity

Subproperty of

hasProperty

Comments

DEF: A relationship type for specifying quantities of particular things

hasQuantityRelation
Element Description

Type

ObjectProperty

Name

hasQuantityRelation

IRI

http://ontology.asam.net/ontologies/Core#hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Comments

DEF: A relationship type for basic arithmetic relationships between quantities

hasRelationDirection
Element Description

Type

ObjectProperty

Name

hasRelationDirection

IRI

http://ontology.asam.net/ontologies/Core#hasRelationDirection

Subproperty of

hasDirection

Subproperty of

relationProperty

Has domain

SpatialRelation

Has range

SpatialRelation

Comments

DEF: A hasQuantity relationship type that specifies the direction of a spatial relation.

hasRelativePosition
Element Description

Type

ObjectProperty

Name

hasRelativePosition

IRI

http://ontology.asam.net/ontologies/Core#hasRelativePosition

Has domain

PhysicalObjectState

Has range

PhysicalObjectState

Comments

DEF: Object properties derived from SpatialRelation

hasRelativeTime
Element Description

Type

ObjectProperty

Name

hasRelativeTime

IRI

http://ontology.asam.net/ontologies/Core#hasRelativeTime

Has domain

Event

Has range

Event

Comments

DEF: Object properties derived from TemporalRelation

hasSpatialObject
Element Description

Type

ObjectProperty

Name

hasSpatialObject

IRI

http://ontology.asam.net/ontologies/Core#hasSpatialObject

Subproperty of

relationProperty

Has domain

SpatialRelation

Has range

SpatialRelation

Characteristic

Functional

Characteristic

Inverse Functional

Comments

DEF: A relationProperty designating the object, destination, or "recepient" in a SpatialRelation.

hasSpatialSubject
Element Description

Type

ObjectProperty

Name

hasSpatialSubject

IRI

http://ontology.asam.net/ontologies/Core#hasSpatialSubject

Subproperty of

relationProperty

Has domain

SpatialRelation

Has range

SpatialRelation

Characteristic

Functional

Characteristic

Inverse Functional

Comments

DEF: A relationProperty designating the subject, origin, or "owner" in a SpatialRelation.

hasSpeed
Element Description

Type

ObjectProperty

Name

hasSpeed

IRI

http://ontology.asam.net/ontologies/Core#hasSpeed

Subproperty of

hasQuantity

Comments

DEF: A hasQuantity relationship type that specifies speed.

hasSubject
Element Description

Type

ObjectProperty

Name

hasSubject

IRI

http://ontology.asam.net/ontologies/Core#hasSubject

Subproperty of

hasParticipant

Inverse

subjectOf

Comments

DEF: A hasParticipant relationship type that relates some activity to a physical object as subject of the activity. The subject is an actor participant. Inverse relationship of subjectOf.

hasTemporalPart
Element Description

Type

ObjectProperty

Name

hasTemporalPart

IRI

http://ontology.asam.net/ontologies/Core#hasTemporalPart

Subproperty of

hasPart

Inverse

temporalPartOf

Comments

DEF: A hasPart relationship type where one spatio-temporal extent has another spatio-temporal extent as a temporal part. This implies that the temporal extent of the part is within the temporal extent of the whole. Inverse relationship of temporalPartOf.

inFrontOf
Element Description

Type

ObjectProperty

Name

inFrontOf

IRI

http://ontology.asam.net/ontologies/Core#inFrontOf

Subproperty of

hasRelativePosition

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is in front of the second PhysicalObject.

intendedRole
Element Description

Type

ObjectProperty

Name

intendedRole

IRI

http://ontology.asam.net/ontologies/Core#intendedRole

Has domain

FunctionalObjectState

Has range

FunctionalObjectState

Comments

DEF: A relationship type where a FunctionalObject has one or more intended role(s).

involves
Element Description

Type

ObjectProperty

Name

involves

IRI

http://ontology.asam.net/ontologies/Core#involves

Subproperty of

relationProperty

Has domain

DefinedRelationship

Has range

DefinedRelationship

Characteristic

Functional

Characteristic

Inverse Functional

Comments

DEF: A relationProperty that states that the classification of some thing in a role is involved in a relationship.

latitudinalConnectedTo
Element Description

Type

ObjectProperty

Name

latitudinalConnectedTo

IRI

http://ontology.asam.net/ontologies/Core#latitudinalConnectedTo

Subproperty of

connectedTo

Comments

DEF: A connectedTo relationship type where the connection is in the latitudinal (East-West) direction with reference to the reference coordinate system.

leftConnectedTo
Element Description

Type

ObjectProperty

Name

leftConnectedTo

IRI

http://ontology.asam.net/ontologies/Core#leftConnectedTo

Subproperty of

latitudinalConnectedTo

Comments

DEF: A latitudinalConnectedTo relationship type where two PhysicalObjects are connected and the first PhysicalObject is to the left of the second PhysicalObject.

leftOf
Element Description

Type

ObjectProperty

Name

leftOf

IRI

http://ontology.asam.net/ontologies/Core#leftOf

Subproperty of

hasRelativePosition

Inverse

rightOf

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is to the left of the second PhysicalObject.

locatedOn
Element Description

Type

ObjectProperty

Name

locatedOn

IRI

http://ontology.asam.net/ontologies/Core#locatedOn

Has domain

PhysicalObjectState

Characteristic

Asymmetric

Comments

DEF: Object property version of RelativeLocation. Note that when using "locatedOn", it is not possible to describe the actual position of the located object on the location object (you need a RelativeLocation for that).

longitudinalConnectedTo
Element Description

Type

ObjectProperty

Name

longitudinalConnectedTo

IRI

http://ontology.asam.net/ontologies/Core#longitudinalConnectedTo

Subproperty of

connectedTo

Comments

DEF: A connectedTo relationship type where the connection is in the longitudinal (North-South) direction with reference to the reference coordinate system.

memberOf
Element Description

Type

ObjectProperty

Name

memberOf

IRI

http://ontology.asam.net/ontologies/Core#memberOf

Characteristic

Asymmetric

Comments

DEF: A relationship type stating that a thing is a member of some Set. A set can have anything of the respective type as a member, even other Sets.

objectOf
Element Description

Type

ObjectProperty

Name

objectOf

IRI

http://ontology.asam.net/ontologies/Core#objectOf

Subproperty of

participantOf

Comments

DEF: A participantOf relationship type that relates some physical object as object to some activity. The object is a non-actor participant.

occursAfter
Element Description

Type

ObjectProperty

Name

occursAfter

IRI

http://ontology.asam.net/ontologies/Core#occursAfter

Subproperty of

occursAtDifferentTime

Inverse

occursBefore

Comments

DEF: A hasRelativeTime relationship type specifying that the first event (marking the beginning or ending of some activity of physical object) occurs after the second event.

occursAtDifferentTime
Element Description

Type

ObjectProperty

Name

occursAtDifferentTime

IRI

http://ontology.asam.net/ontologies/Core#occursAtDifferentTime

Subproperty of

hasRelativeTime

Characteristic

Asymmetric

Comments

DEF: A hasRelativeTime relationship type specifying that the first event (marking the beginning or ending of some activity of physical object) occurs at a different time from the second event.

occursAtSameTime
Element Description

Type

ObjectProperty

Name

occursAtSameTime

IRI

http://ontology.asam.net/ontologies/Core#occursAtSameTime

Subproperty of

hasRelativeTime

Characteristic

Symmetric

Comments

DEF: A hasRelativeTime relationship type specifying that the first event (marking the beginning or ending of some activity of physical object) occurs at the same this as the second event. Note that when two events occur at the same time, the events are both parts of the same PointInTime

occursBefore
Element Description

Type

ObjectProperty

Name

occursBefore

IRI

http://ontology.asam.net/ontologies/Core#occursBefore

Subproperty of

occursAtDifferentTime

Comments

DEF: A hasRelativeTime relationship type specifying that the first event (marking the beginning or ending of some activity of physical object) occurs before the second event

part
Element Description

Type

ObjectProperty

Name

part

IRI

http://ontology.asam.net/ontologies/Core#part

Subproperty of

relationProperty

Has domain

Aggregation

Has range

Aggregation

Characteristic

Functional

Characteristic

Inverse Functional

Comments

DEF: A relationProperty that states that each Aggregation has exactly one spatioTemporalExtent that is the part in the Aggregation.

partOf
Element Description

Type

ObjectProperty

Name

partOf

IRI

http://ontology.asam.net/ontologies/Core#partOf

Subproperty of

aggregatedInto

Comments

DEF: An aggregatedInto relationship type where a SpatioTemporalExtent may be part of another and the whole has emergent properties and is more than just the sum of its parts. This object property has the same meaning as the class Composition, but a different representation.

partOfPossibleWorld
Element Description

Type

ObjectProperty

Name

partOfPossibleWorld

IRI

http://ontology.asam.net/ontologies/Core#partOfPossibleWorld

Subproperty of

partOf

Comments

DEF: A partOf relationship type where a SpatioTemporalExtent may be partOf one or more PossibleWorld.

participantOf
Element Description

Type

ObjectProperty

Name

participantOf

IRI

http://ontology.asam.net/ontologies/Core#participantOf

Subproperty of

partOf

Has domain

Participant

Has range

Participant

Comments

DEF: A relationship stating the participation of a physical object in an activity.

quantityEqualTo
Element Description

Type

ObjectProperty

Name

quantityEqualTo

IRI

http://ontology.asam.net/ontologies/Core#quantityEqualTo

Subproperty of

hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Characteristic

Symmetric

Comments

DEF: A hasQuantityRelation relationship type, where the value for the second quantity is equal to the value of the first quantity.

quantityGreaterThan
Element Description

Type

ObjectProperty

Name

quantityGreaterThan

IRI

http://ontology.asam.net/ontologies/Core#quantityGreaterThan

Subproperty of

hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Inverse

quantityLessThanOrEqualTo

Characteristic

Transitive

Comments

DEF: A hasQuantityRelation relationship type, where the value for the second quantity is strictly greater than the value of the first quantity.

quantityGreaterThanOrEqualTo
Element Description

Type

ObjectProperty

Name

quantityGreaterThanOrEqualTo

IRI

http://ontology.asam.net/ontologies/Core#quantityGreaterThanOrEqualTo

Subproperty of

hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Inverse

quantityLessThan

Characteristic

Transitive

Comments

DEF: A hasQuantityRelation relationship type, where the value for the second quantity is greater than or equal to the value of the first quantity.

quantityLessThan
Element Description

Type

ObjectProperty

Name

quantityLessThan

IRI

http://ontology.asam.net/ontologies/Core#quantityLessThan

Subproperty of

hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Characteristic

Transitive

Comments

DEF: A hasQuantityRelation relationship type, where the value for the second quantity is strictly less than the value of the first quantity.

quantityLessThanOrEqualTo
Element Description

Type

ObjectProperty

Name

quantityLessThanOrEqualTo

IRI

http://ontology.asam.net/ontologies/Core#quantityLessThanOrEqualTo

Subproperty of

hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Characteristic

Transitive

Comments

DEF: A hasQuantityRelation relationship type, where the value for the second quantity is less than or equal to the value of the first quantity.

quantityNotEqualTo
Element Description

Type

ObjectProperty

Name

quantityNotEqualTo

IRI

http://ontology.asam.net/ontologies/Core#quantityNotEqualTo

Subproperty of

hasQuantityRelation

Has domain

PhysicalQuantity

Has range

PhysicalQuantity

Characteristic

Symmetric

Comments

DEF: A hasQuantityRelation relationship type, where the value for the second quantity is not equal to the value of the first quantity.

relationProperty
Element Description

Type

ObjectProperty

Name

relationProperty

IRI

http://ontology.asam.net/ontologies/Core#relationProperty

Has domain

Relationship

Comments

DEF: Relationship types that are generally used only to define other properties, for example, using SWRL.

rightConnectedTo
Element Description

Type

ObjectProperty

Name

rightConnectedTo

IRI

http://ontology.asam.net/ontologies/Core#rightConnectedTo

Subproperty of

latitudinalConnectedTo

Comments

DEF: A latitudinalConnectedTo relationship type where two PhysicalObjects are connected and the first PhysicalObject is to the right of the second PhysicalObject.

rightOf
Element Description

Type

ObjectProperty

Name

rightOf

IRI

http://ontology.asam.net/ontologies/Core#rightOf

Subproperty of

hasRelativePosition

Characteristic

Asymmetric

Comments

DEF: A hasRelativePosition relationship type where the first PhysicalObject is to the right of the second PhysicalObject.

rolePlayedBy
Element Description

Type

ObjectProperty

Name

rolePlayedBy

IRI

http://ontology.asam.net/ontologies/Core#rolePlayedBy

Subproperty of

relationProperty

Has domain

Role

Has range

Role

Comments

DEF: A relationProperty that states that a Role is the role of some Participant.

roleUsedIn
Element Description

Type

ObjectProperty

Name

roleUsedIn

IRI

http://ontology.asam.net/ontologies/Core#roleUsedIn

Subproperty of

relationProperty

Has domain

Role

Has range

Role

Comments

DEF: A relationProperty that states that a Role is used in an Activity.

subjectOf
Element Description

Type

ObjectProperty

Name

subjectOf

IRI

http://ontology.asam.net/ontologies/Core#subjectOf

Subproperty of

participantOf

Comments

DEF: A participantOf relationship type that relates some physical object as subject to some activity. The subject is an actor participant.

temporalPartOf
Element Description

Type

ObjectProperty

Name

temporalPartOf

IRI

http://ontology.asam.net/ontologies/Core#temporalPartOf

Subproperty of

partOf

Comments

DEF: A partOf relationship type where a SpatioTemporalExtent may be a temporal part of one or more other SpatioTemporalExtent. This object property has the same meaning as the class TemporalComposition, but a different representation.

whole
Element Description

Type

ObjectProperty

Name

whole

IRI

http://ontology.asam.net/ontologies/Core#whole

Subproperty of

relationProperty

Has domain

Aggregation

Has range

Aggregation

Characteristic

Functional

Characteristic

Inverse Functional

Comments

DEF: A relationProperty that states that each Aggregation has exactly one spatioTemporalExtent that is the whole in the Aggregation.

A.2. Domain

A.2.1. Classes

Accelerate
Diagram
Element Description

Type

Class

Name

Accelerate

IRI

http://ontology.asam.net/ontologies/Domain#Accelerate

Subclass of

MovingActivity

Subclass of

PrimitiveLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: A MovingActivity with one traffic participant during which the speed of the traffic participant increases continuously.

ActivityByLevel
Diagram
Element Description

Type

Class

Name

ActivityByLevel

IRI

http://ontology.asam.net/ontologies/Domain#ActivityByLevel

Subclass of

TrafficActivity

Comments

DEF: A set of activities categorized according to the complexity of the action ranging from primitive to mission level.

ActivityByNumberOfParticipants
Diagram
Element Description

Type

Class

Name

ActivityByNumberOfParticipants

IRI

http://ontology.asam.net/ontologies/Domain#ActivityByNumberOfParticipants

Subclass of

TrafficActivity

Comments

DEF: A set of activities categorized according to the number of traffic participants involved.

ActivityByStateChange
Diagram
Element Description

Type

Class

Name

ActivityByStateChange

IRI

http://ontology.asam.net/ontologies/Domain#ActivityByStateChange

Subclass of

TrafficActivity

Comments

DEF: A set of activities characterized by the participants moving or communicating.

ActivityByTrafficParticipantType
Diagram
Element Description

Type

Class

Name

ActivityByTrafficParticipantType

IRI

http://ontology.asam.net/ontologies/Domain#ActivityByTrafficParticipantType

Subclass of

TrafficActivity

Comments

DEF: A set of activities categorized according to the type of traffic participants.

AgricultureVehicle
Diagram
Element Description

Type

Class

Name

AgricultureVehicle

IRI

http://ontology.asam.net/ontologies/Domain#AgricultureVehicle

Subclass of

NonVRU

Subclass of

Vehicle

Comments

DEF: A vehicle that is specifically constructed for and used in farming.

Animal
Diagram
Element Description

Type

Class

Name

Animal

IRI

http://ontology.asam.net/ontologies/Domain#Animal

Subclass of

TrafficParticipantByParticipantType

Subclass of

VRU

Comments

DEF: A TrafficParticipant that is a non-human biological object.

ArtificialLightingCondition
Diagram
Element Description

Type

Class

Name

ArtificialLightingCondition

IRI

http://ontology.asam.net/ontologies/Domain#ArtificialLightingCondition

Subclass of

IlluminationCondition

Comments

DEF: An IlluminationCondition characterized by non-natural light from manufactured light sources, such as candles and electric lamps.

AutomaticAccessControlSystem
Diagram
Element Description

Type

Class

Name

AutomaticAccessControlSystem

IRI

http://ontology.asam.net/ontologies/Domain#AutomaticAccessControlSystem

Subclass of

SpecialStructure

Comments

DEF: A SpecialStructure that provides detection and audit to limit who can go where. They can be combined with assured physical barriers to provide delay into a secure site or can be used with demarcation barriers, meaning half-height gates, to provide only detection

BarriersOnRoadEdge
Diagram
Element Description

Type

Class

Name

BarriersOnRoadEdge

IRI

http://ontology.asam.net/ontologies/Domain#BarriersOnRoadEdge

Subclass of

RoadwayEdgeElement

Comments

DEF: A RoadwayEdgeElement that forms a barrier along the edge of the road.

Bicycle
Diagram
Element Description

Type

Class

Name

Bicycle

IRI

http://ontology.asam.net/ontologies/Domain#Bicycle

Subclass of

PrivateVehicle

Subclass of

VRU

Comments

DEF: A human-powered or motor-powered, pedal-driven, single-track Vehicle that has two wheels attached to a frame, one behind the other.

BorderCrossing
Diagram
Element Description

Type

Class

Name

BorderCrossing

IRI

http://ontology.asam.net/ontologies/Domain#BorderCrossing

Subclass of

SpecialStructure

Comments

DEF: A SpecialStructure that is located at the border between states and that supports monitoring and regulating the movement of people, animals, and goods across the border.

Bridge
Diagram
Element Description

Type

Class

Name

Bridge

IRI

http://ontology.asam.net/ontologies/Domain#Bridge

Subclass of

SpecialStructure

Comments

DEF: A SpecialStructure built to span a physical obstacle, such as a river, a valley or a road, withouth blocking the way underneath. A bridge provides passage over the obstacle.

BrokenClouds
Diagram
Element Description

Type

Class

Name

BrokenClouds

IRI

http://ontology.asam.net/ontologies/Domain#BrokenClouds

Subclass of

CloudCondition

Comments

DEF: BrokenClouds is a CloudCondition, is it described by the cloudinessLevel property using oktas unit, BrokenClouds is when the cloudinessLevel is 5-7 oktas.

BrokenLine
Diagram
Element Description

Type

Class

Name

BrokenLine

IRI

http://ontology.asam.net/ontologies/Domain#BrokenLine

Subclass of

LaneMarking

Comments

DEF: BrokenLine is a LaneMarking that is used to mark the middle of a two lane highway to separate traffic on both directions. Drivers are supposed to keep left but can cross the broken line for overtaking if situations permit

Building
Diagram
Element Description

Type

Class

Name

Building

IRI

http://ontology.asam.net/ontologies/Domain#Building

Subclass of

FixedRoadStructure

Comments

DEF: A FixedRoadStructure that is a built physical structure with a roof and walls standing more or less permanently in one place.

Bus
Diagram
Element Description

Type

Class

Name

Bus

IRI

http://ontology.asam.net/ontologies/Domain#Bus

Subclass of

NonVRU

Subclass of

PublicTransportationVehicle

Comments

DEF: A vehicle that is designed to carry many passengers and that usually travels along a fixed route according to a schedule.

BusLane
Diagram
Element Description

Type

Class

Name

BusLane

IRI

http://ontology.asam.net/ontologies/Domain#BusLane

Subclass of

LaneForSpecificParticipants

Comments

DEF: BusLane is a LaneForSpecificParticipants that is a lane where only buses are allowed to drive

CalmWind
Diagram
Element Description

Type

Class

Name

CalmWind

IRI

http://ontology.asam.net/ontologies/Domain#CalmWind

Subclass of

WindCondition

Comments

DEF: CalmWind is a WindCondition, is it described by the WindSpeed property using m/s, CalmWind is when the WindSpeed is 0 - 0.2 m/s.

Car
Diagram
Element Description

Type

Class

Name

Car

IRI

http://ontology.asam.net/ontologies/Domain#Car

Subclass of

NonVRU

Subclass of

PrivateVehicle

Comments

DEF: A Vehicle that is an automobile. It is a motor-powered vehicle used for transporting a small number of people.

ChangeLane
Diagram
Element Description

Type

Class

Name

ChangeLane

IRI

http://ontology.asam.net/ontologies/Domain#ChangeLane

Subclass of

DrivingActivity

Subclass of

LateralActivity

Subclass of

ManeuverLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An activity in which the subject vehicle starts from one lane at the beginning of the activity and drives in a different lane at the end of the activity.

ChangeToLeftLane
Diagram
Element Description

Type

Class

Name

ChangeToLeftLane

IRI

http://ontology.asam.net/ontologies/Domain#ChangeToLeftLane

Subclass of

ChangeLane

Comments

DEF: A ChangeLane activity where the vehicle drives in one lane at the beginning of the activity and drives in the lane left to the original lane at the end of the activity.

ChangeToRightLane
Diagram
Element Description

Type

Class

Name

ChangeToRightLane

IRI

http://ontology.asam.net/ontologies/Domain#ChangeToRightLane

Subclass of

ChangeLane

Comments

DEF: A ChangeLane activity where the vehicle drives in one lane at the beginning of the activity and drives in the lane right to the original lane at the end of the activity.

Clear
Diagram
Element Description

Type

Class

Name

Clear

IRI

http://ontology.asam.net/ontologies/Domain#Clear

Subclass of

CloudCondition

Comments

DEF: Clear is a CloudCondition, is it described by the cloudinessLevel property using oktas unit, Clear is when the cloudinessLevel is 0-1 oktas.

CloseUp
Diagram
Element Description

Type

Class

Name

CloseUp

IRI

http://ontology.asam.net/ontologies/Domain#CloseUp

Subclass of

ActivityByTrafficParticipantType

Subclass of

ManeuverLevelActivity

Subclass of

MovingActivity

Subclass of

MultiParticipantActivity

Comments

DEF: A MovingActivity during which the subject traffic participant moves closer to the object traffic participant.

CloudCondition
Diagram
Element Description

Type

Class

Name

CloudCondition

IRI

http://ontology.asam.net/ontologies/Domain#CloudCondition

Subclass of

WeatherCondition

Comments

DEF: A WeatherCondition in which a specific amount of the sky is covered by clouds, which affects the illumination of things. This condition can occur during day and night. The amount of sky covered in clouds may be described with the cloudinessLevel property.

Cloudburst
Diagram
Element Description

Type

Class

Name

Cloudburst

IRI

http://ontology.asam.net/ontologies/Domain#Cloudburst

Subclass of

RainfallCondition

Comments

DEF: Cloudburst is a RainfallCondition, is it described by the precipitationIntensity property using mm/hr, Cloudburst is when the precipitationIntensity is > 100mm/hr.

CommunicationActivity
Diagram
Element Description

Type

Class

Name

CommunicationActivity

IRI

http://ontology.asam.net/ontologies/Domain#CommunicationActivity

Subclass of

ActivityByStateChange

Comments

DEF: A set of activites that are characterized by the subject traffic participant giving visual or acoustic signals in order to relay its intentions to other traffic participants.

CommunicationCondition
Diagram
Element Description

Type

Class

Name

CommunicationCondition

IRI

http://ontology.asam.net/ontologies/Domain#CommunicationCondition

Subclass of

ConnectivityCondition

Comments

DEF: A ConnectivityCondition that defines the type of communication method used for the communication between vehicle and other elements of the traffic domain, such as infrastructure (V2I) or other vehicles (V2V).

ConnectivityCondition
Diagram
Element Description

Type

Class

Name

ConnectivityCondition

IRI

http://ontology.asam.net/ontologies/Domain#ConnectivityCondition

Subclass of

PhysicalProperty

Subclass of

EnvironmentalCondition

Comments

DEF: An EnvironmentalCondition that indicates a vehicle’s ability to receive data from or transmit data to external systems. The purpose of the data transfer can be positioning of the vehicle or communication with other elements of the traffic domain.

ConstructionSign
Diagram
Element Description

Type

Class

Name

ConstructionSign

IRI

http://ontology.asam.net/ontologies/Domain#ConstructionSign

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that is a traffic sign indicating construction or landscaping work in a specific area.

ConstructionSiteDetour
Diagram
Element Description

Type

Class

Name

ConstructionSiteDetour

IRI

http://ontology.asam.net/ontologies/Domain#ConstructionSiteDetour

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that provides a detour or temporary route around an area that needs to be avoided, for example, due to construction work.

ConstructionVehicle
Diagram
Element Description

Type

Class

Name

ConstructionVehicle

IRI

http://ontology.asam.net/ontologies/Domain#ConstructionVehicle

Subclass of

NonVRU

Subclass of

Vehicle

Comments

DEF: A vehicle that is specifically built for and used in construction work.

Cracks
Diagram
Element Description

Type

Class

Name

Cracks

IRI

http://ontology.asam.net/ontologies/Domain#Cracks

Subclass of

RoadSurfaceFeature

Comments

DEF:Cracks is a RoadSurfaceFeature that are fractures or discontinuation of the road surface.

Cross
Diagram
Element Description

Type

Class

Name

Cross

IRI

http://ontology.asam.net/ontologies/Domain#Cross

Subclass of

ActivityByTrafficParticipantType

Subclass of

ManeuverLevelActivity

Subclass of

MovingActivity

Subclass of

MultiParticipantActivity

Comments

DEF: A MovingActivity during which the path of the subject traffic participant crosses the path of the object traffic participant.

CrossRoad
Diagram
Element Description

Type

Class

Name

CrossRoad

IRI

http://ontology.asam.net/ontologies/Domain#CrossRoad

Subclass of

IntersectionAtGrade

Comments

DEF: An Intersection where exactly four roads meet.

Curb
Diagram
Element Description

Type

Class

Name

Curb

IRI

http://ontology.asam.net/ontologies/Domain#Curb

Subclass of

PhysicalDivider

Comments

DEF: Curb is a PhysicalDivider that is the edge where a raised sidewalk or road median/central reservation meets a street or other roadway.

CutIn
Diagram
Element Description

Type

Class

Name

CutIn

IRI

http://ontology.asam.net/ontologies/Domain#CutIn

Subclass of

DrivingActivity

Subclass of

ManeuverLevelActivity

Subclass of

MovingActivity

Subclass of

MultiParticipantActivity

Comments

DEF: A MovingActivity in which the subject traffic participant ends up directly in front of the object traffic participant. A cutting-in activity can affect the behavior of the object.

CutOut
Diagram
Element Description

Type

Class

Name

CutOut

IRI

http://ontology.asam.net/ontologies/Domain#CutOut

Subclass of

DrivingActivity

Subclass of

ManeuverLevelActivity

Subclass of

MovingActivity

Subclass of

MultiParticipantActivity

Comments

DEF: A MovingActivity where the subject and the object traffic participants start in the same lane. During the activity, the object traffic participant suddenly leaves the lane.

CycleLane
Diagram
Element Description

Type

Class

Name

CycleLane

IRI

http://ontology.asam.net/ontologies/Domain#CycleLane

Subclass of

LaneForSpecificParticipants

Comments

DEF: CycleLane is a LaneForSpecificParticipants that is paved and intended for bicycle use only. Contains only regions or ground specifically designated for cyclists where pedestrians and cars should not enter.

DayLightingCondition
Diagram
Element Description

Type

Class

Name

DayLightingCondition

IRI

http://ontology.asam.net/ontologies/Domain#DayLightingCondition

Subclass of

IlluminationCondition

Comments

DEF: An IlluminationCondition where illuminance is greater than 2000 lux.

Debris
Diagram
Element Description

Type

Class

Name

Debris

IRI

http://ontology.asam.net/ontologies/Domain#Debris

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that consists of scattered pieces of rock, rubbish or other loose material on the road surface; placed not by intention, but by accident or construction work.

Decelerate
Diagram
Element Description

Type

Class

Name

Decelerate

IRI

http://ontology.asam.net/ontologies/Domain#Decelerate

Subclass of

MovingActivity

Subclass of

PrimitiveLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: A MovingActivity with one traffic participant during which the speed of the traffic participant decreases continuously.

DistributorRoad
Diagram
Element Description

Type

Class

Name

DistributorRoad

IRI

http://ontology.asam.net/ontologies/Domain#DistributorRoad

Subclass of

Road

Comments

DEF: A Road with low to moderate capacity that connects local and minor roads to arterial roads.

DividedRoad
Diagram
Element Description

Type

Class

Name

DividedRoad

IRI

http://ontology.asam.net/ontologies/Domain#DividedRoad

Subclass of

Road

Comments

DEF: A type of road that has several carriageways for traffic travelling in opposite directions. The carriageways are separated by a central reservation.

DomainConcepts
Diagram
Element Description

Type

Class

Name

DomainConcepts

IRI

http://ontology.asam.net/ontologies/Domain#DomainConcepts

Subclass of

Thing

Comments

DEF: Top-level container that separates domain concepts in the OpenXOntology. The DomainConcepts define central concepts of the road traffic domain, for example, lane, road, and vehicle. It contains only concepts that are shared by multiple ASAM OpenX standards using the ASAM OpenXOntology and that are not controlled by a single standard.

DoubleSolidLine
Diagram
Element Description

Type

Class

Name

DoubleSolidLine

IRI

http://ontology.asam.net/ontologies/Domain#DoubleSolidLine

Subclass of

LaneMarking

Comments

DEF: DoubleSolidLine is a LaneMarking that separates two lanes.

DrivableAreaElement
Diagram
Element Description

Type

Class

Name

DrivableAreaElement

IRI

http://ontology.asam.net/ontologies/Domain#DrivableAreaElement

Subclass of

WholeLifeFunctionalSystem

Subclass of

WholeLifeFunctionalSystemComponent

Subclass of

WholeLifeSystemComponent

Subclass of

RoadTopologyAndTrafficInfrastructure

Comments

DEF: Areas in the traffic infrastructure that vehicles are supposed and permitted to drive in.

Driver
Diagram
Element Description

Type

Class

Name

Driver

IRI

http://ontology.asam.net/ontologies/Domain#Driver

Subclass of

Human

Subclass of

VRU

Comments

DEF: A HumanParticipant who controls a vehicle.

DrivingActivity
Diagram
Element Description

Type

Class

Name

DrivingActivity

IRI

http://ontology.asam.net/ontologies/Domain#DrivingActivity

Subclass of

MovingActivity

Subclass of

VehicleActivity

Comments

DEF: A set of moving activites that are characterized by a continuous movement of the traffic participants during the complete activity.

DynamicTrafficSign
Diagram
Element Description

Type

Class

Name

DynamicTrafficSign

IRI

http://ontology.asam.net/ontologies/Domain#DynamicTrafficSign

Subclass of

TrafficSignByState

Comments

DEF: A traffic sign whose content can be changed.

EmergencyVehicle
Diagram
Element Description

Type

Class

Name

EmergencyVehicle

IRI

http://ontology.asam.net/ontologies/Domain#EmergencyVehicle

Subclass of

NonVRU

Subclass of

OfficialVehicle

Comments

DEF: A vehicle that is used by an emergency service to respond to incidents.

EnvironmentalCondition
Diagram
Element Description

Type

Class

Name

EnvironmentalCondition

IRI

http://ontology.asam.net/ontologies/Domain#EnvironmentalCondition

Subclass of

DomainConcepts

Comments

DEF: A set of environmental parameters that applies to a complete area, such as a town or a district. Conditions can have natural causes, for example rain or snowfall, or can be created artificially, for example by light sources or communication devices using specific methods like vehice-to-vehicle communication.

FewClouds
Diagram
Element Description

Type

Class

Name

FewClouds

IRI

http://ontology.asam.net/ontologies/Domain#FewClouds

Subclass of

CloudCondition

Comments

DEF: FewClouds is a CloudCondition, is it described by the cloudinessLevel property using oktas unit, FewClouds is when the cloudinessLevel is 1-2 oktas.

FixedRoadStructure
Diagram
Element Description

Type

Class

Name

FixedRoadStructure

IRI

http://ontology.asam.net/ontologies/Domain#FixedRoadStructure

Subclass of

WholeLifeFunctionalSystemComponent

Subclass of

WholeLifeSystemComponent

Subclass of

RoadTopologyAndTrafficInfrastructure

Comments

DEF: An element of the traffic infrastructure with a physical form that is either built or natural and is located near to or on a drivable area. Vehicles are not allowed to drive on a FixedRoadStructure.

FlashHeadlights
Diagram
Element Description

Type

Class

Name

FlashHeadlights

IRI

http://ontology.asam.net/ontologies/Domain#FlashHeadlights

Subclass of

VehicleCommunicationActivity

Comments

DEF: A VehicleCommunicatingActivity in which the subject vehicle communicates a potential warning to the object vehicle by either briefly switching on the headlights or switching between low beams and high beams.

FoggyCondition
Diagram
Element Description

Type

Class

Name

FoggyCondition

IRI

http://ontology.asam.net/ontologies/Domain#FoggyCondition

Subclass of

ParticulatesCondition

Comments

DEF: A ParticulateCondition where the particles are a mixture of non-precipitating water droplets or ice crystals.

FollowRoadUser
Diagram
Element Description

Type

Class

Name

FollowRoadUser

IRI

http://ontology.asam.net/ontologies/Domain#FollowRoadUser

Subclass of

ManeuverLevelActivity

Subclass of

MultiParticipantActivity

Comments

DEF: An activity in which the subject traffic participant drives behind the object traffic participant at the same speed.

FollowTargetSpeed
Diagram
Element Description

Type

Class

Name

FollowTargetSpeed

IRI

http://ontology.asam.net/ontologies/Domain#FollowTargetSpeed

Subclass of

ManeuverLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An activity in which the subject traffic participant drives at a fixed, configured speed.

FollowTrajectory
Diagram
Element Description

Type

Class

Name

FollowTrajectory

IRI

http://ontology.asam.net/ontologies/Domain#FollowTrajectory

Subclass of

ManeuverLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An activity in which the subject traffic participant follows a defined driving path for a specific period of time.

FreshBreeze
Diagram
Element Description

Type

Class

Name

FreshBreeze

IRI

http://ontology.asam.net/ontologies/Domain#FreshBreeze

Subclass of

WindCondition

Comments

DEF: FreshBreeze is a WindCondition, is it described by the WindSpeed property using m/s, FreshBreeze is when the WindSpeed is 8.0-10.7 m/s.

GLONASS
Diagram
Element Description

Type

Class

Name

GLONASS

IRI

http://ontology.asam.net/ontologies/Domain#GLONASS

Subclass of

PositioningCondition

Comments

DEF: A PositioningCondition in which the vehicle’s position is determined using the GLONASS global navigation satellite system.

GPS
Diagram
Element Description

Type

Class

Name

GPS

IRI

http://ontology.asam.net/ontologies/Domain#GPS

Subclass of

PositioningCondition

Comments

DEF: A PositioningCondition in which the vehicle’s position is determined using the Global Positioning System (GPS).

Gale
Diagram
Element Description

Type

Class

Name

Gale

IRI

http://ontology.asam.net/ontologies/Domain#Gale

Subclass of

WindCondition

Comments

DEF: Gale is a WindCondition, is it described by the WindSpeed property using m/s, Gale is when the WindSpeed is 17.2-20.7 m/s.

Galileo
Diagram
Element Description

Type

Class

Name

Galileo

IRI

http://ontology.asam.net/ontologies/Domain#Galileo

Subclass of

PositioningCondition

Comments

DEF: A PositioningCondition in which the vehicle’s position is determined using the Galileo global navigation satellite system.

GentleBreeze
Diagram
Element Description

Type

Class

Name

GentleBreeze

IRI

http://ontology.asam.net/ontologies/Domain#GentleBreeze

Subclass of

WindCondition

Comments

DEF: GentleBreeze is a WindCondition, is it described by the WindSpeed property using m/s, GentleBreeze is when the WindSpeed is 3.4-5.4 m/s.

GeofencedZone
Diagram
Element Description

Type

Class

Name

GeofencedZone

IRI

http://ontology.asam.net/ontologies/Domain#GeofencedZone

Subclass of

TrafficZone

Comments

DEF: A geographic Zone with a virtual perimeter. Geofencing uses the GPS signal or other device services to track when a device crosses the virtual perimeter and enters the geo-fenced zone.

GoodsVehicle
Diagram
Element Description

Type

Class

Name

GoodsVehicle

IRI

http://ontology.asam.net/ontologies/Domain#GoodsVehicle

Subclass of

Vehicle

Comments

DEF: Goods vehicles are vehicles with their designed purpose of transporting goods

GradeSeparatedIntersection
Diagram
Element Description

Type

Class

Name

GradeSeparatedIntersection

IRI

http://ontology.asam.net/ontologies/Domain#GradeSeparatedIntersection

Subclass of

Junction

Comments

DEF: A Junction with two or more roads at different heights (grades). This layout ensures that the traffic flow on each axis is not disrupted by the crossing. The grade separation of the roads is achieved by means of overpasses, for example bridges, or underpasses, for example tunnels, or a combination of both.

GrassShoulder
Diagram
Element Description

Type

Class

Name

GrassShoulder

IRI

http://ontology.asam.net/ontologies/Domain#GrassShoulder

Subclass of

LaneWithConstructionProperties

Comments

DEF: GrassShoulder is a LanesWithConstructionProperties that is an emergency stopping lane by the verge of a road or motorway. Hence, a shoulder, where the surface of a lane consists out of grass is called grass shoulder

GuardRail
Diagram
Element Description

Type

Class

Name

GuardRail

IRI

http://ontology.asam.net/ontologies/Domain#GuardRail

Subclass of

PhysicalDivider

Comments

DEF: GuardRail is a PhysicalDivider that is a strong fence at the side of a road or in the middle of an expressway, intended to reduce the risk of serious accidents; a crash barrier.

HeavyRain
Diagram
Element Description

Type

Class

Name

HeavyRain

IRI

http://ontology.asam.net/ontologies/Domain#HeavyRain

Subclass of

RainfallCondition

Comments

DEF: HeavyRain is a RainfallCondition, is it described by the precipitationIntensity property using mm/hr, HeavyRain is when the precipitationIntensity is 7.6 - 50 mm/hr.

HeavySnow
Diagram
Element Description

Type

Class

Name

HeavySnow

IRI

http://ontology.asam.net/ontologies/Domain#HeavySnow

Subclass of

SnowfallCondition

Comments

DEF: HeavySnow is a SnowfallCondition, is it described by the SnowfallIntensity property using visibility, HeavySnow is when the SnowfallIntensity is < 0.5 km.

HonkHorn
Diagram
Element Description

Type

Class

Name

HonkHorn

IRI

http://ontology.asam.net/ontologies/Domain#HonkHorn

Subclass of

VehicleCommunicationActivity

Comments

DEF: A VehicleCommunicatingActivity in which the subject vehicle sounds the car horn in order to warn other traffic participants.

Human
Diagram
Element Description

Type

Class

Name

Human

IRI

http://ontology.asam.net/ontologies/Domain#Human

Subclass of

TrafficParticipantByParticipantType

Comments

DEF: A human TrafficParticipant that is driving or moving in traffic, either within/on a vehicle or as pedestrian.

HumanActivity
Diagram
Element Description

Type

Class

Name

HumanActivity

IRI

http://ontology.asam.net/ontologies/Domain#HumanActivity

Subclass of

ActivityByTrafficParticipantType

Comments

DEF: A set of activities performed by humans, such as pedestrians.

Hurricane
Diagram
Element Description

Type

Class

Name

Hurricane

IRI

http://ontology.asam.net/ontologies/Domain#Hurricane

Subclass of

WindCondition

Comments

DEF: Hurricane is a WindCondition, is it described by the WindSpeed property using m/s, Hurricane is when the WindSpeed is >= 32.7 m/s.

IlluminationCondition
Diagram
Element Description

Type

Class

Name

IlluminationCondition

IRI

http://ontology.asam.net/ontologies/Domain#IlluminationCondition

Subclass of

PhysicalProperty

Subclass of

EnvironmentalCondition

Comments

DEF: An EnvironmentalCondition that is defined by the characteristics of light within a specific traffic situation. The objects that emit the light may be manufactured, such as lamps, or natural, like the sun. Illumination can improve the visibility of things or deteriorate it, for example by shadows or glare.

InformationSign
Diagram
Element Description

Type

Class

Name

InformationSign

IRI

http://ontology.asam.net/ontologies/Domain#InformationSign

Subclass of

TrafficSignByFunction

Comments

DEF: A traffic sign that provides information to traffic participants regarding the route, traffic flow, or road condition, but does not enforce any traffic rule.

InterferenceZone
Diagram
Element Description

Type

Class

Name

InterferenceZone

IRI

http://ontology.asam.net/ontologies/Domain#InterferenceZone

Subclass of

TrafficZone

Comments

DEF: A zone with limited positioning-signal reception caused by dense foliage on surfaces, tall buildings, tunnels, atmospheric interference, or similar.

IntersectionAtGrade
Diagram
Element Description

Type

Class

Name

IntersectionAtGrade

IRI

http://ontology.asam.net/ontologies/Domain#IntersectionAtGrade

Subclass of

Junction

Comments

DEF: A Junction where two or more roads meet at the same level.

Junction
Diagram
Element Description

Type

Class

Name

Junction

IRI

http://ontology.asam.net/ontologies/Domain#Junction

Subclass of

WholeLifeFunctionalSystem

Subclass of

WholeLifeSystem

Subclass of

RoadTopologyAndTrafficInfrastructure

Comments

DEF: A RoadTopologyAndTrafficInfrastructure where two or more roads meet.

KeepLane
Diagram
Element Description

Type

Class

Name

KeepLane

IRI

http://ontology.asam.net/ontologies/Domain#KeepLane

Subclass of

DrivingActivity

Subclass of

LongitudinalActivity

Subclass of

ManeuverLevelActivity

Comments

DEF: A MovingActivity in which the subject traffic participant keeps the same lane for the entire duration of the activity.

Lane
Diagram
Element Description

Type

Class

Name

Lane

IRI

http://ontology.asam.net/ontologies/Domain#Lane

Subclass of

LaneElement

Comments

DEF: Lane is a LaneElements that is a division of a road that is marked out by dividers, it is intended for use by traffic participants. The lane class contains the type of lanes that can be used to form part of the road

LaneDivider
Diagram
Element Description

Type

Class

Name

LaneDivider

IRI

http://ontology.asam.net/ontologies/Domain#LaneDivider

Subclass of

LaneElement

Comments

DEF: LaneDivider is a LaneElement that is the extruded or painted component that separate one lane from the others. Typical lane dividers include lane markings and physical extrusion features such as guardrails or curbs.

LaneElement
Diagram
Element Description

Type

Class

Name

LaneElement

IRI

http://ontology.asam.net/ontologies/Domain#LaneElement

Subclass of

DrivableAreaElement

Comments

DEF: A DriveableArea element that represents a part of a road, usually marked by lines, that is designed to be used by a single line of vehicles. Lanes may have different types, for example, dependent on the allowed vehicle types, and may have different characteristics, such as markings and curbs.

LaneForSpecificParticipants
Diagram
Element Description

Type

Class

Name

LaneForSpecificParticipants

IRI

http://ontology.asam.net/ontologies/Domain#LaneForSpecificParticipants

Subclass of

Lane

Comments

DEF: LaneForSpecificParticipants is a lane, which can be assoiated and categorized based on specific types of allowed traffic participants.

LaneMarking
Diagram
Element Description

Type

Class

Name

LaneMarking

IRI

http://ontology.asam.net/ontologies/Domain#LaneMarking

Subclass of

LaneDivider

Subclass of

RoadMarking

Comments

DEF: LaneMarking is a type of LaneDivider, that is applied to individual indicating traffic rules such as lane change restriction.

LaneSection
Diagram
Element Description

Type

Class

Name

LaneSection

IRI

http://ontology.asam.net/ontologies/Domain#LaneSection

Subclass of

LaneElement

Comments

DEF: LaneSection is a LaneElements. Lanes may be split into multiple lane sections. Each lane section contains a fixed number of lanes. Every time the number of lanes changes, a new lane section is required Lane sections are defined in ascending order along the road reference line.

LaneWithConstructionProperties
Diagram
Element Description

Type

Class

Name

LaneWithConstructionProperties

IRI

http://ontology.asam.net/ontologies/Domain#LaneWithConstructionProperties

Subclass of

Lane

Comments

DEF: LaneWithConstructionProperties is a lane, which can be assoiated and categorized based on surface material.

LaneWithSpecificRegulations
Diagram
Element Description

Type

Class

Name

LaneWithSpecificRegulations

IRI

http://ontology.asam.net/ontologies/Domain#LaneWithSpecificRegulations

Subclass of

Lane

Comments

DEF: LaneWithSpecificRegulations is a lane, which can be assoiated and categorized based on allowed traffic function and rules.

LateralActivity
Diagram
Element Description

Type

Class

Name

LateralActivity

IRI

http://ontology.asam.net/ontologies/Domain#LateralActivity

Subclass of

MovingActivity

Comments

DEF: A MovingActivity which is characterized by sideways movement.

LightAir
Diagram
Element Description

Type

Class

Name

LightAir

IRI

http://ontology.asam.net/ontologies/Domain#LightAir

Subclass of

WindCondition

Comments

DEF: LightAir is a WindCondition, is it described by the WindSpeed property using m/s, LightAir is when the WindSpeed is 0.3-1.5 m/s.

LightBreeze
Diagram
Element Description

Type

Class

Name

LightBreeze

IRI

http://ontology.asam.net/ontologies/Domain#LightBreeze

Subclass of

WindCondition

Comments

DEF: LightBreeze is a WindCondition, is it described by the WindSpeed property using m/s, LightBreeze is when the WindSpeed is 1.6-3.3 m/s.

LightRain
Diagram
Element Description

Type

Class

Name

LightRain

IRI

http://ontology.asam.net/ontologies/Domain#LightRain

Subclass of

RainfallCondition

Comments

DEF: LightRain is a RainfallCondition, is it described by the precipitationIntensity property using mm/hr, LightRain is when the precipitationIntensity is < 2.5 mm/hr.

LightSnow
Diagram
Element Description

Type

Class

Name

LightSnow

IRI

http://ontology.asam.net/ontologies/Domain#LightSnow

Subclass of

SnowfallCondition

Comments

DEF: LightSnow is a SnowfallCondition, is it described by the SnowfallIntensity property using visibility, LightSnowis is when the SnowfallIntensity is > 1.0 km.

LongitudinalActivity
Diagram
Element Description

Type

Class

Name

LongitudinalActivity

IRI

http://ontology.asam.net/ontologies/Domain#LongitudinalActivity

Subclass of

MovingActivity

Comments

DEF: A MovingActivity which is characterized by lengthwise movement.

LooseSurface
Diagram
Element Description

Type

Class

Name

LooseSurface

IRI

http://ontology.asam.net/ontologies/Domain#LooseSurface

Subclass of

RoadSurface

Comments

DEF:LooseSurface is a RoadSurface that contains loose chippings such as loose gravel or stone fragments on a road surface

MakeALeftTurn
Diagram
Element Description

Type

Class

Name

MakeALeftTurn

IRI

http://ontology.asam.net/ontologies/Domain#MakeALeftTurn

Subclass of

MakeATurn

Comments

DEF: A MakeATurn activity during which the subject traffic participant navigates through an intersection and exits the intersection on a road that is located to the left of the orginal road.

MakeARightTurn
Diagram
Element Description

Type

Class

Name

MakeARightTurn

IRI

http://ontology.asam.net/ontologies/Domain#MakeARightTurn

Subclass of

MakeATurn

Comments

DEF: A MakeATurn activity during which the subject traffic participant navigates through an intersection and exits the intersection on a road that is located to the right of the orginal road.

MakeATurn
Diagram
Element Description

Type

Class

Name

MakeATurn

IRI

http://ontology.asam.net/ontologies/Domain#MakeATurn

Subclass of

DrivingActivity

Subclass of

MissionLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: A MovingActivity at mission level during which the subject traffic participant changes its direction in reference to a traffic infrastructure element, such as an intersection or a road, and has a different direction at the end of the activity.

ManeuverLevelActivity
Diagram
Element Description

Type

Class

Name

ManeuverLevelActivity

IRI

http://ontology.asam.net/ontologies/Domain#ManeuverLevelActivity

Subclass of

ActivityByLevel

Comments

DEF: A set of activities with actions on maneuver level. This level contains abstract descriptions for the movements of a vehicle. It abstracts the physically continuous vehicle motion into a discrete logical state. This state is only partially observable from the outside. Every driving maneuver is linked to an intention.

Manhole
Diagram
Element Description

Type

Class

Name

Manhole

IRI

http://ontology.asam.net/ontologies/Domain#Manhole

Subclass of

RoadSurfaceFeature

Comments

DEF:Manhole is a RoadSurfaceFeature that is an opening in road to access canal system. Has to be big enough to fit a person and includes squared ones.

MarineCondition
Diagram
Element Description

Type

Class

Name

MarineCondition

IRI

http://ontology.asam.net/ontologies/Domain#MarineCondition

Subclass of

ParticulatesCondition

Comments

DEF: An AmbientCondition in an area near the sea where spray from the sea gets mixed into the atmosphere.

MinorRoad
Diagram
Element Description

Type

Class

Name

MinorRoad

IRI

http://ontology.asam.net/ontologies/Domain#MinorRoad

Subclass of

Road

Comments

DEF: MinorRoad is a Road that provides access to residential areas and other local developments.

MissionLevelActivity
Diagram
Element Description

Type

Class

Name

MissionLevelActivity

IRI

http://ontology.asam.net/ontologies/Domain#MissionLevelActivity

Subclass of

ActivityByLevel

Comments

DEF: MissionLevelActivity is a ActivityByLevel, which structures the vehicle behavior at the level of mission or route planning and serves to achieve a higher-level goal. "Mission elements are abstract task descriptions with no knowledge about how they will be executed by the system."

ModerateBreeze
Diagram
Element Description

Type

Class

Name

ModerateBreeze

IRI

http://ontology.asam.net/ontologies/Domain#ModerateBreeze

Subclass of

WindCondition

Comments

DEF: ModerateBreeze is a WindCondition, is it described by the WindSpeed property using m/s, ModerateBreeze is when the WindSpeed is 5.5-7.9 m/s.

ModerateRain
Diagram
Element Description

Type

Class

Name

ModerateRain

IRI

http://ontology.asam.net/ontologies/Domain#ModerateRain

Subclass of

RainfallCondition

Comments

DEF: ModerateRain is a RainfallCondition, is it described by the precipitationIntensity property using mm/hr, ModerateRain is when the precipitationIntensity is <2.5 - 7.6 mm/hr.

ModerateSnow
Diagram
Element Description

Type

Class

Name

ModerateSnow

IRI

http://ontology.asam.net/ontologies/Domain#ModerateSnow

Subclass of

SnowfallCondition

Comments

DEF: ModerateSnow is a SnowfallCondition, is it described by the SnowfallIntensity property using visibility, ModerateSnow is when the SnowfallIntensity is 0.5 - 1.0 km.

Motorcycle
Diagram
Element Description

Type

Class

Name

Motorcycle

IRI

http://ontology.asam.net/ontologies/Domain#Motorcycle

Subclass of

PrivateVehicle

Subclass of

VRU

Comments

DEF: A motor-powered Vehicle, also called motorbike or bike, that has two or three wheels and is used for transporting people.

Motorway
Diagram
Element Description

Type

Class

Name

Motorway

IRI

http://ontology.asam.net/ontologies/Domain#Motorway

Subclass of

Road

Comments

DEF: A Road that is designed for high speed and high traffic volume and has controlled entries and exits. Non-motorized vehicles and pedestrians are prohibited on motorways.

MoveAway
Diagram
Element Description

Type

Class

Name

MoveAway

IRI

http://ontology.asam.net/ontologies/Domain#MoveAway

Subclass of

ActivityByTrafficParticipantType

Subclass of

ManeuverLevelActivity

Subclass of

MovingActivity

Subclass of

MultiParticipantActivity

Comments

DEF: A MovingActivity with moving traffic participants in which the subject traffic participant moves away from the object traffic participant.

MoveBackward
Diagram
Element Description

Type

Class

Name

MoveBackward

IRI

http://ontology.asam.net/ontologies/Domain#MoveBackward

Subclass of

LongitudinalActivity

Subclass of

PrimitiveLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An Activity with one traffic participant in which the traffic participant moves into the direction that is opposite to the original one without changing its orientation.

MovingActivity
Diagram
Element Description

Type

Class

Name

MovingActivity

IRI

http://ontology.asam.net/ontologies/Domain#MovingActivity

Subclass of

ActivityByStateChange

Comments

DEF: A set of activities which result in a changed location of the subject traffic participant.

MultiParticipantActivity
Diagram
Element Description

Type

Class

Name

MultiParticipantActivity

IRI

http://ontology.asam.net/ontologies/Domain#MultiParticipantActivity

Subclass of

ActivityByNumberOfParticipants

Comments

DEF: A set of activities which involve more than one traffic participant.

NearGale
Diagram
Element Description

Type

Class

Name

NearGale

IRI

http://ontology.asam.net/ontologies/Domain#NearGale

Subclass of

WindCondition

Comments

DEF: NearGale is a WindCondition, is it described by the WindSpeed property using m/s, NearGale is when the WindSpeed is 17.2-20.7 m/s.

NightLightingCondition
Diagram
Element Description

Type

Class

Name

NightLightingCondition

IRI

http://ontology.asam.net/ontologies/Domain#NightLightingCondition

Subclass of

IlluminationCondition

Comments

DEF: An IlluminationCondition where illuminance is below 1 lux.

NonVRU
Diagram
Element Description

Type

Class

Name

NonVRU

IRI

http://ontology.asam.net/ontologies/Domain#NonVRU

Subclass of

TrafficParticipantByVulnerability

Comments

DEF: A set of non-vulnerable road users.

NotMove
Diagram
Element Description

Type

Class

Name

NotMove

IRI

http://ontology.asam.net/ontologies/Domain#NotMove

Subclass of

MovingActivity

Subclass of

PrimitiveLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An Activity during which the traffic participant has a speed of zero.

OfficialVehicle
Diagram
Element Description

Type

Class

Name

OfficialVehicle

IRI

http://ontology.asam.net/ontologies/Domain#OfficialVehicle

Subclass of

Vehicle

Comments

DEF: Official vehicles are vehicles with special access and operational authorities, such as ambulance, police vehicle

Overcast
Diagram
Element Description

Type

Class

Name

Overcast

IRI

http://ontology.asam.net/ontologies/Domain#Overcast

Subclass of

CloudCondition

Comments

DEF: Overcast is a CloudCondition, is it described by the cloudinessLevel property using oktas unit, Overcast is when the cloudinessLevel is 8 oktas.

Overtake
Diagram
Element Description

Type

Class

Name

Overtake

IRI

http://ontology.asam.net/ontologies/Domain#Overtake

Subclass of

DrivingActivity

Subclass of

ManeuverLevelActivity

Subclass of

MultiParticipantActivity

Comments

DEF: An activity in which the subject traffic participant starts behind the object traffic participant and ends up in front of the object traffic participant. The subject changes lanes two time during the activity.

Parking
Diagram
Element Description

Type

Class

Name

Parking

IRI

http://ontology.asam.net/ontologies/Domain#Parking

Subclass of

Road

Comments

DEF: A Road where vehicles are allowed to park.

ParticulatesCondition
Diagram
Element Description

Type

Class

Name

ParticulatesCondition

IRI

http://ontology.asam.net/ontologies/Domain#ParticulatesCondition

Subclass of

PhysicalProperty

Subclass of

EnvironmentalCondition

Comments

DEF: An EnvironmentalCondition where particles in the atmosphere lead to a limited visibility or obscuration of things. Particulates can be of different materials, for example water or sand.

Pass
Diagram
Element Description

Type

Class

Name

Pass

IRI

http://ontology.asam.net/ontologies/Domain#Pass

Subclass of

DrivingActivity

Subclass of

ManeuverLevelActivity

Subclass of

MultiParticipantActivity

Comments

DEF: An activity in which the subject traffic participant is located in a lane adjacent to the lane in which the object traffic participant drives. The subject starts behind the object and is position ahead of the object at the end of the activity. The subject does not change lanes.

PavedShoulder
Diagram
Element Description

Type

Class

Name

PavedShoulder

IRI

http://ontology.asam.net/ontologies/Domain#PavedShoulder

Subclass of

LaneWithConstructionProperties

Comments

DEF: PavedShoulder is a LanesWithConstructionProperties that is an emergency stopping lane by the verge of a road or motorway. Hence, a shoulder, where the surface of a lane is paved is called paved shoulder

Pedestrian
Diagram
Element Description

Type

Class

Name

Pedestrian

IRI

http://ontology.asam.net/ontologies/Domain#Pedestrian

Subclass of

Human

Subclass of

VRU

Comments

DEF: A HumanParticipant who moves in traffic on foot.

PedestrianActivity
Diagram
Element Description

Type

Class

Name

PedestrianActivity

IRI

http://ontology.asam.net/ontologies/Domain#PedestrianActivity

Subclass of

HumanActivity

Subclass of

MovingActivity

Comments

DEF: A set of activities performed by pedestrians.

PedestrianCrossing
Diagram
Element Description

Type

Class

Name

PedestrianCrossing

IRI

http://ontology.asam.net/ontologies/Domain#PedestrianCrossing

Subclass of

SpecialStructure

Comments

DEF: A SpecialStructure that creates a place or area where pedestrians are able to cross a road or lane.

PedestrianZone
Diagram
Element Description

Type

Class

Name

PedestrianZone

IRI

http://ontology.asam.net/ontologies/Domain#PedestrianZone

Subclass of

TrafficZone

Comments

DEF: A Zone where only pedestrians are allowed.

PhysicalDivider
Diagram
Element Description

Type

Class

Name

PhysicalDivider

IRI

http://ontology.asam.net/ontologies/Domain#PhysicalDivider

Subclass of

LaneElement

Comments

DEF: PhysicalDivider is a LaneDivider that is a description of a way which has a physical or legal divider that divides opposing direction lanes and prevents crossing the way in a particular direction. In right side driving countries left turns and u-turns are not allowed, in left side driving countries right turns and u-turns are not allowed.

PositioningCondition
Diagram
Element Description

Type

Class

Name

PositioningCondition

IRI

http://ontology.asam.net/ontologies/Domain#PositioningCondition

Subclass of

ConnectivityCondition

Comments

DEF: A ConnectivityCondition that specifies the system or mechanism used by a vehicle to determine its position. Examples: GPS and GLONASS.

Potholes
Diagram
Element Description

Type

Class

Name

Potholes

IRI

http://ontology.asam.net/ontologies/Domain#Potholes

Subclass of

RoadSurfaceFeature

Comments

DEF:Potholes is a RoadSurfaceFeature that is a depression in a road surface, usually asphalt pavement, where traffic has removed broken pieces of the pavement. It is usually the result of water in the underlying soil structure and traffic passing over the affected area

PrimitiveLevelActivity
Diagram
Element Description

Type

Class

Name

PrimitiveLevelActivity

IRI

http://ontology.asam.net/ontologies/Domain#PrimitiveLevelActivity

Subclass of

ActivityByLevel

Comments

DEF: A set of activities that describe the course of state variables through which a maneuver is to be implemented. While a maneuver is often defined relative to the traffic infrastructure, a motion primitive is defined in the vehicle coordinate system. A motion primitive can be a yaw rate, an acceleration or a deceleration.

PrivateVehicle
Diagram
Element Description

Type

Class

Name

PrivateVehicle

IRI

http://ontology.asam.net/ontologies/Domain#PrivateVehicle

Subclass of

Vehicle

Comments

DEF: Private vehicles are vehicles owned and used by private individuals.

PublicTransportationVehicle
Diagram
Element Description

Type

Class

Name

PublicTransportationVehicle

IRI

http://ontology.asam.net/ontologies/Domain#PublicTransportationVehicle

Subclass of

Vehicle

Comments

DEF: Public transporation vehicles are vehicles operated to transport individuals from the public.

RadialRoad
Diagram
Element Description

Type

Class

Name

RadialRoad

IRI

http://ontology.asam.net/ontologies/Domain#RadialRoad

Subclass of

Road

Comments

DEF: A Road for high-density traffic that connects motorways to distributor roads or city centers.

RailCrossing
Diagram
Element Description

Type

Class

Name

RailCrossing

IRI

http://ontology.asam.net/ontologies/Domain#RailCrossing

Subclass of

SpecialStructure

Comments

DEF: A SpecialStructure that is an intersection between a road and a railway track.

RainfallCondition
Diagram
Element Description

Type

Class

Name

RainfallCondition

IRI

http://ontology.asam.net/ontologies/Domain#RainfallCondition

Subclass of

WeatherCondition

Comments

DEF: A WeatherCondition where it is raining. The intensity of the rainfall may be described using the precipitationIntensity property.

RefuseCollection
Diagram
Element Description

Type

Class

Name

RefuseCollection

IRI

http://ontology.asam.net/ontologies/Domain#RefuseCollection

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that contains rubbish or waste that has not been disposed yet.

RegulatorySign
Diagram
Element Description

Type

Class

Name

RegulatorySign

IRI

http://ontology.asam.net/ontologies/Domain#RegulatorySign

Subclass of

TrafficSignByFunction

Comments

DEF: A traffic sign that indicates rules, restrictions, and prohibitions for all or specific traffic participants.

RestrictedLane
Diagram
Element Description

Type

Class

Name

RestrictedLane

IRI

http://ontology.asam.net/ontologies/Domain#RestrictedLane

Subclass of

LaneWithSpecificRegulations

Comments

DEF: RestrictedLane is a LaneWithSpecificRegulations that can have restrictions towards time, traffic participant type etc. For example, when two lanes split there is an area, where driving is forbidden.

Rider
Diagram
Element Description

Type

Class

Name

Rider

IRI

http://ontology.asam.net/ontologies/Domain#Rider

Subclass of

Human

Subclass of

VRU

Comments

DEF: A type of VRU which consists of a human rider and the transporting vehicle the rider is controlling, examples of such vehicles can be animal, bicycle, motorcycle, etc.

RiderActivity
Diagram
Element Description

Type

Class

Name

RiderActivity

IRI

http://ontology.asam.net/ontologies/Domain#RiderActivity

Subclass of

HumanActivity

Comments

DEF: A BiologicalObjectActivity where the participant is a bicyclist or motorcyclist.

Road
Diagram
Element Description

Type

Class

Name

Road

IRI

http://ontology.asam.net/ontologies/Domain#Road

Subclass of

DrivableAreaElement

Comments

DEF: A DriveableArea that is a long stretch with a smooth or paved surface leading from one place to another. Made to be used by traffic participants.

RoadMarking
Diagram
Element Description

Type

Class

Name

RoadMarking

IRI

http://ontology.asam.net/ontologies/Domain#RoadMarking

Subclass of

DrivableAreaElement

Comments

DEF: A DriveableArea on a road surface that may consist of lines or other symbols and that conveys regulatory information about traffic rules.

RoadSignage
Diagram
Element Description

Type

Class

Name

RoadSignage

IRI

http://ontology.asam.net/ontologies/Domain#RoadSignage

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that are signs or symbols on the road and that provide information about temporary changes to traffic routes, about road closures, construction works, detours, etc.

RoadStructureWithVegetation
Diagram
Element Description

Type

Class

Name

RoadStructureWithVegetation

IRI

http://ontology.asam.net/ontologies/Domain#RoadStructureWithVegetation

Subclass of

FixedRoadStructure

Comments

DEF: A FixedRoadStructure that consist of a several plants and the ground they cover.

RoadSurface
Diagram
Element Description

Type

Class

Name

RoadSurface

IRI

http://ontology.asam.net/ontologies/Domain#RoadSurface

Subclass of

RoadSurfaceElement

Comments

DEF:RoadSurface is a RoadSurfaceElement, which classify the road surface into different types based on characteristics of the surface material, for example segmented, uniform and loose.

RoadSurfaceElement
Diagram
Element Description

Type

Class

Name

RoadSurfaceElement

IRI

http://ontology.asam.net/ontologies/Domain#RoadSurfaceElement

Subclass of

DrivableAreaElement

Comments

DEF: A DrivableArea on a road or sidewalk that is characterized by a specific surface, material, or coating.

RoadSurfaceFeature
Diagram
Element Description

Type

Class

Name

RoadSurfaceFeature

IRI

http://ontology.asam.net/ontologies/Domain#RoadSurfaceFeature

Subclass of

RoadSurfaceElement

Comments

DEF: RoadSurfaceFeature is a RoadSurfaceElements. Drivable area surface features shall include damage caused by traffic and weather. Any road damage (and the resulting different surface features) shall be classified into cracks, potholes, ruts or swells.

RoadTopologyAndTrafficInfrastructure
Diagram
Element Description

Type

Class

Name

RoadTopologyAndTrafficInfrastructure

IRI

http://ontology.asam.net/ontologies/Domain#RoadTopologyAndTrafficInfrastructure

Subclass of

DomainConcepts

Comments

DEF: A set of features for describing the logical road network, traffic infrastructure elements, and related conditions.

RoadWork
Diagram
Element Description

Type

Class

Name

RoadWork

IRI

http://ontology.asam.net/ontologies/Domain#RoadWork

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that is the part of a road under construction. As a result, the road layout may change.

Roadblocks
Diagram
Element Description

Type

Class

Name

Roadblocks

IRI

http://ontology.asam.net/ontologies/Domain#Roadblocks

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that is set up to block or control traffic along a road.

RoadwayEdgeElement
Diagram
Element Description

Type

Class

Name

RoadwayEdgeElement

IRI

http://ontology.asam.net/ontologies/Domain#RoadwayEdgeElement

Subclass of

FixedRoadStructure

Comments

DEF: A FixedRoadStructure that forms the side boundary of a road.

Roundabout
Diagram
Element Description

Type

Class

Name

Roundabout

IRI

http://ontology.asam.net/ontologies/Domain#Roundabout

Subclass of

Junction

Comments

DEF: An Intersection where traffic moves into one direction in a circular shape around a central island to reach one of the roads leading into or out of the traffic circle. Roundabouts may have traffic signals.

Run
Diagram
Element Description

Type

Class

Name

Run

IRI

http://ontology.asam.net/ontologies/Domain#Run

Subclass of

PedestrianActivity

Subclass of

SingleParticipantActivity

Comments

DEF: A PedestrianActivity where the biological object moves in such a way that at a specific point in time no foot touches the ground.

Ruts
Diagram
Element Description

Type

Class

Name

Ruts

IRI

http://ontology.asam.net/ontologies/Domain#Ruts

Subclass of

RoadSurfaceFeature

SandCondition
Diagram
Element Description

Type

Class

Name

SandCondition

IRI

http://ontology.asam.net/ontologies/Domain#SandCondition

Subclass of

ParticulatesCondition

Comments

DEF: A ParticulateCondition where the particles consist of sand or dust.

ScatteredClouds
Diagram
Element Description

Type

Class

Name

ScatteredClouds

IRI

http://ontology.asam.net/ontologies/Domain#ScatteredClouds

Subclass of

CloudCondition

Comments

DEF: ScatteredClouds is a CloudCondition, is it described by the cloudinessLevel property using oktas unit, ScatteredClouds is when the cloudinessLevel is 3-4 oktas.

SchoolZone
Diagram
Element Description

Type

Class

Name

SchoolZone

IRI

http://ontology.asam.net/ontologies/Domain#SchoolZone

Subclass of

TrafficZone

Comments

DEF: A Zone that is a road section near a school or near a crosswalk used by students. It is likely that younger pedestrians are present in this area.

SegmentedSurface
Diagram
Element Description

Type

Class

Name

SegmentedSurface

IRI

http://ontology.asam.net/ontologies/Domain#SegmentedSurface

Subclass of

RoadSurface

Comments

DEF:SegmentedSurface is a RoadSurface that consists of individual segments of certain type of surface material. An example of a segmented road surface could contain segments of concrete panels to form the surface.

ServiceLane
Diagram
Element Description

Type

Class

Name

ServiceLane

IRI

http://ontology.asam.net/ontologies/Domain#ServiceLane

Subclass of

LaneWithSpecificRegulations

Comments

DEF: ServiceLane is a LaneWithSpecificRegulations that which offer enough space for a car to drive and stop in emergency cases - typically on highways. Usually on the right side of drivable lanes, but can also be on the left side.

SharedSpace
Diagram
Element Description

Type

Class

Name

SharedSpace

IRI

http://ontology.asam.net/ontologies/Domain#SharedSpace

Subclass of

Road

Comments

DEF: A Road that may be used equally by vehicles and pedestrians. Shared spaces are designed to minimize the segregation between traffic participants.This is done by reducing traffic management features that tend to encourge users of vehicles to assume priority, such as curbs and lane markings.

Sidewalk
Diagram
Element Description

Type

Class

Name

Sidewalk

IRI

http://ontology.asam.net/ontologies/Domain#Sidewalk

Subclass of

LaneForSpecificParticipants

Comments

DEF: Sidewalk is a LaneForSpecificParticipants that is designated for pedestrians or cyclist. Delimited from the road by some obstacles or poles, but not only by marking. Often elevated compared to the road and often located at the side of a road. Also includes walkable parts of traffic islands, but not pedestrian areas.

SingleParticipantActivity
Diagram
Element Description

Type

Class

Name

SingleParticipantActivity

IRI

http://ontology.asam.net/ontologies/Domain#SingleParticipantActivity

Subclass of

ActivityByNumberOfParticipants

Comments

DEF: A set of activities which involve exactly one traffic participant.

Slide
Diagram
Element Description

Type

Class

Name

Slide

IRI

http://ontology.asam.net/ontologies/Domain#Slide

Subclass of

PedestrianActivity

Subclass of

SingleParticipantActivity

Comments

DEF: A PedestrianActivity where the biological object moves in such a way that the feet always touch the ground.

SmokeAndDustCondition
Diagram
Element Description

Type

Class

Name

SmokeAndDustCondition

IRI

http://ontology.asam.net/ontologies/Domain#SmokeAndDustCondition

Subclass of

ParticulatesCondition

Comments

DEF: A ParticulateCondition where the particles consist of smoke or pollution.

SnowfallCondition
Diagram
Element Description

Type

Class

Name

SnowfallCondition

IRI

http://ontology.asam.net/ontologies/Domain#SnowfallCondition

Subclass of

WeatherCondition

Comments

DEF: A WeatherCondition where it snows. The intensity of the snowfall may be described by the SnowfallIntensity property.

SolidLine
Diagram
Element Description

Type

Class

Name

SolidLine

IRI

http://ontology.asam.net/ontologies/Domain#SolidLine

Subclass of

LaneMarking

Comments

DEF: SolidLine is a LaneMarking that is drawn on a two-way road and it indicates that traffic participants cannot overtake the vehicle ahead, or are not allowed to change the lanes.

SoundBarrier
Diagram
Element Description

Type

Class

Name

SoundBarrier

IRI

http://ontology.asam.net/ontologies/Domain#SoundBarrier

Subclass of

RoadwayEdgeElement

Comments

DEF: A RoadwayEdgeElement that is an built structure designed to protect people in residential areas from noise pollution. Sound barriers are usually high walls next to roads.

SoundSiren
Diagram
Element Description

Type

Class

Name

SoundSiren

IRI

http://ontology.asam.net/ontologies/Domain#SoundSiren

Subclass of

VehicleCommunicationActivity

Comments

DEF: A VehicleCommunicatingActivity of an emergency vehicle that uses its siren to alert other traffic participants.

SpecialStructure
Diagram
Element Description

Type

Class

Name

SpecialStructure

IRI

http://ontology.asam.net/ontologies/Domain#SpecialStructure

Subclass of

WholeLifeFunctionalSystem

Subclass of

WholeLifeFunctionalSystemComponent

Subclass of

WholeLifeSystemComponent

Subclass of

RoadTopologyAndTrafficInfrastructure

Comments

DEF: A set of traffic infrastructure types that are installed on road or junctions and on/through which cars can travel.

StaggeredIntersection
Diagram
Element Description

Type

Class

Name

StaggeredIntersection

IRI

http://ontology.asam.net/ontologies/Domain#StaggeredIntersection

Subclass of

IntersectionAtGrade

Comments

DEF: An Intersection that consists of two T-junctions that directly follow each other. One intersection is vertically rotated by 180° in relation to the other intersection.

Stand
Diagram
Element Description

Type

Class

Name

Stand

IRI

http://ontology.asam.net/ontologies/Domain#Stand

Subclass of

PedestrianActivity

Subclass of

SingleParticipantActivity

Comments

DEF: A PedestrianActivity in which the biological object remains with both legs on the ground without moving in any direction.

Start
Diagram
Element Description

Type

Class

Name

Start

IRI

http://ontology.asam.net/ontologies/Domain#Start

Subclass of

MovingActivity

Subclass of

PrimitiveLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An Activity that starts with a speed of 0 for the subject traffic participant and ends with the traffic participant driving at a non-zero speed.

StaticTrafficSign
Diagram
Element Description

Type

Class

Name

StaticTrafficSign

IRI

http://ontology.asam.net/ontologies/Domain#StaticTrafficSign

Subclass of

TrafficSignByState

Comments

DEF: A traffic sign whose content is static, meaning it does not change over time.

Stop
Diagram
Element Description

Type

Class

Name

Stop

IRI

http://ontology.asam.net/ontologies/Domain#Stop

Subclass of

MovingActivity

Subclass of

PrimitiveLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An Activity that starts with the subject traffic participant driving at a non-zero speed and ends with a speed of 0 for the subject.

StopLane
Diagram
Element Description

Type

Class

Name

StopLane

IRI

http://ontology.asam.net/ontologies/Domain#StopLane

Subclass of

LaneWithSpecificRegulations

Comments

DEF: StopLane is a LaneWithSpecificRegulations that is on the side of a highway (typically paved). This lane is only allowed for emergency stopping.

Storm
Diagram
Element Description

Type

Class

Name

Storm

IRI

http://ontology.asam.net/ontologies/Domain#Storm

Subclass of

WindCondition

Comments

DEF: Storm is a WindCondition, is it described by the WindSpeed property using m/s, Storm is when the WindSpeed is 24.5-28.4 m/s.

StreetFurniture
Diagram
Element Description

Type

Class

Name

StreetFurniture

IRI

http://ontology.asam.net/ontologies/Domain#StreetFurniture

Subclass of

FixedRoadStructure

Comments

DEF: A FixedRoadStructure installed at or along a road. Street furniture may have different purposes, such as providing resting places, creating obstacles for traffic, or decorating.

StreetLight
Diagram
Element Description

Type

Class

Name

StreetLight

IRI

http://ontology.asam.net/ontologies/Domain#StreetLight

Subclass of

FixedRoadStructure

Comments

DEF: A FixedRoadStructure that is a manufactured source of light on the edge of the road.

StreetLighting
Diagram
Element Description

Type

Class

Name

StreetLighting

IRI

http://ontology.asam.net/ontologies/Domain#StreetLighting

Subclass of

ArtificialLightingCondition

Comments

DEF: An ArtificialLightingCondition where the area in question is illuminated by lighting equipment installed along the road, typically mounted on tall posts.

StrongBreeze
Diagram
Element Description

Type

Class

Name

StrongBreeze

IRI

http://ontology.asam.net/ontologies/Domain#StrongBreeze

Subclass of

WindCondition

Comments

DEF: StrongBreeze is a WindCondition, is it described by the WindSpeed property using m/s, StrongBreeze is when the WindSpeed is 10.8-13.8 m/s.

StrongGale
Diagram
Element Description

Type

Class

Name

StrongGale

IRI

http://ontology.asam.net/ontologies/Domain#StrongGale

Subclass of

WindCondition

Comments

DEF: StrongGale is a WindCondition, is it described by the WindSpeed property using m/s, StrongGale is when the WindSpeed is 20.8-24.4 m/s.

Swells
Diagram
Element Description

Type

Class

Name

Swells

IRI

http://ontology.asam.net/ontologies/Domain#Swells

Subclass of

RoadSurfaceFeature

Comments

DEF:Swells is a RoadSurfaceFeature that indicates a raised or elevated surface that was not part of the original road designs and can often be caused by the environmental conditions.

TIntersection
Diagram
Element Description

Type

Class

Name

TIntersection

IRI

http://ontology.asam.net/ontologies/Domain#TIntersection

Subclass of

IntersectionAtGrade

Comments

DEF: An Intersection that consists of three roads. Two of the roads form a straight line, the third road meets the others at 90°. The resulting shape is similar to the capital letter T.

TemporaryRoadStructure
Diagram
Element Description

Type

Class

Name

TemporaryRoadStructure

IRI

http://ontology.asam.net/ontologies/Domain#TemporaryRoadStructure

Subclass of

WholeLifeFunctionalSystem

Subclass of

WholeLifeFunctionalSystemComponent

Subclass of

WholeLifeSystemComponent

Subclass of

RoadTopologyAndTrafficInfrastructure

Comments

DEF: A traffic infrastructure that is located on a road for limited period of time and because of specific situations, such as accidents, traffic guidance, or construction works

TimeCondition
Diagram
Element Description

Type

Class

Name

TimeCondition

IRI

http://ontology.asam.net/ontologies/Domain#TimeCondition

Subclass of

PhysicalProperty

Subclass of

EnvironmentalCondition

Comments

DEF: An EnvironmentalCondition that gives information about the time when a specific traffic situation occurs. Time may be give as time of day, day of week, or date of year.

TollPlaza
Diagram
Element Description

Type

Class

Name

TollPlaza

IRI

http://ontology.asam.net/ontologies/Domain#TollPlaza

Subclass of

SpecialStructure

Comments

DEF: A SpecialStructure that contains toll roads, toll boths, and other structures for toll collection.

TrafficActivity
Diagram
Element Description

Type

Class

Name

TrafficActivity

IRI

http://ontology.asam.net/ontologies/Domain#TrafficActivity

Subclass of

ActivityState

Subclass of

TrafficParticipantAndBehavior

Comments

DEF: An activity implies actions performed by traffic participants during a traffic situation, typically to achieve a specific goal, like changing a lane.

TrafficCone
Diagram
Element Description

Type

Class

Name

TrafficCone

IRI

http://ontology.asam.net/ontologies/Domain#TrafficCone

Subclass of

TemporaryRoadStructure

Comments

DEF: A TemporaryRoadStructure that is a solid or hollow cone-shaped marker that is place on roads or sidewalks to temporarily redirect the traffic.

TrafficIsland
Diagram
Element Description

Type

Class

Name

TrafficIsland

IRI

http://ontology.asam.net/ontologies/Domain#TrafficIsland

Subclass of

FixedRoadStructure

Comments

DEF: A FixedRoadStructure that is located on the surface of a road and that serves to guide the traffic flow or protect pedestrians at crosswalks.

TrafficLane
Diagram
Element Description

Type

Class

Name

TrafficLane

IRI

http://ontology.asam.net/ontologies/Domain#TrafficLane

Subclass of

LaneWithSpecificRegulations

Comments

DEF: TrafficLane is a type of LaneWithSpecificRegulations. It is intended for motorist to use and not suitable for pedestrians, traffic stream is marked off on a road.

TrafficManagementZone
Diagram
Element Description

Type

Class

Name

TrafficManagementZone

IRI

http://ontology.asam.net/ontologies/Domain#TrafficManagementZone

Subclass of

TrafficZone

Comments

DEF: A Zone that features infrastructure elements and measures to avoid peaks in the traffic density and create a smooth traffic flow on busy major traffic routes.

TrafficParticipant
Diagram
Element Description

Type

Class

Name

TrafficParticipant

IRI

http://ontology.asam.net/ontologies/Domain#TrafficParticipant

Subclass of

Participant

Subclass of

WholeLifeSystemComponent

Subclass of

TrafficParticipantAndBehavior

Comments

DEF: Traffic participant is A state of a physical object that is participating actively in some traffic activity

TrafficParticipantAndBehavior
Diagram
Element Description

Type

Class

Name

TrafficParticipantAndBehavior

IRI

http://ontology.asam.net/ontologies/Domain#TrafficParticipantAndBehavior

Subclass of

DomainConcepts

Comments

DEF: A set of activities, physical objects, and functional objects that describe traffic participants and their dynamic behavior.

TrafficParticipantByParticipantType
Diagram
Element Description

Type

Class

Name

TrafficParticipantByParticipantType

IRI

http://ontology.asam.net/ontologies/Domain#TrafficParticipantByParticipantType

Subclass of

TrafficParticipant

Comments

DEF: A set of traffic participants which are categorized by the individuals that participate in road traffic, such as vehicles or pedestrians.

TrafficParticipantByVulnerability
Diagram
Element Description

Type

Class

Name

TrafficParticipantByVulnerability

IRI

http://ontology.asam.net/ontologies/Domain#TrafficParticipantByVulnerability

Subclass of

TrafficParticipant

Comments

DEF: A set of traffic participants categorized by the probability and severity of injuries to people involved in a particular traffic situation.

TrafficSign
Diagram
Element Description

Type

Class

Name

TrafficSign

IRI

http://ontology.asam.net/ontologies/Domain#TrafficSign

Subclass of

WholeLifeSystemComponent

Subclass of

RoadTopologyAndTrafficInfrastructure

Comments

DEF: A traffic infrastructure element that is a sign located at the side or above a road to provide information or instructions to traffic participants.

TrafficSignByFunction
Diagram
Element Description

Type

Class

Name

TrafficSignByFunction

IRI

http://ontology.asam.net/ontologies/Domain#TrafficSignByFunction

Subclass of

TrafficSign

Comments

DEF: A set of traffic signs that groups signs according to type of content that they contain or which purpose they fulfil.

TrafficSignByState
Diagram
Element Description

Type

Class

Name

TrafficSignByState

IRI

http://ontology.asam.net/ontologies/Domain#TrafficSignByState

Subclass of

TrafficSign

Comments

DEF: A set of traffic signs that groups signs depending on whether their content can be changed dynamically or is static.

TrafficZone
Diagram
Element Description

Type

Class

Name

TrafficZone

IRI

http://ontology.asam.net/ontologies/Domain#TrafficZone

Subclass of

SpatialLocation

Subclass of

WholeLifeSystemComponent

Subclass of

RoadTopologyAndTrafficInfrastructure

Comments

DEF: A geographic area with special road configurations, driving regulations, or environmental conditions. The boundaries of a zone may be fixed or dynamic. The conditions that define a zone may be based on complexity, operating procedures, or other factors.

Trailer
Diagram
Element Description

Type

Class

Name

Trailer

IRI

http://ontology.asam.net/ontologies/Domain#Trailer

Subclass of

NonVRU

Subclass of

PrivateVehicle

Comments

DEF: An unpowered Vehicle that is designed for being towed by another Vehicle.

Truck
Diagram
Element Description

Type

Class

Name

Truck

IRI

http://ontology.asam.net/ontologies/Domain#Truck

Subclass of

GoodsVehicle

Subclass of

NonVRU

Comments

DEF: A large and heavy road Vehicle designed and used for carrying goods and materials.

Tunnel
Diagram
Element Description

Type

Class

Name

Tunnel

IRI

http://ontology.asam.net/ontologies/Domain#Tunnel

Subclass of

SpecialStructure

Comments

DEF: A SpecialStructure that is a built underground passage through or below a natural or built structure.

Turn
Diagram
Element Description

Type

Class

Name

Turn

IRI

http://ontology.asam.net/ontologies/Domain#Turn

Subclass of

MovingActivity

Subclass of

PrimitiveLevelActivity

Subclass of

SingleParticipantActivity

Comments

DEF: An Activity during which the subject traffic participant changes its orientation.

UndividedRoad
Diagram
Element Description

Type

Class

Name

UndividedRoad

IRI

http://ontology.asam.net/ontologies/Domain#UndividedRoad

Subclass of

Road

Comments

DEF: A type of road where traffic travels in both directions; the directions are not separated by a central reservation.

UniformSurface
Diagram
Element Description

Type

Class

Name

UniformSurface

IRI

http://ontology.asam.net/ontologies/Domain#UniformSurface

Subclass of

RoadSurface

Comments

DEF:UniformSurface is a RoadSurface where the surface material is distributed evenly.

UseHazardLight
Diagram
Element Description

Type

Class

Name

UseHazardLight

IRI

http://ontology.asam.net/ontologies/Domain#UseHazardLight

Subclass of

VehicleCommunicationActivity

Comments

DEF: A VehicleCommunicatingActivity where a vehicle uses its hazard warning lights to warn other traffic participants of a dangerous situation or malfunction of the vehicle.

UseTurnIndicator
Diagram
Element Description

Type

Class

Name

UseTurnIndicator

IRI

http://ontology.asam.net/ontologies/Domain#UseTurnIndicator

Subclass of

VehicleCommunicationActivity

Comments

DEF: A VehicleCommunicatingActivity in which the subject vehicle uses its direction indicator light to indicate its intention of turning, changing lane, or similar.

V2I
Diagram
Element Description

Type

Class

Name

V2I

IRI

http://ontology.asam.net/ontologies/Domain#V2I

Subclass of

CommunicationCondition

Comments

DEF: A CommunicationCondition that enables communication between a vehicle and the surrounding infrastructure.

V2V
Diagram
Element Description

Type

Class

Name

V2V

IRI

http://ontology.asam.net/ontologies/Domain#V2V

Subclass of

CommunicationCondition

Comments

DEF: A CommunicationCondition that enables communication between a vehicle and other vehicles in a traffic situation.

VRU
Diagram
Element Description

Type

Class

Name

VRU

IRI

http://ontology.asam.net/ontologies/Domain#VRU

Subclass of

TrafficParticipantByVulnerability

Comments

DEF: Set of vulnerable road users (VRU) which are non-motorized traffic participants with reduce mobilities and orientation. A VRU includes both the mobility device (if applicable) and the human that controls it.

Van
Diagram
Element Description

Type

Class

Name

Van

IRI

http://ontology.asam.net/ontologies/Domain#Van

Subclass of

GoodsVehicle

Subclass of

NonVRU

Comments

DEF: A medium sized, motor-powered Vehicle, usually without rear side windows, that is used for transporting goods.

Vehicle
Diagram
Element Description

Type

Class

Name

Vehicle

IRI

http://ontology.asam.net/ontologies/Domain#Vehicle

Subclass of

TrafficParticipantByParticipantType

Comments

DEF: A machine that is a TrafficFunctionalObject which has the intended role of transporting things like goods, humans, or animals. Vehicles are participants in traffic-related activities.

VehicleActivity
Diagram
Element Description

Type

Class

Name

VehicleActivity

IRI

http://ontology.asam.net/ontologies/Domain#VehicleActivity

Subclass of

ActivityByTrafficParticipantType

Comments

DEF: A set of activities performed by vehicles.

VehicleCommunicationActivity
Diagram
Element Description

Type

Class

Name

VehicleCommunicationActivity

IRI

http://ontology.asam.net/ontologies/Domain#VehicleCommunicationActivity

Subclass of

CommunicationActivity

Subclass of

VehicleActivity

Comments

DEF: A CommunicatingActivity where the subject is a vehicle.

VehicleLighting
Diagram
Element Description

Type

Class

Name

VehicleLighting

IRI

http://ontology.asam.net/ontologies/Domain#VehicleLighting

Subclass of

ArtificialLightingCondition

Comments

DEF: An ArtificialLightingCondition where the area in question is illuminated by lighting or signaling equipment installed on vehicles, for example, headlights.

VehicleRestrictionArea
Diagram
Element Description

Type

Class

Name

VehicleRestrictionArea

IRI

http://ontology.asam.net/ontologies/Domain#VehicleRestrictionArea

Subclass of

TrafficZone

Comments

DEF: A Zone where specific types of traffic participants are not allowed to travel.

ViolentRain
Diagram
Element Description

Type

Class

Name

ViolentRain

IRI

http://ontology.asam.net/ontologies/Domain#ViolentRain

Subclass of

RainfallCondition

Comments

DEF: ViolentRain is a RainfallCondition, is it described by the precipitationIntensity property using mm/hr, ViolentRain is when the precipitationIntensity is < 50 -100 mm/hr.

ViolentStorm
Diagram
Element Description

Type

Class

Name

ViolentStorm

IRI

http://ontology.asam.net/ontologies/Domain#ViolentStorm

Subclass of

WindCondition

Comments

DEF: ViolentStorm is a WindCondition, is it described by the WindSpeed property using m/s, ViolentStorm is when the WindSpeed is 28.5-32.6 m/s.

Walk
Diagram
Element Description

Type

Class

Name

Walk

IRI

http://ontology.asam.net/ontologies/Domain#Walk

Subclass of

PedestrianActivity

Subclass of

SingleParticipantActivity

Comments

DEF: A PedestrianActivity where the biological object moves in such a way that at least one foot is always on the ground.

WallOnRoadEdge
Diagram
Element Description

Type

Class

Name

WallOnRoadEdge

IRI

http://ontology.asam.net/ontologies/Domain#WallOnRoadEdge

Subclass of

RoadwayEdgeElement

Comments

DEF: A RoadwayEdgeElement that is a vertical structure built from brick or stone and that separates the road from the surrounding area of land.

WarningSign
Diagram
Element Description

Type

Class

Name

WarningSign

IRI

http://ontology.asam.net/ontologies/Domain#WarningSign

Subclass of

TrafficSignByFunction

Comments

DEF: A traffic sign that warns traffic participants of potential dangers ahead so that these can react accordingly, for example, reduce speed.

Wave
Diagram
Element Description

Type

Class

Name

Wave

IRI

http://ontology.asam.net/ontologies/Domain#Wave

Subclass of

HumanCommunicationActivity

Comments

DEF: An Activity of a human traffic participant which waves a hand to indicate their intention.

WeatherCondition
Diagram
Element Description

Type

Class

Name

WeatherCondition

IRI

http://ontology.asam.net/ontologies/Domain#WeatherCondition

Subclass of

PhysicalProperty

Subclass of

EnvironmentalCondition

Comments

DEF: An EnvironmentalCondition that comprises the characteristics of the atmosphere in terms of wind, rain, fog, snowfall and other natural phenomena.

Wheelchair
Diagram
Element Description

Type

Class

Name

Wheelchair

IRI

http://ontology.asam.net/ontologies/Domain#Wheelchair

Subclass of

PrivateVehicle

Subclass of

VRU

Comments

DEF: A traffic participant which consists of a (handicapped) person sitting in a chair that is equipped with wheels. The person uses the chair as means of transport.

WindCondition
Diagram
Element Description

Type

Class

Name

WindCondition

IRI

http://ontology.asam.net/ontologies/Domain#WindCondition

Subclass of

WeatherCondition

Comments

DEF: A WeatherCondition that defines the wind properties within a traffic situation. Properties can include speed, direction, and other characteristics.

YIntersection
Diagram
Element Description

Type

Class

Name

YIntersection

IRI

http://ontology.asam.net/ontologies/Domain#YIntersection

Subclass of

IntersectionAtGrade

Comments

DEF: An Intersection with three roads that has the shape of the capital letter Y.

arc
Diagram
Element Description

Type

Class

Name

arc

IRI

http://ontology.asam.net/ontologies/Domain#arc

Subclass of

curve

Comments

DEF: A Curve with a constant curvature.

atmosphericPressure
Diagram
Element Description

Type

Class

Name

atmosphericPressure

IRI

http://ontology.asam.net/ontologies/Domain#atmosphericPressure

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty that specifies the force per given area unit exerted by the atmosphere. Pascal is used as unit of measurement; values may range from 0 to infinity.

cloudinessLevel
Diagram
Element Description

Type

Class

Name

cloudinessLevel

IRI

http://ontology.asam.net/ontologies/Domain#cloudinessLevel

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty that determines the amount of sky covered in clouds. Okta is used as unit of measurement.

contaminatingRoadCondition
Diagram
Element Description

Type

Class

Name

contaminatingRoadCondition

IRI

http://ontology.asam.net/ontologies/Domain#contaminatingRoadCondition

Subclass of

inducedRoadSurfaceCondition

Comments

DEF: An InducedRoadSurfaceCondition where the road surface is covered with substances or a mix of substances and other materials.

curve
Diagram
Element Description

Type

Class

Name

curve

IRI

http://ontology.asam.net/ontologies/Domain#curve

Subclass of

horizontalGeometry

Comments

DEF: A HorizontalGeometry that is not straight.

downSlope
Diagram
Element Description

Type

Class

Name

downSlope

IRI

http://ontology.asam.net/ontologies/Domain#downSlope

Subclass of

verticalGeometry

Comments

DEF: A VerticalGeometry that is a plane with negative gradient. It represents a descending elevation of the road in driving direction.

drivableAreaGeometry
Diagram
Element Description

Type

Class

Name

drivableAreaGeometry

IRI

http://ontology.asam.net/ontologies/Domain#drivableAreaGeometry

Subclass of

roadTopologyAndTrafficInfrastructureProperty

Comments

DEF: Shape of a drivable area described as geometry.

drivingDirection
Diagram
Element Description

Type

Class

Name

drivingDirection

IRI

http://ontology.asam.net/ontologies/Domain#drivingDirection

Subclass of

roadTopologyAndTrafficInfrastructureProperty

Comments

DEF: A traffic infrastructure property that indicates whether traffic participants keep on the left or right side of the road in birectional travel.

environmentalConditionProperty
Diagram
Element Description

Type

Class

Name

environmentalConditionProperty

IRI

http://ontology.asam.net/ontologies/Domain#environmentalConditionProperty

Subclass of

PhysicalProperty

Subclass of

EnvironmentalCondition

floodedRoadCondition
Diagram
Element Description

Type

Class

Name

floodedRoadCondition

IRI

http://ontology.asam.net/ontologies/Domain#floodedRoadCondition

Subclass of

inducedRoadSurfaceCondition

Comments

DEF: An InducedRoadSurfaceCondition where the road is covered with flowing water, especially from rain.

horizontalGeometry
Diagram
Element Description

Type

Class

Name

horizontalGeometry

IRI

http://ontology.asam.net/ontologies/Domain#horizontalGeometry

Subclass of

drivableAreaGeometry

Comments

DEF: A DrivableAreaGeometry in the horizontal plane

icyRoadCondition
Diagram
Element Description

Type

Class

Name

icyRoadCondition

IRI

http://ontology.asam.net/ontologies/Domain#icyRoadCondition

Subclass of

inducedRoadSurfaceCondition

Comments

DEF: An InducedRoadSurfaceCondition where the road is completely or partially covered with ice.

inducedRoadSurfaceCondition
Diagram
Element Description

Type

Class

Name

inducedRoadSurfaceCondition

IRI

http://ontology.asam.net/ontologies/Domain#inducedRoadSurfaceCondition

Subclass of

roadTopologyAndTrafficInfrastructureProperty

Comments

DEF: A traffic infrastructure property that describes the conditions on the road surface caused by environmental influences, such as rain or snow.

laneDimension
Diagram
Element Description

Type

Class

Name

laneDimension

IRI

http://ontology.asam.net/ontologies/Domain#laneDimension

Subclass of

laneProperty

Comments

DEF: A LaneProperty that is the width of the lane.

laneMarkingColor
Diagram
Element Description

Type

Class

Name

laneMarkingColor

IRI

http://ontology.asam.net/ontologies/Domain#laneMarkingColor

Subclass of

laneProperty

Comments

DEF: A LaneProperty that is the colour of the lane marking.

laneMarkingWidth
Diagram
Element Description

Type

Class

Name

laneMarkingWidth

IRI

http://ontology.asam.net/ontologies/Domain#laneMarkingWidth

Subclass of

laneProperty

Comments

DEF: A LaneProperty that is the width of the lane marking.

laneProperty
Diagram
Element Description

Type

Class

Name

laneProperty

IRI

http://ontology.asam.net/ontologies/Domain#laneProperty

Subclass of

roadTopologyAndTrafficInfrastructureProperty

Comments

DEF: A traffic infrastructure property that describes the characteristics of a lane.

lateralProfile
Diagram
Element Description

Type

Class

Name

lateralProfile

IRI

http://ontology.asam.net/ontologies/Domain#lateralProfile

Subclass of

transverseGeometry

Comments

DEF: A TransverseGeometry that specifies the elevation of a road orthogonally to a reference line.

levelPlane
Diagram
Element Description

Type

Class

Name

levelPlane

IRI

http://ontology.asam.net/ontologies/Domain#levelPlane

Subclass of

verticalGeometry

Comments

DEF: A VerticalGeometry that is a plane with a gradient of 0. All points of the plane are on the same vertical level.

lightingIntensity
Diagram
Element Description

Type

Class

Name

lightingIntensity

IRI

http://ontology.asam.net/ontologies/Domain#lightingIntensity

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty that describes the intensity of illumination by a lighting source. Lux is used as unit of measurement.

mirageRoadCondition
Diagram
Element Description

Type

Class

Name

mirageRoadCondition

IRI

http://ontology.asam.net/ontologies/Domain#mirageRoadCondition

Subclass of

inducedRoadSurfaceCondition

Comments

DEF: An InducedRoadSurfaceCondition where displaced images of distant objects or the sky appear. A mirage is a natural optical phenomenon caused by the bending of light rays via refraction.

numberOfLanes
Diagram
Element Description

Type

Class

Name

numberOfLanes

IRI

http://ontology.asam.net/ontologies/Domain#numberOfLanes

Subclass of

roadTopologyAndTrafficInfrastructureProperty

Comments

DEF: A traffic infrastructure property that indicates how many lanes a road has.

precipitationIntensity
Diagram
Element Description

Type

Class

Name

precipitationIntensity

IRI

http://ontology.asam.net/ontologies/Domain#precipitationIntensity

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientProperty that measures the level of rainfall. mm/hr is used as unit of measurement. It gives the amount or volume of water per fixed amount of time (hour).

roadFrictionScaleFactor
Diagram
Element Description

Type

Class

Name

roadFrictionScaleFactor

IRI

http://ontology.asam.net/ontologies/Domain#roadFrictionScaleFactor

Subclass of

roadTopologyAndTrafficInfrastructureProperty

Comments

DEF: RoadFrictionScaleFactor is a RoadTopologyAndTrafficInfrastructureProperty that describes the Friction scale factor

roadTopologyAndTrafficInfrastructureProperty
Diagram
Element Description

Type

Class

Name

roadTopologyAndTrafficInfrastructureProperty

IRI

http://ontology.asam.net/ontologies/Domain#roadTopologyAndTrafficInfrastructureProperty

Subclass of

PhysicalProperty

Subclass of

RoadTopologyAndTrafficInfrastructure

snowfallIntensity
Diagram
Element Description

Type

Class

Name

snowfallIntensity

IRI

http://ontology.asam.net/ontologies/Domain#snowfallIntensity

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientProperty that quantifies the amount of snow that falls within an area. mm/hr is used as unit of measurement. It gives the amount or volume of water per fixed amount of time (hour).

snowyRoadCondition
Diagram
Element Description

Type

Class

Name

snowyRoadCondition

IRI

http://ontology.asam.net/ontologies/Domain#snowyRoadCondition

Subclass of

inducedRoadSurfaceCondition

Comments

DEF: An InducedRoadSurfaceCondition where snow covers the surface of the road. Snow on the surface lowers the friction coefficent and can obscure lane markings.

speedLimitForLane
Diagram
Element Description

Type

Class

Name

speedLimitForLane

IRI

http://ontology.asam.net/ontologies/Domain#speedLimitForLane

Subclass of

roadTopologyAndTrafficInfrastructureProperty

spiral
Diagram
Element Description

Type

Class

Name

spiral

IRI

http://ontology.asam.net/ontologies/Domain#spiral

Subclass of

curve

Comments

DEF: A Curve with a changing curvature that is described as a clothoid. Spirals may be used to describe the transitions between geometric shapes and help avoiding leaps and gaps in the curvature.

standingWaterCondition
Diagram
Element Description

Type

Class

Name

standingWaterCondition

IRI

http://ontology.asam.net/ontologies/Domain#standingWaterCondition

Subclass of

inducedRoadSurfaceCondition

Comments

DEF: An InducedRoadSurfaceCondition where the road is covered with non-flowing (standing) water. Standing water often occurs in road sinks.

straightLine
Diagram
Element Description

Type

Class

Name

straightLine

IRI

http://ontology.asam.net/ontologies/Domain#straightLine

Subclass of

horizontalGeometry

Comments

DEF: A HorizontalGeometry that runs as a straight line in the associated coordinate system.

sunAzimuth
Diagram
Element Description

Type

Class

Name

sunAzimuth

IRI

http://ontology.asam.net/ontologies/Domain#sunAzimuth

Subclass of

sunProperty

Comments

DEF: A sunProperty that is the azimuth angle of the sun’s position. It is defined as the angle between a line due south and the shadow cast by a vertical rod on Earth.

sunElevation
Diagram
Element Description

Type

Class

Name

sunElevation

IRI

http://ontology.asam.net/ontologies/Domain#sunElevation

Subclass of

sunProperty

Comments

DEF: A sunProperty that is the solar zenith angle, which is defined as the angle between the sun’s rays and the vertical direction. It is complementary to the solar altitude angle, which is the angle between the sun’s rays and a horizontal plane.

sunProperty
Diagram
Element Description

Type

Class

Name

sunProperty

IRI

http://ontology.asam.net/ontologies/Domain#sunProperty

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty that defines characteristics of the sun, for example, azimuth and elevation.

superElevation
Diagram
Element Description

Type

Class

Name

superElevation

IRI

http://ontology.asam.net/ontologies/Domain#superElevation

Subclass of

transverseGeometry

Comments

DEF: A TransverseGeometry the specifies the cross slope of a road, meaning the roll angle of the road cross section around a reference line.

temperature
Diagram
Element Description

Type

Class

Name

temperature

IRI

http://ontology.asam.net/ontologies/Domain#temperature

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty that describes how warm or cold it is. Temperature is given in one of the following units: Kelvin [K], Celsius[℃] or Fahrenheit [℉].

trafficParticipantsAndBehavioursProperty
Diagram
Element Description

Type

Class

Name

trafficParticipantsAndBehavioursProperty

IRI

http://ontology.asam.net/ontologies/Domain#trafficParticipantsAndBehavioursProperty

Subclass of

PhysicalProperty

Subclass of

TrafficParticipantAndBehavior

transverseGeometry
Diagram
Element Description

Type

Class

Name

transverseGeometry

IRI

http://ontology.asam.net/ontologies/Domain#transverseGeometry

Subclass of

drivableAreaGeometry

Comments

DEF: A DrivableAreaGeometry in the cross-section plane; the transverse profile

upSlope
Diagram
Element Description

Type

Class

Name

upSlope

IRI

http://ontology.asam.net/ontologies/Domain#upSlope

Subclass of

verticalGeometry

Comments

DEF: A VerticalGeometry that is a plane with positive gradient. It represents an ascending elevation of the road in driving direction.

verticalGeometry
Diagram
Element Description

Type

Class

Name

verticalGeometry

IRI

http://ontology.asam.net/ontologies/Domain#verticalGeometry

Subclass of

drivableAreaGeometry

Comments

DEF: A DrivableAreaGeometry in the vertical (longitudinal) plane

visibility
Diagram
Element Description

Type

Class

Name

visibility

IRI

http://ontology.asam.net/ontologies/Domain#visibility

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty type that specifies the distance at which a thing can be clearly discerned. The distance may be specified in meters, kilometers, or miles.

wetRoadCondition
Diagram
Element Description

Type

Class

Name

wetRoadCondition

IRI

http://ontology.asam.net/ontologies/Domain#wetRoadCondition

Subclass of

inducedRoadSurfaceCondition

Comments

DEF: An InducedRoadSurfaceCondition where the road is covered with a thin layer of water. This can lower the friction coefficent.

windDirection
Diagram
Element Description

Type

Class

Name

windDirection

IRI

http://ontology.asam.net/ontologies/Domain#windDirection

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty that characterizes the direction from which the wind is coming. The direction may be specified as cardinal direction or in degrees. Example: Wind coming from the North is defined as a wind direction of 0° or 360°.

windSpeed
Diagram
Element Description

Type

Class

Name

windSpeed

IRI

http://ontology.asam.net/ontologies/Domain#windSpeed

Subclass of

environmentalConditionProperty

Comments

DEF: An ambientConditionProperty that defines how strong the wind is blowing. Wind speed is given in m/s.

A.2.2. Properties

Appendix B: Evaluation of ontology languages and rule languages for ASAM OpenXOntology

Different modeling and rule languages are available for ontologies. This topic gives a short summary of the considerations behind the decisions for OWL and SWRL that ASAM OpenXOntology uses.

B.1. Requirements of ASAM OpenXOntology

ASAM OpenXOntology has the goal to ensure semantic interoperability between OpenX standards. This interoperability must address the various differences in data models, information sources, and world views present within the OpenX standards. Also, the modeling principles must match the underlying nature of the things involved, for example, in the road traffic domain.

In order to realize such an ontology, the ontology modeling language must be capable of:

  • Forming a conceptual representation of the knowledge domain, in this case the traffic domain.

  • Formalizing the knowledge domain by means of logic.

  • Generating structured data that is machine-interpretable.

  • Representing both qualitative and quantitative data.

  • Representing hierarchies of classes.

B.2. Evaluation of ontology languages

There are several ontology languages that are in wide use within the context of the Semantic Web and Linked Open Data.

Ontology languages can be classified in two ways:

  • By structure

  • By syntax

Structure

The structure of ontology languages can be categorized as follows:

Table 7. Overview of ontology-based languages
Frame-based structure Based on description logic Based on first-order logic

F-Logic (Frame Logic)

Web Ontology Language (OWL)

Common Logic (CL)

KM programming language

RDF Schema (RDFS)

CycL

Simple Knowledge Organization System (SKOS)

OntoUML and UFO

Knowledge Interchange Format (KIF)

Syntax

In terms of syntax, ontology languages can be divided into languages having some form of specialized syntax, usually predating the widespread use of XML and other markup languages, and languages expressed as markup languages, usually XML or UML.

Table 8. Overview of the syntax of ontology languages
Traditional syntax ontology languages Markup ontology languages

Common Logic (CL)

Web Ontology Language (OWL)

CycL

Resource Description Framework (RDF)

F-Logic (Frame Logic)

RDF Schema (RDFS)

Knowledge Interchange Format (KIF)

Simple Knowledge Organization System (SKOS)

KM programming language

OntoUML and UFO

Regarding ASAM OpenXOntology, a markup ontology language is a good choice for knowledge representation because it provides:

  • Both human-readable and machine-readable annotations of the relationships, classes, and individuals.

  • A clear representation of the data models and data structures.

  • A clear ordering method for the syntax.

  • A possibility to easily check the validity of the model by means of rules and reasoning.

  • A selection from many existing standards and schemas to facilitate the structure.

The following ontology languages have been compared:

  • Resource Description Framework (RDF) [25]

  • RDF Schema (RDFS) [26]

  • Web Ontology Language (OWL) [19]

  • Simple Knowledge Organization System (SKOS) [27]

  • OntoUML [28] and UFO [29]

Resource Description Framework (RDF)

The W3C Recommendation RDF is a standard model for data interchange on the Web. RDF makes statements with the help of triples, that is, in the form subject–predicate–object. RDF triples state that a relationship, indicated by the predicate, holds between the things denoted by subject and object of the triple. When talking about RDF concepts, the term property is used synonymous to the term predicate.

For the expression of RDF, different serialization formats may be used. The most common are RDF/XML and Turtle.

RDF Schema (RDFS)

The W3C Recommendation RDFS is a semantic extension of the basic RDF vocabulary. RDFS enables the assignment of resources to classes. Classes can have subclasses, so that the things described can be organized hierarchically. A relationship can then be drawn between classes of things or individuals. RDFS also provides a mechanism for limiting the scope of a relationship. RDFS thus enables simple deduction and reasoning mechanisms.

Simple Knowledge Organization System (SKOS)

SKOS is another W3C Recommendation and ontology language based on RDF and RDFS. It provides a standard way to represent knowledge organization systems using RDF.

SKOS is intended to create a simple ontology language, which can fulfill simple semantic queries. This is suitable for simple classifications, but it cannot handle the complex logical relationships required in OpenXOntology.

Web Ontology Language (OWL)

OWL is a semantic markup language for publishing and sharing ontologies on the Web. OWL builds on RDF and RDFS and is part of the W3C recommendations related to the Semantic Web.

OWL goes beyond the basic semantics that can be expressed with RDF Schema. The data described by an ontology in the OWL family is interpreted as a set of individuals and a set of property assertions that relate these individuals to each other. An ontology consists of a set of axioms which place constraints on sets of individuals, meaning classes, and the types of relationships permitted between them. These axioms provide semantics by allowing computers to infer additional information based on the data explicitly provided.

OntoUML and Unified Foundational Ontology (UFO)

OntoUML and UFO were created independent of all the other languages described here as language for ontology-driven conceptual modeling. OntoUML is built as an UML extension and is based on UFO. Because UML is applied in many industries, OntoUML is popular in industrial usage.

B.3. Decision to use OWL for OpenXOntology

In ASAM OpenXOntology, knowledge expressions, such as descriptions of traffic scenarios, involve complex temporal dynamics that benefit from a basis in formalized logic. Some of the languages that were reviewed support some form of formalized logic. OWL is the most widely used language of those, in addition to being well-developed and well-documented. OWL is supported by a variety of tools.

ASAM OpenXOntology contains an interoperable domain ontology, which needs to be built on an interoperable, industry-accepted format. This is enabled by OWL, which also allows for easy conversion to other ontological formats.

B.4. Evaluation of rule languages

In OpenXOntology, many important logical assertions, for example, regarding concept definition and inference of the consequences of antecedent conditions, cannot be easily expressed solely with logic. In many of these cases, a rule language can provide the expressiveness required to make these assertions.

The following rule languages have been evaluated:

  • RIF [30]

  • RuleML [31]

  • R2ML [32]

  • SWRL [20]

Rule interchange format (RIF)

RIF is part of the Semantic Web stack, along with, for example, SPARQL, RDF, and OWL. RIF facilitates the exchange and sharing of rules. RIF has three dialects: the Core dialect, the Basic Logic Dialect that is equivalent to a Horn rule language, and a Product Rule Dialect (PRD).

Rule markup language (RuleML)

RuleML is a markup language for forward and backward rules for deduction, rewriting, and further inferential-transformational tasks. RuleML is defined by the Rule Markup Initiative that has the goal to develop a canonical web language for rules in XML markup and transformations to and from other rule standards. RIF and SWRL belong to the standards related to RuleML.

REWERSE rule markup language (R2ML)

The XML-based rule language R2ML is developed by the REWERSE working group and facilitates rule interchange between systems and tools.

R2ML bases on concepts from RuleML and SWRL. It is modeled using model-driven architecture (MDA). Rule concepts are defined using the Meta-Object Facility (MOF) standard and UML.

R2ML integrates functional languages, such as OCL, with datalog languages, such as SWRL.

Semantic web rule language (SWRL)

SWRL combines OWL with a subset of the Rule Markup Language (RuleML). It is a proposed rule language for the Semantic Web. SWRL adds rules at the cost of undecidability and lack of complete implementation. A SWRL rule consists of an antecedent (body) and a consequent (head).

B.4.1. Decision to use SWRL as rule language

The OpenXOntology project decided to use SWRL as rule language, because SWRL meets the basic requirements and is compatible with OWL.

Appendix C: List of figures

Name Description

Figure 1

OpenXOntology and its relation to other ASAM standards

Figure 2

A directed relationship from subject to object

Figure 3

TBox and a possible ABox

Figure 4

Example visualization of core, domain, and application ontologies

Figure 5

View of the core ontology

Figure 6

Sample sets for cars

Figure 7

Sample scenario

Figure 8

Example of traffic light as functional system component

Figure 9

Incorporate a new concept into OpenXOntology

Figure 10

Phases of the data journey in the OpenX standard framework

Figure 11

Data journey through the OpenX standards

Figure 12

TBox for the data journey

Figure 13

Start scene of the traffic situation

Figure 14

Traffic situation during the passing event

Figure 15

End scene of the traffic situation

Figure 16

Interactions of scenario components

Figure 17

Example of information provided by a logical reasoner about a semantic conflict

Figure 18

Overview of phase 3 and how it relates to phases 1 and 2

Figure 19

Animated traffic simulator results

Figure 20

Overview of phase 5

Appendix D: List of tables

Name Description

Table 1

Units

Table 2

Rules for using modal verbs

Table 3

Typographical conventions

Table 7

Overview of ontology-based languages

Table 8

Overview of the syntax of ontology languages

Table 4

Valid conditions and descriptions

Table 5

SWRL rules in ASAM OpenXOntology

Table 6

Alignment with other standards