IIIF-Presentattion API

[tobinski]

Mir ist nicht ganz klar, ob wir die IIIF-Presentation API nutzen, um die Metadaten darzustellen oder ein eigenes Model verwenden. Die Presentation API bietet ein guten Standard, um Informationen um und über ein Bild abzubilden. Ich bin mir jedoch nicht ganz sicher, ob dies im Falle der SAH Metadaten wirklich hilfreich ist, da wir relativ wenig Metadaten haben

[notand]

Ich würde gerne mal herumprobieren, die Metadaten in ein Manifest (Presentation API) zu schreiben, dann könnten wir nämlich die bestehenden Standard-Viewer, wie UniversalViewer oder Mirador nutzen. Bei diesen Viewern sehe ich das Problem momentan darin, dass sie noch nicht sehr gut darin sind, Metadaten zu einzelnen Bildern anzuzeigen, sondern nur zu dem Objekt, das von einem gesamten Manifest (i.d.R. mehrere Bilder) repräsentiert wird. Andererseits hat man mit diesen Viewern gleich die gesamten Blättern-, Vergleichen- u.ä. Funktionalitäten.

Wenn wir OpenSeaDragon (Einzelbild-Viewer) benutzen und direkt in die Webseite einbinden, müssen wir uns für die Anzeige der Metadaten etwas eigenes bauen, wenn ich das richtig verstehe.

Ich habe diese Woche etwas Zeit und würde mir gerne Sebastians Frontend anschauen und mithilfe des IIIF-Servers mit Manifesten und UniversalViewer und Mirador herumprobieren. Und danach nochmal ne Meinung zu dem Thema sagen.

Hintergrundinfo zur Trennung von Metadatenmodell und IIIF-API (View) - siehe http://resources.digirati.com/iiif/an-introduction-to-iiif/wheres-my-model.html:
IIIF confines itself to the semantics of presentation, and that gives us interoperability by steering clear of the object’s meaning. Now we can all view objects over the web in whatever viewers, workbench applications, web pages or other user interfaces the IIIF manifests for those objects find themselves in.
Wrapping those objects in meaning and giving them context is where your model comes in. That meaning resides in other places, both formal - a machine readable record conforming to some accepted scheme - and informal - an essay that describes the object in prose.
[...]
The manifest is an addition to your model, alongside all these things, as a format for the digital surrogate of an object so that you can make it viewable over the web. It doesn’t replace any of the other types of metadata or content.

[notand]

Zur Anzeige seitenbezogener Metadaten in Mirador:
Es gibt einen Entwickler bei biblissima, der diese Funktionalität zu der projektspezifischen Mirador-Version dazuprogrammiert hat:
http://demos.biblissima-condorcet.fr/bbmn-1713/mirador/
(Manuskript-Seite auswählen > in die Einzelseiten-Ansicht/Image-View gehen > das i-Icon links oben anklicken > durchblättern)

[tobinski]

Ich kenne mich nicht mit der Presentation API aus, aber sie scheint gut geeignet die Bilder und die abgebildeten Objekte zu beschreiben. Ich bin mir aber nicht sicher ob wir das für unseren Bestand wollen und können. Wir sollten vorher definieren, was wir darstellen wollen/können und dann schauen, ob wir dies mit einem Manifest können.
Wenn wir auf die Presentation API verzichten und OpenSeadragon nützen, dann müssen wir die Darstellung der Metadaten selber übernehmen. Je nach UseCase wäre dies ein Vor- oder Nachteil.
@notand Damit das Frontend von @sschuepbach funktioniert müssten wir noch eine minimale API Implementieren oder die Bilder statisch in der App hinterlegen. Aktuell sind nur Demodaten drin. Ich hab dies mal als Issue #3 im Frontend Repo erfasst

[notand]

@tobinski Die Use Cases, die wir am 1. Februar besprochen hatten, habe ich im readme notiert. Müssen wir uns die mit den neuen Entwicklungen und Fragen nochmal vornehmen und weiter konkretisieren? Sortieren und Filtern geht meines Wissens mit Manifest+UniversalViewer/Mirador nicht. Aber ich achte da nochmal drauf, wenn ich das dann endlich ausprobiere.

[tobinski]

Wenn wir uns die Use-Cases anschauen, dann ist das Manifest für den Fall "... ein Bild und die zugehörigen Metadaten in einer Ansicht anschauen" eine Option. Für die beiden anderen Use-Cases brauchen wir weitere Features, die die Presentation API nicht unbedingt mitbringen. Zumindest glaube ich das nach der ersten Durchsicht der Specs. Dafür brauchen wir wohl eine Form von API-Endpoint

[Dominique-B]

Die aktuellen Metadaten in JSON:
F_5025 Schweizerisches Arbeiterhilfswerk (SAH).json.zip

[notand]

@Dominique-B Danke für das Metadaten-JSON und für die Beschreibung im readme. Ich habe mal eine extra Tabelle für die Metadaten-Doku und -Spezifikation angelegt und deine Infos dort mit aufgenommen. Würde deshalb die Details aus dem readme streichen. Können wir die csvs als Metadatenquelle damit eigentlich streichen, also verwenden wir die nun garnicht? Oder hast du Daten aus den csvs in das JSON reingespielt?

[notand]

@tobinski Ich habe mit Manifesten und Mirador herumprobiert und komme immer mehr zu dem Schluss, dass die Verwendung von IIIF-Manifesten für unsere Use Cases nicht ganz passt. Grund: Wenn man jedes Bild mit einem Manifest repräsentiert, sind die aktuell verfügbaren Übersichtsfunktionalitäten in den Viewern für uns nicht praktisch. Wenn man alle Bilder eines Ordners (oder einer anderen sinnvollen Einheit) in ein Manifest schreibt, bekommt man schöne Navigations- und Vergleichmöglichkeiten, kann aber keine bildbezogenen Metadaten anzeigen.
Ich habe mal in einer Tabelle für jedes Metadatum aus JSON aufgeschrieben, was das für ein Feld in einem IIIF-Manifest wäre. Dadurch wird vielleicht deutlicher, was ich damit meine, dass die IIIF-API rein darstellungsbezogen ist (ich bin mir nicht sicher, ob wir da aneinander vorbei reden). Die API, die den Datenzugriff des Clients auf den Server realisiert, ist in meiner Sicht etwas anderes. Ich habe ein Dokument für diese API-Spezifikation angefangen, vielleicht können wir darin einen gemeinsamen Ansatz für die API erarbeiten.

[tobinski]

@notand Ich sehe dies ähnlich. Wenn wir auf die IIIF-Presentation API verzichten, können wir auch einfach mal mit einem Elastic Search server als API starten. @dataramblers/owners Was meinen die anderen?

[Dominique-B]

@notand Du kannst das gerne so bereinigen, habe auch keine Verwendung für die CSVs mehr.

[notand]

Habe zwei noch recht stümperhafte beispielhafte IIIF-Manifeste mit SAH-Bildern hier rein gestellt. So seht ihr mal die Grundstruktur, weil @martrei in Frontend-Repo #3 da nochmal Fragen aufgeworfen hat. Zu den Fragen von @martrei:

• Ja, IIIF wäre eine extra Präsentationsschicht und ich sehe das auch so, dass man die relativ unabhängig von ES behandeln kann, sie ist jedenfalls kein Model für die Daten, das habe ich oben versucht zu erklären.
• Ja, Annotieren ist mit IIIF vorgesehen. Ich habe noch keine laufende Mirador-Umsetzung dafür gesehen. Man braucht einen Annotation-Server. Geht über unsere als erste Schritte definierten Use Cases hinaus. Wenn das nicht vergessen gehen soll, in das Use_Cases.mkd aufnehmen!
• Generierung der SAH-Manifest-Dateien wäre nicht kompliziert.
• Wenn man in einem Manifest mehrere Bilder repräsentiert (je nach Such- oder Filterergebnis), würde ich das wie @martrei sagt on the fly generieren. Wenn man für jedes Bild ein Manifest generiert (was eine vollständige Metadatenanzeige erlaubt), dann würde ich einmal für jedes Bild ein Manifest auf den Server/in ES legen.

Wer die beiden Beispielmanifeste in Mirador ausprobieren möchte:

1. Navigate to http://projectmirador.org/demo/.
2. Click the x box in both windows to close the windows.
3. Hover over the icon to the right of the x and click "Replace Object"
4. Paste in your manifest url to the text box "Add new object from URL:" Vorerst diese URLs:

• https://gist.githubusercontent.com/notand/3bc5d8192723bee3086bbf2d04e2e4cf/raw/7e7fb238c3f4cf558b5d9d5885906b035e9c9627/manifest_SAH_singlePic.json
• https://gist.githubusercontent.com/notand/625dc3b82280d6e64e3736df6842106b/raw/4a70f4e7ecf446b8dc9012066ccfd4e0957cc009/manifest_SAH_picList.json

5. Click "Load" - You should see your manifest loaded there. Click on one of your images.

[guenterh]

Hallo @dataramblers/owners
sorry, konnte mich in der letzten Zeit kaum aktiv beteiligen, habe die Diskussionen aber zumeist mit einem Auge mitverfolgt und @sschuepbach hat mir vor einer guten Woche mündlich einen kleinen update gegeben.
Zwei Dinge:

• besteht noch Interesse daran, neben/anstelle der ES API die API platform zu verwenden? Ich werde mich in der nächsten Zeit im Rahmen des swissbib Projekts wieder damit beschäftigen müssen / wollen und könnte hier wohl einen Input geben
• es hat sich ergeben, dass ich Mitte April (14. / 15.) nach Leipzig fahre und u.a. an einem workshop an der UB teilnehme. Daneben werde ich Samstag und / oder Sonntag auch in die Auftaktveranstaltung von coding da vinci hineinsehen (https://codingdavinci.de/events/ost/) Hättet Ihr Interesse, die dataramblers Aktivitäten auch in diesen "Wettbewerb" einzubringen?

[tobinski]

@guenterh Ich weiss nicht ob und wie wir API-Platform einsetzen wollen, das wird wohl nach der Projektsitzung entschieden werden. Ich hab auch der Punkt mit dem coding da vinci als Traktandum für die Projektsitzung gesetzt. Persönlich bin ich aktuell motiviert.