[Zope-CMF] Dublin Core

[Ricardo Newbery]

As a relative newcomer to this space, I would like to chime in on the 
desire for an improved CMF metadata framework.

Metadata requirements are going to differ.  The Dublin Core set is 
good as a default and a lowest common denominator but it would be 
extremely useful to have an easy way to switch in another metadata 
scheme and a straightforward mechanism to map the local scheme onto 
the Dublin Core default elements.

It would also be useful to have some mechanism to handle generic 
metadata requests from external clients -- the Open Archives project 
seems like a good start in this direction.

Hmm... maybe I should write this up as a dogbowl proposal?

Ricardo Newbery
newbery@dvgroup.com


>From: Tim Lynch <lynch@gould.mannlib.cornell.edu>
>Subject: Re: [Zope-CMF] Dublin Core
>To: zope-cmf@zope.org
>Date: Fri, 08 Jun 2001 15:37:29 EDT
>
>
>As someone who has been involved in designing systems that
>incorporate support for Dublin Core for several years, and who
>works in a research library, I'd like to add a few comments
>about the use of DC.
>
>First, DC grew out of the perceived need for a common subset
>of metadata elements drawn from _existing_ metadata schemas.
>For example, most academic libraries use an incredibly
>comprehensive and complex schema called MARC (http://www.loc.gov/marc/)
>to describe their holdings.  Folks who deal with geo-referenced
>datasets typically use the Federal Geographic Data Committee,
>FGDC, schema (http://www.fgdc.gov/). Many other schemas are
>in common use including the Global Information Locator Service
>(http://www.gils.net) and the newest kid on the block,
>the Open Archives Initiative (http://www.openarchives.org/).
>
>If you look at any schema, however, you typically see a dozen
>or so elements that are common or "close enough" to be considered
>common for everyday use.  These dozen or so elements are what
>make up the Dublin Core.  The reason the DC elements appear to
>be "hideously underdescribed" is because corresponding elements
>are already elaborately described in other schemas.  The DC
>was never intended to serve as _the_ schema for anything. It's
>best interpreted as a core set of elements that you can always
>fall back to.  In this light, the required/optional status
>makes more sense: most DC elements are optional exactly because
>it is presumed your data is described by a metadata schema
>more appropriate than DC, that DC is simply the lcd and thus,
>given the nature of your data (and closely linked metadata
>schema) certain DC elements may or may not be present.
>
>I, as a data provider, would never consider building a metadata
>schema around the Dublin Core. Rather, I'd build a schema that
>works for my data and pay particular attention to making it
>congruent with DC.  Thus, my system could potentially negotiate
>an exchange along the lines of:
>
>client:  Hello -- do you speak MARC?
>server:  No, but I speak FGDC.
>client:  No, that won't do.  How about DC?
>server:  Sure, let's talk DC.
>
>So, DC is our lowest common denominator.  In the real world,
>a more extensive schema may well serve as a better lcd.
>
>In any case, to build a system with DC hardwired in is a
>mistake. Particularly a subset of DC.  DC is itself a subset of
>all other proven useful metadata schemas.  Everyone is going
>to want, no make that _need_, to extend the schema.
>
>For another perspective on the utility of DC, take a look at
>Carl Lagoze's paper:
>
>   http://www.dlib.org/dlib/january01/lagoze/01lagoze.html
>
>I think Carl does an excellent job of laying out the pros and cons
>of DC and of the attempts to work with it as _the_ schema of record.
>
>
>Bottom line: If you are going to implement DC, you should at least
>implement the full set. Furthermore, to make DC work as intended within
>CMF, you need to incorporate the ability to extend the metadata element
>set beyond DC.