[Zope-CMF] Dublin Core

[Tres Seaver]

Shane Hathaway wrote:

> 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.


I would prefer changing the DefaultDublinCoreImpl implementation to
indirect all knowledge of the metadata storage through the tool; the
default tool would likely use an "aspect", stored in the content object's
"aspect bag".

An aspect bag is a proposed interface for content, to allow tools and
services to "stash" opaque data about a content object "on" the
object (it is opaque to the content object).  The name comes from aspect-
oriented programming, which focused on "weaving" new behavior onto
relatively "dumb" objects.  This interface will provide a cleaner
mechanism than just sticking things (like metadata, workflow history,
and discussions) directly into the object's dictionary.

We are already looking at ways to extend the set of elements which the
tool can manage, as well.

Expect to see the aspect bag land ASAP after 1.1 final.

Tres.
----
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org