"compacted"-Form Anforderung an Server ist ungünstig

[akuckartz]

Dieses Issue ergibt sich aus OParl/validator#5 (comment) @Telofy

Demnach steht gegenwärtig in der Spezifikation "OParl-Server MÜSSEN sämtliche Objekte grundsätzlich in der kompakten Form ausliefern. Die Umwandlung in die anderen Formen bei Bedarf obliegt dem Client.”

Aus der Diskussion in #10 hatte sich nach meiner Interpretation nur eine SOLL-Anforderung ergeben. @marians

Die MUSS-Anforderung an Server ist problematisch. Gründe:

• ein "compacted"-Dokument kann je nach Kontext unterschiedlich aussehen. Die genaue Form steht also nicht fest und kann auch nicht ohne erhebliche Aufwände festgelegt werden.
• Kontexte wie im Beispiel wie auf dieser Seite https://github.com/OParl/specs/wiki/OParl-Vokabulare-zur-Klassifikation-von-Objekten sind als "compacted" JSON-LD anzusehen, haben aber trotzdem eine teilweise expandierte Form
• der Nutzen der Anforderung ist unklar. Denn ein Ignorieren des Kontext durch Clients bedeutet in der Regel auch, dass z.B. Präfixe nicht expandiert werden. Und wenn man die Präfixe expandiert, dann kann man normalerweise auch mit einer der existierenden JSON-LD Libraries eine vollständige Expansion vornehmen.

Ich bin deshalb dafür, die Anforderung an Server auf SOLL abzuschwächen und von OParl-Clients zu fordern, dass sie sowohl "compacted" als auch "expanded"-Formen verarbeiten können MÜSSEN. Das verhindert keineswegs andere Arten von Clients, Diese können dann allerdings keine OParl-Konformität für sich beanspruchen.

In dem Zusammenhang auch #159 (auf expandierte Beispiele könnte verzichtet werden, wenn in OParl nur eine "compacted"-Form vorgesehen würde - was aber aus oben genannten Gründen problematisch ist.)

[akuckartz]

Da kein Widerspruch kam werde ich morgen die MUSS-Anforderung an den Server wie vorgeschlagen in eine SOLL-Anforderung ändern.

[Telofy]

Wir hatten im Validator-Team besprochen, dass wir das umgekehrte Vorgehen bevorzugen würden, nämlich die Dinge, die trotz der Vorgabe, dass die compacted-Form benutzt werden soll, dennoch flexibel sind, auch vorzuschreiben. Das hat hier niemand am Ticket kommentiert. :-/

Ist dein dritter Punkt ein Beispiel dafür, was du bei Punkt 1 meinst? Was gibt es sonst noch für Flexibilitäten, die man explizit definieren müsste?

[akuckartz]

@Telofy Wie wollt ihr denn prüfen, dass der Kontext zum Rest des JSON-LD Dokuments passt?

Die Spezifikation von OParl würde komplexer, wenn derartige Einschränkungen an JSON-LD vorgenommen würden.

Deshalb noch einmal der Vorschlag: Nutzt eine JSON-LD Library, um das Dokument zu expandieren. (Kleiner Tipp: die Library kann auch verwendet werden, um das entstehende Dokument mit einem beliebigen Kontext wieder zu verdichten, dann aber garantiert die Library, dass das passt.)

[Telofy]

Wie gesagt ist das für uns ist kein wirkliches Problem, wir haben nur Sorge, dass API-Benutzer es nicht mögen werden, wenn sie eine zweite Library brauchen und sich zudem erst einiges Wissen über JSON-LD und Semantic-Web-Technologien anlesen müssen, bevor sie zuverlässig ein paar Namen auslesen können. Solch eine steile Lernkurve wird wahrscheinlich einige Benutzer abschrecken, die es von Twitter et al. gewohnt sind, dass das einfacher geht.

[akuckartz]

@Telofy Übliche Software besteht heute aus zahlreichen Libraries oder Komponenten. Ob das Auslesen "von ein paar Namen" den Hauptteil typischer OParl-Anwendungen repräsentieren wird wage ich zu bezweifeln - unabhängig davon wie OParl aussieht. Und selbst wenn, dann werden das bei Implementierung einer Abfragesprache wie #165 und Verwendung weiterer Libraries simple Einzeiler sein.

Das eigentliche Datenmodell von Twitter ist nach meiner Einschätzung einfacher als das von OParl. Dennoch ist die Twitter-API aufgrund der (bisherigen) Nichtverwendung von JSON-LD insgesamt viel komplexer als erforderlich. Was ist besser: Sich mit den unzähligen Spezialitäten der Twitter-API zu befassen oder etwas lernen, was auf Server-Seite nicht nur von einem einzigen Anbieter und Service verwendet wird? (Nebenbei: Das W3C wird voraussichtlich in den nächsten Wochen mit der Entwicklung von Social Media Standards auf JSON-LD Grundlage beginnen.)

Zudem gibt es nur einen einzigen Service und Anbieter mit Twitter API. OParl Services wird es (hoffentlich) sehr viele mit unterschiedlichen Ausprägungen geben.

[Telofy]

Sass ist mit SCSS den Weg gegangen, dass sie das beste der beiden Welten vereint haben, eine Sprache, die eine Übermenge von CSS ist, so dass man einfach CSS schreiben kann, wenn man meint die SCSS-Features nicht zu benötigen. Ich benutze zwar dennoch Sass, aber das liegt daran, dass ich die CSS-Syntax nicht mag, ein Problem, das ich mit JSON nicht hab.

In unserem Fall sind Lesende und Schreibende der Daten vertauscht, aber die Überlegung ist die selbe. Wenn du aber meinst, dass die JSON-LD-Features, die eine JSON-LD-Library unabdingbar machen werden, so integral sind, dass es kaum eine Client-Anwendung geben wird, die ohne sie auskommt, dann ist es sicherlich unnötig auf eine solche Kompatibilität zu achten. Bisher habe ich aber den Eindruck, dass es recht einfach möglich ist OParl ohne JSON-LD-Library zu benutzen, wenn die Prefixe aufgelöst und das JSON sowie Listen in einem einheitlichen Format sind.

Letztlich ist es wahrscheinlich auch eine Frage, ob wir es den Server-Entwicklern einfach machen wollen, indem wir die Spezifikation minimalistisch halten, oder ob wir es den Client-Entwicklern einfach machen wollen, indem wir das Spektrum möglicher valider Antworten vom Server, die sie verarbeiten können müssen, so klein wie möglich halten, bzw. welche der beiden Entscheidungen die geringeren Nachteile für die jeweils benachteiligte Gruppe mit sich bringen wird.

Die meisten Vor- und Nachteile vieler Designentscheidungen werden sich ohnehin erst in der Praxis zeigen, und ich sehe das ganze eher von der Client-Seite, daher möchte ich mich da auch gar nicht querstellen, wenn ihr meint, dass die Nachteile für Clients vergleichsweise gering sind.

[akuckartz]

@Telofy Neben Client- und Server-Entwicklern gibt es auch noch die Entwickler der Spezifikation. Die Spezifikation von Einschränkungen von JSON-LD ist Aufwand, insbesondere weil dabei auch Nebenwirkungen untersucht werden müssen. Die gegenwärtig im Text enthaltene Einschränkung ist jedenfalls bereits deshalb wenig hilfreich, weil sie nicht präzise bzw. weitreichend genug ist, um das damit beabsichtigte Ziel zu erreichen.

[Telofy]

Im Atom-Standard heißt es »A lot of effort went into making this effortless«, was sicherlich der Grund ist, weshalb ich Atom so toll finde (wenn man davon absieht, dass er auf XML basiert). Aber wenn außerhalb unseres Grüppchens niemandem etwas an dieser Baustelle liegt, dann möchte ich hier gar nicht weiter rumblockieren. ^^

[marians]

Wie Andreas sagt, ist es leider von JDON-LD nicht genau festgelegt, wie "compacted" aussieht. Deshalb müssten wir es sehr aufwändig beschreiben. (Habe auch länger gebraucht, um das zu kapieren).

Ich bin mit der Änderung zu "SOLL" in 92d5557 einverstanden.

[akuckartz]

Unterstützung von #222 kann eventuell eine Vereinfachung bringen.

[akuckartz]

Für diejenigen die sich dafür interessieren: Ich schaue mir dieses alte (geschlossene) Issue aus verschiedenen Gründen gegenwärtig genauer an. Dazu gehört auch, dass für Activity Streams 2.0 eine "compacted" Serialisierung vorgesehen ist.