digital WEMI (dWEMI)

digital WEMI (dWEMI)#

Dieses Dokument:

  • 2025-07: Sammlung von Theoriebzügen, die für ein dWEMI relevant sind; noch wenige Klärungen; inbesondere noch keine Formalisierung in OWL

Digital WEMI

  • erweitert die Ideen Werk, Expression, Manifestation und Item (kurz: WEMI) vorsichtig so, dass FRBR WEMI auch auf Entitäten aus der digitalen Welt besser anwendbar ist

  • interpretiert in Bezug auf WEMI insbesondere im Detail die Spezifikationen

  • ersetzt die Konzepte aus FRBR Gruppe 2 und Gruppe 3 durch Bezugs-Ontologien wie SKOS und PROV-O

  • fügt einige wenige andere Bezugs-Ontologien hinzu, wie z.B. Ontolex LEMON oder DCAT-AP.de Spezifikation 3.0

  • desambiguiert verschiedene Lesarten des polysemen Begriffes “Datensatz”, und ordnet die verschiedenen Lesarten insbesondere folgenden Spezifikationen zu:

dWEMI ist eine Theorie: intendierter Anwendungsbereich?

  • begriffliche Aufklärung des httpRange-14 Problems

  • erlaubt Abbildung von DCAT-AP nach RDA und damit das etablierte Bibliothekswesen

  • Beitrag zur digitalen Semiotik

Grundlagen

  • Kurzfassung von WEMI: Karen Coyle: Works, Expressions, Manifestations, Items: An Ontology; siehe auch ausführlich das sehr kenntnisreiche Buch von Karen Coyle: FRBR, Before and After: A Look at Our Bibliographic Models;

  • zutiefst philosophisch, hier nur literarisch andeutbar, aber an einer Stelle wichtig ist der fundamentale Unterschied zwischen Realität und Wirklichkeit: “Welcome in the desert of the real” Realität vs. Wirklichkeit

    • Wo wird das wichtig? Der Item-Aspekt denotiert Entitäten der Realität, nämlich Datenströme, Messages, Dateien; die Aspekte WEM denotieren Entitäten der Wirklichkeit

  • digital WEMI Zusammenfassung: Die grundlegende Idee … die Klassen sollten “im Kern” verstanden sein, Graubereiche und Abgrenzungsschwierigkeiten kann man später verhandeln

    • klar machen: die WEMI-Klassen sind Ergebnis einer Normalisierung

    • Rückblick FRBR- etc. WEMI (FRBR, FRIR, CIDOC, FRBRoo, RDA); auch FRIR

  • Datenbank-Normalisierung

Im Detail

  • URI RFC3986, andere

    • insbesondere auch Fragment Identifer: abhängig vom Mime-Type … Doppelfunktion: Hash-Uri denotiert in RDF eine vor allem auch abstrakte Entity, in fast allen anderen Fällen ein Syntax-Fragment

  • RDF im Detail, mit großer Ausführlichkeit

    • Resource, Literal, Blank node … referenzieren, referent; denote

    • dereference, describe

    • abstract syntax, concrete syntax

    • RDF dataset: a set of abstract RDF graphs; graph name vs. graph IRI

    • LOD, FAIR, 5star

  • Prov-O: Entity, Akteur, Activity

    • Mapping the W3C Provenance Ontology (PROV-O) to the Basic Formal Ontology (BFO): Epistemological Considerations and Preliminary Implementation Mapping the W3C Provenance Ontology (PROV-O) to the Basic Formal Ontology (BFO): Epistemological Considerations and Preliminary Implementation

    • Auch Ansatz von CIDOC: Keine Entity ohne zugehörigen Prozess

Realität vs. Wirklichkeit#

Realität: physische Welt, Welt der Naturwissenschaften; Wirklichkeit: Konstruktionen des Geistes, Welt der Geisteswissenschaften; Sozial- und Geisteswissenschaften, auch Kunst, Spiritualität, … auch die Unterscheidung zwischen Realität und Wirklichkeit selbst ist zwar nicht real (denn die pyhsikalische Welt denkt nicht), aber immerhin wirklich die Verbindung von Geist, Wirklichkeit und Realität ist eines der großen Rätsel der Philosophie … möchte ich weiterhin als Rätsel behandeln, nicht versuchen, mit naturwissenschaftlichen Theorien zu erklären.

Morpheus: this is the construct … it’s our loading program … we can load everything your appereance now is what we call the visual self image …. it’s the mental projection of your digital self … Neo: this it is real … Morpheus: What is real? How do you define real? … you’ve been living in a dream World, Neo … this is the world as it exists today … Welcome to the desert of the real. (https://www.youtube.com/watch?v=EVM5-_fusjs, https://www.youtube.com/watch?v=O5b0ZxUWNf0, https://www.youtube.com/watch?v=buz7P6oKvDY)

relevant für uns: eine URI kann alles bezeichnen … allermeistens sind das Entitäten der Wirklichkeit, mit einer einzigen, aber im Kontext der Digitalisierung mit einer alles entscheidenden Ausnahme: Eine URI kann auch Reihen aus höherer und geringerer elektrischen Spannung bezeichnen: eine physikalische Datei, einen physikalischen Datenstrom. Computer sind reale Maschinen, die Datenströme auf Basis anderer Datenströme in weitere Datenströme umarbeiten … eine “Information Resource”

digital WEMI Zusammenfassung#

Ein Dokument ist in etwa das, was in einem LitVerzeichnis verzeichnet wird … daran beteiligt sind verschiedene Rollen/Akteure: Autor, Verfasser (Writer), Schriftsetzer, Drucker, Verkäufer, Altpapiersammler … entsprechend gibt es auch verschiedene Aktivitäten rund um Dokumente … Ein Dokument ist eine Entity, die durch einige typische Attribute beschrieben wird … Dokument-Metadaten: in BiBTEX, Zotero etc. jeweils ein mehr oder weniger komplexer Datensatz … in einem relationalen Datenbankmanagemt-System (RDBMS) könntem man jedes Dokument in einer einzigen Zeile einer großen Tabelle aufschreiben … das wäre eine Non First Normal Form (NFNF); das führt zu typischen fehlern, das will man nicht, diese Tabelle will und kann man normalisieren; für die Entity “Dokument” ergeben sich einige wenige Tabellen in NF3; diese wollen wir als die Aspekte eines Dokuments bezeichnen; diese sind:

  • Aspekt Werk: Neuinterpretation des Begriffs nicht eng gefasst als eine Erfindung, sondern weiter gefasst allgemein als Gedanke, Idee, Anschauung

  • Aspekt Expression: Neuinterpretation nicht nur als natürlichsprachliche Beschreibung, sondern weiter gefasst als Modell, insbesondere auch abstraktes Modell; charakteristisches Merkmal “Sprache”: natürliche Sprache in DE, EN etc; aber auch formale Sprachen: Programmiersprachen, Logiksprachen, Beschreibungssprachen, semiformale Modellierungssprachen

  • Aspekt Manifestation: Neuinterpretation

    • im Unterschied zur Expression: medienspezifische Codierung einer Expression in einem bestimmten Format; nutzt Buchstabenzeichen (Letters)

    • Unterscheidung gegenüber Items: eine Manifestation beschreibt beschreibt Eigenschaften eines abstrakten Prototypen; das Gemeinsame vieler einzelner Items;

    • eine Entity aus der sozialen, abstrakten Wirklichkeit

  • Aspekt Item:

    • ein konkreter Gegenstand aus der Realität (physikalischen Welt)

    • digital Ergebnis einer rdf Dereferenzierung; eine Datei, ein Datenstrom;

Wichtig: Ein Dokument wird immer durch alle vier Aspekte beschrieben; die Frage “ist dieses Dokument ein Werk oder eine Expression” geht also fehl. Man kann aber sagen: In Bezug auf den Werk-Aspekt hat das Dokument diese Autoren; es gibt Expressionen auf EN, DE, UML, RDFS; es ist in den Manifestationen pdf, html und ttl verfügbar; ein Item kann man z.B. unter http://… frei herunterladen.

Datensatz#

Record#

eine “verschachtelte Struktur”: eine strukturierte Sammlung von einzelnen Werten, die insgesamt ein einzelnes Ding beschreiben; in C ein Struct; in Pascal:

type
    TAdresse = record
        Strasse: string[50];
        Hausnummer: Integer;
    end;

    TPerson = record
        Name: string[50];
        Alter: Integer;
        Adresse: TAdresse; // Verschachtelte Struktur
    end;

In Python:

@dataclass
class Adresse:
    strasse: str
    hausnummer: int

@dataclass
class Person:
    name: str
    alter: int
    adresse: Adresse  # Verschachtelte Struktur

In Python als verschachteltes Dict, gleichzeitig auch gültiges JSON:

{
    "name": "Max Mustermann",
    "alter": 30,
    "adresse": {
        "strasse": "Hauptstraße",
        "hausnummer": 10
    }
}

Normalisierung#

WEMI kann man als Ergebnis einer Datenbank-Normalisierung interpretieren. Was ist Normalisierung?

Didaktisches Beispiel Parksituation#

Wir wollen Daten erheben, zusammenführen, als offene Daten bereitstellen, die über die Park-Situation in einer Stadt, einem Bundesland etc. auskunft geben … Parkhaus Stammdaten: ParkhausID, Adresse (Straße, PLZ, Ort), Kapazität … Parkhaus-Belegungsdaten: ParkhausID, freie Plätze, belegte Plätze … Wir haben “einfache” Attribute wie z.B. freie Plätze … und wir haben “komplexe” Attribute wie z.B. Adresse … ein “komplexes” Attribut (z.B. Adresse) sei dabei ein solches, bei dem man auch den Attributwert wieder durch weitere Attribute (bei Adresse z.B. Straße, PLZ, Ort) beschreiben kann.

flach#

“flaches” Modell, nicht normalisiert, Datenbank-Normalform NFNF:

  • jede Zeile enthält ParkhausID, Straße, PLZ, Ort, Kapazität, freie Plätze, belegte Plätze

tief#

“tiefes” Modell, in Datenbank-Normalform 3:

  • Tabelle Parkhaus-Stammdaten: ParkhausID, AdressID, Kapazität

  • Tabelle Adresse: AdressID, Straße, PLZ, Ort, ggf. Anfahrts-Beschreibung, Navi-Daten etc.

  • Tabelle Parkhaus-Belegung: ParkhausID, Zeitstempel, freie Plätze, belegte Plätze

flach vs. tief#

Vorteil: Ganz offensichtlich ist die nicht normalisierte Tabelle hoch redundant. Es ist unnötig und fehleranfällig, für jeden Zeitstempel nicht nur die Belegung eines Parkhauses, sondern auch seine Adresse mit anzugeben … die Beschreibung einer Park-Situation durch eine Aufteilung in Parhaus-Stammdaten, Parkhaus-Adresse und Parkhaus-Belegungsdaten vermeidet Redundanz und verhindert Fehler. Sachlich zusammengehörende Informationen werden in der selben Tabelle zusammengehalten; sachlich unterschiedliche Informationen werden in unterschiedlich Tabellen aufeteilt … fachlich: man vermeidet Datenbank-Anomalien; die sind bestens bekannt, bestens dokumentiert – und man weiß bestens, wie man sie auflöst … Die Methode der Datenbanknormalisierung erzeugt aus einer einzigen großen, “flachen” Tabelle ein “tiefes” Datenmodell, verstanden als mehrere, eng aufeinander bezogenen “flache” Tabellen … eine extra Tabelle legt man immer dann an, wenn man über einen Attributwert selbst etwas aussagen will. In unserem Beispiel gilt das jedenfalls für das Parkhaus selbst: Ein Parkhaus hat eine Adresse, hat eine Belegung.

Aspekte#

Wir wollen Parkhaus-Stammdaten, Parkhaus-Adresse und Parkhaus-Belegung als Aspekte der uns interessierenden abstrakten Entität “Park-Situation” interpretieren.

Der Begriff “Aspekt” stammt vom lateinischen Wort “aspectus”, was so viel wie “Anblick” oder “Gesichtspunkt” bedeutet. “Aspectus” leitet sich von dem Verb “aspicere” ab, das “anschauen” oder “betrachten” bedeutet. In der deutschen Sprache wird “Aspekt” verwendet, um verschiedene Perspektiven oder Gesichtspunkte zu beschreiben, unter denen ein Thema oder eine Situation betrachtet werden kann. (Duck.ai, Modell GPT-4o, 2025-06-03)

Aspekte haben die Eigenschaft, dass sie immer gemeinsam auftreten: In unserem Beispiel wird eine Parksituation immmer durch die drei Aspekte Parkhaus-Stammdaten, Parkhaus-Adresse und Parkhaus-Belegung beschrieben. Auch wenn wir in der Tabelle Parkhaus-Belegung nur einen einzigen Zeitstempel betrachten müssen wir auch auf die Aspekte Adresse und Parkhaus-Stammdaten zurückgreifen, um ein (für diesen Zeitstempel) vollständiges Bild einer Parksituation zu erhalten.

ER#

Zugehörige grafische Sprache: ER-Diagramme, Chen, seit 50 Jahren etablierte Sprache, auch Modellierungs-Methode … grundlegende Annahme von Normalisierung, ER usw: die unterschiedlichen Tabellen stellen eine technische Ebene dar; die Tabellen sind die technische Realisierung einer abstrakteren Ebene, in der man die Welt in “Entities” und “Relationships” einteilt, die jeweils “Attribute” haben, und die insbesondere über “Fremdschlüssel” miteinander in Beziehung stehen … in anderen Kontexten kann man die Welt auch anders sehen; aber in der Welt der Datenmodellierung sind das ganz grundlegende Strukturen … eine wesentliche Eigenschaft dieser Sicht auf Welt ist die: Wenn im Zuge einer Normalisierung viele Attribute und Attributwerte “logisch” gruppiert werden; sogenannte funktionale Abhängigkeiten festgestellt, verschiedene Tabellen angelegt und bestimmte Attribute eindeutig bestimmten Tabellen zugeordnet werden; und in diesem Tun die zugehörigen Erkenntisprozesse und Diskurse durch ER-Diagramme teils rekonstruiert, teils visualisiert, teils auch geleitet werden: Dann beschreiben unterschiedliche Attribute und Attributwerte jeweils unterschiedliche Dinge. Technisch gesehen sind die so beschriebenen Dinge disjoint: Parkhaus-Stammdaten sind etwas anderes als eine Adresse, etwas anderes als eine Belegung eines Parkhauses zu einem bestimten Zeitpunkt. Entsprechend werden auch Attribute unterschiedlich zugeordnet; in unserem Beispiel Parksituation heißt das: Es ist das Parkhaus, das eine Kapazität hat und nicht die Adresse; umgekehrt ist die Adresse, die durch Straße, PLZ, Ort beschrieben wird und nicht das Parkhaus; die Anzahl der freien und belegten Plätze ist eine Eigenschaft der Parkhausbelegung, u.s.w.

Transfer auf “Dokument”#

Wenn wir eine Datenbank anlegen, könnte jeder Datensatz in einer einzigen langen Zeile repräsentiert werden … ein “flacher” Datensatz (i.S.v. Record), ein einzelnes Objekt, mit vielen Attributen, auch Multi Value Fields … so machen das viele LitVerwaltungsrogramme … datenbanktechnisch eine non first normal form (NFNF) … ein Dokument kann mehr oder weniger eigenständige Teildokumente haben: eine Monographie einzelne Kapitel; ein Herausgeberband einzelen Aufsätze verschiedener Autoren; ein Kunstkatalog Texte und Abbildungen; ein Mathematik-Paper Formeln, ein Jupyther-Notebook Text und Python-Code, etc. … solche Teildokumente erzeugen in unserer Tabelle andere einzelne Zeilen / Records; in einem Record haben wir auch das Attribut “enthalten in”, das auf einen anderen Record verweist; in BibTeX ist das “inbook” oder “incollection”.

Aus professioneller Sicht wollen wir Normalisieren … “Tiefe” herstellen … später ggf. auch wieder denormalisieren, “flacher” machen, z.B. um Performance zu steigern und Komplexität zu reduzieren … im Extremfall wieder bis zur unrprünglichen NFNF; aber das ist die Ausnahme; auch wenn wir letztlich mit “flacheren” Records arbeiten wollen, ist ein “tiefes” Datenmodell zum Verständnis unerlässlich.

Normalisierung der Tabelle “Dokument” … die Informationen aus “Dokument” werden auf (hier) 4 neue Tabellen verteilt, aus denen man durch Joins automatisch wieder die ursprüngliche Tabelle “Dokument” erzeugen kann; diese 4 Tabellen heißen – (Trommelwirbel, Tusch) – Werk, Expression, Manifestation, Item (WEMI) … die 4 WEMI-Klassen sind ein Normalisierungs-Ergebnis; weil eine Normalisierung nicht rein mechanisch durchgeführt wird, sondern in eine Normalisierung immer auch Weltwissen hineinspielt, spiegelt ein Record in der normalisierten Fassung mehr Weltwissen als ein Record in NFNF wider.

RDF 1.2#

Dokument:

viele Begriffe; vgl. die GenDifS-Wissensrepräsentation als Mindmap:

  • hier MINDMAP aus LOGD einbinden

ÜBERLEGEN: ggf. gleichzeitig behandeln mit RFC 3986? ggf. auch WEBARCH?

rdf: denotieren#

gleich am Anfang: “denotieren”:

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 RDF 1.2 Semantics (https://www.w3.org/TR/rdf12-concepts/#resources-and-statements)

Denotieren ist ein Zusammenhang zwischen einem Zeichen und irgend etwas in der Welt, von dem sich Menschen eine mehr oder weniger gemeinsame Vorstellung machen … dieses Irgendetwas wird durch einen Stellvertreter denotiert, den wir Menschen verwenden, um miteinander zu kommunizieren … zu kommunizieren in Situationen oder Geschehen, in denen dieses Irgendetwas eine Rolle spielt … in RDF wird dieser Stellvertreter “Identifikator” genannt … das Herstellen dieses Zusammenhangs wird “to mint” genannt, die Metapher hier ist “eine Münze prägen” (https://www.w3.org/TR/rdf12-concepts/#change-over-time) …

Um solch einen Zusammenhang herzustellen, zu prägen, muss man kommunizieren, worin dieses Irgendwetwas besteht, für das der Identifikator stellvertretend stehen soll:

By social convention, the IRI owner [WEBARCH] gets to say what the intended (or usual) referent of an IRI is. (https://www.w3.org/TR/rdf12-concepts/#referents) […] The IRI owner can establish the intended referent by means of a specification or other document that explains what is denoted.

Ein Satz “Cäsar schlug die Gallier” enthält die Identifikatoren “Caesar”, “schlug” und “Gallier”; mit diesen Identifikatoren denotiert werden ein Staatsmann, ein sozialer Vorgang, eine Volksgruppe – lauter Entitäten nicht der Realität, sondern der Wirklichkeit … die Verbindung zwischen Zeichen und Ding der Wirklichkeit wird hergestellt durch einen menschlichen Geist: Der Mensch liest einen Text, es entsteht eine Vorstellung im Kopf, wir glauben zu verstehen, was gemeint ist … “denotieren” ist ein Zusammenhang zwischen einem Identifikator und dem Ding der Wirklichkeit,

A good way of communicating the intended referent is to set up the IRI so that it dereferences [WEBARCH] to such a document. Such a document can, in fact, be an RDF document that describes the denoted resource by means of RDF statements.

RDF: derefernzieren#

Zeichenstrom holen, http status auswerten …

  • Datei holen; Datei hat Format; parsen, interpretieren z.B. mit RDFlib

  • SPARQL Anfrage an Endpoint: abstrakten Graph holen; Endpoint generiert Zeichenstrom

RDF: beschreiben#

Idee: Beschreibungen sind Expressionen … in dWEMI u.A. mit den Unterklassen normalsprachliche Beschreibung und Modell

Fragmente#

Eine URI ist nicht Atomar, sondern folgt einer Grammatik, einer Syntax, und weist Teile auf (RFC 3986): … authority, path, queries, fragment … interessant, speziell: Wenn eine URI einen Fragment-Identifier hat, dann können wir diesen abschneiden und erhalten so eine andere (!) URI … https://jbusse.de/example/animals.ttl#bird und https://jbusse.de/example/animals.ttl sind 2 verschiedene URIs … folgt man der Hash-Slash-URI-Konvention (Benennung JB), dann denotiert eine URI mit Fragment (informell: Hash-URI) eine Entität aus der Wirklichkeit. Schneidet man das Fragment ab, entsteht so eine URI ohne Fragment (informell: Slash-URI); diese referenziert einen physikalischen Zeichenstrom wie z.B. eine Datei, mithin also eine Entität aus der Realität. Das abgeschnittene Fragment identifiziert (oder darf man schreiben “denotiert”?) meistens (aber nicht immer) ein Fragment in der durch die Slash-URI denotierten Datei … der Fragment-Begriff hängt vom Format (genauer: Mime-Type) ab: In einer html- oder xml-Datei sind Fragmente anders definiert als in einer CSV-Datei, einer Text-Datei, Audio oder Video etc. … Fragment bezieht sich also meistens auf den Manifestations-Aspekt … mit einer Ausnahme: Im Kontext von RDF identifziert der Fragment-Identifier nicht einen Text-Abschnitt im konkreten, d.h. in einem bestimmten Format serialisierten RDF-Graphen, sondern unabhängig vom der gewählten Serialisierung eine Entity in einem abstrakten RDF-Graphen – der freilich in dieser Datei enthalten ist.

FRAGE: Kann man unterscheiden, ob sich diese Entity im Default-Graph oder in einem Named Graph befindet? SPARQL macht hier Unterschiede …

BEISPIEL machen mit

  • RDF Expression <https://jbusse.de/example/animals.ttl#term-bird> a skos:Concept; skos:broader <https://jbusse.de/example/animals.ttl#term-animal> .

  • Datei https://jbusse.de/example/animals.ttl

digital WEMI und Bezugs-Ontologien#

dWEMI und PROV-O#

Bezug zu Prov-O: Vor der Normalisierung war die Entity eine einzige Entity (nämich ein Dokument), das mit Akteur und Aktivität in Beziehung stand … wie sieht das nach der Normalisierung aus? … wir bilden Subklassen von prov-o Akteur und Aktivitäten, und ordnen sie der entsprechenden Tabelle zu; bei analogen Dokumenten:

  • Werk: Autor, Komponist; denken, erfinden, schaffen

  • Expression: Verfasser oder Übersetzer, Arrangeur; schreiben, verfassen, arrangieren

  • Manifestation: Schriftsetzer, Notensetzer; eintippen, tippen, setzen, gravieren

  • Item: Drucker; abschreiben, drucken, kopieren, downloaden

dWEMI und SKOS#

Aboutness, Topic, Thema, Subject, https://en.wikipedia.org/wiki/Topic_and_comment, https://en.wikipedia.org/wiki/Aboutness

Eine Instanz der Klasse skos:Concept … eine geistige Konstruktion … also eine Subklasse von dWEMI:Work … SKOS ist ein Schema, um einen Begriff strukturiert zu erfassen … auch d

… ebenso jede Instanz, z.B. :term-apfel … alle Instanzen von skos:Concept beginnen bei uns mit term- … z.B. <https://www.jbusse.de/ex/glossar.html#term-apfel> a skos:Concept . …

vor dWEMI: eine URI kann alles bezeichnen … z.B. https://jbusse.de/pub/index.html eine Person, oder auch die Datei, die die Person beschreibt

mit dWEMI : Slash-URI https://jbusse.de/pub/index.html denotiert das Item; wenn man über das Item sprechen will (z.B. das Erstellungsdatum der Datei, die Zugriffrechte oder den zugehörigen Linux-User in einem bestimmten Dateisystem), verwendet man es für sich selbst.

Die Hash-URI https://jbusse.de/pub/index.html# (man beachte das Hash-Zeichen am Ende) denotiert dagegen das Werk, die Idee “J.Busse”. Man darf erwarten,

  • dass durch die Slash-URI, die durch Abschneiden des Fragmentes entsteht (also https://jbusse.de/pub/index.html, d.h. ohne Hash-Zeichen),

    • ein Item referenziert wird,

      • welches ein Exemplar der Manifestation ist,

        • welches die Expression codiert,

          • welche das durch die Hash-URI denotierte Werk beschreibt, modelliert etc.

Default, falls nicht explizit anders deklariert:

  • eine Hash-URI denotiert ein dWEMI:Item;

  • eine Slash-URI denotiert ein dWEMI:Work

  • falls eine Expression oder Manifestationen denotiert werden soll, muss das extra deklariert werden.

PREFIX ex: <https://www.jbusse.de/example/>

ex:index.ttl#johannes ... RDFS und OWL-Beschreibung von Johannes
ex:index.html#johannes ... Normalsprachliche Beschreibung von Johannes
ex:index_skos.ttl#johannes ... die formalen SKOS-Definitionen, insbesondere BT, NT usw.
ex:glossary.html#johannes ... enthält als id u.A. die ID :term-johannes; in SPHINX kann das auch jede andere Datei sein; aber semauth sammelt alle Text-Definitionen aus in glossary.html

misc#

Contents