DFG-Viewer

Question:  METS Version 2.0 has been announced. Do you take it into account? 

Answer: Actually not, because it is not finished right now. For the moment we will stay with Version 1.11, but there are plans for improvement in SLUB/DFG-Viewer. Since the DFG-Viewer supports many different METS-based media types, we don’t want to address this just for 3D models, but for all supported media types at once.

Question: Does a project partner need to transform all fields into METS/MODS?

Answer: This is not necessary. We are planning to just transform a minimal set of fields which are important for visualization and aggregation. We are also planning a possibility for enhancing the connection with other applications. A fundamental principle of the DFG-Viewer is to have as few mandatory fields as possible while supporting many optional fields.

Frage: Who was involved in the first funding phase?

Antwort:  The first phase of the DFG Viewer consisted of 3 project partners:

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

Four external partners were involved in order to incorporate demands from different research fields (and collecting different models) into the DFG Viewer:

• Ludwig-Maximilian-Universität Munich (Prof. Dr. Stefan Hoppe, Art History)
• Brandenburgische Technische Universität Cottbus-Senftenberg (Prof. Dipl.-Ing. Dominic Lengyel, Architecture)
• Universität Cologne (Prof. Dr. Eleftheria Paliou, Archaology)
• Deutsches Museum Munich (Dr. Georg Hohmann, History of Technology)

Question: Is there an ontology for easier data connection to different repositories?

Answer: Our metadata scheme is based on OntSciDoc3D (application ontology of CIDOC-CRM) and is constantly being improved through consultations with other repositories/infrastructures. For the second phase we are planning to update our ontology, since OntSciDoc3D is outdated comparing to the current CIDOC CRM version and not fully cover all issues.

Question: What is the current status of the DFG 3D-Viewer?

Answer: We are currently able to connect various repositories to the Viewer. We have a prototype repository based on WissKi and Drupal in Mainz. The models’ metadata contained there is exported as XML files and then converted into METS/MODS and thus made available for the DFG 3D Viewer. We are also working on a repository in Jena, which will be filled with retrieved models from Sketchfab and also connected to the DFG 3D Viewer.

Question: Are we just sharing 3D data or also sharing annotation data?

Answer: Right now we are not sharing any annotation in DFG 3D-Viewer. The IIIF Work Group is currently assessing all solutions on the market and we are in contact with them. Based on their assessment, an overarching standard is missing, but maybe a standard can be achieved through the IIIF Work group. However, in another project SLUB is currently working on visualizing annotations based on the W3C Web Annotation Standard in the DFG Viewer, which could then be extended to 3D models as well.

Question: How does the DFG Viewer work?

Answer: The DFG Viewer is a public web service for visualizing digital objects from different remote repositories using international standards like METS/MODS and OAI-PMH. It is provided by SLUB Dresden to anyone free of charge and is based solely on open source components like TYPO3 CMS and Kitodo.Presentation, and is in fact open source itself. Currently multiple digital media types are supported (books, manuscripts, newspapers, images, maps, audio, video). The DFG Viewer consists of multiple plugins, which do different things (parse and display descriptive, technical, administrative, legal and structural metadata, provide a browsable table of contents, reference the original repository and alternative views, and - of course - visualize the digital object itself in an interactive viewer). For 3D models the DFG Viewer uses the WebGL graphics engine of modern browsers to render the model on the client-side. The DFG Viewer is not storing any metadata. It just fetches the METS/MODS XML file from the repository, parses its contents, extracts the link to the digital object and provides this link to the viewer component. All data is temporarily stored in the user’s session and deleted as soon as this session ends (i. e. the browser is closed).

Question: Is transformation of the data on the fly possible?

Answer: There are actually two transformations involved: first, we transform the 3D master formats into GLTF in order to get a smaller derivative for web presentation; second, we transform the object’s metadata into METS/MODS in order to provide it to the DFG Viewer and other aggregators. Because the first transformation is reasonably time-consuming, we generally advise to do this as soon as a new 3D model gets ingested into the repository. The transformation of the metadata on the other hand can be done dynamically whenever it is requested. The DFG Viewer supports both, a transformation on the fly or storing of transformed data in the repository. In fact, the DFG Viewer just needs a link which references the METS/MODS file for a digital object, regardless if this file gets generated dynamically when requested or is statically available. However, transformation (static or on-the-fly) has to be implemented in the repository. We plan to offer support for implementing transformation routines as part of our second project phase.

Question: Is it possible to harvest metadata directly via the DFG Viewer?

Answer: Harvesting of metadata via the DFG Viewer is possible,  but we need some license for the metadata. Currently we support all CC licenses. We would encourage all repositories to provide their data with a CC-0 license.

Question: Do we provide storage for the models?

Answer: No, we will just fetch the model every time from the specific repository. For indexing the models from different repositories we are planning to work together with the Deutsche Digitale Bibliothek. They will harvest the metadata from the provided METS/MODS files (German Digital Library sets METS as default format and also the DFG in their “Praxisregeln Digitalisierung”).

Question: Should the layers for the models be defined?

Answer: It is not necessary, but they could be defined. There is a possible option to show the intersections of the models with clipping planes (interactive for any axis).

Question: Are there grid or snap points?

Answer: Yes, it is possible in some way. If you select the tool in the toolbar on the right and move the mouse over some parts of the models, you can pick some elements and select them. Also you can pick different points on the surface of the model and can measure the distance between the points.

Question: In which part is our viewer our own development?

Answer: We are using the Three.js library and use predefined loaders for OBJ, GLTF etc.

Question: Is it enough to provide a link to a GLB file inside a METS/MODS file with some additional metadata?

Answer: Yes, that would be enough.

Questions: Is there any masterformat needed? Should the model be addressable via link? Should all models be converted to glTF? Why not all models in glTF?

Answer: We don’t want to change the masterformat, because we do not want to tell the repositories what they receive from researchers/use in their repositories. We just need a copy of the model in the format GLB/glTF.  Repositories can use our developed pipeline to convert their models or develop their own pipeline. Our pipeline can convert most formats (scripts mostly opened in Blender and transform/export others, no human interaction needed).

Question: Is there any quality control of the conversion process?

Answer: No, not right now. In fact, we are preparing basic compression by the Draco algorithm, but we are using the default level of compression for every model.

Question: Is a OAI-PMH API really needed?

Answer: No, every repository can use their own APIs/tools. The only requirement for the DFG Viewer is to have URLs for the METS files and GLTF derivatives. Those can be static links or point to any API like OAI-PMH. However, since most of the infrastructure around the DFG Viewer, the Deutsche Digitale Bibliothek and the DFG “Praxisregeln Digitalisierung” is based on OAI-PMH we highly recommend implementing an OAI-PMH interface.

Question:  If using XML for storing the annotations and metadata of the 3D models, the files will become very large. How do you deal with that?

Answer: Large XML files are not of any concern, since they are still reasonably small compared to the 3D model file. However, we do not encode annotations in the METS/MODS file, but only a subset of descriptive, administrative, legal and some technical metadata. The 3D model itself is not embedded in XML, but only linked to from within METS.

Question: Is there a limit for the size of a 3D model? How do you deal with big files in the DFG Viewer?

Answer: There is no technical limit, but loading processes will take longer. If the files of the 3D models become too big, repositories and providers of files can decide on their own if they want to compress the data or reduce complexity of the provided derivatives. It can be researched more by using hand-prepared Level of Details implemented by GLTF extensions or by delivering multi-resolution files generated by Draco compression.