Wikilink use-cases

I'm a big fan of semantic markup and miss the inline query functionality of SMW, properties, and data types. I know that one of the goals of "The Platform" is to create a technology-independent ontology that uses a minimal set of markup available in various CMS platforms, including wikis. But it isn't so simple as I'd like it to be. Wordpress and similar CMS' have categories and tags, while WikiMedia has only categories. SMW has categories and semantic markup, which I think can be abused in a fashion to create tag-like structures. Additionally, on this site we have RecordAdmin, which seems to give some similar functionality to semantic query, but can't be counted on to be available on other platforms (just as so the SMW extention) and I think the use-case for RA is not intended to substituted for SM. For this reason, I have tried to devise uses for categories that suit different use-cases like tag clouds and semantic markup. It hasn't been easy. Actually, I have been mulling these issues over for a few months, but this is the first time I have attempted to do so in writing.

One of the things I don't like about using category is the case where an article should belong to multiple categories not in a hierarchy, for example, tag clouds. I consider attempting to do so a misapplication of categories, plus, it introduces a lot of repetition that can easily become outdated when the context for a tag is removed from the related category in the header. MediaWiki doesn't have this separate use, and furthermore, I find annoying the verbosity of repeating the category markup multiple times in the header of an article, e.g.: [[category:x]][[category:y]][[category:z]]. I thought that tags should be tightly coupled with the context, that is, the keyword is the tag.

For this reason I created two templates: {{tag}} and {{tags}}. Orginally my intention was to use category like a tag cloud markup and avoid the surreptitious use of category.

Then I saw that tag can be used to mark keywords inline and leave a visible link in context meanwhile creating or linking to a category by the same name. Second, {{tags|a|b|c|d}} was meant to quickly mark a page for keywords but make them hidden in context. Links implemented this way should naturally belong in the category hierarchy tags>tag, but I did not implement this because very often the 'tag' function naturally overlaps the 'category' function. Nevertheless, the essential difference is that tags are not necessarily hierarchical as is the intended use of categories.

The philosophy behind this use is certainly different than the hierarchical use of categories, and although I have not discussed it with the other guys on the site, no one's complained so-far ;). What I have observed is that from regular use of tags emerges an entirely different structure than categorizing an article into one or a few classes.

What I really need here are diagrams, but for the time being, I'll try to use words to express what I see in my mind's eye, for different use cases.

Internal links

Not much needs to be said about this; the essential function is to link a key word to another page, creating a one-to-one link

• the link is in context
• the link is only unidirectional; there is no easy mechanism for a backlink from the target to the source.
• the link is from a key word in context to an entire page; this is useful for expansion of a term.

See also: sections

On this site we have a prevalent use of the see also section in articles, where links are loosely grouped instead of in context. This certainly is another separate use case that I think we should specify clearly. I think this practice emerged in wikipedia specifically -- in some cases, for lack of a better alternative like tags or semantic markup.

• What often emerges from this practice, are pages or sections that are essentially huge lists of links to other pages, e.g. Money
• the list of links are not in context
• the links are unidirectional
• the list itself is essentially one-to-many - if grouped properly and not too long, a valid use case

Categories

• Categories indeed are suited for classifying, typing, or grouping a collection of pages.
• Consistent use of categories create a link to a list of pages in the same category, or;
• Create a list of wanted categories that a) do not exist and legitimately should exist or b) should not exist because they already exist in the form of a different convention
• Are essentially plural
• Can and often should emerge a classification hierarchy, or ontology
• Category links are not in context, and as a key word, apply to the entire page
• Lots of categories for a single page introduces verbosity
• Over time categories can become disconnected from the content that introduced the need for it
• When multiple pages belong to the same category, the category page functions as a bi-directional, many-to-many link (that is nicely indexed alphabetically)

Tags

• tag links create a list of related pages, just the same way categories do
• they also create wanted links that can be gardened later
• however, tags are in context and tightly coupled with the content that generates the need for a category
• using tags inline reduces redundancy and code verbosity
• using tags inline allows one to focus on content rather than the distraction of verifying the existence of categories, and easily exposes the need for new categories or the creation of redirects, disambiguation pages, articles, or ontological hierarchies
• consistent use of tags emerges a bi-directional, many-to-many structure