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.
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.
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
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.
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
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.
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.
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 is not allowed to provide important additive information; ColourBlind people will not appreciate it.
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