LionsLocalNames

LionKimbro is upset that people are applying StopEnergy to his LocalNames idea

• http://lion.taoriver.net/?p=20

Here's my response :

OK, I’ll try to give you a deep, philosophical argument about what’s wrong. :-)

I don’t think LocalNames are a LinkLanguage.

That’s the same reason I don’t consider Swiki to be a wiki - because it’s not a LinkLanguage to use arbitrary numbers as the names of pages. It’s also why I criticise PurpleNumbers. Any addressable chunk should have a meaningful name. One which is open to serendipitous discovery if you happen to guess the right words. (Or infer them from the public use.)

The problem with all lookups that give an alias for a foreign namespace is that they also reduce this fluency of making links. I can just about work out what Meatball:PageName should mean; particularly after I’ve seen a couple of examples. But what am I to make of, how am I going to guess, Lion:5-11-2006 or Lion:p=20 or Lion:i-was-saying-to-john-malkovich-the-other-day.html etc?

Seems to me that the only times that LocalNames will be part of a fluent LinkLanguage is when they’re a) to a well known name-space eg. CommunityWiki and b) to a name-space where pages (or chunks) have sensible names. (swikis, blogs and content management systems don’t count.)

It’s this fluency of link-making which is the real gain in wiki. And not even LocalNames can give it to you in places where it doesn’t exist.

You got it right when you said :

“There are two obstacles, generally: Typing out whatever you need to link. (For instance, typing out an A HREF, or remembering to put the brackets around something, or whatever.) Second is actually figuring out what the hell weird URL it is to get to the page you want.”

Actually, there are three parts to this problem.

a) typing out the A HREF

b) remembering the domain name / URL for the site, and

c) discovering the id of the chunk (page, posting) you actually want to link to.

Of the the three, the first is the least pain. And it can be solved with most wiki-markups (eg. Markdown, Textile) that allow something like [[ ]] notation.

b) is what LocalNames is really solving, but

the third pain, c) is the worst pain of all.

Because these ids for the chunk of information are unintuitive, it means you are going to have to look the target up before you make the link. That’s what’s different from wiki where a lot of the time you really can guess the name of the page without explicitly checking it.

But once you’ve gone to the trouble of going and looking the target up, copying and pasting from the browser’s navbar is a minor extra step. In fact, given that I’m probably using the mouse to switch between different windows, it’s likely that it’s easier to copy and paste the URL directly from the navbar of the browser than it is to retype the id of the chunk.

In summary, LocalNames solves b) but not c), and without solving c) the value of the solution of b) is minimal. A lot of the time, copying and pasting, or having a bookmarklet copy, the whole URL will be the best solution for capturing the id of the chunk I want to address, and the domain name will come with that for free.

Further thought : I don't acknowledge in the above comment that you can make a special name for a single chunk at the target, which is great if you find yourself linking to the same external place 50 times in your wiki or blog. But I'm right if your typical use-case is wanting to link to 50 different chunks in the same blog.

Actually, if I find myself linking to the same external item more than once on ThoughtStorms I typically refactor to create a local page here, which contians the external link (DontRepeatYourself) and link to that locally. In a sense, this is a local-name, but implemented by a user convention without any extra-technology.

Generally I FavourUserConventions