OpenAtlas

On 11/06/2015 12:37 PM, Elbel, Petr wrote:

Sehr geehrte Kollegen,

ich knüpfe noch an die Frage von Přemysl, die ich eigentlich mitinitiiert habe.

1) Mit dem SOURCE ist es so:

Mich interessieren natürlich die EVENTS, aber gleichzeitig will ich aus der Datenbank auch eine differenzierte Übersicht über die Urkundenvergabe Kaiser Sigismunds für die Empfänger aus Böhmen gewinnen.

Ein EVENT ist bspw. die Verpfändung einer kgl. Burg in Böhmen an einen Parteigänger Sigismunds, ein SOURCE ist eine entsprechende Verpfändungsurkunde Sigismunds für denselben Parteigänger.

Am Ende will ich die Datenbank bspw. abfragen können:

- Ich brauche alle Empfänger der Urkunden Sigismunds (unabhängig vom Inhalt!!) aus der Personengruppe Pilsener Landfrieden (das geht jetzt evt. über das Feld SOURCE)

- Ich brauche alle Pfandinhaber, die ein Pfand von Sigismund bekommen haben, aus der Personengruppe Pilsener Landfrieden (das geht über das Feld EVENT)

Bei der jetzigen Struktur der Datenbank müsste ich jedes EVENT mit der Beteiligung Sigismunds gleichzeitig noch als ein SOURCE abspeichern - und das wäre irre.
Sonst kann ich eine Übersicht über alle Urkunden Sigismunds für bestimmte Person oder Personengruppe nicht abfragen.

M.E. ist die Relation SOURCE - EVENT ganz unentbehrlich, um die Datenbank im Brünner Projekt verwenden zu können.

Und bei der Kategorie SOURCE, Kategorie CHARTER, bräuchten wir mehrere Felder:
- Aussteller
- Empfänger
- Petent
- Relator
- Konzeptbeamte
- Zeuge
- Siegler

---

2) Ich habe aus Ihrer Antwort an Přemek nicht verstanden, ob eine Relation zwischen EVENT und ACTOR-ACTOR RELATION also schon jetzt definiert werden kann, oder ob Sie das erst programmieren müssen.
Das ist auch ganz unentbehrlich.
Ich kehre zum Fall Verpfändung zurück.
Wenn eine Person einer zweite Person eine Burg verpfändet, ist es ein EVENT. Aber gleichzeitig ist es ein wirtschafliches ACTOR-ACTOR RELATION.
Auch das muss man jetzt doppelt eingeben (und noch dazu SOURCE, also jeden Pfandbrief muss dreimal in die Datenbank eingegen werden).

Ich meine, aus jedem EVENT müsste sich automatisch eine ACTOR-ACTOR RELATION zwischen allen am EVENT beteiligten generieren.
Man würde nur entscheiden müssen, welche Qualität diese Relation hat.

---

3) Eine dritte Sache ist noch die Möglichkeit, mehrere Residenzen einer Person + deren Entwicklung während der Zeit eingeben zu können. Wie ich gesehen habe, geht es jetzt nicht.
Viele Personen saßen zuerst auf einer Burg, die wurde durch die Hussiten erobert, dann saßen sie auf anderer Burg usw. usf.

Nur so kann ich die Änderung der Sigismundpartei in Böhmen im Laufe der Zeit nachfolgen und entsprechenden Karten (etwa für jedes Jahr) zu zeichnen.

Neben residenzen bräuchten wir bei jeder Person noch weitere Besitzungen angeben zu können. Das können wir aber wohl selber ergänzen(?).

Wenn diese drei Sachen geändert werden können, kann die Datenbank in unserem Projekt wohl verwendet können. Sonst - fürchte ich - wäre die Eingabe mit unglaublich viel Arbeit verbunden und die Möglichkeit, aus der Datenbank verschidene Netze rekonstruieren zu können, eher bescheiden.

Mit freundlichen Grüßen,

Petr Elbel

Liebe Kollegen, lieber Petr Elbel

vielen Dank für den Input. Jetzt ist mir genauer klar, was gemeint war. Zu den Fragen:

1) Mit dem SOURCE ist es so:

Mich interessieren natürlich die EVENTS, aber gleichzeitig will ich aus der Datenbank auch eine differenzierte Übersicht über die Urkundenvergabe Kaiser Sigismunds für die Empfänger aus Böhmen gewinnen.

Ein EVENT ist bspw. die Verpfändung einer kgl. Burg in Böhmen an einen Parteigänger Sigismunds, ein SOURCE ist eine entsprechende Verpfändungsurkunde Sigismunds für denselben Parteigänger.

Das stimmt nicht so ganz. Ein Source ist der Inhalt. Die Urkunde ist der "Information Carrier" dazu. Die Funktionalität dafür kommt in einer der nächsten Versionen. Für Medcon gibt es erstmal nur eine Minimalvariante. Vgl.
http://redmine.craws.net/projects/uni/wiki/Graphical_User_Interface#Information-Carrier-as-physical-Objects
Falls für das Sigismund Projekt eine größere Funktionalität gebraucht wird, müsste man das theoretische Konzept noch einprogrammieren:
http://redmine.craws.net/projects/uni/wiki/CIDOC-Mappings#Written-Sources-History
Darin können dann Verhältnisse wie z.B. Der Aussteller der Urkunde bzw. der Empfänger und sonstige Relationen festgehalten werden

Am Ende will ich die Datenbank bspw. abfragen können:

- Ich brauche alle Empfänger der Urkunden Sigismunds (unabhängig vom Inhalt!!) aus der Personengruppe Pilsener Landfrieden (das geht jetzt evt. über das Feld SOURCE)

- Ich brauche alle Pfandinhaber, die ein Pfand von Sigismund bekommen haben, aus der Personengruppe Pilsener Landfrieden (das geht über das Feld EVENT)

Der Erste Punkt wäre über den Information Carrier abzufragen.
Was ist gemeint mit Pfand?

Bei der jetzigen Struktur der Datenbank müsste ich jedes EVENT mit der Beteiligung Sigismunds gleichzeitig noch als ein SOURCE abspeichern - und das wäre irre.
Sonst kann ich eine Übersicht über alle Urkunden Sigismunds für bestimmte Person oder Personengruppe nicht abfragen.

M.E. ist die Relation SOURCE - EVENT ganz unentbehrlich, um die Datenbank im Brünner Projekt verwenden zu können.

Das mag für das Sigismund Projekt zutreffen. Die generelle Struktur und Unterscheidung Event/Source/Information Carrier ist aber deshalb notwendig, weil es den Fall geben kann, dass eine Quelle (=Source) etwa von mehreren Events berichtet und dieser Inhalt (Source Content) beispielsweise auf mehreren physichen Trägern (z.b. Originalurkunde, Kopie, spätere Abschrift) vorhanden sein kann. Auch können unterschiedliche Sources vom selben Event berichten.
Als Workaround gegen das Duplizieren von Einträgen wo Source und Event gleich sind, könnte beispielsweise eine Automatisierung programmiert werden. Eine Fusion von Source und Event würde aber gegen das Datenmodell sein.

Und bei der Kategorie SOURCE, Kategorie CHARTER, bräuchten wir mehrere Felder:
- Aussteller
- Empfänger
- Petent
- Relator
- Konzeptbeamte
- Zeuge
- Siegler

Das würde dann wohl mit dem Informationsträger verknüpft sein.

2) Ich habe aus Ihrer Antwort an Přemek nicht verstanden, ob eine
Relation zwischen EVENT und ACTOR-ACTOR RELATION also schon jetzt
definiert werden kann, oder ob Sie das erst programmieren müssen.
Das ist auch ganz unentbehrlich.
Ich kehre zum Fall Verpfändung zurück.
Wenn eine Person einer zweite Person eine Burg verpfändet, ist es ein
EVENT. Aber gleichzeitig ist es ein wirtschafliches ACTOR-ACTOR RELATION.
Auch das muss man jetzt doppelt eingeben (und noch dazu SOURCE, also
jeden Pfandbrief muss dreimal in die Datenbank eingegen werden).

Ich meine, aus jedem EVENT müsste sich automatisch eine ACTOR-ACTOR
RELATION zwischen allen am EVENT beteiligten generieren.
Man würde nur entscheiden müssen, welche Qualität diese Relation hat.

Wie ein Event kategorisiert wird, hängt von den Personen ab, die Eingaben machen und die Kategorien können selber angelegt werden.
http://medcon.craws.net/admin/node -> Event

Die Software kann nicht automatisch sehen, wie unterschiedliche Ereignisse sich auf die direkten Beziehungen zwischen Personen auswirken. Das kann auch nicht so einfach programmiert werden sondern müsste von den inhaltlichen Spezialisten, die die Eingaben machen vorher definiert werden.
Im Prinzip ist es aber egal. Es kommt nicht auf die Eingabe an, sondern auf die Abfrage, um die Information zu bekommen wer wie miteinander in Verbindung steht.
Wenn man also die wie auch immer geartete Verbindung von Akteuren zu Akteuren abfragen möchte, muss man diese zunächst einmal formulieren. Z.B. "Alle Personen, die am selben Event mit dem Typus "Verpfändung" beteiligt sind. Oder auch mit genauerer Spezifikation anhand des "Involvements"
Jedes mal eine Actor-Actor Relation anzulegen ist gar nicht notwendig.

Die Actor-Actor relation bezieht sich auf direkte Verbindungen und ist ein Shortcut der Verbindung Actor-Event-Actor.
Diese Verbindungen/Relationen sind auch im WIKI erläutert.
http://redmine.craws.net/projects/uni/wiki/CIDOC-Mappings#Actors-and-Actors
http://redmine.craws.net/projects/uni/wiki/CIDOC-Mappings#OA7-has-relationship-to

3) Eine dritte Sache ist noch die Möglichkeit, mehrere Residenzen einer
Person + deren Entwicklung während der Zeit eingeben zu können. Wie ich
gesehen habe, geht es jetzt nicht.
Viele Personen saßen zuerst auf einer Burg, die wurde durch die Hussiten
erobert, dann saßen sie auf anderer Burg usw. usf.

Nur so kann ich die Änderung der Sigismundpartei in Böhmen im Laufe der
Zeit nachfolgen und entsprechenden Karten (etwa für jedes Jahr) zu zeichnen.

Neben residenzen bräuchten wir bei jeder Person noch weitere Besitzungen
angeben zu können. Das können wir aber wohl selber ergänzen(?).

Hier sind wir gerade am Überlegen, ob wir das so einbauen oder nicht. Für Medcon wird es wohl vorerst bei der Einzelresidenz bleiben. Prinzipiell sind aber mehrere Residenzen bzw. Besitzungen pro Akteur gestaffelt nach Zeit angedacht

Wenn diese drei Sachen geändert werden können, kann die Datenbank in
unserem Projekt wohl verwendet können. Sonst - fürchte ich - wäre die
Eingabe mit unglaublich viel Arbeit verbunden und die Möglichkeit, aus
der Datenbank verschidene Netze rekonstruieren zu können, eher bescheiden.

Zusammenfassung
Zum ersten Punkt: Was die konzeptionelle Arbeit angeht siehe WIKI. Ich denke man kann es über den Information Carrier lösen.
Zum zweiten Punkt: Es ist nicht notwendig Actor-Actor Relations einzufügen, weil diese ohnehin über Actor-Event-Actor gegeben sind und so abgefragt werden sollen.
Zum dritten Punkt: Soll eingearbeitet werden.
Allgemein: Für Medcon wurde bisher die Grundfunktionalität eingebaut und programmiert. Die gewünschten zusätzlichen Features sind weitgehend konzeptionell ausgearbeitet. Für die Einarbeitung in das Programm ist jedoch entsprechend Arbeit notwendig und der Entwickler/Programmierer müsste sich separat damit befassen, weil es in dieser Detailliertheit nicht in Medcon vorgesehen war. Hier stellt sich natürlich die Frage nach der Finanzierung und Machbarkeit.