Konglomerate (DE)

An einem didaktischen Beispiel wollen wir folgendes ganz alltägliche Phänomen genauer analysieren: (1) Wir haben ein Ganzes, das mehr ist als die Summe seiner Teile. (2) Einer der Teile gibt dem Ganzen seinen Namen, andere relevante Teile werden nicht explizit erwähnt. (3) Das Ganze wird durch Eigenschaften beschrieben, die genau genommen nur für jeweils einzelne Teile sinnvoll anwendbar sind.

Zum Beispiel “verpackte Milch”: Im Kühlschrank ist keine Milch mehr; wir gehen in den Supermarkt und kaufen einen Liter Bauernglück H-Milch 1.5% Fett Tetrapack; voila, unser Kaffe schmeckt wieder!

Was passiert hier? Wir reden davon, Milch zu kaufen. Tatsächlich kaufen wir aber nicht Milch, sondern ein alltägliches Handelsgut “verpackte Milch” als ein Ganzes. (1) Dieses Ganze stammt nicht von Kühen, sondern von der Firma “Bauernglück”, und wird durch seine 13-stellige EAN-Nummer identifiziert. (2) Das Handelsgut besteht aus Verpackung und Inhalt. Es ist dieser Inhalt “Milch”, der wesentlich zur Benennung des Ganzen beiträgt. (3) In der Datenbank wird dieses Ganze u.a. auch durch Eigenschaften wie Fettgehalt, Pasteurisierung, Verpackungshersteller beschrieben, die genau genommen nur für jeweils einzelne Teile sinnvoll sind. Wir haben dieses Phänomen in unserem Workshop experimentell ein Konglomerat genannt: Ein Ganzes, das auch durch die Eigenschaften seiner Teile beschrieben wird.

Übrigens sind Redeweisen wie “ist Teil von” oder “besteht aus” metaphorisch. “Verpackte Milch” als ein Handelsgut ist kein physikalisches Objekt, das physikalische Teile haben kann. Eine genaue Modellierung würde von so etwas wie einem “assoziierten Bestandteil” reden.

Sobald wir an dem didaktischen Beispiel der verpackten Milch das Phänomen des Konglomerats genauer verstanden haben, entdecken wir es auch in anderen Kontexten der semantischen Modellierung. Vielleicht das prominenteste Beispiel ist die Dublin Core Initiative. 1995 einigte man sich auf einer Konferenz in Dublin/Ohio darauf, (Web-) Dokumente durch 15 core elements zu beschreiben, u.A. Titel und Autor, Creator, Sprache, Format etc. Etwa zeitgleich entwickelte sich Bibliothekaren ein gemeinsames Verständnis, dass sich Bücher aus gänzlich unterschiedlichen abstakten Dingen zusammensetzen: Werk, Expression, Manifestation und Item (WEMI).

In unserem Workshop identifizierten wir ein Dublin Core Dokument als ein Konglomerat mit den assoziierten WEMI-Teilen. Das Werk als eine rein geistige Leistung hat einen Titel und einen Autor. Die Expression drückt eine geistige Leistung als ein Mosaik von Symbolen, als “Text” in weitestem Sinne aus. Wichiges Kennzeichen ist die Sprache oder das abstrakte Datenmodell: DE, EN, RDF, UML, BPMN etc. Übersetzungen, andere Modellierungsparadigma erzeugen neue, sich insgesamt ergänzende Expressionen desselben Werkes. Eine Manifestation codiert eine Expression technisch, sie hat ein Format. Ein gedrucktes Buch, das pdf oder die textgleiche html-Website sind unterschiedliche Manifestationen derselben Expression; typische Kennzeichen sind ISBN, URI oder DOI. Ein Item ist ein anfassbares Buch im Regal oder eine für uns zugängliche konkrete Datei auf der Festplatte.

Wir haben im Workshop eine eigene Konzeptualiserung der WEMi-Klassen angedacht: Werk = geistige Vorstellung, Idee; Expression = logisches Modell als eine Mosaik von Zeichen, “Dokument” ; Manifestation = Codierung einer Expression in einem bestimmten Format “Datei”; Exemplar = eine Byte-Zeichenkete in einem digitalen Speicher, auf die wir zugreifen und sie “öffnen” können.

Dies ist nur eine von vielen denkbaren Charakterisierungen. Aus unserer Interpretation folgt, dass die WEMI-Klassen ontologisch grundlegend verschiedene Dinge sind, und eine Klassen-Disjunktheit ähnlich wie owl:AllDisjointClasses ein zentrales Merkmal unserer WEMI-Konzeptualisierung ist. Interessant: Mit Datum 2024-08-02 veröffentlichte dublincore.org auf seiner Homepage ein OpenWEMI-Modell, das WEMI als Rollen interpretiert und der Klassen-Disjunktheit explizit eine Absage erteilt – eine Entscheidung, die wir nur schwer nachvollziehen können.

Die Vertrautheit mit WEMI lässt uns ein Dublin Core Dokument als ein Konglomerat erkennen. Ein einzelner DC-Datensatz kann in WEMI überführt werden, indem für Werk, Expression, Manifestation und Item jeweils ein neuer “assoziierter” Datensatz angelegt wird. Wie die Attribute des ursprünglichen Datensatzes auf diese neuen Datensätze zugeordnet werden hängt von zur Verwendung kommenden WEMI-Ontologie ab und könnte z.B. so aussehen (mit @prefix dc: "http://purl.org/dc/elements/1.1/"): dc:author und dc:title zu wemi:work; dc:language und dc:creator zu wemi:expression; dc:format zu wemi:manifestation; sowie dc:acces_URL zu wemi:item .