Im wundervollen Vortrag "Design in Practice" spricht Rich Hickey davon, wie wichtig ein aktuelles Glossar im Designprozess ist.
Ich sehe das ganz ähnlich, und sehe etwas wie "Business Knowledge Blueprints" als wichtige Grundlage für geschäftliche Anwendungen und besonders für Datenmodelle und (Enterprise) Knowledge Graphs.
Heute wurde ich allerdings auf die Idee gebracht, formale Definitionen gleich mit in ein Glossar zu schreiben. Die Web Ontology Language (OWL) ist als eine Beschreibungslogik definiert, die, wie im Namen angedeutet, vor allem dafür geeignet sind einen Ausschnitt der Welt bzw. die Entitäten im Universe of Discourse zu beschreiben bzw. zu klassifizieren.
Eine spezialisierte Ontologie für die Beschreibung von Glossaren, Taxonomien und Folksonomien ist das Simple Knowledge Organization System (SKOS), das ich für jedes neue Glossar empfehle.
Eindeutige Namen?
Rich spricht auch davon, wie wichtig eindeutige Begriffe oder Namen im Glossar sind, und nennt als Beispiel den Begriff "Kunden".
Hier habe ich meine Zweifel: gerade der Begriff "Kunde" ist meiner Ansicht nach nicht dazu geeignet, eindeutig definiert zu werden. Wenn ich in Firmen bin, verstehen Verkäufer, Management, Rechnungsabteilung und Mitarbeiter im End"kunden"-Kontakt oft etwas recht unterschiedliches unter "unsere Kunden".
Und bei aller Mühe, z.B. Supportmitarbeiter dazu zu verdonnern "Nutzer", "Klient" oder ähnliches zu sagen, im täglichen Sprachgebrauch wird das doch oft zu "unsere Kunden wollen ...".
Hier bin ich froh, dass in RDF und damit in OWL mit den Präfixen so etwas wie Namensräume geschaffen werden, die es mir ermöglichen so etwas abzubilden, indem ich etwa accounting:customer oder support:customer benutze.
Eindeutige Bezeichner von Individuen - im Gegensatz zu Begriffen in einem Glossar - sind im Bereich ETL extrem wichtig, aber auch bei der Vernetzung von strukturierten und unstrukturierten Daten. Dafür definiere ich in jedem meiner Projekte URLs für jedes Individuum als permanente ID. Das ist natürlich von den Grundsätzen der Linked Data "geklaut", und doch betone ich es gerne als eigenes Konzept "PermID", um die Wichtigkeit für die eindeutige Vernetzung von Informationen hervorzuheben.
Beispiele
Schauen wir uns eine Sache an, die fast niemand definiert: eine Adresse. Was bedeutet das für Ihr Beispiel?
Ich greife gerne auf die öffentlich verfügbare Ontologie gist von Semantic Arts zurück, um Ideen für die Definition von Konzepten zu erhalten. gist ist minimalistisch, aber ziemlich präzise in seinen Definitionen.
Adresse
Wenn wir uns die Definition für physische Adressen ansehen, sehen wir, dass es sowohl eine gist:StreetAddress als auch eine gist:PostalAddress gibt. In der Beschreibung, die als Glossareintrag gesehen werden kann, wird eine gist:StreetAddress definiert als "Eine Adresse, die auf einen festen Ort in der physischen Welt verweist", während die Definition von gist:PostalAddress lautet: "Eine Reihe von Codes, die die Postbehörden verwenden können, um physische Post zuzustellen".
Das ist ein ziemlicher Unterschied. Und ich denke, gist:StreetAddress ist nicht ideal benannt: es gibt "Adressen" in der physischen Welt, die nichts mit Straßen zu tun haben.
Und während gist als eine "Ontologie" definiert ist, haben beide Konzepte keine formale Definition, wenn wir uns die OWL-Version davon ansehen :)
Offensichtlich haben die Autoren beschlossen, dass eine Definition für eine Ontologie der oberen Ebene zu restriktiv wäre. Aber vielleicht wäre es in einem spezifischen Projekt von Vorteil, eine formale Definition hinzuzufügen, die sich auf tatsächlich verwendete Datenstrukturen bezieht.
Aber dies zeigt, dass OWL ein guter Weg sein kann, um Gloassaries zu verwalten. Man kann textuelle Beschreibungen definieren, sogar mit mehr semantischer Bedeutung als "nur" Text. gist:StreetAddress zum Beispiel als skos:ScopeNote, die besagt "Dies schließt Adressen aus, die nicht mit einem festen Ort verbunden sind, wie z.B. ein Postfach oder ein FPO-Code.". Allein das Vorhandensein von "ScopeNotes" kann die Benutzer dazu anregen, derartige Notizen hinzuzufügen, was zu genaueren Definitionen führt.
Die Bedeutung von skos:ScopeNote selbst findet sich im Simple Knowledge Organization System: "skos:scopeNote liefert einige, möglicherweise partielle, Informationen über die beabsichtigte Bedeutung eines Konzepts, insbesondere als Hinweis darauf, wie die Verwendung eines Konzepts in der Indexierungspraxis eingeschränkt ist. [...]" SKOS-Fibel
Spezifikation
Schauen wir uns ein etwas formaler definiertes Beispiel an, eine Spezifikation.
Erinnern Sie sich, gist ist eine Ontologie der oberen Ebene, daher sind die Spezifikationen sehr hoch, um sie in vielen verschiedenen Kontexten nutzbar zu machen.
Dennoch definiert gist zwei Arten von Spezifikationen, eine Produkt- und eine Dienstleistungsspezifikation. Und für beide gibt es eine formale Definition. Schauen wir uns das mal an:
Die natürlichsprachliche Definition von gist:ProductSpecification besagt: "Etwas anbieten, das physisch gelagert oder digital gespeichert werden kann." und für gist:ServiceSpecification heißt es: "Eine Beschreibung von etwas, das für eine Person oder Organisation getan werden kann (was eine Form von Handlung hervorbringt).".
Beide Definitionen sind prägnant, klar und beschreiben den Unterschied ("physisch" vs. "kann getan werden"), aber wenn man sich die formale Definition ansieht, könnte man über einige zusätzliche Details überrascht sein:
gist:ProductSpecification
a owl:Class ;
owl:equivalentClass [
a owl:Class ;
owl:intersectionOf (
gist:CatalogItem
[
a owl:Restriction ;
owl:onProperty gist:isCategorizedBy ;
owl:someValuesFrom gist:ProductCategory ;
]
) ;
] ; [...].
gist:ServiceSpecification
a owl:Klasse ;
owl:equivalentClass [
a owl:Class ;
owl:intersectionOf (
gist:CatalogItem
[
a owl:Restriction ;
owl:onProperty gist:isBasisFor ;
owl:someValuesFrom gist:Event ;
]
) ;
] ; [...].
Beide definieren ihre Spezifikationen als ein gist:CatalogItem. Also als etwas, das verkauft werden soll. Das bedeutet, dass es explizit rein interne Spezifikationen ausschließt, was ich ziemlich überraschend finde.
Auch gist:ServiceSpecification sagt klar, dass es die Basis für ein gist:Event ist, und wir könnten in der Definition nachschlagen, um herauszufinden, dass ein gist:Event (nicht ein "Event") als gist:Behaviour mit einer gist:startDateTime und einer gist:endDateTime definiert ist, also etwas, das tatsächlich in der Welt passiert.
Und die gist:ProductSpecification ist ein gist:CatalogItem, das durch eine gist:ProductCategory kategorisiert ist. Auch eine Definition, die ich aus dem natürlichsprachlichen Text nicht vermutet hätte: nur etwas, das in eine gist:ProductCategory kategorisiert ist, wird tatsächlich als ProductSpecification akzeptiert.
Beachten Sie auch die Details, dass eine Spezifikation im Katalog steht, nicht ein Produkt. Das ist ziemlich offensichtlich, wenn man darüber nachdenkt, aber oft sagen wir: "Dieses Produkt gehört in unseren Katalog/Angebot/....".
Hier zwingt uns eine formale Definition dazu, präziser zu denken und zu handeln. Ich denke auch, dass es den Unterschied zwischen einem Glossar und der Alltagssprache deutlicher macht, wenn wir über die Bedeutung von clientXY:customer sprechen und nicht nur über "Kunde".