Brian Kerr

“Local Names is a way to bind names to URLs.” Huh?

Instead of explicitly keeping track of URLs and building links to them, you just write a name (say, “Python”) and Local Names makes it into a link (like “Python”). Local Names works from a series of rules — called a namespace — for matching names to URLs.

Different people can use different namespaces, so that the same name points to different URLs. For example, a person reading on a real computer could follow a link called less man page and get the real thing, whereas someone else could follow their own less man page link and see what they’re missing.

Alternately, two people can share a namespace, so that the name gets linked if either one of them have set up a rule for it. In this case, imagine that students are working together and linking to papers. Using the right kind of shared namespace, they could link into their BibTeX heap for documents they already have, and to the Design Bibliography wiki for those they’re interested in citing — and when the underlying state of the paper changes, the name doesn’t.

If you want more detail, read About Local Names.

I’ve gotten excited about Local Names for a few reasons:

• it’s respectful of the way people read and type,
• it’s a more generalized improvement on my favorite wiki gizmo, InterMap / InterLink,
• there is a nice, human-readable syntax for creating and relating namespaces,
• at least some of the moving parts have been written, and
• it affords more than one way of relating to what you’re naming.

In addition to the basic specifications, code, and public query service, there’s a cool Wordpress plugin, and a web-based namespace tool called My Local Names which lets you name URLs via a bookmarklet or resolve your names via a browser search bar or similar tool for easy access. Thanks to Lion Kimbro for all his work on this ultra exciting project.

(tags: collective design python web weblogs wiki)

Inspired by Andrea’s Half-MSI post, here’s a list of things I’ve actually learned about in the first half of the MSI program. The program is pretty much a bust so far. Anyways, as a student of information I’ve learned (in alphabetical order):

• a bunch of information metaphors, for whatever they’re worth,
• a little more Python,
• a lot about wiki,
• domain-specific language economists use to shout into the abyss,
• domain-specific language the nonprofit sector uses to discuss amongst itself,
• how to emit and chase down invoices,
• how to use LaTeX + KOMA-Script + BibTex to get gorgeous text, and how to use LyX to abstract away all the \{} gunk and just write,
• not to sell myself too short even though the work is fun,
• that pressing ⌃⌥⌘8 inverts your display, helpful for bright rooms and/or tired eyes,
• what I can do to make RecentChanges better,
• what it’s like to work inside nonprofits of varying bulk, an MSO, a foundation, etc.,
• why a certain class of person always wanders around mentioning “communities of practice” and related terms at tech conferences or on wiki pages or what have you, a class of person heavily armed with a controlled vocabulary and steely gaze: these CoP people know what they’re doing, which gives them the confidence to write their crazy moon language “situated learning” stuff on session proposals and to work it into every conversation — they do this, and now I’ve learned why.

There’s probably more than that, such as the interesting people I’ve connected with along the way. But the real surprise for me is how little of the above came out of the curriculum, rather than whatever else I happened to be doing at the time.

(tags: abyss alphabetical order bibtex bust economists gunk invoices latex metaphors nonprofit sector python self umsi)

I can really honestly truly state that until today I had never considered how a waferbaby corner monkey interview with Guido van Rossum, inventor of the Python programming language, would read.

(tags: python weblogs)