marians
Dokumenteneigenschaft type in Suche und Datenbank uneinheitlich
Die Art des Dokuments kann in der Original-Quelle, im Ratsinformationssystem der Stadt Köln, nahezu beliebige Werte annehmen. Hier sind die aktuell vorkommenden Typen:
Anfrage nach § 4 der GeschO des Rates
Anfrage nach § 4
Antrag auf eine Aktuelle Stunde nach § 5
Antrag nach § 3 der GeschO des Rates
Antrag nach § 3 der GeschO des Rates
Antrag nach § 3
Antrag nach § 12 (Dringlichkeitsantrag)
Beantwortung e. mündl. Anfrage (Auss.)
Beantwortung einer Anfrage (Ausschuss)
Beantwortung einer Anfrage (BV)
Beantwortung einer Anfrage (Rat)
Beantwortung einer mündl. Anfrage (BV)
Beschlussvorlage Ausschuss
Beschlussvorlage Bezirksvertretung
Beschlussvorlage Rat / Hauptausschuss
Beschlussvorlage Rat bzw. Hauptausschuss
Beschlussvorlage
Dringlichkeitsvorlage Ausschuss
Dringlichkeitsvorlage BV
Dringlichkeitsvorlage Bezirksvertretung
Dringlichkeitsvorlage Hauptauss. /Rat A
Dringlichkeitsvorlage Hauptausschuss
Dringlichkeitsvorlage Rat
Dringlichkeitsvorlage
Gem. Anfrage nach § 4 (SPD)
Gem. Änderungsantrag (SPD)
Mitteilung Ausschuss
Mitteilung BV
Mitteilung/Beantwortung - Ausschuss
Mitteilung/Beantwortung - BV
Mitteilungsvorlage
SPD Anfrage nach § 4
Stellungnahme zu e. Antrag (Ausschuss)
Stellungnahme zu einem Antrag (BV)
Stellungnahme zu einem Antrag (Rat)
Stellungnahme/Beantwortung - Rat
Da hier viele verschiedene Formulierungen für ein und denselben Typen verwendet werden, werden diese Formulierungen für die Suche durch solr_import.py normalisiert, so dass die folgenden Typen übrig bleiben:
Anfrage
Antrag
Beschlussvorlage
Dringlichkeitsantrag
Dringlichkeitsvorlage
Mitteilung
Das führt aktuell dazu, dass bei der Suche Anhand des Felds type die normalisierten Werte benutzt werden können/müssen.
Die ausgegebenen Dokumenteneigenschaften, die über die API-Funktion /api/documents für die Dokumenteneigenschaft type zurück gegeben werden, sind jedoch nicht normalisiert und entsprechen einem der Werte in der oberen Liste.
Eine Lösung wäre, die Dokumenteneigenschaft type grundsätzlich zu normalisieren. Damit geht jedoch Information verloren.
Die andere Möglichkeit wäre, sowohl die Original-Typbeschreibung als auch die normalisierte Beschreibung als jeweils eigene Dokumenteneigenschaft abzulegen. Damit ginge kein Detail verloren.
Meinungen hierzu bitte gerne in den Kommentaren!
Hier sind die Gründe der Entstehung der langen Liste der Stadt Köln wichtig. Offenbar hat eine intern verwendete Oberfläche dazu ermutigt mehrere Daten zusammen zu packen, die besser separat sein sollten. Und teilweise sind die Elemente der Liste sogar redundant (BV=Bezirksvertretung). Eine Normalisierung halte ich deshalb für angebracht. Die Rohdaten können allerdings eventuell bei einer Plausibilitätsprüfung helfen (Dringlichkeitsvorlage BV in Ausschuss statt in BV).
Für eine solche "normalisierte" Eigenschaft kann demnächst https://github.com/opengovld/skos verwendet werden.