Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepositorien

http://www.laudatio-repository.org

1

LAUDATIO-Workshop

Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepositorien

Technische (Weiter-)Entwicklung LAUDATIO-Repository für

historische Textkorpora 8. Oktober 2014, Berlin

Dennis Zielke Computer- und Medienservice, Humboldt-Universität zu Berlin, 8. Oktober 2014


2

$whoami

Dennis Zielke LAUDATIO-Repository Entwickler

Source code auf Github: https://github.com/DZielke/laudatio

Weitere Projekte:

http://repositoryranking.org/

http://de.linkedin.com/pub/dennis-zielke/


https://github.com/DZielke/laudatio

http://repositoryranking.org/


3

TEI XML P5 Komplexe Datenstruktur

Deutsche historische Texte und ihre linguistischen Annotationen einschließlich aller Dialekte vom 9. bis 19. Jahrhundert • Metadaten zum Korpus • Dokumente • Annotationen • Bearbeitungsschritte



4

Repository-Architektur



5

• CakePHP 2.4-Framework • Fedora 3.6 für die Datenhaltung und Speicherung

• Fedora REST-Schnittstelle zum Datenaustausch • ElasticSearch als Suchengine

• REST-Schnittstelle zum Datenaustausch • Externer PID-Webservice zur Verwaltung der Persistent Identifier

(handle) • Third party Open Source libraries auf Github

• http://tinyurl.com/lf26u97 • Flat-Design (HTML5, CSS3) work in progress

Open-Source-Technologien



6

• Technische Infrastruktur: • 2 Virtuelle Maschinen • Ubuntu 14.04 • jeweils 2 CPUs und 12 GB RAM Arbeitsspeicher (skalierbar) • Ausfallsicherheit durch Monitoring mithilfe von Nagios am

CMS • Versionsverwaltungssystem: Git

• verschiedene nützliche Tools z. B. Git Bash und GitWeb

Entwickeln/Testen/Prüfen



7

• Entwicklungsumgebung: PhpStorm 7.1.3 • Ticketsystem: Redmine • ES-HEAD-PlugIn: Testen von Mapping, Facetten, Nested Facets • FedoraAdmin Client: Testen und Prüfen der Datastreams in Fedora

Entwickeln/Testen/Prüfen



8 Dennis Zielke Computer- und Medienservice, Humboldt-Universität zu Berlin, 8. Oktober 2014


9

Module: • Anbindung an externen PID-Webservice

• Datenhaltung im Fedora-Repository

• GUI-Client für die Suche

• Erweiterbares IndexMapping für ElasticSearch und automatische Schema-Validierung • nutzbar für weitere Formate

• Einbindung Frontend-Editor für Redakteure

• Adminbereich • Nutzermanagement • Authentifizierung LDAP, HTTP-Login • Konfiguration

Nachnutzungsmöglichkeiten



10

• Anbindung an das HU-Medienrepositorium via API-Upload Plugin • Implementierung eines Metadateneditors • Migration von Fedora 3.6 zu Fedora 4 • Unterstützung weiterer Metadatenformate, je nach Bedarf der

jeweiligen Disziplin • Bereitstellung einer OAI-PMH Schnittstelle zur Anbindung an

externe Datenaggregatoren

Ausblick



11

Vielen Dank!

E-Mail: [email protected]


mailto:[email protected]



Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden slub-dresden.de

Aufbau eines Cross Media Repository

Qucosa Project

https://creativecommons.org/licenses/by/4.0/

http://www.slub-dresden.de/




$ whoami

2014-09-19, Fedora User Group Meeting

Ralf Claussnitzer Sächsische Landesbibliothek – Staats- und Universitätsbibliothek

Dresden (SLUB)

IT Abteilung seit 2008

Software Entwicklung und -Architektur

WWW

• @claussni

• github.org/claussni

•

Ralf Claussnitzer | @claussni





Ausgangspunkt


Institutionelles Repositorium Qucosa Mandantenfähig

• Universitäten, Hochschulen, Forschungsinstitute, Bibliotheken

Basierend auf OPUS 4 und TYPO3 • Two-Tier: Web Service Backend + CMS Frontend

− Einfache IR Software

− Komplexes Content Management System

Status Quo • End-Of-Project = End-Of-Resources

• Veraltetet PHP Codebasis

• Nachfrage nach neuen/zeitgemäßen Features

• Resource Discovery System hat Recherchemaske nicht abgelöst


Vorführender

Präsentationsnotizen

SLUB startet mit Hochschulschriftenserver (HSSS) Tomcat Webapp Implementiert von engagierten Studenten (3 Generationen) Ohne Beteiligung der IT Wissen verlässt das Haus zusammen mit den Studenten 2008 Entscheidung zur Neuentwicklung Enge kooperation mit OPUS 4 Projekt (Neuentwicklung OPUS 3) SLUB bringt sich intensiv ein (obwohl nicht Projektpartner) Projekt wird nicht fristgemäß fertig SLUB setzt Qucosa mit leicht abgewandeltem OPUS 4 Ansatz um Ende des Projektes Neue (und alte) Anforderungen kommen auf Technologische Erneuerung notwendig Neustart Verschiedene Projekte werden Evaluiert (Dspace, Eprints, Fedora…) Entscheidung für längerfristiges Entwicklungsprojekt mit Ziele eines Medienübergreifenden Repositoriums





Gesamtlösung für alle Digitalen Objekte - 1


Anforderungen Hochschulschriftenserver Entwicklung von Pre-Print, über Post-Print-Volltext zu Gold Open

Access

Fokussierung auf Dissertationen im PDF Format

Sekundär auch Bilder und Tondokumente, DVD

Oft Einbettung in Webseiten der Universität

Integration mit anderen System „drangestrickt“

Anforderungen der DNB OAI-PMH

Spezielles Protokoll mit inhaltlichen Aspekten: xMetaDissPlus

Pflichtexemplarrecht und Administrative Workflows


Vorführender


Beispiel Ablieferungsform für Harvesting: OAI, schön und gut, aber: XML und XSLT allein bringts nicht Genau eine Transfer-URL, sonst ZIP-Datei Ausdruckbar, Analysierbar - im Fall von PDF-A – Archivierbar Anforderungen der Katalogisierung (Verbund und DNB) Rechteübertragung verhältnismäßig unkompliziert Althergebrachte Integrationsmuster „Dranstricken“ ist kein Intergrationsmuster Keine Services, keine Schnittstellen Anpassungen am Quelltext (daher primär Webtechnologien mit geringer Einstieghürde, wie PHP MYSQL…) (!) Infos zum Pflichtexamplarrecht und Open Access im Anhang







Digitalisate Behandlung bisher getrennt von Repositorien in „Digitalen

Sammlungen“ und Bilddatenbanken

Born Digitals und Retrodigitalisiate teilen sich viele Eigenschaften (URIs, Dateien, Präsentation im Web)

Datenqualität deutlich homogener (Bilder, Beschreibungsformate wie METS/MODS)

Metadatenerfassung meist ausreichend standardisiert


Vorführender


Digitalisate im Repository? Ja, weil: Digitales Objekt (Born Digital oder Digital Reformatting aka Retrodigitalisate) Technologisch im Grunde kein Unterschied DFG Richtlinien haben zu eingehender Standardisierung in diesem Bereich geführt Zu Beachten: Behandlung von Digitalisaten auf Grund ihrer Größe deutlich teurer, Synergien in der Administration helfen Aufwand insgesamt zu verringern







Sammlung vs. Langzeitarchivierung Möglichst umfassende Sammlung von Netzpublikationen erfordert

Verringerung der (technischen) Qualitätsanforderungen

(echte) Langzeitarchivierung erfordert aber hohe Qualität

Umwandlung nicht immer möglich (oder erlaubt)

Definition von Service Levels Nutzer schon bei der Abgabe Informieren


Gute Archivierbarkeit

Schlechte Archivierbarkeit

Keine Archivierbarkeit

Vorführender


LZA richtig betrieben erfordert Qualitätsabwägung LZA wird häufig mit „So lange wie es eben geht aufheben“ oder „nicht aktiv löschen“ gleichgesetzt Sehr falsch. Qualitätsstandards können nicht beliebig gesetzt werden, wenn Pflichtabgabe pragmatisch betrieben werden soll LZA Ampelsystem Den Nutzer schon bei der Abgabe über den bereitstellbaren Service Level informieren Schlussfolgerung für den Export ins Archivierungssystem Prüfung durch Programme wie JHove (Dienste, bereitgestellt vom LZA System)�http://www.dcc.ac.uk/resources/external/jhove2





Perspektiven


Born-Digitals und Retrodigitalisate gleichartig behandeln Digitale Objekte mit Metadaten und Anhängen

Metadatenstandards voll ausnutzen Weg von Bibliothekarisch (/Katalog-) orientierten Datenbankschemata

Organisatorisch-Technische Vorteile Verringerung der Systemvielfalt

Weniger Technologien; Mehr Transparenz


Vorführender


Born-Digitals und Digitalisierungen zusammenlegen und gleichartige Objekte auch gleichartig behandeln Beide Präsentationswelten profitieren voneinander Erweiterbarkeit: Metadatenstandards voll ausnutzen Behandlung sehr großer Dateien > 300Mb > 1Tb (Übertragung aus technischen Gründen oft beschränkt, Alternative aktiver Download) DRM Check, Einschätzung der Archivierbarkeit, Transparente Erklärung zu den Gründen, Möglicherweise Anpassung bei der Dokumenterstellung Nutzungseinschränkung: Allg.: Durchsetzen der Lizenzbestimmung. (In einigen Fällen nicht mit vertretbarem Aufwand zu realisieren) Organisatorisch-Technische Vorteile ausnutzen Nicht mehrere Backendsysteme einsetzen (z.B.: mehrere unterschiedliche Implementationen des OAI Protokolls, ) Funktionen der Digitalen Sammlungen nachnutzen Klare Einteilung: Stichwort „Digitalisierung von Hochschulschriften“ (Digitalisiat+Hochschuldokument)





Warum Fedora?


Fedora fokusiert auf Infrastruktur Out-of-the-box Software fokussiert IR Anwendungsfälle und GUI

• Hohes Abstraktionsniveua

Loose gekoppelte Dienste als Systemmodell

Speicherung unabhängig vom Metadatenschema

Unsere Anforderungen Weiterentwicklung des Metadatenschemas

Vielzahl an Medientypen

Veraltetet Speicherinfrastruktur • Vollständige Migration ist keine Option

• Möglichkeit von irreperablen Inkonsistenzen


Vorführender


Fedora ist „bare bones“ Datenbanksystem Repository Anwendungsfälle werden erst durch Einbindung in Frontend-System nutzbar Frontendsysteme leisten den größten Teil der Umsetzung Fedora ein gutes Basissystem für Datenhaltung Fedora ist ein bekanntes System Aktive Community und Entwicklung (SLUB Neuland!) Konzept auf Service Architekturen ausgelegt (main selling point) Idee: Stabiler Kern Umsetzung der Anwendungsfälle durch lose gekoppelte Dienste Unser Ziel: Born-Digital und Retro-Digitalisate zusammen verwalten Nachnutzung verwandter und ähnlicher Programmteile (z.B. OAI, Datenhaltung, Konsistenzprüfung, LZA-Support…) Anforderung an das Metadatenschema: Flexibel vs. Standardisiert (OPUS4 DB Ansatz erreicht das nicht)





Architekturansatz - 1


Fedora

API-A OAI

API-M JMS

SWORD

API

Elasticsearch

River

API

OAI

Proai 1

Proai 2

Proai …n

Internet TYPO3

Presentation Administration

Services

…


Vorführender


Repository Software vs. Repository Schicht Repository Aufgaben wie Speicherung, Referenzierbarkeit, Auslieferung, Transformationen durch Services umgesetzt Repository hat je nach Objekt die Aufgaben: Datenspeicher oder Registry (für alle: Schnittstellen) Datenspeicher Sichere Aufbewahrung und schnelle Bereitstellung verschiedener Daten (-formate) Enthält auch Dienst-Konfigurationen (damit Unterstützung der Versionierung) (!) Mittlerweile Veraltete Fedora Dienste müssen teilweise erweitert werden Registry Für Datenbestände, die woanders besser aufgehoben sind bzw. nicht migriert werden können Schnittstellen API ist gut, aber F4 API ist besser als F3 Weitestgehende Verwendung von Standards für Zugriff (SWORD, OAI, ATOM) realisiert durch Services Vorhandene Services müssen ertüchtigt werden (F4: einige müssen noch konzipiert und entwickelt werden)





Architekturansatz - 2


Weitere Verbesserungen Konsequente Verwendung von Message Bus Konzepten

• SOA mit Microservices

Ablösung des Elasticsearch River Index • ES Rivers werden nicht mehr unterstützt

Apache Camel / SLUB d:swarm Projekt • Datentransformation

• Nachrichten Routing

Fedora 4.x • Workspaces (Entwürfe)

• Hierarchische Datenbank

• Federated Storage


Vorführender


Idealarchitektur noch nicht erreicht Weitere Fokussierung auf Services Fedora unterstützt Messaging Suchindex auf Basis von Elasticsearch River Plugin Neuimplementierung notwendig, das River Plugins nicht mehr unterstützt werden (Developer Buschfunk) Rivers ein guter Start, aber: auf Services setzen passt besser ins Konzept Messaging und Transformation Workflows Asynchrone Behandlung von Objekten Einfaches Einbinden neuer Funktionen, aber: Konsistenzeigenschaften in Gefahr SLUB d:swarm Projekt soll perspektivisch dafür eingesetzt werden Fedora 4 Zukunft des Fedora Projektes Interessante Features für Mandantensysteme





Stand der Entwicklungen

09.10.2014

Fedora 3.8.0-RC1 als Repository Generisch, Schemaunabhängig

ElasticSearch 1.2.x Cluster-fähiger Suchindex (Lucene Core, REST API)

Indexierung der Daten mit Fedora River (Eigenentwicklung)

Fedora 4 nächster großer Schritt, aber: Fundamental anderes Konzept

Migration von Fedora 3.x erst mit Fedora 4.1 geplant

Generisches Messaging und Application Integration SLUB Datenmanagement Plattform d:swarm für Suchindex

Ralf Claußnitzer, IT SLUB, (@claussni)

Vorführender


Prototyp implementiert Fedora als Chance und Herausforderung Produktivsetzung Mitte des Jahres Dann kontinuierliche Weiterentwicklung (Antragstellung geplant, Perspektive ungewiss) Qucosa Legacy API War ursprünglich als Migration-Layer geplant wird zu Gunsten einer TYPO3 Frontend Entwicklung abgelöst Externe Beauftragung; erste Ergebnisse sind im Test Intensivierter Einsatz Apache Camel und Apache ActiveMQ Hinarbeiten auf Service Architektur Generisches Messaging und Application Integration (SLUB Datenmanagement Plattform d:swarm für Suchindex)





Nachnutzung der Ergebnisse


Open Source Projektergebnisse auf GitHub

https://github.com/slub

Lizensierung GPLv3

• TYPO3 Frontend

Apache License 2.0 • Fedora Komponenten; Java Services

• Elasticsearch River

Andere Open Source Lizenzen • Für Erweiterungen bestehender Fedora Commons Dienste


Vorführender


Entwicklung konsequent Open Source Repository Services von Anfang an auf GitHub Fedora Erweiterungen, Elasticsearch Plug-Ins…, Fedora Content Model und Disseminations… TYPO3 Entwicklung Auftrag an externe Firma Freigabe der Quellen nach Auftragsabschluss, dann Weiterentwicklung Generische Entwicklungen sollen in Fedora einfließen - Hauptsächlich Bug fixes und Anpassungen für Deutsche Anwendungsfälle




https://github.com/slub


Thanks! Questions?


Gesamtlösung für alle digitalen Objekte

09.10.2014 Ralf Claußnitzer, IT SLUB, (@claussni)

Anforderung: Open Access Publishing Plattform

• Weniger qualifizierte erschlossene Beiträge bedeuten mehr Aufwand für die Bearbeiter, mehr Nachfragen, mehr Änderungen

• Unter Umständen müssen Publikationsanfragen abgelehnt werden (keine Thematische Einschränkung, aber inhaltliche)

• Unklare Lizenzsituation bzw. Patentsituation kann zum Veranlassen einer Sperrung führen

• Häufig müssen Embargofristen beachtet werden (Konflikt mit Abgabe und Ablieferungspflicht DNB)

• Neue Veröffentlichung -> neue bibliothekarische Metadaten (schwierig bei einfachen Datenbankkonstruktionen)

• Dubletten (Erkennung? Repository muss potentielle Kandidaten finden und den Administratoren vorschlagen)

Vorführender


Hochschulschriften erfüllen bereits einen hohen Qualitätsstandard (bibliothekarisch) Abgabepflicht erhöht den Druck, sich mit den Bedingungen des Repositoriums auseinanderzusetzen Unklare Lizenzsituation bzw. Patentsituation kann zum Veranlassen einer Sperrung führen (->im Hochschulkontext selten, vielleicht Plagiat)







Anforderung: Elektronische Pflichtexemplare (1)

• Gesetzliche geforderte Abgabe aller elektronisch Publikationen an die Bibliothek

• Basis: Pflichtexemplarrecht

„Zweck des Pflichtexemplarrechtes ist heute vorrangig die möglichst vollständige Archivierung aller Veröffentlichungen eines Landes als Zeugnis des kulturellen Schaffens, ihre bibliografische Dokumentation und die Zugänglichmachung für die Allgemeinheit. Die Bibliotheken sind deshalb gesetzlich dazu verpflichtet, Pflichtexemplare auf unbegrenzte Zeit aufzubewahren und eine Nationalbibliographie zu erstellen.“

(*) http://de.wikipedia.org/wiki/Pflichtexemplar

Vorführender


Pflichtexemplarrecht greift nicht in diesem Umfang für elektronische Dokumente. Hier gibt es Einschränkungen.








§ 7 Beschaffenheit von Netzpublikationen und Umfang der Ablieferungspflicht

(1) Unkörperliche Medienwerke (Netzpublikationen) sind in marktüblicher Ausführung und in mit marktüblichen Hilfsmitteln benutzbarem Zustand abzuliefern. Eine Pflicht zur Ablieferung besteht nicht, wenn die Ablieferungspflichtigen im Rahmen des § 16 Satz 2 des Gesetzes über die Deutsche Nationalbibliothek mit der Bibliothek vereinbaren, die Netzpublikationen zur elektronischen Abholung bereitzustellen. Für die Ablieferung von Netzpublikationen gilt § 2 Abs. 3 entsprechend; für die Bereitstellung zur elektronischen Abholung gilt § 2 Abs. 3 Satz 1 entsprechend.

(2) Die Ablieferungspflicht umfasst auch alle Elemente, Software und Werkzeuge, die in physischer oder in elektronischer Form erkennbar zu den ablieferungspflichtigen Netzpublikationen gehören, auch wenn sie für sich allein nicht der Ablieferungspflicht unterliegen. Dies gilt insbesondere für nicht marktübliche Hilfsmittel, die eine Bereitstellung und Benutzung der Netzpublikationen erst ermöglichen und bei den Ablieferungspflichtigen erschienen sind. Sie sind zusammen mit den Netzpublikationen abzuliefern oder zur elektronischen Abholung bereitzustellen.

http://www.gesetze-im-internet.de/pflav/__7.html

Vorführender


Ablieferung von Software?








• Nicht nur Open Access Publikationen

• Portale mit unterschiedlich lizensiertem Inhalt

• Formatqualität? Archivierbarkeit?

• Rechtliche Bedingungen? Keine freie Verfügbarkeit bei gleichzeitiger Ablieferungspflicht über öffentliche Schnittstellen?

• Wie dem Pflichtexemplar-Gesetz genügen? • Bibliothek kann Veröffentlichung im archivierbaren Format fordern,

aber diese Forderung durchzusetzen ist oft nicht praktikabel • Schulung und Hilfe anbieten

Vorführender


Was da auf Repositorien zu kommt ist noch nicht genau absehbar. Unter Umständen Widersprüchlich bei Abgabe





Vorhandene Workflows vernetzen


• Workflows zur Bearbeitung von elektronischen Publikationen meist sehr individuell und Erfassungs-fokussiert

• Werkzeuge sind entsprechend spezialisiert

• Workflows für Digitalisate auf Durchsatz optimiert -> ohne Automatisierung ist dem Aufkommen eines Digitalisierungszentrums nicht beizukommen

• Produktion der digitalen Objekte unterschiedlich. Verwaltung und Präsentation hingegen sehr ähnlich!

• Technische Workflows: − Archivierung, Backup, Migration, Datenhaltung, Bereitstellung





Verschiedene Präsentationsformate


• Liegen digitale Objekte in bekannten Formaten vor, können automatische (on-demand) Umwandlungen erfolgen, z.B. PDF als ePUB ausliefern

• Digitalisate werden bereits in herunterladbaren PDFs angeboten

• Inhaltsverzeichnisse, wenn Strukturmetadaten das hergeben

• Weiter denkbar: − Video Anzeige − Bildvorschau (Thumbnails) − Audio Streaming − OCR Text Einbettung

Vorführender


Wichtig auch: Such- und Browsingmöglichkeit / Anzeige sind unterschiedlich je Medientyp Das alles zu entwickeln, sollte idealerweise nicht nur den jeweiligen Portalen zu Gute kommen. Idee: DFG Viewer in diese Richtung weiterbauen?




Fedora4- Open Annotation FrameworkDulip Withanage - University Library Ruprecht-Karls University, Heidelberg

Software Entwicklergithub:https://github.com/withanage/

Projekte:

https://github.com/withanage/annotations-reader

https://github.com/withanage/HEIDIEditor

https://github.com/eXist-db/tamboti







Digitalisierung Prozess-Status ● Digitalisierte Sammlungen

○ http://digi.ub.uni-heidelberg.de/diglit/cpg848/0390?template=ubhd● DWork - Erfassung von Digitale Metadaten● Diglit : Präsenstationsmodul

● Webbasiert● Läuft in Apache Server mit Perl CGI Skripte● Backend ist ein mysql Datenbank

http://digi.ub.uni-heidelberg.de/diglit/cpg848/0390?template=ubhd

http://digi.ub.uni-heidelberg.de/diglit/cpg848/0390?template=ubhd

Digitalisierung - Anforderungen

● Erstellung Annotation durch Forscher● Importieren komplexer Annotationen von unterschiedlichen Disziplinen● Kommentare funktionen für alle● Bild-teile Annotationen● Erstellung beliebiger Relationen zwischen mehrere Annotationen.● Interface soll multi-geräte unterstützen● Suche● Indizierung in solr index● Annotationen müssen in andere Programme integrierbar sein● Langzeitarchivierung

Fedora 4 für Annotationen● Repository (Daten & Metadaten)● Rest Schnittstelle● namespaces● Suche● Authentifizierung

http://digi.ub.uni-heidelberg.de:8080/fedora/rest/de/uni-heidelberg/ub/digi/diglit

http://digi.ub.uni-heidelberg.de:8080/fedora/rest/de/uni-heidelberg/ub/digi/diglit

http://digi.ub.uni-heidelberg.de:8080/fedora/rest/fcr:namespaces

http://digi.ub.uni-heidelberg.de:8080/fedora/rest/fcr:namespaces

Fedora 4 Status● In Entwicklung (bis 2016)● Beta Version 3● Aber stabil ● Standalone & in Container

○ Tomcat Java Servlet Engine

Fedora 4 Eigenschaften● Importieren und Exportieren in jcr/xml

Format (java content repository specification)

● JCR - Daten als Baumstruktur für Knoten○ single- und multi-value properties Link○ Schema Unterstützung

http://digi.ub.uni-heidelberg.de:8080/fedora/rest/beispiel/0001/1

Open Annotation Datenmodel

Open Annotation Daten-definitionin turtle format

PREFIX dc: <http://purl.org/dc/elements/1.1/>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

<> dc:format "text/html" .

<> dc:title "Mein Titel" .

<> a oa:Annotation ;

oa:hasBody _:oa_tag1;

oa:hasSource <digi:/cpg848/0390> ;

dc:description“ Weit hinten, hinter den Wortbergen, fern der Länder ….” .

_:oa_tag1 a oa:SemanticTag ;

oax:hasSemanticTag gnd:118529579 ;

oa:hasBody "Einstein, Albert";

oa:hasTarget _:oa_body .

Technische Zusammenfassung Annotation Struktur = Sammlung Struktur.

http://digi.ub.uni-heidelberg.de:8080/fedora/rest/de/uni-heidelberg/ub/digi//diglit/cpg848/0390/

● Per fcr:export werden alle Annotationen zu einem Bild exportiert. http://digi.ub.uni-heidelberg.de:8080/fedora/rest/de/uni-heidelberg/ub/digi//diglit/cpg848/0390/fcr:export

● XML Datei wird in einem json Objekt umgewandelt.● Mit Hilfe von einem Angular Script wird die Darstellung realisiert.● Bildausschnitten - HTML5 Canvas ● Authentifizierung

○ über Shibboleth Server werden die Server verzeichnisse geschützt.



http://digi.ub.uni-heidelberg.de:8080/fedora/rest/de/uni-heidelberg/ub/digi//diglit/cpg848/0390/fcr:export

Vielen Dank!

[email protected]

