[Zope-CMF] Re: Dublin Core's Relation implementation

Ausum augusto@artlover.com
Mon, 16 Jul 2001 09:53:58 -0500


Thanks, Seb, for your answer.

After reading Ken's proposal, the whole concept is now clearer to me.
(Although I still need help with the code) :)
When I started to investigate the Portal existing tools, months ago, I
realized that besides the high-end suites, there weren't good CMS
solutions who could manage well all the concepts we were aiming to bring
to reality. 

One of those concepts was a replication of the "related content" boxes
found at good news portal. Autonomy does it through Story Server, and I
got pleasantly surprised by its refinement. (Actually I didn't try Story
Server, but I did Kenjin, a discontinued and pretty smart small app that
used to find related internet/hard_disk links from whatever windows
application you had in front.) Maybe it wasn't true AI, but it was very
close.

OrganizationObjects seem to englobe more possible situations regarding
more relation cases between portal objects. If I understood it well, 
OObjects would retain relational information between objects, would
gather the changes from objects currently related through them, and
provide searching, organization and navigational tools. With a
Wiki-oriented concern as a background, it considers not only the
relationship between threaded objects, but all other relationships as
well. My contribution to this subject is simple. I would like to suggest
a conceptual abstraction that would lead us more to a complex object
model, instead of a new object type.

If we compare every content object to a person, we would notice that
every object ought have parents and grandparents, right? Our
object/people element would also have children as expected, and this
would be our way of understanding linear inheritances. But wait, this
object lives in a real world and it's for sure that it has more
relatives. It could have brothers, cousins, friends, known people, by
example. At their turn its parents have their own cluster of relatives,
and the same would happen even for the remotest relative or friend, just
like the real world at wich everyone of us is unique. Is there something
more appropiate for an object-relation model? 

What happens when you want to find a remote cousin? Do you start to look
for him, or just ask to your parents, trying to find out more about the
big picture of its remote condition? My personal answer is number 2, and
it's the core of my idea: Every content object should know who it is,
who its parents are, who are their immediate relatives/friends, and some
idea of their children's friends. This is basic information that every
object should have (some of wich is automatically acquired) as this is
the starting point to any future complex relationships. You don't need
to tell everybody that you are moving from town, you just need to tell
one of your relatives, who will store the information until requested,
or propagate it immediately to the family. Notice that "my family", "my
closest friends", or "my unborn nephews" are all results of queries
(persistent or not), and not object by themselves.

Is this a valid comparison? My supossition is that this would be a
friendlier algorithm to the "everything-related-to-everything" current
requirement, as there would be no need to deal with more objects. The
hard side, I guess, is that the content object itself might have to
store more than just metadata, as it might need to store automatically
changed, dynamic criteria for the task of looking for other relatives,
and context-dependable logic to store new data from them, as well. 

This is just a first approach. Any comments?  :)




Ausum




  






seb bacon wrote:
> 
> 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
> 
> _______________________________________________
> 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