[Zope-CMF] Dublin Core

[Tim Lynch]

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.


> On Wednesday, June 6, 2001, at 09:10  AM, Tres Seaver wrote:
> 
> > Ricardo Newbery wrote:
> >
> >> Thanks for the pointers Seb and Tres.  Now I'm looking into 
> >> defining some new metadata elements...
> >> I notice that the CMF DublinCore module doesn't include the 
> >> entire set of metadata elements defined by the Dublin Core 
> >> Metadata Initiative.  Why is that?
> 
> Actually, this is something I hope to be talking about internally 
> today.  Specifically, I want to investigate and write up soon the 
> best practices on how to extend the dublin core to best suit needs 
> of users that we can't speculate ourselves.
> 
> > We chose initially to implement a subset of the DC, for a couple 
> > of reasons.
> > My initial proposal, with rationale for the subseting, is at:
> >
> >  http://cmf.zope.org/rqmts/project_glossary/DublinCore
> 
> I also added in some Links last night in the proposals area (found 
> at the bottom of the page) linking to a couple of Dublin Core 
> documents, posted there for informational purposes only.
> 
> http://cmf.zope.org/rqmts/proposals/
> 
> On a somewhat related note (this also relates to the "historical 
> documents" thread), look at the metadata at:
> 
> http://www.dublincore.org/documents/dcmi-type-vocabulary/
> 
> ------------
> Identifier:
> http://dublincore.org/documents/2000/07/11/dcmi-type-vocabulary/
> 
> Replaces: 	
> http://lcweb.loc.gov/marc/dc/typequalif-20000519.html
> 
> Is Replaced By: 	
> Not Applicable
> 
> Latest version: 	
> http://dublincore.org/documents/dcmi-type-vocabulary/
> ------------
> 
> The URL in 'Indentifier' is the real location of this document - if 
> you visit this URL even when a new revision exists, you'll always 
> get *this* particular draft.  Similar to W3C documents.
> 
> The Replaces and 'Is Replaced By' are interesting relations (we 
> have a proposal about the Relations elements on the dogbowl as 
> well), so you can navigate through revisions of the document.
> 
> 'Latest version' gives you a URI that always renders the current 
> (published) revision of the document.
> 
> I just wanted to point to this as a real world pattern for those 
> thinking about / working on the 'historical' revisions of 
> documents.  This pattern works really well for proposals and 
> recommendations, and is something I'd like to see in the in a site 
> like the dogbowl soon.
> 
> 	
> Jeffrey P Shell, jeffrey@Digicool.com
> http://www.digicool.com/ | http://www.zope.org/
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
> 
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature requests


--
Tim Lynch                            tim.lynch@cornell.edu
Information Technology Section                607.255.9570
Albert R. Mann Library
Cornell University
Ithaca, NY 14853