- Draft conceptual mapping attached: imhTEI2MODS.xls
- Sample article-level IMH MODS record attached: sampleIMHmods.xml
What: A conceptual mapping (and eventually xslt for transformation) between the TEI Header (specifically the headers for the Indiana Magazine of History project) and the Metadata Object Description Schema (MODS)
Why: We considered using MODS to capture article-level metadata for the project. We eventually decided to keep all of the bibliographic information within the TEI itself, with the understanding that we might eventually want to switch to MODS (as the Independent Header becomes obsolete). This mapping will make that transition easier.
- Sample MODS record for a journal: mods86646620.xml (from the MODS site)
- Sample MODS record for an article: modsjournal.xml (from the MODS site)
- One TEI to MODS mapping is linked from the XSLT Library
- The TEI Header captures detailed information about two different resources - the source object and the digital object. MODS is based on MARC, and therefore is focused on the source object only.
- General strategy: Most of the information about the digital file is boilerplate, so when there isn't a way to record information about the source item and the corresponding information about the digital object, prioritize the source item.
- There aren't a lot of mappings out there to work from. In fact, there are hardly any.
- MODS has some of the same problems that TEI does when it comes to representing a a journal issue without losing the article-specific metadata.
- We could have article-level records within <relatedItem> elements in an article-level record, or we could create separate issue and article records, with a link from the issue to each article contained in it (possibly in a <part> element).
- Jenn says it's not going to be useful to have an issue-level record since Fedora breaks the issue up into article-level 'chunks', anyway, so we're going to focus on creating article-level records.
- The only information from the TEI that we lose this way is the issue pagination and ID. However, we could theoretically include a relatedItem for the issue that contains the article. That way, we could have the issue ID and pagination. Is there any reason to do this? It would make it harder to perform the mapping, since it wouldn't be a one header to one record transformation.
- Figure out why <part> element not validating
- Determine appropriate value for 'type' attribute of <relatedItem> for book review information
- Write xslt to transform IMH headers into MODS records