[Christopher Marsden]
> I can understand the value of giving MARC encodinganalog attributes,
> where there may be questions of conversion from one format to
> the other, or links between a MARC fonds-level description and
> an EAD finding aid. However, I haven't figured out what practical
> purpose ISAD(G) encodinganalog attributes might serve. Have I
> missed some crucial point?
To a large extent, I agree with you, because in most cases there is
a fairly good, unambiguous, one-to-one, _reversible_ mapping from
the ISAD(G) element set to (a subset of) the EAD element type
set. So all ISAD(G) 3.1.1 Reference Codes are EAD did-unitid's, all
ISAD(G) 3.1.2 Titles are EAD did-unittitle's etc etc, _and_ vice
versa.
However, we do also make use of encodinganalog attribute values
to record ISADG correpondences, because I feel that in a small
number of cases, it gives us (or our processing application) a
_slightly_ finer degree of control over the data. For a small number
of ISADG elements, I need to encode that data using an EAD
element type which has semantics which do not correspond
exactly to the semantics of the ISADG element.
In some cases the semantics of the EAD element may be broader
in scope e.g. the application guidelines recommend that (in the
absence of an EAD element type with more specific semantics),
ISADG 3.5.1 Location of Originals is encode as an odd.
However, in my display - and I regard the creation of a display
format as just another case of "conversion", like the EAD-MARC
case you note - , ideally, I'd quite like to pull out that data and
display it up there in front of ISADG 3.5.2, and not down with my
ISADG 3.6 Notes" (also encoded as odd), so I use encodinganalog
attribute values to _qualify_ my odd elements and enable the
application to make that distinction.i.e. I can process my
<odd encodinganalog="isadg36">
differently from my
<odd encodinganalog="isadg351">
(Actually, I encode 3.5.1 as an add element, but the argument is
the same!)
A slightly awkward case is, I think, ISADG 3.5.5 and 3.5.4 and
their relationships to relatedmaterial and separatedmaterial.
ISADG makes the distinction between whether the material is
located in the same repository (3.5.3) or not (3.5.4). EAD (I
think) makes a different distinction in the relatedmaterial and
separatedmaterial element types. EAD relatedmaterial is material
not related by provenance (regardless of which repository it is in)
and EAD separatedmaterial is material which is related by
provenance but has been physically separated (but may be in the
same repository or a different one).
(I have written this next paragraph several times and my head is
spinning and I'm still not sure it's right, but here goes...)
Sometimes the information in ISADG353 will be EAD
separatedmaterial because it is related by provenance and it
happens to be in the same repository; sometimes it will be EAD
relatedmaterial because it is not related by provenance. The
information in ISADG354 is defined as being related by provenance
so should consistently be EAD separatedmaterial.
But is the reverse mapping possible? Is all EAD relatedmaterial
always ISADG353? Probably not. And is all EAD
separatedmaterial always ISADG354? No.
Anyway, using the
relatedmaterial encodinganalog="isadg353"
separatedmaterial encodinganalog="isadg353"
separatedmaterial encodinganalog="isadg354"
enables my display application to go ahead and display these as
that ISADG element with confidence.
So, yes, I have sympathy for the argument that says this is hair-
splitting and overkill (and actually in practice we aren't splitting up
our ISADG 353 into relatedmaterial and separatedmaterial....), but
using the encodinaganalog attribute gives the application a little bit
more control. In the end, like all questions of "how much markup is
enough", there is no "right answer": it depends whether that is
required in your processing context. If it isn't - if all your odd's are
to be treated the same way, for example (or if you are
distinguishing them in another way), - then it doesn't matter.
As these values are (in our case) generated by macro it doesn't
cost the encoder any effort, and it gives us a tiny little bit of "added
value" and flexibility.
Pete
Pete Johnston
Glasgow University Archives & Business Records Centre
|