I agree with Ruth that the current split between administrative and
"other" metadata is problematic, although the problems I see are
different to the ones she noted. (Not that I disagree with hers, I just
have a different perspective.) If you embed MARC or MODS or DC records
in the dmdSec, you will often be embedding data elements that are
redundant with some elements in the amdSec, or, even worse, in conflict
with it. The problem is that the "descriptive" metadata record is often
created outside of the context of the METS record and may not complement
it well at all. I understand the reason for allowing the embedding of
descriptive metadata records from various sources, but I also feel that
any metadata record needs to have a coherent set of metadata elements,
which is not necessarily the case when using the embedding technique. I
understand the idea of wanting to use extension schemas, but I think
that in terms of the overall record those extensions need to be
coordinated somehow.
As for Jerry's comment about the installed base, that will always be
true, but if it becomes a reason not to change we're in big trouble. We
need to think about profiling and versioning to allow change to occur in
a controlled fashion.
kc
As for
Ruth Bogan wrote:
> Good morning everyone.
>
> I want to throw out for discussion something that I have been thinking
> over for quite some time. I am troubled by the inclusion in METS of
> the dmdSec and amdSec and am wondering what others think. I welcome
> any and all comments
>
> I believe it is unwise to segment metadata within a METS document into
> descriptive and administrative. Currently METS codifies these inexact
> concepts--descriptive metadata and administrative metadata--by hard
> coding them into the METS structure, and this is problematic. I
> believe that METS implementers would be better served by collapsing
> the dmdSec and amdSec segments of a METS into a generic metadata
> section, which can be repeated and categorized or labeled per the
> needs of the implementing institution.
>
> I think the segmentation of metadata in METS into dmdSec and amdSec is
> based on a misunderstanding of why the distinctions were originally
> made. The definitions of “descriptive” and “administrative” metadata
> are inexact and not mutually exclusive. They are, without question,
> useful terms and serve the purpose of educating practitioners about
> data that is or may be critical in managing digital objects over their
> lifetimes. This has been and continues to be unfamiliar territory, and
> there is need to try to extend our scope beyond the familiar
> boundaries of traditional library cataloging. However, as happily as
> these categorizations serve as informal guides, they are not
> defensible as separate entities.
>
> More importantly, the current METS model of separate descriptive and
> administrative metadata sections is an inherent counter to the
> flexibility that METS offers. There will be, as time goes on, an
> increasing need to segment, modularize, or otherwise section metadata
> into meaningful packets in order to deal with complex objects. For
> example, I can see wanting to have a single, unified metadata
> record--perhaps a MODS record extended with elements from other
> schemas--as my basic metadata. And I might want to incorporate
> multiple versions of that extended record for each manifestation of a
> digital object bundled into my METS object. That’s a more FRBR like
> model. Or perhaps I might want to follow a model more like VRA Core
> and have multiple unified metadata records for a digital image, the
> photograph of a painting used to create the image, and the original
> painting. I want to be able to modularize my metadata in way! s that
> make sense to me, and not be constrained by built in buckets for
> descriptive and administrative metadata.
>
> I think a more generic metadata structure would provide the
> flexibility to experiment with other models, one of which is certainly
> the descriptive vs administrative model. I simply believe it isn’t the
> only model, and that METS should support other possibilities.
>
> Ruth
> Ruth A. Bogan
> Head, Database and Catalog Portal Management
> Rutgers University Libraries
> 47 Davidson Rd., Busch Campus
> Piscataway NJ 08854
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
|