BeAwareOntology

Main public repository for the BeAware Ontology.

Citation

This dataset repository corresponds to the following publication:

@INPROCEEDINGS{10275440,
  author={Ruiz-Celada, Oriol and Dalmases, Albert and Suárez, Raúl and Rosell, Jan},
  booktitle={2023 IEEE 28th International Conference on Emerging Technologies and Factory Automation (ETFA)}, 
  title={BE-AWARE: an ontology-based adaptive robotic manipulation framework}, 
  year={2023},
  volume={},
  number={},
  pages={1-4},
  keywords={Service robots;Perturbation methods;Distance measurement;Cognition;Planning;Task analysis;Manufacturing automation;Robotic manipulation;knowledge;reasoning;ontology},
  doi={10.1109/ETFA54631.2023.10275440}}

BeAware Ontology Overview

Introduction

The beaware_ontology.owl is the core semantic knowledge representation for the BeAware Framework. It defines the structure of behaviors, primitives, flavors, and their relationships using OWL (Web Ontology Language) in RDF/XML format. This ontology enables the framework to reason about behavior composition, context-dependent execution, and monitoring/recovery structures.

Ontology Structure

The ontology is organized into three main sections:

1. Object Properties - Define relationships between classes
2. Data Properties - Define attributes with literal values
3. Classes - Define the core concepts and their hierarchies

---

Core Concepts

Behavior

Class: Behavior

Represents a composite action composed of other behaviors and primitives. In Behavior Trees (BTs), they are represented by SubTree and BehaviorTree tags.

Key Properties:

• hasBTid - Unique identifier for the behavior tree
• hasPortwithDefaultValue - Default values for behavior ports
• hasRole - Functional role of the behavior

Important: Not all behaviors are high-level (PDDL) behaviors. High-level behaviors that appear in the PDDL domain are instances of HighLevelBehavior.

Subtypes:

• HighLevelBehavior - Behaviors that appear in PDDL domain (formerly called "HighBehavior")
• FunctionalBehavior - Behaviors with specific functional roles
• AuxiliaryBehavior - Supporting behaviors
• ConditionBehavior - Condition-checking behaviors
• RecoveryBehavior - Recovery action behaviors

Primitive

Class: Primitive

Represents an indivisible unit of action. In BTs, they are represented by the Action tag. Primitives are the atomic operations that cannot be further decomposed.

Key Properties:

• hasPortwithDefaultValue - Default values for primitive ports

Flavor

Class: Flavor

Flavors modify or augment behaviors through context-specific transformations. They define how behaviors should be adapted based on different execution contexts.

Key Properties:

• hasTrigger - Specifies when/how the flavor is applied

Main Subtypes:

1. SubbehaviorModifier

Flavors that apply to the target subbehavior itself:

• AddBtoA - Loads template for B and adds it to the right of A with a decorator (Fallback, Sequence, etc.)
• ReplaceAbyB - Replaces behavior A with behavior B
• Ignore - Deletes or marks the target subbehavior to be skipped
• BAlternativetoA - Marks B as an alternative to A

2. SequenceModifier

Flavors that modify the order of behaviors in a sequence:

• SwitchAandB - Swaps the execution order of behaviors A and B
• DelayAUntilAfterB - Delays execution of A until after B completes
• DelayAUntilBeforeB - Delays execution of A until just before B starts
• AifBfails - Executes A only if B returns failure; equivalent to A→B becoming A?B (if A succeeds, B is skipped)

3. ParameterModifier

Flavors that modify or set parameters in the BT:

• FixParameter - Sets a parameter to a fixed value
  • hasParamTarget - Name of the parameter to modify
  • hasNewValue - New value to assign
  • Example: AddKinematicRestriction (subclass) - Adds kinematic constraints
• ModulateParameter - Dynamically modulates a parameter value
• ReplaceByParam - Replaces a parameter by obtaining value through a query
  • obtainsParamValuewithQuery - Query to obtain the new value
  • replacedByParam - Parameter to replace

4. BeAwareStateFlavors

Flavors that directly interact with internal state:

• ASetsPropertyQ - Behavior A sets property Q in the state
  • hasTargetBehavior - The behavior that sets the property
  • hasTargetProperty - The property being set

5. KinematicFlavors

Flavors related to kinematic constraints and motion:

• AddKinematicRestriction - Adds kinematic restrictions to behaviors

6. MRSFlavor (Monitoring and Recovery Structure)

Flavors for adding monitoring and recovery capabilities to behaviors:

• AhasMRS - Base class indicating a behavior has monitoring/recovery structure

  • hasTargetBehavior - The behavior being monitored/recovered

• AhasPreCondition - Behavior has preconditions to check before execution

  • hasConditionBlock - Behavior(s) implementing the condition check
  • hasRecoveryBlock - Behavior(s) to execute if condition fails

• AhasHoldCondition - Behavior has conditions to maintain during execution

  • hasConditionBlock - Behavior(s) implementing the condition monitoring
  • hasRecoveryBlock - Behavior(s) to execute if condition is violated
  • isTerminal - Boolean flag indicating if failure is terminal

• AhasHoldConditionTerminal - Hold condition where failure is terminal (subclass of AhasHoldCondition with isTerminal=true)

• AhasPostCondition - Behavior has postconditions to verify after execution

  • hasConditionBlock - Behavior(s) implementing the condition check
  • hasRecoveryBlock - Behavior(s) to execute if condition fails

• AhasRecovery - Puts action in a fallback with recovery behavior if action fails

  • hasRecoveryBlock - Behavior(s) to execute on failure

• AisRetriable - Marks a behavior as retriable on failure

ContextMode / ActionMode

Classes: ContextMode, ActionMode (equivalent)

Context modes define different execution contexts for behaviors. When a behavior has multiple context modes, the framework expands it into multiple variants (e.g., "High Behavior Y" → "High Behavior Y__context_mode_alpha", "High Behavior Y__context_mode_beta").

Subtypes:

• RiskActionMode - Context mode for risky actions

Context modes enable the same behavior to have different implementations or parameters depending on the execution context.

---

Object Properties

Object properties define relationships between individuals in the ontology:

Property	Domain	Range	Description
hasFlavor	Behavior	Flavor	Links a behavior to its associated flavors
hasMRSFlavor	Behavior	MRSFlavor	Links a behavior to MRS-specific flavors
hasContextMode	Behavior	ContextMode	Links a behavior to its context modes
hasTargetBehavior	Flavor	Behavior	Identifies the target behavior of a flavor
hasTargetBehaviorA	Flavor	Behavior/Primitive	First target in binary flavor operations
hasTargetBehaviorB	Flavor	Behavior/Primitive	Second target in binary flavor operations
hasRecovery	Behavior	Behavior	Links a behavior to its recovery behavior
hasConditionBlock	MRSFlavor	Behavior	Links MRS flavor to condition checking behaviors
hasRecoveryBlock	MRSFlavor	Behavior	Links MRS flavor to recovery behaviors
incompatibleWith	Behavior	Behavior	Marks two behaviors as incompatible
modeHasFlavor	ContextMode	Flavor	Links context modes to their specific flavors
hasTargetProperty	Flavor	Data	Target property for state-modifying flavors

---

Data Properties

Data properties define attributes with literal values:

Property Hierarchy

BeAwareProperties (Top-level)

• BehaviorProperties - Properties of behaviors

  • hasBTid (string) - Behavior tree identifier
  • hasRole (string) - Functional role

• FlavorProperties - Properties of flavors

  • hasTrigger (string) - Trigger condition for flavor application

• ParamModulateProperties - Properties for parameter modification

  • hasParamTarget (string) - Target parameter name
  • hasNewValue (double) - New parameter value
  • obtainsParamValuewithQuery (string) - Query to obtain parameter value
  • replacedByParam (string) - Parameter to be replaced

• MRSProperties - Monitoring and Recovery Structure properties

  • isTerminal (boolean) - Whether failure is terminal

• General Properties

  • hasParameter (string) - Generic parameter association
  • hasPort (string) - BT port specification
  • hasPortwithDefaultValue (string) - BT port with default value
  • hasValue (string) - Generic value property
  • hasDecorator (string) - BT decorator type (Sequence, Fallback, etc.)

---

Physical vs Abstract Classes

The ontology distinguishes between physical and abstract entities:

• Physical - Real-world entities

  • Object - Physical objects in the environment

• Abstract - Conceptual entities (disjoint from Physical)

  • Behavior - Abstract behavior concepts
  • Primitive - Abstract primitive actions
  • Flavor - Abstract behavior modifications
  • ContextMode / ActionMode - Abstract execution contexts
  • Parameter - Abstract parameter concepts
  • TBD - Placeholder for testing (to be ignored)

---

Special Classes

TBD

Class: TBD

A placeholder class for testing and work-in-progress elements. Classes under TBD should be ignored in production:

• AfullfillsCondition - (Work in progress)
• Condition - (Work in progress)
• ErrorClass - (Work in progress)
• KinematicRestriction - (Work in progress)

---

Disjoint Classes

The ontology enforces several disjointness constraints:

1. Top-level disjointness:

   • Abstract, Physical, ErrorClass are mutually disjoint

2. Abstract entity disjointness:

   • Behavior, Primitive, Flavor, Parameter are mutually disjoint

3. Flavor modification disjointness:

   • Ignore, ReplaceByParam, SequenceModifier are mutually disjoint

---

Usage Examples

Example 1: High-Level Behavior with Context Modes

# Behavior "Pick Object" with two context modes
Pick_Object rdf:type HighLevelBehavior ;
    hasBTid "Pick Object" ;
    hasContextMode Gentle_Mode ;
    hasContextMode Fast_Mode .

# Context modes have associated flavors
Gentle_Mode modeHasFlavor FixSpeed_Slow .
Fast_Mode modeHasFlavor FixSpeed_Fast .

# Results in expanded behaviors:
# - "pick_object__gentle_mode"
# - "pick_object__fast_mode"

Example 2: Behavior with MRS Flavors

# Behavior with precondition and recovery
Navigate_To_Location hasFlavor CheckPathClear_Precondition ;
    hasFlavor Retriable .

CheckPathClear_Precondition rdf:type AhasPreCondition ;
    hasConditionBlock Check_Obstacle_Free ;
    hasRecoveryBlock Clear_Path_Recovery .

Example 3: Subbehavior Modification

# Replace gripper behavior in specific context
Adaptive_Grasp_Mode modeHasFlavor Replace_StandardGrip_by_PrecisionGrip .

Replace_StandardGrip_by_PrecisionGrip rdf:type ReplaceAbyB ;
    hasTargetBehaviorA Standard_Grip ;
    hasTargetBehaviorB Precision_Grip .

---

Integration with PDDL

The ontology supports integration with PDDL (Planning Domain Definition Language):

1. High-Level Behaviors are marked as instances of HighLevelBehavior class
2. These behaviors correspond to PDDL domain actions
3. In Python code, they are identified by the pddl_behavior=True flag
4. Context mode expansion creates separate PDDL actions for each mode

Example:

• PDDL domain has action (pick ?obj)
• Ontology has Pick_Object behavior with 2 context modes
• Results in behaviors: pick_object__gentle, pick_object__fast
• Each has its own BT template and parameters

Version Information

• Ontology IRI: http://www.semanticweb.org/oriol.ruiz/ontologies/2023/8/beaware_ontology
• Format: RDF/XML (OWL 2)
• Generated by: OWL API (version 4.5.9.2019-02-01T07:24:44Z)