LionKimbro is upset that people are applying StopEnergy to his LocalNames idea
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