Angewandte Form

Aus CIDOC-CRM

Wechseln zu: Navigation, Suche

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


Das CRM ist eine Ontologie im Sinne der Informatik. Es wurde als ein objektorientiertes, semantisches Modell ausgedrückt, in der Hoffnung, dass diese Formulierung sowohl für Dokumentationsexperten wie auch für Informatiker gleichermaßen verständlich sein wird, während es gleichzeitig problemlos in maschinenlesbare Formate umgewandelt werden kann, wie RDF-Schema, KIF, DAML+OIL, OWL, STEP, etc. Es kann in jedem relationalen oder objektorientierten Schema implementiert werden. CRM Instanzen können auch in RDF, XML, DAML+OIL, OWL und anderen kodiert werden.

Obwohl die hier angebotene Version des CRM vollständig ist, ist es eine bewusst kompakte und knappe Darstellung der 86 Klassen und 137 eindeutigen Eigenschaften des CRM. Die Definition versucht nicht die Vererbung von Eigenschaften (Properties) durch Unterklassen über die gesamte CRM Klassenhierarchie auszuformulieren (dies würde die Auflistung von mehreren Tausend Eigenschaften erfordern, im Gegensatz zu den 137 eindeutigen). Dennoch enthält diese Definition die notwendige Information, um auf Eigenschaften zu schließen und automatisch eine vollständige Benennung aller Eigenschaften, einschließlich der vererbten, generieren zu können.

Terminologie

Die folgenden Definitionen der in diesem Dokument benutzten Schlüsselbegriffe sind zum einen als Hilfe für solche Leser gedacht, die noch nicht mit der Terminologie des objektorientierten Modellierens vertraut sind, und zum anderen, um den präzisen Gebrauch von Begriffen, die auch unter Experten des objektorientierten Modellierens nicht immer eindeutig verwendet werden, für dieses Dokument klar zu stellen. Wenn immer möglich, haben die Herausgeber versucht, Terminologie zu verwenden, die konsistent mit der des Ressource Description Formates (RDF<ref>Informationen über das Resource Description Framework (RDF) können unter http://www.w3.org/RDF/ gefunden werden </ref>) ist, einer Empfehlung des World Wide Web Konsortiums. Die Herausausgeber haben versucht eine Sprache zu finden, die einerseits für den Nicht-Computerexperten verständlich und andererseits für den Informatiker präzise genug ist, so dass beide die Bedeutung der Begriffe verstehen.

<references />


Begriff Definition
Klasse <class> Eine Klasse ist eine Kategorie von Dingen, die ein oder mehrere gemeinsame Merkmale aufweisen, die als Kriterien dienen, um die zu der Klasse gehörenden Dinge zu identifizieren. Diese Eigenschaften brauchen nicht notwendiger Weise in logischen Begriffen formuliert werden, sondern können in einem Text (hier eine Beschreibung des Anwendungsbereichs genannt) beschrieben werden, der den Bezug zu einem unter Fachleuten des betreffenden Fachbereichs gängigen Konzepts herstellt. Die Summe dieser Merkmale wird Intension <intension> dieser Klasse genannt. Eine Klasse kann die Ausgangsklasse oder Zielklasse von keiner, einer oder mehreren formal in einem Modell definierten Eigenschaften sein. Die formal definierten Eigenschaften müssen nicht notwendigerweise Teil der Intension <intension> ihrer Ausgangsklasse oder Zielklasse sein: solche Eigenschaften sind optional. Ein Gegenstand, der zu einer Klasse gehört, wird eine Instanz dieser Klasse genannt. Eine Klasse ist eine von der Zahl her offenen Menge von Instanzen zugeordnet, die im wirklichen Leben existieren, bekannt als Extension der Klasse. Hier wird "offen" in dem Sinne benutzt, dass es im Allgemeinen jenseits unserer Möglichkeiten liegt, alle Instanzen einer Klasse in der Welt zu kennen und dass in der Zukunft zu jeder Zeit neue Instanzen auftreten könnten (Offene Welt). Deswegen kann eine Klasse nicht durch die Aufzählung ihrer Instanzen definiert werden. Eine Klasse spielt eine Rolle analog der eines grammatischen Substantivs. Sie kann völlig ohne Hinweis auf ein anderes Konstrukt definiert werden (im Gegensatz zu Eigenschaften, die eine eindeutig definierte Ausgangsklasse und Zielklasse haben müssen). In einigen fachlichen Zusammenhängen werden die Begriffe individuelle Klasse, Entität oder Knoten synonym zu Klasse benutzt.

Zum Beispiel >>Person<< ist eine Klasse: Eine Person zu sein, mag tatsächlich mittels DNS-Merkmalen eindeutig bestimmt werden, aber wir alle wissen auch so, was eine Person ist. Eine Person mag die Eigenschaft haben, ein Mitglied einer Gruppe zu sein, aber im Umkehrschluss ist es nicht notwendig, Mitglied einer Gruppe zu sein, um eine Person zu sein. Wir werden niemals alle Personen der Vergangenheit kennen. Es wird zukünftig noch mehr Personen geben.

Unterklasse <subclass> Eine Unterklasse ist eine Klasse, die eine Spezialisierung einer anderen Klasse ist (ihrer Überklasse). Spezialisierung oder die IsA-Beziehung (IsA = „is a“)bedeutet:
1. Alle Instanzen der Unterklasse sind auch Instanzen ihrer Überklasse,
2. die Intension der Unterklasse erweitert die Intension ihrer Überklasse, d.h. ihre Eigenschaften sind einschränkender als die ihrer Überklasse und
3. die Unterklasse erbt ausnahmslos die Definition aller genannten Eigenschaften ihrer Überklasse (strikte Vererbung), und kann zusätzlich keine, eine oder mehrere Eigenschaften ihrer eigenen Klasse hinzufügen.

Eine Unterklasse kann mehr als eine unmittelbare Überklasse haben und erbt folglich die Eigenschaften aller seiner Überklassen (mehrfache Vererbung). Die IsA-Beziehung oder Spezialisierung zwischen zwei oder mehreren Klassen lässt eine als Klassenhierarchie bekannte Struktur entstehen. Die IsA-Beziehung ist transitiv und darf nicht zyklisch sein. In einigen fachlichen Zusammenhängen (z.B. der Programmiersprache C++) wird der Begriff „abgeleitete Klasse“ synonym zum Begriff der Unterklasse benutzt.

Zum Beispiel: Jede (Instanz der Klasse) Person ist ein(IsA= is a) Biologisches-Objekt, bzw. die Klasse Person ist eine Unterklasse der Klasse Biologisches Objekt. Desweiteren ist jede Person ebenfalls (IsA) ein Akteur. Eine Person kann sterben. Jedoch sterben andere Arten von Akteuren, wie z.B. Gesellschaften, nicht (c.f. 2). Jedes Biologische Objekt ist ein(IsA) Ding. Ein Ding kann bewegt werden. Daher kann eine Person bewegt werden (c.f. 3).


Überklasse <superclass> Eine Überklasse ist eine Klasse, die eine Generalisierung einer oder mehrer anderer Klassen (ihrer Unterklassen) darstellt, das heißt, dass sie alle Instanzen ihrer Unterklassen mit umfasst (subsumiert), und auch zusätzliche Instanzen haben kann, die zu keiner ihrer Unterklassen gehören. Die Intension der Überklasse ist weniger einschränkend als die ihrer Unterklassen. Diese Subsummierungs-Beziehung oder Generalisierung ist die Umkehrung der IsA-Beziehung oder Spezialisierung.

In einigen fachlichen Zusammenhängen (z.B. der Programmiersprache C++) wird der Begriff Elternklasse synonym zum Begriff Überklasse benutzt.

Zum Beispiel: "die Klasse Biological-Objekt mitumfasst die Klasse Person" ist synonym zu "die Klasse Biological-Objekt ist eine Überklasse der Klasse Person". Es werden weniger Merkmale benötigt einen bestimmten Gegenstand als Biologisches Objekt zu identifizieren als diesen Gegenstand als eine Person zu identifizieren.

Intension <intension> Die Intension einer Klasse oder Eigenschaft ist ihre beabsichtigte Bedeutung. Sie besteht aus einem oder mehreren gemeinsamen Merkmalen, die von allen Instanzen der Klasse oder Eigenschaft geteilt werden. Diese Eigenschaften brauchen nicht notwendigerweise in ausdrücklichen logischen Begriffen formuliert zu werden, sondern können einfach in einem Text (hier eine Anmerkung zum Anwendungsbereich genannt) beschrieben werden, der den Bezug zu einem unter Fachleuten des betreffenden Fachbereichs gängigen Konzept herstellt. Im Besonderen können die so genannten primitiven Konzepte, die den größten Teil des CRM bilden, nicht weiter auf andere Konzepte durch logische Begriffe zurückgeführt werden.
Extension <extension> Die Extension einer Klasse ist die Menge der Instanzen dieser Klasse, das heißt aller real vorkommenden Instanzen, die die Kriterien der Intension dieser Klasse erfüllen. Diese Menge ist "offen" in dem Sinne, dass es im Allgemeinen jenseits unserer Möglichkeiten liegt, alle Instanzen einer Klasse in der Welt zu kennen und dass in der Zukunft in der Tat zu jeder Zeit neue Instanzen auftreten können (Offene Welt). Ein Informationssystem mag sich zu jedem Zeitpunkt auf einige Instanzen einer Klasse beziehen, die eine Untermenge ihrer Extension bilden.
Anwendungsbereich <scope note> Eine Scope Note (Anmerkung zum Anwendungsbereich) ist eine Beschreibung der Intension einer Klasse oder Eigenschaft in Worten.

Scope Notes sind keine formalen Modellierungskonstrukte, sondern werden eingesetzt, um die beabsichtigte Bedeutung und Anwendung der Klassen und Eigenschaften des CRM erklären zu helfen. Sie beziehen sich im Wesentlichen auf ein unter Fachleuten des betreffenden Fachbereichs gängiges Konzept und treffen Unterscheidungen zwischen möglichen Interpretationen. Beispiele der Instanzen von Klassen und Eigenschaften werden auch regelmäßig im Anwendungsbereich zur Erläuterung aufgeführt.

Instanz <instance> Eine Instanz einer Klasse ist ein real vorkommender Gegenstand, der alle Merkmale aufweist, die die Kriterien der Intension der Klasse erfüllen.

Zum Beispiel: Das als "Mona Lisa" bekannte Gemälde ist eine Instanz der Klasse E22 Künstlicher Gegenstand.

Eine Instanz einer Eigenschaft ist eine faktische Beziehung zwischen einer Instanz der Ausgangsklasse und einer Instanz der Zielklasse (Range) der Eigenschaft, die mit Kriterien der Intension der Eigenschaft übereinstimmt.

Zum Beispiel: Der "Louvre ist gegenwärtiger Besitzer von Mona Lisa" ist eine Instanz der Eigenschaft "ist gegenwärtiger Besitzer von".

Eigenschaft <property> Eine Eigenschaft dient der Definition einer spezifischen Art von Beziehung zwischen zwei Klassen. Die Eigenschaft wird durch eine Intension charakterisiert, die in einer Anmerkung zum Anwendungsbereich erläutert wird. Eine Eigenschaft spielt eine Rolle analog dem eines grammatikalischen Verbs, in dem Sinne, dass es unter Bezug sowohl auf seine Ausgangsklasse als auch auf seine Zielklasse definiert werden muss, die dem zugehörigen grammatikalischen Subjekt und Objekt entsprechen (im Gegensatz zu den Klassen, die unabhängig definiert werden können). Es unterliegt der Willkür, welche Klasse als die Ausgangsklasse ausgewählt wird, ebenso wie die grammatikalische Wahl zwischen Aktiv und Passiv willkürlich ist. Mit anderen Worten, eine Eigenschaft kann in beiden Richtungen interpretiert werden, mit zwei getrennten, aber zueinander in Beziehung stehenden Interpretationen. Eigenschaften können selbst Eigenschaften besitzen, die sich auf andere Klassen beziehen (Diese Möglichkeit wird in diesem Modell nur dazu benutzt, um eine dynamische Typverfeinerung von Eigenschaften zu beschreiben). Eigenschaften können in der gleichen Weise wie Klassen, mittels IsA- Beziehungen zwischen Untereigenschaften und ihren Übereigenschaften, spezialisiert werden.

In der vorwiegend englischsprachigen Fachliteratur werden auch folgende Begriffe synonym zum Begriff der Eigenschaft (Property) benutzt: Attribute, reference, link, role oder slot.

Zum Beispiel: "Hergestelltes stellt dar CRM Entität" ist gleichwertig zu "CRM Entität wird dargestellt von Hergestelltes"

Untereigenschaft <subproperty> Eine Untereigenschaft ist eine Eigenschaft, die eine Spezialisierung einer anderen Eigenschaft (d.h., ihrer Übereigenschaft) ist. Spezialisierung oder IsA-Beziehung bedeutet, dass:
  1. alle Instanzen der Untereigenschaft auch Instanzen ihrer Übereigenschaft sind.
  2. die Intension der Untereigenschaft erweitert die Intension ihrer Übereigenschaft, d.h. ihre Merkmale sind einschränkender als die ihrer Supereigenschaft.
  3. die Ausgangsklasse der Untereigenschaft ist die gleiche wie die Ausgangsklasse ihrer Übereigenschaft oder eine Unterklasse jener Ausgangsklasse.
  4. der Zielklasse (Range) einer Untereigenschaft ist der gleiche wie der Zielklasse (Range) ihrer Übereigenschaft oder eine Unterklasse jener Zielklasse (Range).
  5. die Untereigenschaft erbt ausnahmslos die Definition aller Eigenschaften, die für der Übereigenschaft definiert sind (Strikte Vererbung), und kann zusätzlich selbst keine, eine oder mehrere Eigenschaften hinzufügen.

Eine Untereigenschaft kann mehr als eine unmittelbare Übereigenschaft haben und vererbt folglich die Eigenschaften aller ihrer Übereigenschaften (mehrfache Vererbung). Die IsA-Beziehung oder Spezialisierung zwischen zwei oder mehr Eigenschaften lässt eine Struktur entstehen, die wir eine Eigenschaftshierarchie nennen. Die IsA-Beziehung ist transitiv und darf nicht zyklisch sein. Einige objekt-orientierte Sprachen, wie C++, haben keine Entsprechung zur Spezialisierung von Eigenschaften.

Übereigenschaft <superproperty> Eine Übereigenschaft ist eine Eigenschaft, die eine Generalisierung von einer oder mehreren anderen Eigenschaften ist (seine Untereigenschaft), das heißt, dass sie alle Instanzen ihrer Untereigenschaften mit einschließt, und dass sie auch zusätzliche Instanzen haben kann, die zu keiner ihrer Untereigenschaften gehören. Die Intension der Übereigenschaft ist weniger einschränkend als die ihrer Untereigenschaften. Die Einschlussbeziehung oder Generalisierung verhält sich umgekehrt zur IsA-Beziehung oder Spezialisierung.
Domäne <domain> Die Ausgangsklasse ist die Klasse, für die eine Eigenschaft formell definiert wird. Dies heißt, dass Instanzen der Eigenschaft auf Instanzen ihrer Ausgangsklasse anwendbar sind. Eine Eigenschaft muss genau eine Ausgangsklasse haben, obwohl die Ausgangsklasse immer auch Instanzen enthalten kann, für die die Eigenschaft nicht instanziiert wird. Die Ausgangsklassenklasse steht grammatikalisch analog zum Subjekt eines Satzes, in dem die Eigenschaft analog zum Verb ist. Es ist willkürlich, welche Klasse als Ausgangsklasse ausgewählt wird und welche als Zielklasse (Range), geradeso wie die grammatikalische Wahl zwischen Aktiv und Passiv willkürlich ist. Die Namen der Eigenschaften im CRM werden entworfen, um semantisch bedeutungsvoll und grammatikalisch richtig zu sein, wenn man sie von der Ausgangsklasse zur Zielklasse (Range) liest. Außerdem wurde der umgekehrte Eigenschaftsname, normalerweise in Klammern angegeben, so entworfen, dass er semantisch bedeutungsvoll und grammatikalisch richtig ist, wenn er von der Zielklasse (Range) zur Ausgangsklasse gelesen wird.
Bereich <range> Die Zielklasse (Range) ist die Klasse, die alle potenziellen Werte einer Eigenschaft umfasst. Das heißt, dass sich Instanzen der Eigenschaft nur mit Instanzen ihrer Zielklasse (Range Class) verbinden können. Eine Eigenschaft kann nur genau eine Zielklasse (Range) haben, obwohl die Zielklasse (Range) immer Instanzen enthalten kann, die nicht ein Wert der Eigenschaft sind. Die Zielklasse steht grammatikalisch analog zum Objekt eines Satzes während die Eigenschaft analog zum Verb steht. Es ist willkürlich, welche Klasse als Ausgangsklasse ausgewählt wird und welche als Zielklasse (Range), geradeso wie die grammatikalische Wahl zwischen Aktiv und Passiv willkürlich ist. Die Namen der Eigenschaften im CRM werden entworfen, um semantisch bedeutungsvoll und grammatikalisch richtig zu sein, wenn man sie von der Ausgangsklasse zur Zielklasse (Range) liest. Außerdem wurde der umgekehrte Eigenschaftsname, normalerweise in Klammern angegeben, ebenso entworfen, um semantisch bedeutungsvoll und grammatikalisch richtig zu sein, wenn er von der Zielklasse (Range) zur Ausgangsklasse gelesen wird.
Vererbung <inheritance> Vererbung der Eigenschaften von Überklassen zu Unterklassen bedeutet, dass wenn ein Gegenstand x eine Instanz der Klasse A ist, dann
  1. müssen alle Eigenschaften, die für die Instanzen der Super-Klassen von A gelten müssen, auch für den Gegenstand x gelten, und
  2. alle optionalen Eigenschaften, die für die Instanzen einer der Superklassen von A gelten können, können auch für den Gegenstand x gelten.
Strikte Vererbung <strict inheritance> Strikte Vererbung bedeutet, dass es keine Ausnahme zur Vererbung von Eigenschaften von Über- auf Unterklassen gibt. Beispielsweise mögen einige Systeme erklären, dass Elefanten grau sind und einen weißen Elefanten als Ausnahme betrachten. Unter Strikter Vererbung würde jedoch gelten dass:

Wenn alle Elefanten grau wären, dann könnte ein weißer Elefant kein Elefant sein. Offensichtlich sind nicht alle Elefanten grau. Grau zu sein ist nicht Teil der Intension des Konzepts Elefant, sondern nur eine optionale Eigenschaft. Das CRM wendet Strikte Vererbung als Normalisierungsprinzip an.

Mehrfache Vererbung <multiple inheritance> Mehrfache Vererbung bedeutet, dass eine Klasse A mehr als nur eine unmittelbare Überklasse besitzt. Die Extension einer Klasse mit mehreren unmittelbaren Überklassen ist eine Untermenge der Schnittmenge aller Extensionen ihrer Überklassen. Die Intension einer Klasse mit mehreren unmittelbaren Überklassen erweitert die Intension aller ihrer Überklassen, z.B. ihre Merkmale sind restriktiver als die jeder ihrer Überklassen. Wenn mehrfache Vererbung benutzt wird, entsteht eine resultierende "Klassenhierarchie" in Form eines gerichteten Graphen, und nicht einer Baumstruktur. Wenn diese als eingerückte Liste dargestellt wird, gibt es zwangsläufig Wiederholungen derselben Klasse an verschiedenen Stellen der Liste. Zum Beispiel, ‘Person’ ist beides, ein Akteur und Biologischer Gegenstand.
Endurant / Perdurant Der Unterschied zwischen enduranten und perduranten Entitäten (welche auch Endurante und Perdurante genannt werden können) leitet sich von ihrem Verhalten in der Zeit ab. Endurante sind zu jedem Zeitpunkt ganzheitlich gegenwärtig (d.h. all ihnen eigene Teile sind vorhanden). Perdurante hingegen, breiten sich in der Zeit aus, indem unterschiedliche zeitliche Teile akkumuliert werden, so dass sie zu jedem Zeitpunkt, zu dem sie vorhanden sind, nur in Teilen vorhanden sind, in dem Sinne dass manche der ihnen eigenen Teile (z.B. ihre vorherigen oder künftigen Phasen) nicht gegenwärtig sein mögen. Z.B. ist der Teil des Artikels, den Sie gerade lesen wird im Ganzen gegenwärtig, während einige zeitliche Teile Ihres Lesevorgangs nicht mehr gegenwärtig sind. Im philosophischen Sinn sind Endurante in der Zeit existierende Entitäten, die aber über keine zeitliche Teile verfügen (alle ihre Teile fließen so zu sagen mit ihnen durch die Zeit). Perdurante auf der anderen Seite sind sich in der Zeit ereignende Entitäten, die zeitliche Teile haben können (all ihre Teile sind über die Zeit fixiert)" (Gangemi et al. 2002, pp. 166-181).
Abkürzung <shortcut> Eine Abkürzung ist eine formal definierte einzelne Eigenschaft, die eine Ableitung oder eine Verbindung (join) eines 'Bedeutungspfades' im CRM darstellt. Die Anmerkungen zum Anwendungsbereich aller Eigenschaften, die als Abkürzung gekennzeichnet sind, beschreiben in Worten die äquivalente Ableitung (Deduktion). Abkürzungen wurden in den Fällen eingeführt, in denen die allgemein übliche Dokumentationspraxis sich eher auf die Deduktion bezieht als auf den vollständigen 'Bedeutungspfad'. Z.B. dokumentieren Museen oft nur die Dimension eines Objektes, ohne jedoch das Ereignis des Messens dabei mitzudokumentieren. Der CRM erlaubt Abkürzungen als Fälle weniger detaillierten Wissens, bewahrt dabei aber in seinem Schema die Beziehung zur entsprechenden vollständigeren Information.
Monotone Folgerung <monotonic reasoning> Der Begriff ‘monotone Folgerung’ stammt aus dem Bereich der Wissensdarstellung. Eine Folgerungsweise ist monoton, wenn eine Vermehrung der Menge der Aussagen, die eine Wissensbasis aufbauen, niemals zu einem Verlust von Aussagen aus der Menge der Schlussfolgerungen führt, welche aus der Wissensbasis über Schlussfolgerungsregeln abgeleitet werden können. Um es in Praxis näheren Begriffen auszudrücken: Geben Experten richtige Aussagen aufeinander folgend in ein Informationssystem ein, sollte das System nie irgendein Ergebnis aus diesen Aussagen als ungültig betrachten, auch wenn eine neue Aussage hinzukommt. Das CRM ist so ausgelegt, dass es monotone Folgerung erlaubt und dadurch konfliktfreies Verschmelzen von riesigen Wissensbeständen ermöglicht.
Disjunkt <disjoint> Klassen sind disjunkt, wenn die Schnittmenge ihrer Extensionen eine leere Menge darstellt. In anderen Worten: Sie haben in keiner ‘möglichen Welt’ (die den derzeitigen Gesetzmäßigkeiten gehorcht) gemeinsame Instanzen.
Primitive <primitive> Im Bereich der Wissensdarstellung beschreibt der Ausdruck 'Primitiv' ein erklärtes Konzept über dessen Bedeutung Einverständnis besteht, aber das nicht durch eine logische Ableitung (Deduktion) von anderen Konzepten definiert ist. Wenn zum Beispiel der Begriff Mutter als 'weiblicher Mensch mit Kind' beschrieben wird, steht hinter dem Begriff Mutter kein primitives Konzept. Demgegenüber ist ‘Ereignis’ ein primitives Konzept. Das CRM besteht im Wesentlichen aus primitiven Konzepten.
Offene Welt <Open World> Die 'Offene Welt Prämisse’ (Open World Assumption) ist ein Begriff aus dem Bereich der sog. Wissensbasierten Systeme. Diese Prämisse charakterisiert Wissensbasierte Systeme, von denen angenommen wird, dass die in ihnen gespeicherte Information im Verhältnis zum Diskursuniversum, das sie zu beschreiben beabsichtigen, unvollständig ist. Diese Unvollständigkeit kann zum einen auf den mangelnden Möglichkeiten des Betreibers beruhen, ausreichende Informationen bereit zu stellen oder auf fundamentaleren erkenntnistheoretischen Problemen des entsprechen Wissensbereiches beruhen. Diese Art von Problemen ist charakteristisch für den Bereich kultureller Informationssysteme. Unsere Aufzeichnungen über die Vergangenheit sind notwendigerweise unvollständig. Zusätzlich zu den genannten Schwierigkeiten lässt sich nicht jede Sache klar einer gegebenen Klasse zuweisen.

Insbesondere bedeutet das Fehlen einer gewissen Eigenschaft eines in einem System beschriebenen Etwas, nicht, dass dieses Etwas die fehlende Eigenschaft nicht besitzt. Wenn zum Beispiel etwas als Biologisches Objekt und etwas anderes als Materieller Gegenstand beschrieben ist, ist nicht ausgeschlossen das letzteres auch ein Biologisches Objekt sein mag. Deshalb können generell aus einem Informationssystem auf Basis der Offenen Welt Prämisse keine Schlussfolgerungen über das Komplement einer Klasse hinsichtlich ihrer Überklasse gezogen werden. In einem gegebenen System sind z.B. "alle dem System bekannten materiellen Gegenstände, die nicht biologische Gegenstände in der realen Welt sind", nicht abfragbar; demgegenüber sind natürlich "alle dem System bekannten materiellen Gegenstände, die ihm nicht als biologische Gegenstände bekannt sind" abfragbar.

Komplement <complement> Die Ergänzungsmenge einer Klasse A (Komplement) hinsichtlich einer ihrer Überklassen B ist die Menge aller Instanzen von B, die nicht Instanzen von A sind. Formal handelt es sich um die mengentheoretische Differenz, der Extension von B abzüglich der Extension von A. CRM kompatible Erweiterungen sollten auf die Deklarierung von Klassen verzichten, deren Intension eine Ergänzungsmenge zu einer oder mehreren anderen Klassen darstellt. Ein solches Vorgehen wird normalerweise dem Wunsch eine "Offene Welt" zu beschreiben zuwiderhandeln. Z.B. sollte das menschliche Geschlecht 'männlich' nicht als Ergänzungsmenge von 'weiblich' oder umgekehrt deklariert werden, denn wie sollten wir dann Fälle von Hermaphroditen oder möglichen anderen, neuen Formen behandeln?
"Query Containment" <query containment> "Query Containment" (Abfragebeinhaltung) ist ein Problem aus der Datenbanktheorie: Eine Abfrage X beinhaltet eine weitere Abfrage Y, wenn für jeden möglichen Datenbestand einer Datenbank die Menge der Antworten auf Frage X auch die Menge der Antworten auf Frage Y enthält. Wenn man die Abfragen X und Y als Klassen ansieht, dann wäre X die Überklasse von Y.
Interoperabilität <interoperability> Interoperabilität bezeichnet die Fähigkeit, Inhalte zwischen unterschiedlichen Informationssystemen zu kommunizieren. Im Einzelnen bedeutet das:
  1. zwei Systeme können Informationen austauschen, und/oder
  2. mehrere Systeme sind über eine einzige Methode zugänglich.

Generell wird syntaktische Interoperabilität von semantischer Interoperabilität unterschieden.

Syntaktische Interoperabilität bedeutet, dass die Informationskodierung der beteiligten Systeme und Zugriffsprotokolle kompatibel ist, so dass die Informationen, wie oben beschrieben, ohne Fehler verarbeitet werden können. Das bedeutet jedoch nicht, dass jedes System die Daten auch in einer Weise bearbeitet die konsistent mit ihrer beabsichtigten Bedeutung ist. Zum Beispiel mag in einem System eine Tabelle mit "Actor" bezeichnet werden, während ein anderes System die Bezeichnung "Agent" verwendet. Unter syntaktischer Interoperabilität würden die Daten aus beiden Tabellen, selbst wenn sie die exakt gleiche Bedeutung haben, immer nur als unterschliedlich aufgefasst. Um diesen Missstand zu beheben, muss zusätzlich semantische Interoperabilität gewährleistet werden. Das CRM geht von existierender syntaktischer Interoperabilität aus und befasst sich nur mit dem Hinzuzufügen semantischer Interoperabilität.

Semantische Interoperabilität <semantic interoperability>

Semantische Interoperabilität bezeichnet die Fähigkeit unterschiedlicher Informationssysteme zur Kommunikation von Information folgerichtig zu ihrer beabsichtigten Bedeutung. Im näheren betrifft die beabsichtigte Bedeutung folgendes:

  1. die Datenstruktur der involvierten Elemente
  2. die als Daten erscheinende Terminologie und
  3. die Kennzeichen, die zur Identifikation der eigentlichen Orte, Personen, Objekte usw. genutzt werden.

Offensichtlich muss im ersten Schritt die Kommunikation über die Datenstrukturen aufgelöst werden. Konsistente Kommunikation bedeutet in diesem Fall, dass Daten zwischen Datenstrukturelementen mit derselben beabsichtigten Bedeutung übertragen werden können oder dass Daten aus Elementen mit derselben beabsichtigten Bedeutung vereinigt werden können. In der Praxis ist dieses Ideal der semantischen Interoperabilität nicht zu erreichen, wenn in verschiedenen Systemen unterschiedliche Grade der Generalisierung vorliegen. Semantische Interoperabilität gilt daher schon als erreicht, wenn Elemente gefunden werden, die eine hinreichend nahe Generalisierung für die Übertragung oder Vereinigung erlauben. Dieses Problem wird theoretisch als das "Query Containment" Problem behandelt. Das CRM befasst sich ausschließlich mit Semantischer Interoperabilität auf der Ebene der Datenstrukturelemente.

Eigenschaftsquantor <property quantifiers>

Im CRM wird der Begriff "Eigenschaftsquantor" als Festlegung der zulässigen Anzahl von Instanzen einer gegebenen Eigenschaft verstanden, die eine Instanz ihrer Zielklasse oder ihrer Ausgangsklasse haben darf. Diese Festlegungen sind ontologisch, d.h. sie beziehen sich auf die Natur der beschriebenen, wirklichen Welt und nicht auf unser gegenwärtiges Wissen über sie. Z.B., hat jede Person genau einen Vater, aber angesammeltes Wissen kann auf keinen Vater, auf einen oder auf viele (in Frage kommende) Väter verweisen.

Allgemeingültiges <universal>

Die fundamentale ontologische Unterscheidung zwischen Allgemeingültigem und Speziellem kann durch Betrachtung ihrer Beziehung zur Instanziierung einfach verstanden werden: Spezielles sind Entitäten, die keine Instanzen in irgendeiner möglichen Welt besitzen; Allgemeingültiges sind Entitäten die Instanzen haben. Klassen und Eigenschaften (Entsprechungen der Prädikate in einer logischen Sprache) werden üblicherweise als Allgemeingültiges angesehen. (nach Gangemi et al. 2002, pp. 166-181).

Eigenschaftsquantoren

Eigenschaftsquantoren dienen allein dem Zweck der semantischen Klarstellung und dürfen nicht als Implementierungsempfehlung verstanden werden. Das CRM wurde gestaltet, um alternative Meinungen und unvollständige Information aufnehmen zu können. Alle Eigenschaften sollten daher für ihre Ausgangsklasse und Zielklasse optional und wiederholbar implementiert werden ("many to many (0,n:0,n)"). Aus diesem Grund wird der Begriff "Cardinality Constraints" vermieden, da er üblicher Weise auf Implementierungen angewendet wird.

Die nachfolgende Tabelle zeigt die möglichen Eigenschaftsquantoren, die in diesem Dokument vorkommen, in Form ihrer Notation, zusammen mit einer Erläuterung in einfachen Worten. Um die bestmögliche Klarheit zu erzielen, werden zwei weithin akzeptierte Notationen redundant in diesem Dokument angewandt, eine verbale und eine numerische. Die verbale Notation benutzt Ausdrücke wie "one to many" und die numerische solche wie "(0,1:0,n)". Während die Ausdrücke "one", "many" und "necessary" intuitiv fassbar sind, bezeichnet der Ausdruck "dependent" eine Bedingtheit, in der eine Instanz einer Zielgruppe nicht ohne Instanz der jeweiligen Eigenschaft existieren kann. In anderen Worten, die Eigenschaft ist "necessary" für ihre Zielklasse.


Ausdruck Erklärung
many to many (0,n:0,n)

Uneingeschränkt (unconstrained): Eine individuelle Ausgangsklasseninstanz und eine Zielklasseninstanz dieser Eigenschaft kann keine, eine oder mehrere Instanzen dieser Eigenschaft haben. D.h. diese Eigenschaft ist optional und wiederholbar für ihre Ausgangsklasse und Zielklasse.

one to many (0,n:0,1)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaft kann keine, eine oder mehrere Instanzen dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz kann nicht durch mehr als eine Instanz dieser Eigenschaft referenziert werden. D.h. diese Eigenschaft ist optional für ihre Ausgangsklasse und Zielklasse, aber nur innerhalb für die Ausgangsklasse wiederholbar. In einigen Zusammenhängen wird diese Situation "fan-out" genannt.

many to one (0,1:0,n)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaft kann keine, oder eine Instanz dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz kann durch keine, eine oder mehrere Instanzen dieser Eigenschaft referenziert werden. D.h. diese Eigenschaft ist optional für ihre Ausgangsklasse und ihre Zielklasse, aber nur für ihre Zielklasse wiederholbar. In einigen Zusammenhängen wird diese Situation "fan-in" genannt.

many to many, necessary (1,n:0,n)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaft kann eine oder mehrere Instanz dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz kann keine, einer oder mehrere Instanzen dieser Eigenschaft besitzen. D.h. diese Eigenschaft ist notwendig und wiederholbar für ihre Ausgangsklasse, und optional und wiederholbar für ihre Zielklasse.

one to many, necessary (1,n:0,1)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaft kann eine oder mehrere dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz kann nicht durch mehr als eine Instanz dieser Eigenschaft referenziert werden. D.h. diese Eigenschaft ist notwendig und wiederholbar für ihre Ausgangsklasse und optional aber nicht wiederholbar für ihre Zielklasse. In einigen Zusammenhängen wird diese Situation "fan-out" genannt.

many to one, necessary (1,1:0,n)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaften muss genau eine Instanz dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz kann durch keine, eine oder mehrere Instanzen dieser Eigenschaft referenziert werden. D.h. diese Eigenschaft ist notwendig und nicht wiederholbar für ihre Ausgangsklasse und optional und wiederholbar für ihre Zielklasse. In einigen Zusammenhängen wird diese Situation "fan-in" genannt.

one to many, dependent (0,n:1,1)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaft kann keine, eine oder mehrere Instanzen dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz muss durch genau eine Instanz dieser Eigenschaft referenziert werden. D.h. diese Eigenschaft ist optional und wiederholbar für ihre Ausgangsklasse aber notwendig und nicht wiederholbar für ihre Zielklasse. In einigen Zusammenhängen wird diese Situation ein "fan-out" genannt.

one to many, necessary, dependent (1,n:1,1)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaft kann eine oder mehrere Instanzen dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz muss durch genau eine Instanz dieser Eigenschaft referenziert werden. D.h. diese Eigenschaft ist notwendig und wiederholbar für ihre Ausgangsklasse und notwendig aber nicht wiederholbar für ihre Zielklasse. In einigen Zusammenhängen wird diese Situation ein "fan-out" genannt.

many to one, necessary, dependent (1,1:1,n)

Eine individuelle Ausgangsklasseninstanz dieser Eigenschaft muss genau eine Instanz dieser Eigenschaft haben, aber eine individuelle Zielklasseninstanz kann durch eine oder mehrere Instanzen dieser Eigenschaft referenziert werden. D.h. diese Eigenschaft ist notwendig und nicht wiederholbar für ihre Ausgangsklasse und notwendig und wiederholbar für ihre Zielklasse. In einigen Zusammenhängen wird diese Situation ein "fan-in" genannt.

one to one (1,1:1,1)

Eine individuelle Ausgangsklasseninstantz und Zielklasseninstanz dieser Eigenschaft muss genau eine Instanz dieser Eigenschaft haben. D.h. diese Eigenschaft ist notwendig und nicht wiederholbar für ihre Ausgangsklasse und für ihre Zielklasse.

Gemäß den Definitionen in oben stehender Tabelle definiert das CRM einige Eigenschaften als notwendig für ihre Ausgangsklasse oder als abhängig von ihrer Zielklasse. Beachten Sie, dass wenn eine solche Eigenschaft nicht für eine Instanz der entsprechenden Ausgangsklasse oder Zielklasse spezifiziert ist, dies bedeutet, dass die Eigenschaft zwar existiert, aber der Wert auf der einen Seite dieser Eigenschaft unbekannt ist. Im Falle optionaler Eigenschaften unterscheidet die durch das CRM vorgeschlagene Methodologie nicht zwischen einem unbekannten Wert oder einer überhaupt nicht zutreffenden Eigenschaft. Z.B. kann bekannt sein, dass ein Objekt einen Eigentümer hat, der selbst allerdings unbekannt ist. In einer CRM Instanz kann dieser Sachverhalt nicht unterschieden werden von der Tatsache, dass das Objekt überhaupt keinen Besitzer hat. Natürlich können derartige Details immer als Anmerkungstexte spezifiziert werden.

Konventionen zur Benennung

Im CRM werden folgende Konventionen zur Benennung angewandt:

  • Klassen werden durch den Buchstaben "E" mit nachgestellter Zahl identifiziert (anfangs wurden Klassen auch als "Entitäten" bezeichnet) und benannt durch substantivierte Ausdrücke (Nominalgruppen) in Groß/Kleinschreibung, z.B. E63 Daseinsbeginn.
  • Eigenschaften werden durch den Buchstaben "P" mit nachgestellter Zahl identifiziert und durch verbale Ausdrücke in Kleinschreibung in beiden Leserichtungen benannt. Einen Zustand beschreibende Eigenschaften werden im Präsens benannt, wie z.B. "P2 hat den Typus (ist Typus von)", während dem ereignisbezogene Eigenschaften in der Vergangenheitsform benannt werden, wie z.B. "P14 wurde ausgeführt von (führte aus)".
  • Eigenschaftsnamen sollten in ihrer ungeklammerten Form augehend von der Ausgangsklasse zur Zielklasse gelesen werden, während der Ausdruck in Klammern von der Zielklasse zur Ausgangsklasse zu lesen ist.
  • Eigenschaften mit einer Zielklasse, die eine Unterklasse von "E59 Primitiver Wert" ist (wie z.B. E1 CRM Entität.P3 hat Anmerkung:E62 Zeichenkette), haben keine in Klammer gesetzte Form, weil ein Lesen des Eigenschaftsnamens von der Zielklasse zur Ausgangsklasse als nicht sinnvoll angesehen wird.
  • Eigenschaften mit identischer Ausgangsklasse und Zielklasse sind entweder symmetrisch oder transitiv. Die Instanziierung einer symmetrischen Eigenschaft impliziert, dass dieselbe Beziehung von der Ausgangsklasse zur Zielklasse wie auch von der Zielklasse zur Ausgangsklasse gilt. Ein Beispiel ist die Beziehung zwischen "E53 Ort.P122 grenzt an:E53 Ort". Die Namen symmetrischer Eigenschaften haben keine Klammerform, weil die Leserichtung von der Zielklasse zur Ausgangsklasse dieselbe ist wie von der Ausgangsklasse zur Zielklasse. Transitive, asymmetrische Eigenschaften wie z.B. "E4 Phase.P9 setzt sich zusammen aus (bildet Teil von):E4 Phase" haben eine Klammerform, die sich auf die Bedeutung der umgekehrten Leserichtung bezieht.
  • die Wahl der Ausgangsklasse von Eigenschaften und dem zur Folge die Anordnung ihrer Namen werden in Übereinstimmung mit der nachfolgenden Prioritätsliste festgelegt:
Persönliche Werkzeuge