Eigenschaft "member" in oparl:Person ungünstig!

[sterni24]

Das Ausgeben einer @list in der Eigenschaft "member", wie auch die in #167 vorgeschlagene @list von "meeting" wirken sich ungünstig auf die Performance aus. Die Personen werden z. B. für die Darstellung eines Sitzungskalenders nicht benötigt, wie auch umgekehrt eine Mitgliederliste mit den Terminen zunächst nichts zu tun hat. Im Bedarfsfall sollten die Daten nachgelesen werden.

Im Kapitel 4.7.3 wird ein Lösungsansatz beschrieben. Bei einer Liste mit nur einem Eintrag stellt sich hier die Frage, wie erkennt der Client, ob es sich um ein Objekt oder eine URL handelt?

Ja, wir drehen uns hier im Kreis, siehe #174.

Aber auch bei einer angedachten „memberlist“ mit URL bekomme ich immer die komplette Objektliste, die ich dann wiederum sequentiell auslesen muss.

[akuckartz]

@sterni24 Heute haben @marians und ich diese Problematiken und Lösungsansätze besprochen. Anschliessend habe ich mir noch einmal die aktuellen Überlegungen des Hydra-Projektes angesehen - das gute ist ja, dass wir nicht die einzigen sind, die solche Probleme lösen müssen: zu den Experten, die Lösungen erarbeiten gehören u.a. zwei der Hauptautoren der JSON-LD-Spezifikation. (Erstaunlich mag sein, dass es noch keine fertigen Lösungen gibt. Warum das so ist kann ich bei Gelegenheit erklären.)

Meine Einschätzung ist, dass wir zu für alle Beteiligten akzeptablen Lösungen kommen werden (und das sogar bei Einhaltung des geplanten Termins für die Freigabe von Version 1.0 ;-)

[sterni24]

@akuckartz @marians Super, dann können wir uns schon mal mental vorbereiten und einen Server "oparl.ratsinfomanagement.net" aufsetzen, und Sie, Herr Kuckartz, entwickeln den ersten Client. ;-)) Über ein Prototyping bekommen wir die bugs am besten raus.

Ich danke für die bisherige Zusammenarbeit, vor allem, weil ich Ihnen manchmal ganz schön "auf den Senkel gegangen" bin. Ein schönes Wochenende und noch gutes Gelingen!

[akuckartz]

Ich bin aufgrund der Aussicht auf eine kurz nach OParl 1.0 erfolgende Ergänzung um Linked Data Fragments als Abfragesprache (#165) nun ebenfalls der Auffassung, dass member in oparl:Person nicht benötigt wird. Entsprechendes gilt für weitere inverse und damit redundante Eigenschaften.

[akuckartz]

Ich wollte die Eigenschaft gerade entfernen bzw. auf DEPRECATED setzen. Aber sie ist bereits entfernt.

[marians]

oparl:Person hatte die Eigenschaft member auch gar nicht. Jedenfalls nicht in unserer Review-Version. Habe gerade noch mal im PDF nachgesehen. :)

[sterni24]

@marians es ging hier um "hasMemberShip", bitte entfernen, siehe auch #175