Connected graphs [was RE: Dimensions?]

[Christopher Browne]

On Thu, 28 Sep 2000 10:30:24 +1000, the world broke into rejoicing as
"Phillip Shelton" <shelton@usq.edu.au>  said:
> > I tend to think that interpreting these kind of complex relationships
> > is not really the domain of the engine at all - it's the domain of the
> > individual reports that interpret the data in the engine in different 
> > ways.
> 
> It appears that we are writing our own database software.
>  
> > As for the user interface question, ideas are rolling around in the
> > back of the head, but you're right, it is *nasty*.
> 
> Does it impinge on the way the records are stored?

That's likely the _easy_ part; if there is a more complex "view,"
the worst case is to have something applicative that basically walks
through all the records in the database and says, "Does this record
match my criteria?"

The problem is that describing the criteria in a coherent way such
that you can assemble this into a useful report will be problematic.

For instance, suppose you want to have a report on different sorts
of clothing.

- There's the "footgear" section, where we collect together "Shoes,"
  "Socks," and "Boots."  (Which might be three accounts.)

- There's the "pants" section;

- The "jacket" section;

- The "Hats" section;

- Then everything else fits in as "Other Clothing."

So far, so good.  But two issues leap out:

a) What if I have an account that matches more than one area, say
"Shoes and Boots"?  I wouldn't want to double count that, but will
need to be pretty careful lest that happen.  How about the
"Socks and Toques" account, arranged together because both involve
wool?  Does that go to footgear, hats, or "other"?

That's the 'engine side' stuff.  The examples are a bit contrived,
but there is still the danger of accounts fitting in more than one
place, at which point ambiguity leaps out.

b) What kind of a user interface do you put on front of this?

If it's all a tree, it's easy enough to say "It's a tree of depth
3; roll it up to being 2 levels deep," or "I only want 2 levels of
hierarchy," or some such thing.  The notion of making it a tree,
and clicking on nodes to expand out the children is so obvious that
the GTK library includes a widget designed for that very purpose.

But the grouping suggested above for clothing requires that we
introduce, for a not-dramatically-complex report, a sort of 
"set grouping" language where there is some sort of way of 
adding in rules to make ambiguities no longer ambiguous.

Anything you do will require thinking about those annoying Venn
diagrams from "New Math" :-(.

I tend to consider the terms "point and click" and "twit" to be
pretty strongly correlated, but would rather see a tree that is
simple enough to click on and expect fixed behaviour than fight
with general trees for this purpose...
--
cbbrowne@acm.org - <http://www.ntlug.org/~cbbrowne/linux.html>
"War is  a matter of  vital importance to  the State; the  province of
life or death;  the road to survival or ruin. It  is mandatory that it
be thoroughly studied."  -- Sun Tzu