Metadaten vs. Aboutness
Contents
Metadaten vs. Aboutness#
https://de.wikipedia.org/wiki/Metadaten : “Metadaten oder Metainformationen sind strukturierte Daten, die Informationen über Merkmale anderer Daten enthalten. Bei den durch Metadaten beschriebenen Daten handelt es sich oft um größere Datensammlungen wie Dokumente, Bücher, Datenbanken oder Dateien.”
Interpretation JB: Daten werden oft in Containern (Dokumenten, Seiten, Tabellen, umfangreichere XML-Elemente, Named Graphs etc.) vorgehalten und organisiert, die selbst als Objekte mit IRI in Erscheinung treten, z.B. obige Wiki-Seite http://www.waschknecht.de/wiki/Superclean2000/Waschmittelrückstände.html :
Das Dokument tritt selbst als Entität, nämlich als Dokument vom Typ Container in Erscheinung
auch über den Container selbst kann man Aussagen machen: Autor(en) der Seite, Bearbeitungsstatus, letzte Datensicherung etc.
iirds: Information unit lifecycle status
Metadaten sind dann - relativ zu den Daten, die in diesem Container enthalten sind - Daten, die den Container selbst beschreiben.
Was Daten und was Metadaten sind ist relativ. Ein Beispiel:
Der digitale Zwilling unserer Waschmaschine technisch möglicherweise als eine Datenbank realisiert. Aus Perspektive eines Waschmaschinen-Wartungstechnikers, der aus der Datenbank Teile-Laufzeiten abruft um zu entscheiden, ob ein Teil ausgewechselt werden muss, sind Angaben über die Datenbank selbst (wie z.B. die letzte Datensicherung) Metadaten.
Aus Sicht der Datenbankadministratorin sind Daten über die letzte Datensicherung Objekt-Daten, die sie aus den Protokolldateien wieder abrufen kann - wobei die Größe der Protokolldateien (Metadaten!) in
/var/logfür die Linux-Systemadministratorin wichtige Objekt-Daten zur Berechnung der freien Plattenkapazität sind.
Zusammengefasst:
Was Daten und was Metadaten sind, hängt vom Standpunkt des Betrachters ab
Als Faustregel gilt: Metadaten beschreiben meistens Sammlungen, Container von Daten. (Semantic Web community: Named Graphs, d.h. Erweiterung des Datenmodells auf ein Viertupel
Kompliziert wird es, wenn Daten in Containern selbst wieder Container beschreiben.
Was sind also Metadaten? Ganz normale Daten, die allerdings spezifische Entitäten beschreiben, nämlich Container von Daten. Der Fokus auf Container entspricht einer Fokussierung auf eine Domäne: Nicht CAD–Daten, nicht Messdaten, nicht Maschinen-Daten, sondern Container-Daten. Metadaten sind ganz normale Daten in der Domäne der (Daten-) Container. Typische Daten, die in Bezug auf Container interessant sind, sind, z.B.:
Autor, Erstellungsdatum, letzter Zugriff, Zugriffsrechte etc.
Versionierungsdaten
Daten über Format, Struktur etc.
Daten aus dem Redaktions-Zyklus: Skizze, proposed, in Revision, publiziert, zurückgezogen etc.
Exkurs: Sind (Objekt-) Modelle Metadaten?#
Auch können Daten interessant sein, die den Inhalt eines Container erschließen:
Auf welches Sachgebiet beziehen sich die Daten, die in dem Container liegen, der mit den Metadaten beschrieben wird?
Was wird über dieses Sachgebiet ausgesagt? In der Bibliothekswissenschaft könnte das z.B. in Form eines indikativen Abstracts mitgeteilt werden, in Semantic Web könnten das Begriffe aus einem kontrollierten Vokabular sein.
Man kann darüber streiten, ob solch eine auf ein Sachgebiet bezogene Inhaltserschließung als Metadaten bezeichnet werden sollen:
Tatsächlich sind das ja keine Daten, die einen Container beschreiben, sondern Daten, die ein Sachgebiet beschreiben.
Eigentlich will man solche Daten nicht in einen Metadaten-Standard mit einbeziehen, da sonst beliebige Sachgebiets-Terminologien in den Metadaten-Standard einfließen und diesen damit beliebig entgrenzen.
In iirds dürfen (sollen) auch vereinfachte Objekt-Modelle enthalten sein:
“iiRDS models products and components as metadata for technical documentation”
6.7.1 “Component Trees in the Package”: “An iiRDS package MAY model a component tree”: Davor würde ich warnen.
“6.7.2 External Product Ontology: […] A proprietary iiRDS extension MAY map the metadata labels in the package to the external product ontology.”
“An iiRDS package MUST NOT use an external product ontology directly. If an external product ontology is available and used in the iiRDS package, then the iiRDS package MUST also contain metadata labels as instances of iirds:Component. “
Fig 3 “Figure 3 Mapping of external product ontology”: Hier wird also eine Schatten-Struktur erzeugt.
Besser wäre es ggf, die Inhaltserschließung eines durch einen Container adressierten Sachgebiets selbst wieder in einem Container zusammenzufassen, und diesen z.B. mit geeigneten Metadaten auf unseren ursprünglichen Container zu beziehen?
Was wird durch einen URI identifiziert?#
Wir haben URIs:
URI: Ein Identifikator von einer speziellen Form, siehe Wikipedia > URI
Beipiel für einen URI: https://de.wikipedia.org/wiki/Waschmaschine. Die Frage ist: Was “identifiziert”, was “bezeichnet” dieser URI? Ein URI identifiziert eine Ressource - und das ist alles, was man in weitestem Sinn als “Ding” bezeichnen kann: Eine Waschmaschine, ein einzelner Waschgang, ein Erlebnis von Duft und Frische, der Werbespruch “Weißer als Weiß!”
“””the term “resource” is used in a general sense for whatever might be identified by a URI. […] A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship …””” (https://datatracker.ietf.org/doc/html/rfc3986.html)
Identifier#
Wir wollen gleichzeitig über Ressourcen, ihre Identifikatoren und ihre Inhalte reden.
Wenn wir eine Zeichenkette als URI verstehen wollen, setzen wir sie in spitze Klammern:
<https://.../Waschmaschine>. Ein Markdown2html-Compiler wird daraus einen Link generieren, hier: https://de.wikipedia.org/wiki/Waschmaschine. Wenn wir ganz explizit sein wollen, verwenden wir das Prädikathref(), also z.B.href("https://.../Waschmaschine").Wenn wir über die Erscheinungform des URI, also die Zeichenkette selbst reden wollen, setzen wir diese in Anführungszeichen, z.B. “https://de.wikipedia.org/wiki/Waschmaschine”; und/oder wir verwenden explizit das Prädikat
string(), also z.B.string(<https://.../Waschmaschine>).
(Nebenbei: string und href verhalten sich zueinander als Umkehrfunktionen:
string(href("..."))ist das gleiche wie"..."href(string(<...>))ist das gleiche wie<...>. )
Container#
In unserem Beispiel ist die Ressource, die durch den URI <https://de.wikipedia.org/wiki/Waschmaschine> identifiziert wird, eine Datei, d.h. ein Container für aneinandergereihte Zeichenketten.
Die Unterscheidung von Aussagen über den Container selbst (Container als Black Box) versus Aussagen über den Inhalt des Containers (Container als Glass Box) ist fundamental, wird aber oft nicht klar gesehen. Wir wollen sie explizit handhabbar machen:
Ein URI identifiziert den Container als Black Box
das Prädikat
content(URI)gebe uns den Inhalt eines Containers in die Hand, z.B. einen Stream von Zeichen oder Zeilen, semistrukturierte Date wie z.B. eine Markdown-Datei, oder auch hoch strukturierte Daten wie z.B. eine Excel-Tabelle.
Wir können nun Aussagen treffen über den Container an sich, der durch den URI identifiziert wird (Container als Black Box):
z.B. Größe und Autor des Containers, Datum der letzten Änderung etc.
z.B. dass es eine Markdown- oder html- oder XML-Datei ist; oder ein zip-Archiv, das seinerseits wieder Dateien enthält, etc.
Eigentlich sollte der URI selbst ausreichen, einen Container zu identifizieren, denn ein URI identifiziert eben eine Ressource, im Fall einer Datei genau die Datei als Container. Aber wenn wir ganz explizit werden wollen, können wir hierfür das Prädikat container(URI) verwenden, und es gilt container(URI) == URI
Wir können aber auch Aussagen treffen über den Inhalt des Containers, der durch content(URI) erhältlich ist (Container als Glass Box): Was dürfen wir erwarten, wenn wir in den Container hineinschauen?
Falls wir - wie bei
content(href("https://de.wikipedia.org/wiki/Waschmaschine"))der Fall - auf einen menschenlesbaren Text blicken, dann ist es üblich, diesen Text zu interpretieren und Auskuft geben zu wollen, was das Thema des Textes ist.Dieser Aspekt wird im Bibliotheks-Fachjargon Wikipedia > Aboutness genannt, Prädikat:
aboutness(URI)
Die Aboutness des Wikipedia-Artikels https://de.wikipedia.org/wiki/Waschmaschine sind nicht nur um Waschmaschinen als technisches Gerät, sondern auch die Geschichte der Waschmaschine, Keime und Verunreinigungen, uns sogar die Waschmaschine im deutschen Mietrecht.
Zwischenstand#
Wir haben Identifizierendes:
der URI selbst
<https://de.wikipedia.org/wiki/Waschmaschine>die String-Repräsentation
string(<https://de.wikipedia.org/wiki/Waschmaschine>): “https://de.wikipedia.org/wiki/Waschmaschine” des URIsdie (hier) Web-Adresse, an der ein Container zum Download bereitsteht:
href(string(<https://de.wikipedia.org/wiki/Waschmaschine>))
Und wir haben Identifiziertes:
der durch den URI selbst identifiziere Container selbst, hier die html-Datei:
container(URI)der Inhalt (EN: content) dieses Containers als Zeichenkette, hier rund 213.000 (!) ASCII-Zeichen (Stand Okt 2021):
content(URI)die Aboutness des Containers, hier u.A. auch Waschmaschinen im deutschen Mietrecht:
aboutness(URI).Und nicht zuletzt haben wir die Struktur des Inhalts des Containers:
structure(URI)(s.u.)
Struktur#
Als Autor von umfangreichen Texten wollen wir bisweilen auch Auskunft geben über die Struktur der Inhalte der Datei, die wir über einen URI referenzieren. Im Fall von umfangreicheren Dateien wie unserer Wiki-Seite zur Waschmaschine gibt das eingebettete Inhaltsverzeichnis einen groben Eindruck über diese Struktur, wie das ja auch bei pdf-Dateien oft der Fall ist.
Um per URI referenzierbar zu werden, muss ein Inhaltsverzeichnis explizit als Datei vorliegen. Im Web-publishing hat sich hier die Idee der sog. Wikipedia > Sitemap durchgesetzt - die streng genommen kein Inhaltsverzeichnis ist, sondern umfassender als Baum aller an einer Website beteiligten Dateien darstellt.
Als Struktur einer URI wollen wir das Inhaltsverzeichnis oder die Sitemap-Datei bezeichnen, in denen die URI als Teil aufgeführt ist.
Dokument#
Was ist ein Dokument?
Im Fall der Wiki-Seite zur Waschmaschine können wir “Dokument” mit “Datei” identifizieren.
Auch die pdf-Version des scikit-learn user guide (Release 0.21.3, Jul 29, 2019) enthält ein Inhaltsverzeichnis, das die insgesamt 2497 kleingedruckten pdf-Seiten allerdings nur oberflächlich erschließt.
Der scikit-learn user guide interessiert uns im folgenden besonders: Während bei der pdf-Version “Dokument” und “Datei” identisch sind, besteht die Web-Version https://scikit-learn.org/ aus sehr viele Einzeldateien. Auch die Web-Version ist als Datei erhältich, nämlich als zip-File: https://scikit-learn.org/dev/versions.html -> “Scikit-learn 1.0 (stable) documentation (ZIP 57.8 MB)”.
Die Frage lautet also immer noch:
Was ist ein Dokument, wenn wir “Dokument” nicht mit “Datei” identifizieren wollen?
Pragmatischer Antwortversuch: Ein Dokument ist
z.B. eine zip-Datei,
die viele Einzeldateien enthält,
die sich z.B. im Web als Website navigieren lassen,
die sich durch eine geeignete Software im Prinzip zu einem mehr oder weiger konventionellen Print-Dokument zusammenbauen lassen.
Das charakteristische Merkmal, das eine Anzahl einzelner Dateien zu einem Dokument werden lässt, ist die Strukturinformation,
wie die einzelnen Dateien z.B. im Web als einheitliche Website navigiert werden können, und
wie diese Website im Prinzip zu einer pdf-Datei zusammengebaut werden könnte.
Andere existierende Beispiele für ein Dokument sind:
LibereOffice-Dateien folgen der Wikipedia > OpenDocument technical specification und sind faktisch eine zip-Datei. Ausprobieren: Endung
.odtin.zipändern, auspacken, gucken was ‘drinn ist!
Wir haben hier ein konservatives Verständnis von “Dokument”, das sich sich an der Idee einer Druckfassung als pdf orientiert, die im Prinzip hergestellt werden könnte. Der pdf-Aufsatz oder das pdf-Buch werden damit zu einem regulativen Ideal, das faktisch gar nicht existieren muss, aber immerhin als Leitidee funktioniert für:
Reihenfolge
Gliederung durch hierarchische Überschriften
Erschließung und Navigation durch ein Inhaltsverzeichnis, das die Hierarchie spiegelt
verschiedene Verzeichnisse: Abbildungen, Tabellen, Stichworte, Autoren, Quellen etc.
Zusammenhang URI und Dokument#
Der Zusammenhang von URI und Dokument könnte dieser sein:
URIs identifizieren technisch gesehen Dateien, mithin also Container.
Öffnet man einen solchen Container, so kann dieser enthalten:
Daten, Zeichketten, an denen wir eigentlich interessiert sind, und die wir interpretieren wollen;
wiederum viele Dateien / Container enthalten, die im Prinzip wiederum über einen URI identifizierbar sind.
Einen Container, der Information enthält, wie man aus seinen vielen einzelnen Dateien im Prinzip eine druckbare pdf-Datei erzeugen kann, wollen wir als Dokument bezeichnen.
Ein URI, der eine html-Datei referenziert, referenziert also ein “Dokument” wie z.B. einen Aufsatz, ein Buch, einen Flyer, eine Partitur,
wenn der URI als Einstieg in eine gut navigierbare Website dienen kann,
es aber auch genügend Informationen gibt, wie man aus den einzelnen Dateien ein druckbares pdf-Dokument herstellen könnte - typischerweise ein Inhaltsverzeichnis, eine previous-next-Navigation etc.
Kontext dieser Diskussion
Superclean 2000#
Diskussion im Folgenden auf Basis des Beispiels https://www.empolis.com/blog/digitale-transformation/content-delivery-was-ist-das-eigentlich/ (zuletzt abgerufen April 2022).
Wir wollen in Anlehnung an obiges Beispiel über Objekte aus verschiedenen “Sachgruppen” sprechen:
Es gibt eine Waschmaschinen-Baureihe Superclean2000 vom Hersteller www.waschknecht.de.
Die Superclean2000 gibt es ohne und mit Heißwasserzulauf.
Es gibt eine konkrete, in einer Großwäscherei aufgebaute Waschmaschine mit einer eindeutigen Seriennummer sprechen, z.B. Superclean2000_337.17.06.2015_HW (HW … mit Heißwasserzulauf).
Eine Bedienungsanleitung für Maschinen der Reihe Superclean2000, die vor Ort als pdf und auf Papier ausgedruckt vorliegt.
Eine Datenbank, in der alle Textbausteine vorliegen, die in allen Gebrauchsanleitungen der Superclean2000 vorkomen.
Insbesondere wird auch das Glossar, das alle Fachbegriffe aus der Waschmaschinen-Wisssenschaft und -Praxis enthält, in solchen Textbausteinen vorgehalten.
In sogennannten TOC- (Table Of Content-) Dateien wird statisch definiert, welche ausgewählten Textbausteine wie zu einer als Handbuch strukturierten pdf-Gebrauchsanleitung zusammengefügt werden.
In Zukunft sei gewünscht, einzelne Abschnitte der Gebrauchsanleitung nicht mehr als pdf-Dokumenmt, sondern online als html-Dokumentation bereitzustellen.
Wir stellen uns im folgenden vor, dass die Textbaustein-Datenbank ein Wiki ist. (Industriestandard ist Confluence, aber spezifisch für technische Dokumentation (TD) bietet sich eher ein XML-basiertes oder auch ein Semantisches Wiki an.) In diesem Wiki wird die Bedienungsanleitung Topic-orientiert kollaborativ gepflegt. Für jeden Maschinentyp kann eine entsprechende Druckfassung exportiert werden.
Ein Teil dieses Wiki ist nach einer Basis-Authentifizierung öffentlich einsehbar und wird nicht nur von Kunden, sondern - neben anderen Quellen - auch vom Kundendienst und dem Call Center genutzt. In diesem Wiki gibt es insbesondere diese Seiten:
http://www.waschknecht.de/wiki/Superclean2000_337.17.06.2015 (diese Seite ist nur für Servcetechniker einsehbar)
Um bei einem geeigneten Fehlerbild diese Seiten systematisch zu finden, gilt eine Facetten-Navigation als Stand der Technik. Üblicherweise wird in den einzelnen Facetten mit “Bäumen” von Begriffen gearbeitet, z.B.
Fleck (SYN: Schmutz)
Waschmittelrückstand
Während Facetten-Navigationen Objekte mit Filter und Drilldown eingrenzen, lassen sich auch viel komplexere Systeme denken, um - hier am Beispiel von Fehlerbildern - relevante Wiki-Seiten zu identifizieren.
Insbesondere wird im industriellen Umfeld relevant der sog. “digitale Zwilling” unserer Superclean2000_337.17.06.2015_HW - jedenfalls dann, wenn wir annehmen, dass wir eine Wäscherei sind, und nicht die Waschmaschine gekauft haben, sondern einen Dienstleistungsvertrag über eine bestimmte Waschleistung geschlossen haben.
Dieser digitale Zwilling enthält alle Daten, die z.B. für die Wartung unserer konkreten Maschine relevant sind.
Auch die spezifischen Daten zu unserer konkreten Maschine sind natürlich eine 1a Quelle, um im Waschknecht-Wiki für unseren Fehler relevante Informationen zu finden: Vielleicht wurde ja einfach bei einer Wartung übersehen ein Teil auszutauschen?
Als Büro für TK erhalten wir vom Hersteller viele Daten:
Konstruktions-, CAD-Daten etc. von Maschinen des Reihe Superclean2000
Von den Entwicklern fachlich tiefgehende, aber aus Sicht der TR noch nicht dokumentationskonforme Beschreibungen von Wartung etc.
ggf. auch Laufzeit- und Wartungs-Daten der konkreten Superclean2000_337.17.06.2015_HW als sog. digitaler Zwilling der Maschine
Unser Job:
Wir wollen eine normkonforme und systematisch erschließbare Dokumentation der Superclean2000 erstellen - und zwar mit dem o.a. Wiki als Redaktionssystem.
Wir erstellen nicht nur den natürlichsprachlichen Text der Doku, sondern fügen der Doku auch maschinenlesbare Daten hinzu - mit dem Ziel, dass einzelne (bei uns: Wiki-) Seiten der Doku nicht nur z.B. über Volltextsuche, sondern auch über eine Facetten-Navigation oder ein komplexeres Content Delivery Portal gezielt abgerufen werden können.
Für dieses Abrufen sind z.B. relevant:
allemeine Informationen über Maschinen der Reihe Superclean2000: Technischer Aufbau, Installation, Wartung, Fehlerbehebung, Entsorgung etc.
falls verfügbar idealerweise: Informationen, die sich auf unsere konkrete Superclean2000_337.17.06.2015_HW beziehen … digitaler Zwilling
Information über unsere Qualifikation als Nutzer: Bestimmte Fehlerbehebungen sind dem Wartungspersonal vorbehalten, andere können wir als Laien selbst vornehmen.
Information über die Sprache(n), in der wir die Doku lesen wollen
Informationen über die Qualität der Doku, die wir erwarten: Für Enduser nur qualitätsgesicherte, freigegebene Seiten, oder für Wartungstechniker auch in Arbeit befindliche Informationen - zu denen er im Wiki ja vielleicht regelmäßig selbst schreiben beiträgt?
iirds:ContentLifecyleStatus
Container#
Welche Objekte haben wir - und wie beschreiben wir sie?
die spezielle Maschine Superclean2000_337.17.06.2015_HW als digitaler Zwilling; digitales Modell der speziellen Maschine
Ein digitales Modell ist typischerweise ein hoch strukturierter technischer Datensatz, z.B. als XML-Datei, Datenbank etc.
Aber wir haben auch klassische Texte:
textuelle Dokumentationen von Maschinen der Baureihe Superclean2000: Zielgruppenspezifische Beschreibung (Anwender, Wartungstechnikerin etc.) durch komplexe Texte, die als Mosaik von einzelnen Text-Bausteinchen zusammengesetzt ist. (Die Inhalte der Doku sind vielfältig: Beschreibung der Maschine, Wartung, Fehlerbeiseitigung, erforderliche Sicherheitsmaßnahmen und Schulungen - also im Prinzip alles, was gesagt werden kann.)
die einzelnen (Bau-) Steinchen der Doku, typischerweise Abbildungen, Formulierungen und forgefertigte Textbausteine, sowie intellektuell generierte informative Abschnitte im Text
ein Mosaik: welche Steinchen sind enthalten, und wie werden sie zum jeweiligen Mosaik zusammengesetzt?
Ziel: Erzeuge ein Einzel-Mosaik für unsere speziellen Maschine Superclean2000_337.17.06.2015_HW:
Spezialisierung der allgemeinen Dokumentation der Baureihe
zielgruppenspezifisch!
incl. Beschreibung von speziellen Teilen, Konfigurationen etc.
ggf. mit eingebetten Daten aus dem digitalen Zwilling (Laufzeit, letzter Ölwechsel, Austauschmotor etc.)
Die Herausforderung liegt im X-Media-Publishing, und zwar just in time:
Im Idealfall soll solch ein Mosaik als Ergebnis einer User-Interkation erzeugt, gebrowst und verfeinert werden können - und zwar online, just in time.
Jedes einzelne Mosaik soll zuerst online als html-Version zugänglich sein, dann aber auch als pdf heruntergeladen und archiviert werden können.