Glacial Erratics

Danny Ayers has been doing some thinking about PurpleNumbers and the URI refs that they create. Rather than respond to him in a comment, I'll put my thoughts here because it is a TrackBack kind of day.    (0001GJ)

In the second half of his posting Danny reiterates his desire for a trackback anchor that provides a sort of more public and open version of a development list for, well, anything.    (0001GK)

Unless I'm misunderstanding Danny (which I do a lot) Topic Exchange is some of the way there but doesn't really provide support for comments (although every comment does get a wiki). In MovableType, a category could be created that receives pings. I've just tested this by creating a PurplePings category with the following TrackBack URL:    (0001GL)

It gets the basic principle, but implementing comments is something other than trivial, but should be possible.    (0001GN)

Somewhere other than my blog is probably a better place.    (0001GO)

KMPings is an implementation in MovableType that's quite clean but it doesn't do comments.    (0001GP)

Either of these options, if publicized would go some distance to accomplishing some good. And I bet the Lazyweb could do or has done the tuning to make it better.    (0001GQ)

Update: Actually, the Lazyweb site is already doing it: trackbacks with comments all nicely lined up. Maybe that's easy to do elsewhere?    (0001H4)

On the URIrefs and associated stuff. Danny says:    (0001GR)

Several thoughts in response to this:    (0001GV)

• Eugene and I have been in the habit of putting id tags in the anchors with the same text as the name attribute. This is part of the reason for the (I think bogus) 'nid' text. IDs can't be numbers. Where did that come from?    (0001GW)
• I've never been sure about where the close tag on the named anchor should go. Danny has wrapped the text (which seems more correct), PurpleWiki (and anything it parses, like this blog) puts the anchor, empty, at the start of the chunk.    (0001GX)
• The ideal is that the anchor will always point to an evolving information item (the same chunk of text) as it is edited and is moved around. If the chunk is deleted a reference would return some kind of pointer to a version history. Part of the reasoning behind creating domain wide PurpleNumbers, rather than per page, was so that information items could be accessed by nid alone. SpaceCGI is a test implementation of that.    (0001GY)
• The reality is much different. At the moment, if a nid is deleted, using it as a reference will land you on the page where it used to be. In the current implementation of PurpleWiki, if a chunk of information is moved from one wiki page to another, the index which manages NID:URL pairs is not updated (the index entries are created but then not maintained, maintenance is possible, just not done yet) so the ref goes down the wrong street.    (0001GZ)

I've experimented with nodal styles of information storage that represent the wiki page (or whatever else) as a graph of nodes, each with an ID, each with a history, each mobile across multiple presentations.    (0001H0)

The long term PurpleReligion?, at least in my branch of the church, is that cool information items (the granular chunks) have URIs and because they are cool, they don't change. Of course, this is complicated by the fact that I'm also in the church that says identifiers are to strictly persistent, strictly unique, and strictly meaningless (so they can be unique and persistent), so I don't much like URIs as they are generally implemented because they are so, ewww, meaningful. Labels should be meaningful, and they should be pointed to by identifiers.    (0001H1)

Given time, funding, motivation, etc I'd like to create an implementation of Purple that uses handles as the identifiers for the chunks.    (0001H2)

All of this stuff, though, raises the spectre of how to deal with versision and doing identification of versions.    (0001H3)