JSON-LD Unterstützung #237
Comments
|
Die Behauptung, dass die Nicht-Verwendung von JSON-LD eine "simple Client-Implementierung" oder einfachere Validierung ermögliche halte ich aus mehreren Gründen für abwegig. Ohne JSON-LD wird
Es stellt sich für mich die Frage inwieweit bzw. weshalb die in dem OParl-Dokument aufgelisteten "Unterstützer" (darunter Kommunen und RIS-Hersteller) diese Entscheidung stützen und würde vor allem gerne deren Stellungnahmen sehen. Für mich sieht das sehr nach einem Versuch aus, einen "Standard" jetzt auf Teufel komm raus möglichst kurzfristig veröffentlichen zu wollen wärend andere für echte Standards wesentliche Aspekte in den Hintergrund geraten. (Nebenbei: dazu gehört auch der Umgang mit dem nicht besonders komplizierten aber für Client-Konformität entscheidenden #140 ) Ich möchte auch auf die von Fraunhofer FOKUS im Auftrag des BMI erstellte Open Government Data Studie hinweisen, in der bereits 2012 im Abschnitt "4.5.6 Linked Open Data" kurz und bündig auf die Bedeutung des Themas "Linked Data" und die Verwendung entsprechender Standards eingegangen wurde - als das W3C mit der Erstellung der JSON-LD-Recommendation gerade begonnen hatte. |
|
@marians Als RIS-Hersteller unterstütze ich die Entscheidung, OParl 1.0 auf den "kleinsten gemeinsamen Nenner" zurückzuführen. @akuckartz Für mich stand zunächst der Entwurf des Datenmodells im Vordergrund. Im Zuge der Beiträge um einzelne Aspekte der Implementierung wurden hier immer wieder formalistische, ja fast wissenschaftliche Betrachtungen eingestreut, die zudem in elend langen Diskussionen, gespickt mit reichlich Quellenangaben aus w3.org, skos, hydra, SPARQL & Co., endeten. Ich habe versucht, einigen Argumenten und Quellen zu folgen; es ist mir nicht wirklich gelungen. Andere Beiträge von "Hobbyisten" unterstützen meine Sichtweise. Man hätte dieses Projekt vielleicht in OParlData und OParlTech trennen sollen. Es wurde versäumt, die OParl-Teilnehmer dort abzuholen, wo sie stehen. Die externe Mitarbeit in diesem Forum ging schon fast gegen 0, ach ja, es muss heißen 'null'. Blicken wir nach vorn: es kann doch kein großer Schritt sein, in OParl 1.5 oder 2.0 eine erweiterte Spezifikation mit JSON-LD zu realisieren. |
Ja, das war sicherlich kontraproduktiv und hat den Eindruck von massiv erhöhter Komplexität erweckt.
Es ist mir nach wie vor nicht wirklich klar wie das Projekt eigentlich organisiert ist, wo die Diskussionen stattfinden (wirklich hier auf GitHub? Hab z.B. bez. der Entscheidung JSON-LD nicht mehr zu unterstützen absolut keine Diskussion gesehen) und wie Entscheidungen getroffen werden.
Falls das wahr ist, dann sollte die Gelegenheit jetzt genutzt werden. Es macht meiner Meinung nach keinen Sinn noch eine weitere JSON Variante zu erfinden und zu "standardisieren"... wir haben bereits mehr als genug davon. Hier wäre ein konkreter Vorschlag für die weitere Vorgehensweise: 1.) Es werden Beispieldokumente für jeden "Objekttyp" erstellt. Diese können gerne in einer Ordnerstruktur abgelegt und gegenseitig referenziert werden so dass man praktisch eine statische Version der OParl API bekommt was auch hilft mal alles "in Aktion" zu sehen. Wie klingt das? |
|
Die Frage kann ich Ihnen nicht beantworten. Wir haben bereits ein solches Projekt als propietäre Eigenlösung schon mehr als 2 Jahren umgesetzt, allerdings nicht mit JSON / JSON-LD. Deswegen liegt mein Focus auf der praktischen Umsetzung von OParl, sowohl in Entwicklung als auch in der Anwendung. |
|
Die Entscheidung, in OParl 1.0 nicht auf JSON-LD zu setzen, wurde aus mehreren Gründen getroffen: 1. JSON-LD wurde nicht unter der richtigen Prämisse eingeführtEines unserer Design-Prinzipien für OParl ist, dass wir uns am Status Quo ausrichten. Das bedeutet zum Beispiel bei der Datenmodellierung, dass wir in der Regel nur solche Objekttypen und Eigenschaften definieren, die für die Abbildung der Daten, die in gängigen Ratsinformationssystemen geführt werden, benötigt werden. An der einen oder anderen Stelle haben wir optionale Komponenten hinzugefügt, die über den Status Quo hinausweisen, zum Beispiel wenn es um die Abbildung komplexer Geodaten geht. Diese Lösungen sind dann jedoch "unobtrusive", das heißt, sie stehen dem, der sie nicht nutzen möchte, nicht im Wege. Dahinter steht der Plan, das Komplexitätsniveau mit Version 1.0 von OParl noch gering zu halten. Unsere Priorität liegt seit Beginn darauf, einen leicht implementierbaren Standard zu gestalten, und dann möglichst bald mit ersten Implementierungen echte Erfahrungen in der Praxis zu sammeln. Anhand solcher Erfahrungen könnte man OParl dann weiter entwickeln. Im Rahmen dieser Fokussierung war "Linked Data" für mich von Beginn an kein Thema für die Version 1.0. Warum? Weil die Daten der Ratsinformationssysteme (der besagte Status Quo) nicht mit Linked Data im Hinterkopf modelliert wurden. Eine Drucksache, die in Köln den Typ "Antrag nach §4 der Gemeindeordnung" heißt, kann z. B. in Düsseldorf "Dringlichkeitsantrag" heißen, oder anders. Die Zusammenführung solcher Vokabeln, die die grenzübergreifende Auswertung dieser Daten erlauben würde, sehe ich als arbeitsintensives Thema für die Zukunft. Diese kann jedoch besonders gut dann erfolgen, wenn einige Ratsinformationssysteme bereits dank OParl programmatisch ausgelesen werden können. So kann man beispielsweise einen Überblick über alle verwendeten Bezeichnungen erstellen. Beim Workshop in Bielefeld (Januar 2014) wurde das Thema JSON-LD diskutiert. Hier wurden als die wesentlichen Pro-Argumente
genannt. Nun ist (1) ein ehrbares Ziel, hatte aber für Version 1.0 eigentlich keine Priorität. Wir gehen nach wie vor davon aus, dass die Clients, die sich mit einem OParl-Server verbinden, in Kenntnis der OParl Spezifikation entwickelt wurden und nicht als abstrakte Crawler. (2) ist ebenfalls gut zu haben, ist jedoch ebenfalls kein hoch priorisiertes Ziel für Version 1.0. Und wenn es nur um eine Tripel-Darstellung der Inhalte geht, gibt es sicherlich Möglichkeiten, hier mittels Software zu konvertieren. Der eigentlich interessantere Aspekt von Linked-Data, nämlich die Verwendung bereits bekannter Vokabulare, ist jedoch völlig unabhängig von der Serialisierung der Ausgabe. Hier hilft uns JSON-LD nicht. (3) ist auch ohne JSON-LD trivial. In JSON-LD hätten wir einen Präfix wie "foo:" per Kontext einer Namespace-URL zugewiesen. Ohne JSON-LD nutzen wir den "foo:" Präfix, ohne dass dieser zu einer Namespace-URL wird. (4) ist bei näherer Betrachtung eigentlich kein Pro-Argument, sondern sagt aus, dass es keinen nennenswerten Schaden anrichtet. Tatsächlich würde ich diesem Argument aber aus heutiger Sicht nicht mehr zustimmen. Siehe dazu weiter unten. Nach meiner Erinnerung gab es einen einzigen wahrnehmbaren Fürsprecher für JSON-LD bei diesem Workshop, der Rest war skeptisch oder neutral. Mit der vorläufigen Annahme, dass sich dadurch OParl nicht verkomplizieren würde, habe auch ich damals der JSON-LD-Unterstützung zugestimmt. Nun bewerte ich diesen Schritt anders und stelle fest, dass wir JSON-LD aus den falschen Gründen in den OParl-Entwurf eingeführt haben und die Nebenwirkungen seinerzeit nicht richtig eingeschätzt haben. 2. OParl auf JSON-LD aufzubauen bedeutet, dass man JSON-LD (und mehr) verstanden haben muss.Einen OParl-konformen Client zu entwickeln, würde damit an Entwickler auch die Anforderung stellen, JSON-LD in gewissem Maße verstanden zu haben. Ebenso würde es an Server-Entwickler die Anforderung stellen, JSON-LD verstanden zu haben. Das ist keine Kleinigkeit, denn es handelt sich bei JSON-LD - anders als je nach Kontext gerne angeführt wird - ja nicht nur um kleine Syntax-Erweiterungen zu JSON-Objekten. Mit JSON-LD werden eine Reihe von Konzepten eingeführt, die dazu führen, dass man OParl nur richtig nutzen und weiter entwickeln kann, wenn man diese verstanden hat. Dazu gehört:
Ich gebe freimütig zu, dass ich lange gebraucht habe, um zu verstehen, was alles hinter JSON-LD steckt und dass es weit mehr ist, als eine kleine syntaktische Ergänzung zu JSON. Und ich behaupte noch nicht, das vollständig begriffen zu haben. Aus den Diskussion mit Entwicklern kann ich abschätzen, dass es anderen ähnlich ging. Bevor wir JSON-LD eingeführt haben, konnten wir uns in einer breiten, heterogenen Gruppe von Stakeholdern über das OParl Datenmodell unterhalten. Ich glaube, dass es auch an JSON-LD liegt, dass sich der Kreis der Mitwirkenden hier stark verkleinert hat. 3. Linked Data macht einiges kompizierter, was einfach sein könnteMit der Entscheidung, mit OParl JSON-LD zu fordern, schien für einzelne eine weitere Entscheidung ebenfalls gefallen zu sein: nämlich dass überall, wo möglich, externe Vokabulare genutzt werden müssten. Anstatt sich eine zur Domäne passende Bezeichnung für eine Eigenschaft auszusuchen und diese abzustimmen, wurde nun in definierten Vokabularen wie vcard, foaf oder schema.org nach der passenden Eigenschaft gesucht. Das Problem dabei:
Das kann man natürlich nicht JSON-LD zur Last legen, aber es scheint der Lokig zu folgen, dass wer A sagt, auch B sagen muss. In ähnlicher Art und Weise wurde es plötzlich sehr kompliziert, einfache Dinge wie die Paginierung von Listen zu realisieren. Während wir mehrere praktikable Mechanismen diskutiert und beschrieben hatten, passte keine davon so recht zu Linked Data und JSON-LD. Alleine diese Fragestellung hat sich über Wochen gezogen. 4. Die Freiheitsgrade, die ein Server bei der Ausgabe von JSON-LD hat, erschweren die ValidierungIn JSON-LD kann jedes Attribut eines Objekts beliebig viele Werte haben. Das heißt, in einem Objekt kann eine Eigenschaft einen String als Wert haben, im nächsten ein Array von Strings. In JSON hingegen kann man simpel an der Syntax erkennen, ob es sich um ein Array oder einen eizelnen Wert handelt. Die verschiedenen syntaktischen Formen (Expanded, Compacted, Flattened, Framed) sind sämtlich inhaltlich identisch, unterscheiden sich aber formell stark. Ausgerechnet die "Compacted" Form, die einer üblichen JSON-Notation am ähnlichsten sieht, ist jedoch nicht streng definiert. So gibt es für ein bestimmtes "Expanded" Objekt beliebig viele Notationen in "Compacted" Formen. Kontext (@context) kann direkt im Dokument ausgegeben oder über eine externe URL referenziert werden. Es kann beliebig viele Kontexte geben, wobei auch lokale und externe gemischt werden können. URLs können ausgeschrieben oder durch Präfixe, die im Kontext definiert werden, verkürzt werden. Listen können als [] geschrieben werden oder als {"@list": []} oder als {"@set": []}. Ein Key-Value-Paar mit einem einfachen String kann entweder so ausgegeben werden oder so: Das alles heißt: Mit JSON-LD verkompliziert sich das Problem der Validierung. Aber nicht nur das. Will man einzelne dieser Freiheitsgrade einschränken, muss man dafür zusätzliche Anforderungen formulieren. Diese wiederum können die Server-Implementierung verkomplizieren, weil eine eventuell verwendete JSON-LD-Bibliothek die Beeinflussung des jeweiligen Kriteriums nicht erlaubt. In jedem Fall machen sie die Spezifikation umfangreicher und schlechter verständlich. Die Validierung, also eine verbindliche Aussage darüber, ob ein Server OParl-konform arbeitet, ist aus meiner Sicht für die Akzeptanz von OParl sehr wichtig. Diese Sicht spiegeln mir auch Hersteller-Vertreter. 5. JSON-LD-Bibliotheken sind noch frisch oder fehlenEin iOS-Client (iPad, iPhone) beispielsweise würde üblicherweise in Objective C geschrieben. Client-Entwickler müssten auf dieser Plattform momentan ohne eine Bibliothek zur Normalisierung von JSON-LD auskommen und das Parsing selbst übernehmen. Das ist, aufgrund der oben beschriebenen Freiheitsgrade, nicht zu unterschätzen. Für die Windows-Welt ist unter http://json-ld.org/ bislang nur eine einzige Bibliothek (in C#) aufgeführt, diese basiert auf einem auto-Port der Java-Implementierung. Anzahl Entwickler: einer, letzter Commit: vor 4 Monaten. Da können Windows-Entwickler nur hoffen, dass da schon alles fertig ist. Für Python gibt es bislang eine einzige Bibliothek, PyLD. Meine eigenen Gehversuche damit haben mir gezeigt, dass wir es hier noch mit sehr junger Software zu tun haben. So war es mir beispielsweise nicht möglich, Objekte mit mehreren Kontext-URLs zu parsen. Kommentare zu Bugs und Pull Requests wie z.B. digitalbazaar/pyld#13 zeigen, dass der Code hinter der Spezifikation hinterher hinken könnte. ZusammengefasstFasst man die oben aufgezählten Punkte zusammen, dann bin ich der Überzeugung, dass wir die Entscheidung, JSON-LD für OParl vorauszusetzen, teils aus guten Absichten, teils aus Unwissenheit getroffen haben. In der Annahme, dass wir damit keinen Schaden anrichten. Tatsächlich ist Schaden entstanden, indem wir den Fokus verloren haben, unsere Zeitpläne mehrfach nicht eigehalten haben und etwas geschaffen haben, dass von einigen, die es umsetzen sollen, nicht mehr verstanden und/oder akzeptiert wird. Mit der Abkehr von JSON-LD und der Tendenz zur Linked-Data-Konformität kehren wir zurück zu einer leichtgewichtigen Spezifikation für die Version 1.0, die es ermöglichen soll, schon bald echte Praxiserfahreungen zu sammeln und dann auf Basis dieser Erfahrungen weitere Entscheidungen treffen zu können, was für eine Weiterentwicklung wichtig ist und was nicht. Markus, um auf Deine Frage nach dem Entscheidungsweg zu beantworten: Unterstützend für die Entscheidung war Feedback, dass zum Ende der Review-Phase, zum an mich persönlich gerichtet, eingegangen ist. Ein Teil davon wurde hier auf Github diskutiert. Diskussionen haben aber auch in Telefonaten, Hangouts und Mails stattgefunden. Am 25. Juni habe ich telefonisch mit Vertretern von drei beteiligten Herstellern (Ralf Sternberg, Babett Schalitz/CC e-Gov, Bern Thiem/Somacos) gesprochen, um zu klären, ob aus ihrer Sicht etwas gegen die Abkehr von JSON-LD (oder für die Unterstützung) spricht. Das für mich nicht überraschende Feedback war, dass aus ihrer Sicht nichts gegen den Verzicht auf JSON-LD spricht. Am vergangenen Freitag hat darüber hinaus nach längerem Mail-Wechsel eine Telefonkonferenz zwischen den OParl-Initiatoren (Christine Siegfried/VITAKO, Jens Klessmann/Fraunhofer FOKUS, meine Wenigkeit) und Andreas Kuckartz stattgefunden. Das Ergebnis dieses Austauschs ist, dass wir (die Initiatoren) OParl 1.0 ohne Unterstützung von JSON-LD und RDF-Serialisierbarkeit fertig stellen wollen. |
|
@sterni24 Ich unterstütze den Vorschlag von @lanthaler . Die heute in den
Ich versuche grundsätzlich meine Standpunkte zu belegen und gebe deshalb Quellen an. Dass das hier nicht funktioniert hat finde ich bedauerlich.
Ich habe diese Behauptung letzte Woche schon von anderer Seite gelesen. Die Entwicklung der Mitarbeit hier auf GitHub ist lückenlos nachvollziehbar. Ich habe mir das deshalb Ende letzte Woche einmal für die ganze Zeit der Existenz des OParl specs Projekts angesehen - und auch was für Beiträge es vor etwa Januar 2014 gab oder nicht gab. Diese Daten sprechen eine etwas andere Sprache. |
|
@lanthaler: Vielen Dank für den Vorschlag, aber damit drehen wir uns im Kreis und tun das, womit wir schlechte Erfahrungen gemacht haben, noch einmal. |
|
@marians Ich hätte es begrüßt, wenn dieser längere Kommentar hier letzte Woche in Form eines Issue aufgeschlagen wäre. Das hätte möglicherweise manches vereinfacht. Ich nehme an, dass @lanthaler sich für deinen Kommentar sehr interessiert und insbesondere auf die JSON-LD betreffenden Punkte antworten wird und möchte ihm nur ungern vorgreifen. Dennoch zu ein paar Punkten meine Sicht der Dinge.
Ich weiss nicht wer mit diesem "Wir" genau gemeint ist. Ich jedenfalls gehöre zu denen, die mit generischen Clients zugreifen wollen.
Ich finde es bedauerlich, dass trotz mehrerer Hinweise #222 ignoriert wurde und wird und auch die Punkte 3 und 4 des Vorschlags von @lanthaler von heute.
Noch einmal: die GitHub-Daten der letzten eineinhalb Jahre sprechen eine völlig andere Sprache. Das betrifft sowohl die Beteiligung im Issue-Tracker als auch bei der Erstellung von Pull-Requests. Das Schreiben von Spezifikationen ist aufwändig - wenn sie etwas taugen sollen. Mal an einem Workshop teilnehmen ist eine Sache, dann an Details zu feilen bis alles passt ist etwas ganz anderes.
Das nehme ich ganz auf meine Kappe. Auch hier wollte ich nicht das Rad neu erfinden wie es unzählige Web APIs machen. Wenn ich die von Hydra übernommene Lösung von Anfang an gekannt hätte, dann hätte ich sie möglicherweise direkt vorgeschlagen. Angesichts der etwa eineinhalb Jahre, über die sich die OParl-Entwicklung insgesamt erstreckt hat halte ich ein paar Wochen als Zeitraum für diesen nicht gerade nebensächlichen technischen Aspekt für harmlos.
Einer der Entwickler des Validators hat selbst erklärt, dass das dem nicht so ist. Und das gilt sogar dann, wenn man alle Freiheitsgrade offen lässt, da die JSON-LD Dokumente durch einen Einzeiler in eine kanonische Form gebracht werden können (unter Verwendung der JSON-LD Library) und dann weiter bearbeitet werden können.
Ich verweise noch einmal auf #222
Der Hinweis auf diese Verkomplizierung der Server-Implementierung bezieht sich offenbar auf einen Kommentar, den ich vor einer Weile in Zusammenhang mit Präfixen "auf der rechten Seite" gemacht hatte. Wenn ein JSON-LD Profil (#222) präzise festgelegt ist, dann können zum Schreiben möglicherweise keine JSON-LD Libraries verwendet werden. Dann muss direkt JSON geschrieben werden (EDIT: in JSON-LD konformer Weise) - wie bei Nicht-Verwendung von JSON-LD auch. Bei einer Gewichtung der Vor- und Nachteile zur Alternative, dass OParl kein JSON-LD verwendet verblasst das völlig und ist nicht irrelevant. Und bei dem zu erwartenden JSON-LD Profil wäre es ohnehin kein praktischer Unterschied.
Noch einmal: #222 Wenn ein Client mit einem JSON-LD Kontext nichts anfangen kann, dann nutzt er ihn halt nicht. Muss er nicht. Punkt. Das bedeutet nur, dass andere Clients die den Kontext nutzen können zusätzliche Vorteile haben, nicht aber, dass ein iOS-Client wegen JSON-LD irgend einen Nachteil hätte.
Dazu ist schwer etwas zu sagen, solange das genaue Aussehen dieser JSON-Objekte nicht bekannt ist.
Das war In der Tat nicht überraschend: Du hattest ja dafür gesorgt, dass du alleine mit ihnen sprechen konntest - trotz meines mehrfach geäußerten Wunsches das diese auch meinen Standpunkt kennen lernen. Dieses intransparente Vorgehen war einer der zwei Gründe, warum ich mich am Freitag aus dem Projekt zurückgezogen habe.
Ja, eine Entscheidung die ich für eindeutig falsch halte. Und mit der Nicht-Unterstützung von JSON-LD war nachträglich auch die "Geschäftsgrundlage" für meine Beteiligung an OParl weggefallen. |
|
Andreas, Dein Ton vedirbt mir langsam die Lust, auf Deine Kommentare weiter einzugehen. In Deiner Mail vom 25. Juni, 11:35 Uhr hast Du Jens, Christine und mir geschrieben, dass Du erst am nächsten Tag ausführlich zum vorgeschlagenen JSON-LD Rückzug würdest Stellung nehmen können. Und weiter: "Dann sollten wir das gegenüber den RIS-Herstellern zusammen mit den verschiedenen Gesichtspunkten zur Diskussion stellen." - Da keiner der RIS-Hersteller bislang als Befürworter von JSON-LD aufgefallen ist, konnte ich mir schwerlich vorstellen, dass diese nun gegen die Abkehr von JSON-LD sein sollten. Das Ziel meiner Kontaktaufnahme mit den Herstellern war, das ohne nennenswerten Zeitverlust zu überprüfen. Am Freitag haben Du und ich festgestellt, dass wir bestimmte Gesichtspunkte, die OParl betreffen, sehr unterschiedlich bewerten. Es ist, wie Du selbst sagst, die "Geschäftsgrundlage" für Deine Beteiligung an OParl weggefallen. Ich bin Dir für Deinen bisherigen Einsatz dankbar. Aber was wird das jetzt hier? Im Moment kommt es mir vor wie Trollen. |
|
Der Vollständigkeit halber: Der Vorschlag von Marian zum "Rückbau von JSON-LD" kam am 25.6. um 8:00 Uhr und in meiner Antwort 3,5 Stunden später hatte ich bereits angedeutet, dass ich den Vorschlag nicht unterstütze. |
|
"OParl ist eine Initiative zur Standardisierung des offenen Zugriffs auf parlamentarische Informationssysteme in Deutschland." @akuckartz @lanthaler Ich merke, dass ihr über die nötigen Kompetenzen für eure Bereiche verfügt. Linked-Data ist eine sinnvolle Sache und wenn ich Hydra einigermaßen verstanden habe ist das auch ein wertvolles Ding. Aber für Version 1.0 halte ich den damit verbundenen Aufwand für Otto Normal für unzumutbar. Versteht mich hier bitte wirklich nicht falsch, das sind alles sinnvolle und unterstützenswerte Konzepte. Und wenn es mit dem JSON-LD-Profil tatsächlich möglich ist das JSON an sich nicht zu "verunreinigen" und eine kanonische Form bereitzustellen (?) dann sage ich: Warum erst in OParl 1.5? Das ist doch ein toller Zusatz und sollte nach Möglichekeit in 1.1 gestartet werden! @akuckartz Ich war tatsächlich erstaunt als ich gesehen habe mit welchem Elan du an dem Projekt mitarbeitest. Was spricht dagegen in naher Zukunft bereits eine Version 1.1 zu veröffentlichen, welche sich um Linked-Data bemüht? Nochmal kurz zur 1.0: |
|
Eins mal vorweg: Lasst uns bitte versuchen sachlich zu bleiben und die beste technische Lösung zu finden anstatt nach „Schuldigen“ zu suchen. Vielen Dank für die detaillierte Antwort @marians und auch vielen Dank an @black-snow für die Darlegung deiner Sichtweise. Da @akuckartz schon einige Punkte angesprochen hat, versuche ich mich kurz zu halten und nur einige Punkte herauszupicken die mir wichtig erscheinen.
Linked Data unterscheidet sich in der Hinsicht nicht sonderlich von dem was OParl zu erreichen versucht, nämlich eine Harmonisierung des Datenmodells unterschiedlicher RIS Systeme so dass man nicht für jedes RIS spezialisierte Clients bauen muss. Kapitel 5 (Schema) der Spezifikation macht genau das. Es werden einheitliche "Objekttypen" mit dazugehörigen Eigenschaften definiert. Die einzige Anforderung von Linked Data besteht darin dass diese Dinge nicht nur mit String Tokens wie "oparl:Body" identifiziert werden, sondern auch über eine URL, also z.B. http://oparl.de/schema#Body.
Entweder wir verstehen uns hier falsch, oder ich hab die ganze Idee die OParl zugrunde liegt falsch verstanden. Ich hatte angenommen das genau eine solche "grenzübergreifende (über die Grenzen eines einzelnen RIS hinaus) Auswertung dieser Daten" das Ziel von OParl ist. Deshalb wir eine Spezifikation geschrieben und alle RIS die OParl unterstützen liefern Daten anhand eines einheitlichen Datenmodels. In anderen Worten, sie nutzen das gleiche Vokabular um sich auszudrücken. Nur weil es ein einheitliches Datenmodel (Vokabular) im Hintergrund gibt, heißt nicht dass auch alle Benutzeroberflächen gleich aussehen müssen - falls das gemeint ist.
Genau das bedeutet es eben nicht und ich genau das ist der Knackpunkt an der aktuellen Diskussion meiner Meinung nach. Natürlich sollten die Leute die die Spezifikation schreiben JSON-LD verstehen, Benutzer derselben müssen JSON-LD aber nicht verstehen. Man könnte genau das gleiche Argument für andere, tieferliegende Layer benutzen. Müssen Entwickler TCP, DNS, IP, Ethernet, IEEE 802.11 und so weiter verstanden haben um OParl einzusetzen? In der Regel wohl kaum.
All das wird von der OParl Spezifikation festgelegt, das heißt Client & Server Entwickler müssen sich nicht mehr darum kümmern. Entwickler die sich damit nicht beschäftigen wollen konsumieren und produzieren einfach JSON wie von der Spec gefordert. Nicht mehr, nicht weniger.
Das (und der media type) ist das einzige das Entwickler von JSON-LD zu sehen bekommen. Ein kurzer Absatz in der Spec mit einem Verweis auf die JSON-LD Spezifikation sollte mehr als ausreichend sein.
Ja, das ist in der Tat eine der "Schwächen" der "Semantic Web Community" und einer der Hauptgründe warum so viele Projekte Abstand davon nehmen. Wir sollten das pragmatisch sehen. OParl macht zur Zeit nichts anderes als implizit ein Vokabular (mit dazugehörigen JSON Strukturen) zu definieren. Alles was fehlt sind URLs für dies definierten Vokabeln. Das Mapping zu anderen, externen Vokabularen kann problemlos und völlig deklarativ später gemacht werden.
Sich wirklich mit den Konsequenzen der Datenmodellierung auseinanderzusetzen und die eigentliche Bedeutung der Daten näher zu beleuchten wirft natürlich Probleme auf die bei ad-hoc Designs meist unter den Tisch gefegt werden (nicht falsch verstehen: ich sage hier nicht das die diskutierten Mechanismen ad-hoc Designs waren). Langfristig zahlt sich das aber immer aus und auch das kann nicht wirklich JSON-LD oder Linked Data zur Last gelegt werden.
Der einzige Grund warum Spezifikationen geschrieben werden ist es solche Freiheitsgrade zu minimieren um damit Interoperabilität herzustellen. Je nach den Anforderungen, können mehr oder weniger Freiheitsgrade sinnvoll sein. Falls JSON-only clients auch unterstützt werden müssen (und davon gehe ich hier aus), muss die Spezifikation die JSON Strukturen exakt definieren. Die gesamte Bedeutung der Daten liegt in einem JSON Dokument nämlich in dessen Struktur.
Das ist doch genau was jetzt gemacht wird, oder nicht? Ob diese genau definierten JSON Strukturen zusätzlich gültiges JSON-LD sind, ist für Validierung usw. komplett irrelevant. Ich habe das bereits vor einiger Zeit versucht in Issue #222 klar zu machen.
Um OParl anzusprechen, braucht es keine JSON-LD Bibliothek. Die braucht es nur wenn man mehr mit OParl machen will.
Diese Schuld JSON-LD zuzuschieben finde ich ungerechtfertigt. Ich habe mehrmals meine Hilfe angeboten, jedoch wurde sie kein einziges Mal in Anspruch genommen.
Ich kann dieser Argumentation leider nicht folgen. Die Spezifikation ist leider nicht aktuell oder vollständig genug um die Komplette Auswirkung abzuschätzen. Der Begriff JSON-LD wird zur Zeit 3 Mal verwendet. Recht viel öfter würde er meiner Meinung nach auch der Umsetzung meines Vorschlages nicht benötigt werden. Noch ein paar Kommentare zu @black-snow Feedback
Nein, ist auch nicht nötig. Aber wer mehr weiß kann natürlich mehr aus dem System rausholen.
Wenn die OParl Spezifikation richtig geschrieben ist und sowohl Server 1 als auch Server 2 konform sind, dann wird sowas nicht passieren.
Ja, genau das ist die Aufgabe der OParl Spezifikation. Das Profil ist im Endeffekt nur eine URL die die OParl Konventionen unmissverständlich identifiziert.
Darüber lässt sich natürlich streiten. Die schöne an JSON-LD ist jedoch die Tatsache dass sich Leute die sich nicht um Linked Data kümmern, es komplett ignorieren können. Leute die ein Interesse daran haben, bekommen jedoch alle Vorzüge die Linked Data zu bieten hat.
Warum nicht in 1.0 :-) Ich schreibe das hier in meinem Mailclient, ich werde gleich noch ein Beispiel direkt auf GitHub posten um den Unterschied zu verdeutlichen.
Genau das möchte ich vermeiden. Linked Data ist vor allem im öffentlichen Bereich bereits sehr verbreitet. Daher würde ich es sehr schade finden wenn hier mit OParl eine neue Insellösung entstehen würde die nur extrem aufwändig mit anderen Systemen integriert werden kann.
Ich glaube der Aufwand bzw. die Auswirkungen einer JSON-LD Unterstützung wurden noch immer nicht verstanden. Ich hoffe das Beispiel das ich gleich posten werde hilft das zu ändern.
Eines der Merkmale eines Standards sollte es sein stabil zu sein und sich nicht dauernd zu ändern. Wenn die Lebensdauer von Version 1.0 in Monaten gemessen wird, ist es verschwendete Zeit. Wenn es sich um Jahre handelt, glaube ich sollte klar werden warum es keinen Sinn macht auf 1.1 zu warten.
Ich befinde mich ziemlich der gleichen Position und das ist der Hauptgrund warum ich mich jetzt hier für JSON-LD einsetze. Das hat nicht wirklich was damit zu tun das ich einer der Designer von JSON-LD bin. |
|
Leider gibt es in der Spezifikation zur Zeit so gut wie keine Beispiele wie die JSON Dokumente aussehen sollen. Ich verwende daher hier eine leicht gekürtze Version des Beispiels auf Seite 45 der PDF Version der Spec. So sieht es ohne JSON-LD aus: {
"id": "https://oparl.example.org/body/0",
"type": "http://oparl.org/schema/1.0/Body",
"system": "https://oparl.example.org/",
"contactEmail": "mailto:[email protected]",
"contactName": "RIS-Betreuung",
"rgs": "053150000000",
"shortName": "Stadt Köln",
"name": {
"de": "Stadt Köln, kreisfreie Stadt",
"en": "City of Cologne"
},
"website": "http://www.beispielstadt.de/",
"license": "http://creativecommons.org/licenses/by/4.0/",
"licenseValidSince": "2014-01-01",
"organization": "https://oparl.example.org/body/0/organizations/",
"created": "2014-01-08T14:28:31.568+0100",
"modified": "2014-01-08T14:28:31.568+0100"
}Und so würde es mit JSON-LD aussehen: {
"@context": "http://oparl.de/v1",
"id": "https://oparl.example.org/body/0",
"type": "http://oparl.org/schema/1.0/Body",
"system": "https://oparl.example.org/",
"contactEmail": "mailto:[email protected]",
"contactName": "RIS-Betreuung",
"rgs": "053150000000",
"shortName": "Stadt Köln",
"name": {
"de": "Stadt Köln, kreisfreie Stadt",
"en": "City of Cologne"
},
"website": "http://www.beispielstadt.de/",
"license": "http://creativecommons.org/licenses/by/4.0/",
"licenseValidSince": "2014-01-01",
"organization": "https://oparl.example.org/body/0/organizations/",
"created": "2014-01-08T14:28:31.568+0100",
"modified": "2014-01-08T14:28:31.568+0100"
}Alles was nötig ist, ist eine einzige zusätzliche Eigenschaft, nämlich Wie bereits in #237 (comment) angeboten, bin ich gerne bereit zu helfen Beispieldokumente in pragmatisches, komplett valides JSON-LD zu verwandeln. |
|
@lanthaler Interessant sind dort insbesondere die Abschnitte 4.6 und 4.7. Einer der Vereinfachungswünsche bestand/besteht übrigens aus dem Verzicht auf Mehrsprachigkeit. Also nicht mehr: sondern nur noch Eine Diskussion dazu gab es aber vor dem "backtojson"-Schritt nicht mehr (also auch nicht zur eventuellen Verwendung von Der OParl-Entwurfs-Stand unmittelbar vor dem "backtojson" Schritt wird noch ein paar Tage hier zugänglich sein: Was ich heute in solchen Spezifikationen u.a. anders machen würde:
|
Abschnitt 4.6 ist meiner Meinung für OParl komplett irrelevant und kann weggelassen werden. 4.7 wird auch bei einer JSON-only Version gebraucht kann aber meiner Meinung nach ziemlich vereinfacht werden (auch wenn JSON-LD verwendet wird).
Falls es aktuellere Beispieldokumente gibt, kann ich gerne ein solches als Beispiel verwenden. Der Verzicht auf Mehrsprachigkeit ändert aus JSON-LD Sicht nichts.
Gibt es irgendwo eine aktuellere Spezifikation?
Gehört meiner Meinung nach nicht in die Spec.
Weglassen, irrelevant. Wird durch die JSON-LD Spec bereits vollständig spezifieziert.
+1, das ist einer der Hauptgründe für die Existenz von Contexts in JSON-LD
Das ist die Essenz einer Spezifikation, ja. @marians Wie ist die weitere Vorgehensweise? Wird über meinem Vorschlag noch diskutiert? |
|
Mehrsprachigkeit ist in keinem mir bekannten RIS zu sehen, d. h. sie ist nicht durch den Status Quo zu begründen. Sie stand auch als Ziel nicht für OParl 1.0 zur Debatte. Erst mit JSON-LD kam diese in OParl. |
|
@lanthaler: Den stets aktuellsten Stand des Specs-Entwurfs findest Du im Ordner dokument/master, also unter https://github.com/OParl/specs/tree/master/dokument/master . Die letzte PDF-Version vor dem JSON-LD-Rückbau ist hier: https://github.com/OParl/specs/blob/7545d89663e3ae576c12593be83bee002be7dc81/dokument/pdf/document.pdf |
|
@lanthaler Aktuellere Versionen gibt es gegenwärtig nicht. Damit es keine Missverständnisse zu den von mir angegebenen Abschnitten gibt (die Nummerierung in beiden PDF-Dateien ist etwas unterschiedlich): Ich meinte jeweils die Abschnitte zu "Objektlisten" und "Feeds". Generell gibt es in der Spezifikation diverse Abschnitte (auch unter 4.x) ohne normative Bedeutung. @marians Für mich stand Mehrsprachigkeit so zur Debatte wie für andere die Integration von Geoinformationen (die es abgesehen von dem RIS der Stadt Bonn bisher soweit bekannt nirgendwo gibt). Ich sehe nicht, wie Mehrsprachigkeit gegen JSON-LD spricht. In JSON-LD ist spezifiziert wie das aussieht, in simplem JSON nicht - und es gibt dort anscheinend noch nicht einmal Konventionen dazu. Ich halte dies aber für einen relativ einfach zu lösenden Punkt, der mittels JSON-LD Profil, AcceptLanguage o.ö. abgehandelt werden kann und dann sowohl eine einsprachige als auch eine mehrsprachige Ausgabe ermöglicht. |
|
Wer behauptet, dass Mehrsprachigkeit gegen JSON-LD spricht? Niemand hat sich für Mehrsprachigkeit in OParl ausgesprochen. Die Tatsache, dass man mit JSON-LD Mehrsprachigkeit umsetzen kann, ist daher als Grund, JSON-LD zu unterstützen, nicht ausschlaggebend. |
|
Ich hatte mich für Mehrsprachigkeit ausgesprochen. Als Grund für JSON-LD hatte ich Mehrsprachigkeit nie genannt. Niemand hat bisher inhaltliche Gründe dagegen vorgebracht. Das einzige was vorgebracht wurde ist, dass die Serialisierung für einen Teil der Client-Entwickler zu kompliziert sei. |
Hier gibt es eventuell ein Missverständnis. Ich hatte nicht vorgeschlagen jetzt sofort Hydra in OParl verpflichtend aufzunehmen. Ich hatte das in Zusammenhang mit den Was Linked Data betrifft, so beschränkt sich der Aufwand auf die Autoren der Spezifikation.
Damit bin ich generell einverstanden. Abgesehen von der JSON-LD-Debatte muss dann allerdings auch gesagt werden, dass OParl bereits selbst ein solches "Konkurrenzformat" ist. Popolo gab es nämlich bereits. Ich hatte dieses Spezifikations-Projekt aber leider selbst erst relativ spät entdeckt. Dennoch hatte ich in letzter Zeit einzelne in Popolo verwendete Eigenschaften oder Problemlösungen in OParl einfließen lassen. Die Zielsetzungen von Popolo sind teilweise weitreichender als die von OParl. Gleichzeitig passen große Teile des für OParl erarbeiteten Vokabulars auch gut zu Popolo. Insoweit halte ich es für sinnvoll die Arbeiten in der W3C Open Government Community Group zusammenzuführen. Dafür sprechen auch Aspekte der Transparenz und Governance. Es gab in letzter Zeit unnötige Alleingänge der deutschen Verwaltung bei Standardisierungen. Beispielhaft ist die "Datenlizenz Deutschland". Inzwischen ist aber auch in den Verwaltungskreisen Leuten klar geworden, dass so ein Vorgehen kontraproduktiv ist und sie sind nun dabei die Übernahme einer weltweit etablierten CC-Lizenz vorzubereiten. Bei Formaten für Daten von Parlamenten, Gremien etc. können solche Umwege hoffentlich vermieden werden.
Dagegen spricht eIne Aussage vom 27.6. wonach nach 1.0 erst mindestens 6 Monate verstreichen sollen bevor es eine neue Version gibt.
Die RIS-Hersteller waren und sind meines Wissens der Auffassung, dass es etwa gleich aufwändig ist JSON-LD zu unterstützen oder nicht. (Alles andere wäre auch überraschend)
Schnittstellen zwischen Komponenten eines verteilten Systems zu ändern ist um so schwieriger je mehr Komponenten / Beteiligte es gibt. Wer es heute für schwierig hält z.B. schllchte Mehrsprachigkeit in einem Client zu behandeln, der wird sich mit hoher Wahrscheinlichkeit auch gegen Änderungen der Schnittstelle sträuben die Anpassungen seines Client erfordern und ihm nicht unmittelbar helfen. Eventuell fehlen aber auch nur fünf Minuten Zeit für die notwendige Anpassung. D.h falls OParl einen gewissen Erfolg haben sollte und gleichzeitig die Unterstützung von JSON-LD erschwert ist (ob das so sein wird kann ich nicht sagen, da ich das Ergebnis noch nicht kenne) dann kann das letztendlich doch ein Weg in eine Sackgasse sein. Ich bin durchaus Anhänger von DevOps und anderen agilen Vorgehensweisen. Aber variierende Schnittstellen-Spezifikationen in verteilten Systemen sind eine viel schwierigere Angelegenheit. |
|
Nochmal die Frage:
|
|
@lanthaler Was mich betrifft, sehe ich keinen Anlass, die Entscheidung (JSON-LD in 1.0 nicht einzusetzen) umzukehren. Wir haben viele Argumente ausgetauscht. Diejenigen, welche ich als wesentlich betrachte, haben für mich weiterhin Gültigkeit. |
|
@lanthaler Interessantes Detail am Rande (da einer der "OParl Initiatoren" für Fraunhofer FOKUS tätig ist): Manfred Hauswirth wird im September die Leitung von Fraunhofer FOKUS übernehmen. Bei einer Veranstaltung in diesem Zusammenhang hat er sich bereits für "vernetzte Informationen" als Grundlage von Smart Cities ausgesprochen: |
|
Auf dieses Issue wird sogar von Wikipedia verwiesen (mit der gebotenen Neutralität): |
|
@marians schrieb:
Falls ich nichts übersehe wurden alle vorgebrachten Argumente entkräftet. Insofern ist diese Aussage nicht nachvollziehbar. Trotz mehrfacher Nachfrage sind die Fragen von @lanthaler an das OParl-Projekt nicht beantwortet:
|
|
Da zu diesem Thema wenig Resonanz vorhanden ist und wir uns anscheinend im Kreis drehen, ist eine weiterführende Diskussion um OParl 1.0 und JSON-LD nicht mehr förderlich. Angesichts des aktuellen Projektfortschritts sollte Oparl 1.0 nun zügig ferstigestellt und vorgelegt werden. Alles Weitere ist ein Thema für nachfolgende Versionen. |
|
@sterni24 Zur Frage ob die Änderungen seit dem 27. Juni insgesamt eher als Fort- oder eher als Rückschritt zu bewerten sind gibt es offensichtlich sehr unterschiedliche Bewertungen. Falls mehr öffentliche Resonanz gewünscht ist, dann kann ich gerne dazu beitragen diese zu ermöglichen. Interessehalber aber eine Frage: Zu welchem anderen OParl-Thema gibt es mehr "Resonanz"? (Wobei diese aber ohnehin kaum ein geeignetes Kriterium für Entscheidungen über Eigenschaften von Spezifikationen ist.) |
|
Der Rat der Stadt Köln hat vor wenigen Monaten offiziell zur Kenntnis genommen, dass die Stadtverwaltung das Ziel "Linked Open Data" verfolgt. Gleichzeitig wurde OParl-Konformität als Ziel angegeben. Das war jedoch zu einem Zeitpunkt, als OParl noch auf JSON-LD basierte. |
|
Schon interessant, dass man dazu im RIS der Stadt Köln nichts findet. |
|
@sterni24 Richtig, die Inhalte der PDF-Dateien werden offenbar von der Suchmaschine nicht berücksichtigt. |
|
@sterni24 Vorlagen Nummer: 1090/2014 ("Internetstadt Köln- Sachstandsbericht zum Umsetzungsprozess"). Kenntnis genommen in Sitzung des "Ausschuss Allgemeine Verwaltung und Rechtsfragen / Vergabe / Internationales" vom 19.05.2014. |
|
Eine aktuelle Meldung zum Thema: Linked Open Data erfreuen sich wachsender Beliebtheit |
|
cio.gov unterstützt JSON-LD mit Project Open Data Metadata Schema v1.1. In der Version 1.1 ist die Verwendung der "@"-properties noch optional. Aber ansonsten ist das Schema für die Bundesbehörden in den USA verpflichtend (sie riskieren sonst ihre Finanzierung):
Dies wurde vorher zunächst intensiv in project-open-data/project-open-data.github.io#309 und dann knapp in project-open-data/project-open-data.github.io#388 diskutiert. |
|
Ich schließe diesen Issue jetzt, da es in absehbarer Zeit keine Unterstützung von JSON-LD in OParl geben wird. |
Anscheinend wurde letzte Woche beschlossen die JSON-LD Unterstützung zu entfernen:
Meine Nachfrage nach den Gründen und der Diskussion die zu dieser Entscheidung führten wurden folgendermaßen beantwortet:
Da JSON-LD 100% valides JSON ist und clients dieses auch als solches direkt verwenden können, bin ich doch sehr verwundert über die Aussage das Client-Implementierung und Validierung durch den Verzicht auf JSON-LD vereinfacht wird. alls die Spezifikation die genaue JSON Struktur vorschreibt, was sie bei Verzicht auf JSON-LD zweifellos machen muss, gibt es absolut keinen Unterschied für Clients oder Validatoren.
Der Vorteil von JSON-LD besetht darin dass OParl auf einen offiziellen und bereits weit verbreiteten (Google, Microsoft, Yahoo, Yandex, BCC, DBpedia, ...) W3C Standard aufbauen würde anstatt das Rad selbst neu zu erfinden. Links z.B werden von JSON nicht unterstützt. JSON-LD erlaubt es mächtigere Clients zu erstellen, falls gewünscht. Es vereinfacht auch Datenintegration, Dokumentation und bietet Erweiterungspunkte für zukünftige Versionen von OParl.
Ich würde deshalb alle Beteiligten nochmal bitten die Entscheidung zu überdenken und stehe natürlich gerne für Fragen zur Verfügung. Meiner Meinung beruht ein Großteil der Entscheidung auf Mißverständnissen von JSON-LD und der Meinung dass, falls JSON-LD eingesetzt wird, Clients auf alle Eventualitäten vorbereitet sein müssen und nur funktionieren falls sie jede beliebige Variation von JSON-LD verstehen.
The text was updated successfully, but these errors were encountered: