While some loose ends are still being tied up, the IR Metadata team is very close to finalizing its first round of deliverables. Thank you to IR Metadata group chair Rachel Appel (Unlicensed) as well as group members Jasmine Clark Matthew Ducmanas Stefanie Ramsay (Unlicensed) Holly Tomren and Leanne Finnigan (Unlicensed) for all the work you’ve put into this!
These deliverables include, but aren’t limited to:
A Metadata Application Profile (MAP).
A defined syntax for each field in our Institutional Repository
Clearly defined controlled vocabularies for those fields that need them.
Crosswalks into DSpace from ProQuest ETD Administrator, Symplectic Elements, and CONTENTdm
Let’s take a closer look at just one of these deliverables, the MAP. Below we have the entry for just one field --Contributor (committee member) – as it’s described in the MAP:
Field Label | Contributor (committee member) |
Status | Optional |
Hidden/Visible | Visible |
Description | A person on the committee for the creation of the item. Used primarily for dissertation committee members. |
Source of Information | Item or submitter |
Simple DC Element | dc:contributor |
Qualified DC Element | dcterms:contributor |
DSpace Element | dc.contributor.committeemember |
Repeatable | Yes |
CV | LCNAF when available |
Syntax |
May differ if LCNAF standard name |
Notes and Best Practices |
|
Examples |
|
It is wonderful to have the standards for each field defined in such detail. Once a 1.0 version of the MAP is finalized it will be made publicly available through Confluence.
The DSpace project team is moving closer to determining how exactly the system we're building will look and function when we go live. While DSpace will form the system's technical core, and will serve at the very least as its administrative interface, it could be possible to 'skin' DSpace, that is, build a separate system through which the public would interact with the items in our IR. We’re currently consulting with
Chad Nelson and Christina Harlow to determine what approach is best out of the three outlined in last week’s blog post.
To review, here are the three options under consideration:
Skinning with a system such as Blacklight, the framework used to create our new Library Search (this could look something like Cornell’s IR).
Extensively customizing DSpace (this could look something like DukeSpace)
Using an out-of-the box DSpace theme (i.e., this example repository)
To weigh the relative merits of each option we used a project management tool called a product requirements matrix, a grid that lists each feature the finished system should be able to perform (read this page for a fuller description). The matrix Gabe Galson made in consultation with the Services and Metadata groups can be found at the top of this page. The Groups ranked each feature's importance, giving it one of four ratings: 'must have', 'should have', 'could have', or 'won’t have'. These rankings, generated by stakeholders, can be cross referenced with a 'difficulty of execution' ranking that can be assigned by by the developers and technical team. Or, they can be consulted by developers who can advise on the best solution. This matrix is a bit more complex than the standard example, as we’re already locked into DSpace as our administrative interface, and whatever front end approach we decide on must take this into account. This means, for starters, that certain features requested by the Groups could either be fulfilled via DSpace, or via the second system, depending on the approach we take. It also means that the fact that a feature is front end (relating to the interface) or back end (relating to the administration of the objects and metadata the system contains) is important, as it determines whether it can be done through DSpace’s out-of-the-box functionalities, or whether it must be rebuilt in the second system. Note that the matrix is still a work in progress, and will be revised and brought back to the Services Group for further review. Stay tuned!