There is some overlap in functionality between what METS can do and what
the EAD <dao>-type elements can do for you, but at least in my
environment I look at them as serving two different purposes. You
probably don't want to create METS documents just to have them, but
instead because they do something for you in your environment. Two
things METS is really good at are documenting the strucutre of complex
digital objects and linking together multiple versions of the same
thing. I think both of these situations can arise with collections that
have finding aids encoded in EAD.
The first (complex objects) is helpful when you have a multi-page
object, say, a 3-page letter. This isn't the sort of thing you'd likely
display inline as part of an HTML finding aid, but rather link out to
it. If you have a delivery system that uses the <structMap> in METS to
put the pages of the object in sequence and display them to a user (like
we do here at IU), then METS works well with EAD in that case.
The second (multiple versions) is helpful when METS is used to package
up digital objects (and maybe the EAD too) into some sort of repository
system to get managed and preserved over time. Your EAD display to a
user might only point to one version of an object (a little one to show
inline, a bigger one on its own outside of the finding aid, or an HTML
page showing the object in some kind of context) but your repository
will need to manage ALL versions of that object (a high-res TIFF plus
two sizes of JPEG derivatives, for example). While the EAD may or may
not point to all of these, the METS definitely would so that the
repository can know about them and manage them over time.
One case in which they can both do a very similar thing is when you have
multiple digital objects within a file-level description. In the EAD,
you could put a whole bunch of <dao>s right in a row and assume their
order is meaningful. In METS, you can explicitly put these items in a
sequence. *Basically* the same functionality, done a slightly different
So, basically, when you have systems that already use METS for
something, then the METS can compliment the EAD. We're looking here at
IU to use the EAD as the master source of this information whenever we
can, and to derive as much of the METS as possible from the EAD file.
We're not sure if this will always be possible (in case 1 above we have
to assume the sequence of pages from filenames, for example), but we're
just starting to think about this issue.
(currently working on implementing this very thing!)
Digital Library Program
Indiana University - Bloomington
Wells Library E170
Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]]
> On Behalf Of Michele Rothenberger
> Sent: Wednesday, November 29, 2006 10:16 AM
> To: [log in to unmask]
> Subject: EAD and METS ?
> Can someone give me a brief explanation of the relationship
> (if any) between EAD and another of LOC's standards, METS?
> It appears to me that METS is intended only for digital
> objects; is it then complementary to EAD, and/or is there
> some overlap with EADs dao, daogrp etc elements?
> Michele R. Combs
> [log in to unmask]
> Manuscripts Processor
> Special Collections Research Center
> Syracuse University Library
> 222 Waverly Avenue
> Syracuse, NY 13244
> (315) 443-2697