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.
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:
Provision | Verbal form |
---|---|
Requirements |
shall |
Recommendations |
should |
Permissions |
may |
Possibilities and capabilities |
can |
Obligations and necessities |
must |
2.3.3. Typographic conventions
This documentation uses the following typographical conventions:
Mark-up | Definition |
---|---|
|
This format is used for code elements, such as technical names of classes. |
|
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 TC22 SC32 WG8 [16]
5. Relation to ASAM OpenX
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.
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 classRoadVehicles
(subject) to a member of the classWheels
(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.
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 thatElectricVehicles
must have at least one value fromElectricEngines
for thehasPart
relationship. -
The logical construct
cardinality = 2
may be used to define thatBicycles
must have exactly two values fromWheels
for thehasPart
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)
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.
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:
-
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.
-
An OR relation between two conditions shall be expressed with two separate rules.
Example 1. OR relationshipA 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].
-
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.
-
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
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:
-
The datatype property
hasValue
assigns a float value to aPhysicalQuantity
. -
Each subclass of
Quantity
is defined to have a particular unit, usually the corresponding SI unit. For example,LengthQuantity
is a subclass ofPhysicalQuantity
that represent lengths in the unit meters.
Example:
A particular road (roadA
) is meant to have a width of 3 meters.
-
A
LengthQuantity
,widthOfRoadA
, is declared to be the width of roadA. roadA is a member of the classRoad
. -
A
hasValue
datatype property is declared to assign a float value of 3.0 towidthOfRoadA
.
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:
-
Define a quantity (for example,
LengthQuantity
,WidthQuantity
) as subclass ofPhysicalQuantity
, if there is no existing one. -
Define a unit, for example, meter, as subclass of
Unit
, if there is no existing one. -
Optional: Define an object property, for example,
hasLength
orhasWidth
, as subproperty ofhasProperty
. -
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.
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:
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:
Element | Description |
---|---|
Type |
Class |
Name |
Event |
IRI |
|
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.
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.
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 ofV1
from its beginning tot1
. 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 ofV1
fromt1
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:
Element | Description |
---|---|
Type |
Class |
Name |
State |
IRI |
|
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 toPointInTime
inEvent
,PeriodOfTime
is a subclass ofState
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 classPeriodOfTime
.-
PossibleWorld
: APeriodOfTime
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. ASpatialLocation
describes a position, an area, or a space that is important in a defined context. ASpatialLocation
can be described in various ways, such as by topology, topography, or coordinates. Examples ofSpatialLocation
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 someEvent
. Participants are individuals ofPhysicalObjectState
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 ofIntentionallyConstructedObjectState
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 anIntentionallyConstructedObjectState
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 aSociallyConstructedObjectState
. 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:
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
.
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.
|
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
.
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 partmotorcycleQ0_0
ofmotorcycleQ
passes the temporal partcarL1_0
ofcarL
.Event
pass1to0
is the end event of the activity. -
In the activity
laneChange0_1
, the temporal partmotorcycleQ0_1
ofmotorcycleQ
changes the lane.Event
pass2to0
is the end event of the activity. -
In the activity
drivingStraight0_2
, the temporal partmotorcycleQ0_2
ofmotorcycleQ
drives in front ofcarL
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:
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 anOrdinaryBiologicalObjectState
orOrdinaryFunctionalObjectState
. -
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 theintendedRole
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 notFunctionalObjectState
or aBiologicalObjectState
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 notOrdinaryPhysicalObjectState
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
: AOrdinaryPhysicalObjectState
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 aSystemState
that is not aFunctionalSystemState
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
: AOrdinaryFunctionalObjectState
that is also aSystemState
.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
orOrdinaryFunctionalObjectState
. -
WholeLifeSystem
: ASystemState
that is also aWholeLifeOrdinaryPhysicalObject
.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 aWholeLifeFunctionalSystem
is the entire life of a hurricane from when it is formed to when it ceases to exist. -
WholeLifeFunctionalSystem
: AFunctionalSystemState
that is also aWholeLifeSystem
.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
: APhysicalObjectState
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. ASystemComponentState
may be completely replaced without losing its identity, so it is not anOrdinaryPhysicalObjectState
.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
: AFunctionalObjectState
that is also aSystemComponentState
. Represents a replaceable component of aFunctionalSystem
.The object property
componentOf
is used to relate the object to theFunctionalSystem
.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
: ASystemComponentState
that is also aWholeLifePhysicalObject
. 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 aWholeLifeFunctionalSystemComponent
is the eye of a hurricane. -
WholeLifeFunctionalSystemComponent
: AFunctionalSystemComponentState
that is also aWholeLifeSystemComponent
. 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 intoFunctionalSystemComponentStates
for each of theInstalledObjects
that acted as the component over the lifetime of the functional system. -
InstalledObject
: AnOrdinaryPhysicalObjectState
that is installed in a system, meaning that is also aSystemComponentState
.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 ofInstalledObject
, 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
: AFunctionalSystemComponentState
that is also aInstalledObject
. 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.
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:
-
As a component of the traffic infrastructure, meaning it is a functional system component (member of
FunctionalSystemComponentState
). -
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.
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:
Element | Description |
---|---|
Type |
Class |
Name |
AbstractObject |
IRI |
|
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:
Element | Description |
---|---|
Type |
Class |
Name |
Set |
IRI |
|
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 aSetOfParticipants
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 aSetOfStates
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 aSet
that groups states by a specific characteristic, butPhysicalProperty
is understood to be the specific characteristic shared by its members. That means, a member ofPhysicalProperty
is just a characteristic of all states that are members of thePhysicalProperty
as aSetOfStates
.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 aPhysicalProperty
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 aPhysicalProperty
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 asDirectionQuantity
,LengthQuantity
,SpeedQuantity
, andAngleQuantity
.
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:
Element | Description |
---|---|
Type |
Class |
Name |
Relationship |
IRI |
|
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
: ARelationship
where the whole is at least the sum of the parts. Basis for object propertyaggregatedInto
.-
Composition
: AnAggregation
where the whole is an arrangement of the parts that results in emergent properties. Basis for object propertiespartOf
andhasPart
. -
TemporalComposition
: AComposition
where the part is the entire whole spatially, but part of the whole temporally. Basis for object propertiestemporalPartOf
andhasTemporalPart
.
-
-
Classification
: ARelationship
where a thing is a member of a class. Basis for object propertiesmemberOf
andhasMember
. -
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
: ADefinedRelationship
that describes a temporal relationship between two things, usually between events. Basis for the object propertiesoccursBefore
,occursAfter
, and similar. -
ConnectionRelation
: ADefinedRelationship
for relations between things that are connected in any way, physically or otherwise. Basis for the object propertyconnectedTo
. 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
: ADefinedRelationship
between two physical objects that describes their directional relationship, not the distance. Basis for object properties such asrightOf
,leftOf
,inFrontOf
,behind
, and more. ASpatialRelation
must have a direction that is aDirectionQuantity
, a spatial object that is aPhysicalObjectState
, and a spatial subject that is aPhysicalObjectState
. ASpatialRelation
is not aTemporalRelation
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 aSpatialRelation
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. |
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.
-
Assume that if a concept appears in more than one application standard, it must be considered until other methods exclude it.
-
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.
-
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:
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:
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:
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).
Figure 9 shows the workflow proposed by ASAM OpenXOntology to incorporate a new concept.
Proceed as follows to integrate a concept into ASAM OpenXOntology:
-
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.
-
If the answer is YES, you shall use the existing domain concept directly.
-
If the answer is NO, proceed with step 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 classTrafficParticipant
.-
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.
-
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).
-
-
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.
-
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.
-
If the answer is YES, proceed with step 4.
-
-
Research whether your concept and the related application concepts that you identified in the previous step are fully equivalent.
-
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.
-
If the answer is NO, proceed with step 5.
-
-
Decide whether your concept can be used as parent class for the identified application-level concept(s).
-
If the answer is YES, your concept needs to be at domain level. Submit a corresponding change request to the ASAM OpenXOntology group.
-
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:
-
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:
-
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.
-
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.
-
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.
-
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.
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:
-
Label sensor data with OpenLABEL annotations, see phase 1 of the data journey: Label sensor data.
-
Check the data with a semantic application and infer knowledge, see phase 2 of the data journey: Check data and infer knowledge.
-
Generate scenario details and export OpenSCENARIO 1.1.1 and OpenDRIVE files, see phase 3 of the data journey: Detail the scenario.
-
Simulate the scenario, see phase 4 of the data journey: Simulate the scenario.
-
Check the OSI stream against an ODD, see phase 5 of the data journey: Check against ODD.
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.
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.
Steps in phase 1
-
A label annotation software processes the sensor data and identifies the traffic participants, the involved road infrastructure, and the environmental conditions.
-
The label annotation software creates object labels using OpenLABEL syntax. OpenXOntology provides descriptions for the terms in the OpenLABEL syntax.
-
The label annotation software stores the labels in JSON files.
-
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 asVehicle
that change their states over the time duration of interest, temporal parts of thoseWholeLifeFunctionalSystem
shall be created as members of the classFunctionalSystemState
. For example,egoCar0
begins in one lane and later moves to the other lane. To represent this, the annotator creates threeFunctionalSystemState
:-
egoCar0_0
is the temporal part of theegoCar0
that is inlane1
-
egoCar0_1
is the temporal part of theegoCar0
that is changing lanes -
egoCar0_0
is the temporal part of theegoCar0
that is inlane2
.The annotator specifies the beginning and ending for each of the
FunctionalSystemState
as one of theEvent
marking important points of time, such as the start or end of one of theActivityState
.Figure 16. Interactions of scenario componentsFigure 16 shows the interactions of the
Event
,ActivityState
, andFunctionalSystemState
.
-
-
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
"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"
}
]
}
}
<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>
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
-
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.
-
-
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
passesegoCar0_2
, which is in conflict with the assertion thategoCar0_2
is behindvehicle2_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.
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
andhasSubject
individuals or removing the assertion about the passing event completely.
-
-
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.
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.
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
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
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 onPrecipitation
andTemperature
. 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
isIcyRoadCondition
. ThisIcyRoadCondition
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.
[9] PAS 1883:2020 Operational design domain (ODD) taxonomy for an automated driving system (ADS). Specification. The British Standards Institution, 2020.
[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.
[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.
[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
Element | Description |
---|---|
Type |
Class |
Name |
AbstractObject |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ActivityState |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Aggregation |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
AngleQuantity |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Classification |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Composition |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ConnectionRelation |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
CoreConcepts |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
DirectionQuantity |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Event |
IRI |
|
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
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Geometry |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
InstalledObject |
IRI |
|
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
LengthQuantity |
IRI |
|
Subclass of |
PhysicalQuantity |
Comments |
DEF: A PhysicalQuantity that is a length value in meters. |
EXAMPLES: |
USAGE: |
OrdinaryBiologicalObjectState
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Participant |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
PeriodOfTime |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
PhysicalProperty |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
PhysicalQuantity |
IRI |
|
Subclass of |
PhysicalProperty |
Comments |
DEF: A PhysicalProperty that represents a measurable quantity of a characteristic. |
EXAMPLES: length, speed, and angle. |
USAGE: |
PointInTime
Element | Description |
---|---|
Type |
Class |
Name |
PointInTime |
IRI |
|
Subclass of |
Event |
Comments |
DEF: An Event that is the whole of space at an instant from some viewpoint. |
EXAMPLES: |
USAGE: |
PossibleWorld
Element | Description |
---|---|
Type |
Class |
Name |
PossibleWorld |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Relationship |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
RelativeLocation |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Role |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SeparationDistance |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Set |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
SetOfEvents |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SetOfParticipants |
IRI |
|
Subclass of |
SetOfPhysicalObjectStates |
Comments |
DEF: A SetOfPhysicalObjectStates that groups participants of activities. |
EXAMPLES: |
USAGE: Generally use Role rather than this class. |
SetOfPhysicalObjectStates
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
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
Element | Description |
---|---|
Type |
Class |
Name |
SetOfStates |
IRI |
|
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
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
SpatialConnection |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SpatialLocation |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SpatialRelation |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
SpeedQuantity |
IRI |
|
Subclass of |
PhysicalQuantity |
Comments |
DEF: A PhysicalQuantity that is a speed value in meters per second. |
EXAMPLES: |
USAGE: |
State
Element | Description |
---|---|
Type |
Class |
Name |
State |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
SystemState |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
TemporalRelation |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
WholeLifeActivity |
IRI |
|
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
WholeLifeSystem |
IRI |
|
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
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Subproperty of |
hasQuantity |
Comments |
DEF: A hasQuantity relationship type that specifies an angle quantity of something. |
hasBeginning
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasBeginning |
IRI |
|
Subproperty of |
hasTemporalPart |
Comments |
DEF: Inverse relationship of beginningOf |
hasColor
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasColor |
IRI |
|
Subproperty of |
hasProperty |
Comments |
DEF: A hasPropertyrelationship type that specifies the color of something. |
hasComponent
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasComponent |
IRI |
|
Subproperty of |
hasPart |
Comments |
DEF: Inverse relationship of componentOf |
hasDirection
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasDirection |
IRI |
|
Subproperty of |
hasQuantity |
Comments |
DEF: A hasQuantity relationship type that specifies a direction quantity of something. |
hasDistance
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasDistance |
IRI |
|
Subproperty of |
hasLength |
Comments |
DEF: A hasQuantity relationship type that specifies a distance quantity of something. |
hasEnding
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasEnding |
IRI |
|
Subproperty of |
hasTemporalPart |
Comments |
DEF: Inverse relationship of endingOf |
hasGeometry
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasGeometry |
IRI |
|
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 |
|
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 |
|
Subproperty of |
hasQuantity |
Comments |
DEF: A hasQuantity relationship type that specifies the length quantity of something. |
hasMember
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasMember |
IRI |
|
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 |
|
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 |
|
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 |
|
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 |
|
Comments |
DEF: Relationship type for specifying properties of particular things |
hasQuantity
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasQuantity |
IRI |
|
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 |
|
Has domain |
Event |
Has range |
Event |
Comments |
DEF: Object properties derived from TemporalRelation |
hasSpatialObject
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasSpatialObject |
IRI |
|
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 |
|
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 |
|
Subproperty of |
hasQuantity |
Comments |
DEF: A hasQuantity relationship type that specifies speed. |
hasSubject
Element | Description |
---|---|
Type |
ObjectProperty |
Name |
hasSubject |
IRI |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Accelerate |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ActivityByLevel |
IRI |
|
Subclass of |
TrafficActivity |
Comments |
DEF: A set of activities categorized according to the complexity of the action ranging from primitive to mission level. |
ActivityByNumberOfParticipants
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
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Animal |
IRI |
|
Subclass of |
TrafficParticipantByParticipantType |
Subclass of |
VRU |
Comments |
DEF: A TrafficParticipant that is a non-human biological object. |
ArtificialLightingCondition
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Bicycle |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
BorderCrossing |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Bridge |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
BrokenClouds |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
BrokenLine |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Building |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Bus |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
BusLane |
IRI |
|
Subclass of |
LaneForSpecificParticipants |
Comments |
DEF: BusLane is a LaneForSpecificParticipants that is a lane where only buses are allowed to drive |
CalmWind
Element | Description |
---|---|
Type |
Class |
Name |
CalmWind |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Car |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ChangeLane |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ChangeToLeftLane |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Clear |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
CloseUp |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
CloudCondition |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Cloudburst |
IRI |
|
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
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
ConstructionSign |
IRI |
|
Subclass of |
TemporaryRoadStructure |
Comments |
DEF: A TemporaryRoadStructure that is a traffic sign indicating construction or landscaping work in a specific area. |
ConstructionSiteDetour
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Cracks |
IRI |
|
Subclass of |
RoadSurfaceFeature |
Comments |
DEF:Cracks is a RoadSurfaceFeature that are fractures or discontinuation of the road surface. |
Cross
Element | Description |
---|---|
Type |
Class |
Name |
Cross |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
CrossRoad |
IRI |
|
Subclass of |
IntersectionAtGrade |
Comments |
DEF: An Intersection where exactly four roads meet. |
Curb
Element | Description |
---|---|
Type |
Class |
Name |
Curb |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
CutIn |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
CutOut |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
CycleLane |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Debris |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Decelerate |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
DistributorRoad |
IRI |
|
Subclass of |
Road |
Comments |
DEF: A Road with low to moderate capacity that connects local and minor roads to arterial roads. |
DividedRoad
Element | Description |
---|---|
Type |
Class |
Name |
DividedRoad |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
DomainConcepts |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
DoubleSolidLine |
IRI |
|
Subclass of |
LaneMarking |
Comments |
DEF: DoubleSolidLine is a LaneMarking that separates two lanes. |
DrivableAreaElement
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
Element | Description |
---|---|
Type |
Class |
Name |
Driver |
IRI |
|
Subclass of |
Human |
Subclass of |
VRU |
Comments |
DEF: A HumanParticipant who controls a vehicle. |
DrivingActivity
Element | Description |
---|---|
Type |
Class |
Name |
DrivingActivity |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
EmergencyVehicle |
IRI |
|
Subclass of |
NonVRU |
Subclass of |
OfficialVehicle |
Comments |
DEF: A vehicle that is used by an emergency service to respond to incidents. |
EnvironmentalCondition
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
Element | Description |
---|---|
Type |
Class |
Name |
FewClouds |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
FlashHeadlights |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
FoggyCondition |
IRI |
|
Subclass of |
ParticulatesCondition |
Comments |
DEF: A ParticulateCondition where the particles are a mixture of non-precipitating water droplets or ice crystals. |
FollowRoadUser
Element | Description |
---|---|
Type |
Class |
Name |
FollowRoadUser |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
FollowTrajectory |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
FreshBreeze |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
GLONASS |
IRI |
|
Subclass of |
PositioningCondition |
Comments |
DEF: A PositioningCondition in which the vehicle’s position is determined using the GLONASS global navigation satellite system. |
GPS
Element | Description |
---|---|
Type |
Class |
Name |
GPS |
IRI |
|
Subclass of |
PositioningCondition |
Comments |
DEF: A PositioningCondition in which the vehicle’s position is determined using the Global Positioning System (GPS). |
Gale
Element | Description |
---|---|
Type |
Class |
Name |
Gale |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Galileo |
IRI |
|
Subclass of |
PositioningCondition |
Comments |
DEF: A PositioningCondition in which the vehicle’s position is determined using the Galileo global navigation satellite system. |
GentleBreeze
Element | Description |
---|---|
Type |
Class |
Name |
GentleBreeze |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
GeofencedZone |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
GoodsVehicle |
IRI |
|
Subclass of |
Vehicle |
Comments |
DEF: Goods vehicles are vehicles with their designed purpose of transporting goods |
GradeSeparatedIntersection
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
Element | Description |
---|---|
Type |
Class |
Name |
GrassShoulder |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
GuardRail |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
HeavyRain |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
HeavySnow |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
HonkHorn |
IRI |
|
Subclass of |
VehicleCommunicationActivity |
Comments |
DEF: A VehicleCommunicatingActivity in which the subject vehicle sounds the car horn in order to warn other traffic participants. |
Human
Element | Description |
---|---|
Type |
Class |
Name |
Human |
IRI |
|
Subclass of |
TrafficParticipantByParticipantType |
Comments |
DEF: A human TrafficParticipant that is driving or moving in traffic, either within/on a vehicle or as pedestrian. |
HumanActivity
Element | Description |
---|---|
Type |
Class |
Name |
HumanActivity |
IRI |
|
Subclass of |
ActivityByTrafficParticipantType |
Comments |
DEF: A set of activities performed by humans, such as pedestrians. |
Hurricane
Element | Description |
---|---|
Type |
Class |
Name |
Hurricane |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
InformationSign |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
InterferenceZone |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Junction |
IRI |
|
Subclass of |
WholeLifeFunctionalSystem |
Subclass of |
WholeLifeSystem |
Subclass of |
RoadTopologyAndTrafficInfrastructure |
Comments |
DEF: A RoadTopologyAndTrafficInfrastructure where two or more roads meet. |
KeepLane
Element | Description |
---|---|
Type |
Class |
Name |
KeepLane |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Lane |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
LaneDivider |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
LaneElement |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
LaneMarking |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
LaneSection |
IRI |
|
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
LateralActivity |
IRI |
|
Subclass of |
MovingActivity |
Comments |
DEF: A MovingActivity which is characterized by sideways movement. |
LightAir
Element | Description |
---|---|
Type |
Class |
Name |
LightAir |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
LightBreeze |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
LightRain |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
LightSnow |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
LooseSurface |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
MakeALeftTurn |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
MakeARightTurn |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
MakeATurn |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Manhole |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
MarineCondition |
IRI |
|
Subclass of |
ParticulatesCondition |
Comments |
DEF: An AmbientCondition in an area near the sea where spray from the sea gets mixed into the atmosphere. |
MinorRoad
Element | Description |
---|---|
Type |
Class |
Name |
MinorRoad |
IRI |
|
Subclass of |
Road |
Comments |
DEF: MinorRoad is a Road that provides access to residential areas and other local developments. |
MissionLevelActivity
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
Element | Description |
---|---|
Type |
Class |
Name |
ModerateBreeze |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ModerateRain |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ModerateSnow |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Motorcycle |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Motorway |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
MoveAway |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
MoveBackward |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
MovingActivity |
IRI |
|
Subclass of |
ActivityByStateChange |
Comments |
DEF: A set of activities which result in a changed location of the subject traffic participant. |
MultiParticipantActivity
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
Element | Description |
---|---|
Type |
Class |
Name |
NearGale |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
NonVRU |
IRI |
|
Subclass of |
TrafficParticipantByVulnerability |
Comments |
DEF: A set of non-vulnerable road users. |
NotMove
Element | Description |
---|---|
Type |
Class |
Name |
NotMove |
IRI |
|
Subclass of |
MovingActivity |
Subclass of |
PrimitiveLevelActivity |
Subclass of |
SingleParticipantActivity |
Comments |
DEF: An Activity during which the traffic participant has a speed of zero. |
OfficialVehicle
Element | Description |
---|---|
Type |
Class |
Name |
OfficialVehicle |
IRI |
|
Subclass of |
Vehicle |
Comments |
DEF: Official vehicles are vehicles with special access and operational authorities, such as ambulance, police vehicle |
Overcast
Element | Description |
---|---|
Type |
Class |
Name |
Overcast |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Overtake |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Parking |
IRI |
|
Subclass of |
Road |
Comments |
DEF: A Road where vehicles are allowed to park. |
ParticulatesCondition
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
Element | Description |
---|---|
Type |
Class |
Name |
Pass |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
PavedShoulder |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Pedestrian |
IRI |
|
Subclass of |
Human |
Subclass of |
VRU |
Comments |
DEF: A HumanParticipant who moves in traffic on foot. |
PedestrianActivity
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
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
Element | Description |
---|---|
Type |
Class |
Name |
PedestrianZone |
IRI |
|
Subclass of |
TrafficZone |
Comments |
DEF: A Zone where only pedestrians are allowed. |
PhysicalDivider
Element | Description |
---|---|
Type |
Class |
Name |
PhysicalDivider |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Potholes |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
PrivateVehicle |
IRI |
|
Subclass of |
Vehicle |
Comments |
DEF: Private vehicles are vehicles owned and used by private individuals. |
PublicTransportationVehicle
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
Element | Description |
---|---|
Type |
Class |
Name |
RadialRoad |
IRI |
|
Subclass of |
Road |
Comments |
DEF: A Road for high-density traffic that connects motorways to distributor roads or city centers. |
RailCrossing
Element | Description |
---|---|
Type |
Class |
Name |
RailCrossing |
IRI |
|
Subclass of |
SpecialStructure |
Comments |
DEF: A SpecialStructure that is an intersection between a road and a railway track. |
RainfallCondition
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
Element | Description |
---|---|
Type |
Class |
Name |
RefuseCollection |
IRI |
|
Subclass of |
TemporaryRoadStructure |
Comments |
DEF: A TemporaryRoadStructure that contains rubbish or waste that has not been disposed yet. |
RegulatorySign
Element | Description |
---|---|
Type |
Class |
Name |
RegulatorySign |
IRI |
|
Subclass of |
TrafficSignByFunction |
Comments |
DEF: A traffic sign that indicates rules, restrictions, and prohibitions for all or specific traffic participants. |
RestrictedLane
Element | Description |
---|---|
Type |
Class |
Name |
RestrictedLane |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Rider |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
RiderActivity |
IRI |
|
Subclass of |
HumanActivity |
Comments |
DEF: A BiologicalObjectActivity where the participant is a bicyclist or motorcyclist. |
Road
Element | Description |
---|---|
Type |
Class |
Name |
Road |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
RoadMarking |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
RoadSignage |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
RoadSurface |
IRI |
|
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
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
RoadWork |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Roadblocks |
IRI |
|
Subclass of |
TemporaryRoadStructure |
Comments |
DEF: A TemporaryRoadStructure that is set up to block or control traffic along a road. |
RoadwayEdgeElement
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
Element | Description |
---|---|
Type |
Class |
Name |
Roundabout |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Run |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Ruts |
IRI |
|
Subclass of |
RoadSurfaceFeature |
SandCondition
Element | Description |
---|---|
Type |
Class |
Name |
SandCondition |
IRI |
|
Subclass of |
ParticulatesCondition |
Comments |
DEF: A ParticulateCondition where the particles consist of sand or dust. |
ScatteredClouds
Element | Description |
---|---|
Type |
Class |
Name |
ScatteredClouds |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SchoolZone |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SegmentedSurface |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ServiceLane |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SharedSpace |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Sidewalk |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Slide |
IRI |
|
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
SolidLine |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SoundBarrier |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
SoundSiren |
IRI |
|
Subclass of |
VehicleCommunicationActivity |
Comments |
DEF: A VehicleCommunicatingActivity of an emergency vehicle that uses its siren to alert other traffic participants. |
SpecialStructure
Element | Description |
---|---|
Type |
Class |
Name |
SpecialStructure |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Stand |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Start |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
Stop |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
StopLane |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Storm |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
StreetFurniture |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
StreetLight |
IRI |
|
Subclass of |
FixedRoadStructure |
Comments |
DEF: A FixedRoadStructure that is a manufactured source of light on the edge of the road. |
StreetLighting
Element | Description |
---|---|
Type |
Class |
Name |
StreetLighting |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
StrongBreeze |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
StrongGale |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Swells |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
TIntersection |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
TimeCondition |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
TollPlaza |
IRI |
|
Subclass of |
SpecialStructure |
Comments |
DEF: A SpecialStructure that contains toll roads, toll boths, and other structures for toll collection. |
TrafficActivity
Element | Description |
---|---|
Type |
Class |
Name |
TrafficActivity |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
TrafficCone |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
TrafficIsland |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
TrafficLane |
IRI |
|
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
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
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
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
TrafficSign |
IRI |
|
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
TrafficZone |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Trailer |
IRI |
|
Subclass of |
NonVRU |
Subclass of |
PrivateVehicle |
Comments |
DEF: An unpowered Vehicle that is designed for being towed by another Vehicle. |
Truck
Element | Description |
---|---|
Type |
Class |
Name |
Truck |
IRI |
|
Subclass of |
GoodsVehicle |
Subclass of |
NonVRU |
Comments |
DEF: A large and heavy road Vehicle designed and used for carrying goods and materials. |
Tunnel
Element | Description |
---|---|
Type |
Class |
Name |
Tunnel |
IRI |
|
Subclass of |
SpecialStructure |
Comments |
DEF: A SpecialStructure that is a built underground passage through or below a natural or built structure. |
Turn
Element | Description |
---|---|
Type |
Class |
Name |
Turn |
IRI |
|
Subclass of |
MovingActivity |
Subclass of |
PrimitiveLevelActivity |
Subclass of |
SingleParticipantActivity |
Comments |
DEF: An Activity during which the subject traffic participant changes its orientation. |
UndividedRoad
Element | Description |
---|---|
Type |
Class |
Name |
UndividedRoad |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
UniformSurface |
IRI |
|
Subclass of |
RoadSurface |
Comments |
DEF:UniformSurface is a RoadSurface where the surface material is distributed evenly. |
UseHazardLight
Element | Description |
---|---|
Type |
Class |
Name |
UseHazardLight |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
UseTurnIndicator |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
V2I |
IRI |
|
Subclass of |
CommunicationCondition |
Comments |
DEF: A CommunicationCondition that enables communication between a vehicle and the surrounding infrastructure. |
V2V
Element | Description |
---|---|
Type |
Class |
Name |
V2V |
IRI |
|
Subclass of |
CommunicationCondition |
Comments |
DEF: A CommunicationCondition that enables communication between a vehicle and other vehicles in a traffic situation. |
VRU
Element | Description |
---|---|
Type |
Class |
Name |
VRU |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Van |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Vehicle |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
VehicleActivity |
IRI |
|
Subclass of |
ActivityByTrafficParticipantType |
Comments |
DEF: A set of activities performed by vehicles. |
VehicleCommunicationActivity
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
Element | Description |
---|---|
Type |
Class |
Name |
VehicleLighting |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
ViolentRain |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
ViolentStorm |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Walk |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
WallOnRoadEdge |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
WarningSign |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Wave |
IRI |
|
Subclass of |
HumanCommunicationActivity |
Comments |
DEF: An Activity of a human traffic participant which waves a hand to indicate their intention. |
WeatherCondition
Element | Description |
---|---|
Type |
Class |
Name |
WeatherCondition |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
Wheelchair |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
WindCondition |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
YIntersection |
IRI |
|
Subclass of |
IntersectionAtGrade |
Comments |
DEF: An Intersection with three roads that has the shape of the capital letter Y. |
arc
Element | Description |
---|---|
Type |
Class |
Name |
arc |
IRI |
|
Subclass of |
curve |
Comments |
DEF: A Curve with a constant curvature. |
atmosphericPressure
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
Element | Description |
---|---|
Type |
Class |
Name |
cloudinessLevel |
IRI |
|
Subclass of |
environmentalConditionProperty |
Comments |
DEF: An ambientConditionProperty that determines the amount of sky covered in clouds. Okta is used as unit of measurement. |
contaminatingRoadCondition
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
Element | Description |
---|---|
Type |
Class |
Name |
curve |
IRI |
|
Subclass of |
horizontalGeometry |
Comments |
DEF: A HorizontalGeometry that is not straight. |
downSlope
Element | Description |
---|---|
Type |
Class |
Name |
downSlope |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
drivingDirection |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
environmentalConditionProperty |
IRI |
http://ontology.asam.net/ontologies/Domain#environmentalConditionProperty |
Subclass of |
PhysicalProperty |
Subclass of |
EnvironmentalCondition |
floodedRoadCondition
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
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
Element | Description |
---|---|
Type |
Class |
Name |
icyRoadCondition |
IRI |
|
Subclass of |
inducedRoadSurfaceCondition |
Comments |
DEF: An InducedRoadSurfaceCondition where the road is completely or partially covered with ice. |
inducedRoadSurfaceCondition
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
Element | Description |
---|---|
Type |
Class |
Name |
laneDimension |
IRI |
|
Subclass of |
laneProperty |
Comments |
DEF: A LaneProperty that is the width of the lane. |
laneMarkingColor
Element | Description |
---|---|
Type |
Class |
Name |
laneMarkingColor |
IRI |
|
Subclass of |
laneProperty |
Comments |
DEF: A LaneProperty that is the colour of the lane marking. |
laneMarkingWidth
Element | Description |
---|---|
Type |
Class |
Name |
laneMarkingWidth |
IRI |
|
Subclass of |
laneProperty |
Comments |
DEF: A LaneProperty that is the width of the lane marking. |
laneProperty
Element | Description |
---|---|
Type |
Class |
Name |
laneProperty |
IRI |
|
Subclass of |
roadTopologyAndTrafficInfrastructureProperty |
Comments |
DEF: A traffic infrastructure property that describes the characteristics of a lane. |
lateralProfile
Element | Description |
---|---|
Type |
Class |
Name |
lateralProfile |
IRI |
|
Subclass of |
transverseGeometry |
Comments |
DEF: A TransverseGeometry that specifies the elevation of a road orthogonally to a reference line. |
levelPlane
Element | Description |
---|---|
Type |
Class |
Name |
levelPlane |
IRI |
|
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
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
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
Element | Description |
---|---|
Type |
Class |
Name |
numberOfLanes |
IRI |
|
Subclass of |
roadTopologyAndTrafficInfrastructureProperty |
Comments |
DEF: A traffic infrastructure property that indicates how many lanes a road has. |
precipitationIntensity
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
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
Element | Description |
---|---|
Type |
Class |
Name |
roadTopologyAndTrafficInfrastructureProperty |
IRI |
http://ontology.asam.net/ontologies/Domain#roadTopologyAndTrafficInfrastructureProperty |
Subclass of |
PhysicalProperty |
Subclass of |
RoadTopologyAndTrafficInfrastructure |
snowfallIntensity
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
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
Element | Description |
---|---|
Type |
Class |
Name |
speedLimitForLane |
IRI |
http://ontology.asam.net/ontologies/Domain#speedLimitForLane |
Subclass of |
roadTopologyAndTrafficInfrastructureProperty |
spiral
Element | Description |
---|---|
Type |
Class |
Name |
spiral |
IRI |
|
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
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
Element | Description |
---|---|
Type |
Class |
Name |
straightLine |
IRI |
|
Subclass of |
horizontalGeometry |
Comments |
DEF: A HorizontalGeometry that runs as a straight line in the associated coordinate system. |
sunAzimuth
Element | Description |
---|---|
Type |
Class |
Name |
sunAzimuth |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
sunElevation |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
sunProperty |
IRI |
|
Subclass of |
environmentalConditionProperty |
Comments |
DEF: An ambientConditionProperty that defines characteristics of the sun, for example, azimuth and elevation. |
superElevation
Element | Description |
---|---|
Type |
Class |
Name |
superElevation |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
temperature |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
trafficParticipantsAndBehavioursProperty |
IRI |
http://ontology.asam.net/ontologies/Domain#trafficParticipantsAndBehavioursProperty |
Subclass of |
PhysicalProperty |
Subclass of |
TrafficParticipantAndBehavior |
transverseGeometry
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
Element | Description |
---|---|
Type |
Class |
Name |
upSlope |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
verticalGeometry |
IRI |
|
Subclass of |
drivableAreaGeometry |
Comments |
DEF: A DrivableAreaGeometry in the vertical (longitudinal) plane |
visibility
Element | Description |
---|---|
Type |
Class |
Name |
visibility |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
wetRoadCondition |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
windDirection |
IRI |
|
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
Element | Description |
---|---|
Type |
Class |
Name |
windSpeed |
IRI |
|
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:
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.
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)
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:
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 |
---|---|
OpenXOntology and its relation to other ASAM standards |
|
A directed relationship from subject to object |
|
TBox and a possible ABox |
|
Example visualization of core, domain, and application ontologies |
|
View of the core ontology |
|
Sample sets for cars |
|
Sample scenario |
|
Example of traffic light as functional system component |
|
Incorporate a new concept into OpenXOntology |
|
Phases of the data journey in the OpenX standard framework |
|
Data journey through the OpenX standards |
|
TBox for the data journey |
|
Start scene of the traffic situation |
|
Traffic situation during the passing event |
|
End scene of the traffic situation |
|
Interactions of scenario components |
|
Example of information provided by a logical reasoner about a semantic conflict |
|
Overview of phase 3 and how it relates to phases 1 and 2 |
|
Animated traffic simulator results |
|
Overview of phase 5 |
Appendix D: List of tables
Name | Description |
---|---|
Units |
|
Rules for using modal verbs |
|
Typographical conventions |
|
Overview of ontology-based languages |
|
Overview of the syntax of ontology languages |
|
Valid conditions and descriptions |
|
SWRL rules in ASAM OpenXOntology |
|
Alignment with other standards |