WEMI-digital

WEMI-digital#

Wie sieht WEMI aus, wenn wir nicht staubige Bücher, sondern digitale Dateien beschreiben wollen? Unser Kontext hier sind nicht beliebige Daten, sondern spezifisch Linked Open Data (LOD), RDF-Welt, Semantic Web. Frage: Wie würden wir diese Welt mit WEMI assoziieren?

Ausgangspunkte:

Zitate aus RDF 1.1:

This document [https://www.w3.org/TR/rdf11-concepts/) defines an abstract syntax (a data model) …

This specification, RDF 1.1 Concepts and Abstract Syntax, defines a data model and related terminology for use in other specifications, such as concrete RDF syntaxes, …

spezifisch 1.8 RDF Documents and Syntaxes https://www.w3.org/TR/rdf11-concepts/#dfn-concrete-rdf-syntax:

An RDF document is a document that encodes an RDF graph or RDF dataset in a concrete RDF syntax, such as Turtle [TURTLE], RDFa [RDFA-PRIMER], JSON-LD [JSON-LD], or TriG [TRIG]. RDF documents enable the exchange of RDF graphs and RDF datasets between systems.

A concrete RDF syntax may offer many different ways to encode the same RDF graph or RDF dataset, for example through the use of namespace prefixes, relative IRIs, blank node identifiers, and different ordering of statements. While these aspects can have great effect on the convenience of working with the RDF document, they are not significant for its meaning.

These: Es gibt eine Bedeutungsähnlichkeit zwischen

  • Expression und RDF abstrakter Syntax

  • Manifestation und RDF konkreter Syntax

Die RDF Spec benutzt früh und prominent den Begriff denotieren:

1.2 Resources and Statements. Any IRI or literal denotes something in the world (the “universe of discourse”). These things are called resources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with “entity” as it is used in the RDF Semantics specification [RDF11-MT]. The resource denoted by an IRI is called its referent, and the resource denoted by a literal is called its literal value.

Interessanterweise wird an keiner Weise näher erläutert, was denotieren näher bedeutet. Vermutlich bezieht sich RDF11 auf die Idee semiotisches Dreick (siehe z.B. https://de.wikipedia.org/wiki/Semiotisches_Dreieck). Was die Ecken dieses Dreiecks tatsächlich bedeuten hängt stark von der jeweiligen Theorie ab (Kritik siehe https://www.jbusse.de/dtt2023/e_triangle-of-reference.html). Um Anschlussfähig zu sein an das Terminologiemanagement der technischen Dokumentation, schließen wir uns hier an die Terminologie von Odgen und Richards (“or”) an:

https://de.wikipedia.org/wiki/Semiotisches_Dreieck#Charles_Kay_Ogden_/_Ivor_Armstrong_Richards : Nach Charles Kay Ogden und Ivor Armstrong Richards symbolisiert das Zeichen (symbol) etwas und ruft einen entsprechenden Bewusstseinsinhalt (reference) hervor, der sich auf das Objekt (referent) bezieht.[6] Das semiotische Dreieck wird wie folgt erklärt: „Umweltsachverhalte werden im Gedächtnis begrifflich bzw. konzeptuell repräsentiert und mit Sprachzeichen assoziiert. So ist z. B. das Wort „Baum“ ein Sprachzeichen, das mit dem Begriff bzw. Konzept von „BAUM“ assoziiert ist und über diesen auf reale Bäume (Buchen, Birken, Eichen usw.) verweisen kann.“.[19]

Wir hätten somit also or:Zeichen = RDF:URI, or:Bewusstseinsinhalt = ??, or:referent = rdf:referent.

Gemäß Zitat 1.2 Resources and Statements oben kann ein URI aber alles denotieren. Bezogen auf das semiotische Dreieck kann ein rdf:URI also nicht nur einen or:referent, sondern auch einen or:Bewusstseinszustand oder ein or:Zeichen denotieren. Und bezogen auf RDF selbst können wir uns die Frage stellen, ob ein bestimmter URI wie z.B. <hier_eine_ttl-Datei> nun einen abstrakten RDF-Graphen oder eine von mehreren möglichen konkreten konkreten Syntaxen (ttl, RDF/XML), mithin also eine Datei “denotiert”. Dass RDF hierzu keine Aussage macht hatte in der Semantic Web Community unter dem Titel HTTPRange-14 zu engagierten Diskussionen geführt, die von Wikipedia liebevoll als “long-running logical conundrum” (https://dict.leo.org/german-english/conundrum) bezeichnet wird:

httpRange-14 is a long-running logical conundrum or design problem in the semantic web. The problem arises because when HTTP is extended from referring only to documents to talking about real-world things (planets, flowers, emotions, Platonic forms, etc) the domain of HTTP GET becomes undefined.[1][2] […] The impact of the issue (more correctly the impact of confusion around the issue) is greatest in semantic web communities whose models involve large numbers of abstract concepts which cannot be serialised, such as the FRBR community.[8]

These: das httpRange-14-Problem lässt sich begrifflich besser diskutieren, modellieren und in der Folge auch teilweise auflösen, wenn man es mit FRBR zusammenbringt. Konkret:

  • per Konvention werden Slash-URIs (https://www.w3.org/wiki/HashVsSlash) ausschließlich verwendet, um Dateien (oder breiter verstanden Datenströme) zu denotiern, die man auf der Festplatte hat, oder die man auf eine http-Anfrage erhält. Dateien (oder Datenströme) haben mit Zugriff zu tun. Das entspricht dem Verständnis von URL aus den frühzeiten des Internets als “Locator” (“Internetadresse”) als Angabe eines Ortes, mit dem man auf eine (html-) Resource Datei zugreifen kann. Zwei Dateien sind gleich, wenn sie (z.B.) den selben sha256-Hash aufweisen.

  • Per Konvention werden Hash-URIs verwendet, um auf alle anderen Dinge zu verweisen, die keine Dateien sind.

Die RDF Unterscheidung zwischen abstrakten und konkretem Datenmodell mappen wir auf die Unterscheidung zwischen Expression und Manifestation

  • Die Expression ist eine Beschreibung eines Dings in weitestem Sinn; in RDF ein RDF Graph als abstraktes Modell

  • Die Manifestation ist die Serialisierung, die Codierung des abstrakten Modells.

  • Das Werk ist – in Anlehnung an Richards und Odgen – ein Teil eines Bewusstseinszustand

Hier wird eine Hilfs-Theorie hier erforderlich: Wir machen einen Unterschied zwischen “Realität” und “Wirklichkeit”. Klassiker hier The Matrix: Welcome To The Desert Of The Real. Realität = pysikalische Welt; Wirklichkeit = Welt der geistigen Vorstellungen, sozialen Konstruktionen, menschlicher Verstand. Es ist der Mensch mit seinem Sinnesapparat und seiner kulturellen Einbettung, der Dinge aus der Realität als soziale Wirklichkeit konstruiert, erfindet, wiedererkennt. So ziemlich alles, was in typischen Ontologien als Entität konzeptualisiert wird, sind nicht Dinge aus der Realität, sondern aus der Wirklichkeit.

Im Kontext von Linked Open Data “denotieren” Slash-URIs idealerweise spezielle Entities aus der matrix:Realität, nämlich (vereinfacht) Dateien oder technische digitale Datenströme, Hash-URIs Entitäten aus der nichtdigitalen Welt. Im Unterschied zum konventionellen semiotischen Dreieck besteht in RDF also nur zwischen Zeichen (Slash-URI) und dem Datenstrom, den ein erfolgreicher Zugriff auf eine URL erzeugt, ein direkter physikalischer Bezug zwischen Zeichen und Realität. Alle anderen Bezüge bestehen zwischen Hash-URI und gedanklichen Vorstellungen. (Besonders interessante gedankliche Vorstellungen sind übrigens die WEMI-Kategorien selbst).

  • Wir können ein Item als ein beliebiges aus vielen identischen Exemplaren verstehen, die alle die selbe (z.B. sha256-)Checksumme haben (und damit byte-identisch sind). Items in diesem Sinn sind Teil der Realität.

  • Die Menge aller identischen Items ist die Manifestation. Teil der Wirklichkeit. Ein wesentliches charakteristiches Merkmal einer Manifestation ist der Internet Media Type (aka MIME-Type) (https://wiki.selfhtml.org/wiki/MIME-Type/Übersicht). Der Medientyp definiert insbesondere die Art und Weise, wie man eine beliebige identische Kopie einer bestimmte Datei öffnet, insbesondere Syntax der Codierung und zugehörige Software.

  • Eine Expression ist ein Modell, Teil der Wirklichkeit. RDF11 definiert formal, wann zwei abstrakte RDF-Graphen identisch sind – und zwar ohne Rückgriff auf Format oder Serialisierung. Entsprechend kann man für abstrakte Graphen einen Hash definieren. Die Informatik kennt auch viele Typen von semiformalen Modelle, wie z.B. ER, BPMN, UML etc. Auch eine natürlichsprachliche Beschreibung ist ein wichtiger Typ von Expressionen.

  • Als Werk wollen wir ein Verständnis oder einen Teil von einem Bewusstseinszustand verstehen, der sich bei einem Menschen einstellt, der ein Modell liest, interpretiert, mit vorhandenem Wissen etc. verknüpft. Werke sind tyischerweise komplex und knnen nur von einem einzigen Modell und/oder Modelltyp nicht ausreichend beschrieben werden.

Beispiel: Im Laufe eines langen sozialen Prozesses entsteht in einer Gruppe von Menschen eine gemeinsame Vorstellung einer abstrakten Entität … z.B. ein Standard für die Beschreibung von Offenen Daten wie z.B. DCAT … Damit der Standard nicht nur in den Köpfen bleibt, sondern kommuniziert werden kann, muss er zum Ausdruck gebracht werden. In DCAT werden dazu verschiedene Modelle erstellt: (a) Beschreibungen in natürlicher Sprache, (b) ein formales Modell in Form einer Ontologie, (c) ein UML-Diagramm. (Jedes einzelne dieser Modelle wird dann in verschiedenen Manifestationen publiziert, z.B. als Medientyp text/html, application/pdf, text/turtle, image/svg+xml).

Immer dann, wenn ein Bewusstseinsinhalt “digital”, d.h. in einem Zeichensystem kommuniziert, zum Ausdruck gebracht werden soll, kommen vier unterschiedliche Tätigkeiten zusammen: holen, öffnen, lesen, verstehen:

  • Ein Browser (oder eine andere Applikation) verwendet eine Slash-URI, um ein entferntes Dokument zu holen und im lokalen Speicher (RAM, Festplatte) vorzuhalten. In einer Bibliothek entspricht das dem Gang zum Regal, um ein Buch zu entnehmen. Im Internet besuchen wir mit einem Browser eine Website. Wir erhalten oder erzeugen eines von vielen Byte-identischen Exemplaren desselben Dokuments, wie z.B. https://www.dcat-ap.de/def/dcatde/2.0/spec/.

  • Eine auf den Medientyp spezialisierte Applikation öffnet dieses Dokument. (Wir öffnen das Buch und stellen fest, dass wir unsere Lesebrille holen müssen, um es überhaupt lesen zu können.) Moderne Browser wie z.B. Firefox rendern freundlicherweise auch gleich die darin referenzierte SVG-Datei https://www.dcat-ap.de/def/dcatde/2.0/uml/dcat-ap-de.svg als Pixel-Bitmap, damit wir es lesen können.

  • Wir lesen den Text des Dokuments, interpretieren das UML-Diagramm (und stellen fest, dass das alles nicht zu 100 Prozent zusammenpasst): Offensichtlich verwenden die Autoren dieses Dokuments verschiedene Modelle und Modelltypen, um ihre geistige Idee angemessen auszudrücken.

  • Wir aktivieren unser Vorwissen und versuchen das Dokument zu verstehen. (Wir könnten dabei z.B. auf den Gedanken kommen, dass ein dcat:Dataset Ähnlichkeit mit unserem Verständnis eines kombinierten LRM Werk-Expression-Normdatensatzes aufweist, und dass dcat:Distribution in etwa einer kombinierten Beschreibung von LRM Manifestation und Item entsprechen könnte. Aber das ist eine andere Diskussion.)

Wir stellen fest, dass wir ein “Dokument” wie z.B. die Spec von DCAT-AP 2.0 mit IFLA LRM sehr detailliert beschreiben können. Das überrascht uns aber nicht, weil IFLA LRM ja genau für diesen Zweck entwickelt wurde.

Unsere eigentliche Frage lautet ja: Wir gut und mit welchem Aufwand lassen sich auch Datensätze aus der RDF-Welt, insbesondere Linked Open Data mit IFLA LRM oder WEMI beschreiben?

Gedankenexperiment Wetter-Daten, Belegungsdaten von Parkhäusern#

  • Werk wäre die Idee “Wetter”. Wetter lässt sich auf vielerlei Weise modellieren. Es bietet sich ein Datenschema mit dem zusammengesetzen Primärschlüssel Zeitstempel, Längen- und Breitengrad, Höhe über NN, sowie den Messdaten Windrichtung- und Stärke, Temperatur, Feuchtigkeit, Ozongehalt, Verschmutzung etc.

  • Dieses Schema beschreiben wir normalsprachlich, liefern ein UML-Diagramm und eine OWL-Ontologie hinzu; wir erhalten damit einige unterschiedliche Modelle, die sich teilweise ergänzen, teilweise konkurrieren (z.B. in Bezug auf die “Vererbung” und den “Besitz” von “Attributen”, die in UML eine prominente Rolle spielt, aber in OWL weitgehend sinnfrei ist). Unter anderem verlangen wir, dass Wetterdaten gemäß dem UML-Schema im Format CSV angeliefert werden (das man als eine anwendungsspezifisches konkretes Datenmodell interpretieren kann.)

  • Messstationen liefern uns weltweit Daten, die von verschiedenen Akteuren z.T. statisch als CSV-Dateien, teils über SPARQL-Endpoints dynamisch als Ort-Zeit-konfigurierbare Zeitreihen (incl. Echtzeitdaten) zur Verfügung gestellt werden.

Mit WEMI können wir dies so interpretieren:

  • Die geistige Vorstellung, die menschliche kulturelle Konstrution “Wetter” besteht aus dem Teilwerk “Schema” (in der Welt des Semantic Web die Terminologie, die TBox) und dem Teilwerk “Daten”. Das Teilwerk “Schema” können wir strukturgleich wie obiges Beispiel DCAT mit WEMI interpretieren. Interessant sind die Daten (in der RDF-Welt sind das die Assertions, die ABox). Mit WEMI sprechen wir hier von einem einzigen (!) Werk “Wetterdaten”.

  • Die geistige Idee “Wetter” findet in einer einzigen (!) Expression ihren Ausdruck, nämlich der hypothetischen gedanklichen Vereinigung aller Wetterdaten weltweit zu allen Zeiten.

  • Entsprechend können wir auch eine hypothetisch-gedankliche “große” Manifestation aller CSV-Dateien konstruieren, die freilich in ihrer überwältigenden Gesamtheit nie vorliegt. Was aber vorliegt sind sehr viele einzelne CSV-Datenpakete, die man in WEMI als Teil-Manifestationen dieser großen Manifestation interpretieren kann.

  • Ein einzelnes CSV-Datenpaket kann man downloaden oder kopieren oder durch eine Datenbank-Anfrage erzeugen und lokal vorhalten: Man erzeugt so ein neues Item desselben Datenpakets. Diese Datenpakete können statisch als Datei vorliegen, oder durch eine Online-Abfrage auf einen SPARQL-Endpoint dynamisch erzeugt werden.

“Wetter” ist ein paradigmatisches Beispiel, wir erwarten im Diskurs von Linked Open Government Data keine Wetterdaten. Wohl aber können wir z.B. Daten erwarten zur aktuellen und historischen Belegung von City-Parkhäusern. Die WEMI-Modellierung einer Parkhausbelegung entspricht 1:1 der Modellierung des Wetter-Datensatzensatzes. Ich habe dazu mal eine Abschlussarbeit ausgeschrieben: https://www.jbusse.de/pub/projektideen.html#govdata-parkhausbelegung

Contents