JSON-LD Unterstützung #237

Closed
lanthaler opened this Issue Jul 8, 2014 · 35 comments

Projects

None yet

6 participants

@lanthaler

Anscheinend wurde letzte Woche beschlossen die JSON-LD Unterstützung zu entfernen:

… eine Entscheidung vom Freitag, wonach OParl nicht auf JSON-LD basieren wird.
@akuckartz in #226 (comment)

Meine Nachfrage nach den Gründen und der Diskussion die zu dieser Entscheidung führten wurden folgendermaßen beantwortet:

Ja, die Entscheidung ist gefallen und Grund ist im Allgemeinen der Wunsch nach simpler Client-Implementierung und Validierung. Das hat nicht alleine mit JSON-LD zu tun, aber auch.
@marians in #226 (comment)

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.

@akuckartz
Contributor

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

  • die Implementierung hochwertiger moderner Clients erschwert und nicht etwa vereinfacht.
  • die Implementierung von Clients durch Hobbyisten wird keineswegs vereinfacht. Siehe dazu insbesondere #222

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 marians added this to the Zukünftige Version milestone Jul 8, 2014
@sterni24
Contributor
sterni24 commented Jul 8, 2014

@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.

@lanthaler

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.

Ja, das war sicherlich kontraproduktiv und hat den Eindruck von massiv erhöhter Komplexität erweckt.

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'.

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.

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.

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.
2.) Es wird allen Objekttypen und dazugehöriger Eigenschaften eine URL zugewiesen (sollte wirklich trivial sein und kann ich gern erledigen)
3.) Wir erstellen einen JSON-LD Context der zum Beispiel beim W3C gehostet werden könnte (auch da helfe ich gerne mit)
4.) Die Spezifikation wird um ein Statement erweitert dass alle Resourcen als application/ld+json mit einem Verweis zum Context ausgeliefert werden (das ist wirklich die einzige zusätzliche Anforderung zur Unterstützung von JSON-LD in Version 1.0)

Wie klingt das?

@sterni24
Contributor
sterni24 commented Jul 8, 2014

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.

@marians
Contributor
marians commented Jul 8, 2014

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ührt

Eines 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

  1. die damit perspektivisch mögliche "Selbstbeschreibungsfähigkeit"
  2. die Nutzbarkeit in der Linked-Data-Welt
  3. die einfache Umsetzbarkeit von herstellerspezifischen Eigenschaften
  4. die unwesentlichen Änderungen gegenüber reinem JSON

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:

  • Was ist Linked Data und wen kümmert das?
  • Was ist RDF, was sind Tripel, was ist OWL?
  • Was sind Namespaces und Namespace-URLs?
  • Was ist @context und wofür brauche ich das?
  • Kann ich mehr als einen @context haben?
  • Was sind die expanded, compacted, flattened, framed Form?
  • Was sind @list und @set, warum sind Arrays grundsätzlich ungeordnet?
  • Wie kann ich Listen von Objekten in JSON-LD darstellen?
  • Was bedeutet die @graph Schreibweise?

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önnte

Mit 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:

  • Eine große Menge an Verweisen auf externe Quellen in unserer Schema-Beschreibung, die die Verständlichkeit und Lesbarkeit des Dokuments verschlechtern.
  • Der Prozess war langwierig und offensichtlich Teilnehmern mit Affinität zur Linked-Data-Welt vorbehalten.
  • Die Begrifflichkeiten passen nicht unbedingt zur Domäne.

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 Validierung

In 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

"key": "value"

oder so:

"key": {"@value": "value"}

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 fehlen

Ein 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.

Zusammengefasst

Fasst 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.

@akuckartz
Contributor

@sterni24 Ich unterstütze den Vorschlag von @lanthaler .

Die heute in den master-Branch übernommenen Änderungen führen eben nicht zu einem "kleinsten gemeinsamen Nenner" zurück sondern - nach nicht allzu ausgiebiger Sichtung - zu einem nicht unerheblichen Teil dazu, dass

  • die Verwendung für einen wesentlichen Teil der potentiellen Datennutzer erheblich und unnötig erschwert wird
  • bereits erledigte Issues (insbesondere zu Feinheiten die von @sterni24 aufgeworfen wurden) wieder geöffnet werden müssen (sofern diese Probleme jemandem auffallen)
  • neue Probleme durch Scheinvereinfachungen an Stellen geschaffen werden, die bisher niemand für problematisch hielt (zumindest ist mir jeweils kein Issue dazu bekannt)

Ich versuche grundsätzlich meine Standpunkte zu belegen und gebe deshalb Quellen an. Dass das hier nicht funktioniert hat finde ich bedauerlich.

Die externe Mitarbeit in diesem Forum ging schon fast gegen 0, ach ja, es muss heißen 'null'.

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.

@marians
Contributor
marians commented Jul 8, 2014

@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.

@akuckartz
Contributor

@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.

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.

Ich weiss nicht wer mit diesem "Wir" genau gemeint ist. Ich jedenfalls gehöre zu denen, die mit generischen Clients zugreifen wollen.

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.

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.

Ich glaube, dass es auch an JSON-LD liegt, dass sich der Kreis der Mitwirkenden hier stark verkleinert hat.

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.

In ähnlicher Art und Weise wurde es plötzlich sehr kompliziert, einfache Dinge wie die Paginierung von Listen zu realisieren. ... Alleine diese Fragestellung hat sich über Wochen gezogen.

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.

  1. Die Freiheitsgrade, die ein Server bei der Ausgabe von JSON-LD hat, erschweren die Validierung

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.

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.

Ich verweise noch einmal auf #222

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.

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.

Ein 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.

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.

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.

Dazu ist schwer etwas zu sagen, solange das genaue Aussehen dieser JSON-Objekte nicht bekannt ist.

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.

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.

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.

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.

@marians
Contributor
marians commented Jul 8, 2014

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.

@akuckartz
Contributor

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.

@black-snow
Contributor

"OParl ist eine Initiative zur Standardisierung des offenen Zugriffs auf parlamentarische Informationssysteme in Deutschland."
Man muss nun also nicht mehr 20 Server erforschen und herausfinden wie man die RIS-Daten herausbekommt sondern man liest eine Spezifikation und kann mit einer Software die Daten aller unterstützenden Systeme lesen. Eventuell werden sogar Code-Snippets vorbereitet und man muss effektiv nur noch die Daten verwenden. Das ist in meinen Augen OParl 1.0. Und wenn ich's mit dem Lesen von Spezifikationen nicht so habe, dann verstehe ich einfach die Strukturen wie ich sie bekomme, die sind dann bei allen Teilnehmern gleich.

@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.
Für mich war es viel Aufwand die Konzepte zu verstehen. Möchte ich als gemeiner Nutzer einer API Einblick in zig verschiedene Spezifikationen nehmen müssen? Dann denke ich mir "aha", frage Server 1 an und sehe: "Ja, so sieht das aus". Dann frage ich Server 2 an, erwarte ähnliches und muss mich fragen, ob ich mich in der URL vertippt habe weil plötzlich alles anders scheint. (Dazu muss ich sicherlich sagen, dass ich mich mit #222 noch nicht auseinandergesetzt habe.) Dennoch, ich möchte doch lieber in eine Spezifikation schauen, sehen wie die Dinge heißen die ich brauche und dann setze ich das um.
Die Werkzeuge sind m. E. einfach noch nicht gegeben oder verbreitet um mit den Linked-Data-Dingen umzugehen wie wir es heute vielleicht mit HTTP 1.1 machen. Das ist aktuell noch ein Feld auf das man sich spezialisieren muss um es zu begreifen.

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!
Darum muss ich auch sagen, dass ich es nicht für gut befinde ein "Konkurrenzformat" zu schaffen. Das hilft m. E. allen Beteiligten weniger als versuchte man beide (alle) Seiten in einem Produkt anzugehen. Im schlimmsten Fall schadet es sogar mehr. Es spricht m. E. pauschal nichts dagegen diese Dinge als nächstes anzugehen. Nur für Version 1.0 ist es schlicht zu viel des Guten.

@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?
Ich habe mit dem Projekt letztendlich wenig zu tun, aber ich finde es sehr schade, dass hier jetzt die Gefahr besteht Kapazitäten zu verschwenden.

Nochmal kurz zur 1.0:
Es wäre doch sehr schade wenn man eine super Spezifikation hat die tolle Features erlaubt und mit generischen Clients umgehen kann und letztendlich möchte sie keiner weil keiner sie versteht. Das ist dann so als machte ich PhotoShop auf um schnell ein Diagramm anzufertigen, sähe die 4000 Knöpfe und Funktionen und verwende letztlich MS Paint weil es einfach nur die drei Buttons hat die ich benötige.
Oder wenn die RIS-Hersteller sagen ihnen sei das zu kompliziert, sie wollen einen neuen Standard (oder mehr Geld vom Land).
Für mich scheint nichts gegen einen iterativen Prozess für OParl zu sprechen.

@lanthaler

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.

  1. JSON-LD wurde nicht unter der richtigen Prämisse eingeführt

Eines 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.

[...]

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.

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.

Die Zusammenführung solcher Vokabeln, die die grenzübergreifende
Auswertung dieser Daten erlauben würde, sehe ich als
arbeitsintensives Thema für die Zukunft.

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.

  1. 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.

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.

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:

• Was ist Linked Data und wen kümmert das?
• Was ist RDF, was sind Tripel, was ist OWL?
• Was sind Namespaces und Namespace-URLs?
• Was sind die expanded, compacted, flattened, framed Form?
• Was sind @list und @set, warum sind Arrays grundsätzlich ungeordnet?
• Wie kann ich Listen von Objekten in JSON-LD darstellen?
• Was bedeutet die @graph Schreibweise?
• Kann ich mehr als einen @context haben?

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.

• Was ist @context und wofür brauche ich das?

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.

  1. Linked Data macht einiges kompizierter, was einfach sein könnte

Mit 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.

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.

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.

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.

  1. Die Freiheitsgrade, die ein Server bei der Ausgabe von JSON-LD hat,
    erschweren die Validierung

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 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.

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.

  1. JSON-LD-Bibliotheken sind noch frisch oder fehlen

Um OParl anzusprechen, braucht es keine JSON-LD Bibliothek. Die braucht es nur wenn man mehr mit OParl machen will.

Zusammengefasst

Fasst 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.

Diese Schuld JSON-LD zuzuschieben finde ich ungerechtfertigt. Ich habe mehrmals meine Hilfe angeboten, jedoch wurde sie kein einziges Mal in Anspruch genommen.

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.

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

Für mich war es viel Aufwand die Konzepte zu verstehen. Möchte ich als
gemeiner Nutzer einer API Einblick in zig verschiedene Spezifikationen
nehmen müssen?

Nein, ist auch nicht nötig. Aber wer mehr weiß kann natürlich mehr aus dem System rausholen.

Dann denke ich mir "aha", frage Server 1 an und sehe:
"Ja, so sieht das aus". Dann frage ich Server 2 an, erwarte ähnliches
und muss mich fragen, ob ich mich in der URL vertippt habe weil
plötzlich alles anders scheint.

Wenn die OParl Spezifikation richtig geschrieben ist und sowohl Server 1 als auch Server 2 konform sind, dann wird sowas nicht passieren.

(Dazu muss ich sicherlich sagen, dass
ich mich mit #222 noch nicht auseinandergesetzt habe.) Dennoch, ich
möchte doch lieber in eine Spezifikation schauen, sehen wie die Dinge
heißen die ich brauche und dann setze ich das um.

Ja, genau das ist die Aufgabe der OParl Spezifikation. Das Profil ist im Endeffekt nur eine URL die die OParl Konventionen unmissverständlich identifiziert.

Die Werkzeuge sind m. E. einfach noch nicht gegeben oder verbreitet um
mit den Linked-Data-Dingen umzugehen wie wir es heute vielleicht mit
HTTP 1.1 machen. Das ist aktuell noch ein Feld auf das man sich
spezialisieren muss um es zu begreifen.

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.

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!

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.

Darum muss ich auch sagen, dass ich es nicht für gut befinde ein
"Konkurrenzformat" zu schaffen. Das hilft m. E. allen Beteiligten
weniger als versuchte man beide (alle) Seiten in einem Produkt
anzugehen. Im schlimmsten Fall schadet es sogar mehr.

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.

Es spricht m. E. pauschal nichts dagegen diese Dinge als nächstes
anzugehen. Nur für Version 1.0 ist es schlicht zu viel des Guten.

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.

@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?

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 habe mit dem Projekt letztendlich wenig zu tun, aber ich finde es
sehr schade, dass hier jetzt die Gefahr besteht Kapazitäten zu
verschwenden.

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.

@lanthaler

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:ris@beispielstadt.de",
  "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:ris@beispielstadt.de",
  "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 "@context": "http://oparl.de/v1". Ich hoffe das illustriert das der Aufwand wirklich minimal ist und das weder für Client- noch Serverentwickler die Arbeit erschwert wird.

Wie bereits in #237 (comment) angeboten, bin ich gerne bereit zu helfen Beispieldokumente in pragmatisches, komplett valides JSON-LD zu verwandeln.

@akuckartz
Contributor

@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:

  "name": {
    "de": "Stadt Köln, kreisfreie Stadt",
    "en": "City of Cologne"
  },

sondern nur noch

  "name": "Stadt Köln, kreisfreie Stadt",

Eine Diskussion dazu gab es aber vor dem "backtojson"-Schritt nicht mehr (also auch nicht zur eventuellen Verwendung von AcceptLanguage). Diese Komplexität hat aber offensichtlich wenig mit JSON-LD zu tun.

Der OParl-Entwurfs-Stand unmittelbar vor dem "backtojson" Schritt wird noch ein paar Tage hier zugänglich sein:
https://github.com/OpenGovLD/specs/blob/master/dokument/pdf/document.pdf?raw=true
Dort sind im Vergleich zu dem aktuellen OParl-Stand insbesondere 4.7. und 4.8 relevant.

Was ich heute in solchen Spezifikationen u.a. anders machen würde:

  • Kontexte an einer Stelle in einem Anhang konzentrieren
  • expandierte Versionen ebenfalls in einen Anhang konzentrieren (oder weglassen)
  • Entkopplung von Eigenschaftsnamen durch Kontexte. So können Kontexte z.B. membership auf hasMembership mappen, so dass mit dem historisch bedingten "has" nur noch Linked Data Anwender in Berühring bekommen
  • frühzeitig klären was für welche Art von Software normativ ist und was nicht
@lanthaler

@lanthaler Interessant sind dort insbesondere die Abschnitte 4.6
und 4.7.

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).

Einer der Vereinfachungswünsche bestand/besteht übrigens aus dem
Verzicht auf Mehrsprachigkeit...

Falls es aktuellere Beispieldokumente gibt, kann ich gerne ein solches als Beispiel verwenden. Der Verzicht auf Mehrsprachigkeit ändert aus JSON-LD Sicht nichts.

Der OParl-Entwurfs-Stand unmittelbar vor dem "backtojson" Schritt wird
noch ein paar Tage hier zugänglich sein.. Dort sind im Vergleich zu
dem aktuellen OParl-Stand

Gibt es irgendwo eine aktuellere Spezifikation?

Was ich heute in solchen Spezifikationen u.a. anders machen würde:
• Kontexte an einer Stelle in einem Anhang konzentrieren

Gehört meiner Meinung nach nicht in die Spec.

• expandierte Versionen ebenfalls in einen Anhang konzentrieren (oder weglassen)

Weglassen, irrelevant. Wird durch die JSON-LD Spec bereits vollständig spezifieziert.

• Entkopplung von Eigenschaftsnamen durch Kontexte. So können Kontexte
z.B. membership auf hasMembership mappen, so dass mit dem historisch
bedingten "has" nur noch Linked Data Anwender in Berühring bekommen

+1, das ist einer der Hauptgründe für die Existenz von Contexts in JSON-LD

• frühzeitig klären was für welche Art von Software normativ ist und
was nicht

Das ist die Essenz einer Spezifikation, ja.

@marians Wie ist die weitere Vorgehensweise? Wird über meinem Vorschlag noch diskutiert?

@marians
Contributor
marians commented Jul 10, 2014

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.

@marians
Contributor
marians commented Jul 10, 2014

@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

@akuckartz
Contributor

@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.

@marians
Contributor
marians commented Jul 10, 2014

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.

@akuckartz
Contributor

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.

@akuckartz
Contributor

@black-snow

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.

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 []-Eigenschaften als Möglichkeit angegeben, wie Server maschinenlesbar Aussagen über die Unterstützung insbesondere optionaler Eigenschaften machen können.

Was Linked Data betrifft, so beschränkt sich der Aufwand auf die Autoren der Spezifikation.

Darum muss ich auch sagen, dass ich es nicht für gut befinde ein "Konkurrenzformat" zu schaffen.

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.

Was spricht dagegen in naher Zukunft bereits eine Version 1.1 zu veröffentlichen, welche sich um Linked-Data bemüht?

Dagegen spricht eIne Aussage vom 27.6. wonach nach 1.0 erst mindestens 6 Monate verstreichen sollen bevor es eine neue Version gibt.

Oder wenn die RIS-Hersteller sagen ihnen sei das zu kompliziert, sie wollen einen neuen Standard

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)

Für mich scheint nichts gegen einen iterativen Prozess für OParl zu sprechen.

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.

@lanthaler

Nochmal die Frage:

@marians Wie ist die weitere Vorgehensweise? Wird über meinem Vorschlag noch diskutiert?

@marians
Contributor
marians commented Jul 17, 2014

@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.

@akuckartz
Contributor

@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:
http://www.behoerden-spiegel.de/icc/Internet/nav/f68/broker.jsp?uCon=fb80b77e-7917-41bf-463c-547b988f2ee2

@akuckartz
Contributor

Auf dieses Issue wird sogar von Wikipedia verwiesen (mit der gebotenen Neutralität):
http://de.wikipedia.org/wiki/JSON-LD#Anwendungen_und_Anwender

@akuckartz
Contributor

@marians schrieb:

Wir haben viele Argumente ausgetauscht. Diejenigen, welche ich als wesentlich betrachte, haben für mich weiterhin Gültigkeit.

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:

Wie ist die weitere Vorgehensweise? Wird über meinem Vorschlag noch diskutiert?

@sterni24
Contributor

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.

@akuckartz
Contributor

@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.)

@akuckartz
Contributor

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.

@sterni24
Contributor

Schon interessant, dass man dazu im RIS der Stadt Köln nichts findet.

@akuckartz
Contributor

@sterni24 Richtig, die Inhalte der PDF-Dateien werden offenbar von der Suchmaschine nicht berücksichtigt.

@akuckartz
Contributor

@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.

@akuckartz
Contributor

Eine aktuelle Meldung zum Thema:

Linked Open Data erfreuen sich wachsender Beliebtheit
25.09.2014
http://www.heise.de/ix/meldung/Linked-Open-Data-erfreuen-sich-wachsender-Beliebtheit-2403748.html

@akuckartz
Contributor

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):

Federal CFO-Act agencies are expected to complete the transition to the v1.1 schema by February 1st, 2015.

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.

@konstin
Member
konstin commented Jun 21, 2016

Ich schließe diesen Issue jetzt, da es in absehbarer Zeit keine Unterstützung von JSON-LD in OParl geben wird.

@konstin konstin closed this Jun 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment