search

dataramblers / datenhack-frontend

Frontend for Datenhack project (incubating)
0 stars 1 forks source link

Minimale API #3

Closed tobinski closed 6 years ago

tobinski commented 6 years ago

Damit wir das Frontend real können, sollten wir eine minimale API implementieren, die alle verfügbaren Bilder zurück gibt. Dadurch können wir mit realen Daten arbeiten und uns durch den Bestand klicken. Diese API können wir dann anschliessend ausbauen oder auch wieder einstampfen, je nachdem was wir für entscheide bezüglich Metadaten Repräsentation fällen.

notand commented 6 years ago

Mein Ansatz wäre dieser: Am Ende holt man die Info über die (verfügbaren) Bilder(dateinamen) nicht vom Bilderserver, sondern aus der Datenhaltung. Unsere Datenhaltung muss für jedes Bild auch die Info enthalten, mit welchem Pfadende (Unterordner und Dateiname) das Bild auf dem Bilderserver zu finden ist. Wenn ich das richtig sehe, entspricht der Dateiname der Signatur in den csv-Metadaten. Entweder holt die App sie direkt aus diesen csvs, oder aus den Daten, die aus ElasticSearch kommen (und die u.a. alle csv-Daten enthalten, weil diese für die Anreicherung vorher dort hinein geflossen sind?) - in JSON? Für diesen Ansatz könnten wir als ersten Schritt aus den Signaturen eine Liste in JSON generieren und den Zugriff von Sebastians App auf diese Liste implementieren. Oder kann man sich JSON-Files sparen und greift holt die Daten über eine API aus ElasticSearch? (Ich habe keine sehr konkrete Vorstellung davon, was ElasticSearch ganz genau ist und tut).

Falls wir mit einem IIIF-Manifest arbeiten, würde dieses ebenfalls aus dieser Datenhaltung generiert - das Manifest wäre nur die View/Darstellung, nicht die Datenhaltung (Model) selbst.

notand commented 6 years ago

Zu den Signaturen hatte @martrei per Email geschrieben:

Dominique (@Dominique-B) sind bei der Analyse der Metadaten aber auch gleich eine ganze Reihe an Problemen aufgefallen:

·Die Daten haben momentan keine eindeutigen Identifier, da die Signaturen nicht eineindeutig sind (z.B. Sozarch_F_5025-Fx-03-1). Ich bin mir daher auch nicht ganz sicher, ob es nicht Probleme bei der Bilderzuordnung geben wird (möglicherweise haben diese Signaturen aber auch gar keine Bilder…)

·Titel (F_5025-Fb-280), Zeitwerte (F_5025-Fd-031) und teilweise auch Orte sind nach einer fixen Zeichenlänge abgeschnitten.

Gerade hinsichtlich der viel reicheren Metadaten, die eigentlich beim Sozialarchiv vorhanden sind, ist die Metadatenqualität für einen OpenData Hackathon doch etwas unzufriedenstellend...

tobinski commented 6 years ago

@notand Der Bildserver stellt keine Infos über alle vorhandenen Bilder bereit. Dies müssen wir tatsächlich in einem anderen Service implementieren. Wenn wir die Usecases anschauen, dann brauchen wir wohl eine Form von API, damit wir folgende Funktionalitäten bereitstellen können.

  1. Eine Liste alle Bilder (mit Pagination)
  2. Einen Mechanismus zum Filtern und Sortieren

Technisch können wir dies beiden UseCases direkt mit der Elasticsearch-API machen. Für einfache Tests reicht auch eine JSON-Datei. Wenn wir eine Manifest pro Bild aus den Daten generieren wollen, dann brauchen wir jedoch eine etwas flexiblere API und können nicht direkt die Elasticsearch-API abrufen. Wir müssten wohl auf API-Plattform (oder vergleichbares) zurückgreifen und diese entsprechend generieren. Wenn wir dies tun, dann stellt sich die Frage, ob die IIIF Spezifikationen wirklich stimmig sind für unsere Daten, oder wir besser mit schema.org ImageObject nutzen. Dieses wäre über den schema generator einfach in die API-Plattform zu laden. Die Frage der API hängt sehr stark mit https://github.com/dataramblers/datenhack-sozarchiv/issues/6 zusammen

guenterh commented 6 years ago

@tobinski @sschuepbach @notand @witzigs Hallo zusammen, ich konnte in den letzten zwei, drei Wochen, Eure Diskussionen leider immer nur aus dem off verfolgen, sorry, kam einfach nicht zu mehr. Treffe mich diese Woche mit @sschuepbach , er kann mir ja kurz erklären, was Ihr alles machen wollt. Wenn Ihr daran denkt, die API-Platform zu verwenden, fände ich das natürlich schön. Das würde mir vielleicht auch besser die Möglichkeit geben, dass was wir schon haben, und in das ich sowieso Arbeit stecken muss, bei Euch - mit @tobinski ? - einzubringen?

Dominique-B commented 6 years ago

Die Probleme mit den Metadaten sind behoben. https://github.com/Sozialarchiv stellt demnächst einen kompletten JSON-Abzug der beim SozArch vorhandenen Metadaten zur Verfügung.

notand commented 6 years ago

@tobinski Danke für die Ausführungen und für die Links. Wenn das mit der ElasticSerach-API geht, super. Interessant, das mit schema.org ImageObject. Scheint mir eine inhaltliche Datenstruktur zu sein. Falls wir IIIF-Manifeste verwenden, würden die als Präsentationsschicht darüber liegen, das müssen wir aber aus meiner Sicht nicht jetzt sofort klären.

Frage: Was ist die API-Plattform (Link, Doku?), im Vergleich zur ElasticSearch API? @tobinski @guenterh

Vorschlag für die nächsten Schritte:

tobinski commented 6 years ago

@notand Die API Plattform ist ein Plattform um API's im Hydra Format generieren, die sich per GraphQL abfragen lassen. Sie basiert auf Symfony Komponenten und ist in php geschrieben. Damit können wir theoretisch jeden beliebige Endpoint programmieren. ElasticSearch ist eine auf Lucen basierende Suchmaschine, die Daten auch in Json-Format ausliefern kann. Wir haben aber nicht dieselben Möglichkeiten Daten vor der Auslieferung programmatisch zu manipulieren, wie bei API-Plattform.

Den Vorschlägen stimme ich weitgehend zu. Prüfen wir zuerst das Afrikaportal und schauen danach weiter. Wenn wir uns entscheiden unser eigenes Frontend weiterzuentwickeln, sollten wir jedoch zuerst die Fragen des Metadaten-Formats klären und danach eine minimale API bauen. Ich würde viele der Funktionen (Filter, Sortieren usw.) auf dem Server machen und nicht im Frontend. Danach können wir das Frontend an den Server anbinden.

sschuepbach commented 6 years ago

@tobinski, vielen Dank für deine spezifischen Ausführungen zum weiteren Vorgehen, denen ich zustimme. Die Frage der Nachnutzung des Afrika-Portals hängt für mich wesentlich von der (Nicht-)Verwendung einer intermediären API (wie API-Plattform) ab.

tobinski commented 6 years ago

@sschuepbach Stimmt! Falls wir spezifische Ansprüche an eine View haben, dann ist das RDV-Projekt nur bedingt geeignet. Hier stellt sich - wieder einmal - die Frage, was am Schluss alles sichtbar sein soll und in welchen Formaten. :point_up: Auch das RDV Projekt verwendet ein intermediäres Layer. Sie verwenden ein php Script, dass als Proxy auf den eigentlichen Elastic Search Server fungiert. Dort wären vielleicht kleinere Datentransformationen durchzuführen.

notand commented 6 years ago

@tobinski Danke für die Erklärungen, hat mir sehr geholfen! Was braucht es, um die Frage "Was am Schluss alles sichtbar sein soll und in welchen Formaten" genügend weit zu klären (um die RDV-Entscheidung zu treffen und mit der API weiter zu kommen)? Mein Klärungsversuch dazu: Die Metadaten-Tabelle und das API-Spezifikations-mkd, die ich gerade eingestellt habe (bei umfangreicheren Klärungen finde ich Spec-Doks besser als verstreute Issue-Diskussionen, aber bitte schreibt gerne, womit ihr für solche Fälle gute Erfahrungen gemacht habt). Falls jemand eine bessere Formatidee für Tabellen hat (besser als .ods), gerne her damit!

tobinski commented 6 years ago

@notand Danke für die Spezifikationen. Ich würde das am Anfang ohne Manifest machen, sondern mal alles in ein Elastic Search Index pushen und dann von da abfragen. Wenn wir motiviert sind, können wir dies dann immer noch weiter verfeinern. Ich hab dazu ein Issue erstellt.

Bezüglich RDV Projekt, warten wir aktuell noch auf eine Antwort von dem Entwickler (https://github.com/UB-UNIBAS/rdv/issues/3), wie das Modell auszusehen hat.

martrei commented 6 years ago

@Dominique-B: glaubst du das Sozialarchiv könnte in ihren Daten auch angeben, welche Objekte digitalisiert sind (oder sollte für alle ein Bild existieren?). Beim Konvertieren der Bilder nach JP2000 sind nämlich ein paar Fehler aufgetreten (ohne dass ich allerdings die konkreten Bilder kenne). Bevor ich mich nun selbst auf die Suche mache, wäre es hilfreich, dies anhand der Metadaten überprüfen zu können. @Dominique-B / @tobinski : brauchen wir momentan Paginierung? momentan gehe ich davon aus, dass je Objekt nur ein Bild existiert. @tobinski / @notand : müssen sich IIIF-Pres, Präsentation, ES ausschliessen? Könnte man nicht die Manifeste ganz gut in ES speichern bzw. über Templates im Zwischenlayer befüllen? Ich erinnere mich auch vage, dass die IIIF-Pres-API mit Canvas und OpenAnnotation auch die Möglichkeit zum Erschliessen bietet und daher als Ergänzung Richtung Crowdsourcing interessant sein könnte? Dazu braucht es aber sicher noch konzeptionelle Arbeit. In vielen deutschen Institutionen wird ja auch eine eigene Präsentationsschicht und der DFG-Viewer (via METS-Files) gemeinsam angeboten. Könnte es hier dann nicht Präsentationsschicht + z.B. Mirador sein? Durch die nicht vorhandene innere Struktur der Objekte dürfte, so hoffe ich, die Generierung der Manifest-Dateien nicht zu kompliziert sein?

tobinski commented 6 years ago

@martrei Ich versteh die Applikation aktuell so, dass ich durch den egasamten Bestand des Soz-Archives navigieren kann. Entsprechend muss es eine Listen-Sicht geben, die Paginable, Sortable und Filterable ist. Davon "getrennt" ist dann das einzelne Objekt, das wir dann auch im Viewer genauer betrachten können. Also ein einzelnes Bild, dass über Metadaten verfügt. Soweiz ich das gesehen habe, ist die IIIF-Pres-Api eine Spezifikation, wie Daten auf ein Modell gemapped werden und keine Implementation. Es kann sein, dass es ein Tool gibt, welches Crowdsourcing ermöglicht, da kenne ich mich aber zu wenig aus. Ein Manifest zu generieren sollte nicht zu schwer sein. Stellt sich halt die Frage, welchen Mehrwert das Manifest mit unseren Meta-Daten hat?

tobinski commented 6 years ago

Ich hab mal einen Elasticsearch Container aufgesetzt und mit den Metadaten des SAH befült. Dadurch haben wir einfach Zugriff auf die Daten und können weiter an dem Frontend arbeiten. Ihr könnt über http://es.dataramblers.io/sah/_search?q=* darauf zugreifen oder setzt den Server bei euch lokal mittels Ansible und Docker auf. Aktuell ist kein spezifisches Mapping geladen.

martrei commented 6 years ago

http://projectmirador.org/demo/ ist ein Tool, dass die IIIF-Präsentations-Manifeste interpretiert und auch annotierbar macht, um etwa auf Fotos einzelne Personen zu taggen. Wie solche Informationen gespeichert und genutzt werden, wären dann weiterführende Fragen. Mit dem Mirador-Viewer könnte man auch relativ billig eine Lösung bekommen, um sich Bilder nebeneinander anzuschauen, zu vergleichen oder in einer Gallery-Ansicht zu präsentieren, wenn man dafür die Manifeste immer on the flow je nach Suchtreffer generiert. Das würde ich eigentlich recht spannend finden, weil es glaube ich dem Nutzer eine sehr gute Möglichkeit gibt, sich rasch einen guten visuellen Ueberblick über Suchtreffer zu machen...

notand commented 6 years ago

@martrei Ich habe meine Bemerkungen zu IIIF in das Issue 6 im Datenhack-Sozarch-Repo geschrieben. Weil es hier in diesem Issue wenn ich das richtig verstehe eher um die Datenzugriffs-API (Model, Controller - im Gegensatz zu View) geht.

sschuepbach commented 6 years ago

@notand / @tobinski / @matrei: Könnnen wir dieses Issue schliessen? Die konzeptionelle Diskussion haben wir an unserem letzten Treffen geführt, und für die Klärung von Implementierungsdetails der API scheint mir das inzwischen erstellte Repository https://github.com/dataramblers/api-middleware besser geeignet.

tobinski commented 6 years ago

Ja schliessen wir das issue