NearLink

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Wikis covering overlapping subject areas with community overlap, such as a project branch or community fork of an existing wiki, often mix-and-match the PatternLanguage of both wikis on a page. An external-link syntax like InterWiki breaks the flow of text for the reader, but indirect-link schemes like TwinPages act as a PricklyHedge demarcating the line between the two communities.

Therefore, inject the namespace of one wiki (A) into the other (B), allowing "internal" links (e.g. plain CamelCase on MeatballWiki) to link to the external wiki pages. To avoid breaking the flow of text, the text used in the link must be unadorned: if NearLink is used on wiki A, NearLink, Near-Link, Near_Link or similar must be usable on wiki B (see WikiNameCanonicalization). If the linking site uses a LatticeSpace, this can be done simply by injecting A's namespace into a subspace of B's namespace, coincidentally enabling InterWiki-like link disambiguation, and TwinPages-like automatic parent-child linking.

If B has a flat namespace, a link to page X should point to page X on A if it exists, X on B if it does not exist on A but does on B, and be displayed as a regular BrokenLink only if X is defined on neither A nor B. (LatticeSpace injection can then be emulated in part by setting up InterWiki and TwinPages links to A.)

But, NearLinking is susceptible to ContextSwizzling, as the target of a link changes randomly (from the perspective of the user) as pages are created and destroyed. This is a problem if NearLink is used to link to content rather than to use a PatternLanguage. This is also the case locally on a wiki, as content can be radically changed, but the problem is amplified with NearLinks as BackLinks may be broken, preventing links from being fixed if content changes.

Care must be taken to allow X to be defined on wiki B even if it is already defined on wiki A. Project branches can ensure that pages are created OnceAndOnlyOnce?, avoiding this problem; community forks may not want this limitation. Forcing users to hand-craft URLs should be avoided. This may be done by placing links to the appropriate edit pages at the bottom of the linking page on wiki B, or somewhere else close at hand (e.g. the edit page).

Hostile community forks may need to be careful when setting up a NearLink to the forked wiki, as users may be bemused to find themselves amidst a different community, with potentially different edit syntax, copyright rules, and community expectations. In this case, the PricklyHedge of TwinPages will act as a warning to the user that they're "not in Kansas anymore".

NearLinks, in this context, were invented by Chris Purcell.

Original Presentation

Near links are links that look like ordinary links but point to a different site, or a different NameSpace on the same site. If two wikis A and B act as two different namespaces, and they allow near links to each other, then when you link to page X on wiki A, X may point to page X on A, if it exists, or to page X on B, if it does not exist on A but it does exist on B. Clearly, this requires A and B to exchange information on the pages they have defined. Indeed, this is a SisterSite method, but it is a more direct bridge than the original TwinPages formulation.

This is very similar to the use of NameSpaces (see also WikiNameSpace) in natural languages: when talking about wikis and mentioning SoftSecurity, there is no need to write MeatBall:SoftSecurity. The reference only needs qualifying when it is ambiguous, e.g. "The link is from my homepage AlexSchroeder on MeatBall, not the one on EmacsWiki". Thus, near links can be made into explicit far links by qualifying them with an InterWiki moniker.

Benefits

NearLinks help a new sub-community with their own Wiki use the rich pattern language and database of MeatBall without violating the compendium copyright, or using UgLy InterWiki syntax. The project can keep in direct contact with the wonderful MeatBall community, which forking prevents. The project site feels like an extension of Meatball. PeriPeri has benefited enormously from this, and CommunityWiki appears to be doing the same. -- ChrisPurcell

Problems

NearLinks are not a HumaneInterface as they are magical. They are examples of ContextSwizzling as the target of the link randomly changes from the user's perspective once pages get created. Once you create the page here, the target changes. Note also that you may think you are linking to Wiki B when Wiki A comes along and creates the page; if Wiki A is higher priority, all of a sudden the target changes on you. And when you change the InterMap order, it also will modify a lot of links invisibly. Also, now there is no convenient way to create the page SoftSecurity on your wiki.

Be consistent and be visible. Ward and Steve's implementation of TwinPages makes a lot more sense in that respect. -- SunirShah

: Perhaps the solution is to copy programming languages and have "using" statements on each page. So, rather than continually write Meatball:X, Meatball:Y, Meatball:Z on some page on meta-wikipedia, I could just write "using meatball" at the top of it and save my weary finger. -- MartinHarper

This is what I saw on TinyWiki once; unfortunately I can't find the reference anymore. As to Sunir's comment: Using near links only makes sense if I don't even want to create SoftSecurity on my site. Therefore, I don't mind that aspect. I do mind the "magical" aspect of it, though. Martin's "possible features" below might help. At the moment I have decided to indicate via CSS (link color) that the link points off-site. And a tooltip will tell you to which site it points. Swizzling remains a problem, but I'm not sure I want to worry about it. After all, content on the remote end might have changed as well. -- AlexSchroeder

OddMuse Implementation

There is a near link extension for OddMuse [1] which checks the InterMap and tries to read a list of pages for every entry in the map.

For an example, visit AlexSchroeder's homepage. [2]

Possible features:

Set the hover-text to indicate the destination wiki or namespace
Warn editor or reader when there's an ambiguous link.
For closer interlinking, if there's a local article and a "near" article, then link to both. Put the remote link in a little green thing in brackets. Useful for MultiCopyrightWiki?
Render a NearLink to SoftSecurity as SoftSecurity[?] (see [SoftSecurity Meatball])

PeriPeri Implementation

PeriPeri has a NearLink to Meatball, but emulates set-identifiers by grabbing the set of categories on each page. See PeriPeri:NearLink for more details.

ProWiki Implementation

It implements NearLink to different namespaces within one wiki. Such namespaces may act (like in FractalWiki) as completely separate wikis having they own RecentChanges, logs, categories, layout and language. But still its not the same as between different servers.

What may soon be needed is a kind of "multiple" near link, if the same page exists in more than one namespace. Currently the system works with a priority list - as soon as a match is found in one of the defined "near namespaces" the link is established. It would also be possible to offer all these links automatically or to offer a (e. g. symbol) link to an additional switch page. It could be also possible to add an user option for the user to the define the namespaces he is interested in.

Discussion

I think that it would be better for the user to expand a NearLink to display an interwiki link. -- HelmutLeitner

This page inspires thinking about "What if the targeted wiki doesn't like the foreign wiki NearLink strategy", about SystemCooperation?, SymbioticSystems? and ParasiticSystems?. NearLinks are one species of DeepLink, and if you don't like being deep-linked, you could opt to implement a DeepLinkDefense.

I would suggest that the display (CommunityWiki page rendering) of the near links in the mb+cw situation should be changed:

   link (--) (--) "page_?_"          (normal cw edit form, no change necessary)
   link (mb) (--) "_MB:page_"        (near link shown as interwiki link)
   link (--) (cw) "_page_"           (normal local link, no change necessary)
   link (mb) (cw) "_page_ (_MB_)"    (two links to both pages)

This would be simple and transparent to users. No change in page content is necessary. -- HelmutLeitner

What's wrong with colour+hovertext over MB:? It's pretty intuitive once you get used to it, and it doesn't force dyslexia on readers.

Reasons:

"used to it" works only for regular readers (perhaps 5-10%)
without "MB:" the same link may refer to different opinions (semantic content) on different days
for readability you could also use _page(MB)_ or _page.MB_ or _page/MB_ for the "visible near link" but _MB:page_ seems clearer.

How about page<sup>MB</sup> or page<sub>MB</sub>? It's innocuous, shows the information, and does not look like possible WikiSyntax.

: Colour's better, in my opinion, as it's only there to give a little more information at a low price. If you're using a link to reference an argument, the referenced page could shift under you anyway. If you're using a link to make an argument, the name of the page should be enough (e.g. UseRealNamesPlease?). ContentSwizzling isn't more of a problem than is standard on a Wiki anyway. Adding all this extraneous stuff is only important if you're NearLinking to a site you really shouldn't be. -- ChrisPurcell

Colour is not allowed to provide important additive information; ColourBlind people will not appreciate it.

: That's my point: it's not important. Better to lose it entirely than add extraneous fluff. Colour blind people still get the hover text.

So the so important information about CopyLeft or not (why cw has been built), is suddenly not important anymore? -- HelmutLeitner

: Not here, no. That's only important to the people who want to copy the text, and they can find it out without looking at the colour of the links from the referring page. -- cp

Could you define the term "important" so that it means the same for you, me and especially all the people that you are talking for? -- HelmutLeitner

: "Important" as in "simply must be done because it's providing an invaluable service." I don't think this is true of links being coloured to let people know the copyright rules of a page they're not even on. I certainly don't think it's true of links in other situations NearLink could be used in - like splitting one wiki into two but keeping the same page database for the course of the split.

: If the information about which site is being linked to is important enough to break the flow of text and disturb the readers - which the proposals suggested do - then just use InterMap! -- ChrisPurcell

CategoryNameSpace? CategoryInterCommunity CategoryWikiTechnology