search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

Eigenschaft "resolution" in Objekttyp AgendaItem ist nicht mit OWL kompatibel #212

Closed akuckartz closed 10 years ago

akuckartz commented 10 years ago

Eine Eigenschaft, deren Wertebereich sowohl Objekttypen als auch Datentypen beinhaltet ist mit wichtigen OWL Ausprägungen nicht kompatibel.

Siehe: http://www.w3.org/TR/2009/REC-owl2-direct-semantics-20091027/#Interpretations

Das ist ganz schlecht. Meine Idee für resolution also leider auch.

Ein ähnliches Problem gibt es aktuell in geojson-ld: https://github.com/geojson/geojson-ld/issues/23

sterni24 commented 10 years ago

Aus meiner Sicht müssen beide Eigenschaften 'resolutionText' und 'resolutionDocument' vorhanden sein. 'resolutionText' kann z. B. HTML beinhalten, während 'resolutionDocument' eine PDF-Datei ist.

akuckartz commented 10 years ago

Dann haben wir drei Eigenschaften die das Ergebnis ausdrücken: result, resolutionText und resolutionDocument. Das ist ein Indiz für ungeschickte Modellierung. Eventuell sollten die Ergebnisse in eine eigene Klasse verpackt werden? Dort können dann später eventuell auch Informationen zum Stimmverhalten einzelner Personen aufgenommen werden.

Welche Festlegungen wir zu dem "Text" treffen können. Ich bin für die Möglichkeit HTML verwenden zu können. Aber niemand sollte den Text erst untersuchen müssen, um herauszufinden ob er HTML oder etwas anderes enthält. Eine Möglichkeit wäre eine Erweiterung von oparl:Document auf "Dokumente" die nicht in Dateien enthalten sind sondern direkt als JSON-Zeichenketten.

sterni24 commented 10 years ago

Zur Verdeutlichung der Inhalte:

result beinhaltet das Abstimmungsergebnis, z. B. einstimmig / mehrheitlich dafür / 25 Ja-Stimmen, keine Nein-Stimmen, keine Enthaltung

resolutionText stellt den reinen Beschlusstext dar, z. B. "Der Rat beschließt die Veröffentlichung der persönlichen Daten aller Mandatsträger".

resolutionDocument ist ein komplettes Beschlussdokument zu einem Tagesordnungspunkt mit Gremium, Sitzungstermin, usw., z. B. http://wwwsvc1.stadt-kassel.de/sdnet4/sdnetrim/Lh0LgvGcu9To9Sm0Nl.HayIYu8Tq8Sj1Kg1HauCWqBZo5Ok4KfyIfuCWsESn4Qn0Ke.LauCYy8bm5Sm4LeyGavEZs9Tn8Sr1Ni1MbyIar9Ur8Si3RgzGexHcGJ/Beschlusstext_101.17.1154_-oeffentlich-_Ausschuss_fuer_Stadtentwicklung-_Mobilitaet_und_Verkehr_16.01.2014.pdf

Alle 3 Eigenschaften werden benötigt.

Der Eigenschaft resolutionText würde ich noch einen Typ mitgeben, ob es sich um "text/plain", full HTML oder nur einen body-Inhalt handelt. Ich denke, hier sind die Speicherformen der Betreiber sehr unterschiedlich.

sterni24 commented 10 years ago

Hier spricht einiges für ein neues Objekt oparl:Resolution, analog zu oparl:Paper.

Den Beschlüssen werden häufig eigene Anlagen zugewiesen, die sich erst aus der Beratung ergeben haben. Gleichermassen ließen sich Informationen zur Beschlussverfolgung / -erledigung abbilden.

marians commented 10 years ago

Ich finde den (ersten) Vorschlag von @sterni24 durchaus praktikabel. result drückt etwas ganz anderes aus, als die beiden resolution*-Eigenschaften. Ich finde die Modellierung sauber und nachvollziehbar.

Eine Einschränkung: Ich befürworte nicht, dass die Eigenschaft resolutionText verschiedene Dokumententypen unterstützen soll. Ich bin dafür, diese Eigenschaft ZWINGEND für reinen Text zu nutzen. Für Dokumente mit anderen Typen, eben auch HTML, steht ja resolutionDocument zur Verfügung. Das dort verlinkte Dokumente kann ja dann, wir in oparl:Document grundsätzlich spezifiziert, auch auf Derivate zeigen (derivativeDocument).

marians commented 10 years ago

OWL-Kompatibilität wird als Ziel für Version 1.0 nicht verfolgt. Im Dokument ist inzwischen die Lösung mit zwei EIgenschaften resolutionText und resolutionDocument umgesetzt. Das Issue wird daher geschlossen.