Keeping Data Alive Supporting reuse & repurposing of 3D data in the humanities

Evaluation: Research Outcomes for Infrastructure Design

Successes

The KDA project successfully designed an alpa 3D repository to ingest, host, deliver,and retrieve 3D models linked to metadata, paradata, and descriptive data that can be visualized and edited in an open source 3D visualization environment with changes tracked by the repository. The repository has three main components that work together for the preservation and access of 3D procedural models. The repository back end has repository services that assign metadata and storage services (a PostgreSQL database)that stores 3D model geometry, metadata and paradata. The front end API interfaces directly with the back end to call up 3D scenes to be visualized and modified on an open source 3D Web Viewer. Importantly, the original metadata and paradata as well as any new changes made by users are captured and stored by the KDA repository. Additionally, while not implemented, the system can be easily customized to assign DOIs to each 3D object and scene to allow for citability.

Guidance for the creation of an appropriate repository is available through this report. Workflow #2 provides instructions to help set up the repository environment on your own development machine or server that will import the 3D procedural models using the export_to_kda.py script.The repository supports RDF--a key component of linked data--for describing both metadata and structure and any repository package that supports RDF for describing both metadata and structure and fulfills the above requirements, can be customized using the KDA infrastructure and scripts. The use of Fedora's native API system is appropriate for initial development, and leaves the choices of repository interface for a production version open to future development.

Challenges

While the approach we developed works to link derivations of objects and scenes, robust implementation remains a challenge. A basic demonstration form, has been created for scene ingest that demonstrates the tasks of linking versions of Ccenes and associating included objects. A shortcoming is that the potential for errors as a user manually inputs information on relationships. A better solution would be for an outside application (preferably an online application, but potentially a desktop application) to connect directly to the repository, read in an object or scene, allow the user to swap objects and apply rules, and then publish the new version back to the repository. In this scenario, the application tracks the versions and parts of scenes and models, and correctly applies the correct links on publication. The repository would track the chain of users and edits, and would allow users to use, modify, and recombine models while preserving the metadata citing the original creators.

Overall, the ability to read and write from a repository should be as generalized as possible to allow for broad applicability and interoperability with 3D Viewers. Ideally, a repository would have a well-defined API that could be applied to other repositories, so software would not be locked into reading and writing from only one site.