URN und weiter?

[jan]

Hallo @bbfks,

um einschätzen zu können was genau gewünscht wird brauchen wir eine genauere Aufstellung der Anforderungen. Wird zu Beispiel eine Weiterleitung gewünscht, oder eine Abfragemöglichkeit der potentiellen Ressourcen?

Viele Grüße,

Jan

[bbfks]

Ich weiß zunächst nicht, wie es technisch - in der URN-Spezifikation - eigentlich gedacht ist.

• Sollte die URN nicht sowieso - vom viewer-eigenen Resolver - bis zur viewer-eigenen URL weitergeleitet werden. Das ist ja im Moment nicht der Fall, bzw. bei uns nicht.

Und was zweitens ihr als Entwickler eigentlich vorschlagen würdet, wie man über die APIs mit dem Viewer kommunizieren soll.

Unabhängig davon: die einfachste Lösung wäre, eine Weiterleitung die PPN und URN irgendwie zu matchen, und so weiterzuleiten, dass ich die Schnittstellen URLs gleiichermaßen benutzen kann. Also dein erster Vorschlag …

[jan]

Hi,

Nunja, es ist vorgegeben, dass die URN von der DNB eindeutig auf eine URL matcht. Die URN von der DNB zeigt immer auf den Goobi viewer internen URN-Resolver, damit wir auch Fälle wie URN-Granular auf Seitenebene mit bedacht sind.

Wenn wir die Resolver dahingehend erweitern würden, dass sie auch mit URNs umgehen können, quasi analog zu dem bisherigen Identifer, sehe ich bereits den nächsten Anwender hier stehen und sagen: “Wir haben keine URNs, sondern nutzen DOI”. Dann haben wir auf einmal URLs, die in der URL kodiert werden müssen die dann weiter gegeben werden? Das finde ich nicht schön.

Besser fände ich da einen REST Endpoint zu haben dem ich einen Feldnamen und einen Identifier übergeben kann und dann ein eine Antwort bekomme die - und jetzt geht es in Deine Richtung - WIE aussehen soll? Was ist denn technisch gefordert wenn der skizzierte Fall “maschinell weiterverarbeitet” Eintritt?

Beste Grüße aus dem Homeoffice von

Jan

[bbfks]

Also du meinst so etwa:

https://meinlieberview.er/gibmirzu/MEINEID/dieJPGVersion

oder

https://meinlieberview.er/gibmirzu/MEINEID/die_iif_anweisung

Das meinst du aber - glaube ich - nicht.

Was meisnt du mit Feldnamen?

[jan]

Das habe ich nicht verstanden.

Mit Feldnamen meine ich die Namen der Felder im Apache Solr Suchindex.

[bbfks]

Ich glaube ich kann das abkürzen.

Wir brauchen tatsächlich einen vollen Zugriff über jeden Identfiier auf die sonstige Funktionalität des Viewers.

So wie es jetz ist, ist dieser Resolver eine Sackgasse.

Und nein, keine Eingabe von Feldnamen. Das ist doch für außenstehende EntwicklerInnen nicht verständlich.

[jan]

Ein Resolver ist ein Resolver. Es ist ein PPN-Resolver, ein URN-Resolver, ein METS- oder LIDO-Resolver. Er löst bei der Eingabe der entsprechenden Identifier zu den Werken oder den Metadaten auf. Diese Funktionalität hat der Goobi viewer inzwischen in dieser Form seit 10 Jahren. In dieser Zeit hat sich das nicht als Sackgasse erwiesen.

Ich kann aber verstehen was hier gewünscht ist. Dafür müssen wir aber ein Konzept erstellen, denn eine PPN steht nun einmal nicht im Suchfeld für URNs. Eine DOI auch nicht. Gerne überlege ich mir und schreibe ein entsprechendes Konzept auf. Ich glaube auch, dass das gar nicht schwer ist.

Es gibt nur eine Frage die ich beantwortet haben muss: Was ist mit sonstige Funktionalität des Viewers gemeint?

Das kann ja extrem viel sein wenn man sich das überlegt:

• Gib mir die IIIF Collections in denen dieses Werk enthalten ist
• Gib mir die Kommentare des Werkes
• Gib mir die Links zu den Crowdsourcing Kampagnen
• Gib mir die ALTO Dateien
• Gib mir die Annotationen
• Gib mir die IIIF Manifeste
• Gib mir die Metadaten im Format XYZ
• Gib mir die Benutzer die eine Annotation in diesem Werk erstellt haben
• …

Man könnte tausend Dinge aufschreiben. Am einfachsten ist es da immer konkret mit etwas anzufangen was direkt benötigt wird und nicht pauschal alles zu machen. Das würde nämlich viel zu lange dauern und wäre dann auch viel zu teuer…

[bbfks]

Der GND-Resolver im Viewer ist eigentlich kein Resolver, weil er nicht “auflöst”, sondern etwas entgegennimmt, damit etwas da ist. Er müsste eigentlich auf etwas weiterleiten. So ist er ein Stellvertreter , damit die GND, bzw. ein Nutzer auf jeden Fall eine Antwort bekommt.

Was benötigt wird? Alles. Die URN ist der schlüssel zu allen Daten und Möglichekkeiten im Viewer.

So wie du das beschreibst, ist es genau das, was ich meine. Wahrscheinlich oder vielleicht ist die Lösung tatsächlich eine Weiterleitung, na ja ein Resolver eben.

[jan]

Hallo @bbfks,

im Goobi viewer gibt es keinen GND-Resolver. Alles was an GND-Informationen abgefragt wird passiert über einen REST Endpoint, aber nicht über einen Resolver.

Ja, für Euch ist die URN vielleicht der Schlüssel, aber nicht für alle. Deswegen wäre es fatal eine Lösung zu implementieren die nur auf einen kleinen Anwenderkreis zutrifft. Sie sollte so generisch sein, dass alle Eure Anfragen erfüllt werden, sie aber auch von allen anderen genutzt werden kann.

Ein REST Endpoint zum Beispiel:

• GET: /rest/record/FIELDNAME/IDENTIFIER/

Könnte dann ja die folgenden URLs enthalten:

• https://viewer.example.org/rest/record/PI/PPN1234567890/
• https://viewer.example.org/rest/record/PI/AC1234567/
• https://viewer.example.org/rest/record/URN/urn:nbn:de:123:foo-bar-123459/
• https://viewer.example.org/rest/record/MD_HANDLE/21.11107##SLASHPLACEHOLDER##record_DE-MUS-069123_118/
• https://viewer.example.org/rest/record/MD_DOI/10.1038##SLASHPLACEHOLDER##nphys1170/

Alles wäre valide und möglich. Die alternative wäre ja den Endpoint so zu gestalten:

• GET: /rest/record/IDENTIFIER/

Da ein Werk ja aber mehr als einen Identifier haben kann, andere Einrichtungen haben in der Vergangenheit zum Beispiel zusätzlich auch einen Allegro Identifier genutzt, müssten wir im Goobi viewer Logik implementieren das überhaupt erst einmal Identifier Felder definiert. Wir müssten also in der Konfigurationsdatei sagen:

<config>
  <webapi>
    <identifierFields>
      <field>PI</field>
      <field>URN</field>
      <field>MD_HANDLE</field>
      <field>MD_DOI</field>
      <field>MD_ALLEGROID</field>
    </identifierFields>
  </webapi>
</config>

Das ist sicherlich auch möglich, erfordert aber mehr Einrichtungsaufwand und schränkt die Möglichkeiten nach außen hin auch ein weil neue Felder die ein Entwickler vielleicht gerne abfragen und probieren würde erst einmal konfiguriert und freigeschaltet werden müssten.

Die Antwort des REST Endpoints könnte dann JSON oder XML sein. Ich bevorzuge immer JSON aber der Response content type kann ja bei jeder Anfrage einfach über den HTTP accept header gesetzt werden. Spannend ist aber wie die Antwort dann aussehen soll. Hier habe ich von Dir leider immer noch keine konkrete Aussage bekommen was in Eurem Fall genau gewünscht ist. Ich habe mir oben nur etwas ausgedacht, technisch könnte es so aussehen:

{
	"identifier": "urn:nbn:de:123:foo-bar-123459",
	"identifierField": "URN",
	"recordResolverLinks": {
		"ppnresolver": "https://viewer.example.org/ppnresolver?id=ppn1234567890",
		"urnresolver": "https://viewer.example.org/resolver?urn=urn:nbn:de:123:foo-bar-123459"
	},
	"sourceMetadata": "https://viewer.example.org/metsresolver?id=ppn1234567890",
	"iiifManifest": "https://viewer.example.org/rest/iiif/manifests/ppn1234567890/manifest"
}

Allerdings kann man sich jetzt hier austoben. Man könnte beliebige Informationen zurückbekommen. Wie soll die Antwort hier konkret aussehen? Ich interpretiere die Anfrage hier so, als ob es Entwickler gäbe die gerne mit der Schnittstelle arbeiten würden aber nicht können. Wenn dem so ist muss es doch konkrete Fragestellungen geben die nicht beantwortet werden können. Die würde ich gerne wissen.

Viele Grüße,

Jan

[Schlueter_HAAB]

Hallo,

so richtig klar ist mir der Wunsch bzw. was damit erreicht werden soll, noch nicht. Wäre es bzgl. der URN nicht eigentlich optimal, direkt über https://nbn-resolving.org/ mehr Informationen zum Werk zu liefern? Wenn also eine URN gegen den Resolver läuft, dann gibt der als Antwort nicht nur den Link zum Werk zurück, sondern je nach Art der Anfrage evtl. auch direkt die METS-Datei/ das IIIF-Manifest.

[jan]

@Schlueter_HAAB das würde ja aber Entwicklung bei der DNB bedeuten und wäre dann auch kein Resolver mehr in dem Sinne, sondern eine Übersicht mit verschiedenen Informationen zu einer URN.

[Schlueter_HAAB]

@jan aber wenn ich die Anforderung verstanden habe, würde es das Problem lösen?

[jan]

@Schlueter_HAAB Ja, es würde das Problem lösen. Aber es wäre die gleiche Entwicklung wie im Goobi viewer nur bei der DNB und es müsste dazu kommen, dass die DNB die Seite mit den verschiedenen Informationen zu einer URN regelmäßig aktualisieren würde. Dafür müsste zum Beispiel beim Provider (in diesem Fall der Goobi viewer) Activity Streams nicht nur für die IIIF Change Discovery API implementiert, sondern auch beim Consumer (der DNB) diese Informationen ausgewertet und angezeigt werden.

Ich würde mich immer noch dafür interessieren wie genau der UseCase hier aussieht und was an konkreten Informationen benötigt werden…

[bbfks]

@jan

gibt es keinen GND-Resolver

Ein Vertippser. Es war natürlich URN-Resolver gemeint.

[bbfks]

@jan

Ja, für Euch ist die URN vielleicht der Schlüssel, aber nicht für alle. Deswegen wäre es fatal eine Lösung zu implementieren die nur auf einen kleinen Anwenderkreis zutrifft.

Mittlerweile kristallisieren sich zwei oder drei globale Identifier heraus: DOI, URN vielleicht auch Handle.

Die Forschenden werden dazu angehalten, diese Identifier zu benutzen. Die Verwendung von lokalen Identifiern sollte möglichst vermieden werden.

Es handelt sich dabei also nicht um eine Lösung für einen kleinen Anwenderkreis, sondern um eine globale Lösung. Im Moment scheint der Anwenderkreis vielleicht noch klein, aber diese Maßnahme bzw. Diskussion dient zur Vorbereitung auf eine zukünftige Nachfrage.

[bbfks]

@Schlueter_HAAB

Wäre es bzgl. der URN nicht eigentlich optimal, direkt über https://nbn-resolving.org/ mehr Informationen zum Werk zu liefern? Wenn also eine URN gegen den Resolver läuft, dann gibt der als Antwort nicht nur den Link zum Werk zurück, sondern je nach Art der Anfrage evtl. auch direkt die METS-Datei/ das IIIF-Manifest.

Aud der Logik der URN-Spezifikation, müsste eigentlich jede digitale, endgültige und unveränderliche Repräsentation eine Dinges eine eigene URN haben.

[bbfks]

@jan

Da ein Werk ja aber mehr als einen Identifier haben kann, andere Einrichtungen haben in der Vergangenheit zum Beispiel zusätzlich auch einen Allegro Identifier genutzt, müssten wir im Goobi viewer Logik implementieren das überhaupt erst einmal Identifier Felder definiert. Wir müssten also in der Konfigurationsdatei sagen:

Ja, das ist richtig.

[bbfks]

@jan

Hier habe ich von Dir leider immer noch keine konkrete Aussage bekommen was in Eurem Fall genau gewünscht ist.

Ja, doch. Ich habe sehr konkret gesagt: alle digitalen Repräsentation eines Dinges - natürlich nicht auf einmal. Du hast das oben schon aufgeführt: Volltexte, Image-Formate, und Zugriff auf die IIF-Schnittstelle, damit ich eine beliebige Image-Verison definieren kann usw.

Der Nachteil

@jan

Die Antwort des REST Endpoints könnte dann JSON oder XML sein

Das hat den Nachteil, dass ein Programm erst eine Datei auswerten muss. In unserem Fall würde es aber genügen, wenn wir URL-Arithemetik machen, also mit einer gegeben URN dem Programm das iif-Manifest geben lassen. Das ist dort auch bereits implementiert, nur kommen wir eben über diese URN-Sackgasse nicht auf die anderen Schnittstellen des Viewers.

[Schlueter_HAAB]

Sollte ich ein Image-Format wirklich mit einer URN hinterlegen? Das würde, bei krasser Auslegung der Richtlinien, bedeuten, dass ich weder Kompressionsgrad noch Dateiformat ändern dürfte? Auch an den Bildheadern dürften keine Änderungen mehr stattfinden. Schon bei einem erneuten Export von Vorgängen an den Viewer sehe ich hier gleich mehrere Probleme.

[jan]

Nur so zur Info mal eben eingeschoben: Wenn man wie in der Doku beschrieben einen Redirect anstelle eines Forwards macht, kann man sehr einfach durch das Parsen des Response Headers und Auswerten der Location von einer URN auf den Identifier schließen…

curl -sI https://viewer.example.org/resolver?urn=urn=urn:nbn:de:123:foo-bar-123459 | grep Location: | cut -d"/" -f3