LocalLink

Local links are links to pages on the same site. Traditionally, wikis used very simple markup that was easy to write: WikiWords. Some people did not like CamelCase and wanted spaces in their links and page titles, and other people used scripts that don't use upper- and lowercase (Arabic, Hebrew, Chinese, Japanes, Korean, etc). Thus, FreeLinks were created.

CategoryLinking CategoryWiki

Discussion

I wonder whether local links are good tags? [1] In other words, make every single link a category using rel="tag". [2] This way, wikis could participate easily in the folksonomy hype [3] without requiring any extra thought.

I think using our existing categories would yield very broad tags that are practically useless for searching.

I don't understand the idea- do you mean, instead of going to a given page, a LocalLink would go to a collection of pages?

Assume you visit http://www.technorati.com/tags/ and search for "linking". Would you expect to find this page? This page belongs to the CategoryLinking.

How could we make tag search more useful? How about using every single page on this wiki as a category, and treating every single local link as a category? Then this page would belong to WikiWords, CamelCase, FreeLinks, CategoryLinking, AlexSchroeder, LionKimbro, and LocalLink.

Would it be better or worse?

Rrr…

I do like the idea of our pages showing up in Technorati.

I'm not so sure I like this page being tagged with "LionKimbro." Because I would like "LionKimbro" things to be about Lion Kimbro, the person, rather than "here's everything in the wiki that includes the text LionKimbro."

The category tags seem better to me. They may be broad, but not nearly as overly-broad as just text snippets. The ForwardIndex is even better, but we'd require WikiMetaData, because we point to pages that aren't indexed in the ForwardIndex in the page that holds the ForwardIndex.

Assume for a moment that this was the only page you wrote on the web. Should Technorati not find it? If you wrote two pages, should this page not be on the list, even if second place? Now think about it: You wrote a thousand pages. Clearly this page is not on the Top 10 – but it should be in there somewhere.

That's why I think tagging this page with LionKimbro is worth it.

Similarly, you could then ask the engine: What posts in the last 24h are related to Lion? And it would find this one. Would it not make sense?

Hmm, I agree with Lion that doing this would put pages in a lot more "categories" than you want.

I agree that this page should be tagged "linking" because it contains the word "CategoryLinking".

If a user wants to search for all pages with the word "CamelCase" on them, they'll use a keyword search engine like Google. If they use tags, then they are looking for things which a human categorized as CamelCase.

However, your suggestion does lead to me to suggest a different feature; there should be a bot that goes through and detects wiki pages which are reciprocally linked, and then makes a list of them to suggest to the user (or to the wiki community, via a bot-controlled web page) that they be added as "see also"s.

And then there should be a bot that builds a graph of the "see alsos", identifies clusters which are not already categories, and suggests to the user that new clusters be created. It could also detect pages which "should belong" to some existing category but which aren't in there yet.

A blogger convinced me that this is not true. From my blog:

At Wikimania 2005 I had a talk with a blogger about tagging. I claimed that tagging was useless because the broad tags I was using (Wikis, Web, Switzerland, Iraq) are good for organizing my blog, but no good for finding related information. The blogger then said that he used it a lot for his own research on a daily basis, but with a lot more detailed tags: Names of people, locations, and events.

Thus, using such a broad category as "linking" is practically useless. Technorati is a kind of search engine.

If you're looking for fine-grained categories, then the page names themselves would be the appropriate tag name for those pages. After all, one wiki page contains many "posts" made by different people at different times. On a wiki, we use pages to group our posts instead of "forums" on a discussion board or "categories" on blogs.

However, one page might belong under multiple "tags" – which is what you're trying to get at by tagging with forward links. But I still think there are too many forward links for that to work (too little SignalToNoise). I agree that many times the only way to tell that page B belongs in the tag given by the title of page A is when there is a hyperlink from page A to page B, but unfortunately, there are so many other reasons to hyperlink that we can't use that.

One additional thing we could do would be to use "see also" links; that is if page A contains "See also …, page B, …", then page B should be tagged "A".

I've also toyed with the idea of using [[tag:Foo Bar]] to mark some links as tags, but basically I think the system should be even easier to use.

Taking local links is very much like the WikiContextualLinking to automatically determine namespaces in ChrisPurcell's PeriPeri. He, too, uses all the local links available on a page.

So where as I agree that an ordinary page will generate a lot of metadata (a large number of tags it belongs to), I'm not convinced that we're really reducing the SignalToNoise ratio.

Take this page for example: Do you not think that this page is in some way related to SignalToNoise? So why not use it? Doesn't this page belong into the WikiContextualLinking category in some way?

I think our category tags are a way of organizing the site: Using them, we find the ForwardIndex that we need, or the BackLink search we need if the index is no good. In real life, however, I use backlink search from ordinary pages a lot. So clearly I personally think that finding all instances of incoming links is interesting, although it would be nice if the pages were ordered by relevance. On a wiki with Oddmuse:Indexed Search, that's exactly what happens. And the result is good enough! So if it is good enough for searching our site from the inside, why should it not be a good solution for searching our site from the outside?

I don't dispute that there's valuable information in the set of ForwardLinks? on a page, and that a sufficiently clever AIWiki:MachineLearning algorithm could put that to information to work to better satisfy user queries.

However, that does not imply that throwing all of these links into technorati will increase its performance. There's always a false negative/false positive tradeoff. I think it's more likely that it will decrease false negatives a little but greatly increase false positives, and that on balance the modification will decrease the usefulness of technorati to users.

Reductio ad absurdum: your line of reasoning can be applied to argue for full-tech indexing: I also use FullTextSearch? a lot when navigating CommunityWiki. There is information contained in the set of words on a page that can assist you in finding pages about a desired topic, and some of this information is not present merely in the links. But does that imply that we should tag each page according to each of its words?

No. There is a false positive/false negative tradeoff. The whole point of technorati search is to use human-specified categories, which picks a specific point along that continuum (also along a generality/specificity continuum). The expectation that the tags given are human-specified categories probably underlies the way people use Technorati.

If you want to make use of all of the other information in a page, you can submit your site to a keyword-based search engine, like Google. This way you won't surprise people who are trying to search for categories on Technorati.

However, I must admit that I don't use Technorati search, unlike your blogger friend, so I may be wrong. Perhaps we should ask whoever administers technorati what they would prefer.

I think the reduction does not lead to absurd results – it leads to Google and similar search engines. In this respects, tags are just a overt tool to get a social process started. We know people will use a constrained namespace for tagging. Seeing other people use the same tags as we do increases our belief in the usefulness of the tag. And so tags spring into existence and are useful.

Now that I think about it this way, I think providing a automated tagging feature would unhinge this social process.

No automatic tagging, then.

Here's a silly hack idea - what if you rendered a WikiWord like this only if it was over a certain length in chars, or maybe only if it has 3+ cap letters in it? That way you'd be focusing on the subset of ForwardLinks? that are "more unusual"…

WebSeitzWiki:WikiWordAsTag, WebSeitzWiki:z2005-07-26-MarksDecentralizedTagsonomy, WebSeitzWiki:FolksonOmy, WebSeitzWiki:SocialNetworkContext

In my opinion categoryX should lead to automatic tagging with X, if categoryX is used as a tag in a page (that seem to be any categoryX categoryY .. on a single line in this wiki). Tags should be expanded by the categories the category belongs to, by the same rule.

Define external redirect: FullTextSearch ForwardLinks

EditNearLinks: PeriPeri WikiContextualLinking CamelCase FreeLinks SignalToNoise WikiWords WikiWord

Languages: