| Alpha Prototype — Feedback Welcome! |
Kurzbeschreibung
Service Directorys von Mobilitätsdienstleistungen sind Verzeichnisse von Diensten (APIs), welche die Planung und Buchung von Reisen unterstützen. Derartige Verzeichnisse spielen in Szenarien zur internationalen Vernetzung der Mobilität, für MaaS (Mobility as a Service) und für AI-basierte Assistenten eine Schlüsselrolle. Standards und Protokolle hierfür sind jedoch noch kaum etabliert.
Mit diesem Beitrag möchten wir zur Entwicklung und Standardisierung dieses Gebiets beitragen.
Fachliche Beschreibung
Was ist ein Service Directory von Mobilitätsdienstleistungen?
Ein Service Directory von Mobilitätsdienstleistungen ist elektronisches, maschinen-lesbares Verzeichnis (auch “catalog”, “registry”, “yellow pages”) von Diensten (hauptsächlich APIs) im Bereich Mobilität. Es unterstützt die Suche nach Anbietern (Intermediäre, Vermittler) mit ihren Planungs- und Vertriebs-Schnittstellen (APIs). Es ist damit ein Schlüssel für die Planung von intermodalen, mehrteiligen Reisen, inklusive Bepreisung und die anschliessende Buchung (Reservation, Kauf, Bezahlung, Clearing).
Wozu braucht es derartige Service Directorys?
Aktuell sehen wir diese Argumente:
- EU-Regulierung: Die MMTIS-Verordnung der EU fordert von den NAPs die Bereitstellung von bestimmten Datensätzen. Im Annex werden rund 73 Datenkategorien definiert. Manche davon könnten in Form eines Verzeichnisses aufgebaut werden. Die genauen Ausführungsbestimmungen werden aktuell (Frühling 2024) in einer NAPCORE WG 3 erarbeitet (mit Beteiligung unseres Teams SKI+).
- Vision MaaS (Mobility as a Service ): Für den Aufbau eines internationalen, interoperablen, roaming-fähigen MaaS-Systems braucht es Service Directories. Nur dank eines Verzeichnisses könnte ein Roaming-Client (z. B. ein MaaS-Nutzerin aus dem Ausland die verfügbaren Services finden).
- AI-basierte persönliche Assistenten/Agenten: nach Prognosen von Gartner und anderen Anbietern von IT-Marktanalysen werden in wenigen Jahren viele Käufe durch AI-basierte Assistenten resp. Agenten getätigt. Menschen fragen dann ihren AI-Prompt z. B. “wie kann ich von A nach B reisen?” und “Buche mir diese Reise!”. Dafür wird es strukturierte Verzeichnisse von Mobilitätsanbietern brauchen.
Aktueller Stand der Umsetzung
Nach unserer Beobachtung stecken derartige Vorhaben noch in den Kinderschuhen. In vielen Ländern sind keine derartigen Verzeichnisse als Open Data bekannt. Ebenso fehlt die Standardisierung von Datenformaten und Prozessen dafür. Auf europäischer Ebene (CEN) oder weltweit (ISO) sind uns keine Standards hierfür bekannt.
Erwähnenswert ist das Beispiel Finnland (NAP von Finnland, https://finap.fi/#/services) mit einem Verzeichnis von 3000+ Transportdiensten (Taxi, Züge, Autovermieter, usw.). Allerdings fokussiert dieses hauptsächlich auf Transportunternehmen und nicht Intermediäre.
Technische Beschreibung
Entwurf eines prototypischen Datenmodells (JSON) für die Schweiz
Nachfolgend entwerfen wir ein Datenmodell für einen Prototypen für ein Verzeichnis von Mobilitätsdiensten. Dieses soll Metadaten wie URL, Beschreibung, unterstützte Vertriebsprozesse wiedergeben können. Das Modell soll eine Grundlage liefern, um die Diskussion mit Akteuren und der Community beginnen zu können.
Specification by Example
Unser Entwurf soll hier anhand eines beispielhaften, prototypischen Datensatzes vorgestellt werden.
{
"last_updated": "2024-07-26T15:54:16.940281+00:00",
"ttl": 31536000,
"version": "0.1",
"spec": "https://opentransportdata.swiss/de/cookbook/service-directory",
"mobilityProviders": [
{
"id": "1",
"name": "SBB Swiss Mobility API - Ticketing",
"description": "An interface that you can integrate into your own distribution system. Fare details are made available to you via this interface.",
"type": "intermediary",
"endpoints": [
{
"url": "https://developer.sbb.ch/apis/b2p/information",
"environment": "prod",
"service_types": [
"pricing",
"reservation"
],
"api_protocol": "proprietary",
"api_version": "3.26.2",
"api_profile": "3.26.2/none",
"credentials": "BearerToken",
"url_description": "SBB Swiss Mobility API - Ticketing. An interface that you can integrate into your own distribution system. Fare details are made available to you via this interface.\nThere are two ways to use the service:\n- Either integrate the SBB Swiss Mobility API as a full version, so that bookings are made directly via your distribution environment\n- Or use the Affiliate solution, with a link to the SBB webshop or SBB mobile",
"qos_document": "https://developer.sbb.ch/apis/b2p/information",
"url_contractual": "https://company.sbb.ch/en/sbb-as-business-partner/services/digital-sales-solutions/sales-solutions/sbb-swiss-mobility-api/sbb-swiss-mobility-api-gtc.html",
"covered_modes": [
"rail",
"tram",
"bus",
"trolleybus",
"metro"
]
}
],
"myOpertors": [
{
"ref": "ch:1:sboid:100001",
"name": "Schweizerische Bundesbahnen SBB"
}
],
"otherOpertors": [],
"coveredArea": "CH"
},
{
"id": "101",
"name": "Open Journey Planner 2.0",
"description": "OJP is the API's Route Planner. The API can be used to plan trips, track journeys, and build departure and arrival indicators. OJP works from coordinate to coordinate, address to address.",
"type": "intermediary",
"endpoints": [
{
"url": "https://api.opentransportdata.swiss/ojp20",
"environment": "prod",
"service_types": [
"planning"
],
"api_protocol": "OJP",
"api_version": "2.0",
"api_profile": "none",
"credentials": "BearerToken",
"url_description": "unknown",
"qos_document": "https://data.opentransportdata.swiss/en/dataset/ojp2-0",
"url_contractual": "https://opentransportdata.swiss/en/dev-dashboard",
"covered_modes": [
"bus",
"coach",
"funicular",
"metro",
"rail",
"tram",
"trolleybus",
"water",
"cableway",
"taxi",
"bicycle",
"demand_and_response_bus",
"car",
"scooter",
"cable_car",
"telecabin",
"air_cableway"
]
}
],
"myOpertors": [],
"otherOpertors": [],
"coveredArea": "CH"
},
{
"id": "102",
"name": "OJPFare",
"description": "Beta: Price information with OJP Fares. A query of public transport prices via NOVA is made available via this interface. This is an initial test system and the data comes from integration and not from production.",
"type": "intermediary",
"endpoints": [
{
"url": "https://api.opentransportdata.swiss/ojpfare/",
"environment": "int",
"service_types": [
"pricing"
],
"api_protocol": "OJP",
"api_version": "1.0",
"api_profile": "none",
"credentials": "BearerToken",
"url_description": "unknown",
"qos_document": "https://opentransportdata.swiss/en/cookbook/beta-price-information-with-ojp-fares-2",
"url_contractual": "https://opentransportdata.swiss/de/dev-dashboard",
"covered_modes": [
"bus",
"coach",
"funicular",
"metro",
"rail",
"tram",
"trolleybus",
"water",
"cableway",
"taxi",
"bicycle",
"demand_and_response_bus",
"car",
"scooter",
"cable_car",
"telecabin",
"air_cableway"
]
}
],
"myOpertors": [],
"otherOpertors": [],
"coveredArea": "CH"
}
]
}
Modellierung als UML-Klassendiagramm
Grundlegender Aufbau
Die grundlegende Struktur ist eine Liste (Array) mit allen bekannten mobilityProviders. In künftigen Versionen könnte anstelle einer Datei eine Abfrageschnittstelle treten, welche die Abfrage von einzelnen mobilityProvider nach bestimmten Merkmalen ermöglicht.
MobilityProvider
MobilityProvider umfasst grundlegende Felder (einfache Merkmale) desselben:
- id: Identifikator; soweit möglich aus etablierten Verzeichnissen übernommen (z. B. sboid).
- orgId: Identifikator aus dem atlas-Verzeichnis atlas.app.sbb.ch (für aktuelle Beispieldaten nicht existent).
- type: Enum (Wertebereich: provider, intermediary, providerAndIntermediary).
- coveredArea: siehe weiter unten.
Dazu kommen die Listen (Arrays) von endpoints, myOperators und otherOperators.
Endpoint
Endpoint definiert eine konkrete API-Schnittstelle für die automatische Nutzung. Hinweise zu den Feldern (siehe auch Enums):
- apiVerision / apiProfile: Version und (gegebenenfalls) Profil-Ausprägung des Schnittstellenstandards/Formats.
- urlDescription / urlContractual /QoSDocument: URLs mit entsprechenden Dokumentationen (Spezifikation & Dokumenation / Vertragliches /Quality of Service)
- serviceType: Wertebereich generalInfo, planning, availability, using, pricing, reservation, bookingLeg, bookingTrip, complaints, payment.
- apiProtocol: Wertebereich proprietary, TOMP, OJP, OSDM.
- coveredMode: Wertebereich air, bus, coach, ferry, funicular, lift, metro, rail, tram, trolleybus, water, cableway, motorcycle, taxi, bicycle, shuttle, demand_and_response_bus, horse_drawn_carriage, car, scooter, cable_car, telecabin, air_cableway, monorail, other. Entspricht den Modi von NeTEx.
- credentials: Wertebereich BearerToken, OAuthSKI, OAuth, unknown.
Operator
myOperators und otherOperators referenzieren unterstützte resp. assoziierte Anbieter (Transportunternehmen); beschränkt auf id (ref) und Name; weiterführende Daten müssten in einer separaten Liste ausgelagert werden.
coveredCountry / coveredArea
Dieses Feld in MobilityProvider soll die geographische Abdeckung definiert werden. Folgende Lösung wird hier vorgeschlagen:
- Definition von geographischen Bereichen (Areas) mittels Geofences mit WGS-84-Koordinaten, ausgelagert in eine separate GeoJSON-Datei.
- Verwendung von GeoJSON FeatureCollections, Definition von Polygonen/Multipolgonen.
- Referenzierung von üblichen, gebräuchlichen Abkürzuungen, z. B. CH für die Schweiz, Kantonskürzel für Kantone, usw.
- noch nicht vorhandene Geofences werden neu erfasst, mit passendem Kürzel.
Weiterführende Angaben
Dies ist zurzeit ein “alpha Entwurf” zur Diskussion und ohne jede Verbindlichkeit.
Feedback willkommen, bitte an opendata@sbb.ch.