[Zope-CMF] Dublin Core

[Shane Hathaway]

I'd like to suggest an alternate implementation of metadata in the CMF. 
Let's look at the intended purposes of metadata in CMF:

- To make objects searchable.

- To provide navigation between related objects.  (Neighborhoods :-)

- To provide attribution.

(There may be more.)

According to one premise of Dublin Core (thanks Tim Lynch!), people's
requirements for metadata differ wildly.  Dublin Core just provides a
common subset.  So that means that CMF should provide an easy way to
extend the metadata.

Right now extending the metadata means creating subclasses of content
classes. This reminds me of where we were with workflow in the PTK a
year ago.  To change workflow, you had to create your own classes.  This
strategy really made sense until it became clearer what people wanted to
do in terms of workflow.  We all learned that workflow can vary
independently of object type.

Now it seems clear that metadata can also vary independently of object
type.  Subject keywords, for example, really have nothing to do with
images or files, except for the fact that they can be tacked on so
people can find them.

I can imagine at least one real-world scenario: an online newspaper
might decide that all images should have a metadata element listing all
published stories that use that image.  That way it would be easy to
tell whether it's alright to modify or delete it.  That property really
isn't a property of image objects nor is it a part of Dublin Core.  In
fact, the newspaper might later decide to apply the same policy to other
types of objects.

So I propose that content objects have a special attribute called
"metadata".  It would be an opaque attribute; only the portal_metadata
tool would know anything about its contents.  The portal_metadata tool
would then implement the following methods (or similar):

  getMetadataFor(ob) --
    Invoked by the catalog tool, returns a dictionary containing
    all metadata for a given object so the data can be cataloged.

  getMetadataElementFor(ob, name, default) --
    Invoked by the presentation layer, returns the given metadata
    element or the default.

  setMetadataFor(ob, values) --
    Verifies that the user has "Modify portal content" permission
    on 'ob' then sets the metadata for 'ob'.  'values' is a dictionary
    (or a REQUEST).

The tool could also choose to store metadata in a flat database rather
than in the "metadata" attribute.  By default, the tool would use Dublin
Core as the metadata definition.

What do you think?  Would this serve more needs?  Or would it make
things harder?  Metadata attributes would no longer be direct attributes
of objects.  But I think it is a good trade-off.

Shane