Liebe Kollegen,

prinzipiell halte ich eine umfassende REST-API für einen großen Mehrwert, da die Integration von / nach Drittsystemen, sowie die Automatisierung erfahrungsgemäß einfacher zu bewerkstelligen ist.

An der ULB Halle mussten wir für unseren neuen Digitalierungs-Workflow eine Reihe zusätzlicher Modifikation der Metadaten und Mediadaten einarbeiten, was wir mangels Alternativen über Skripte auf dem Server realisiert haben. Diese Skripte manipulieren teilweise direkt die XML-Daten. Mittel- und langfristig wird diese Situation schwierig zu warten sein.

Soweit ich das überschaue, wurde die REST-API für Version 3 gegenwärtig mehr oder weniger direkt von Kitodo 2 übernommen, inklusive der bereits in Version vorhandenen, komplett eigenständigen Service-Implementation. Die eingeständige Implementation führt leider auch dazu, dass sich die REST-API im Moment anders verhält als die JSF-Web-GUI.
In Kitodo 3 gibt es eine ServiceFactory, die man sicherlich auch als Grundlage für eine voll funktionsfähige REST-API nehmen könnte. Dann könnte man als Grundlage die zentrale Service API verwenden, was die Pflege enorm vereinfachen würde.

Falls das auch andere Mitstreiter für eine sinnvolle Option halten, würde ich dort auch mithelfen, da ich beruflich bereits mit Swagger & Co im Maven-Umfeld zu tun hatte.


Mit freundlichen Grüßen


On 15.10.19 13:51, Christian Haenger wrote:
Lieber Herr Ronge,

haben Sie vielen Dank für die Info. Für Kitodo 2 werden wir mit der meta.xml arbeiten und für Kitodo 3 gibt es vielleicht gute Optionen.

Viele Grüße

Christian Hänger


Am 14.10.2019 um 09:57 schrieb Ronge, Matthias:

Hallo Herr Häger,

 

In Kitodo 3 ist das Bearbeiten der Metadateien über die Kitodo-API möglich. Die Kitodo API ist eine Java API (keine XML API). Sie können damit aber auf jeden Fall auf die METS-Datei zugreifen. Durch Verwendung der Kitodo-API ist sichergestellt, dass zusätzliche Annahmen, die für das Internformat gelten, korrekt berücksichtigt werden. Dennoch rate ich dazu, vor dem Verändern eine Sicherheitskopie der Datei anzulegen.

 

Hier ein Beispiel für das Hinzufügen von Daten:

 

import java.io.*;

import java.net.*;

 

// kitodo-api.jar

import org.kitodo.api.*; // metadata

import org.kitodo.api.dataformat.*; // Kitodo data format

 

// module from kitodo-dataformat.jar

import org.kitodo.dataformat.access.MetsXmlElementAccess;

 

public class AddDataExample {

    static final MetsXmlElementAccess kitodoDataformat= new MetsXmlElementAccess(); // load module

 

    public static void main(String[] args) throws IOException, URISyntaxException {

        // read existing file

        File metaXmlFile = new File("/path/to/meta.xml");

        Workpiece workpiece;

        try (InputStream in = new FileInputStream(metaXmlFile)) {

            workpiece = kitodoDataformat.read(in); // use module to read

        }

 

        // adding an included structural element

        IncludedStructuralElement includedStructuralElement = new IncludedStructuralElement();

        includedStructuralElement.setType("volume");

        includedStructuralElement.setLabel("Band J-N");

        workpiece.getRootElement().getChildren().add(includedStructuralElement);

 

        // adding metadata to an included structural element

        MetadataEntry metadata = new MetadataEntry();

        metadata.setKey("title");

        metadata.setValue("20000 Meilen unter dem Meer");

        metadata.setDomain(MdSec.DMD_SEC);

        workpiece.getRootElement().getMetadata().add(metadata);

 

        // adding a media unit to a workpiece

        MediaVariant localVariant = new MediaVariant();

        localVariant.setUse("LOCAL");

        localVariant.setMimeType("image/tiff");

 

        MediaVariant maxVariant = new MediaVariant();

        maxVariant.setUse("MAX");

        maxVariant.setMimeType("image/jpeg");

 

        MediaUnit mediaUnit = new MediaUnit();

        mediaUnit.setOrder(1234567);

        mediaUnit.getMediaFiles().put(localVariant, new URI("images/Vern2000_media/01234567.tif"));

        mediaUnit.getMediaFiles().put(maxVariant, new URI("jpgs/max/01234567.jpg"));

        workpiece.getMediaUnits().add(mediaUnit);

 

        // assigning a media unit to an included structural element

        View view = new View();

        view.setMediaUnit(mediaUnit);

        includedStructuralElement.getViews().add(view);

       

        // save file

        try (OutputStream out = new FileOutputStream(metaXmlFile)) {

            kitodoDataformat.save(workpiece, out); // use module to write

        }

    }

}

 

Ich hoffe, dass dies Ihnen nützlich sein kann.

 

An dieser Stelle noch der Link, wie Sie die Javadoc Quelltextdokumentation zu Kitodo erzeugen können:

https://kitodo-production.readthedocs.io/en/master/javadoc/README/

 

Mit freundlichen Grüßen

Matthias Ronge

 

 


Matthias Ronge
Software Entwicklung/Software Development

Zeutschel GmbH | Heerweg 2 | 72070 Tübingen | Deutschland
p: +49 (7071) 9706-62 | m: | f: +49 (7071) 9706-44
e: Matthias.Ronge@zeutschel.de | w: http://www.zeutschel.de
Geschäftsführer/President: Joerg Vogler | Registergericht Stuttgart: HRB 380917

Von: kitodo-community-bounces@kitodo.org <kitodo-community-bounces@kitodo.org> Im Auftrag von Christian Haenger
Gesendet: Donnerstag, 10. Oktober 2019 11:52
An: kitodo-community@kitodo.org
Betreff: Re: [Kitodo] REST-API

 

Hallo Herr Weber,

 

danke für die Antwort. Ja, mir geht es um die Ergänzung der Meta- und Strukturdaten eines bereits erstellten Vorgangs.

 

Wir schauen uns die Funktion für Kitodo.Production 3.x an.

 

Kurzfristig werden wir uns wahrscheinlich über die meta.xml helfen. Mittelfristig ist aus meiner Sicht eine funktionierende import-API der richtige Weg.

 

Viele Grüße

 

Christian Hänger

 

 

Am 10.10.2019 um 08:17 schrieb Weber, Frank-Ulrich:

Hallo Herr Hänger,

 

es geht Ihnen im Grundsatz also darum, die Meta- und Strukturdaten eines bereits erstellten Vorgangs

im Nachhinein automatisch (durch Import) zu aktualisieren und zu ergänzen?

 

Diese Erweiterung wurde für Kitodo.Production 2.x schon mehrmals diskutiert

und müsste jetzt in Kitodo.Production 3.x umgesetzt werden.

Da wir bereits in anderen Projekten (Kitodo.Production  2.x / Kitodo.Presentation) und jetzt im Rahmen des DFG-Projekts zu Kitodo.Production 3.x

aktiv an der Entwicklung von Kitodo teilnehmen, sind wir natürlich auch gerne bereit weitere Entwicklungen (z.B. API) durchzuführen.

 

Unabhängig davon werde ich Ihren Wunsch, sofern korrekt von mir interpretiert, in die Projektinterne Liste möglicher Weiterentwicklungen aufnehmen.

 

Beste Grüße

 

Frank Ulrich Weber

 


Frank-Ulrich Weber
Product Manager Software Solutions

Zeutschel GmbH| Heerweg 2 | 72070 Tübingen | Deutschland
p: +49 (7071) 9706-56 | m: | f: +49 (7071) 9706-44
e: Frank-Ulrich.Weber@zeutschel.de | w: http://www.zeutschel.de

Geschäftsführer/President: Joerg Vogler | Registergericht Stuttgart: HRB 380917

Von:kitodo-community-bounces@kitodo.org<kitodo-community-bounces@kitodo.org>Im Auftrag von Christian Haenger
Gesendet: Mittwoch, 9. Oktober 2019 15:50
An:kitodo-community@kitodo.org
Betreff: Re: [Kitodo] REST-API

 

Hallo Herr Ronge,

 

haben Sie erst einmal vielen Dank für die genaue Auflistung.

 

Ich habe die vier APIs für die Mannheimer Installation abgefragt und habe die folgenden Ergebnisse erzeilt:




http://server.domain.example/kitodo-production/rest/catalogueConfiguration

» Gibt die konfigurierten Katalogschnittstellen und Dokumenttypen aus. Diese Informationen sind analog zu den in opac.xml konfigurierten Informationen.

Das ist nicht relevant für die Fragestellung, Metadaten aus dem System zu exportieren (oder gar zu importieren)


 

http://server.domain.example/kitodo-production/rest/projects

» Gibt die konfigurierten Projekte mit entsprechenden Produktionsvorlagen mit verfügbaren Sammlungen, und Metadatenschlüsseln aus. Die Projekte und Produktionsvorlagen sind diejenigen, die auf dem System vorhanden sind. Die Sammlungen entsprechen der Konfiguration in der collections.xml-Datei, die Metadatenschlüssel entsprechen der Konfiguration in der projects.xml-Datei (wie für das betreffende Projekt konfiguriert).

Das ist nicht relevant für die Fragestellung, Metadaten aus dem System zu exportieren (oder gar zu importieren)

 

http://server.domain.example/kitodo-production/rest/processes

» Listet alle Vorgänge auf dem System auf. Die Vorgänge sind diejenigen, die auf dem System vorhanden sind.

Das beantwortet meine Frage am ehesten. Es werden aber keine  METS-Daten ausgegeben.
Beispiel:

<goobiProcess>

<identifier>52015858X</identifier>

<title>

Arnoldi Clapmari[i] Juris-Consulti, Nobile Triennium

</title>

</goobiProcess>

<goobiProcess>

<identifier>52015875X</identifier>

<title>Salomonis Codomanni ... Vindiciae</title>

</goobiProcess>

Das ist nicht relevant für die Fragestellung, Metadaten aus dem System zu exportieren (oder gar zu importieren)

» Zeigt alle Schritte des Vorgangs mit der angegebenen PPN an. Beachten Sie, dass die PPN der Wert im Feld PPN digital a-Satz bzw. PPN digital f-Satz sein muss, nicht der Vorgangstitel.

 

Würde Zeutschel denn den Kitodo-APIs weiternetwickeln? Gedacht ist daran, über die API zu einem bestehenden Projekt und mit bestehenden Titeldaten aus dem Verbund ergänzend METS-Dateien (z.B. https://digi.bib.uni-mannheim.de/fileadmin/digi/490029922/490029922.xml) nach Kitodo Production zu importieren? Das ist aus meiner Sicht ein echter Mehrwert für Kitodo.

 

Viele Grüße

 

Christian Hänger

 

 

 

 

 

 

-----Ursprüngliche Nachricht-----
Von: kitodo-community-bounces@kitodo.org<kitodo-community-bounces@kitodo.org> Im Auftrag von Christian Haenger
Gesendet: Freitag, 20. September 2019 14:01
An: kitodo-community@kitodo.org
Betreff: Re: [Kitodo] REST-API

 

Hallo Herr Hartwig,

 

ich habe mir fast gedacht, dass die REST-API nur Lesezugriffe erlaubt.

Wir haben ja eine ähnliche Kitodo-Geschichte wie die ULB Halle und sind

2015 von Visual Library auf Kitodo (damals noch Goobi) umgestiegen.

Allerdings haben wir wegen der damals auch noch nicht vorhandenen Exportmöglichkeiten die Alt-VL-Metadaten nicht nach Production importiert, sondern greifen nur mit Presentation darauf zu. Bei einer erneuten Bearbeitung des "Altdatensatzen" muss dann eine erneute Aufnahme in Production erfolgen.

 

Letztlich ist es suboptimal, nicht mit einem System, also Production, zu arbeiten, sondern Workarounds zu schaffen. Aber manchmal geht es nicht anders.

 

Viele Grüße

 

Christian Hänger

 

 

 

Am 20.09.2019 um 13:39 schrieb Uwe Hartwig:

> Hallo Herr Hänger,

> das klingt spannend. Bei uns geht es darum, unsere Strukturierung bei

> der Arbeit so weit es geht zu unterstützen, was ggf. heißt,

> Arbeitsschritte nicht über die Kitodo.Production2 Oberfläche

> durchzuführen, sondern auf anderen Wegen.

> Aktuell erlaubt die REST-API allerdings durchgehend nur Lesezugriffe,

> wobei mir leider das dahinterliegende Modell noch nicht klar ist

> (process vs. prozesse vs. prozesseeigenschaften vs. vorlagen vs.

> vorlageneigenschaften vs. werkstuecke vs. werkstueckeeigenschaften).

> Grüße

> On 20.09.19 13:16, Christian Haenger wrote:

>> Hallo Herr Hartwig,

>> 

>> eine vergleichbare Frage wollte ich auch gerade stellen.

>> 

>> Mein Problem ist, dass die Scanabteilung mehr digitalisierte Werke

>> liefert als die Metadatenabteilung beschreiben kann. Daher denke ich

>> bei Werken aus dem 19. und 20. Jahrhundert über eine Automatisierung nach.

>> Wir digitalisieren in Mannheim Fortsetzungswerke, deren Aufbau über

>> mehrere Ausgaben hinweg immer gleich bleibt. Das sind z.B.

>> Hoppenstedt Handbuch der Aktiengesellschaften. Daher denke ich

>> darüber nach, die Inhaltsverzeichnisse zu scannen und die Inhalte

>> automatisiert nach XML-DC oder XML-MODS zu überführen. Denkbar wäre

>> dann ein Import über die REST-API nach Production. Anschließend

>> erfolgt dann die manuelle weitere Bearbeitung in Kitodo.

>> 

>> Hat das jemand mal gemacht oder einen anderen Lösungsvorschlag?

>> 

>> In Mannheim haben wir bereits Metadaten und Imgaes automatisiert

>> übernommen, aber nur für Presentation zur Verfügung gestellt. Zuletzt:

>> 

>> Viele Grüße

>> 

>> Christian Hänger

>> 

>> 

>> Am 20.09.2019 um 11:20 schrieb Uwe Hartwig:

>>> Liebe Community,

>>> 

>>> für Kitodo.Production existiert eine REST-API, die in unveränderter

>>> Form auch in Version3 übernommen wurde.

>>> Nutzt jemand aktuell diese Schnittstelle?

>>> Wird diese gepflegt bzw. gibt es Ideen für deren Weiterentwicklung?

>>> 

>>> 

>>> Viele Grüße

>>> 

 

--

Dr. Christian Hänger

Abteilungsleiter Digitale Bibliotheksdienste UB Mannheim

68131 Mannheim

0049 621 181 2954

 

 

 

_______________________________________________

Kitodo-Community mailing list

Kitodo-Community@kitodo.org

https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community




_______________________________________________
Kitodo-Community mailing list
Kitodo-Community@kitodo.org
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community

 

-- 
Dr. Christian Hänger
Abteilungsleiter Digitale Bibliotheksdienste
UB Mannheim
68131 Mannheim
0049 621 181 2954



_______________________________________________
Kitodo-Community mailing list
Kitodo-Community@kitodo.org
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community

 

-- 
Dr. Christian Hänger
Abteilungsleiter Digitale Bibliotheksdienste
UB Mannheim
68131 Mannheim
0049 621 181 2954

_______________________________________________
Kitodo-Community mailing list
Kitodo-Community@kitodo.org
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community


-- 
Dr. Christian Hänger
Abteilungsleiter Digitale Bibliotheksdienste
UB Mannheim
68131 Mannheim
0049 621 181 2954

_______________________________________________
Kitodo-Community mailing list
Kitodo-Community@kitodo.org
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community
-- 
Uwe Hartwig
Anwendungsentwickler IT / Digitale Dienste 

Universitäts- und Landesbibliothek Sachsen-Anhalt
August-Bebel-Straße 13
D - 06108 Halle (Saale)

Fon: + 49 345 55 22 183
Mail: uwe.hartwig@bibliothek.uni-halle.de