Im Rahmen der Open Data Tourism Alliance (ODTA) wurde ein Prozess definiert, wie die Domain Specifications weiterentwickelt werden sollen. Dieser besteht aus drei Basisschritten:

1. Einreichung eines Anforderungsprofils für einen spezifischen Datentyp seitens einer Arbeitsgruppe in der ODTA an das Semantic Technology Institut (STI) in Innsbruck (= Einreichung eines Anforderungsprofils für die DS).
2. Das STI analysiert die Einreichung und erstellt einen Vorschlag, wie die bei der Einreichung formulierten Anforderungen an die jeweilige Domain Specification im schema.org-Vokabular aussehen können und übermittelt diesen Vorschlag an die ODTA mit der Bitte um Kommentierung (= Bitte um Kommentare). In der ODTA erfolgt eine Diskussion sowie die Kommentierung.
3. Diese Kommentare werden dann vom STI eingearbeitet und in einer Pre-Final-Version erneut zurückgespielt. Die Pre-Final-Version wird von der ODTA endgültig Verabschiedet, sodass abschließend vom STI eine neue Domain Specification veröffentlicht sowie Erweiterungen mit einem entsprechenden Geltungsbereich an das schema.org-Konsortium weitergegeben werden.

Die Basis ist die Einreichung seitens einer Arbeitsgruppe innerhalb der ODTA, welche zu bestimmten Themen Anforderungen definiert und diese in eine dafür entwickelte Vorlage (Canvas) einarbeitet. Die Vorlage reduziert dabei die Komplexität der Anforderungen. Die Aufgabe der Touristiker (= ODTA-Arbeitsgruppe) ist es, diese Anforderungen zu beschreiben. Unter Anforderungen sind Dinge zu verstehen, die nur fachkundige Touristiker beantworten können, nicht aber das STI als technisch versierter Partner. Die Kernkompetenz der Arbeitsgruppen sollte also bei den jeweiligen Themen liegen, die sie bearbeiten. Wenn eine Spezifizierung des Types „Event“ erfolgen soll, dann sollten also auch diejenigen in die Arbeitsgruppe involviert werden, die in ihrer täglichen Arbeit Veranstaltungen in Datenbanken einpflegen und wissen, welche Anforderungen es seitens der Veranstalter:innen gibt und wie diese innerhalb der Datenbanken bisher abgebildet werden. Im Idealfall ist dies ein Verbund unterschiedlicher DMOs, die über die ODTA koordiniert werden, damit nicht diverse DMOs unterschiedliche Vorschläge für dasselbe Datenschema einreichen.

Auf Basis der in der Vorlage definierten Anforderungen macht das STI dann eine Domainanalyse. Um den Anforderungen näher zu kommen, priorisiert das STI in einem ersten Schritt der Domainanalyse zunächst, was eine zwingende Anforderung bei der Beschreibung ist (must-have) und was „nice-to-have“ ist, sofern es im Rahmen der Einreichung entsprechende Anhaltspunkte zur Relevanz gibt. Derartige Hinweise zur Priorität der jeweiligen Anforderung sollten also von der Arbeitsgruppe, welche die Einreichung vornimmt, gegeben werden. Davon wird dann die Modellierungsentscheidung abhängig gemacht. Ziel ist es immer, dass so wenig wie möglich Anpassungen innerhalb von schema.org erfolgen. Denn wenn diese Anpassungen dann dem schema.org-Konsortium (u. a. Google) vorgestellt werden, steigt bei gut durchdachten und gleichzeitig schlanken Lösungen, mit denen viele Fälle abgebildet werden können, die Wahrscheinlichkeit, dass diese dann auch vom Konsortium angenommen werden. Der große Vorteil bei einer Annahme ist es, dass diese eben nicht nur im Rahmen der Domain Specifications eine Relevanz entfalten, sondern international und auch von Google interpretiert werden können. Das STI übersetzt die Anforderungen dann in die Logik von schema.org. Das heißt konkret, dass bei jeder Anforderung geschaut wird, welche Types und Properties dafür erforderlich wären und daraus ein DS-Vorschlag entwickelt wird, der an die ODTA gegeben wird, die diesen wiederum kommentieren und an das STI zurückspielen. Hierzu sind zunächst drei Analyseschritte in Frageform entscheidend:

1. Können wir die formulierte Anforderung bereits mit dem bestehenden Vokabular von schema.org abbilden, zum Beispiel weil sie schon bei einem anderen Datentyp beschrieben ist?
2. Falls ja, wird dies entsprechend vermerkt (Fall 1). Falls nein muss gefragt werden, ob die Anforderung Eigenschaften beinhalten, deren Systematik neu und keine weitere Ausprägung (z. B. eine bestimmte Art eines Events bei der Eigenschaft kindOfEvent) einer vorhandenen Eigenschaft sind (Fall 2)?
3. Falls ja, muss ein neuer Typ erstellt werden, der dann entsprechende Eigenschaften enthält (Fall 4). Falls nein, kann zum bestehenden Typ eine neue Eigenschaft hinzugefügt werden, die dann den bestehenden Typ lediglich erweitert (Fall 3).

Daraus folgt, dass sich vier Fälle unterscheiden lassen (siehe Abbildung). Insbesondere dann, wenn es um Themenbereiche geht, die sich unterschiedlichen Typen zuordnen lassen, sind neue Eigenschaften relevant (Fall 2), die als Ergänzung eines Types dienen. So ist das Thema digitale Besuchermessung zum Beispiel für unterschiedliche Datentypen relevant, weil sowohl zu einem Strand (Type = Beach) als auch zu einer Veranstaltung (Type = Event) noch deren Auslastung angezeigt werden kann.

Die Frage ist bei der Kommentierung des DS-Vorschlags sowie der Entwicklung einer Pre-Final-Version nicht nur, was technisch möglich, sondern auch, was strategisch sinnvoll ist. Daher sollte sowohl die ODTA als auch das STI dies berücksichtigen. Denn wenn 200 Unterklassen zum Type Event definiert werden, damit unzählige unterschiedliche Events abgebildet werden können, dann ist dies technisch zwar möglich, aber deutlich sinnvoller ist es für die Domäne Tourismus, wenn nur eine Eigenschaft (Property) mit dem Namen „kindOfEvent“ neu definiert wird, unter der dann alle Arten von Events in ihren unterschiedlichen Ausprägungen subsumiert werden können. Es kommt hierbei häufig vor, dass es genau diesen Fall gibt. Nämlich, dass es zwar keiner weiteren Types bedarf, jedoch aber weiterer Eigenschaften.

Eine Eigenschaft selbst kann dabei dann sehr unterschiedliche Ausprägungen haben. Ziel ist es nun, dass mit nur einer weiteren Eigenschaft sehr viele unterschiedliche Ausprägungen dieser Eigenschaft abgebildet werden können. Allerdings müssen auch diese Arten wiederum klar definiert werden. Dies gelingt über eine Aufzählung (Enumeration). Diese Enumeration wird in Form einer Liste vorgehalten, in der alle Themen, die ein Event haben kann, hinterlegt sind. Es können so JazzMusic, HouseMusic usw. aufgeführt werden, sodass Touristiker:innen hierüber das Event eindeutig und sehr spezifisch mit nur einer einzigen Erweiterung (kindOfEvent) beschreiben können. Wichtig ist jedoch, dass auch die Aufzählungslisten in einer detaillierten, durchdachten und strukturierten Form angelegt werden.

So macht es zum Beispiel einen Unterschied, ob ein Public Viewing für ein Fußballspiel angeboten wird, das Fußballspiel in einem Stadion live verfolgt werden kann, oder ob gar ein Fußballturnier stattfindet, wo die Teilnehmenden selbst mitspielen können. Auch stellen sich Detailfragen wie bei einem „Krimidinner“, ob dies dann ein Event im Bereich „Literature“ oder „Food“ ist. Derartige Dinge müssen berücksichtigt werden. Zudem sollten die Aufzählungslisten (Enumeration) von allen Touristiker:innen gekannt und genutzt werden, damit diese an vielen unterschiedlichen Stellen identisch eingepflegt und so besser vergleichbar sind und von Maschinen leichter interpretiert werden können.

Auf technischer Ebene sollte zudem noch geklärt sein, ob es innerhalb von schema.org bereits Unterklassen gibt, die mit den Enumeration-Listen interferieren könnten. Aktuell werden die Listen auf GitHub gepflegt und können dort ergänzt werden (ähnlich, wie bei einem Wiki): https://github.com/odta

Die Anforderungen können seitens der Touristiker:innen sehr komplex formuliert werden. Daher ist es für künftige Ergänzungen sinnvoll, wenn diese sehr schlank gehalten werden, aber dennoch die Option einer Erweiterung haben. Es sollte immer die Frage gestellt werden, ob etwas auch von mehreren Regionen oder Orten benötigt wird, oder ob es so spezifisch ist, dass es nur von einer sehr kleinen Gruppe genutzt werden würde (z. B. Anbindebalken für Pferde). Was ist der gemeinsame Nenner, der für alle konsensfähig ist? Das ist die zentrale Frage bei einer Ergänzung. Der Tourismus ist zudem auch deshalb mit Blick auf das Datenmanagement sehr komplex, weil es sich um eine Querschnittsbranche handelt. Daher sollte immer auch geschaut werden, ob es a) bereits Datenstandards aus anderen Bereichen/Branchen gibt und ob b) Daten bereits anderswo vorliegen (z. B. die Beschreibung von Kinderspielplätzen oder Badestellen im Bereich der öffentlichen Verwaltung). Eine Herausforderung ist es aktuell, dass zum Beispiel am Elberadweg Daten für jede Teilstrecke in einer eigenen Datenlogik vorgehalten werden. Die Routen und Wege sind auf inhomogen beschrieben und nutzen unterschiedliche Datenschemata. Dadurch sind sie nicht untereinander vergleichbar. Es ist damit schwierig, Daten für den gesamten Elberadweg zu extrahieren und in neue Anwendungen zu überführen.

Ziel wäre auch, dass technische Dienstleister darauf achten, dass die Weiterentwicklung ihrer Datenbanken kompatibel mit den Domain Specifications sind oder zumindest auf diese übertragbar, wozu unter Umständen eine Anpassung der bestehenden Datenmodelle erforderlich wird. Im Idealfall läuft diese Angleichung so ab, dass die Datenpflegenden den Unterschied gar nicht merken, aber die Kategorienbäume ähnlich wie bei eBay Kleinanzeigen erweitert werden, sodass diese angeklickt werden können und darüber die Berücksichtigung von Erweiterungen der Domain Specifications erfolgt.