I have always viewed tags as completely different than the normal folder hierarchy model. I am building a system that needs tagging to tag sets of data. We had the db design all worked out, (pretty straightforward model) but a debate arose around the value of still having concepts of hierarchies within a world of tags.
On SOF, as an example, the only equivalent I see some of this by using - in some tag names like tagging; jquery, jquery-ui, jquery-ui-dialog so there is no inherent modeled relationship (just a naming convention).
Is there any conventional wisdom of best practices around how and if hierarchies should exist in a world of tagging?
I developed a portal that involved hierarchical tags. I can assure you that is a mess to manage :)
My solution then moved to a hybrid approach in which tags can be stand-alone or hiearchically handled but they reside in two different namespaces.
This because some tags can be seen as children of parents of other tags while others cannot, so for example dialog tag is a concept that is also indipendent from jquery so a content with both tags jquery dialog has implicitly the relationship needed.
Hierarchical should be used to express a kind of inheritance between concepts, eg. collections -> trees, lists, maps in which trees tag can be effectively included inside a collections tag.
In your example dialog and jquery are orthogonal and uncomparable, so it makes no sense to make one child of another.