Dokumentation | Code-Beispiele mit ../vocab/.. #240
Comments
|
Ihr Beispiel stammt aus dem Abschnitt Objektlisten / Kompakte und vollständige Form. Wenn eine solche URL an der Stelle Fragen aufwirft, wäre es unter Umständen besser, das JSON-Beispiel dort nicht mit einer URL, sondern mit einem einfachen String zu versehen. Die Entsprechung könnte "Mitteilung" lauten. Das eigentliche Konzept hinter den URLs in Eigenschaften wie paperType wird im Abschnitt "Vokabulare zur Klassifizierung" erläutert. Ob "classification" im Objekttyp oparl:Organization oder "paperType" in oparl:Paper, die dort genannten Eigenschaften funktionieren alle auf die gleiche Art und Weise: Sie können als Wert entweder einen String oder eine URL haben. (In einigen Fällen sind Arrays gefordert, d. h. die Eigenschaft muss analog als Wert ein Array von Strings oder URLs haben.) Wenn Sie Sich für URLs entscheiden wollen, dann ist das zu tun: Sie müssen entweder selbst auf einem Webserver Ihrer Wahl die berühmten skos:Concept Objekte ablegen. Oder Sie nutzen Alternativ die URLs von skos:Concept Objekten, die jemand anderes für diesen Zweck bereits auf einem öffentlichen Webserver hinterlegt hat. Wenn Sie also beispielsweise eine Drucksache mittels URLs klassifizieren wollen, könnten Sie auf einem Server Ihrer Wahl die folgenden Dateien anlegen: Wie der Inhalt dieser Dateien beschaffen sein muss, ist in "Vokabulare zur Klassifizierung" beschrieben. Diese URLs könnten Sie dann als Wert für die Eigenschaft "paperType" einsetzen. Für die sich anschließende Frage, warum sie das tun sollten: Das dient dazu, auf verschiedenen Systemen das selbe Vokabular zu benutzten. Wenn in A-Stadt und B-Ort jeweils der paperType "Antrag" ausgegeben wird, sieht das zwar identisch aus, man weiß aber nicht, ob das zufällig ist oder wirklich dasselbe gemeint ist. Verwendet man jedoch in beiden Städten dieselbe URL, kann es sich nicht um einen Zufall handeln. Perspektivisch könnte OParl auch solche Objekte/Dateien/URLs für Vokabeln zur Verfügung stellen. Aber das ist ein anderes Projekt. Halten Sie vor diesem Hintergrund die Beschreibung im Abschnitt "Vokabulare zur Klassifizierung" für ausreichend und verständlich, oder besteht da Bedarf für Nachbesserung? |
|
Das fällt für mich unter das Thema Standardisierung von OParl-Eigenschaften. Wenn jeder Server-Implentierer hier anfängt, eigene Dinge zu entwicklen, wird es unüberschaubar. Die Aussichten einer Standardisierung haben sie ausreichend erläutert. Ich würde die Möglichkeit der Nutzung dieser externen URLs aus dem OParl 1.0 rausnehmen. |
|
Ich rechne ja auch nicht damit, dass alle nun sofort anfangen, ihre eigenen Vokabulare zu hosten. Der Standardfall wird anfangs sicherlich sein, dass der Server einfache Strings ausgibt. Entspechend sollten wir evtl. darauf achten, in den Beispielen wo möglich von URLs zur Klassifizierung abstand zu nehmen und diese nur im Sonderfall einzusetzen. Aber warum würden Sie die Möglichkeit, mit URLs zur Klassifizierung zu arbeiten, aus OParl 1 rauslassen? Wegen der Verständlichkeit? Der Vorteile davon, die URLs für die Klassifizierung jetzt zu integrieren, wäre der, dass wir unabhängig von der weiteren Standard-Entwicklung (die ja ein bisschen dauern kann, wie wir sehen) am Vokabular arbeiten können. Wir können also sukzessive URLs/Vokabeln, z.B. für Drucksachen-Typen, bereitstellen, bevor die nächste OParl-Version verabschiedet wird. |
Was ist mit "extern" gemeint? Dass in den URLs andere Domains als die des RIS verwendet werden? Wozu diese Einschränkung? Dann müsste jede Körperschaft ihr eigene Begriffsmenge betreiben. Was wäre damit gewonnen? Die Unübersichtlichkeit würde dadurch nur noch größer, nicht kleiner. |
|
Ich verstehe unter "externen URLs" die Verwendung einer URL anstelle eines einfachen Strings. |
|
Zu Absatz 1: sehe ich auch so, ohne Sonderfälle Zu Absatz 2: ich würde für die OParl 1.0 saubere Abgrenzungen vornehmen. Zu Absatz 3: wenn es hier einmal Standardisierungen geben wird, dann würde ich so etwas für eine Version 1.1 oder 1.2 vorsehen. Das kann doch erst nach Freigabe einer solchen Spezifikation in den Server-Implementierungen entsprechend umgesetzt werden. Oder? |
|
Das würde zu einer noch viel größeren und noch dazu erzwungenen Unübersichtlichkeit führen. (Um auf die Parallelentwicklung hinzuweisen: In OpenGovLD werden einfache Strings für solche Zwecke nicht zugelassen, um eine geringe Redundanz zu erzwingen. Das gilt jedenfalls für Server mit höheren Ansprüchen an die Datenqualität.) |
|
@akuckartz externe URLs sind für mich Pfade, die nicht zu den festgelegten Objekten von OParl zählen. In diesem Zusammenhang meinte ich die "../vocab/.."-URLs. |
Das ist einfach. Eine Menge von |
Das sehe ich nicht so. Wir können in der OParl Spezifikation (Version 1.0) den Mechanismus beschreiben, und dann irgendwann - unabhängig vom Lebenszyklus der Spezifikation, ein Vokabular veröffentlichen. Das muss nicht teil einer neuen Spezifikations-Version sein. Möglicherweise kommt uns aber auch jemand anderes zuvor und macht sich die Mühe - dann müssten wir das von OParl nicht mehr tun. Oder beispielsweise ein Bundesland empfiehlt seinen Kommunen die Verwendung eines einheitlichen maschinenlesbaren Vokabulars, möchte aber damit nicht auf uns oder andere angewiesen sein und entwickelt lieber in einer Arbeitsgruppe ein eigenes. Wenn eine bestimmte Kommune jetzt schon mustergültig sein will, was Vokabulare betrifft, kann sie sich auch jetzt sofort ihr ganz eigenes entwickeln und dieses einsetzen, sobald ihr OParl Server läuft. Egal, mit welchem Vokabular irgendwer irgendwann herauskommt, folgendes ist relativ sicher: Es wird nicht jeden glücklich machen. Einzelne Begriffe werden irgendwo nicht passen. Daher ist es gut, wenn man verschiedene Vokabulare kombinieren kann. Wenn Immekepeln unter einem "Dringlichkeitsantrag" unbedingt etwas anderes verstehen will als Bottrop, dann macht Immekeppeln eben dafür eine eigene Vokabel. Das lässt sich ja kombinieren. Das System ist also ziemlich offen für verschiedenste Szenarien. Wir sollten nur darauf achten, dass es nicht kompliziert dargestellt wird. |
Das würde zu einer noch viel größeren und noch dazu erzwungenen Unübersichtlichkeit führen. Solange es hier keinen OParl-Standard gibt, gilt das für Ihr System mehr als für OParl 1.0. |
|
Ich stimme dem Kommentar von @marians vollständig zu. Genau das ist es worum es hier geht. Es wird eine Grundlage zu Vereinheitlichungen geschaffen, nicht eine konkrete Vereinheitlichung selbst. Solche Vereinheitlichungen können dann unabhängig und mit eigenem Zeitplan etc. geschaffen werden. |
|
Was muss denn ein Server-Implementierer tun, damit er diese Vocabs einsetzen kann? |
|
@sterni24 Wenn ein solches Vokabular bereits existiert (unter welchen URLs auch immer), dann muss eIn Server-Implementierer nur die URLs der jeweiligen |
|
Wer hat diese Objekte angelegt? |
|
@sterni24 Das kommt ganz drauf an. Solche Objekte können z.B. auf sitzungsdienst.net oder stadt-koeln.de oder nrw.de oder govdata.de von den Betreibern dieser Server angeboten werden. Oder z.B, ein Dienstleister oder Verein bietet solche Objekte in 30 Sprachen an (denn SKOS unterstützt von sich aus Mehrsprachigkeit). Das mag zunächst nach Unübersichtlichkeit aussehen, aber es würde einen immensen Fortschritt bei der Vereinheitlichung bedeuten. Wenn noch kein geeignetes Vokabular existiert und ein bestehendes RIS mit einer solchen Schnittstelle ausgerüstet werden soll, dann ist der Aufwand gut überschaubar: Statt z.B. einer Zeichenkette "Mitteilung" für die Art einer Drucksache müsste jeweils die URL des entsprechenden Wichtig vielleicht noch: Ein RIS-System kann bei Bedarf von einem Augenblick zum nächsten oder auch allmählich auf ein anderes Vokabular wechseln. Das wäre in technischer Hinsicht völlig ok. |
|
Das hört sich alles plausibel an, ist m. E. jedoch sehr praxisfremd. Ich nehme einmal die Eigenschaft Scenario 1: Scenario 2: ... das ist nur eine kleine Auswahl Bei jedem Datenabgleich muss der RIS-Betreiber die Existenz seiner Scenario 3: Daraus ergeben sich folgenden Der RIS-Hersteller oder RIS-Betreiber muss über eine Tabelle die Klassifizierung vornehmen und stetig auf Vollständigkeit überprüfen. Falls ein Scenario 4: Scenario 5: Zusammenfassung Aus RIS-Hersteller-Sicht sind für die Scenarien 1 und 2 überschaubare Entwicklungsarbeiten zu leisten. Scenario 3 halte ich dagegen schon für sehr aufwendig. Aus OParl-Sicht wäre Scenario 5 die einzig sinnvolle Anwendung von Ich würde die Einführung der . |
|
Noch ein Nachsatz: Perspektivisch könnte OParl auch solche Objekte/Dateien/URLs für Vokabeln zur Verfügung stellen. Aber das ist ein anderes Projekt. Das System ist also ziemlich offen für verschiedenste Szenarien. Wir sollten nur darauf achten, dass es nicht kompliziert dargestellt wird.. Ich bin für eine klare, verbindliche Spezifikation, ohne irgendwelche Interpretationsspielräume und Funktionalitäten, die ggf. in eine falsche Richtung führen (siehe vorstehende Szenarien). |
|
@sterni24 Danke für die Zusammenstellung und das Durchdenken der Szenarien. Ich denke aber, dass es weiterhin Missverständnisse über die Aufwände und Vorgehensweisen gibt. Zunächst zu den einzelnen Szenarien und dann zu dem (fast schon trivialen) minimalen Aufwand der für RIS-Entwickler und -Betreiber geleistet werden muss.
Um welchen Datenabgleich geht es? Wenn die RIS-Betreiber sich auf ihre eigenen
EIne solche Vorgehensweise mit Datenabgleich etc. ist schlicht nicht notwendig. Dazu eine mögliche Vorgehensweise ganz am Ende.
Weder Hersteller noch Betreiber müssen dies tun. Eine Vereinheitlichung erfordert tatsächlich Aufwand und die Verwendung von
Ein solches Objekt dem RIS-Betreiber zur Verfügung stehen. Er kann es auf seinem System hosten und muss dazu keinerlei externe Abstimmung durchführen.
Eine solcher Zwang muss nicht sein - ich würde ihn nicht für hilfreich halten! Eine solche einheitliche Klassifizierung sollte ein Angebot sein, kein Zwang.
Nein, ein solcher Zwang wäre tatsächlich fürchterlich. Eine Neuklassifizierung alter Daten ist nicht erforderlich.
Diese können dann genutzt werden (und sollen es eventuell auch), müssen es aber nicht.
Aus Client-Sicht ist gibt es keine nennenwerten Auswirkungen auf Performance, weder was Bandbreite betrifft noch Rechengeschwindigkeit o.ä. Ein Client hat dann aber die Möglichkeit z.B. auf einen Server zuzugreifen, der selber als Client auf RIS-Systeme mehrerer Kommunen zugreift und deren Daten weiter aufbereitet. Warum soll ein solcher Server nicht ebenfalls eine einheitliche Schnittstelle verwenden können ohne dadurch in seinen Möglichkeiten beschränkt zu werden?
Wie oben dargestellt wurde kann zwar Aufwand hineingesteckt werden, muss aber nicht. Einen geringen EInstiegsaufwand halte ich dafür auch für wichtig.
Nun zu der eingangs angekündigten fast trivialen Implementierungsmöglichkeit. Für die Begriffe "Antrag", "Beschlussvorlage" kann ein RIS-System diese zwei URLs automatisch bilden: Der Server kann dann aus den Werten automatisch Ein einfacher Client, der nur mit einem einzigen Server einer Kommune Verbindung aufnimmt wird relativ wenig Vorteile davon haben (Mehrsprachigkeit ist ein Beispiel, welche auch in einem solchen Szenario relevant sein kann). Auf je mehr Daten verschiedener Körperschaften zugegriffen wird, um so bedeutsamer wird die Möglichkeit zu Vereinheitlichung. Dazu hilft durchaus auch, wenn Kommune A ein eigenes Begriffs-Objekt für Anfragen hat und Kommune B ebenfalls ein eigenes Objekt für Anfragen. Das dann zusammenzuführen kann einem Client überlassen werden (der möglicherweise wesentlich mehr tut als Daten in HTML-Form aufzubereiten). |
|
Soweit mir bekannt ist, hat SKOS etwas mit Wissensorganisation tu tun. Das Beispiel in Scenario 3 geht in diese Richtung. Wenn der Client sich dieses Wissen letzendlich durch Sichtung aneignen (organisieren) muss, ist das eine fragwürdige Argumentation. Ich kann es nicht nachvollziehen, dass Wertelisten, die nicht eindeutig sind, in einer solchen Struktur abgelegt werden sollen / können. Solange es keine OParl-einheiliche Lösung gibt, werden wir in unserem RIS keinen Gebrauch davon machen. Da es aus meiner Sicht hier nichts mehr zu dikutieren gibt, schließe ich diesen Beitrag. |
Zur Verbesserung der Verständlichkeit. Vgl. Issue #240
|
Damit die skos:Concept Idee in der Spezifikation nicht im Weg steht, habe ich in allen Beispielen anstelle der URLs einfache Strings eingefügt. Evtl. werde ich unter "Vokabulare zur Klassifizierung" noch etwas mehr dazu schreiben, damit es wenigstens dort deutlich wird, was mit externen Vokabularen gemeint ist. |
|
@sterni24 Da das leicht zu übersehen ist: SKOS sieht auch die Möglichkeit der Festlegung von Reihenfolgen für Begriffe vor. Diese Eigenschaft war bisher auch die Grundlage um z.B. die Reihenfolgen der Anzeige von Ausschüssen festzulegen. Dazu gab es das eine oder andere Issue. Wenn keine |
|
Das glaube ich jetzt nicht! Zeigen Sie mir das mal auf! Aber konkret und nicht als ein Verweis auf www. |
|
Ich hatte in dem Kommentar #167 (comment) am Ende ein einfaches Beispiel für die Angabe einer solchen Reihenfolge angegeben. Möglicherweise ist das bislang nicht in die Spezifikation eingeflossen. |
|
Was hat das mit einer Sortierung zu tun? |
|
Die Werte der Eigenschaft |
|
Also gilt dies nicht für OParl 1.0. |
|
Ja, diese Sortierung wurde gewissermassen zusammen mit JSON-LD entsorgt. |
Was muss der Serverimplementierer tun, um solche URL anwenden zu können?
Beispiel:
"https://oparl.example.org/vocab/message".
Hier fehlt ein allgemeiner Beschreibungsteil in der Doku.
The text was updated successfully, but these errors were encountered: