[Zope-CMF] Extensible Metadata

[Tim Hoffman]

Hi Christian

On Tue, 2002-08-06 at 15:27, ctmobile@gocept.com wrote:
> On Tue, Aug 06, 2002 at 09:24:17AM +0800, Tim Hoffman wrote:
> > Hi Christian
> > 
> > I have been thinking about this problem for a while, and done some
> > fiddling, but haven;t had enough time to devote to either a write up 
> > or finishing any code.
> > 
> > My thoughts are that the current metadata tool needs to be replaced.
> > Along with defaultDubinCoreImpl (which is what was intended by putting
> > it in CMFDefault rather than core ;-)
> > Despite what Dieter says about what you can do with the current tool, it
> > is pretty crude and basic.
> 
> Yes. I still didn't find a way to introduce *one* new field to the set 
> of metadata, without modifying the DublinCore implementation.

I have been doing monkey patches for each of our projects. But this
means that I can only run a single site with a single patch, as
different sites have different and incompatible metadata requirements.

> > 
> > My thoughts are along the lines of a new metadata tool which has the
> > following features. (I think it could be built using formulator so
> > form generation can be also made easier.)
> > 
> > What I would like are
> > 
> > 1. The tool where possible preserves all of the existing portal_metadta
> > interfaces. 
> > 2. Metadata name spaces, essentially the tool comes with a single
> > default name space for DublinCore. If you need additional set's of
> > metadata .e.g. AGLS you can add a new names space. 
> 
> This doesn't sound good to me. Actually you have a set of metadata which 
> involves the same data (e.g. Location), so why should you enter this data
> twice? One reason may be, that the different metadata spaces have a different
> definition of location, but if every object may have a different kind of 
> location description, we lose the effect of metadata: easy classification.

Except if I am not overriding Location, then I wouldn't define it in the
AGLS namespace, I would only define things in a new namespace that are
additive to the default namespace, rather than duplicating. 

Yes all the elements could be blobbed together and not have seperate
namespaces, but I for one still need to be able separate out groups of 
metadata elements, that are either not specific to a site (if I have
multiple sites with different element sets (what about nesting sites
each having it's own metadata requirements), then just multiple
metadata_tools would be enough. But if I have specific content objects
that warrant additional metadata (as opposed to everyday object
properties) but the metadata is not relevant to other data types, it
seems that polluting all content with all metadata is a problem (well at
least for me)

e.g. Image/artwork content has different metadata requirements
(Australian Image Archive has extensions over and above AGLS/DublinCore,
but is not relevant to non image data), over and above say basic textual
content that might have just DublinCore and AGLS.


Regards

Tim

> 
> I think you could define a single space for all metadata, but have a set
> of views on that, e.g. one view offers you the DublinCore, the next one 
> may offer "AGLS" ... . You got the point.
> 
> > 3. Each namespace can be defined by creating a namespace object which
> > inherits from Formulator.
> > 4. Each field/attribute of the metadata namespace could be defined as a
> > formulator field.
> 
> I don't know if that's needed. I never touched Formulator, as I have my
> own tools.
> 
> > 5. I would like to be able to say specific namespaces may be mandatory
> > for specific content types, but unnecessary for others.
> 
> Actually, this is what the current metadata tool seems to be aiming at.
> You can set constraints on fields. Not on namespaces, but see my earlier
> comment on the namespace issue.
> > 
> > I have a some of this working (only as a proof of concept) Preserving
> > some of the old metadata tool interfaces are a bit of a pain.
> > 
> > Just my 2c worth
> >
> Thanks,
> Christian