feat(openlabel): SafetyPool ontology alignment — request for artifacts and integration path

[jdsika]

Context

The T5.3 scenario assets use OpenLABEL JSON annotation files that reference the SafetyPool ontology (https://live.safetypooldb.ai/api/ontologies/v1) instead of the ASCS-eV/OMB OpenLABEL ontology.

Both ontologies share BSI PAS-1883 as their foundation, but SafetyPool extends it with:

• Actor-role attribution — Ego/TrafficAgent suffixes on every motion tag (e.g., MotionDriveEgo, MotionAccelerateTrafficAgent)
• Mutation tags — vehicle/human type variation (MutationVehicleCar, MutationSubjectVehicleTruck)
• Safety analysis layer — concepts outside ODD scope: hazard severity, ADAS features, autonomy levels, certification, data provenance, test environment

Compatibility Analysis

We performed a systematic diff between openlabel-v2 (LinkML) and the SafetyPool vocabulary (168 terms extracted from T5.3 boundary_list):

Shared concepts (~42 terms, different structure)

OMB v2	SafetyPool	Pattern
MotionAccelerate: true	MotionAccelerateEgo, MotionAccelerateTrafficAgent	16 motion pairs
CommunicationHeadlightFlash enum	CommunicationHeadlightFlashEgo/TrafficAgent	8 communication pairs
RoadUserVehicle: VehicleCar enum	SubjectVehicleCar, MutationVehicleCar	11 vehicle types
RoadUserHuman: HumanPedestrian enum	MutationHumanPedestrian	7 human types

SafetyPool-only concepts (~60 terms)

• AbstractionLevel{Concrete,Functional,Logical} — scenario methodology
• AccidentCause{Ai,Animal,God,Human,Mechanical} — safety forensics
• AdasFeature{Acc,Aeb,Aps,Lca,Ldw,Lka,Tsr} — system-under-test
• AutonomyLevel{0-5} — SAE J3016
• Certification{CEcap,EuroNcap} — regulatory
• Hazard{Fatal,Major,Minor,NearMiss,None} — risk classification
• Source{CrashIncident,Simulation,MachineLearning,...} — provenance
• TestEnvironment{Laboratory,Road,Simulator,Track} — execution context
• PedestrianCrossing{Pelican,Puffin,Toucan,Zebra,...} — UK crossing subtypes
• StreetFurniture{BusStop,SpeedCamera} — infrastructure

Legitimate PAS-1883 gaps in OMB v2

SafetyPool includes terms that are within BSI PAS-1883 scope but currently missing from openlabel-v2:

• MotionYield, MotionPass, MotionParkingManoeuvre (behaviours)
• LaneMarkingSolidLine, LaneMarkingBrokenLine, LaneMarkingDoubleSolidLine, LaneMarkingBottsDots (lane marking enum values)
• RoundaboutNormal (junction subtype)

Key structural incompatibility

OMB v2 uses a property graph (boolean flags + typed quantitative values + SHACL validation):

Behaviour:
  MotionAccelerate: true
  motionAccelerateValue: 2.5  # ms⁻²

SafetyPool uses a flat tag bag (presence = assertion, no numeric data, actor encoded in name):

{"boundary_list": ["MotionAccelerateEgo", "MotionDecelerateTrafficAgent"]}

Request

1. Can SafetyPool provide their ontology artifacts? (OWL, SHACL, or any formal schema) — We only have the vocabulary list from the boundary_list, not the actual ontology definitions with class hierarchies, property domains/ranges, and constraints.

2. Should we create a SKOS alignment file (openlabel-v2-safetypool-mappings.ttl) mapping the ~42 shared concepts? This would enable interoperability without merging the ontologies.

3. Should the PAS-1883 gaps (MotionYield, lane markings, RoundaboutNormal) be added to openlabel-v2 LinkML regardless of SafetyPool, since they are legitimate PAS-1883 terms?

Recommendation

Based on the analysis: keep the ontologies separate with a SKOS alignment bridge. The safety analysis layer is a different domain (V&V methodology vs ODD description), the actor attribution model is structurally incompatible, and the governance is different (Deepen AI vs ASCS-eV).

SafetyPool contact: Tudor Dodoiu (Tudor.Dodoiu@warwick.ac.uk)