Zunächst werden hier die Anforderungen an ein Vokabular in der Koch-Domäne dargelegt, welche sich aus unserem Kochbuch ergeben. Da die zuvor vorgestellten Auszeichnugssprachen diesen Anforderungen nicht genügen, stellen wir anschließend unser selbst entwickeltes cueML-Vokabular vor.
Folgend erklären wir, was für uns ein Rezept ausmacht und was das Vokabular dementsprechend erfassen können muss. Die einzelnen Punkte werden zusammenfassend am Ende noch einmal aufgelistet.
Ein Rezept besteht für uns nicht nur aus reinem Text. Aus unserer Sicht ist ein Rezept in Themenbereiche unterteilt. Das Beispiel-Rezept aus Abb. 1 ist eindeutig in einen Bereich für ein Bild, eine Überschrift/Namen einen einleitenden Text, usw. aufgeteilt. Ein Rezept hat für uns im Allgemeinen folgende klar strukturierte und voneinander separierte Bereiche:
Ein Vokabular sollte diese Struktur erfassen können. Sofern in einem Rezept die Struktur noch nicht gegeben ist, sollten die im Rezept vorhandenen Informationen nach einer Auszeichnung mit dem Vokabular automatisch in so eine Struktur umgewandelt werden können.
In den Rezepten aus unserem Kochbuch ist keine Zutatenliste vorhanden. Die Zutaten sind allerdings in den Zubereitungs-Anweisungen zu finden. Dementsprechend sollte nach einer Auszeichnung mit dem Vokabular eine Zutatenliste aus den Zubereitungs-Anweisungen eines Rezeptes extrahierbar sein. Daraus ergeben sich weitere Anforderungen, wie folgende zwei Beispiel-Sätze verdeutlichen:
In Erstens kann Soja zum würzen verwendet werden. Da Soja jedoch sehr geschmacksintensiv ist, hat das Gericht, je nachdem ob Soja verwendet wird, eine ganz andere Geschmacksrichtung. Dementsprechend wäre eine Festlegung, ob Soja in die Zutatenliste kommt oder nicht, eine Reduzierung des Rezeptes. Daher soll das Vokabular optionale Zutaten von Obligatorischen unterscheiden können.
Des Weiteren gehören in das Rezept nicht Madeira, weißer Franzwein und Rum, sondern Madeira oder weißer Franzwein und Rum. Also muss das Vokabular alternative Zutaten abbilden können.
Erstens enhält somit genau genommen vier mögliche, unterschiedliche Rezepte. Je zwei ob die Soja verwendet wird oder nicht, sowie je zwei ob Madeira oder weißer Franzwein und Rum verwendet wird. Nach der Auszeichnung sollen daher aus den Rezepten alle möglichen Rezepte abgeleitet werden können.
In Zweitens soll nach No. 1 eine Bouillon gekocht werden. Rezept No. 1 ist jedoch nicht ein Rezept für Bouillon, sondern ein Rezept für Rindfleischsuppe, in welches das Rezept für Bouillon integriert ist . Dementsprechend soll das Vokabular Verweise auf (Teil-) Rezepte ermöglichen.
Für eine kulinarische Analyse sind offensichtlich nicht nur die Zutaten wichtig, sondern auch die Mengenangaben der Zutat, wobei eine Mengenangabe ohne Einheit wertlos ist. Daher wird im Vokabular zusätzlich eine Möglichkeit zur Auszeichnung von Mengenangaben und Mengeneinheiten benötigt.
Im Sinne des semantischen Webs ist es zudem wünschenswert, dass die Zutaten und Mengeneinheiten als weltweit frei verfügbare und eindeutige Ressourcen (mittels URIs) verstanden werden. Eine gute und anschauliche Erklärung des Begriffes semantisches Web ist in zu finden. Zu der URI einer Zutat können Nährwertangaben und Einordnungen in Taxonomien wie „ist-vegetarisch“ hinterlegt werden. Die Mengeneinheiten sind erst dann sinnvoll verwendbar, wenn Informationen zur Umrechnung in standardisierte Einheiten vorliegen; z. B. die Mengenangabe „für 8 Pfennig [...] Weißbrod“ ist ohne die Information, wie viel Gramm/Scheiben Weißbrot man nach Meinung von Frau Davidis für 8 Pfennig kriegt, wertlos. Erst die Verknüpfung beider Ressourcen ermöglicht eine transparente Extraktion von Nährwertangaben aus einer Zutatenliste.
Die zuvor vorgestellten Auszeichnungssprachen erfüllen die oben genannten Anforderungen an das benötigte Vokabular nicht, wie folgend knapp an je einem Punkt erläutert wird: TEI erhält zwar die Struktur des Rezeptes, stellt allerdings keine Vokabeln zur Verfügung, um die einzelnen Themenbereiche wie Zutatenliste oder Zubereitungs-Anweisung als solche auszuzeichnen. Schema.org/Recipe bietet zwar die Möglichkeit Zutaten als solche zu markieren, aus dem eingeschlossenen Text der Markierungen kann der Computer jedoch weder die konkrete Zutat noch die Mengenangabe mit dazugehörender Einheit ableiten. Die eigenen Vokabulare von Chefkoch.de und Cooking.nytimes.com zeichnen die bestehenden Zutatenlisten aus, welche bei unserem Kochbuch nicht vorhanden sind. Des Weiteren sind ihre Vokabulare nicht frei verfügbar und somit von uns sowieso nicht verwendbar.
Daher haben wir culinary editions Markup Language (cueML) entwickelt, was netterweise wie Kümmel auszusprechen ist. Eine beispielhafte Auszeichnung von einem Rezept aus unserem Kochbuch mit cueML ist in Abb. 2 zu sehen.
Es kombiniert und erweitert TEI und Schema.org/Recipe. Da die Transkription bereits in TEI vorliegt, ist es naheliegend TEI zu erweitern. Das Vokabular von Schema.org/Recipe übernehmen wir. So kann aus cueML für Suchmaschinen leicht zusätzlich eine Auszeichnung mit Schema.org/Recipe abgeleitet werden. Zusätzlich erweitern wir es um Attribute für Mengenangaben (quantity, bzw. atLeast und atMost) und Mengeneinheiten (unit), sowie Möglichkeiten um optionale (optional="True") und alternative Zutaten (altGrp="id" und alt="id1 id2 [...]") auszuzeichnen. Des Weiteren führen wir Möglichkeiten ein, um eine Zutat auf Bereiche des Kochbuches verweisen zu lassen (target="#id") sowie allgemeine Verweise innerhalb eines Rezeptes kenntlich zu machen (ein in Abb. 2b nicht vorhandenes ref-Element).
Einen Ressourcenbestand von Zutaten, wie in den Anforderungen beschrieben, konnten wir leider nicht finden. Daher behelfen wir uns mit dem Bundeslebensmittelschlüssel (BLS). Der BLS enthält zu knapp 15.000 Zutaten und Gerichten 38 Nährwert-Informationen wie z. B. Ballaststoffe pro 100g. An sich ist er nicht frei verfügbar, wir dürfen jedoch mit ihm im Rahmen einer akademischen Lizenz arbeiten.
Abb. 3 zeigt, wie wir den BLS in cueML integriert haben. Jede Zutat wird auf ein ingredient-Element abgebildet und das BLSref-Attribut ist ein Verweis auf den eindeutigen BLS-Schlüssel. Zusätzlich geben wir eine Liste von möglichen Lemmata für die Zutaten sowie optional ein erläuterndes note-Element an.
Einen Ressourcenbestand für Mengenangaben konnten wir ebenfalls nicht finden. Auf einen Ressourcenbestand, der Frau Davidis' Einheiten wie 1 Maß, oder für 8 Pfennig Weißbrod umrechnet, wird nicht weiter eingegangen, da das nicht Teil dieser Informatik-Arbeit ist. Unabhängig davon sei erwähnt, dass es ganz im Sinne der Programmier-Prinzipien Seperation of Concerns und DRY keine gute Idee ist, die Umrechnung in der Auszeichnung vorzunehmen. Sollte sich beispielsweise bei späteren Recherchen ergeben, dass 1 Maß nach Frau Davidis doch nicht 1l sondern 0,8l oder doch 1,2l entsprechen, müssten sämtliche ausgezeichnete Umrechnungen erneut vorgenommen werden. Bei einem Verweis auf eine URI, welche zu der Mengeneinheit 1 Maß von Frau Davidis gehört, muss nur der Eintrag bei der entsprechenden URI geändert werden. Daher übernehmen wir Frau Davidis' verwendete Mengeneinheiten.
Im Gegensatz zu Schema.org/Recipe haben wir cueML durch eine RELAX NG-Grammatik wohldefiniert. Schema.org hat die Prämisse „some data is better than none“ und validiert daher nicht gegen eine Grammatik. Für Suchmaschinen, die möglichst viele Daten erfassen wollen und die Zielgruppe der Schema.org-Vokabulare sind, ist das eine vertretbare Prämisse. Unsere Arbeitsgruppe ist dagegen der Überzeugung, dass die Validierung gegen eine Grammatik nicht schwer ist und einfache Fehler, wie beispielsweise Tippfehler verhindert. Darüber hinaus kann eine Grammatik gut als Dokumentation verwendet werden. Des Weiteren verstärkt sie die Idee des Vokabulars als Ontology.
Wir haben die Grammatik cueMLV1.0.rng mittels Roma erstellt. Das Roma-Template ist hier abrufbar. Die vollständige Dokumentation zu cueML ist hier einsehbar.