IR Services- Drafting Policy as a Group
The IR services group has started setting policy and determining our repository’s scope. The group has divided into two-person teams, each of which is tackling one key area connected to the IR’s configuration. Here are the areas we’ve tackled so far:
Purpose- What is our repository’s raison d'etre?
Intellectual Content- What does the repository include, content wise.
User Communities- Who can submit content to the repository? (i.e. faculty, staff, grad students, undergrads)
Noa and I, for example, are working on the ‘Intellectual Content’ section. We’re trying to determine which types of scholarly content will be accepted, and how submitted materials will be vetted. This also involves listing out the DSpace-compatible file extensions, then comparing this list to the file types we’re interested in collecting in the IR. This process leads to a number of questions, for example, will we be supporting Illustrator working files, even though they can’t be displayed through the system?. ‘Intellectual Content’ also involves a digital preservation component: many institutions advise submitters on the support level they offer for a given file type, that is, let them know whether they’re confident that they’ll be able to host and display the file type down the line. Determining what Temple is able to support long-term --or whether we should commit to anything at all-- is a complex process, requiring the input of multiple IR stakeholders and technical staff.
We’re still working through these issues, but we already know that we’re going to recommend to the main group: the creation of a libguide or wiki along the lines of MIT’s. This approach would allow our institution’s IR policies to be displayed transparently, but would also serve to ‘pay it forward’: Much of the progress made thus far in both the IR Services and IR Services Metadata groups are attributable to Institutions like MIT that have made their policies available publically. Uminn is a good example- they’ve posted their policies in their own IR, which we were able to find through google, and which has informed the metadata group’s work.
The IR Services Metadata Subgroup has begun its work!
The group consists of Rachel Appel (Unlicensed) [Chair], Gabe Galson [Project manager], Jasmine Clark, Leanne Finnigan (Unlicensed), Holly Tomren, Stefanie Ramsay (Unlicensed), and Matthew Ducmanas. As described in the last DSpace blog post, this is a working group chartered through the main IR Services group. We will meet bi-weekly for as long as necessary, and will attend to the configuration of the metadata housed in Temple’s DSpace-based institutional repository.
As stated in the project charter, the group will design a metadata model that:
Ensures stewardship of resources through the entire digital lifecycle
Is flexible and interoperable with other infrastructures that may need to interact with the repository for discovery across environments
Meets user requirements based on self-service submissions as well as administratively applied description
Adheres to standards
Applies to a variety of record and object types
Follows specifications required or recommended by the repository platform or infrastructure
Determines user needs and how they may impact metadata creation
Clearly outlines guidelines, fields, and how those fields should be populated
Is well documented and outlines decisions made
Has a clear workflow and application process
Getting started
The group’s first project is to create a comprehensive schema that will be implementable in DSpace, and that will meet our needs going forward. Here’s how this process has worked so far.
We’re looking at various IRs and the way they organize their metadata. For starters we’re focusing on University of Minnesota, UT Austin, Cornell, TriCo, Georgetown, UC Irvine, UT Austin, Cornell, Auburn, Brandeis, Duke, Washington State University & Virginia Tech. If you know of any other excellent or interesting institutional repositories please don’t hesitate to point them out to the group!
We brainstormed, creating a list of fields we’ll need in our IR. Determining which fields will be necessary can be tricky, as as metadata will be incoming from multiple sources- Elements, ProQuest, and direct submission via form. Each team member was assigned several fields, for which they’ll suggest mappings based on their own expertise and/or supplementary research into IR metadata best practices. We’ll then review this body of work as a group.