Überlegungen zum Transport von NBC mit Hilfe von OTDS

Aktuell beschäftigen wir uns mit der Aufgabe, beschreibende Daten von Reiseprodukten unterschiedlicher Quellen an ein Front-End-CMS zu senden. Dabei stehen wir vor der Überlegung, ob OTDS als Export-Format eine akzeptable Lösung darstellt.

Bei jedem Produkt in der Touristik müssen neben den Informationen, die für die Preiskalkulation oder Verfügbarkeit zuständig sind, auch Beschreibungen transportiert werden. Diese Beschreibungen können sowohl Texte, Verweise auf Bilder sowie Eigenschaften zu Einrichtungen und Umwelt des Produktes enthalten. Häufig werden diese beschreibenden Elemente als Not-Bookable-Content (kurz NBC) oder Beschreibungungsebene bezeichnet, im Gegensatz zur Kalkulationsebene.

Nun gibt es verschiedene Anbieter für NBC-Daten, oder auch Veranstalter, die ihre eigenen NBC-Daten abspeichern. Im Laufe der Zeit hat sich so eine unüberschaubare Anzahl an Formaten gebildet, zwischen denen munter hin und her formatiert wird.

Inerhalb des OTDS werden beide Ebenen beschrieben.
Hier ein verkürzter Einblick in die Struktur:

  • Liste von Accommodation, enthält
    • Properties (Eigenschaften) zur Beschreibung der Unterkunft
    • Preise
    • mindestens ein SellingAccom (zur Gruppierung von Unterkünften und Verpflegungen), enthält
      • Properties und Preise
      • Liste von Board (Verpflegungen), enthält
        • Properties
        • Preise
        • Liste von Unit (Unterbringungen), enthält
          • Properties
          • Liste von SellingUnit, enthält
            • Belegungsparameter der Zimmer
            • Properties
            • Preise


Bei dieser Struktur des OTDS erhält man den Eindruck, dass sich der Aufbau sehr stark an der Kalkulation von Preisen orientiert. Die Preiselemente sind an allen Elementen angebunden, die berechnet werden können.

Bei beschreibenden Elementen würde man hingegen erwarten, dass sie unabhängig von der Kalkulationsebene sind. Allerdings sind beispielsweise die beschreibenden Elemente eines Zimmers oder der Verpflegung unterhalb der SellingAccom abgelegt, wobei eine Unterkunft mehrere SellingAccom enthalten kann. So erkennt man schnell, dass bestimmte Eigenschaften mehrfach in einem Export enthalten sein müssen. Die Ursache für diese unerwünschten Redundanzen sind konzepzioneller Natur und könnte als Vermischung von Kalkulations- und Beschreibungsebene bezeichnet werden.

Nun stellt sich für uns die Frage, ob dieser Aufbau dennoch eine akzeptable Lösung darstellt, oder ob in künftigen Versionen von OTDS diese Vermischung wieder zurückgedrängt werden kann.


Wäre es nicht schön, wenn nicht immer weitere Neuerfindungen des Rades als NBC-Formate benötigt würden?

Zurück