Hypertagging attempts to simplify things.
The basic idea is to go back to basics. Del.icio.us introduced tag bundles, but this is similar to what SL did with subpages: there it ends.
I use ClearCase? and played a bit with CVS (these are wikipedia:sourcecode versioning tools); now at the company we are moving to SVN, and there I discover that branches nor tags need to be "special" objects, but rather what imagination makes of it (and meanwhile Git became the norm :-) ). So I thought: how about removing those special tags, remove the asymmetry between pages and tags? Also, the current concept of subpages is outdated and cramped.
Another observation: as far as I remember, I mostly tend to navigate SL by searching for a word, or via the small list of favorites in this SL left-hand column (or maybe via RC). This illustrates that there is a lack of structure on SL to quickly find interesting data; keywords are limited and harcoded, so a flexible tag concept becomes interesting.
Enter hypertagging: there are no tags, pages are tags
- Make tags the general and only way to organise objects. This should simplify SL code?
- Demote existing page types, difficulty and keywords to common tags. group those tags under a "system" tag (i.e. tag those tags with the tag "system"). consider NOT restricting manipulation of these tags to admins (users can already use those tags, but they should also be allowed to add new tags to the system tag).
- here's the best part: tags and pages are the same. Therefore, there is no need for tag objects any more. Indeed: a page is a text string (the page name) and content. A tag has a name (a string in the most general way is still a tag) and - usually missing - explanatory content. Once it has content, there is no difference any more with pages. Conclusion: remove the tag concept alltogether (from wiki source code), allow pages to be used as tags (and introduce the hypertag concept in code...). Equating tags to pages allows to create various kinds of structures - including the current structure. SL is already a bit of a jungle, why not admit and encourage this? Yes, I know this doesn't sound very structured at all.
- I guess the concept of discarding tags as separate entities already exists somewhere. Otherwise I'll claim the term "hypertagging" to describe the concept. Paradoxally, there are no longer tags in this view - as every page can be used as a tag.
- There are no such things as "meta"tags: tags can organise themselve (eg page type tags, keyword tags, difficulty tags).
- There is no strict hierarchical ordering of pages: similar to hyperlinking, hypertagging introduces a mesh of relationships between pages.
Calling up a page then presents (three, or more) sections and allows for a new way to navigate the wiki:
- tags attached to the page (page tags, also called parent tags)
- page content with normal hyperlinks to other pages.
- pages tagged with this tag/page (this can express child pages, subtags) (note that this can also describe paths - another candidate for removal)
(optionally: a fourth section listing pages that link to this one (backlinks) (FIXME: this is quite close, yet different to the third section)
The advanced find page becomes much more simple now - it's a matter of selecting the right combination of keywords.)
- a page tag (actually the relationship between page and tag) could have a fuzziness factor, to express how related the page is to the tag. when listing page tags, the most relevant are on top.
- Allow to create tag expressions: "show me objects that have " (tag A and not tag B) etc...
Issues to handle
notation: b <- a : page 'a' is tagged with tag 'b'
- mapping of SL's path concept to tag concept
- a path actually is a way to tag pages, using a page! in a sense, a path seems to implement the hypertag concept. but the tagging currently happens in the "tag" itself (the path page), while it should happen in the tagged page.
- the relationship between tag and tagged object could be given a name too: "parent", "related to", "see also", "part of path" ...
- tags are usually presented in drop-down boxes, populating those drop-down boxes with all pages in existence is a no-go. but presenting top-level tags (the root page is the root tag) and a tag hierarchy (in a tree dialog, rather than a drop-down) allows to navigate to the desired tag. Via several paths, BTW: as tags can be linked in various ways, an HTML page containing a tag's various relations to other tags is the better way to navigate to a tag. This can also be solved by forcing the user to create tags before using them: to "create" a tag means to tag it with the root tag; tag menus will always navigate from the root tag via child/parent relation).
- tag inheritance (parent/childs) allows to (also) express classical (tree and/or IS-A) hierarchies.
- circular tagging should be allowed ( a <- b <- c <- a), as well as self tagging (a <- a, even if that currently makes no sense to me, it might have an application). software should guard against "wild" expansions of tag trees
- support must be given to easily tag large sets of pages when a new tag is "discovered" (created): otherwise the already existing pages end up missing the tag (if applicable) because they were created before the tag sprang into life.
This might be no more than the WikiMedia Category concept, but more general.
A further generalisation: tag semantics, RDF
A tag defines a relationship between pages: a page A tagged by tag B (also a page) can mean that "A isa B".
In other words, tagging pages means defining a relationship called "is a" between pages. But more relationships exist, such as "has a", "uses", "includes", ...
Such relationships usually are bidirectional, but require a different wording: "is-a" vs "specialised in" (? is there a better term), "contains"/"has-a" vs "contained in", ...
I'll use "tag type" and "relationship type" but mean the same thing.
A system that provides hypertagging must be able to define the tag type:
- a possibility to manage (add, delete, rename, ...) relationship types: by default, "is a" (which expresses the default tag concept) is present
- a way to select from existing relationship types: when "tagging" a page with another, the user can choose the relationship. this can be implemented by having pages define a relationship, and tag that page as a "tag" page. teh page title contains two parts separated by e.g. "/" (or another symbol to avoid clashing with subpage concept), to express the two directions of the relationship
- relationships should not be special objects, but pages themselve. this allows the user not only to document the relationship, but also to create relationships between relationships... relationships are to be marked (tagged) as such so that the wiki can present the user a dropdown of relationship types when tagging a page.
- each tag type (ie the page that describes the tag type) is a the same time the root page for that type: when the user selects a tag type, the associated root page acts as a starting point from where to navigate to desired (existing) tag. any page can also serve as new tag for any other page.
Hypertagged pages will present one section per tag type (rather than the earlier mentioned three sections).
Current SL mechanism can be implemented with hypertags:
- Subpages can be implemented by introducing "subpage"/"subpage of" relationship.
- To implement a path, define two relationship types: "path"/"section", and "next"/"previous". "path" defines the containement of pages in a path, while "next"/"prev" allows to navigate to sibling pages. Each new page is tagged with the "parent" path page, and is "inserted" in the existing path (which is a cumbersome and error-prone operation...)
Note that it is no longer tags that are registered, but tag types (relationships).
Tagging means associating to a set; the software must be able to say "this object is NOT part of a set (defined by that tag)". The relationship between tags and tagged objects has three states:
- tagged as included in the set defined by that tag
- tagged as excluded in that set
- no tag info for this tag