Datenmodell Termin: Ort

[CatoTH]

Bei den Terminen sollte eine Möglichkeit bestehen, den Ort genauer anzugeben. Entweder durch ein einfaches Textfeld, oder durch eine Beziehung zu einem "Ort"-Objekt.

Beispiele, wo das in München vorkommt: http://www.ris-muenchen.de/RII2/RII/ris_sitzung_detail.jsp?risid=2799821 http://www.ris-muenchen.de/RII2/BA-RII/ba_sitzungen_details.jsp?Id=2817299

[marians]

Die einfacherer Variante, die den Status Quo abbildet, ist wohl, hier ein Textfeld vorzusehen, in dem so etwas wie "Rathaus, Raum 136" stehen kann. So habe ich es nun in das Dokument aufgenommen.

[mrtopf]

Ich würde mir bei Adressen (kommt ja auch bei Person usw. vor) mehr Struktur wünschen, also Strasse, PLZ, Stadt usw. lieber in separaten Feldern (zumindest bei uns wird das auch separat in verschiedenen Zeilen in der Ausgabe dargestellt).

[marians]

Okay, verstehe. Ich habe bisher die Textversion (description) am Ort-Objekt ausschließlich für menschliche Nutzer gedacht. Für Maschinen gibt es ja die Koordinaten. Aber die gibt es ja eben in vielen Fällen dann leider doch nicht. Werde das ergänzen.

Falls Ihr es nicht gesehen habt: Ich habe heute am Ort-Objekttyp im Dokument eine Ergänzung vorgenommen.

[mrtopf]

wobei ja nicht jedes RIS Koordinaten hat und vll. will man ja auch noch "2. Etage" reinschreiben, z.B. bzgl. Sitzungsraum. Ein Adresszusatz wäre daher evtl. auch noch gut.

[akuckartz]

Falls es ganz perfekt sein soll, dann gibt es zum Aufbau von Adressen übrigens Informationen beim Weltpostverband: http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html

[marians]

Wir müssen also Adressangaben als Sitzungsort, für Personen sowie am "Ort" Objekt vorsehen. Können wir mit diesem Schema alle drei erschlagen?

{
    "street_address": "Hauptstraße 16a",
    "address_extension": "Hauptgebäude, Raum 147",
    "postal_code": "01234",
    "locality": "Musterstadt"
}

[akuckartz]

Zu Adressen siehe auch #38

[marians]

Hier könnte http://schema.org/Place verwendet werden. Das bietet natürlich sehr viel mehr, als von mir noch etwas weiter oben aufgeführt. Aber man muss ja nicht den gesamten Umfang eines angebotenen Schemas implementieren.

[marians]

Nach dem Workshop haben wir die Tendenz, für Ortsangaben zu Sitzungen, Personen, Organisationen etc. ein einheitliches Schema zu erstellen, das außerdem die Anforderung aus #29 (Örtlicher Bezugspunkt der parlamentarischen Befassung) mit abdeckt.

Weiterhin ist aufgefallen, dass nach Möglichkeit Hausnummern in einem eigenen Feld enthalten sein sollten, um die Verarbeitung zu erleichtern.

Hier wäre das obige Beispiel, korrigiert:

{
    "street": "Hauptstraße",
    "housenumber": "16a",
    "address_extension": "Hauptgebäude, Raum 147",
    "postal_code": "01234",
    "locality": "Musterstadt"
}

Das ist im übrigen nicht kompatibel mit dem für unsere Zwecke ohnehin deutlich zu umfangreichen Schema http://schema.org/Place . Daher auch die Vereinfachung der Attributnahmen in Abweichung vom schema.org "Place".

Hier ein Beispiel, das darstellt, wie mit einer Kombination aus Adressattributen, einem Freitextfeld und Geoinformation die genaue Lage einer Straßenkreuzung, die Gegenstand einer Beratugn sein könnte, kodiert werden kann:

{
    "street": "Zülpicher Straße",
    "housenumber": "247",
    "locality": "Köln",
    "description": "Kreuzung Zülpicher Straße/Robert-Koch-Straße/Ägidiusstraße",
    "geoinfo": {
        "type": "Feature",
        "geometry": {
            "type": "Point",
            "coordinates": [6.924189, 50.92312]
        }
    }
}

Die Position, die sich aus "street" und "housenumber" ergibt, ist eine Annäherung, die nicht erforderlich wäre, aber die Position bereits recht genau beschreibt. Das "description"-Attribut ist ein Freitextfeld, das Nutzern kommuniziert, dass es nicht etwa um die Hausnummer 247 geht, sondern um eine Kreuzung. Das attribut "geoinfo" ist ein GeoJSON-Objekt, das die Position der Kreuzung genau und maschinenlesbar kommuniziert. Die GeoJSON-Sezifikation: http://geojson.org/geojson-spec.html#geojson-objects

[marians]

Die Inhalt sind nun ins Dokument eingeflossen. Das Issue wird daher geschlossen.

https://github.com/OParl/specs/blob/master/dokument/master/chapter_8130.md