An institutional repository’s effectiveness in showcasing heterogenous content depends largely
on an appropriate selection of metadata schemata. Specialized structures and fields are
required to faithfully depict the context and type of audiovisual media and special collections.
The metadata associated with digital assets are fundamental to the repository’s function, and
they allow users to search, sort, share, attribute, represent, and track the provenance of
content. Librarians often term a specialized set of metadata fields from various schemata a
“metadata application profile”.
The Applications Development team at Texas A&M University Libraries has prototyped an
application called CAP (Curators’ Administrative Platform) to enable dynamic customization of
metadata application profiles for Fedora repositories and to facilitate the basic interactions
with the Fedora REST API (LDP, Fixity, Versioning, and Transactions) through a clean, intuitive
modern UI. CAP also includes viewers to render image resources in the browser with <img>tags
or with OpenSeadragon and a IIIF Image Server. The A&M team includes developers James Creel,
Jeremy Huff, Kevin Day, Ryan Laddusaw, Jason Savell, and William Welling; and managers Doug Hahn
and Mike Bolton.
CAP is a thin layer on top of the Fedora Repository platform which allows administrators to
designate URIs for RDF metadata namespaces over the Internet, parse the namespaces using
the Apache Jena library (https://jena.apache.org), and select specific fields for use in a given IR.
In this way, administrators can craft application profiles appropriate for specific content types
or collections in a Fedora repository.
Architecturally, CAP consists of an Angular.js frontend to a Spring Boot webserver. The
webserver persists information about IR locations and schemata and performs the calls to
remote namespace URIs and Fedora REST endpoints. Interactions with underlying Fedora
repositories are handled with the Fedora Java client.
The Applications Development team at A&M would ideally like to see the CAP webservice as
“One API to rule them all” by making CAP usable with other repository platforms, but
acknowledges this as a future goal that would likely entail compromises in homogenizing
different repository interfaces and data models.
The open source code for CAP is available on GitHub at https://github.com/TAMULib/Cap . Prior
to a formal release, the developers would appreciate feedback from any community members
willing to stand-up the software, fix bugs, or commit code. Please contact James Creel
email@example.com with question or suggestions.