The fundamental reality of all the options we have seen is that, unless you are relying completely on some default mapping of EAD elements to MARC fields, you will need to add some data by hand to some record at some point if you want to get subfield granularity. Nothing here is "free" of overhead.
I always say that it reminds me of the old Fram oil filter commercials: "you can pay me now or you pay me later." The solution you employ all depends on where in your workflow you want to embed the subfield coding: in your EAD encoding environment or in your MARC editor. You can do it
By adding element markup to your EAD encoding as John Harrison illustrates.
By embedding strings like $a or $3 into the CDATA text of particular elements as Mark Carlson has shared.
By editing the MARC record that results from your transformation of the EAD, inserting the subfield codes at that point, the entire EAD element having been mapped to subfield $a in the transformation.
Michael Fox
-----Original Message-----
From: Encoded Archival Description List [mailto:[log in to unmask]]On Behalf Of
John Harrison
Sent: Thursday, May 04, 2006 3:57 AM
To: [log in to unmask]
Subject: Re: mapping <altformavail> to MARC
On Wed, 2006-05-03 at 15:32 -0700, Mark Carlson wrote:
> We addressed the granularity problem in <controlaccess> terms by
> embedding the actual subfield codes within the EAD elements:
>
> <subject source="lcsh" rules="aacr2" encodinganalog="650">School
> integration$zWashington (State)$zSeattle</subject>
But this leaves MARC specific code in the actual text of the finding
aid. This is not a good approach from an interoperability point of view.
An approach recommended for use in the Archives Hub (UK
http://www.archiveshub.ac.uk/) is to wrap the marc subfield analogs in
emph tags and apply an altrender attribute to specify which marc
subfield they apply to. e.g.
<subject source="lcsh" rules="aacr2" encodinganalog="650">School
integration <emph altrender="z">Washington (State)</emph> <emph
altrender="z">Seattle</emph></subject>
If you do this, you don't need to worry about stripping the subfield
codes in non-MARC oriented output.
Relating back to the original question, maybe altrender attributes could
be used to tag subfields of the MARC 530 field.
--
John Harrison
Special Collections and Archives
University of Liverpool Library
Chatham Street, PO Box 123, Liverpool, L693DA
e: [log in to unmask]
w: sca.lib.liv.ac.uk
t: 0151 7943142
f: 0151 7942681
|
