[Zope3-dev] zwiki: performance of findChildren()

[Ken Manheimer]

On Wed, 30 Apr 2003, Chris Withers wrote:

> Max M wrote:
> > Why put the relation in the object?
> 
> ...becasue it's much more natural to work that way.

If i'm understanding the question, then i don't see that it's anywhere
near more natural.  If the zwiki findchildren() mentioned in the topic
line is what i'm thinking, then this is about systematic assessments
of relationships across numerous objects.  As with the catalog for
searching, you don't want to have to wake up all the potentially
involved objects in order to make such an assessment.

It so happens that this very question is what spurred me to my
interest in having a third party for satisfying such queries, when i
was developing "lineage" in WikiForNow.

In that situation, pages had offspring pages, and you needed to be
able to assess both "who is my parent" and "who are my offspring" on
separate occasions.  If you put the information about offspring in the
parent, then you have to visit all the pages in the wiki to answer the
"who is my parent" question.  If you put the information about parents
in the offspring, then you have to assess the entire wiki to answer
the other question, "who are my offspring".

(I wound up putting the lineage relationship in the children because
that accounts for the most common wiki relationships assessment.  The
header for each page indicates the page's ancestry.  That can be
fairly trivially assessed by examining the page's parent info, listing
the parents, and then recursively processing them them until you get
to the wiki root page(s).  You have to wake all the ancestors, but
that's a usually a relatively very small number of objects,
particularly as the wikis get big.  Assessing the reverse
relationship, what are the offspring of a page, requires visiting all
the pages in the wiki, but it so happens that you only need to know
the children when you're getting a lineage map of the entire wiki, so
you would need to visit all the objects anyway.)

What i wound up _wanting_ was something like the catalog for
relationships - an independent entity that holds info about all the
relationships in the wiki, so i could consult the relationship info
without messing with the objects, themselves.  (I referred to that
third-party object as OrganizationObjects, and wrote about it here:
http://cmf.zope.org/rqmts/proposals/OrganizationObjects .)

This requires something like the event service and object hub to
reliably maintain the relationship info.  It's no coincidence that
Zope3 has them.  They're generally useful for doing kind of thing -
and in fact i think my ruminations on OrganizationObjects had
something to do with prompting those services.

I think that a relationship service would enable a lot of very useful
things, including and well beyond lineage.  I sketched out several
kinds of relationships in the OrganizationObjects spiel i mention
above.  Now that i've been (barely) introduced to RDF, i'm also seeing
how tieing RDF in with the relationship service could capitalize on
RDF's technology for federation and systematic translation of
relationships, and even the high level semantic web stuff like
ontology mapping if/when that cogeals.

What this would _mean_ is being able to talk about and manipulate
content in terms of the elaborate relationships that exist between the
data items, within and across applications.  This is truly exciting
stuff - but depends on providing for scalable, systematic assessment
across many objects.

> > Isn't it better to have a container 
> > with different relations?
> 
> Not really.
> 
> If you wanted to know what someone was working on, would you ask them or ask
> their mother?

I don't see how your question is relevant.  ?

At least, the kind of thing that concerns me is more along the lines
of this question: "If you wanted to call a plumber, would you go to
everyone in your city to ask them if they do plumbing, or would you
look in a directory?"

--
Ken
klm@zope.com