Links zu Listenobjekten

[akuckartz]

Diese Aufgabe ist bereits an verschiedenen Stellen erwähnt, es gab aber noch kein eigenes Issue zu dieser Aufgabe.

Wenn Eigenschaften mit einer zu großen Menge von Werten verknüpft sind, dann sollen diese nicht im Objekt selbst, sondern in einem separaten Listenobjekt ausgegeben werden.

Dafür können wir die von Hydra erarbeitete Lösung verwenden, die inzwischen dokumentiert ist: https://www.w3.org/community/hydra/wiki/Collection_Design

[akuckartz]

In dem Beispiel kann die URL unter Verwendung der LDF basic Abfragesprache angegeben werden. Dafür ist nicht Voraussetzung, dass diese in OParl 1.0 spezifiziert wird. Man kann das hier schlicht als eine Möglichkeit des URL-Aufbaus andeuten.

[akuckartz]

Das auf der oben angegebenen Wiki-Seite angegebene Beispiel ist vollständig:

{
  "@id": "/alice",
  "hasCollection": {
    "@id": "/alice/friends",
    "@type": "Collection",
    "manages": {
      "property": "schema:knows",
      "subject": "/alice"
    }
  }
}

/alice/friends ist dabei ein separates Listenobjekt (Collection oder PagedCollection) wie in http://www.hydra-cg.com/spec/latest/core/#collections spezifiziert.

Ein einzelner oder wenige Bekannte von Alice würde man stattdessen unmittelbar mit der Beispieleigenschaft schema:knows angeben.

[marians]

Wenn man die Änderung in commit fc5a517 auf das vollständige oparl:System Beispiel überträgt, müsste dies nun so aussehen:

{
    "@context": "http://oparl.org/schema/1.0/System",
    "@type": "oparl:System",
    "@id": "beispielris:",
    "oparlVersion": "beispielris:specs/1.0/",
    "name": "Beispiel-System",
    "website": "http://www.example.org/",
    "contactEmail": "mailto:info@example.org",
    "contactName": "Allgemeiner OParl Kontakt",
    "vendor": "http://example-software.com/",
    "product": "http://example-software.com/oparl-server/",
    "hydra:hasCollection": {
        "@id": "beispielris:bodies/",
        "@type": "hydra:Collection",
        "hydra:manages": {
            "hydra:property": "body",
            "hydra:subject": "beispielris:"
        }
    },
    "newObjects": "beispielris:new_objects/",
    "updatedObjects": "beispielris:updated_objects/",
    "removedObjects": "beispielris:removed_objects"
}

Das ist ganz schön viel Syntax im Vergleich zur einfachen Ausgabe unserer URL.

Was würde man denn tun, wenn man auf mehrere Listen verweisen möchte, wie das z.B. bei einem Objekt vom Typ oparl:Body sein könnte? Den Schlüssel "hydra:hasCollection" wird man ja nur einmal verwenden können.

Edit: JSON Beispiel angepasst (URL prefixed mit "beispielris:")

[akuckartz]

@marians Sehr gute Frage. Dann erhält hydra:hasCollection mehrere Werte, also eine Liste mit Objekten mit jeweils eigener @id und unterschiedlicher hydra:property. Auf @type kann möglicherweise verzichtet werden, aber das vereinfacht auch nicht sehr viel.

[lanthaler]

Ich habe die Diskussion nur beiläufig verfolgt. Könnte jemand bitte kurz die Probleme in 1-2 Sätzen zusammenfassen um die es hier geht? hasCollection wird verwendet falls es keine passendere property mit kompatibler range gibt. foaf:knows z.b. hat eine rdfs:range von foaf:Person. Das bedeutet dass diese property nicht direkt dazu verwendet werden kann auf eine Collection zu zeigen da die Collection dann als Person interpretiert würde. Es spricht jedoch nichts (nicht viel) dagegen neue properties einzuführen deren range eine hydra:Collection ist und dann diese properties anstatt hasCollection zu verwenden.

Übrigens kann hasCollection natürlich mit mehreren Werten verwendet werden. Die einzelnen Collection Objekte werden dann einfach in ein Array gepackt.

[akuckartz]

@lanthaler Das Problem entsteht durch die Notwendigkeit der Auslagerung langer Listen mit Paging. Es wären viele Properties von der Verdopplung betroffen. Deshalb wollen wir nicht zu jeder Eigenschaft mit möglicherweise vielen Werten zusätzliche Eigenschaften einführen.

Insoweit ist die 'hasCollection'-Lösung OK. Aber sie sieht für nicht-LD Menschen tendenziell abschreckend aus.

[lanthaler]

Es geht weniger darum zusätzliche properties für properties mit mehreren Werten einzufügen sondern properties die beschreiben was am anderen Ende steht. Also zum Beispiel statt "hydra:hasCollection: [ { /documents, … }, { /people/ … } ]" (mit jeweils Collection Metadaten) zwei properties deren range eine Collection ist, also "oparl:documents: /documents" und "oparl:people: /people" (alles Pseudocode, hoffe es ist trotzdem klar).

[akuckartz]

@lanthaler Genau das meinte ich mit Verdopplung: oparl:people und oparl:person. Fände ich selbst nicht schön, würde aber die JSON-Struktur vereinfachen und fänden deshalb andere OParl-Stakeholder möglicherweise besser.

Wegen der Diskussion wieder geöffnet.

[lanthaler]

Ich meinte was anderes. Ich sprach nicht von people und person sondern von people und documents. Beide nehmen immer eine Collection als Wert, auch wenn es nur einen einzigen Eintrag in der Liste gibt. Der Vorteil dieser Vorgehensweise ist dass die Collection Metadaten nicht mehr notwending sind da die properties selbst schon spezifisch genug sind.

[lanthaler]

Das Beispiel von oben sähe dann in etwa so aus:

{
  "@context": "http://oparl.org/schema/1.0/System",
  "@type": "oparl:System",
  "@id": "/",
  "name": "Beispiel-System",
  ...
  "people": "/people/",
  "documents": "/documents/"
}

[akuckartz]

@lanthaler Jetzt verstehe ich, danke. Richtig ungünstig ist das eigentlich nur bei Eigenschaften die häufig nur einen Eintrag haben aber auch sehr viele haben können. Würde man den Typ der Elemente der Collection irgendwo angeben?

[lanthaler]

Richtig ungünstig ist das eigentlich nur bei Eigenschaften die häufig nur einen Eintrag haben aber auch sehr viele haben können.

Was sind das für Eigenschaften? Ist das wirklich ein Problem in der Praxis? Falls nicht wie in #218 vorgeschlagen der Client entscheidet ob Listen "vollständig" ausgegeben werden oder nicht (triff wahrscheinlich auch auf Collections zu) sondern der Server, dann kann dieser bis "intelligent" bis zu einer gewissen Anzahl von Elementen diese direkt zurückgeben. Ich finde es generell besser dass der Server solche Entscheidungen trifft um das System flexibel zu halten und Optimierungen server-seitig vornehmen zu können.

Würde man den Typ der Elemente der Collection irgendwo angeben?

Ist nicht zwingend nötig. Hydra selbst hat noch keinen "Shortcut" dafür aber das lässt sich falls gewünscht auch ziemlich einfach mit OWL beschreiben.

[akuckartz]

@lanthaler Wenn ich nichts übersehe, dann sind solche Eigenschaften in OParl kein wirkliches Problem. Die Idee, dass der Server entscheiden darf was er schickt wird hier bei anderen Teilnehmern wahrscheinlich nicht auf Zustimmung stoßen - weil dadurch Anforderungen an Clients steigen.

[lanthaler]

Die Idee, dass der Server entscheiden darf was er schickt wird hier bei anderen Teilnehmern wahrscheinlich nicht auf Zustimmung stoßen - weil dadurch Anforderungen an Clients steigen.

Das hängt davon ab was genau spezifiziert wird. Wenn zum Beispiel Listen ohne Details ein MUSS sind, dann können einfache Clients einfach davon ausgehen dass jedes Element separat abgerufen werden muss. Einfache Clients sind also langsamer funktionieren aber in jedem Fall. Ich denke die ganze Thematik wird aber dramatisiert. Es geht hier wirklich im Prinzip nur um zwei If-statements im Client. Pseudo Code:

getProperty(object, property) {
   if (object.property)
      return object.property

  if (object.fullyRetrieved)
      throw Error / return null

  object.retrieve()

  getProperty(object, property)
}

[akuckartz]

@lanthaler Würde man mit solchen Collection-Eigenschaften LDF sinnvoll verwenden können?

[lanthaler]

Falls für die Collection auch „Triple Pattern Fragments“ unterstützt, ja.

[akuckartz]

Ich rege an dieses Issue zu schliessen, da JSON-LD Konformität für OParl kein Thema mehr ist. Deassigned.

[marians]

Ich mache es so, wie von @akuckartz vorgeschlagen.