Re: [unrev-II] Semantic Community Web Portal

From: Alex Shapiro (alex@touchgraph.com)
Date: Sat Sep 15 2001 - 16:35:31 PDT

  • Next message: Jack Park: "Re: [unrev-II] Re: Graphs in Web Community Tools - forum?"

    At 04:31 PM 9/14/01 -0700, Eric Armstrong wrote:

    Alex Shapiro wrote:

    >  Have you
    >
    >> > checked
    >> > out this paper by the
    >> > way? http://www.cs.vu.nl/~frankh/postscript/VSW01.pdf What to you
    >> think?
    >
    The examples in this paper appear to me to reinforce the principles I
    posited
    in a post quite a while back. Graphics work when there is
      * a small set of
      * fixed data types
      * small sets of relationships

    That allows one icon to be associated with each type. The graph can then
    show
    patterns or locations of the items. Graphs run into problems in one of
    three ways:
      1) When the number of types grows large, there are too many icons to
    keep track of, and no meaningful patterns emerge.

    But there does not have to be too many types.  IBIS for instance has only a handful of types for nodes.

      2) When the number of relationships grows large, the intersecting
    lines in any graphic representation turns the picture into a confusion.

      3) When the number of entries grows large, items are far removed from
    each other, and the other end of any given relationship is rarely
    visible in a given display area.

    The above two are true when the number of entities/relationships shown ON SCREEN is large.  There are a number of approaches to reducing the number of nodes displayed, through filtering/other means.

    Reducing the number of nodes on screen, while maintaining a host of other properties is what my research is focused on. 


    I note that the examples used in this paper have exactly two data types:
    a location
    at the top level of the hierarchy, and something else (presumably a
    "job" type) at
    the second level of the hierarchy. I note that no information about the
    job is
    contained  in the graph. So the "information content" only goes one
    level deep.

    The interesting thing, is that the location + job type ontologies do not form a first and second level of a hierarchy.  They coexist, forming a multiple hierarchy.  The paper demonstrates one way of simultaneously showing the two, one is displayed using location the other through color.  But there are other ways, for instance using location to simultaneously show subsets of both.

    [----]
    At the second level of the hierarchy, the *only* information is the
    number of jobs.
    (Assuming that I am correctly interpreting the intent of the diagrams.)
    The
    individual bubbles would be useless for keeping track of jobs. They are
    already
    getting small and hard and select.

    One could zoom in to make them easier to select.

     And it would take different types of
    icons to
    present any useful information.

    Icons, colors, pop-ups with information, labels appearing on zooming.

    Given these limitations, I don't see how graphing techologies apply at
    all to
    collaborative design/discussion tools or a knowledge base, given the
    huge
    volume of information such a tool needs to manage, the vast array of
    information types, and the exponentially exploding number of
    interconnects.

    I don't know about this vast array of interconnections you speak of.  The current thread structure of forums is a series of small trees.  In my mind, any improvement would be welcome.

    Perhaps TheBrain has something that could provoke a change of mind. I
    can't say I've seen it (or recall what I saw, if I did). But as a simple
    example,
    how would any of the information contained in this message be captured
    in
    a graph? Were it done, in what way would such a graph be of use to
    anyone?

    I might have said this earlier, but I don't advocate graphing at too far below post level.  Something that could be done, is to look at the granularity at paragraph level.  Purple-numbers address the issue that a user might refer to something that has been said in the middle of a post.  If an email addresses multiple issues, then something that might be nice, would be to allow responses to parts of an email, rather then a whole email.  Visually, the original post would be a node, paragraphs would be satellite nodes, and one could chose to respond by linking to the central node, or to a satellite node.

    I simply do not see graphing technology as useful in any substantive way

    in a knowledge-engineering context. It's GREAT for visualizing small
    systems, which makes it a wonderful tool for teaching. It gives people a

    mental model of the systems. But in actual use? I'm still inclined to
    pass,
    I'm afraid.


    I happy that you're skeptical.  It gives me "job security".

    I do appreciate your comments though.  Thanks,

    --Alex
    Yahoo! Groups Sponsor

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe:    unrev-II-subscribe@onelist.com
      Unsubscribe:  unrev-II-unsubscribe@onelist.com
      List owner:   unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II

    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

    This archive was generated by hypermail 2.0.0 : Sat Sep 15 2001 - 16:15:22 PDT