(redirected from FreeLinks)

FreeLink

MeatballWiki | RecentChanges | Random Page | Indices | Categories

A FreeLink allows a flexible combination of characters, letters, digits and punctuation (different wikis vary in what symbols they allow), unlike e.g. CamelCase which is restricted to the English alphabet and which must alternate capitals and lower-case in a particular pattern. This allows much more freedom in naming pages, which can be highly advantageous in e.g. an encyclopedia or a dictionary, but demands ad hoc standards when creating a PatternLanguage.

Because the FreeLink syntax is so flexible, they must be marked up with a special syntax. This could be [a link], [[a link]], _a_link_, or a number of other regular patterns. This is in contrast to both CamelCase and DynamicLinkSyntax (e.g. CommunityWiki:PlainLink).

Discussion

A FreeLink, at least in a closed PageDatabase like a wiki, means that the LinkPattern is fully open. Any string of characters can be a link. The WorldWideWeb's HREF's (now xlink:hrefs) are FreeLinks.

: Not exactly. There are many characters that are not allowed in URIs. Perhaps you were referring to the descriptive text of the link? In the UseModWiki sense, only 4 more valid characters are added. Most of the freedom comes from allowing arbitrary spaces and capitalization.

For instance, instead of restricting all links resolve to the CamelCase pattern we have here (e.g. "FreeLink", "CamelCase", "LinkPattern"), we could make a link to "I feel that arctic cod tastes really good."

: ...or for that matter to "Free Link", "Camel Case", "Link Pattern", or "Arctic Cod".

On a wiki, this means that unlike the restrictive LinkPattern commonly used, the wiki can make pages with any name, including a page named "I feel that arctic cod tastes really good." While the argument is that this detracts from AccidentalLinking, many people still seem to use them. WikiPedia could really benefit from this given their requirements, for instance. Indeed, the restrictive pattern is actually detracting from AccidentalLinking on their site.

CamelCase WikiNames tend to belong to the page the name represents

Free-formed links lead to clutter in the link name. With free-formed links, the link name tends to depend on its referring context (like the caller of the method/function) because it's easy to _(make the link flow) with the surrounding text. This is kind of a top-down approach where new pages are only created to clarify existing pages.

With a strict link pattern, on the other hand, the name tends to belong to the page that the name represents (the actual method/function itself). It's easier to fill in content for a page, or write a method/function, if the method/function can focus on what it's doing and totally ignore how it is being used outside. Indeed, it is the method/function that defines how it is called and the callers are responsible for getting it right. Same here. You want to lose context in the link pattern. This is more of a bottom-up, compositional strategy.

This is just like using Haiku or CRC cards to consolidate, clarify and crystalize ideas. They force you (by being a pain in the butt) to use the lowest energy solution possible.

More power isn't always a good thing, or else we'd all be hacking in assembly. -- SunirShah

With free-formed links, the link name tends to depend on its referring context because it's easy to _(make the link flow) with the surrounding text.

V. true. I don't have a good solution, although I observe in passing that the problem will likely occur mostly with pages that don't have Capitalized Titles. -- DanBarlow

The important part is that words smashed together in any way -- ie. without whitespace -- also form a token visually. This makes linking more deliberate, as the name does not flow easily with the text. It stands out visually as one term. Therefore, the following make good link patterns:

_wiki_names_ wiki_name wiki-name

And the following make bad link patterns:

_(wiki names)_ [wiki names] [[wiki names]] {wiki names}

Accidental Linking

: "The cost is that AccidentalLinking is broken badly now."

Free links break accidental linking, because the increased freedom in page naming reduces the chances of accidentally using the same page name in a different context. This happens anytime you have to make a choice between two syntactically different yet semantically identical identifiers. See AccidentalLinking for a discussion whether creating links "by accident" is actually something to be desired or not.

It seems that the "accidental" goals are more a function of choosing good names rather than the link syntax. General phrases (especially noun phrases like "arctic cod") are more likely to be useful in other contexts. The specific syntax of the links (ArcticCod? vs [[arctic cod]]) is less important.

One concession to AccidentalLinking is that all FreeLink pages have their first letter capitalized. This lets one write sentences like "[[Arctic cod]] is a kind of fish." and "Polar bears eat [[arctic cod]]." which will both link to the same [[Arctic cod]] page.

The WikiName convention encourages shorter names because it requires work proportional to the number of words, and because long WikiNames are hard to read. Perhaps the Wiki:WikiNature requires these constraints. Not all sites want to be wikis, however, and I am not very interested in enforcing the limitations of wikis.

Flow

Many people feared that free linking would make linking to other pages difficult, since longer page titles are harder to "inline" into a sentence. The natural tendency of people to use meaningful page titles -- even when using Free Links -- results in less problematic links than the community expected in the beginning. Neither TrikiWiki? nor WhyClublet experience much accidental linking, yet both are arguably successful wikis. Therefore, it makes no sense to worry whether "I love arctive code!" is a good page title, and whether it can be used in the middle of other sentences.

A good way to use longer page names when linking without breaking the flow of a text has been used in paper publishing for a long time, now.

Use footnotes
Parenthesis (see Using Free Links).
Partial sentences, see Using Free Links.
Normal sentences. See Using Free Links.

Balancing Forces

This abstract discussion isn't really interesting in the particular case of UseModWiki's implementation. It's far better for UseModWiki to allow whatever its users demand. I am using it as an example because it's new and this site has a tradition of supporting the UseModWiki script for obvious reasons.

Instead, I'd rather talk about the various BalancingForces at play, in order to think about what a good LinkPattern might be or even that the basic concept of a LinkPattern is broken to begin with. After all, it's possible to number each node on the wiki and then use HTML-style DescriptiveLink?s. This could look like (modeled after footnotes):

[Hitch hiker's guide to the galaxy [42]]: <A HREF="wiki?action=browse&id=42">Hitch hiker's guide to the galaxy [42]</A>

Anyway, the point is that WikiWiki has the appropriate LinkPattern for its context, which doesn't work for WikiPedia for example. Picking a good LinkPattern is really important. Some places need FreeLinks. My argument is that FreeLinking makes AccidentalLinking no longer work (effectively). But even that's false.

Really, the whole point is usability. By using a TechnologySolution to enforce the linking convention, this allows new users unfamiliar with the local customs to create links that conform to some sort of local standards. However, with FreeLinks, a greater onus is on the community to maintain consistent and sane page names. For instance, it would be the very rare exception that "I feel that I really like arctic cod." [ed: ha. See, I even forgot what the link was. Of course, I really meant, "I feel that arctic cod tastes really good."] would be a good name.

: As a speaker of an inflexed language with no widespread capitalization in titles, give me a FreeLink any time. And preferably with optional alternative text. That's why, when setting up my wiki, I went for MediaWiki and [[Page title|link text]], as in "Nie miałem pojęcia, że chciałaś porozmawiać o [[Galaretka truskawkowa|galaretce truskawkowej]]!"

Discussion of the more technical aspects

UseModWiki (though not MeatballWiki) as of version 0.91 now has FreeLinking. It looks like (WikiSyntax first, emitted HTML second):

[[I feel that arctic cod tastes really good.]]: <a href="wiki.pl?I_feel_that_arctic_cod_tastes_really_good.">I feel that arctic cod tastes really good.</a>

The NoSuchPageSyntax has to be special in order to make it clear how much previous context will form the link, so that looks like:

[[I feel that arctic cod tastes really good.]]: [I feel that arctic cod tastes really good.]<a href="wiki.pl?I_feel_that_arctic_cod_tastes_really_good.">?</a>

The square brackets wrap around the whole text that will form the link. Consider what would happen if the text were:

[[I feel that arctic cod tastes really good.]]: I feel that arctic cod tastes really good.<a href="wiki.pl?I_feel_that_arctic_cod_tastes_really_good.">?</a>

What words actually will form the link? Maybe It's only "arctic cod tastes really good."

Nonetheless, notice that the current syntax sucks up the trailing punctuation. So, now the two references:

: [[I feel that arctic cod tastes really good.]]

and

: [[I feel that arctic cod tastes really good]]

are different (note the trailing period in the first link, and the lack thereof in the second).

While the script may pick this syntax out, it shouldn't really. It's a free link, after all. The cost is that AccidentalLinking is broken badly now. But really, what's the correct way to link to "i-mode" using MeatballWiki's LinkPattern? (IModeProtocol? is probably the best, but it's really non-intuitive). For phrase titles, like "FreeLink", the existing LinkPattern is nearly ideal. For proper nouns, it's terrible. In fact, one reason why the UseModWiki LinkPattern is different from WikiWiki's is to allow middle initials.

Even the UseModWiki implementation isn't as free as it could be as you admit as you do a little WikiNameCanonicalization. You could go even further to canonicalize the links too. For instance, you can

Translate the normal LinkPatterns to be link_pattern;

: e.g. "JohnFKennedy" --> "john_f_kennedy"

Strip punctuation from the free links;

: e.g. "sh.. bang!" --> "sh_bang"

Reduce all whitespace substrings to a single underscore;

: e.g. "spread \n\r out \t text" --> "spread_out_text"

Convert the entire link to lowercase.

: e.g. "NTT Do Co Mo" --> "ntt_do_co_mo"

These transforms would allow better writability yet improve AccidentalLinking. This is definitely an improvement over the existing systems, I think.

By the way, if you doubt the power of this many-to-one LinkPattern philosophy, you can also translate all of those into the UseModWiki LinkPattern style as well (allowing for one-word links too):

john_f_kennedy: JohnFKennedy
sh_bang: ShBang
spread_out_text: SpreadOutText
ntt_do_co_mo: NttDoCoMo

One side note that I don't really think is important, but it's interesting. Someone once wrote that the CamelCase LinkPattern of WikiWiki was its particular stylistic identifier. I suppose similar to odes to hot grits on SlashDot. ;) -- SunirShah

For links to non-existant pages, one future possibility is that they might be rendered in a different style or color. This could even be a per-user preference. Some people want non-existant pages to be obvious, and others want them to be subtle. (One likely near-term addition will be a "printable page" display mode which would display the non-existant page-links as ordinary text, as well as hiding the link bars and search interface.)

Another advantage of FreeLinks is that they make it obvious how to type plural-forms of links. For instance, on a FreeLink-enabled wiki one could type [[FreeLink]]s rather than trying to remember which combinations of single or double quotes the local wiki uses.

Response.

The argument here is more at the ridiculousness of the double-quote rule or the Wiki:SixSingleQuotes idiom. Neither rule is user friendly, both are hacks. One is an unexpected bonus of existing page translation, the second is hacked directly into the script. Unfortunately, there is no clear way through the problem.

One solution might be to extend the LinkPattern to require bracketing characters, ala [[LinkPattern]]. Then, you can talk about many [[LinkPattern]]s all at once.

So, as you see, it's not the FreeLink that gives you the latter property, but the BracketedLinks. That might be a legitimately useful upgrade to the LinkPattern too. That would solve the unwanted links that happen frequently in program listings for example.

: You can get close to this behavior in 0.91--just set the $WikiLinks variable to 0. All valid LinkPatterns are a subset of FreeLinks. Program listings should use the nowiki, code, or pre tags, however.

Another argument for a free-format LinkPattern in a Wiki (striving for multimedia collaboration) is compatibility with different WikiForums: each non-CamelCase LinkPattern elsewhere that we would like to link to has to be translated first into a cumbersome CamelCase LinkPattern.

When allowing free-format LinkPatterns, the CamelCase hard-core people could form a stable subspace. -- FridemarPache, FriendlyPeerContributor

I propose adding a restricted form of FreeLink to the MB engine to do away with page names like "DemaGogue" and "WhatIsaWiki". It would allow only single words; use CamelCase for everything else like before. This allows us to create a small dictionary of terms that are frequently used on MB: demagogue, wiki, etc. (Capitalization should be optional to avoid turning things into proper nouns; this is especially appropriate for "wiki", where we have standardized on a lower-case ‘w’.) -- ChrisPurcell

I think DemaGogue is just a bad name for that page; MobLeader? or RabbleRouser? or EmotionalAppeal? would be better (when I decide, I'll rename the page). I think creating a glossary is a separate idea to what MeatballWiki is meant to be, but a good one. It could/should be a separate wiki/UserInterface, and then we can mixin its namespace to the MeatballWiki PatternLanguage namespace, which we can refer to with FreeLink syntax. We can then use CommunityExpectations to limit the pages on the glossary to being definitions. If the glossary remains in MeatballWiki (probably a more HumaneInterface), then glossary pages should be visually distinct from Pattern pages, say by changing the background colour. Also, we should provide a separate IndexingScheme for just this subset of pages. -- SunirShah