I have no personal experience of the frond though and don't know if you can generate image-maps. But, I once generated a representation of perl grammar using ATT graphviz.

-- stefp

For an example of what Graphviz and perl can do, check out this nifty DNS mapper.

-Blake

Or this example, by merlyn.

I think a double-sided tree would work with the "You Are Here" node joining them. I picture parents to the left, kids to the right, all links with summary information. If disconnected components exist, list them separately by either entry point or last-visited.

Assuming you use some flavor of Graph::Base, here's a sketch:

     Viewing [Local Mutts]
                               | [Mopsy]
[Spot]  |______________________| [Rover]
[Molly] |      [ Fido ]        | [Gus]
                               | [Jack]

            [AKC Registry]
           [Fictional Dogs}
[download]

This local approach can handle circularities and self-loops as easily as the more sedate database you describe.

Update: Some corrections for Graph::Base calling conventions.

After Compline,
Zaxo

I'm sure you've already thought of something along these lines, but I didn't see it mentioned. So...

I presume you have an easy way to know whether or not a given node has multiple parents? Assuming so, I have provided a "pivot" button in similar situations, one that takes the currently selected node and "reverses" the heirarchy, e.g. instead of showing the children, it shows the parents "belonging" to the child.

For example:

Books
  + Perl [ *Pivot* ]
  + Unix/Linux
  + SomethingElse
Reviews
Tech Sites
  + Perl 
  + Unix/Linux
  + SomethingElse
[download]

Becomes:

Perl
  + Books
  + Tech Sites
SomethingElse
Unix/Linux
[download]

Implementation tends to be fairly straightforward, if you're using a reasonably well-designed database/schema.

I've also found this to be a really interesting way to allow users to learn your heirarchy.

--f

People often think this is the way to handle cross-linked hierarchies. I think what Yahoo does makes more sense, essentially having symlinks to the other nodes rather than a standard parent-child relationship. Having multiple parents means you can never know your context (for something like a breadcrumb trail back up to the root node) without keeping a complete history of every node a user has visited on the way to this one.

The last time I had a problem like this was at an e-commerce site (see if you can guess which one) where we were trying to deal with the fact that a section like "new Pokemon junk" might need to show up under multiple areas in the store and the merchants controlling it don't want to keep track of that and double enter it. An obvious requirement for multiple parentage, but I saw all kinds of implementation problems with it. After trying various things, I ended up making two trees, one for concepts like "new Pokemon junk" with products attached, and one for site layout. The nodes on the concept tree were mapped many to many onto nodes of the layout tree. It sounds complex, but it was less confusing than multiple parentage and it was plenty fast in oracle.

hear hear

I bet the multiple parentage requirement is editorially-driven? I'd go for a symlinking mechanism rather than genuine multiple parentage, if you really want to keep a close match between visible and underlying structures. If not, create a layer of abstraction between the two, as perrin suggests.

One of my old employers is still, five years later, suffering from my conviction that there was a logical structure into which everything would fit and that once we'd built it, all we would need to do is show it to people. It turns out that editorial content isn't really like that :(

You can find it here (example purely coincidence).

HTH,

Jeroen
"We are not alone"(FZ)

Thanks for pointing that one out. And that would work fine for focus on one node, except that the result of a search will be perhaps many distinct nodes, some of which will share parentage, and some of which will have distinct parentage. That darn "0 or more but usually 1" parent thing gets in the way.

And yes, I agree with perrin on this one, but the client has chosen to mix links of both "is-like-a" and "contains-a" in the same syntax net. Ugh.

-- Randal L. Schwartz, Perl hacker