[Zope-CMF] Dublin Core's Relation implementation was:(Portal Topics as items' metadata)

[seb bacon]

Hi,

* Ausum <augusto@artlover.com> [010711 19:52]:
> Just after posting my previous message I read more about this subject.
> If I'm not wrong, it looks like DC's Relation element is still a work in
> progress, and that a simple identifier (URL, URN, etc) is recommended
> for this label, by the DCMI.
> 
> I think that within the context of the CMF, the Relation element, IMHO,
> should be understood as one object's engine, and not just as a
> collection of identifiers. 

Yes, I would have guessed that the best way of doing the Relation
element would be to dynamically generate it using something like ken's
OrganisationObjects[1], since URIs are liable to change. 

> Your idea, Seb, is good, but I think that
> without the aid of artificial intelligence tools (which high-end CMSs do
> have), every related resource must be found after an adjusted search, at
> a per-object basis. 

When you say 'artificial intelligence' are you referring to things
like Autonomy?  Autonomy make a big song and dance about their Dynamic 
Reasoning Engine, but really it's just a decent search engine with
automatic document retrieval and index discovery.  Ultimately, you're
always looking at an 'adjusted search' of some kind.  And as I
mentioned, a Topic *is* just a catalog search.

> As I see it (considering all the previous), a good
> "related info" box should contain "stuck", previouly approved resources,
> and "floating" resources as well. And all this seem to need a user
> interface.
> 
> So the question still remains. How would you attach a Portal Topic to a
> portal resource, as metadata?

If I understand you correctly, you want to be able to have a list
which is made up both of dynamically retrieved, query-based data, and
a manually updated list.  Topics won't give you this, since they are
basically catalog queries, and that's it.

In order to add static references to objects which are liable to move
at any point, you'll need to implement some kind of reference
storage.  This could be a catalog which indexes objects by a unique
identifier, or something more sophisticated which plays with the
not-yet-developed EventsTool.  Or wait for an OrganisationObjects
implementation ;-)

For the query part, you could add a Topic to the
DefaultDublinCoreImpl, and move the elements of its interface over
into the metadata_edit_form.  You'd add a couple of get and set
methods, the get method returning the results of the topic's catalog
query.  I can't think of a simple way of doing it off the top of my
head.  I'd be tempted to ignore Topics and write my own version.
Hopefully someone else will have a better idea :-)

seb

[1] http://cmf.zope.org/rqmts/proposals/OrganizationObjects