The question of encoding the abstract metadata set ETD-MS in MARC arises from a number of directions.

Those NDLTD member institutions that prefer to store their records in one of the MARC standard formats (e.g., MARC-21 or UNIMARC) will benefit from a standard "location" within the record for each element in ETD-MS.

Communications between institutions storing ETD metadata in different formats will also benefit from this standard. USing the "crosswalk" below, a MARC-based institution can harvest data in XML-encoded ETD-MS, translating it automatically to MARC data, and can export MARC data that can itself be translated into XML-encoded ETD-MS for use at a more XML-oriented site.

Finally, NDLD members who function as OAI data providers can now export both XML-encoded ETD-MS and OAI-standard XML-encoded MARC data, irrespective of how they store their ETD data locally. In particular, sites that use the Virginia Tech Digital Library and Arhive's "NDLTD in a box" package will be able to export both formats automatically.

ETD-MS MARC crosswalk

ETD-MS Element	MARC-21 field & subfield	Notes
dc.title	245a
dc.title.alternative	246	Both title.alternative and MARC 246 are used for truly divergent titles. Mere translations are dealt with differently.
dc.title translated	242	Translations (neither alternative nor parallel titles) should be encoded in 242 fields. Parallel titles (as when an ETD is submitted in both English and German) are encoded in XML ETD-MS using two <title> elements with different XML:LANG qualifiers, and in MARC-21 using a single 245a subfield with the format <primary language title> = <secondary language title>.
dc.creator	100a	"Creator" is always a person in ETD-MS, although not in general Dublin Core; thus it requires a x00 field, in this case 100.
dc.subject	653a	Since \a subfields are not generally repeatable in 6xx fields, we recommend that separate <subject> tags be mapped to & from separate 653 fields.
dc.description.abstract	520a
dc.description.note	Any 5xx field not otherwise used, e.g., 504
dc.description.release
dc.publisher	260a+b	Publisher name maps to 260b. 260a is place of publication; this may be found in the element itself or in the linked authority record.
dc.contributor	720a	In ETD-MS, "contributor" is always some part of the guiding or examining committee. A "complete" ETD-MS 720 field includes both the person's name (in the \a subfield) and his or her role in the process (in the \e subfield).
dc.contributor.role	720e	(see note above)
dc.date	008 positions 7-10	The year portion of the date only should appear as decimal digits in positions 7-10 of the 008 fixed field. Positions 11-14 should (normally) be filled with blank spaces, and position 6 should have the value 's'. In the case where a second date (e.g., publication date where the first is date of the defense, or submission date where the first is date degree awarded) positions 11-14 may be used (in these cases position 6 should be 't' or 'p'). Dates may also be entered in 260c, although current best practices for MARC-21 recommend that dates in 260c not be encoded (e.g. in ISO-8601) but be written for human consumption.
dc.type	leader 6&7; 655	Electronic theses and dissertations are peculiar in that they are at once text monographs and machine-readable files. (Some ETDs may in fact not be text objects, but all are bound to be monographs.) As text objects, they should have leader position 6 set to 'a' and as monographs, position 7 set to 'm'. Multimedia ETD's may have different values in position 6 (including as a default 'm', software), but all should have an 'm' in 7. As well as these leader values, ETD's may also include the text "Electronic Thesis or Dissertation" in the 655a field.
dc.format	856q
dc.identifier	856u	This assignment is based on the (common but not required) use of URIs (of the theses or dissertations themselves, for instance, or of their "electronic title pages") as identifiers. Actual identification numbers such as those used in the OAI protocol to name each item should map to the 035a or 035z subfield.
dc.language	008 positions 35-37; [548]	MARC-21 makes use of its own standard abbreviations for languages, different from the two-letter ISO-639 codes recommended by ETD-MS or even the three-letter RFC 1766 standard used alternately by Dublin Core. Some translation must therefore be used in filling 008 positions 35-37. Field 548, in further contrast, requires a human-readable "note." Accordingly, we have attached an appendix to this document mapping ISO-639 codes to MARC-21 codes and human-readable language names.
dc.coverage	651 or 690	"DC Coverage" fields may contain either (some description of) geographic or temporal extents or both. There is no single equivalent among MARC fields. Coverage is often encoded in general subject (6xx) fields using the \y and \z modifying subfields. Alternatively, when geographic coverage descriptions can be recognized they can be mapped directly to 651a subfields. Without a corresponding temporal subject field, temporal coverage elements must be mapped to a general-purpose subject field such as a 690.
dc.rights	540
thesis.degree.name	502a	AACR-2 guidelines for cataloging theses and dissertations require that the cataloger generate a 502 field in the form: <name> (<level>) -- <grantor>,<date>. We recommend that as much as possible of this string be synthesized from the ETD-MS thesis.degree element, and when such a string is recognized in the 502 field of an existing MARC record, that it be considered to encode (most of) a thesis.degree element.
thesis.degree.level	502a	(See note in thesis.degree.name.
thesis.degree.discipline	710b	Unable to find a MARC field that encodes the discipline of a cataloged work, we have fallen back on the common practice of conflating the discipline with the name of the granting department. This is encoded by putting the discipline name in the last \b subfield of the 710 corresponding to the grantor (see note below).
thesis.degree.grantor	502a; 710ab	In addition to the AACR-2 procedure for thesis notes mentioned above, the degree grantor may be considered an institutional contributor to the work. This motivates generating an added entry (710) for the granting institution. The grantor may be considered to be the college or university (the name of which should appear in the 710a subfield) or it may be a subdivision of the learning institution, in which case best practice is to generate sucessive b subfields for each division following standard MARC pracices for x10 fields. In any case, the final \b subfield should map the thesis.degree.discipline element.

 

Accordingly, institutions that create ETD-MS compliant MARC records have several alternatives for sharing those records:

• They may share the MARC records as they are held, either as streams of data in MARC Communications Format or encoded as XML using the OAI XML MARC encoding (or equivalent).
• They may share just the parts of their records corresponding to the ETD-MS standard metadata set, either as MARC-like objects or using the XML encoding of ETD-MS.
• They may share the records as Dublin Core, using the Library of Congress MARC / Dublin Core crosswalk or similar tool. Just as DC and ETD-MS overlap to a great extent, so the crosswalk defined above overlaps significantly with the crosswalks defined by LoC.