UMTHES in SKOS - innoQ Deutschland GmbH

SNS UMTHES in SKOS DRAFT
Editor:
UMTHES in SKOS
Modellierung und Serialisierung des Umweltthesaurus in einer formalen Sprache des
Semantic Web.
Projekt:
Spezifikation, mit OWL/RDFS Schema und komplexen Beispielen.
Thomas Bandholtz (tb), innoQ Deutschland GmbH
Erweiterung von SNS … AZ …
Auftraggeber:
Verteiler:
www.umweltbundesamt.de
Willem van Kerkhof (wvk), innoQ Deutschland GmbH
Joachim Fock (fo), Umweltbundesamt Deutschland
Jens Wissmann (jw), Forschungszentrum Informatik (FZI)
Versionen reviewed by:
03 25. Mai 2009
wvk fo jw
V 03 Umweltbundesamt S. 1

SNS UMTHES in SKOS DRAFT
Inhalt
1 Einleitung ......................................................................................................................................... 3
2 SKOS Architektur aus der Sicht von UMTHES ............................................................................... 6
2.1 Concept und Label .................................................................................................................. 6
2.2 Identität und Referenz ............................................................................................................. 9
2.2.1 Aus Sicht der Migration ................................................................................................... 9
2.2.2 Aus Sicht des URI Designs ........................................................................................... 10
2.2.3 UMTHES Namensraum ................................................................................................. 10
2.3 Semantische Beziehungen zwischen Concepts .................................................................... 10
2.4 (Keine) Spezialisierung von skos:Concept ........................................................................... 11
2.5 (Keine) Concept Collections .................................................................................................. 11
2.6 Concept Scheme ................................................................................................................... 12
2.7 Mapping Properties ............................................................................................................... 12
3 Lexical Properties .......................................................................................................................... 15
3.1 Einfache SKOS Eigenschaften .............................................................................................. 15
3.1.1 Lexical Labels ................................................................................................................ 15
3.1.2 Notation vs. Enumeration .............................................................................................. 15
3.2 XL Labels ............................................................................................................................... 17
3.2.1 Eigenschaften von skosxl:Label .................................................................................... 17
3.2.2 Asymmetrische Mehrsprachigkeit .................................................................................. 20
3.2.3 Koordination ................................................................................................................... 21
4 Documentation Properties ............................................................................................................. 23
4.1 SKOS Note Typenübersicht .................................................................................................. 23
4.2 DCTERMS in Documentation Properties .............................................................................. 25
4.3 Datentypen für UMTHES Notes ............................................................................................ 27
4.3.1 Alle Texttypen ................................................................................................................ 27
4.3.2 usageNote ..................................................................................................................... 27
4.3.3 expirationNote ................................................................................................................ 28
4.3.4 editorialState .................................................................................................................. 28
4.3.5 exportNote ..................................................................................................................... 29
5 UMTHES Entitäten in SKOS..........................................................................................30
V 03 Umweltbundesamt S. 2

SNS UMTHES in SKOS DRAFT
1 Einleitung
Warum ein SKOS Schema für UMTHES, und zunächst einmal, was ist SKOS?
„Das Simple Knowledge Organisation System (SKOS, frei übersetzt „einfaches System zur
Organisation von Wissen“) ist eine auf dem Resource Description Framework basierende
formale Sprache zur Kodierung von Dokumentationssprachen wie Thesauri, Klassifikationen
oder andere kontrollierte Vokabulare. Mit SKOS soll die einfache Veröffentlichung und
Kombination kontrollierter, strukturierter und maschinenlesbarer Vokabulare für das
Semantische Web ermöglicht werden.“ (Wikipedia).
SKOS ist für uns zunächst die formale Sprache für ein Modell, das nicht viel mehr sein will
als ein logisches Datenmodell für UMTHES. Diese Sprache gibt ein abstraktes Modell vor,
mit dem wir die tatsächlichen Strukturen von UMTHES formal beschreiben (Schema). Mit
Bezug auf dieses Schema kann jedes einzelne Datenelement zutreffend und vollständig
beschrieben werden.
Bei dieser Modellierung von UMTHES geht es um drei Schwerpunkte:
(1) Die abstrakten Modelle von UMTHES und SKOS sind zwar ähnlich, erfordern aber
einen strukturellen (auch gedanklichen) Transformationsschritt (Kap. 2, SKOS
Architektur aus der Sicht von UMTHES).
(2) Die in SKOS vordefinierten lexikalischen Eigenschaften müssen und können für
UMTHES erweitert werden (Kap.3, Lexical Properties).
(3) SKOS ermöglicht eine striktere Typisierung der Dokumentation (UMTHES
„Bemerkungen“), die optional genutzt werden kann (Kap. 4 Documentation
Properties).
Das Resource Description Framework (RDF) und die darauf aufbauenden formalen
Sprachen (z.B. SKOS) verfügen darüberhinaus über eine maschinenlesbare Syntax. Dies
gilt sowohl für das Schema (die konkrete Architektur eines Vokabulars) als auch für das
Vokabular selbst. Daraus ergeben sich vielfältige Möglichkeiten der maschinellen Nutzung.
Im gegebenen Kontext wird die Maschinenlesbarkeit von RDF/SKOS zunächst im Sinne
eines Austauschformats genutzt. SKOS hat sich in der Europäischen Umweltterminologie
seit 2004 in dieser Rolle etabliert, daher ist UMTHES in SKOS schon für sich allein ein
Dienst im Sinne der Datenbereitstellung.
Der erste Migrationsschritt des Vorhabens ist ein Export der Quelldaten aus dem
Bibliothekssystem in das hier beschriebene SKOS Format. Die geplante SNS Erweiterung
wird aktuelle und künftige UMTHES Daten in genau demselben Format über Services
bereitstellen. Daher ist das UMTHES/SKOS Schema ein strategischer Baustein dieses
Vorhabens, gleichermaßen für das Modell und die Implementierung der Schnittstellen.
V 03 Umweltbundesamt S. 3

SNS UMTHES in SKOS DRAFT
Die feste Adresse der SKOS Standardisierung ist:
� SKOS: http://www.w3.org/2004/02/skos/
Die hier verwendete SKOS Version ist die
� SKOS Reference W3 Candidate Recommendation, 17 March 2009
http://www.w3.org/TR/2009/CR-skos-reference-20090317/.
Dazu gehört eine lesenswerte Einführung für „Anfänger“:
� SKOS Primer, Working Draft, 17 March 2009:
http://www.w3.org/TR/2009/WD-skos-primer-20090317/
Es kann sein, dass sich beim Übergang von der W3C Candidate Recommendation zur W3C
Recommendation noch Änderungen ergeben, aber der Workflow des W3C löst in aller Regel
die kritischen Fragen zuerst, daher sind im abschließenden Schritt eher Detailklärungen zu
erwarten. Diese werden gegebenenfalls in eine neue Version dieses Konzepts eingearbeitet.
Für die Beispiele in den folgenden Kapiteln kommen mehrere gängige RDF/OWL Syntaxen
in Frage 1 , zwei XML-Varianten, N3 oder Turtle. Die SKOS Spezifikation und der Primer
verwenden die für Menschen am leichtesten lesbare Turtle Syntax, dies wird hier
übernommen. Turtle schreibt die RDF Tripple etwa in nachstehender Weise (leicht
vereinfacht).
Katze ist-ein Tier;
frisst (Maus Fisch Gras);
hasst Hund;
hatBeine 4;
gehört Mensch.
Hund ist-ein Tier;
frisst (Wurst Chips Katze);
hasst Katze;
hatBeine 4.
gehört Mensch.
Daraus folgt (mit einigen zusätzlichen Annahmen):
Mensch liebt (Katze Hund);
braucht (Maus Fisch Gras Wurst Chips);
beschützt Katze;
hatBeine 2.
Wenn Sie das jetzt mitlesen konnten, haben Sie Turtle schon verstanden. Natürlich folgt
Mensch hatBeine 2 keinesfalls aus dem zuvor gesagten. Auch die Katzenfreundlichkeit
des Besitzers ist spekulativ, aber man kann sich an diese formale Ausdrucksweise
gewöhnen.
In RDF (und auch in der Turtle Syntax) werden die Bezeichner (wie „Katze“, „ist-ein“, „Tier“
im obigen Beispiel) durch ein Präfix ihrem jeweiligen Namensraum zugeordnet. Beispiele:
1 http://www.w3.org/TR/2009/WD-owl2-primer-20090421/#OWL_Syntaxes
V 03 Umweltbundesamt S. 4

SNS UMTHES in SKOS DRAFT
Beispiele Namensraum
rdf:type ist in RDF definiert
rdfs:label ist in RDF Schema definiert
skos:Concept ist in SKOS definiert
skosxl:Label ist in der SKOS Extension for Labels definert
dct:date ist als Dublin Core Term definiert
umt:date
umt:inflectional
umt:useNarrower
:abgas
:00000456
sind in der SKOS Erweiterung durch UMTHES („umt:“) definiert
Leeres Präfix (nur Doppelpunkt) - sind im lokalen Namensraum
definiert.
Tabelle 1 Verwendete Namensraum – Präfixe in diesem Dokument
V 03 Umweltbundesamt S. 5

SNS UMTHES in SKOS DRAFT
2 SKOS Architektur aus der Sicht von UMTHES
UMTHES muss ein wenig Umdenken. Das grobe Modell von UMTHES lässt sich
beschreiben als:
{ Thesaurus [ Deskriptor, Nicht-Deskriptor] } { Wörterliste }
Dagegen wirkt SKOS auf den ersten Blick vereinfachend:
{ Concept } { Label }
Dass SKOS nicht vereinfacht sieht man, wenn man auch die Beziehungen zwischen diesen
Elementen betrachtet.
Abbildung 1 Strukturelle Unterschiede zwischen UMTHES und SKOS
2.1 Concept und Label
Die Semantik von skos:Concept stimmt weitgehend mit der von Deskriptor überein. Die
Unterschiede rühren eher daher, dass es in SKOS keine entsprechend äquivalente Klasse
für Nicht-Deskriptor gibt. Das Äquivalent zur USE Beziehung (skosxl:altLabel)
verweist sozusagen direkt auf ein „Wort“ in der Wörterliste.
V 03 Umweltbundesamt S. 6

SNS UMTHES in SKOS DRAFT
Lexikalische Eigenschaften (siehe Kap. 3 Lexical Properties) der Worte werden nicht direkt
im Concept beschrieben, sondern sie bilden eine eigene Klasse (3.2 XL Labels). Diese
entspricht grob den Einträgen in der UMTHES Wörterliste. Ein solches Label ist per se weder
Deskriptor noch Synonym oder Einzelbegriff usw., dies ergibt sich erst aus dem Vorliegen
und dem Typ einer Zuordnung zu einem Concept (skosxl:preLabel,
skosxl:altLabel, skosxl:hiddenLabel).
Aus Sicht von UMTHES „fehlt“ in SKOS der Nicht-Deskriptor. Aber SKOS braucht ihn nicht,
denn er ist lediglich die Fassade eines Worts, ohne eigenständige Semantik. Diese Semantik
liegt allein in der Beziehung zum Deskriptor (Concept). SKOS stellt diese Beziehung direkt
zum Wort (Label) her.
:00000577 rdf:type skos:Concept;
skosxl:prefLabel :abgasreinigung;
skosxl:altLabel :abgasreinigungsanlage.
:abgasreinigung rdf:type skosxl:Label;
skosxl:lexicalForm „Abgasreinigung“@de.
:abgasreinigungsanlage rdf:type skosxl:Label;
skosxl:lexicalForm „Abgasreinigungsanlage“@de.
Codebeispiel 1 USE Beziehung ohne Nicht-Deskriptor im SKOS Modell
Labels werden durch die Art ihrer Verwendung klassifiziert, und nicht von vorn herein.
� Nicht-Deskriptoren im Sinne von UMTHES sind die Untermenge aller Wörter (Label),
die wenigstens eine altLabel, aber keine prefLabel Beziehung zu irgendeinem
Concept haben. Diese Untermenge lässt sich jederzeit maschinell identifizieren, und
SKOS hebt sie nicht durch eine explizite Klasse hervor.
� Ähnlich für UMTHES Einzelbegriffe: das sind alle Labels, die keinerlei direkte
Beziehung zu irgendeinem Concept haben.
Nähere Festlegungen sind möglich, bedürfen aber einer (zulässigen) Erweiterung des SKOS
Modells.
Hinsichtlich dieser Architektur befindet sich SKOS in Übereinstimmung mit der
gegenwärtigen Aktualisierung des ISO Standards. Leonard Will berichtete am 13.02.2009 in
der öffentlichen SKOS Mailingliste:
“I write as Chair of the „Data Modeling, Exchange Formats and Protocols‟ subgroup of the
ISO working group SC9WG8/Project 25964, currently revising the ISO standard for thesauri
for information retrieval, but as these standards are still in draft form anything I say here is
my own interpretation of the way we are going, and is not authoritative”. … “The ISO model
is firmly based on relationships between concepts, not terms. Terms are used as labels for
concepts, as in SKOS”. 2
2 http://lists.w3.org/Archives/Public/public-esw-thes/2009Feb/0033.html
V 03 Umweltbundesamt S. 7

SNS UMTHES in SKOS DRAFT
Abbildung 2 ISO UML Modell (draft) working group SC9WG8/Project 25964
V 03 Umweltbundesamt S. 8

SNS UMTHES in SKOS DRAFT
Die Anlage enthält ein UML Diagramm (Abbildung 2), in dem dies detailliert wird. Die
Modellierung ist sehr ähnlich wie in SKOS, die Äquivalenzbeziehungen preferred und nonpreferred
term verlaufen zwischen ThesaurusConcept und ThesaurusTerm, und es gibt
keine Klasse für Nicht-Deskriptoren.
Da sich die Nicht-Deskriptoren durch eine einfache formale Regel als Untermenge der
Wörter (Label oder Term) ableiten lassen, kann UMTHES semantisch verlustfrei in beiden
Modellen (SKOS und ISO) abgebildet werden.
2.2 Identität und Referenz
UMTHES hat heute zwei parallele Schlüsselsysteme: die THSISN in der Basistabelle und die
WLISN in der Wörterliste.
Wenn, wie im vorigen Kapitel erläutert, die Nicht-Deskriptoren als Klasse ganz entfallen, so
entfallen auch die THSISN ihrer Instanzen (vgl. Abbildung 1). Die den Nicht-Deskriptoren
äquivalente Untermenge der Label enthält Einträge aus der Wörterliste, die mit einer WLISN
identifiziert werden. Die USE / USEDFOR Beziehung in UMTHES verwendet aber an beiden
Enden THISN. Die hier beteiligten Nichtdeskriptoren verweisen ihrerseits in die Wörterliste
(WLISN). Beim Übergang zu SKOS kann diese Indirektion über die Nicht-Deskriptor-
„Fassade“ kurzgeschlossen werden. Die neue altLabel Beziehung verweist nun direkt von
der THSISN des Deskriptors auf die WLISN des dem ehemaligen Nicht-Deskriptor
zugeordneten Worts.
Dieses Vorgehen erlaubt eine semantisch verlustfreie, reproduzierbare Transformation aus
dem aDis Datenmodell in SKOS, aber es gibt keine verlustfreie Rekonstruktion der
Quelldaten, da die THSISN der Nicht-Deskriptoren nicht mehr vorliegen. Dies erschwert die
Qualitätssicherung der Datenmigration, und es würde jede spätere Aktualisierung des aDis
Datenbestands aus dem SKOS Modell von SNS stark einschränken. Daher wird
vorgeschlagen, alle THSISN und WLISN der Quelle in einer historyNote
(umt:exportNote) mitzuführen wie näher unter (4.3.5) bei den Documentation Properties
beschrieben.
Für das UMTHES/SKOS Modell ergibt sich die Frage, welche ID für Concept und Label
verwendet wird. Aus technischer Sicht ist dies unerheblich, solange die Transformation
fehlerfrei und die Schlüssel eindeutig sind.
2.2.1 Aus Sicht der Migration
Die Concepts sind durch die THSISN der Deskriptoren identifiziert, die Labels durch die
WLISN der Wörterliste. Da aber beide Schlüssel nicht untereinander eindeutig sein müssen,
wird eine Unterscheidung benötigt, z.B. durch ein Präfix.
Beispiele für solche URIs könnten sein:
http://www.semantic-network.de/umthes/2009/concept/00004711
http://www.semantic-network.de/umthes/2009/label/00004711
oder
http://www.semantic-network.de/umthes/2009/concept4711
http://www.semantic-network.de/umthes/2009/label4711
V 03 Umweltbundesamt S. 9

SNS UMTHES in SKOS DRAFT
Hier ist unterstellt, dass in THSISN und WLISN zufällig der gleiche Schlüssel 00004711
vergeben wurde. (Eine URI ist immer als Ganzes zu sehen: „Semantik Network kennt im
UMTHES 2009 ein Concept Nr. 00004711“. Die Nummer allein braucht nicht eindeutig sein).
Dies ist nur eine Möglichkeit, die URIs auf Basis der bisherigen THSISN und WLISN zu
gestalten, sie ist keineswegs zwingend, wenn alle THSISN und WLISN in exportNotes
mitgeführt werden.
2.2.2 Aus Sicht des URI Designs
In den nachstehenden Code Beispielen werden für Labels „sprechende“ IDs verwendet, wie
z.B. „:abgas“ als ID für das Label „Abgas“ anstelle der WLISN 00025534. Eine solche
(technisch normalisierte) Ableitung der ID aus dem Namen ist im Semantic Web weit
verbreitet, da sie sehr gut menschenlesbar ist. Solange die Namen selbst hinreichend
eindeutig sind (Vorlageform), ist dies auch technisch einfach zu realisieren.
Für Concepts, die ja unabhängig von den ihnen zugewiesenen Labels existieren, ist eine
abstrakte ID angemessen. In den Beispielen wird hier meist die THSISN verwendet.
http://www.semantic-network.de/umthes/2009/00000577
http://www.semantic-network.de/umthes/2009/abgasreinigung
http://www.semantic-network.de/umthes/2009/abgasreinigungsanlage
2.2.3 UMTHES Namensraum
UMTHES/SKOS benötigt einen autonomen Namensraum. Dieser beginnt in den
vorausgegangenen Beispielen bei http://www.semantic-network.de/umthes/.
Die URI dieses Namensraums kann sich aus Datensicht jederzeit ändern, es werden intern
nur relative URIs verwendet. Für diese relativen URIs gelten Eindeutigkeit und Persistenz
lediglich innerhalb des Namensraums.
Zur Persistenz der gesamten URI gehört auch die des Namensraums. Dies fällt in die
organisatorische Zuständigkeit und kann nicht aus deinem Datenformat heraus sichergestellt
werden.
2.3 Semantische Beziehungen zwischen Concepts
Dies meint ausschließlich Relationen zwischen jeweils zwei Concepts, Labels spielen hier
gar keine Rolle. Die Äquivalenz-Beziehungen (USE / USED FOR) finden sich nicht unter den
Semantic Relations, denn dies sind Beziehungen zwischen Concept und Label, nicht
zwischen Concept und Concept. Siehe dazu unter (3.2) XL Labels.
SKOS enthält vordefinierte hierarchische und Verwandtschaftsbeziehungen.
skos:semanticRelation
skos:broaderTransitive
skos:broader
skos:narrowerTransitive
skos:narrower
skos:related
UMTHES benötigt hier derzeit keine Erweiterung.
V 03 Umweltbundesamt S. 10

SNS UMTHES in SKOS DRAFT
Für die Hierarchie wird nicht die von SKOS angebotene transitive Variante verwendet.
:abgas rdf:type skos:Concept;
skos:narrower :abgasanlage.
:anlage rdf:type skos:Concept;
skos:narrower :abgasanlage.
:abgasanlage rdf:type skos:Concept;
skos:broader :abgas;
skos:broader :anlage.
Codebeispiel 2 SKOS Semantic Relations: Hierarchie
In SKOS schließen sich hierarchische und related Beziehungen zwischen denselben
Concepts gegenseitig aus (disjoint). Im Beispiel open wäre :abgas skos:related
:abgasanlage nicht gleichzeitig möglich.
2.4 (Keine) Spezialisierung von skos:Concept
SKOS fordert ausdrücklich dazu auf, von der Klasse Concept spezialisierte Unterklassen
abzuleiten. Dies ist (2004) bei GEMET für die Groups und Themes verfolgt worden.
Unterklassen „erben“ zunächst alle Eigenschaften ihrer Oberklassen. Das bedeutet, dass
auch gemet:Group und gemet:Theme eine Hierarchie bilden können wie skos:Concept.
(Das illustriert nebenbei, warum eine Unterklasse von Concept kein Äquivalent zu den
UMTHES Nicht-Deskriptoren sein kann: sie würden damit alle Beziehungstypen von
Deskriptoren erben.)
Zusätzlich wurden spezifische semantische Relationen zwischen skos:Concept und
gemet:Group und gemet:Theme ergänzt.
Im UMTHES haben wir die sog. Ordnungsbegriffe und die Top-Terms. Beiden ist
gemeinsam, dass sie wegen ihrer großen Allgemeinheit nicht für die Indexierung empfohlen
werden, sie enthalten sprechende Namenszusätze wie „Benutze Unterbegriffe“. Ansonsten
verhalten sie sich wie gewöhnliche Deskriptoren. Es gibt auch keine speziellen Relationen in
diesem Zusammenhang. Daher erscheint eine spezialisierte Klasse in beiden Fällen
unangemessen.
Zur Kennzeichnung von Top-Terms sieht SKOS eine hasTopConcept-Relation zwischen
dem (2.6) ConceptScheme und den betreffenden Concepts vor.
Für Ordnungsbegriffe wurden auch (2.5) Concept Collections erwogen, aber schließlich fiel
die Entscheidung für die umt:usageNote unter den (3.2) Documentation Properties. In
dieser Note kann der Verwendungshinweis angemessen codiert werden.
2.5 (Keine) Concept Collections
Neben der Hierarchie ein weiteres von SKOS angebotenes Strukturelement für Concepts.
Wird in UMTHES bisher nicht explizit verwendet.
V 03 Umweltbundesamt S. 11

SNS UMTHES in SKOS DRAFT
Das Prinzip ist in einem verbreiteten Struktur-Beispiel dargestellt (keine Turtle Syntax):
und
============================================
wines
red wines
Burgundy
rose wines
white wines
Chardonnay
Chablis
Chenin Blanc
Johannisberg Riesling
Sauvignon Blanc
sweet wines
Chenin Blanc
Johannisberg Riesling
dry wines
Chardonnay
Chablis
Sauvignon Blanc
=================================================
Abbildung 3 Beispiel für Collections
Die Collections stehen hier in spitzen Klammern.
2.6 Concept Scheme Beispiel UMTHES und Umweltklassifikation
Ein Concept Scheme bezeichnet ein komplettes Vokabular, also hier z.B. „UMTHES“. Es
können im selben SKOS Graphen auch mehrere Vokabulare vorkommen, die Zuordnung der
Concepts (nicht der Labels!) erfolgt über skos:inScheme, für Top Terms mit
skos:topConceptOf.
Es besteht die Option, z.B. die Umweltklassifikation als eigenes Concept Scheme und jede
Umweltklasse als Concept zu modellieren, die dann mit Mapping Properties auf UMTHES
Concepts bezogen werden. Eine einfachere Alternative ist unter (3.1.2) Notation vs.
Enumeration beschrieben.
Der Umgang mit mehreren ConceptSchemes ist im Vorhaben nicht ausdrücklich gefordert
oder angeboten, würde aber der Umweltklassifikation zu mehr „Prominenz“ verhelfen, es
gäbe dann eine gepflegte Referenzadresse mit allen Zugriffsmöglichkeiten für Menschen und
Maschinen. Ein Beispiel findet sich im folgenden Kapitel.
2.7 Mapping Properties
Diese dienen zum Querverweis zwischen Concepts, die verschiedenen ConceptSchemes
angehören.
Es gibt hier verschiedene Ausprägungen, darunter auch Querverweise auf andere
Hierarchieebenen. Feine Unterschiede können mit exact, close oder related differenziert
werden.
V 03 Umweltbundesamt S. 12

SNS UMTHES in SKOS DRAFT
skos:mappingRelation
skos:closeMatch
skos:exactMatch
skos:broadMatch
skos:narrowMatch
skos:relatedMatch
Wenn die Umweltklassifikation als eigenes ConceptScheme modelliert wird, dann erfolgt die
Zuordnung der UMTHES Concepts über Mapping Properties.
Zunächst werden mit uk:uklass und umt:umthes die beiden ConceptSchemes definiert.
uk:uklass rdf:type skos:ConceptScheme;
dct:title "Umweltklassifikation"@de.
umt:umthes rdf:type skos:ConceptScheme;
dct:title "Umweltthesaurus"@de.
Dann wird beispielhaft eine Umweltklasse (uk:ab54) als skos:Concept in uk:uklass
initialisiert. Sie erhält ein (einfaches) skos:prefLabel in Deutsch, das durch ein englisches
ergänzt werden kann.
uk:ab54 rdf:type skos:Concept;
skos:prefLabel "AB 54 Abfallbeseitigung"@de;
skos:inScheme uk:uklass.
Abschließend wird beispielhaft ein Deskriptor (umt:00000477) als skos:Concept in
umt:umthes initialisiert. Dieser verweist auf ein skosxl:Label umt:abgasreinigung und ist
mit skos:closeMatch der Umweltklasse uk:ab54 zugordnet.
:00000477 rdf:type skos:Concept;
skosxl:prefLabel umt:abgasreinigung;
skos:inScheme umt:umthes
skos:closeMatch uk:ab54.
Codebeispiel 3 Mapping Properties am Beispiel UMTHES und Umweltklassifikation
Die Administration mehrerer skos:ConceptScheme in einem gemeinsamen Graphen
erfordert weitergehende Klärungen, z.B. ob es für jedes Scheme getrennte Hierarchien
geben soll. Mit SKOS ist lediglich gesagt, dass Mapping Properties und Semantic Relations
disjunkt sind. Aber ein noch nicht vernetztes Concept lässt sich dennoch ohne Weiteres
falsch initialisieren. Hier scheinen Erweiterungen des SKOS Modells erforderlich, wenn man
die beabsichtige Logik in der formalen Sprache ausdrücken will. Eine einfachere Variante
zum Umgang mit der Umweltklassifikation findet sich in Kap. 3.1.2, Notation vs.
Enumeration.
Die Zuordnung zu GEMET ist ein Mapping zu einem vollständig externen Vokabular. Es ist
nicht ganz korrekt, hier die Mapping Properties zu verwenden, wenn man damit auf die
jeweilige EEA-Webseite zeigt. Das Ziel einer Mapping Property ist selbst ein SKOS Concept.
Die SKOS Repräsentation von GEMET ist aber nicht über die darin enthaltenen URI
erreichbar (diese leiteten um auf die jeweilige Webseite). Letzeres ist aus formaler Sicht kein
Hinderungsgrund, der einen Verweis verbieten würde. Die im SKOS GEMET verwendeten
V 03 Umweltbundesamt S. 13

SNS UMTHES in SKOS DRAFT
URI sind die von der Autorität vergebenen Resource-IDs und als solche gültig, auch wenn
sie nicht unmittelbar dereferenziert werden können.
UMTHES hat jedoch Interesse, die EUA auf diesen Sachstand hinzuweisen. Die
Bereitstellung von GEMET ist aus Sicht des Semantic Web unvollständig und entspricht nicht
dem Stand der Technik [CoolURI].
:00000477 rdf:type skos:Concept;
skosxl:prefLabel umt:abgasreinigung;
skos:inScheme umt:umthes
skos:closeMatch uk:ab54
skos:closeMatch http://www.eionet.europa.eu/gemet/concept/9080
Codebeispiel 4 Mapping Properties für UMTHES und GEMET
Alle derartigen Zuordnungen im UMTHES können zunächst mit skos:closeMatch
abgebildet werden, wenn eine automatische Unterscheidung zwischen den Varianten nicht
möglich erscheint.
V 03 Umweltbundesamt S. 14

SNS UMTHES in SKOS DRAFT
3 Lexical Properties
Jedem Concept werden Wörter (Label) zugeordnet. Jedes Wort wird durch einen Namen
repräsentiert.
In natürlicher Sprache tauchen in erster Linie Wortformen auf. Dies können grammatisch
begründete (also Mehrzahl, Genitiv, Vergangenheit usw.) oder andere Varianten wie z.B.
Abkürzungen sein, die oft uneinheitlich sind. Diese ganze “Wolke” von Zeichenketten, durch
die ein Wort repräsentiert ist, wird als seine „lexikalische Form“ bezeichnet: „A lexical form is
an abstract unit representing a set of wordforms differing only in inflection and not in core
meaning.” 3
In einem etwas erweiterten Sinn reden wir auch von lexikalischen Eigenschaften (lexical
properties).
3.1 Einfache SKOS Eigenschaften
3.1.1 Lexical Labels
Ausgangspunkt ist ein sehr generisches rdfs:Label, mit dem sich jeder beliebigen Instanz
irgend einer Klasse Namen zuweisen lassen. Dabei wird Mehrsprachigkeit durch einen
Language Code unterstützt. Der Wert eines rdfs:Label muss nicht eine Zeichenkette sein,
es handelt sich um einen RDF literal value, was viele Möglichkeiten eröffnet. Meist wird aber
einfach der Name angegeben, mit dem das Objekt angezeigt werden soll („Vorlageform“).
Für RDF Tools ist es heute ein Standardverhalten, neben der ID (URL) einer Instanz auch
ihren Namen (rdfs:label) anzuzeigen, unter Berücksichtigung der aktuellen Sprache.
SKOS hat dieses Modell zunächst semantisch untergliedert in skos:prefLabel,
skos:altLabel und skos:hiddenLabel.
:00000577 rdf:type skos:Concept;
skos:prefLabel „Abgasreinigung“@de;
skos:altLabel „Abgasreinigungsanlage“@de.
Codebeispiel 5 Einfache Lexical Labels
Schließlich hat man darüber hinaus die Schwäche einer einfachen Wertzuweisung erkannt
und SKOS um XL Labels erweitert. Erst diese Erweiterung ermöglicht eine angemessene
Modellierung unter Einbeziehung aller in UMTHES gepflegten lexikalischen Eigenschaften.
Siehe dazu näher in (3.2) XL Labels.
3.1.2 Notation vs. Enumeration
Zwei gebräuchliche Methoden, um den Wertebereich von Lexical Lables zu formalisieren.
Notationen sind Zeichenketten mit Angabe eines „Datentyps“. Ein Beispiel wäre
skos:notation "K"^^
3 http://www.sil.org/linguistics/GlossaryOfLinguisticTerms/WhatIsALexicalForm.htm
V 03 Umweltbundesamt S. 15

SNS UMTHES in SKOS DRAFT
ist hier der „Datentyp“. Er wird durch eine URL angegeben.
Diese URL könnte zum Look-Up für den Wertevorrat führen, dies ist aber nicht ausdrücklich
standardisiert.
Man könnte sich nun vorstellen:
:concept4711 rdf:type skos:Concept;
skos:notation "AB10"^^
In diesem Modell können jedoch weder Codierung noch Wortgut oder Hierarchie der
Umweltklassifikation formal beschrieben werden. Letztlich besteht hier jede Notation aus
zwei beliebigen Zeichenketten, es fehlt ein Referenzsystem gültiger Umweltklassen.
Das in (2.6) Concept Scheme angesprochene Vorgehen über Mapping Properties ist
wesentlich aussagekräftiger (aber auch aufwändiger).
Ein Kompromiss, der das Wortgut berücksichtigt, wenn auch nicht eine formale Hierarchie,
liegt in einer Referenz auf eine flache Wertetabelle (Enumeration).
Im Schema:
(1) Die Wertetabelle umt:UmweltklasseEnum, jeder zugehörige Wert wird durch ein
„Individual“ aufgezählt (owl:oneof).
umt:UmweltklasseEnum owl:equivalentClass [
rdf:type owl:Class ;
owl:oneOf (umt:ab umt:ab10 umt:ab20 usw.… )
] .
(2) Jeder Wert erhält mehrsprachige Bezeichner.
umt:ab rdfs:label „AB Abfall“@de;
rdfs:label „AB Waste“@en.
umt:ab10 rdfs:label „AB10 Abfallentstehung, Abfallaufkommen, …“@de;
rdfs:label „AB10 Types and occurrence of waste“@en.
usw. für jede Umweltklasse.
(3) Eine Property (z.B. umt:classified) definieren und deren Wert mit der Wertetabelle
hinterlegen.
umt:classified rdf:type rdfs:ObjectProperty;
rdfs:range umt:UmweltklasseEnum.
In der Anwendung:
:concept4711 rdf:type skos:Concept;
umt:classified umt:ab10.
Codebeispiel 6 Umweltklassifikation als Enumeration
V 03 Umweltbundesamt S. 16

SNS UMTHES in SKOS DRAFT
3.2 XL Labels
SKOS eXtension for Labels (XL) ist als optionale Erweiterung im Standard enthalten. Sie
erlaubt komplexere lexikalische Modelle, in denen Labels selbst attributiert und miteinander
in Beziehung gebracht werden können.
skosxl:Label ist eine eigenständige Klasse. SKOS XL gibt ihr ein einziges vordefiniertes
Attribut skosxl:literalForm, das semantisch dem rdfs:label entspricht.
Da wir es aber nun mit einer Label-Klasse zu tun haben, können wir jedes Label um
zusätzlich Attribute erweitern und Labels zueinander in Beziehung setzten.
Dennoch können wir Concept und Label wie gewohnt verknüpfen: SKOS XL kennt drei
Relationen von skos:Concept zu skosxl:Label
skosxl:prefLabel - Vorzugsbegriff
skosxl:altLabel - Synonymverweis
skosxl:hiddenLabel – Interner Begriff, der nicht nach außen sichtbar sein soll.
Dies entspricht semantisch den einfachen SKOS Label Properties, aber hier wird der Wert
durch eine Referenz auf ein Label Objekt angegeben, nicht direkt als einfacher „Name“ des
Concepts.
Das schon verwendete Beispiel:
:00000577 rdf:type skos:Concept;
skos:prefLabel „Abgasreinigung“@de;
skos:altLabel „Abgasreinigungsanlage“@de.
… liest sich in SKOS XL:
:00000577 rdf:type skos:Concept;
skosxl:prefLabel :abgasreinigung;
skosxl:altLabel :abgasreinigungsanlage.
:abgasreinigung rdf:type skosxl:Label;
skosxl:lexicalForm „Abgasreinigung“@de.
:abgasreinigungsanlage rdf:type skosxl:Label;
skosxl:lexicalForm „Abgasreinigungsanlage“@de.
Codebeispiel 7 skos:Concept und skosxl:Label
Das macht so noch keinen erkennbaren Sinn, denn es sagt nicht mehr als die einfachere
skos: Variante. Die zusätzlichen Möglichkeiten ergeben sich aber daraus, dass sich nun
weitere Eigenschaften eines Labels beschreiben lassen als lediglich „der Name auf dem
Etikett“.
3.2.1 Eigenschaften von skosxl:Label
Das vordefinierte skosxl:Label kennt ausschließlich eine (1) lexikalische Form:
skosxl:literalForm – (genau 1) entspricht der „Vorlageform“, also z.B. mit
Qualifier oder Benutzungshinweis.
V 03 Umweltbundesamt S. 17

SNS UMTHES in SKOS DRAFT
Für UMTHES ergänzen wir jedes Label (bzw. dessen Vorlageform) um weitere Attribute:
� Kodierung des Endungsmusters:
umt:baseForm – „Ansetzungsform“.
umt:inflectionalCode – Endungscode.
� Aufzählung lexikalischer Varianten:
umt:lexicalVariant – (mehrfach) lexikalische Variante der Vorlageform.
Diese hat drei Formen:
Ein konstruiertes Beispiel:
umt:inflectional –einzelne, ausgeschriebene Flexionsformen.
umt:acronym – optional abgekürzte Schreibweisen.
umt:cultural – optional kulturell abweichende Schreibweisen.
:fernsehen rdf:type skosxl:Label;
skosxl:literalForm “Fernsehen“@de;
umt:baseForm “Fernsehe“;
umt:inflectionalCode “xyz”
umt:inflectional “Fernsehen”;
umt:inflectional “Fernsehens”;
umt:inflectional “Fernseher”;
umt:inflectional “Fernsehern”;
umt:acronym “TV”;
umt:cultural “Glotze”.
Abbildung 4 Erweiterte einfache Properties von skosxl:Label
Label-zu-Label Relationen können grundsätzlich beliebige Beziehungen zwischen Labels
ausdrücken. Der SKOS Primer erläutert dies am Beispiel von Abkürzungen. Da wir die
Abkürzung aber als ein Attribut der zugehörigen Vorlageform ansehen, folgen wir diesem
Beispiel nicht. Die Abkürzung ist aus unserer Sicht kein eigenes Label, da sie keine weiteren
Eigenschaften hat, die beschrieben werden müssten. Auch Varianten einer Abkürzung
können ohne Weiteres durch mehrfaches umt:acronym ausgedrückt werden.
Andererseits hätte man im obigen Beispiel aus „Glotze“ ein eigenes Label mit allen
zugehörigen Varianten machen können. Dies hängt letztlich von den jeweiligen Ressourcen
und Prioritäten ab. Aus formaler Sicht gilt:
Die Entscheidung für eine Label Relation fällt immer dann, wenn beide Beteiligte außer
ihrem jeweiligen Namen weitere eigenständige lexikalische Eigenschaften mitführen. In
diesem Fall instantiiert man zwei Labels und verbindet sie mir einer …
skosxl:labelRelation – zunächst unspezifische Relation zwischen zwei Labels,
dient lediglich als Erweiterungspunkt für spezifische Relationen.
UMTHES-Anwendungen:
V 03 Umweltbundesamt S. 18

SNS UMTHES in SKOS DRAFT
umt:translation – hier als direkte Beziehung zwischen Labels, nicht vermittelt
über ein gemeinsames Concept, dem Labels in mehreren Sprachen zugewiesen sind.
Letzteres sagt nicht ausdrücklich, welches Label welches andere Label übersetzt,
daher ist die direkte Zuordnung zwischen Labels präziser. Daraus kann nicht
abgeleitet werden, dass ein Label seinem Concept zwangsläufig einen Schwarm ihm
zugeordneter Übersetzungen „vererbt“. Beides ist unabhängig zu sehen.
umt:compoundFrom – ein zusammengesetztes Label zeigt auf eine Liste seiner
Komponenten (die selbst Labels sind), kann mehrfach vorkommen.
umt:hasQualifier – Ist die lexicalForm ein Homograph („Weide“), dann wird sie
mit einem Namenszusatz (=qualifier) ergänzt („Weide [Salix]“). Dieser Qualifier
(„Salix“) ist selbst ein Label.
umt:lexicalExtension – Wenn es für Labels lexikalische Varianten mit eigenen
Beugungsformen gibt, soll für jede dieser Varianten ein eigenes Label verwendet
werden. Dies gilt z.B. für alte und neue deutsche Rechtschreibung (:schiffahrt
:schifffahrt), aber möglicherweise auch für substantivische und Verbform
(:reinigung :reinigen).
Labels können darüber hinaus alle SKOS Documentation Properties verwenden. Dazu mehr
in Kap. 4 Documentation Properties.
Abschließend das Beispiel Abgasreinigungsanlage aus dieser Sicht. Zunächst die drei
elementaren Labels:
:abgas rdf:type skosxl:Label;
skosxl:literalForm “Abgas“@de;
umt:baseForm “Abgas“;
umt:inflectionalCode “CC”
umt:inflectional “Abgase”;
umt:inflectional “Abgases”;
umt:inflectional “Abgasen”.
:reinigung rdf:type skosxl:Label;
skosxl:literalForm “Reinigung“@de;
umt:baseForm “Reinigung“;
umt:inflectionalCode “D0”
umt:inflectional “Reinigungen”.
:anlage rdf:type skosxl:Label;
skosxl:literalForm “Anlage“@de;
umt:baseForm “Anlage“;
umt:inflectionalCode “D3”
umt:inflectional “Anlagen”.
Eine beispielhafte Übersetzung:
:wasteGas rdf:type skosxl:Label;
skosxl:literalForm “waste gas“@en;
… weitere Properties …
umt:translation :abgas.
Eine (experimentelle) lexicalExtension als Option:
V 03 Umweltbundesamt S. 19

SNS UMTHES in SKOS DRAFT
:reinigen rdf:type skosxl:Label;
skosxl:literalForm “reinigen“@de;
umt:baseForm “reinig“;
umt:inflectionalCode “??”
umt:inflectional “reinige”;
umt:inflectional “reinigen”;
umt:inflectional “reinigte”;
umt:inflectional “gereinigt”;
umt:inflectional “gereinigte”;
umt:inflectional “gereinigter”;
umt:inflectional “gereinigtes”;
umt:inflectional “reinigend”;
umt:inflectional “reinigende”;
umt:inflectional “reinigender”;
umt:inflectional “reinigendes”.
:reinigung umt:lexicalExtension :reinigen.
Einfache Zusammensetzungen, wie z.B. „Abgasreinigung“.
:abgasreinigung rdf:type skosxl:Label;
skosxl:literalForm “Abgasreinigung“@de;
umt:baseForm “Abgasreinigung“;
umt:inflectionalCode “D0”
umt:inflectional “Abgasreinigungen”;
umt:compoundFrom (:abgas :reinigung).
Komplexere Zusammensetzungen lassen sich mehrfach auflösen:
:abgasreinigungsanlage rdf:type skosxl:Label;
skosxl:literalForm “Abgasreinigungsanlage“@de;
umt:baseForm “Abgasreinigungsanlage“;
umt:inflectionalCode “D3”
umt:inflectional “Abgasreinigunganlagen”;
umt:compoundFrom (:abgas :reinigungsanlage);
umt:compoundFrom (:abgasreinigung :anlage).
Nutzung im Concept.
:00000477 rdf:type skos:Concept;
skosxl:prefLabel :abgasreinigung;
skosxl:altLabel :abgasreinigungsanlage.
Codebeispiel 8 Wortformen und Dekomposition
3.2.2 Asymmetrische Mehrsprachigkeit
SKOS ist mit Blick aus symmetrische Mehrsprachigkeit entstanden: ein Konzept kann
prefLabels in mehreren Sprachen haben, aber nur eines je Sprache. Das Concept selbst hat
keine „eigene“ Sprache, es wird angenommen, dass dieses Concept in allen Sprachen
bekannt ist.
Bei asymmetrischer Mehrsprachigkeit geht man davon aus, dass auch die Concepts
sprachspezifisch sind (es gibt keine vollständig exakte Übersetzung), daher sollte ein
Concept hier nur ein einziges prefLabel haben, und dessen Sprache entscheidet über die
Sprache des Concepts. Man könnte daraus auch explizite Unterklassen GermanConcept
und EnglishConcept ableiten.
V 03 Umweltbundesamt S. 20

SNS UMTHES in SKOS DRAFT
Was macht ein sprachabhängiges Concept überhaupt aus: nicht nur die Sprache des
zugeordneten Labels, sondern möglicherweise auch sprachabhängige Beziehungen, also
z.B. eigenständige Hierarchien in jeder Sprache. Diese Fragen sind bisher nicht vollständig
erschlossen und für UMTHES nicht ausgeführt, alle englischen Begriffe sind Nicht-
Deskriptoren. Daraus folgt, dass sie ausschließlich als skos:altLabel Verwendung finden:
also wird es ausschließlich deutsche Concepts in UMTHES 4 geben.
Als skosxl:altLabel können Label aller Sprachen uneingeschränkt an Concepts gebunden
werden. Dies sagt nur aus, dass all diese Wörter ungefähr dieses Concept beschreiben,
nicht aber welches von ihnen eine Übersetzung des Vorzugsbegriffs (skosxl:prefLabel) ist.
Auch Übersetzungsbeziehungen innerhalb der mehrsprachigen altLabels sind so nicht
erkennbar.
Daraus ergeben sich zwei Anforderungen:
(1) Labels sind einsprachig, und
(2) Explizite Übersetzungsbeziehungen (wenn gewollt) werden zwischen den Labels
direkt eingerichtet, nicht aus gemeinsamen Concepts abgeleitet.
Letztlich ist für die Zukunft auch die Möglichkeit zu betrachten, dass ein Vokabular sowohl
sprachspezifische als auch symmetrische mehrsprachige Concepts enthält.
:abfall rdf:type skosxl:Label;
skosxl:literalForm “Abfall“@de.
:waste rdf:type skosxl:Label;
skosxl:literalForm “waste“@en;
umt:translation :abfall.
Symmetrisch:
:00000112 rdf:type skos:Concept;
skosxl:prefLabel :abfall;
skosxl:prefLabel :waste.
Aymmetrisch:
:00000112 rdf:type skos:Concept;
skosxl:prefLabel :abfall;
:00000xyz rdf:type skos:Concept;
skosxl:prefLabel :waste.
Codebeispiel 9 Mehrsprachigkeit
3.2.3 Koordination
Dieses Strukturelement wird in UMTHES “Benutze Kombination” genannt. Man will z.B.
sagen:
4 SNS hat 2007 damit experimentiert, englische Deskriptoren und eine englische Hierarchie aus den
bestehenden Daten abzuleiten.
V 03 Umweltbundesamt S. 21

SNS UMTHES in SKOS DRAFT
Und nicht
Rauchgasentschwefelung USE (Rauchgas UND Abgasentschwefelung)
Rauchgasentschwefelung USE (Rauchgas ODER Abgasentschwefelung).
In SKOS 5 instanziieren wir zunächst zwei Concepts (Deskriptoren) :00020299 und
:00020299, die beide auf :rauchgasentschwefelung als altLabel verweisen.
:00020299 rdf:type skos:Concept;
skosxl:prefLabel :rauchgas;
skosxl:altLabel :rauchgasentschwefelung.
:00000442 rdf:type skos:Concept;
skosxl:prefLabel :abgasentschwefelung;
skosxl:altLabel :rauchgasentschwefelung.
Dies allein ist ein Hinweis, dass :rauchgasentschwefelung mit beiden Deskriptoren zu
tun haben kann. Zwischen den Deskriptoren besteht eine nicht-ausschließliche ODER-
Beziehung. Koordination oder Benutze-Kombination führt UND-Beziehungen zwischen
benannten Deskriptoren ein. (Es kann auch vorkommen, dass einem Label drei Deskriptoren
zugeordnet sind, aber nicht alle tauchen in einer Koordination auf).
Dies lässt sich als Relation vom Label auf eine RDF Liste von koordinierten Deskriptoren
ausdrücken wie in nachstehendem Beispiel.
:rauchgasentschwefelung rdf:type skosxl:Label;
umt:coordinationOf (:00020299 :00000442).
Codebeispiel 10 Koordination
5 Das folgende übernimmt im Wesentlichen ein Beispiel aus dem SKOS Primer.
V 03 Umweltbundesamt S. 22

SNS UMTHES in SKOS DRAFT
4 Documentation Properties
Diese Eigenschaften sind von owl:AnnotationProperty abgeleitet und unterscheiden sich
lediglich nach der im Namen angedeuteten Aufgabe, nicht aber hinsichtlich ihrer inneren
Struktur.
4.1 SKOS Note Typenübersicht
--- FUSSNOTE1 Umt:Deskriptor erfordert als Äquivalent zu skos:Concept als wesentlichem Inhalt eine
Begriffsdefinition. Diese wird als Definition oder als scopeNote abgelegt. In UMTHES liegen
Begriffsdefinitionen derzeit für etwa von 11 493 Deskriptoren vor (Stand 22.5.2009). Vorübergehend
könnte eine möglichst eindeutige Begriffsbenennung an Stelle einer Definition stehen. BK-NDs in
UMTHES stellen eigene Begriffe dar …
� Die UMTHES Bemerkungs-Typen
T0808 „role“ nach TI808-Schlüssel gekennzeichnet übernehmen
� Weitere Quellattribute
b Definition
a Quelle der Anregung
c Benutzungshinweise
d red. Bemerkung
V 03 Umweltbundesamt S. 23

SNS UMTHES in SKOS DRAFT
In der folgenden Übersicht über die vordefinierten skos:Note Klassen sind Definitionen
(skos:definition) aus dem SKOS RDF Schema in kursiv angegeben.
Note SKOS UMTHES
skos:note A general note, for any purpose. Verwendung generell so nicht empfohlen.
Alle Notes erhalten Datum und
Bearbeiterkürzel.
semantisch:
skos:definition A statement or formal explanation
of the meaning of a concept.
skos:example An example of the use of a
concept.
skos:scopeNote A note that helps to clarify the
meaning and/or the use of a
concept.
redaktionell:
skos:changeNote A note about a modification to a
concept.
skos:editorialNote A note for an editor, translator or
maintainer of the vocabulary.
skos:historyNote A note about the past
state/use/meaning of a concept.
erweitert:
Tabelle 2 skos:Note Unterklassen und UMTHES Dokumentation
(Text) Typ b. Liegen für die meisten
Deskriptoren vor. Teilweise aber im Sinne
von Scope Notes.
Bisher nicht ausgewiesen.
(Text) Eventuell Typ c. Kann aber auch als
Typ b vorkommen?
(Text) Datum und Bearbeiter kommen aus
anderen Feldern. Notes dazu wohl unter Typ
d? siehe Tabelle …
(Text) Typ d.
(Text) Wenn dann bisher unter Typ d.
umt:exportNote --- Strukturierte Daten, WLISN und THSISN
umt:sourceNote --- (Text) Typ a.
umt:usageNote --- Typ c?
Enumeration, z.B. Kennzeichnung von OD.
Beispiel: umt:00041004
umt:usageNote umt:useLower;
umt:editorialState --- Quelle kennt mehrere Stati, siehe Tabelle
…in Kap. 3
umt:expirationNote --- Strukturierte Daten
V 03 Umweltbundesamt S. 24

SNS UMTHES in SKOS DRAFT
Weder OWL noch SKOS machen irgendeine Einschränkung zum Wertebereich (range) von
Notes. Der SKOS Primer beschreibt aber drei empfohlene Patterns 6 :
� "documentation as an RDF literal",
� "documentation as a related resource description”
� "documentation as a document reference"
Hier ein Beispiel für Related Resource Description aus dem SKOS Primer:
ex:tomato skos:changeNote [
rdf:value "Moved from under 'fruits' to under 'vegetables'"@en;
dct:creator ex:HoraceGray;
dct:date "1999-01-23"
].
Codebeispiel 11 related resource description
Mit diesen einfachen Mitteln kann man buchstäblich Alles zu Allem anmerken. Die in (2.2)
Identität und Referenz begründete exportNote (historyNote) kann dann z.B. so aussehen:
:abgas umt:exportNote [
umt:source ;
umt:wlisn “00025534”;
umt:ndThsisn “00000426”;
dct:date "2009-05-23"
].
Dieses Beispiel enthält die WLISN (umt:wlisn) und die THSISN des ehemals zugehörigen
Nicht-Deskriptors (umt:ndThsisn) für ein Label mit neuer ID umt:abgas.
Wir wollen die Nachrichtendaten aber etwas genauer typisieren.
4.2 DCTERMS in Documentation Properties
Es ist gute Praxis, bei der Dokumentation Dublin Core Terms (dct:) zu verwenden,
insbesondere eine Auswahl aus den “Properties in the /terms/ namespace” 7 :
abstract, accessRights, accrualMethod, accrualPeriodicity, accrualPolicy,
alternative, audience, available, bibliographicCitation, conformsTo,
contributor, coverage, created, creator, date, dateAccepted,
dateCopyrighted, dateSubmitted, description, educationLevel, extent,
format, hasFormat, hasPart, hasVersion, identifier, instructionalMethod,
isFormatOf, isPartOf, isReferencedBy, isReplacedBy, isRequiredBy, issued,
isVersionOf, language, license, mediator, medium, modified, provenance,
publisher, references, relation, replaces, requires, rights, rightsHolder,
source, spatial, subject, tableOfContents, temporal, title, type, valid.
Infrage kommen z.B.:
6 http://www.w3.org/TR/skos-primer/#secadvanceddocumentation
7 http://dublincore.org/documents/dcmi-terms/#H2
V 03 Umweltbundesamt S. 25

SNS UMTHES in SKOS DRAFT
dct:created Date of creation of the resource.
dct:creator An entity primarily responsible for making the resource.
dct:date A point or period of time associated with an event in the lifecycle
of the resource.
dct:dateSubmitted Date of submission of the resource.
dct:dateAccepted Date of acceptance of the resource.
dct:isReplacedBy A related resource that supplants, displaces, or supersedes the
described resource.
dct:modified Date on which the resource was changed.
dct:source A related resource from which the described resource is derived.
Tabelle 3 Ausgewählte Dublin Core Terms
Allen gemeinsam ist es, dass sie eine “resource” beschreiben, die im Kontext der
skos:Note nicht mehr eindeutig scheint: handelt es sich um die Note selbst oder um das,
was die Note annotiert? Ein dct:created in einer Note würde üblicherweise auf die Note
selbst bezogen werden, denn diese erscheint in der Rolle der resource. Wenn das
dct:created eines Concepts gemeint ist, dem die Note zugordnet ist, würde man
erwarten, dass dieses dct:created dem Concept selbst zugewiesen wird und nicht der
Note.
Um diese Ambivalenz aufzulösen, wird folgendes empfohlen:
(1) Alle Notes können mit DCT attributiert werden, diese beschreiben dann die Note selbst.
(2) DCT, die das Zielobjekt (Concept oder Label) der Note beschreiben, müssen diesem
selbst zugewiesen sein. Dies wird hier aber nicht empfohlen.
(3) Stattdessen wird zu jedem benötigten DCT eine gleichnamige subProperty im UMTHES
Namensraum („umt“) definiert. Diese subProperty beschreibt in der Note nicht die Note,
sondern das Zielobjekt. (OWL 2 „Property Chain“).
Beispiel im Schema:
umt:created rdfs:subPropertyOf dct:created.
Anwendung im lokalen Namensraum “umt” wie nachstehend:
:abgas rdf:type skosxl:Label;
skos:historyNote :thisNote
:thisNote: dct:created „2009-05-25“;
umt:created „1999-01-01“.
Codebeispiel 12 Beschreibung von Note und Zielobjekt
Diese Note wurde am „2009-05-25“ angelegt und sagt uns, dass das Label :abgas am „1999-
01-01“ entstanden ist.
V 03 Umweltbundesamt S. 26

SNS UMTHES in SKOS DRAFT
4.3 Datentypen für UMTHES Notes
Wenn man die Freiheiten der Related Resource Description durch typisierte Eigenschaften
zügeln möchte, so kann man spezialisierte „Dokument-Typen“ für die einzelnen
Ausprägungen von skos:Note definieren und diese nach dem Muster „Documentation as a
document reference“ verwenden.
Nachstehend einige Entwürfe für solche Dokument-Typen.
4.3.1 Alle Texttypen
Geeignete Note-Typen sind etwa:
skos:definition
skos:example
skos:scopeNote
skos:changeNote
skos:editorialNote
skos:historyNote
Diese Notes erhalten einen Freitext-Attribut umt:content und können zusätzlich Dublin
Core Terms verwenden.
:00000112 rdf:type skos:Concept;
skosxl:prefLabel:abfall;
skos:definition :tb-2009-05-23.
:tb-2009-05-23 rdf:type umt:TextNoteData;
umt:content „ Bewegliche Sachen deren sich der Besitzer entledigen
will”;
dct:source „1000 schnelle Definitionen”;
dct:created „2009-05-23”;
dct:creator :tb.
Codebeispiel 13 Texttyp für Notes
4.3.2 usageNote
Domain: nur skos:Concept
Range: umt:UsageNoteEnum
Die UMTHES Erweiterung „usageNote“ (siehe 2.4) erhält eine Aufzählung („Enumeration“)
der gültigen Werte, die dem heutigen Namenszusatz von Ordnungsbegriffen entspricht, also
z.B. „Benutze Unterbegriffe“ wie in den Beispielen für Abfall als Ordnungsbegriff (oben) und
als Deskriptor (unten).
Schema:
umt:UsageNoteEnum owl:equivalentClass [
rdf:type owl:Class ;
owl:oneOf ( umt:useNarrower umt:useNarrowerRelated )
] .
Anwendung Ordnungsbegriff:
:00041004 rdf:type skos:Concept;
V 03 Umweltbundesamt S. 27

SNS UMTHES in SKOS DRAFT
umt:usageNote umt:useNarrower;
skosxl:prefLabel :abfall.
Anwendung Deskriptor (keine usageNote):
:00000112 rdf:type skos:Concept;
skosxl:prefLabel :abfall.
Codebeispiel 14 usageNote
Ein ausführlicheres Beispiel für eine Enumeration siehe Codebeispiel 6 Umweltklassifikation
als Enumeration, S. 16.
4.3.3 expirationNote
Domain: skos:Concept oder skosxl:Label
Range: umt:ExpirationNoteData
:00000112 rdf:type skos:Concept;
skosxl:prefLabel:abfall;
umt:expirationNote :tb-2009-05-23.
:tb-2009-05-23 rdf:type:ExpirationNoteData;
dct:created „2009-05-23”;
dct:created :tb;
umt:bestBefore „2009-06-01”;
umt:final „2010-01-01”;
umt:reason „Some Reason”;
umt:isReplacedBy umt:12345678.
Codebeispiel 15 expirationNote
Wäre am Ende des Beispiels nicht umt:isReplacedBy, sondern dct:isReplacedBy
verwendet, so würde die Note ersetzt und nicht das verfallende Concept.
4.3.4 editorialState
Domain: skos:Concept oder skosxl:Label
Range: umt:EditorialStateData
:00000112 rdf:type skos:Concept;
skosxl:prefLabel:abfall;
umt:editorialState :tb-2009-05-23.
:tb-2009-05-23 rdf:type :EditorialStateData;
dct:created „2009-05-23”;
dct:created :tb;
umt:state umt:onEdit;
umt:reminder „2010-01-01”;
umt:editor :tb;
umt:reviewer :fo
umt:remark „Hello”@en.
Für umt:state gibt es seine Werteauswahl
umt:EditorialStateEnum owl:equivalentClass [
rdf:type owl:Class ;
owl:oneOf ( umt:onEdit umt:editClosed umt:onReview umt:approved )
] .
V 03 Umweltbundesamt S. 28

SNS UMTHES in SKOS DRAFT
umt:reminder (optional) gilt als “Wiedervorlagedatum”.
Codebeispiel 16 editorialState
4.3.5 exportNote
Domain: skos:Concept oder skosxl:Label
Range: umt:ExportNoteData
In Kap. 2.2, Identität und Referenz wurde begründet, warum Concepts und Labels die bisher
in vergebenen ISN mitführen sollten. Dies ist hier umgesetzt. Zusätzlich ein
Verweise auf die Quelle, so dass mehrere gleichartige Quellen unterstützt werden können.
:abgas rdf:type skosxl:Label;
skosxl:lexicalForm “Abgas”@de;
umt:exportNote :ex-2009-05-23.
:ex-2009-05-23 rdf:type umt:ExportNoteData
dct:created „2009-05-23”;
dct:creator :auto;
umt:source ;
umt:wlisn “00025534”;
umt:ndThsisn “00000426”.
Codebeispiel 17 exportNote
Welche Verweise im einzelnen genutzt werden sollten, ist nachstehender Tabelle zu
entnehmen.
ISN Referenz Anwendung
umt:wlisn Alle Label. (Unabhängig von einer Konvention hinsichtlich der Label
URI).
umt:thsisn Alle Concept. (Unabhängig von einer Konvention hinsichtlich der
Concept URI).
umt:ndThsisn Alle Labels die in aDis auf Nicht-Deskriptoren zeigen, geben deren
THSISN hier an. Er würde sonst im SKOS Format verloren gehen.
Tabelle 4 Verweise aus umt:exportNote auf die ISN
V 03 Umweltbundesamt S. 29

SNS UMTHES in SKOS DRAFT
5 UMTHES Entitäten in SKOS
Dies ist die Checkliste, ob alle benötigten UMTHES Daten im (erweiterten) SKOS Modell
berücksichtigt worden sind.
Zurzeit noch externes EXCEL in Arbeit.
V 03 Umweltbundesamt S. 30