Übersicht Letzte Änderungen Letzte Änderungen in der Umgebung KurzAnleitung Blog RSS

LocalNames

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, …”

When you hit “Save” (or “submit” or “comment”), your blog automatically hyperlinks “SlashDot” to http://slashdot.org/ for you.

How Can This Work?

When you clicked the bookmarklet, it made a note that “SlashDotshould point tohttp://slashdot.org/”.

It made that note in your “namespace.”

Your blog has a Local Names plugin, and you’ve configured it to look at your namespace. It sees that “SlashDot” was previously bound to http://slashdot.org/ . So, it links it for you.

The part of the plugin that knows how to read a namespace, is called a “resolver.” (per software package, per website, per WikiEngine, …)

Local Names in Wiki

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.

Summary So Far

So we have:

Got it so far?

NamespaceDescription

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.”

So the CommunityWiki PageIndex is a namespace definition. Specifically, it is the namespace definition for CommunityWiki.

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.

ie:

 blah blah blah <a href="http://example.net/">example</a> blah blah blah

…establishes that “example” should link to http://example.net/ .

I like it a lot, it makes it much more flexible, you could use practically anything on the web as your source of names: tags, dictionaries, web searches, directory listings, blogs. It’s so simple!RadomirDopieralski

There are web glossaries, such as: “Theories About Conforming.” It’s a rich source of reusable names.

:question: “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:

Other Ideas

See Also

CategoryLinking

Discussion

Making Sense of Different Sorts of Links

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.

Thus:

Lion’s Local NamesOddmuse Local Names
NamePage
URLURL of the page
Definition of a nameLocal page exists
Delegation to a remote namespaceList 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:

Hm;..

LocalNames is not the same sort of thing as InterLink or NearLink.

InterLink and NearLink are specific name resolution strategies.

Some wiki, and the Local Names system, support those two strategies. 1

If a wiki were to natively support LocalNames, and made use of the traditional query resolution style, it would automatically get InterLink and NearLink as part of the deal.

But there is no one resolution process that is Local Names.

Where you are right:

  • namespace pages – Local Names relies on namespace descriptions; – they can be produced by wiki, or produced by a wrapper around a wiki, written by hand, created with a tool, etc., etc., etc.,.
  • FutureLink” – actually, it’s not called “Future Link” in Local Names; it’s called "X FINAL" instead – that’s where a name goes if there’s no suitable binding.

Things you missed:

  • “this wiki” – there is no check for “this wiki” first, because there’s no such idea as “this wiki” in Local Names; if a wiki were to use Local Names, it would likely just produce it’s namespace description, and likely use that as the origin of it’s local names queries
  • NearLink – Local Names supports “near links” – if you query a namespace, by the “traditional” query style, then that implies a search of all neighboring namespaces as well (1 level deep)

Another thing to note about Local Names:

  • There’s no one specific way to look up a name, in 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.

I’d like near-universal spam-proof moderated BackLinks as well; I love how OddMuse implements it with referrers, for example.


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.


Fussnoten:

1. As for Local Names, the strategies are completely defined in the “Lookup Path” and “Traditional Query Styles,” in the Local Names XML-RPC Query Interface specification.

Diese Seiten lokal erstellen: AssumeGoodFaith CamelCase MeatballWiki FutureLink PatrickAnderson ThisWiki

Sprachen: