API development

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:

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:

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:

Geben Sie Stichwörter ein, die dieser Seite hinzugefügt werden sollen:
Please wait 
Sie suchen ein Stichwort? Beginnen Sie einfach zu schreiben.