Has there been an implementation of a tag hierarchy with graph edge relations?

Question

When organizing information it is common to use either a hierarchy or tags. An element in a hierarchy is ordered within a predefined category and relates to other elements as above, below or at the same level. The only direct link between elements in an hierarchy is its immediate superior and the elements subordinates.

Tags on the other hand are non-hierarchical keywords assigned to an element. There are no links between tags, and elements can have tags on different hierarchical level which in a strict hierarchy would not be possible.

Paul Heymann and Hector Garcia-Molina wrote a technical report in 2006 on the tag hierarchy topic with the title "Collaborative Creation of Communal Hierarchical Taxonomies in Social Tagging Systems". They came to the conclusion that it is possible to have relations among tags in several hierarchies, linked by top level connections and noisy edges (see image from their paper):

^{Fig 1: Latent Hierachical Taxonomy. Haymann and Garcia-Molina 2006}

At first glance this is a graph representation, which could very well be used on tags in any tagging system. It would place tags in a strict hierarchy (when appropriate) and provide noisy edges or top level connections when linking relational between different hierarchies.

From my point of view it could be used to improve navigation not only using the standard hierarchical navigation and/or tags, but also use a tag hierarchy. It would place tags within a context, which from a usability perspective could improve users ability to find information.

But from what I know, the implementation of this or similar model have not yet been done. Have there been an implementation of a tag hierarchy with graph edge relations?

Answer 1

My company's product uses several entities that work like tags and form graph-ish tree structures, much like your example shows. (The product isn't public, so I can't get too detailed, sorry.)

From a UX perspective, the main win that we've found is that the system is very flexible and can often describe more complex subject matter than a flat tag list or a simpler tag tree, which in the problem space we are in is valuable.

The con's with a system this sophisticated, however, are substantial. (In fact, I am constantly trying to figure out how we can get rid of the complexity b/c of user confusion.) Users understand flat lists automatically, trees with some effort, and graphy-tree-thingies with much more effort.

A few key points:

• You needed a diagram to explain the relationships to us
• Per @yitznewton, libraries (and related metadata specs) have struggled to gain traction with these sort of systems for decades.
• It's just plain complicated. See: If your program model is nontrivial, it's probably not the user model.

That said, if you control the data structure for the user, and the user never needs to understand how it works in order to use it, you might be helping them out more than hindering. On the other end of things, if you expect it to be user managed, expect big trouble.

I often find that when you find taxonomy getting complicated, you are better off funneling users towards search, sort, and/or filter.

Answer 2

Book metadata generated by librarians includes subject headings, which are a hierarchic controlled taglike system. The main implementation (Library of Congress Subject Headings, or LCSH) is clumsy, but the library community has been working in this area for decades. Check out http://id.loc.gov/

Answer 3

I don't know if you're asking for some tool to make the visualization, but maybe here's an answer.

Well, the InfoViz/TheJit library for JS does exactly what you're asking for. It takes a hierarchical JSON feed.

Answer 4

I'm still not sure I understand what is being asked...for an example implementation of drawing a visual representation of the taxonomy?

That being said, my product does exactly this. It asks the data-model-builder to organize information along physical lines (in my case, see isa-95.com), while often the person using the system wants to see a comparison along functional lines. The example would be the difference between asking for a "pump" (an object in the hierarchy), or asking for objects that contain a "flow" variable, it might include pump, valve, pipeline, etc.

Because of these two common uses, we allow both navigation by hierarchy and by tag.