Vom Datenschema bis zum Einsatz in der Praxis
Einheitliche Standards sind von zentraler Bedeutung, um die Qualität, Sicherheit und Interoperabilität technischer Systeme zu gewährleisten. Sie schaffen eine gemeinsame Grundlage für Entwicklung, Dokumentation und Betrieb im Tourismus. Gerade mit Blick auf KI-basierte Anwendungen gewinnen Standards zusätzlich an Bedeutung, da sie Transparenz, Nachvollziehbarkeit und Vergleichbarkeit der Daten sicherstellen. Wichtige Voraussetzungen, um KI-Modelle zuverlässig in bestehende Systeme zu integrieren. Ziel der ODTA und ihrer Partner ist, dass die Touristiker im DACH-Raum und langfristig auf europäischer Ebene ihre Daten untereinander teilen, für innovative Anwendungen zur Verfügung stellen und für andere zugänglich machen.
Die ODTA als Unterstützerin zur Weiterentwicklung von Datenschemata für den Tourismus
Vor diesem Hintergrund hat sich die Open Data Tourism Alliance (ODTA) gegründet. Dies ist eine nichtkommerzielle Arbeitsgruppe bestehend aus Vertreter:innen der nationalen Tourismusorganisationen im D-A-CH-Raum sowie deren föderalen Organisationseinheiten (Landestourismusorganisationen, Kantone usw.) sowie wissenschaftlichen Einrichtungen. Zudem erfolgt eine enge Abstimmung mit relevanten Unternehmen wie zum Beispiel Anbieter touristischer Datenbanken, um die über die zur Verfügung gestellten Schemata aufzuklären.
Die ODTA befasst sich im Rahmen ihrer Arbeit mit der semantischen Annotierung von Daten, indem sie ein Datenschema entwickeln, das gemeinsam genutzt werden kann und soll. So können dezentral gelagerte Daten über eine Übersetzung (Mapping) zusammengeführt und zentral zur Verfügung gestellt werden. Dabei werden Vorlagen entwickelt und publiziert, die den speziellen touristischen Anforderungen genügen (Domain Specifications, kurz DS).
Diese Spezifikationen basieren auf schema.org und es werden anschlussfähige Teilmengen dieser (i.d.R. Erweiterungen) an das schema.org-Konsortium weitergetragen mit dem Ziel, dass dort noch fehlende Aspekte übernommen werden. Die ODTA ist zudem bestrebt, Werkzeuge bereitzustellen, um die weiterentwickelten Datenschemata so einfach wie möglich nutzbar zu machen (z. B. durch die Entwicklung eines DS-Editors oder eines Mapping Browser als Open Source-Projekt).
Wie funktioniert schema.org?
Die Logik, nach der schema.org insgesamt funktioniert, ist ein System aus Typen und deren Eigenschaften. Typen (Types oder auch Classes genannt) verkörpern inhaltliche Elemente wie ein Event. Die Types sind vergleichbar mit einer Kategorie oder Unterkategorie eines Kategoriebaumes innerhalb einer Datenbank. Damit wird ein Ereignis oder ein Ort eindeutig zugeordnet. Auch ein Hotel ist in der Logik von schema.org beispielsweise ein klar definierter Typ. Eigenschaften (Properties) werden dann dazu genutzt, um Typen näher zu beschreiben. Eigenschaften des Typs Event (schema:Event) können der Start der Veranstaltung (schema:startDate), die Dauer (duration) der Veranstaltung oder der Ort, wo diese stattfindet (location), sein.
Zu dieser recht simplen Grundstruktur kommt, dass schema.org hierarchisch angelegt ist. Das bedeutet, dass es unterhalb vom Typen „Thing” weitere Typen (Unterklassen) geben kann, in denen weitere Eigenschaften hinterlegt sind. So ist eine Unterklasse von „Thing” zum Beispiel „Event“ und ein Beispiel für eine der Unterklassen davon ist ein „Hackathon“ (Hierarchie = Thing > Event > Hackathon). Je weiter oben ein Typ ist, desto allgemeiner ist dieser und je weiter unten in der Hierarchie, desto spezifischer wird er (ein Hackathon ist eine spezifische Form eines Events).
Nach dieser Logik werden alle Eigenschaften (Properties), die eine Oberklasse hat, an die darunterliegenden Klassen vererbt. Wenn also ein „Thing“ eine bestimmte Eigenschaft hat, so hat diese auch der Typ „Event“ und der Typ „Hackathon“, nicht aber umgekehrt (Top-Down). Diese hierarchische Logik ist hier gut ersichtlich: https://schema.org/docs/full.html
Was sind die Domain Specifications?
Schema.org soll eine möglichst weltweite Gültigkeit haben und muss damit universell über Branchen und Stakeholder hinweg einsetzbar sein. Dies führt mitunter dazu, dass für den Einsatz im Tourismus nicht eindeutig ist (z. B. wann ist etwas ein POI und wann eine TouristAttraction?). Ein zu hohes Maß an Differenzierungen wäre aus dem Blickwinkel Dritter sehr unübersichtlich und damit nicht im Sinne des schema.org-Konsortiums. Für den Tourismus werden nun mitunter spezifischere Typen und Eigenschaften benötigt als jene, die in schema.org bereits definiert sind.
Für diese Spezifizierung, die entweder anders, aber oftmals eben auch feingranularer sein muss, wurden die Domain Specifications entwickelt. Sie spezifizieren das schema.org-Vokabular aus Sicht des Tourismus im Sinne der „Domäne Tourismus“, sodass die Zuordnung von Objekten der Wirklichkeit stets eindeutig definiert ist und damit im übertragenen Sinne eine “Sprache” sprechen, bzw. dieselben Domain Specifications nutzen. Wenn schema.org als eine „Sprache für Daten“ angesehen wird, dann listen die DS auf, welche Typen und Properties genau verwendet werden sollen, damit tourismusspezifische Dinge eindeutig und mitunter detailreicher beschrieben werden können.
Es sind Ausformung, die den Anforderungen an touristische Daten besser gerecht wird, als das allgemeine Vokabular. Anders formuliert: Domain Specifications bieten ein Benutzungsmuster für schema.org, das für eine bestimmte Domäne gilt, in diesem Fall den Tourismus. In den jeweiligen Mustern sind die wichtigen Eigenschaften (Properties) eines Typs von schema.org enthalten sowie auch deren Beschränkungen. Darüber hinaus kann eine DS neue Typen und Eigenschaften haben, die in schema.org (noch) nicht vorhanden, aber für die Domäne nötig sind.
Wie kann es gelingen, dass schema.org die Spezifika des Tourismus berücksichtigt?
Im Tourismus gibt es zum Beispiel unzählige unterschiedliche Arten von Events wie Weinverköstigungen, Messen, Sportveranstaltungen usw. Diese sollten alle über die Domain Specifications abgebildet werden können. Allerdings ist es eher unrealistisch, dass diese dann alle vom schema.org-Konsortium (u. a. Google) übernommen werden, weil sie einfach viel zu speziell sind.
Das Ziel wäre dennoch, dass möglichst diejenigen Typen und Eigenschaften, die innerhalb der DS neu definiert wurden auch in das reguläre Vokabular von schema.org integriert werden, wenn diese einen entsprechenden Geltungsbereich haben – wie dies zum Beispiel bei “Trails” der Fall ist, da es weltweit gesehen viele Millionen Wanderrouten gibt und diese damit einen berechtigten Anspruch haben, auch in schema.org als eigener Type geführt zu werden.
Daher gilt immer die Prämisse: Bei allen Erweiterungen sollte so viel wie möglich spezifiziert werden können, aber gleichzeitig sollten bei schema.org so wenig wie mögliche Anpassungen erforderlich sein.
Warum sind Domain Specifications wichtig?
Die Nutzung der Domain Specifications durch die Tourismusbranche ist deshalb wichtig, damit Daten in den nationalen Content-Hubs auf die gleiche Art und Weise beschrieben und auch spezifischere Datenschemata in den nationalen Content-Hubs einheitlich aufgenommen werden.
Nur, wenn hier auf eine Einheitlichkeit geachtet wird, dann können Daten miteinander verglichen und es können zum Beispiel alle Weinverköstigungen in Deutschland, Österreich oder der Schweiz (und darüber hinaus) aus dem jeweiligen Content-Hub ausgelesen werden.
