Re: ahoi

[Dennis Riedel]

Hallo Hannah, hallo Lukas. Frohe Ostern!

Hannah wrote:

wenn das dokument ein non-legally binding document ist, gibt es nur ein datum, nämlich das adoption_date. wenn das dokument ein legally binding document ist, gibt es zwei daten: adoption_date und "date of entry into force" (das ist zeitlich immer nach dem adoption_date)

Ich habe jetzt mal die alte Eigenschaft "publication_date" in "enforcement_date" umbenannt. Dort können wir für ein Dokument "entry into force" speichern

.

Wenn ich das also richtig verstehe, kann ein Land erst mal "reservations" haben, die wir dann im Backend als solche aufnehmen:

Land X - Dokument Y - "Wir halten das für keine gute Idee. Könnt Ihr nicht a und b zu c ändern?" Datum: 2010-10-09

Später gibt es dann ein "ratified":

Land X - Dokument Y - "ratified" Datum: 2010-10-27

Später dann "signed":

Land X - Document Y - "signed" Datum: 2010-11-23

Jetzt haben wir zur Zeit in der Datenbank das Land zusammen mit dem Dokument als Schlüsselpaar. Es darf dieses Paar nur einmal geben. Daher könnte man oben genannten Szenario nicht in der Tabelle "Votes" wiederfinden, sondern müsste immer den gleichen Entrag "aktualisieren". Also von "reservations" zu "ratified" zu "signed". Das bedeutet aber, mann kann "ratified and signed" nicht zusammen darstellen.

@Lukas: wolltest Du die Historie über die Versionable abrufen?

@Hannah: ist die Historie interessant oder kann man die Information einfach aktualisieren und vorheriges überschreiben?

@Hannah: kannst Du mir bitte diesen Absatz noch mal erläutern, bitte?

"Wir hatten mal, soweit ich mich erinnern kann, besprochen, dass als default für non-legally binding documents immer alle länder, die der entsprechenden organisation zugeordnet sind, wo man dann entsprechend modifizieren kann."

@Hannah: ist es ein Problem, wenn wir im Backend Interface für Votes alle Typen ("yes", "no", "signed", "not present", ...) in einem Feld auswählbar darstellen, ohne danach zu filtern, welchen Legal Value das Dokument hat (non-legally, legally binding)? Oder sollten wir darauf achten, welchen Legal Value das Dokument hat und dementsprechend die möglichen Vote Types darstellen?

Um eine Vote einzutragen, muss der Benutzer die Möglichkeit haben, sowohl für das Dokument, als auch seine einzelnen Klauseln einen Text zu "reservations" einzugeben, sofern er "reservations" als vote type ausgewählt hat. Korrekt?

Viele Grüsse

Dennis

2010/4/1 Hannah Birkenkötter <h.birke...@googlemail.com>

Am 31.03.2010 um 17:37 schrieb Lukas Kahwe Smith:

On 31.03.2010, at 23:20, Dennis Riedel wrote:

Könntest Du bitte die Begriffe im Voting noch näher ausführen. "Reservations" verstehe ich jetzt gerade gar nicht in dem Zusammenhang. Und vielleicht noch ein paar generelle Umschreibugen der Voting Sektion. Clause relations sind "relations" für ein Dokument, neben den schon zugehörigen Klauseln oder sind das related clauses zu den schon bestehenden Klauseln des Dokuments?

also voting laufen wie folgt ab:
laender sind ja organisationen zu geordnet (achtung, das kann auch nur fuer einen oder mehrere zeitintervalle gelten). ein dokument ist wiederum einer organisation zugeordnet, sowie einem adoption_date (@hannah: eventuell braucht es da noch ein anderes datum, aber wir koennen vorerst mal dies nehmen).

wenn das dokument ein non-legally binding document ist, gibt es nur ein datum, nämlich das adoption_date. wenn das dokument ein legally binding document ist, gibt es zwei daten: adoption_date und "date of entry into force" (das ist zeitlich immer nach dem adoption_date). Wir hatten mal, soweit ich mich erinnern kann, besprochen, dass als default für non-legally binding documents immer alle länder, die der entsprechenden organisation zugeordnet sind, wo man dann entsprechend modifizieren kann. hier braucht es: yes, no, abstention, not present als "voting options". Für legally bidning documents gibt es manchmal keine organisation (wenn das dokument nicht im rahmen der UN verhandelt wurde). ALLE länder können IMMER dem legally binding document "beitreten". hier hatten wir mal besprochen, dass der default kein land ausgewählt hat, und man dann die optionen "signed", "ratified" und "reservations" hat. "signed" und "ratified" bräuchten eine möglichkeit zur datumseingabe (da das datum der signature und der ratification nicht immer mit dem datum der adoption übereinstimmen). ein land kann ein legally binding document entweder signed oder ratified oder beides oder gar nichts haben. zu den reservations:

nun darf jedes land dabei entsprechende "reservationen" angeben. d.h. einschraenkungen etc. das ist glaube ein freitext feld. ich sehe im aktuellen schema ist dies nur fuer clauses vorgesehen .. ich weiss nicht ob es dies auch fuer documents als ganzes geben soll.

ja, es soll reservations für das document als ganzes und für die clauses geben, beide als freitextfelder.

USA:
vote: X
document reservation: bla
clause 1 reservation: ding
clause 5 reservation: dong
clause 12 reservation: halli

also ich stelle mir das etwa so vor:
document D: ist legally binding.
USA hat ratifiziert, aber nicht signed.

document reservation: bla
clause 1 reservation: ding
clause 5 reservation: dong

hierbei kann für jedes land keine oder mehrere document/clauses reservations angegeben werden.

relations:
ich glaube das ist alles im schema schon komplett erfasst. es gibt da einmal die relation "parent".

das ist die einzige relation,die wir im excel im main sheet schon angegeben haben.

es gibt aber auch "recalls" und "closely_related. documents koennen relationen zu anderen documents aber auch clauses haben. die clauses koennen aus beliebigen documents kommen (@hannah: clauses koennen nur aus related documents kommen?).

nein, die clauses können aus beliebigen dokumenten kommen. ein beispiel: wir haben dokumente x, y, z. dokument y hat clause a und b und dokument z hat clause c und d. dokument x und y sind "closely_related". dann kann es trotzdem folgende clause-document relations geben:
- dokument x und clause c sind related
- dokument x und clause a sind related

Ich hoffe, das hat alles Sinn gemacht - bei weiteren Fragen jederzeit gerne!

Beste Grüße,

Hannah

Gruss,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Hannah Birkenkötter]

Erstmal ebenfalls frohe Ostern!!

Wenn ich das also richtig verstehe, kann ein Land erst mal "reservations" haben, die wir dann im Backend als solche aufnehmen:

Land X - Dokument Y - "Wir halten das für keine gute Idee. Könnt Ihr nicht a und b zu c ändern?" Datum: 2010-10-09

Später gibt es dann ein "ratified":

Land X - Dokument Y - "ratified" Datum: 2010-10-27

Später dann "signed":

Land X - Document Y - "signed" Datum: 2010-11-23

Reservations gibt es ausschließlich bei legally binding documents. So sieht die absolut exakte Reihenfolge so aus: 

- Dokument Y wird beschlossen. 

- Land X signed das Dokument Y (signature kommt immer vor ratification), Datum 2010-10-27

- Land X ratified das Dokument Y, Datum 2010-11-23, und sagt entweder a) Ich ratifiziere das Dokument, aber a und b in Dokument Y werden wir nicht anwenden (--> das wäre eine clause-specific reservation) oder b) Ich ratifiziere das Dokument, aber es muss immer konform mit der Sharia ausgelegt werden (--> das wäre eine reservation affecting the entire document). Sprich: Reservations werden IMMER erst mit der ratification (also dem letzten Schritt) interessant. Sorry, da war ich wohl etwas unklar..

Jetzt haben wir zur Zeit in der Datenbank das Land zusammen mit dem Dokument als Schlüsselpaar. Es darf dieses Paar nur einmal geben. Daher könnte man oben genannten Szenario nicht in der Tabelle "Votes" wiederfinden, sondern müsste immer den gleichen Entrag "aktualisieren". Also von "reservations" zu "ratified" zu "signed". Das bedeutet aber, mann kann "ratified and signed" nicht zusammen darstellen.

Hm. Dadurch, dass ein Land ein Dokument ratifiziert, wird die Unterschrift nicht obsolet. Es ist gerade interessant zu sehen, wann ein Land welches Dokument mit einer signature und später dann mit einer ratification belegt hat. Verstehe ich das mit dem aktualisieren richtig, dass im Prinzip immer der entsprechende Eintrag "Dokument-Land" modifiziert werden müsste? 

@Hannah: ist die Historie interessant oder kann man die Information einfach aktualisieren und vorheriges überschreiben?

Wenn mit Historie obiges (also signature -> ratification) bedeutet, dann kann man sie leider nicht einfach überschreiben.

@Hannah: kannst Du mir bitte diesen Absatz noch mal erläutern, bitte?

"Wir hatten mal, soweit ich mich erinnern kann, besprochen, dass als default für non-legally binding documents immer alle länder, die der entsprechenden organisation zugeordnet sind, wo man dann entsprechend modifizieren kann."

Oha. Unvollständiger Satz. Also, im letzten Dezember schwebte uns etwa folgendes vor: 

- ich gebe ein non-legally binding document ein

- nachdem die infos (name, code, issuing organisation, legal value etc..) eingegeben wurden, ist der default automatisch auf "Adopted without a vote" gestellt. D.h. das Dokument wurde per Konsens beschlossen und es gab keine Abstimmung. 

- Manchmal gibt es aber Abstimmungen (adoption with a vote). Dann könnte man "adopted without a vote" de-clicken (oder so) und würde eine Liste mit allen Mitgliedsstaaten der issuing organisation X zum Zeitpunkt, zu dem das Dokument beschlossen wurde. Hier kann man eingeben "yes", "no", "not present", "abstention". 

@Hannah: ist es ein Problem, wenn wir im Backend Interface für Votes alle Typen ("yes", "no", "signed", "not present", ...) in einem Feld auswählbar darstellen, ohne danach zu filtern, welchen Legal Value das Dokument hat (non-legally, legally binding)? Oder sollten wir darauf achten, welchen Legal Value das Dokument hat und dementsprechend die möglichen Vote Types darstellen?

Also im Backend interface macht es nicht direkt was aus, ob man darauf achtet, welchen legal value Dokument X hat - aber es würde unsere Arbeit vermutlich extrem vereinfachern, wenn der legal value festgestellt und die vote types dementsprechend dargestellt würden. 

Um eine Vote einzutragen, muss der Benutzer die Möglichkeit haben, sowohl für das Dokument, als auch seine einzelnen Klauseln einen Text zu "reservations" einzugeben, sofern er "reservations" als vote type ausgewählt hat. Korrekt?

Ja. Aber nochmal: reservations werden zusammen mit der ratification abgegeben, sind also kein separater "voting type". 

Ich hoffe, die voting/ratification procedure ist ein bißchen klarer - lasst mich wissen, wenn ihr noch weitere Fragen habt!

Herzliche Grüße, 

Hannah

[Dennis Riedel]

Hallo Hannah

Ok, prima. Jetzt ist das alles schon etwas klarer. Ich habe heute zwei "frühe" Implementierungen für das Erzeugen von Document Reservations und Clause Reservations in das Projekt eingespielt. Das werde ich dann auch erst noch mal mit Lukas näher betrachten und dann mit den verschiedenen Regeln, die Du uns genannt hast, verbessern.

Vielleicht gibt es ja dann am nächsten Wochenende die Möglichkeit, dass an einem ersten Prototypen mit Dir zu testen.

Generell fände ich es gut, wenn wir jetzt im April und Anfang Mai sehr zeitnah einzelne Szenarien mit Hannah oder anderen Stakeholdern testen könnten, um schneller wichtige Änderungen und die Schlüsselfunktionalitäten wie gewünscht zu implementieren.

Bin nicht sicher, was dafür nötig ist, aber eine wöchentliche Aktualisierung der Version, auf die die MCM Gruppe Zugang hat, wäre angebracht.

Grüsse,

Dennis

2010/4/5 Hannah Birkenkötter <h.birke...@googlemail.com>

[Hannah Birkenkötter]

Hi Dennis, 

ja, testen ab dem nächsten Wochenende hört sich sehr gut an. Eine wöchentliche Aktualisierung halte ich für sehr gut, die nächsten Wochenenden habe ich auch einigermaßen Zeit, einzelne Prototypen zu testen. Ich werde auch mit einigen anderen Leuten besprechen, ob sie ebenfalls Zeit zum testen haben. 

Dazu habe ich noch eine Frage: Einige Informationen, insbesondere die länderspezifischen Sachen, sind ja in den Excels noch gar nicht enthalten und es dauert sicherlich ein wenig, bis wir diese Dinge vollständig ins backend eingefügt haben. Wann können wir in etwa damit beginnen? 

Beste Grüße, 

Hannah