Modellierungsprinzipien

Aus CIDOC-CRM

Wechseln zu: Navigation, Suche

INHALT:  Einführung |  Ziele |  Anwendungsbereich |  Kompatibilität |  Angewandte Form und Syntax |  Modellierungsprinzipien |  Beispiele |  Hierarchien der Klassen & Eigenschaften


Die Entwicklung des CIDOC-CRM orientierte sich an folgenden Modellierungs-Prinzipien.

Inhaltsverzeichnis

Monotonie

Da die primäre Aufgabe des CRM die Integration von Informationen in einer "Offenen Welt" ist, zielt das CRM darauf ab, monoton im Sinne der Domänentheorie zu sein. D.h. die existierenden CRM Konstrukte und davon abgeleitete Deduktionen sollen immer gültig und wohl geformt sein, selbst wenn von Erweiterungen dem CRM neue Konstrukte hinzugefügt werden.

Zum Beispiel: Eine neue Unterklasse soll der Klasse E7 Handlung hinzugefügt werden, um die Gewohnheit einer Instanz einer Gruppe während eines gewissen Zeitraums zu beschreiben, einen bestimmten Namen für einen Ort zu benutzen. Durch diese Erweiterung werden keine der bereits existierenden IsA Beziehungen oder Eigenschaftsvererbungen beeinträchtigt.

Außerdem zielt das CRM auf die formale Erhaltung der Monotonie ab, wenn ein bestimmtes CRM-kompatibles System angereichert werden soll. D.h. wenn neue Instanzen, die von dem Fachbereichsexperten als konsistent betrachtet werden, dem System hinzugefügt werden, sollten die schon existierenden CRM Instanzen, ihre Eigenschaften und die davon abgeleiteten Deduktionen immer gültig und wohlgeformt bleiben.

Zum Beispiel: Beschreibt jemand zutreffender weise, dass ein Objekt eine Instanz der Klasse E19 Materieller Gegenstand ist, und wird später das Objekt, gleichfalls korrekt, als Instanz der Klasse E20 Biologischer Gegenstand charakterisiert, sollte das System nicht aufhören, es immer auch noch als Instanz der Klasse E19 Materieller Gegenstand anzusehen.

Um Monotonie in den häufigen Fällen alternativer Meinungen formal aufrecht zu erhalten, sollten alle formal definierten Eigenschaften als "unconstraint" (many:many)" implementiert werden, so dass widersprüchliche Instanzen von Eigenschaften lediglich angesammelt werden. So dient das über das CRM integrierte Wissen als Forschungsgrundlage, indem es relevante alternative Meinungen um wohl definierte Entitäten ansammelt. Schlussfolgerungen über die Wirklichkeit hingegen sind Aufgabe der fortlaufenden Hypothesenbildung in Forschung und Wissenschaft.

Zum Beispiel: Eine tatsächlich nachgewiesene Person wie El Greco oder selbst eine aus Sagen bekannte Person wie König Arthur sollten immer als eine Instanz der Klasse E21 Person behandelt werden und als innerhalb unseres Diskurses existierend behandelt werden, nachdem sie als solche in unsere Wissensbank eingeführt wurden, unabhängig ob sie wirklich gelebt haben oder nicht. Alternative Meinungen über ihre Eigenschaften wie z.B. über Geburts- und Aufenthaltsorte sollten ohne Gültigkeitsentscheidungen während der Datenansammlung akkumuliert werden.

Minimalität

Obwohl der Wirkungsbereich des CRM sehr weit ist, ist das Model selbst so sparsam wie möglich konstruiert.

  • Eine Klasse wird nur deklariert, soweit sie als Ausgangsklasse oder Zielklasse einer Eigenschaft benötigt wird, die nicht für ihre Überklasse geeignet ist, oder sich als Schlüsselkonzept im praktischen Anwendungsbereich erweist.
  • CRM Klassen und Eigenschaften, die eine gemeinsame Oberklasse besitzen, sind normaler Weise nicht exklusiv. Zum Beispiel kann ein Objekt beides sein, eine Instanz der Klasse E20 Biologischer Gegenstand und eine Instanz der Klasse E22 Künstlicher Gegenstand (z.B. ein bearbeiteter Elefantenzahn [Elfenbein])
  • CRM Klassen und Eigenschaften sind entweder primitiv oder Schlüsselkonzepte im praktischen Anwendungsbereich.
  • Komlemente von CRM Klassen werden nicht deklariert.

Abkürzungen

Einige Eigenschaften sind als Abkürzungen von längeren, reicher gegliederte Pfaden erklärt, die die gleiche Ausgangsklasse und Zielklassen wie die abgekürzt Eigenschaf über eine oder mehrere dazwischen liegende Klassen verbinden. Zum Beispiel stellt die Eigenschaft von E18 Materielles.P52 hat derzeitigen Besitzer (ist derzeitiger Besitzer von):E39 Akteur, eine Abkürzung des vollständigen Pfades: E18 Materielles über E8 Erwerb zu E39 Akteur dar. Eine Instanz des vollständigen Pfades impliziert immer eine Instanz der Abkürzungseigenschaft. Jedoch ist der umgekehrte Fall nicht immer richtig; eine Instanz des vollständigen Pfades kann nicht immer von einer Instanz der Abkürzungseigenschaft abgeleitet werden.

Die Klasse E13 Merkmalszuweisung erlaubt eine Dokumentation dessen, wie eine Zuweisung irgendeiner Eigenschaft zustande kam und wessen Meinung sie war, und das sogar in Fällen nicht explizit gekennzeichneter Eigenschaften.

Disjunkte Klassen

Klassen sind disjunkt, wenn sie in der wirklichen Welt keine gemeinsamen Instanzen in irgendeiner möglichen Welt besitzen. Im CRM gibt es viele Beispiele für disjunkte Klassen.

Eine umfassende Erklärung aller denkbaren disjunkten Klassenkombinationen im CRM wurde hier nicht bereit gestellt. Der praktische Wert einer solchen Auflistung ist fraglich und könnte leicht dem Ziel der Bereitstellung von kurzen und klaren Definitionen entgegenstehen. Jedoch gibt es zwei Schlüsselbeispiele disjunkter Klassenpaare, die für ein effektives Verständnis des CRM grundlegend sind:

  • E2 Geschehendes ist disjunkt von E77 Seiendes. Instanzen der Klassen E2 Geschehendes sind Perdurante während Instanzen der Klasse E77 Seiendes Endurante sind. Obwohl Instanzen der Klasse E77 Seiendes sich durch eine zeitlich begrenzte Existenz auszeichnen, sind sie in ihrer Natur fundamental verschieden von Instanzen der Klasse E2 Geschehendes, da sie ihre Identität über Ereignisse hinweg bewahren. Die Kennzeichnung von Enduranten und Perduranten als disjunkte Klassen stimmt überein mit den in den Datenstrukturen gemachten Unterscheidungen, die unter den pragmatischen Anwendungsbereich des CRM fallen.
  • E18 Materielles ist disjunkt von E28 Begrifflicher Gegenstand. Die Unterscheidung besteht eigentlich zwischen Materiellem und Immateriellem, welches letzteres auch noch ausschließlich künstlich ist. Instanzen der Klasse E18 Materielles und E28 Begrifflicher Gegenstand unterscheiden sich in vielfacher Hinsicht; so bedingt z.B. die Herstellung von Instanzen der Klasse E18 Materielles die Einarbeitung von physikalischem Material, was bei der Herstellung von Instanzen der Klasse [[E28 begrifflicher Gegenstand] nicht der Fall ist. In ähnlicher Weise verlieren Instanzen der Klasse E18 Materielles ihre Existenz, wenn sie zerstört werden, während Instanzen der Klasse E28 Begrifflicher Gegenstand nur dann ihre Existenz verlieren, wenn sie vergessen werden oder ihr letzter materieller Träger zerstört wird.

Über Typen

So gut wie alle strukturierten Beschreibungen von Museumsobjekten beginnen mit einem eindeutigen Objekt-Kennzeichen und Informationen über den "Typus" des Objekts, oft vermittels einer Gruppe von Feldern mit Namen wie "Klassifizierung", "Kategorie", "Objekttyp", "Objektname" etc.. All diese Felder werden für Begriffe benutzt, die erklären, dass das Objekt zu einer bestimmten Kategorie von Dingen gehört. Im CRM umfasst die Klasse E55 Typus solche Begriffe aus Thesauren und kontrolliertem Vokabularen, die verwendet werden, um Instanzen von CRM Klassen zu charakterisieren oder zu klassifizieren. Instanzen von E55 Typus stellen Konzepte (Allgemeingültiges) dar, im Gegensatz zu Instanzen von E41 Benennung, die benutzt werden, um Instanzen von CRM Klassen zu benennen.

E55 Typus stellt die Schnittstelle des CRM zu fachbereichsspezifischen Ontologien und Thesauren dar. Diese können im CRM als Unterklassen von E55 Typus dargestellt werden und Begriffshierarchien bilden, d.h. Instanzen von E55 Typus verknüpft über P127 hat den Oberbegriff (hat den Unterbegriff). Solche Hierarchien können durch zusätzliche Eigenschaften erweitert werden.

Die Klasse E1 CRM Entität ist die Ausgangsklasse (Domäne) der Eigenschaft P2 hat den Typus (ist Typus von) mit der Zielklasse E55 Typus. Deshalb erbt jede Klasse des CRM, mit Ausnahme der Klasse E59 Primitiver Wert, die Eigenschaft P2 hat den Typus (ist Typus von). Dies stellt einen generellen Mechanismus bereit, um eine Spezialisierung der Klassifikation von CRM Instanzen auf beliebig feine Detailebenen zu simulieren, indem eine Verbindung zu externen Vokabularen, Thesauren, Klassifikationsschemata oder Ontologien hergestellt wird.

Analog zur Funktion der Eigenschaft P2 hat den Typus (ist Typus von) sind einige Eigenschaften im CRM mit einer zusätzlichen Eigenschaft assoziiert, diese sind im CRM mit einer '.1' Erweiterung nummeriert. Die Zielklassen dieser Eigenschaftseigenschaften fallen immer unter E55 Typus. Ihr Zweck ist es, eine Spezialisierung der Ursprungseigenschaft durch Untereigenschaften zu simulieren, die als Instanzen von E55 Typus erklärt werden. Sie erscheinen nicht in der Auflistung der Eigenschaftshierarchien, sondern sind als Teil der Erklärungen der Eigenschaften im CRM enthalten und werden in den Erklärungen der Klassen angeführt. Z.B. P62.1 Art der Abbildung:E55 Typus ist assoziiert mit E24 Hergestelltes.P62 bildet ab (wird abgebildet durch):E1 CRM Entität.

Die Klasse E55 Typus dient auch als Zielklasse von Eigenschaften, die auf kategorisches Wissen Bezug nehmen, das gemeinhin in der Dokumentation kulturhistorischer Disziplinen gefunden wird. Z.B. befähigt die Eigenschaft P125 benutzte Objekt des Typus (Objekt des Typus ... wurde benutzt in) das CRM Aussagen zu treffen wie "Dieser Abguss wurde unter Verwendung einer Gussform hergestellt", d.h. das ein unbekanntes oder unerwähntes Objekt gegeben hat, eine "Gussform", die wirklich benutzt wurde. Damit kann die spezifische Instanz des Abgusses mit dem gesamten Typus des unter dem Namen "Gussform" bekannten Herstellungsgeräts in Beziehung gesetzt werden. Darüber hinaus würden Objekte des Typs "Gussform" über P2 hat den Typus (ist Typus von) auf diesen Begriff bezogen werden. Diese indirekte Beziehung sollte für das mögliche Aufspüren des unbekannten Objektes in einer integrierten Umgebung tatsächlich hilfreich sein. Andererseits mag auch irgendein Abguss sich über die Eigenschaft P16 benutzte das bestimmte Objekt (wurde benutzt für) direkt auf bekannte Gussformen beziehen. Damit ließe sich eine statistische Abfrage über "Wieviele Objekte einer Sammlung sind gegossen worden?" eindeutig beantworten, indem beiden oben genannten Pfaden gefolgt wird (durch P16 benutzte das bestimmte Objekt (wurde benutzt für) P2 hat den Typus (ist Typus von) sowie P125 benutzte Objekt des Typus (Objekt des Typus ... wurde benutzt in)). Dieser konsistente Umgang des CRM mit kategorischem Wissen verbessert die Eignung zur Integration von kulturellem Wissen.

Zusätzlich zu seiner Schnittstelle zu externen Thesauren und Klassifikationssystemen ist E55 Typus eine gewöhnliche Klasse im CRM und eine Unterklasse von E28 Begrifflicher Gegenstand. Die Klasse E55 Typus und ihre Unterklassen erben alle Eigenschaften ihrer Überklasse E28 Begrifflicher Gegenstand. Deshalb kann zusammen mit der CRM Klasse E83 Typuserfindung die strenge geisteswissenschaftliche oder naturwissenschaftliche Vorgehensweise, die einen Typus absichert, ausführlich beschreibt und angemessen benennt innerhalb des CRM modelliert werden. In einigen Fällen, insbesondere in der Archäologie und den Lebenswissenschaften benötigt eine E83 Typuserfindung die Angabe eines namensgebenden Belegexemplars sowie die Publikation der Typusdefinition in einer der jeweiligen wissenschaftlichen Disziplin angemessenen Form. Dies ist ein zentraler Punkt in den Lebenswissenschaften, in denen ein Typus als "Taxon" bezeichnet wird und die publizierte Erstbeschreibung der Typusdefinition als „Protolog“ und die namensgebenden Belegexemplare als "Originale Elemente" oder "Holotypus" bezeichnet werden.

Schlussendlich werden Typen, d.h. Instanzen der Klasse E55 Typus und ihrer Unterklassen, benutzt, um Instanzen einer CRM Klasse zu charakterisieren und damit den Bedeutungsgehalt der Klasse zu verfeinern. Ein Typus "Künstler" kann verwendet werden, um Personen vermittels der Eigenschaft P2 hat den Typus (ist Typus von) zu charakterisieren. Andererseits kann es in einer kunstgeschichtlichen Anwendung des CRM’s angemessen sein, die CRM Klasse E21 Person um eine Unterklasse E21.xx Künstler zu erweitern. Was ist der Unterschied zwischen dem Typus "Künstler" und der Klasse Künstler? Konzeptionell gibt es auf den ersten Blick keinen Unterschied. Beide benennen das Konzept "Künstler" und identifizieren die gleiche Gruppe von Personen damit. Deshalb kann in dieser Zusammenstellung ein Typus als Klasse und die Klasse von Typen als Metaklasse gesehen werden. Da heutige Systeme keine adäquate Kontrolle für vom Anwender definierte Metaklassen bereitstellen, bevorzugt das CRM die Modellierung von Instanzen der Klasse E55 Typus als wären sie konkrete Objekte mit den Beziehungen wie oben beschriebenen.

Es liegt in der Entscheidung des Anwenders, ob ein Konzept in Form einer Unterklasse das CRM Klassensystem erweitert oder als Instanz von E55 Typus implementiert wird. Eine neue Unterklasse sollte nur in dem Fall geschaffen werden, wenn sie ausreichend stabil und mit zusätzlichen, für sie spezifischen, explizit modellierten Eigenschaften assoziiert ist. Ansonsten stellt eine Instanz der Klasse E55 Typus dem Anwender mehr Flexibilität zu Verfügung. Anwender, die einen Diskurs beschreiben wollen, der nicht nur eine Erweiterung des CRM‘s um ein Konzept sondern auch die Geschichte des Konzeptes selbst beinhaltet, können dasselbe Konzept sowohl als Unterklasse als auch als Instanz der Klasse E55 Typus mit demselben Namen modellieren. Ähnlich sollte es als gute Praxis angesehen werden, in jeder Begriffshierarchie, die eine bestimmte CRM Klasse spezialisiert, einen Ausdruck vorzusehen, der dem Namen dieser CRM Klasse als übergeordneter Begriff äquivalent ist. Z.B. sollte eine Begriffshierarchie für Instanzen der Klasse E21 Person mit "Person" beginnen.

Erweiterungen

Obwohl der beabsichtigte Anwendungsbereich des CRM eine Teilmenge der "Realen" Welt und diese potentiell unendlich ist, wurde das Modell so entworfen, dass es durch die Einbindung von Verknüpfungen zu kompatiblen, externen Typenhierarchien erweiterbar ist.

Kompatibilität von Erweiterungen mit dem CRM bedeutet, dass Daten, die gemäß einer Erweiterung strukturiert wurden, als CRM Instanz gültig bleiben müssen. Das impliziert im praktischen Umgang die "Abfrageenthaltung", d.h., dass jede auf CRM Konzepten basierende Anfrage eine Ergebnissatz erzeugt, der im Sinne der CRM Semantik richtig ist, unabhängig davon, ob die Quelle der Information gemäß der CRM Semantik oder auch vermittels von kompatiblen Erweiterungen strukturiert wurde. Zum Beispiel sollte eine Anfrage, "Liste alle Ereignisse auf" 100 Prozent der Instanzen aufrufen, die als CRM Ereignisse aufgefasst werden können, unabhängig davon wie sie innerhalb der Erweiterung klassifiziert wurden.

Eine ausreichende Bedingung für die Kompatibilität einer Erweiterung mit dem CRM ist, dass CRM Klassen alle Klassen ihrer Erweiterung zusammenfassen und alle Eigenschaften ihrer Erweiterung entweder durch CRM Eigenschaften zusammengefasst werden, oder Teile eines Pfades sind, für die eine CRM Eigenschaft als Abkürzung dient. Eine solche Bedingung kann offensichtlich nur intellektuell getestet werden.

Abdeckung des Anwendungsbereich

Notwendigerweise sind einige der durch das CRM abgedeckten Konzepte weniger umfangreich ausgearbeitet worden als andere: z.B. E39 Akteur und E30 Recht. Dies ist eine natürliche Konsequenz, die sich aus der Beschränkung auf einen klar artikulierten praktischen Anwendungsbereich des CRM innerhalb einer von Natur aus nicht beschränkten Betrachtungswelt ergibt. Diese "weniger ausgeprägten" Konzepte können als Aufhänger für kompatible Erweiterungen betrachtet werden.

Das CRM sieht eine Anzahl von Mechanismen vor, um sicher zu stellen, daß die Abdeckung des beabsichtigten Anwendungsbereichs vollständig ist:

  1. In der Hierarchie hoch stehende CRM Klassen können entweder strukturell als Unterklassen oder dynamisch durch Gebrauch einer Typenhierarchie erweitert werden.
  2. In der Hierarchie hochstehende CRM Eigenschaften können entweder strukturell als Untereigenschaften oder in einigen Fällen dynamisch durch den Gebrauch von Eigenschaften von Eigenschaften erweitert werden, die eine Verfeinerung erlauben.
  3. Zusätzliche Informationen außerhalb der formal durch das CRM definierten Semantik können als unstrukturierte Daten unter Verwendung der Klasse E1 CRM Entität.P3 hat Anmerkung: E62 Zeichenkette aufgezeichnet werden.

Bei den Mechanismen 1 und 2 fassen die CRM Konzepte die Erweiterungen zusammen und decken sie dadurch ab.

In Mechanismus 3 ist die Information über einen definierten Zugangspunkt in den jeweiligen Wissensbasen zugänglich. Dieser Ansatz ist dann vorzuziehen, wenn detailierte, gezielte Abfragen nicht erwartet werden; generell müssen nur die für eine formale Abfrage notwendigen Konzepte explizit modelliert werden.

Persönliche Werkzeuge