Local Names is a project to use wiki-like linking just about everywhere.
Imagine: You’re reading a web page you like, such as: http://slashdot.org/
You are going to talk about it in your blog, so you click a bookmarklet, and name the page, “SlashDot.”
Then you go to your blog, or your favorite wiki, or are writing a comment somewhere, and you say, “I was just looking at SlashDot the other day, and I saw this idea, …”
It made that note in your “namespace.”
The part of the plugin that knows how to read a namespace, is called a “resolver.” (per software package, per website, per WikiEngine, …)
Wiki is half-way there, because wiki already have resolvers and namespaces built in:
For LocalNames to work in a PHP BB, or in blog software, you have to do some plug-in work.
You also have to do some plug-in work, if you want your wiki to link outside of it’s own local namespace.
So we have:
Got it so far?
We’d like to use names from one place (say, a wiki) in another place (say, in a Slashdot comment.) How is this going to work?
Somehow, Slashdot has to know to look at the wiki’s namespace, and it has to know how to understand how to decipher that namespace.
The simplest format we can think of for doing this, is to just use a normal web page.
Interpret every link on a web page as a local name definition- “this link text is the name, and it points to the linked URL.”
A wiki’s page index consists of the name of each page on the wiki, hyperlinked to the page of that name. What you do, is you strip out all the hyperlinks from the page, and make those your name-url bindings.
blah blah blah <a href="http://example.net/">example</a> blah blah blah
…establishes that “example” should link to http://example.net/ .
There are web glossaries, such as: “Theories About Conforming.” It’s a rich source of reusable names.
“What if there are several links to different urls with the same link text, like the dreaded “more” links?” – RadomirDopieralski
Answer: Ideally, you’d be using a page that was intentionally made for doing this. Sub-ideally, we have to tolerate the dreaded “more” links, or manually cull them out.
Yes, Oddmuse’s implementation will use the first more link. But luckily we’re not linking all words, so this is only a problem if you do in fact link to
[[more]] which is rare. So effectively we’re just wasting some space, not corrupting the usability. Similarly, if you screen scrape a wiki’s page index, there will be some useless entries from the header and footer. It’s nice if wikis provide a dedicated list of links, such as these:
But it is not necessary at all. If you look at the NearMap, you can check the result of screen scraping Meatball’s index:
One problem is loops. Assume, for example, the following sites:
So why can’t the wiki just test for loops?
If you check the following links, you’ll know why:
If you check the links, you’ll notice that A and B point to the same page using a different interface (English and German), whereas C points to a different wiki altogether. So assume that #1 is site A from the example above, and the definition for TEST on site C could be pointing to #2 or #3 – if it points to #2 we have an infinite loop; if it points to #3 we don’t. I don’t think it’s possible to build a system that will automatically do the right thing. Solutions will always be brittle.
Well, InterLinks are explicit: MeatBall:AlexSchroeder points to the AlexSchroeder page on Meatball because I said so. AssumeGoodFaith points to a page on Meatball wiki as well, but not because I said so – instead, a little search strategy is used: First, we check whether the page exists here, then we go through the NearMap and check whether the page exists on any of those wikis, and if it does, we link there. Should we one day create a local copy of the page, the link will automatically point to the local page, since the search strategy looks at local pages first.
Lion’s system formalizes this, and provides a generic framework where you can link names to URLs in a namespace, and delegate the lookup to other namespaces if no local definition exists.
|Lion’s Local Names||Oddmuse Local Names|
|URL||URL of the page|
|Definition of a name||Local page exists|
|Delegation to a remote namespace||List remote wiki on the NearMap|
I’m sure we could make a better comparison than the table above, but it’s a quick start to see how the Oddmuse:Near Links compare to Lion's Local Names. And I think that makes it pretty clear that LocalNames are not the same as InterLinks.
If I understand correctly:
Some wiki, and the Local Names system, support those two strategies. 1
But there is no one resolution process that is Local Names.
Where you are right:
Things you missed:
Another thing to note about Local Names:
Query servers can support multiple ways of looking up names. They should all have a “default” way, though, and they should all support the “traditional” lookup method. (Which is basically: 1. Look Here. 2. Look all Around. 3. Use X FINAL.)
This is so that the system can support all the different ways of looking up names: Do you want to be picky about foreign characters? Do you want to be picky about spaces? Do you want to be picky about capitalization? Do you want to search deep through the namespace web? Do you only want to search a single namespace, and nothing else, while still being able to perform namespace hopping? And so on.
Rather than construct an entire constraint based query language, I decided: “I’ll just let people name styles of lookup, and hand-code them into their query servers. People are going to be using traditional most of the time, anyways.”
local names- There is the scent of hearing somebody scatching. As if we dug tunnels towards each other. Local names and wiki-net. As if somebody scratches not far away and the tunnels are to connect soon. Just a September-scent.
InterLink, NearLink, LocalNames are for better connection and that’s fine. but i’m missing the backlink (another word for re-ligion (and this shows us how important it is)) . in my opinion each side has to have a main backlink (rc-tree rudiments) and a list of (perhaps weighted) backlinks (rhizome) .
see also BalkanizedWeb
Mattis- I feel the image too.
I think it’s the desire to connect ideas with other people. Local Names is a step forward for mental contact.
If anyone would like to make use of this method in a tool or something, please let me know; I’m eager to help make it happen.
In fact, I’d give 100 points on the InternetExchange, for the opportunity to do so. I really want to see this work.
I’ve been trying out on local names a bit lately.
The community-wiki imports the local names from several wiki-hives:
See the CommunityLocalNames
It would be nice to get a link like [[kabo-wiki-hive_-_local-names-wiki_-_talk?]] to work on community-wiki as well (http://socialsynergyweb.com/cgi-bin/wiki2/LocalNames/Talk). Within and across the above wiki-hives local page names do already work.
Testing some more I added on CommunityLocalNames. It’s local names because every wiki cares only for its own local names. Care for your local names at home and use all local names yours included all over.
Hm, the clean cw page names do not yet work on [[kabo-wiki-hive_-_local-names-wiki_-_talk?]] 2008-10-30 (no clean page names for day-pages yet). But maybe the will when I wait a bit. … hm.
The phrases link language, community-wiki, hive mind and mind the gap are LinkLanguage examples that link in our minds.
Once a person or group defines a Name Locally, their brains link it to that definition regardless of case or spurious punctuation such as extra ’s, .’s, :’s, ;’s, -’s, _’s, +’s, %20’s, etc.
WikiSoftware should be just as loose.
Ah, … so the situation is that you (A) link to someone (C) who links back to you (A), …
The problem seems endemic to redirects, period. Like email autoreplies in a war with one another.
I think the cheap solution would be to just point, and not try to resolve the chain. That is, if you are resolving a page on (A), then point it to (C). Leave it to the web browser (rather than the page renderer) to try and resolve the infinite loop.
The deeper solution would be – as you resolve the target, keep a list of the chain so far. When you get to a repetition, realize, “This is looping.” The only way it will go on forever is if the URLs generated are always different. (Which I could imagine – if unique random id’s are part of generated page URLs, or something.) But if it’s just /en and /de, you will exaust the supply at some point.
def redirect(url): """Return the Location: url that the received url redirects to. Returns None if it does not redirect. """ ...(code goes here)... def resolve_url(url, L=None) if L is None: L=list() # first time through? start w/ an empty list if url in L: return "infinite loop" next_url = redirect(url) if next_url is None: return url else: L.append(url) return resolve(next_url, L)
That would work. Since HTTP is stateless, and the wiki software we use (Oddmuse) is also stateless, I’d have to store the URLs visited in a cookie. That would only work if all the sites in the loop use the same software. Or I’d have to add state to the software.
Luckily there’s a cheaper alternative. The software has a SurgeProtector and it kicked in when I ran into the problem: I followed the Meatball link, load load load load load load load load load load (in other words, Firefox will not detect a loop), and I got the message Please do not fetch more than 10 pages in 20 seconds.
I think what we’re seeing is that the importing of entire namespaces instead of manually defining single names one after another results in a brittle system. We cannot control what remote sites will define, so other people will set up infinite loops for us.
If the browser is fast enough, it may even be something like: “Please do not fetch more than 2 pages in a single second,” to sufficiently capture the condition.
When I wrote up the problem description, I had to invoke both NearLinks and LocalNames to describe the problem. But you are right, you can setup up loops using just one of these technologies. The key is that you are setting up an external redirect. Once you can do that, you can set up loops.
You might modify the SurgeProtector to handle the loop special case – really, people shouldn’t be fetching the same page more than twice (once??) within the 20-second time frame, so the code could check for a repeat-fetch on a single page and report it as a likely loop.
Yes, tweaking the SurgeProtector is probably the simplest way to break a redirect loop.
Another way to fix the problem: Avoid literal HTTP 301 redirects entirely.
The user could manually click on that last URL (that says it came from C) over and over again, and see that same 404 page (from A) over and over again. That would be confusing, but not disastrous.
That 404 page should give the user enough information to fix that confusion: (a) go to C, and fix their incorrect URL for “TEST” to point to a good URL; or (b) Remove C from A’s list of places to check for local names, and forget all the local names C already gave us, until C stops giving A nonsense; or (c) create the page “TEST” at A.
Hmm… I think this boils down to “don’t do external redirects if the request is not from the local site.” That makes sense. A will only redirect to B if the user followed a link from A. If the user followed a link from C and ended up on the non-existing page on A, then he’s not redirected any further.
Essentially this is what internal redirection using #REDIRECT already does: It passes along a parameter when it redirects. As it redirects, it checks for the absence of said parameter so that it will only ever redirect once.
I like the idea!
Define external redirect: community-wiki - mind the gap eArt-wiki-Nest - Peinlich-wiki - lokale Namen SillyName community-wiki - link language NamespacePage kabo-wiki-hive - kabo-wiki-center-en - edit the day-page talk for today mind the gap hive mind kabo-wiki-hive - kabo-wiki-center-en - talk link language community-wiki - hive mind kabo-wiki-hive - local-names-wiki - talk obm-wiki-hive - world-democracy-wiki - wiki-net, explained