Widersprüchliche Anforderungen: Redundanz versus Implementierungsaufwand

[akuckartz]

Wir sollten nicht bei jeder Eigenschaft einzeln überlegen, wer gerne welche Redundanz hätte, um bestimmte Funktionen einfach umsetzen zu können, oder wen sie stört - und dann auch noch jeweils entscheiden. Wir benötigen dazu eine einfach handhabbare einheltliche Vorgehensweise.

Ich plädiere dafür, auf redundante Eigenschaften vollständig zu verzichten und die dadurch gesparte Energie lieber in die Abfragesprache (#165) zu stecken - womit sich auch dieses Problem erledigen würde.

[akuckartz]

Das ist ein Thema, welches wir nächste Woche auf der Telefon-Konferenz besprechen sollten.

[marians]

• Eine Abfragesprache im Sinne von Linked Data Fragmens in OParl 1.0 zu integrieren, lehne ich ab. Es würde die Komplexität von OParl 1.0 meines Erachtens deutlich erhöhen und wr bräuchten einen neuen Zeitplan.
• Ich halte das Ziel, dass die Daten "browseble" sind, nach wie vor für wichtig. Wenn wir Verlinkungen nur einseitig ausgeben, kann der Graph nur in eine vorgegebene Richtung gecrawlt werden. Für einen leichtgewichtigen Client mit geringen Ressourcen (z. B. ein mobiles Gerät) ist das eine Problem, denn für die Anzeige von in Verbindung stehenden Objekten müssten zunächst viele Objekte in den Cache geladen werden.

Wenn Einheitlichkeit bei allen Beziehungen das Ziel ist, dann wäre die Konsequenz, Beziehungen grundsätzlich redundant auszugeben.

[akuckartz]

Ein Problem der Ausgabe redundanter Daten - gerade für die Übertragung an mobile Geräten - ist die Vergrößerung der Menge der Daten die möglicherweise überflüssig übertragen werden. Was (nicht nur) mobile Clients benötigen sind die jeweils richtigen Daten - und möglichst wenig zusätzliche Daten.

@marians Wenn ich davon ausginge, dass verbleibender Gesamtaufwand und zu erwartende Komplexität mit LDF basic größer würden, dann würde ich das ebenfalls klar ablehnen und würde es nicht vorschlagen. Meine Einschätzung ist jedoch anders: Eine Lösung mit LDF basic ist insgesamt (also unter Berücksichtigung der aktuell offenen Issues) der einfachste Weg zur Fertigstellung von OParl 1.0.

Der Witz dabei ist, dass wir tatsächlich bereits eine Art Teilmenge von LDF basic verwenden, nur ohne Abfragesprache: nämlich in Form der Objektlisten - denn dabei sind ja genau Subjekt und Prädikat festgelegt und das Objekt nicht ! Das ist mir leider heute erst klar geworden, sonst hätte ich das bei dem Ausgabe-Format bereits berücksichtigt. Nach einer Anpassung dieses Formats ist der Restaufwand für die Spezifikation von LDF basic trivial (jedenfalls einfacher als die meisten offenen issues !).

Die URLs für die Objektlisten lassen sich dann unter Verwendung des LDF-Abfrageformats (jeweils mit Angabe von subject und predicate als URL-Parameter) angeben.

Insgesamt würde die Spezifikation mit LDF basic geschätzt etwa eine Seite länger als ohne.

[akuckartz]

Hier gibt es nichts mehr zu tun, was nicht durch andere Issues abgedeckt ist.