Difference between revisions of "Wikilink use-cases"
From Organic Design wiki
Infomaniac (talk | contribs) m (→Tags) |
m |
||
| (22 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ;Category, tag, see also, semantic markup | |
| − | + | I'm a big fan of [http://semantic-mediawiki.org/wiki/Help:Introduction_to_Semantic_MediaWiki semantic markup] and miss the [http://semantic-mediawiki.org/wiki/Help:Inline_queries inline query functionality], properties, and data types of SMW. 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 extension) and I think the use-case for RA is not intended to be a substitute for Semantic Markup. 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. | |
| − | + | ==categories as tags== | |
| − | + | 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 and can easily become outdated when the context for a tag is removed (to another page, for example) from the related category in the header. I thought that tags should be tightly coupled with the context, that is, the keyword ''is'' the tag. | |
| + | MediaWiki doesn't have this separate use case. | ||
| − | + | Furthermore, I find annoying the surreptitious use of ''category'' markup in the header of an article, e.g.: <nowiki>[[category:a]][[category:b]][[category:c]]</nowiki>. | |
| − | 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. | + | For this reason I created two templates: [[:template:tag|<nowiki>{{tag}}</nowiki>]] and [[:template:tags|<nowiki>{{tags}}</nowiki>]]. Orginally my intention was to to quickly mark a page for ''multiple'' keywords but make them hidden in context - essentially, to easily create multiple categories: <nowiki>{{tags|a|b|c}}</nowiki>. |
| + | |||
| + | Then I saw that ''tag'' can be used to quickly mark keywords inline and leave a visible link in context ''to a category'' (or wanted category) by the same name. | ||
| + | |||
| + | 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 classifying an article into one or a few categories. | ||
| + | |||
| + | 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 the different use cases. | ||
==Internal links== | ==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 | + | Not much needs to be said about this; the essential function is to link a key word to another page (or wanted page), creating a '''one-to-one''' link |
*the link is '''in context''' | *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 only '''unidirectional'''; there is no easy mechanism for a backlink from the target to the source. | ||
| Line 19: | Line 28: | ||
==''See also:'' sections== | ==''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. | 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]] | + | *What often emerges from this practice, are pages or sections that are essentially huge lists of links to other pages, e.g. [[Money]], [[Documentaries]] that should become categories or tag clouds (see below) |
| − | *the list of links are '''not in context''' | + | *the list of links are '''not in context''' (or only in the general context of the entire page, basically what a ''link-to-category'' is for) |
*the links are '''unidirectional''' | *the links are '''unidirectional''' | ||
*the list itself is essentially '''one-to-many''' - if grouped properly and not too long, a valid use case | *the list itself is essentially '''one-to-many''' - if grouped properly and not too long, a valid use case | ||
| Line 26: | Line 35: | ||
==Categories== | ==Categories== | ||
*Categories indeed are suited for classifying, typing, or grouping a collection of pages. | *Categories indeed are suited for classifying, typing, or grouping a collection of pages. | ||
| − | *Consistent use of categories | + | *Consistent use of categories creates links to a list of pages in the same category, or; |
| − | * | + | *Creates 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 |
| − | * | + | *Categories are essentially plural in nature (and name) |
| − | *Can and often should emerge a classification hierarchy, or ontology | + | *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) |
| − | *Category links are '''not in context''', and as a key word, apply to the entire page | + | *Category pages ''act as a hub in a star topology'' consisting of all pages related by belonging to the category |
| − | + | *Can, and often should, emerge a classification hierarchy, or ontology | |
| + | *Category links are practically invisible - they are displayed at the bottom of the article and not easily noticed. | ||
| + | *Thus, category links are '''not in context''', and as a key word, apply to the entire page and are recorded in the header (or section zero) - no matter how huge the page becomes or what content qualifies the page to belong to a category | ||
*Over time categories can become disconnected from the content that introduced the need for it | *Over time categories can become disconnected from the content that introduced the need for it | ||
| − | * | + | *Lots of categories for a single page introduces verbosity |
| − | ==Tags== | + | ==Tags (link to category)== |
*tag links create a list of related pages, just the same way categories do | *tag links create a list of related pages, just the same way categories do | ||
| − | *they also create wanted | + | *they also create wanted categories that can be gardened later |
| + | *like categories, form the ''hub of a star topology'' | ||
*however, tags are '''in context''' and tightly coupled with the content that generates the need for a category | *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 reduces redundancy and code verbosity | ||
| − | *using tags inline allows one to focus on content rather than the distraction of verifying the existence of categories, | + | *using tags inline allows one to focus on content rather than the distraction of verifying the existence of categories, |
| + | *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 | *consistent use of tags emerges a '''bi-directional''', '''many-to-many''' structure | ||
*pages can participate in more than one network of tags in fine-grained context | *pages can participate in more than one network of tags in fine-grained context | ||
| + | *the "tag cloud" appears in the page's category list | ||
| + | [[Category:Help]] | ||
Latest revision as of 17:41, 19 October 2014
- Category, tag, see also, semantic markup
I'm a big fan of semantic markup and miss the inline query functionality, properties, and data types of SMW. 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 extension) and I think the use-case for RA is not intended to be a substitute for Semantic Markup. 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.
Contents
categories as tags
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 and can easily become outdated when the context for a tag is removed (to another page, for example) from the related category in the header. I thought that tags should be tightly coupled with the context, that is, the keyword is the tag. MediaWiki doesn't have this separate use case.
Furthermore, I find annoying the surreptitious use of category markup in the header of an article, e.g.: [[category:a]][[category:b]][[category:c]].
For this reason I created two templates: {{tag}} and {{tags}}. Orginally my intention was to to quickly mark a page for multiple keywords but make them hidden in context - essentially, to easily create multiple categories: {{tags|a|b|c}}.
Then I saw that tag can be used to quickly mark keywords inline and leave a visible link in context to a category (or wanted category) by the same name.
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 classifying an article into one or a few categories.
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 the 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 (or wanted 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, Documentaries that should become categories or tag clouds (see below)
- the list of links are not in context (or only in the general context of the entire page, basically what a link-to-category is for)
- 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 creates links to a list of pages in the same category, or;
- Creates 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
- Categories are essentially plural in nature (and name)
- 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)
- Category pages act as a hub in a star topology consisting of all pages related by belonging to the category
- Can, and often should, emerge a classification hierarchy, or ontology
- Category links are practically invisible - they are displayed at the bottom of the article and not easily noticed.
- Thus, category links are not in context, and as a key word, apply to the entire page and are recorded in the header (or section zero) - no matter how huge the page becomes or what content qualifies the page to belong to a category
- Over time categories can become disconnected from the content that introduced the need for it
- Lots of categories for a single page introduces verbosity
Tags (link to category)
- tag links create a list of related pages, just the same way categories do
- they also create wanted categories that can be gardened later
- like categories, form the hub of a star topology
- 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,
- 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
- pages can participate in more than one network of tags in fine-grained context
- the "tag cloud" appears in the page's category list
