FAQs

Frage:  METS Version 2.0 ist angekündigt worden. Berücksichtigen Sie diese?

Antwort: Derzeit nicht, denn diese ist noch nicht veröffentlichtt. Wir bleiben vorerst bei der Version 1.11, aber es gibt Pläne für Verbesserungen im SLUB/DFG-Viewer. Da der DFG-Viewer viele verschiedene METS-basierte Medientypen unterstützt, wollen wir dies nicht nur für 3D-Modelle angehen, sondern für alle unterstützten Medientypen auf einmal.

Frage: Muss ein Projektpartner alle Metadaten-Felder in METS/MODS umwandeln?

Antwort: Dies ist nicht notwendig. Wir planen, nur ein minimales Set von Feldern zu transformieren, die für die Visualisierung und Aggregation wichtig sind. Wir planen auch eine Möglichkeit, die Anbindung an andere Anwendungen zu verbessern. Ein Grundprinzip des DFG-Viewers ist es, so wenig Pflichtfelder wie möglich zu haben, aber viele optionale Felder zu unterstützen.

Frage: Wer war an der ersten Finanzierungsphase beteiligt?

Antwort:  An der ersten Phase des DFG-Viewers waren 3 Projektpartner beteiligt:

  • Friedrich-Schiller-Universität Jena 
  • Hochschule Mainz
  • Sächsische Landes- und Universitätsbibliothek Dresden

Vier externe Partner waren beteiligt, um die Anforderungen aus unterschiedlichen Forschungsbereichen (und die Sammlung unterschiedlicher Modelle) in den DFG-Viewer einfließen zu lassen:

  • LMU München(Prof. Dr. Stefan Hoppe, Kunstgeschichte)
  • BTU Cottbus-Senftenberg (Prof. Dipl.-Ing. Dominic Lengyel, Architektur)
  • Unversität Köln (Prof. Dr. Eleftheria Paliou, Archäologie)
  • Deutsches Museum München (Dr. Georg Hohmann, Technikgeschichte)

Frage: Gibt es eine Ontologie zur einfacheren Datenverbindung mit verschiedenen Repositories?

Antwort: Unser Metadatenschema basiert auf OntSciDoc3D (Anwendungsontologie von CIDOC-CRM) und wird durch Konsultationen mit anderen Repositorien/Infrastrukturen ständig verbessert. Für die zweite Förderphase planen wir eine Aktualisierung unserer Ontologie, da OntSciDoc3D im Vergleich zur aktuellen CIDOC-CRM-Version veraltet ist und nicht mehr alle Themen abdeckt.

Frage: Wie ist der aktuelle Stand des DFG 3D-Viewers?

Antwort: Wir sind derzeit in der Lage, verschiedene Repositorien an den Viewer anzubinden. Wir haben ein prototypisches Repositorium auf Basis von WissKi und Drupal in Mainz. Die dort enthaltenen Metadaten der Modelle werden als XML-Dateien exportiert und dann in METS/MODS konvertiert und so für den DFG-3D-Viewer verfügbar gemacht. Außerdem arbeiten wir an einem Repositorium in Jena, das mit abgerufenen Modellen aus Sketchfab befüllt und ebenfalls an den DFG-3D-Viewer angebunden werden soll.

Frage: Tauschen Sie nur 3D-Daten oder auch Anmerkungsdaten aus?

Antwort: Im Moment werden im DFG 3D-Viewer keine Annotationen ausgetauscht. Die IIIF-Arbeitsgruppe prüft derzeit alle auf dem Markt befindlichen Lösungen, und wir stehen in Kontakt mit ihr. Nach ihrer Einschätzung fehlt ein übergreifender Standard, aber vielleicht kann ein Standard durch die IIIF-Arbeitsgruppe erreicht werden. In einem anderen Projekt arbeitet die SLUB jedoch derzeit an der Visualisierung von Annotationen auf der Basis des W3C Web Annotation Standards im DFG-Viewer, die dann auch auf 3D-Modelle ausgeweitet werden könnte.

Frage: Wie funktioniert der DFG-Viewer?

Antwort: Der DFG-Viewer ist ein öffentlicher Webdienst zur Visualisierung digitaler Objekte aus verschiedenen entfernten Repositorien unter Verwendung internationaler Standards wie METS/MODS und OAI-PMH. Er wird von der SLUB Dresden kostenlos zur Verfügung gestellt und basiert ausschließlich auf Open-Source-Komponenten wie TYPO3 CMS und Kitodo.Presentation, und ist selbst Open Source. Derzeit werden mehrere digitale Medientypen unterstützt (Bücher, Manuskripte, Zeitungen, Bilder, Karten, Audio, Video). Der DFG-Viewer besteht aus mehreren Plugins, die unterschiedliche Aufgaben erfüllen (Analyse und Anzeige von beschreibenden, technischen, administrativen, rechtlichen und strukturellen Metadaten, Bereitstellung eines durchsuchbaren Inhaltsverzeichnisses, Verweis auf das ursprüngliche Repository und alternative Ansichten und - natürlich - Visualisierung des digitalen Objekts selbst in einem interaktiven Viewer). Bei 3D-Modellen nutzt der DFG-Viewer die WebGL-Grafik-Engine moderner Browser, um das Modell clientseitig zu rendern. Der DFG-Viewer speichert keine Metadaten. Er holt lediglich die METS/MODS-XML-Datei aus dem Repository, parst ihren Inhalt, extrahiert den Link zum digitalen Objekt und stellt diesen Link der Viewer-Komponente zur Verfügung. Alle Daten werden vorübergehend in der Sitzung des Benutzers gespeichert und gelöscht, sobald diese Sitzung endet (d. h. der Browser geschlossen wird).

Frage: Ist eine Transformation der Daten im laufenden Betrieb möglich?

Antwort: Es handelt sich eigentlich um zwei Transformationen: Erstens wandeln wir die 3D-Masterformate in GLTF um, um ein kleineres Derivat für die Webpräsentation zu erhalten; zweitens wandeln wir die Metadaten des Objekts in METS/MODS um, um sie dem DFG-Viewer und anderen Aggregatoren zur Verfügung zu stellen. Da die erste Umwandlung relativ zeitaufwändig ist, empfehlen wir, sie durchzuführen, sobald ein neues 3D-Modell in das Repository aufgenommen wird. Die Umwandlung der Metadaten hingegen kann dynamisch erfolgen, sobald sie angefordert wird. Der DFG-Viewer unterstützt beides, eine Transformation on the fly oder die Speicherung der transformierten Daten im Repository. Tatsächlich benötigt der DFG-Viewer nur einen Link, der auf die METS/MODS-Datei für ein digitales Objekt verweist, unabhängig davon, ob diese Datei bei Anforderung dynamisch erzeugt wird oder statisch verfügbar ist. Eine Transformation (statisch oder on-the-fly) muss jedoch im Repository implementiert werden. Wir planen, im Rahmen unserer zweiten Projektphase Unterstützung für die Implementierung von Transformationsroutinen anzubieten.

Frage: Ist es möglich, Metadaten direkt über den DFG-Viewer zu sammeln?

Antwort: Das Sammeln von Metadaten über den DFG-Viewer ist möglich, aber wir benötigen eine Lizenz für die Metadaten. Derzeit unterstützen wir alle CC-Lizenzen. Wir würden alle Repositorien ermutigen, ihre Daten mit einer CC-0-Lizenz bereitzustellen.

Frage: Bieten Sie Speicherplatz für die Modelle an?

Antwort: Nein, wir holen das Modell nur jedes Mal aus dem jeweiligen Repository ab. Für die Indexierung der Modelle aus verschiedenen Repositorien planen wir eine Zusammenarbeit mit der Deutschen Digitalen Bibliothek. Diese wird die Metadaten aus den bereitgestellten METS/MODS-Dateien auslesen (die Deutsche Digitale Bibliothek gibt METS als Standardformat vor, ebenso die DFG in ihren "Praxisregeln Digitalisierung").

Frage: Müssen die Ebenen für die Modelle definiert werden?

Antwort: Es ist nicht notwendig, aber sie können definiert werden. Es gibt die Möglichkeit, die Schnittpunkte der Modelle mit den Schnittebenen anzuzeigen (interaktiv für jede Achse).

Frage: Gibt es Raster- oder Fangpunkte?

Antwort: Ja, das ist in gewisser Weise möglich. Wenn Sie das Werkzeug in der Symbolleiste auf der rechten Seite auswählen und die Maus über einige Teile der Modelle bewegen, können Sie einige Elemente auswählen und diese markieren. Sie können auch verschiedene Punkte auf der Oberfläche des Modells auswählen und den Abstand zwischen den Punkten messen.

Frage: In welchem Teil ist unser Viewer unsere eigene Entwicklung?

Antwort: Wir verwenden die Three.js Bibliothek und nutzen vordefinierte Lader für OBJ, GLTF etc.

Frage: Reicht es aus, einen Link zu einer GLB-Datei innerhalb einer METS/MODS-Datei mit einigen zusätzlichen Metadaten zu versehen?

Antwort: Ja, das würde ausreichen.

Fragen: Ist ein Masterformat erforderlich? Soll das Modell über einen Link adressierbar sein? Sollen alle Modelle nach glTF konvertiert werden? Warum nicht alle Modelle in glTF?

Antwort: Wir wollen das Masterformat nicht ändern, weil wir den Repositories nicht vorschreiben wollen, was sie von den Forschern erhalten bzw. in ihren Repositories verwenden. Wir brauchen nur eine Kopie des Modells im Format GLB/glTF.  Die Repositorien können die von uns entwickelte Pipeline zur Konvertierung ihrer Modelle verwenden oder ihre eigene Pipeline entwickeln. Unsere Pipeline kann die meisten Formate konvertieren (Skripte, die meist in Blender geöffnet werden und andere transformieren/exportieren, keine menschliche Interaktion erforderlich).

Frage: Gibt es eine Qualitätskontrolle des Konvertierungsprozesses?

Antwort: Nein, im Moment nicht. In der Tat bereiten wir eine grundlegende Komprimierung durch den Draco-Algorithmus vor, aber wir verwenden die Standard-Komprimierungsstufe für jedes Modell.

Frage: Ist eine OAI-PMH-API wirklich erforderlich?

Antwort: Nein, jedes Repository kann seine eigenen APIs/Werkzeuge verwenden. Die einzige Anforderung an den DFG-Viewer ist, URLs für die METS-Dateien und GLTF-Derivate zu haben. Diese können statische Links sein oder auf eine API wie OAI-PMH verweisen. Da jedoch ein Großteil der Infrastruktur rund um den DFG-Viewer, die Deutsche Digitale Bibliothek und die DFG-Praxisregeln Digitalisierung auf OAI-PMH basiert, empfehlen wir dringend die Implementierung einer OAI-PMH-Schnittstelle.

Frage:  Wenn Sie XML für die Speicherung der Anmerkungen und Metadaten der 3D-Modelle verwenden, werden die Dateien sehr groß. Wie gehen Sie damit um?

Antwort: Große XML-Dateien stellen kein Problem dar, da sie im Vergleich zur 3D-Modelldatei immer noch relativ klein sind. Wir kodieren jedoch keine Anmerkungen in der METS/MODS-Datei, sondern nur eine Untergruppe von beschreibenden, administrativen, rechtlichen und einigen technischen Metadaten. Das 3D-Modell selbst ist nicht in XML eingebettet, sondern nur von METS aus verlinkt.

Frage: Gibt es eine Grenze für die Größe eines 3D-Modells? Wie geht man mit großen Dateien im DFG-Viewer um?

Antwort: Es gibt keine technische Grenze, aber die Ladevorgänge werden länger dauern. Wenn die Dateien der 3D-Modelle zu groß werden, können Repositorien und Anbieter von Dateien selbst entscheiden, ob sie die Daten komprimieren oder die Komplexität der bereitgestellten Derivate reduzieren wollen. Es kann mehr recherchiert werden, indem von Hand vorbereitete Level of Details verwendet werden, die durch GLTF-Erweiterungen implementiert werden, oder indem Dateien mit mehreren Auflösungen geliefert werden, die durch Draco-Kompression erzeugt wurden.