Child pages
  • API development
Skip to end of metadata
Go to start of metadata

Linked Data vs. Search-API

Momentan sind die Linked-Data-URIs (z.B. http://lobid.org/resource/HT016479875) Aliase für id-Suchanfragen (z.B. http://lobid.org/resource?id=HT016479875). Daraus ergibt sich auch das Format bzw. der Umfang der zurückgelieferten Daten; beispielsweise liefert eine Anfrage zusätzliche Tripel (Name, Alter) über eine assoziierte Ressource wie einen Autoren.

Da dies für die OER-Worldmap Suche ähnlich sein wird, stellt sich bezüglich der OER-Worldmap Schreib-API nun die Frage, welche Daten mit welcher (HTTP-)Operation an welche Stelle gesendet werden sollen. Um obiges Beispiel aufzugreifen, sollte bei einer Aktualisierung einer Ressource üblicherweise keine Daten über den Autoren mitgeschickt werden:

GET http://lobid.org/resource?id=HT016479875

<http://lobid.org/resource/HT016479875> <http://purl.org/dc/terms/title> "Sprachen der Kunst" .
<http://lobid.org/resource/HT016479875> <http://purl.org/dc/elements/1.1/creator> <http://d-nb.info/gnd/118696432> .
<http://d-nb.info/gnd/118696432> <http://d-nb.info/standards/elementset/gnd#preferredNameForThePerson> "Goodman, Nelson" .
<http://d-nb.info/gnd/118696432> <http://d-nb.info/standards/elementset/gnd#dateOfDeath> "1998" .
<http://d-nb.info/gnd/118696432> <http://d-nb.info/standards/elementset/gnd#dateOfBirth> "1906" .
PUT http://lobid.org/resource?id=HT016479875

<http://lobid.org/resource/HT016479875> <http://purl.org/dc/terms/title> "Sprachen der Kunst : Entwurf einer Symboltheorie" .
<http://lobid.org/resource/HT016479875> <http://purl.org/dc/elements/1.1/creator> <http://d-nb.info/gnd/118696432> .

An dieser Stelle wird klar, dass es sauber wäre, die Daten je nach gewünschter Funktionalität unterschiedlich bereitzustellen. Es gäbe also zwei unterschiedliche Sichten auf die Daten:

HTTP-PUT wäre demnach idealerweise eine Operation auf die Linked-Data-URI der Ressource:

GET http://lobid.org/resource/HT016479875/about

<http://lobid.org/resource/HT016479875> <http://purl.org/dc/terms/title> "Sprachen der Kunst" .
<http://lobid.org/resource/HT016479875> <http://purl.org/dc/elements/1.1/creator> <http://d-nb.info/gnd/118696432> .
PUT http://lobid.org/resource/HT016479875/about

<http://lobid.org/resource/HT016479875> <http://purl.org/dc/terms/title> "Sprachen der Kunst : Entwurf einer Symboltheorie" .
<http://lobid.org/resource/HT016479875> <http://purl.org/dc/elements/1.1/creator> <http://d-nb.info/gnd/118696432> .

Diese verschiedenen Sichten könnten folgendermaßen aus dem lobid-Technologie-Stack ausgeliefert werden. Denkbar ist dabei, für Sink und Index die selbe Technologie (Elasticsearch) einzusetzen.

Bei einer solchen klaren Trennung von Linked Data und Search-API kann bei letzterer noch stärker der Fokus auf Web-Entwickler gelegt werden. z.B. könnten Suchergebnisse nur noch als JSON-LD ausgeliefert werden, und zwar in der hier von Manu Sporny vorgeschlagenen Variante ohne @graph-Overhead.

Drupal vs. Read-Write-API

Für den Prototypen der OER-Worldmap sind zahlreiche Komponenten, u.a. die für die Datenanreicherung, nicht zwingend notwendig:

  • No labels