Purple.pm

Last week Eugene swung by after RecentChangesCamp and we took a day to do something we've been talking about for years: We finally made a separate module for handling the PurpleNumber creation and index management that is used in PurpleWiki.    (PYC)

The code is still coming together. Thus far there's a subversion repository with working code at:    (PYD)

The basic functions of the tool are pretty straightforward:    (PYF)

• Give a URL, get a PurpleNumber NID    (PYG)
• Give a NID, get back the URL where the identified node can be found    (PYH)

NIDs are stored in SQLite. The code is written with something akin to a factory class so other data storage implementations will be easy to create.    (PYI)

Accessing the data store can be done through direct use of the Perl library, or through a RESTful server subclassed from HTTP-Server-Simple (thanks to Jesse for releasing a new version patched to support PUT and DELETE).    (PYJ)

Using a central nid index for multiple wikis or other tools that use PurpleNumbers enables TransClusion between those multiple tools.    (PYK)

It's nice to get this going.    (PYL)

Update: There's been a fair amount of updates recently. The commit messages have more info.    (PYZ)

Update 2: Released to CPAN.    (PZ0)

Posted by cdent at 07:19 AM | Trackback This | Comments (0) | TrackBack (0) | | bl

Microcontent and Purple

I originally wrote this as a comment at a Microcontent Musings post on PurpleNumbers but thought it should go here too (with some slight edits). I felt perhaps the point of purple numbers hadn't quite hit home.    (PU7)

PurpleNumbers provide granular addressability to pieces of content smaller than a document. Originally the idea was to be able to create references into a page so the pointing one does when making reference to something is more complete. For example I can say "Yeah, take a look at the third item on that list after the third header on this page" or I can say "Look here" (unfortunately there a bit of an error in my css that scrolls that chunk up under the header instead of putting it in view, I should fix that). That's perhaps a micro optimization, but it is one that adds up immensely over the history of one's browsing by reducing ambiguity.    (PU8)

More interestingly, though, is that once we got PurpleNumbers working, we saw that they could be used to give the chunks identifiers that raised them to the level of first class elements on the web: they could have their own URI and the purple numbered content could therefore be dynamically transcluded into other documents or used to compose new documents. For a pretty old example see TransClusion.    (PU9)

Arnaud says:    (PUA)

Indeed there is a big difference between what the quoter and quotee might think of as a quotable (or referenceable or transcludable) piece. PurpleNumbers currently take the political stance that the quoter should be able to quote whatever they want: every chunk gets a purple number. Some similar tools let the author decide what chunks get numbers. Purple numbers choose the more anti-authority approach. They also try to avoid being ridiculous.    (PUC)

Where the chunks gain meaning is in the way they can be reused in other documents. Knowledge creation is a dialectic of sorts. Reusing existing content to create new content springboards new understandings without reinventing the wheel.    (PUD)

Posted by cdent at 10:23 PM | Trackback This | Comments (1) | TrackBack (2) | | bl

Microcontent Musings

I've started reading Arnaud Leene's Microcontent Musings. An entry there provides a list of attributes that could lead to a definition of microcontent:    (PTY)

• small - read micro. This is still a troublesome attribute, as MicroContent? items seems to grow and grow and can become pretty large. But it is good to focus on smallness. MicroContent? can be small and that is worth to note in itself;    (PTZ)
• self-contained - this attribute I like much better. It means that MicroContent? can live on its own. It does not need to have context. I am not sure whether I exclude an MicroContent? types by this, such as Discussion Forum Items. In a Discussion Forum has a strong thread between each Item in a discussion;    (PU0)
• addressable - I think that this one is important. This is Marc Canter's demand. Each piece of MicroContent? must have a unique permaUri. That allows for syndication in all kind of forms. This implies that MicroContent? can be autonomous;    (PU1)
• structured - MicroContent? should have structure. This can be extremely minimal (title, permaUri, description), but ideally more fields are defined;    (PU2)
• flexibility - MicroContent? should not be rigid in it's structure. The user should be able to add fields at will, or fallback to a minimal set. Flexibility also implies that there shouldn't be any rigid schema's underlying any MicroContent? type. It should be like OPML, but with a good reference to a dictionary;    (PU3)
• single - this attribute I am not sure about. I believe that each MicroContent? item should have it's own file (or resource). There seems to be a trend to embed multiple MicroContent? items in a single piece of MacroContent?. If you see the number of different MicroContent? items (and types) people add to their blog-page, it has become a petri-dish for all kinds of MicroContent?. It will become harder and harder to extract the MicroContent? item you want. I am afraid this will hamper the creation of the MicroWeb?;    (PU4)
• computer data - I reference this in my definition, so I should include it here as well: we talk about computer readable data;    (PU5)

The long term vision for PurpleNumbers is for them to be the identifiers for addressable, self-contained, small, flexible, single chunks of computer data that are usable alone or can be composed into more complex structures (documents).    (PU6)

Posted by cdent at 05:00 AM | Trackback This | Comments (1) | TrackBack (0) | | bl

rubead

OSCON 2005, especially the lucky stiff, inspired me to start working on a project in Ruby. The project is not exactly a surprise.    (PTU)

rubead is a start at implementing a nodal style data store for a PurpleWiki style wiki. This is a lot like NodaryPublic. In rubead every block (bead) gets a PurpleNumber and sub-documents can be composed from any position in the parse tree allowing more complex and effective TransClusion than implemented in Purplewiki and Kwiki-Purple. Should end up with something that's a bridge between a standard document oriented wiki and TiddlyWiki.    (PTV)

Not much done thus far, but Ruby has made it pretty easy so far. Next step: throw in some WEBrick for display and improve the parse tree creation.    (PTW)

Code soon.    (PTX)

Posted by cdent at 04:46 AM | Trackback This | Comments (0) | TrackBack (0) | | bl

Long Live(d) Purple Numbers

Phil responds to Eugene's participation in the recent chatter about purple numbers, returning to the issue of numbers versus names. Some late night thoughts in response:    (PNG)

Phil says numbers make sense in a blog, because you're already there when you decide to make reference, whereas in a wiki you're not. He says:    (PNH)

I'm sorry I helped to extend that impression. Purple numbers have never been thought of as a thing that just live in wikis or for that matter just in any environment. They facilitate cross medium reference and reuse. Purple numbers may be optimized for synthesis, but they are predicated on ethic (or at least goal) of interoperability. Where they show their most value is content reuse between blogs and wikis and email archives.    (PNJ)

Phil suggests a sort of "purple names":    (PNK)

   [[PostName#OK?. But]]    (PNM)

What, I ask, happens when that paragraph has its first six characters change? Or it moves to another page? The link breaks.    (PNN)

This transclusion uses just the purple number:    (PNO)

If the content at PM3 is moved from my blog into my wiki, and I were running the latest PurpleWiki code, the transclusion would continue to work. If I changed the text from "a high degree" to "a significant degree", the transclusion would continue to work.    (PNQ)

Yes, right now it has a horrible, nasty, unfortunate interface, but that interface is helping to flesh out an infrastructure that will support some stuff with nice interfaces down the road. In the meantime it does some cool stuff that takes a short while to get used to but provides huge benefits if you're willing to pay the price.    (PNR)

Posted by cdent at 07:10 AM | Trackback This | Comments (0) | TrackBack (0) | | bl

Reading To Write

Phil Jones and I continue our conversation about purple numbers:    (PMY)

That's a pretty good characterization of what I was saying, and Phil makes some excellent points. His comments inspire a thought that illuminates a thing I forgot to emphasize in my earlier comments:    (PN0)

Yes, purple numbers do try to favor the reader and the act of reading, but not just for reading. They favor the reader so the reader may more easily do more writing. The whole point is for purple numbers and tools like it to be a generative force in the synthesis of new understandings.    (PN1)

Phil can write all he wants, and I can read all I want, but until I write down something that builds on what Phil says, while making chains of reference back through the many layers of context, there's been no synthesis, at least not any that is available outside the confines of my own mind.    (PN2)

So purple numbers aren't anything new: They are yet another in a long history of techniques that help people generate a little understanding with a little authority. The purple numbers twist is that you can point and grab with finer detail and in real time.    (PN3)

Update: Eugene joins in with some interesting additions.    (PN4)

Posted by cdent at 08:41 PM | Trackback This | Comments (0) | TrackBack (0) | | bl

Purple Identification

In a fine bit of conversation, Phil Jones has responded to my response to Adina Levin responding to my response to Jason Kottke talking about the fundamental units of content on the web.    (PLT)

Phil asserts that I'm hostile to the semantics of labels being bound by everyday behavior. This is not at all the case. Phil uses WikiWords as a good example. My hostility to free linking should indicate the depth of my love for WikiWords. I also love tags, but as Bill Seitz points out, tags don't point to a single resource, they point to a collection.    (PLU)

Tags and WikiWords don't serve the same purpose as purple numbers.    (PLV)

Tags and WikiWords are names people can use to label something or some things. They grant a certain power to authors: "I am calling this thing I am writing or this thing I am pointing to FOO". There is an expectation or hope of collision.    (PLW)

Purple numbers are identifiers that grant power to readers, reviewers, annotators and commentators to indicate a specific piece of any content anywhere and make reference to or, more importantly, reuse it. If pieces of content had meaningful labels, imagine the difficulty of adding labels to every piece of content?    (PLX)

For perspective: Tim Bray took a step down the slippery slope away from the shimmering shiny idealism of allowing the reader access to everything by implementing his (reference only, no support for transclusion) purple numbers in way that grants the author control over what chunks get the numbers. That's like letting a politician say "off the record..."    (PLY)

By the way, a closer look at my gripe with URIs    (PLZ)

shows that I'm okay with labels (which is what WikiWords and tags are) in general. I agree that presenting purple numbers onscreen as the numbers, and requiring users to manipulate the numbers is problematic.    (PM1)

However given the goals    (PM2)

• a high degree of flexibility in referencing content from anywhere, even content that will change its location on the network    (PM3)
• referential control in the hands of the reader    (PM4)
• versioned nodes    (PM5)

there need to be persistent, unique, stable identifiers underneath whatever helpful interfaces will eventually exist between the user and the guts of the system. In simple wiki systems, the page name which people use to gain access to the resource which is the manifestation of that page on that particular system resolves to a unique identifier (inode) on the (extremely local) filesystem. In modern operating systems, you don't personally use inodes to get at stuff, but they are a crucial piece of the pie. Purple numbers, someday, can be thought of as inodes for individual chunks of content that transcend filesystems and local networks and can move around.    (PM6)

Someday, perhaps, there will be nice libraries for them. In the meantime we have to come up with what those libraries will need to do by messing with some ick.    (PM7)

Posted by cdent at 12:05 AM | Trackback This | Comments (2) | TrackBack (1) | | bl

Purple response

Responding to my Fundamentally Purple posting, Adina asks some good questions about purple numbers summed with:    (PKN)

Adina's concerned that during the editing process the numbers will migrate around too much as paragraphs split and sentences move from one paragraph to another.    (PKP)

That's a valid concern, and it does happen, but experience with Purplewiki and the collaborative environments at Blue Oxen and other places lucky enough to have a full suite of purple stuff have shown that it's not too much of a big deal: people adapt well.    (PKQ)

(If you are short of time you may find it useful to skip to the end of this meandering think.)    (PKR)

People's writing habits change a bit:    (PKS)

• a little more effort is made to break thoughts up into chunks (paragraphs or list items) so that references are easier to make and are more stable    (PKT)
• there's a bit more atomism (Wikipedia's description of transclusion has a bit on this)    (PKU)
• when editing a wiki page, people choose to maintain the purple number on a chunk or remove it as fits the degree of change made to the chunk    (PKV)
• references to information that adds context to the current content increase    (PKW)

Purplewiki's implementation of purple numbers is far from done or perfect (it's a sweet little hack that happens to enable all kinds of helpful behaviors): it provides a platform for exploring the concepts and issues with systems that allow granular addressability and transclusion but imposes some burdens on the user. The flaws present now are pointers to things to fix or research as we learn how to create systems that support the basic (and flawless in the abstract sense) concept at the core of purple numbers: If you put handles on things that both computers and people can manipulate, you increase opportunities for use and manipulation.    (PKX)

(Lee Iverson's Nodal project presents a more formal model for node-based document systems.)    (PKY)

Adina lists three points:    (PKZ)

1. purple references to an early draft will be very different from their referents in a later draft.    (PL0)
2. the sequence will be garbled    (PL1)
3. some references will be missing ps    (PL2)

The first and third can be at least somewhat addressed by one of largest missing pieces in current purple implementations: node versioning. With proper versioning, references will never die, they just fade out of the foreground. A cool system of doing versioning will allow a referenced node to present itself from any point on its history, while giving indicators of its forward and backward life.    (PL3)

In very recent versions of PurpleWiki, purple numbered nodes (the chunks of content) can move easily from page to page in the wiki and amongst associated blogs, document repositories and email archives. Experimental code exists which allows nodes to move between a designated set of servers. Long term nodes could move anywhere on the public internet.    (PL4)

The second point is not so much a problem as a misunderstanding. Despite the fact that some purpled documents appear to show a sequence (such as PK1, PK2, PK3, etc.) this is coincidental: the system that generates the numbers happens to be predictable, but is not reliably so. The purple numbers are meant to be entirely meaningless identifiers (not labels or names) and therefore not present any information about the content they identify (no sense of time of creation or of sequence). This makes them portable and stable in the extreme. That they sometimes do show up in sequence is essentially a misfeature resulting from laziness.    (PL5)

Current implementations of purple numbers expose the identifiers (in both the numbers on the screen and numbers at all senses) but this does not need to be the case. Because they are unique (for now in a given suite of tools, but long term globally), persistent and stable they can have labels associated with them that resolve to the stable identifiers (Purple:DistributedPurpleNumbers for some references). The labels could be names like "mom's address" or sequences like those found in legal documents. All this is very much like the concept of a URI except that URIs, because they contain information about what they identify, fail to be persistent or stable and thus are not identifiers at all but labels posing (miserably) as identifiers.    (PL6)

In advanced tools using purple numbers, they never need be seen. Fancy gestural interfaces could include "reference this" or "transclude this" for content that is, behind the scenes, purple numbered.    (PL7)

And lest we forget, purple numbers are just one implementation of a concept, granular addressability, that could be done in many ways.    (PL8)

In purple number tools of today, when one right clicks on a purple number you get the full url of the page being clicked plus the purple number. Something like this:    (PL9)

 http://www.example.com/purple/thing.html#nidA9E    (PLB)

Better would be something like one of these:    (PLD)

 http://purpleresolver.net/A9E {nid PLF}

 purple:A9E    (PLG)

(The answer to the question "Why?" left as an exercise for the reader. I'll make some Church of Purple t-shirts on Cafe Press and give one to the author of the best answer.)    (PLI)

Update:    (PM8)

paulv: is the "why" question "why is http://purpleresolver.net/A9E better
than http://www.example.com/purple/thing.html#nidA9E"?
cdent: yes    (PM9)

So, are purple numbers stable enough to be useful? For everyone and every case? No. But for quite a number of people in quite a number of situations they have been very useful. The primary use has been with smallish groups of people who need to create and use a large amount of information that is both stock and flow that is as valuable the second and later uses as the first.    (PLJ)

See the WateringHole at Blue Oxen for a place to experiment.    (PLK)

Clearly I am in far too deep with purple stuff: I need a translator. The above can be so much meaningless noise and I find little time to make things cogent.    (PLL)

Here's a different angle: I've been using purple numbers on this blog for two and a half years and using them in wikis and mailing list archives for more than three. In collaborative settings where I've had purple numbers my ability to recall, use, synthesize and act on information has been exponentially augmented. So much so that in environments where I do not have them I feel radically hobbled.    (PLM)

The present day technical and usability issues with purple numbers (or better systems that might replace it) are temporary, interesting problems to solve, and a small price to pay for being less dumb.    (PLN)

Posted by cdent at 06:48 AM | Trackback This | Comments (2) | TrackBack (0) | | bl

Fundamentally Purple

Kottke:    (PKB)

He then lists the sequence: site, pages, post/permalink combo and now, with bookmark managers and tagging systems, the phrase or word.    (PKD)

Left out is the more useful (for reuse and reference) paragraph or block unit, as done in purple numbers and other fragment identification systems, which make every "paragraph a first-class Web citizen".    (PKE)

Reference at the level of a paragraph enables valuable granular referencing and reuse while staying just on the safe side of the boundary between respecting context and being ridiculous.    (PKF)

Posted by cdent at 06:14 AM | Trackback This | Comments (2) | TrackBack (2) | | bl

Apple Amplifier

Meet Automator by Matt Neuburg at TidBITS opens with:    (PK4)

They've done this by giving users more granular access to the operations of the tools and applications on the system. Applescript and Automator let people manipulate and assemble simple data and actions in ways that create complex systems.    (PK6)

It's like lego. If you have lots of little pieces of lego you can build all kinds of fancy things that are less limited than what you can build with the bigger blocks of Duplo.    (PK7)

This is the argument that's often been used to explain the superiority of Un*x over Windows; the lack of flexibility and real assistance provided by wizards and Clippy; the value of nanotechnology; and, near and dear, the importance of purple numbers and similar systems.    (PK8)

Apple's use of this model may explain why I've never felt particularly insulted by the company. Granting people usable handles to actions and information is a generous and trusting gesture that hopes and assumes the receiving end is a creative and intelligent person that wants to use their tools in a less dumb fashion. There's extra power here if you want it. Headroom.    (PK9)

Posted by cdent at 01:27 AM | Trackback This | Comments (0) | TrackBack (1) | | bl

Purple Numbers for Attention Management

Raymond M. Kristiansen is thinking about attention:    (PGZ)

This nicely describes the long term goal of the Purple suite of tools and ideas (PurpleNumbers, GranularAddressability, TransClusion, PurpleNet, PurpleNetwork and friends). In a fully fleshed out purple universe, all chunks of content are individually addressable and reusable (as micro content, if that's your preferred term) throughout the network, with flexible access control.    (PH1)

All your stuff exists in your pool. All my stuff exists in my pool. Anything that I say you can reuse is accessible by you with a straightforward identifier that points not to a particular page, but to the individual paragraphs, headers or list items within. This same model could be extended to audio and video as well.    (PH2)

The identifiers will be unique across the entire system, making them resilient in the face of edits, even edits that move the content across domains.    (PH3)

In the present day, purple numbers remain limited to single server implementations (there is experimental support for multiple server using tools). The Blue Oxen Collaboratories have a fairly integrated set of tools that use purple numbers, and the Indiana University Knowledge Base developers and editors use purple numbers extensively in their daily work through a network of mailing list archives, rt, blogs, irc tools, wikis and document repositories that use purple numbers and transclusion.    (PH4)

The systems provide what amounts to a shared infocloud for the participants where there attention and cognition is supported by an available but not in their face network of addressable information.    (PH5)

I'll try to flesh out some more details in a later entry.    (PH6)

Update: I've pointed to the quotation with PurpleSlurple, I'm ashamed I forgot.    (PHC)

More about purple:    (PH7)

• An Introduction to Purple from E.E. Kim    (PH8)
• Purple Numbers Coolness Draft    (PH9)
• Purple Number Identity    (PHA)
• Purple Number Signs from Tim Bray    (PHB)

Posted by cdent at 01:44 AM | Trackback This | | bl

Why Wiki?

A regular unanswered question (for myself and others) of "what do you do?", some conversations with Lee LeFever about social design and community, and recent updates at work have given me a chance to think a bit about the question and stir some ideas.    (PG6)

At work I'm primarily a developer, but I tend to think of my vocation as a builder of augmenting, computer-based tools for personal and collaborative work. I go to the trouble of making that mouthful of a statement to distinguish between types of activities that computers do and types of activities that people do.    (PG7)

Computers have two types of applications, those that automate and those that augment (21Q, 22J). An augmenting application assists a person in performing some activity which cannot or is not automated. Only activities which can be formally described in theory can be automated. As such there are many tasks, especially those related to human discourse, which cannot be automated; they can, however, be augmented.    (PG8)

At a fundamental level computers are tools for creating representations (22L). An augmenting application supporting discourse is engaged in representing and transmitting information. The application is used as tool to evaluate, craft and remodel information (22K).    (PG9)

   (PGA)

Most of my development effort in the last few years has been with wikis (first PurpleWiki, and now Kwiki and Socialtext) and purple numbers. Purple numbers may eventually change the universe of information handling, but that's a discussion for another day.    (PGB)

Wikis are a type of augmenting discourse tool optimized for a particular set of behaviors. Under ideal(tm) conditions they provide an easy path to participation in evolving communication. They do this by being straightforward to learn, quick to respond, and accessible in a distributed fashion. They support changing content and provide an easy way to create and explore connections between things. How something fits in to the larger picture is a large part of how we infer meaning.    (PGC)

I think there are three primary audiences for wikis: the individual who hopes to use the wiki as an outboard brain or memory; the nascent group that hopes to discover and solidify the community that lies as potential in their loose connections; and the existing community that hopes to support a shared goal or perform some action.    (PGD)

Those three categories could be used to describe any set of people, but a wiki is not the perfect tool for every task. There are multiple types of discourse and multiple tools to support them. Some are better at certain aspects than others, none are really good enough (we have a long long way to go, but each day and in every way we are becoming better and better).    (PGE)

Blogs have become a central tool in the distribution of narrative discourse. With a blog there is usually a single author or small group expressing outwardly in a gesture that leads, over time, to the distribution of language and understanding outside the immediate clan. Very often the initial discourse is not fully refined but is rather some author's speculation: a seed that may lead to more knowledge later, as a separate piece of content. As has been said many times, the connections in the network of blogs is often loose and distributed.    (PGF)

Email continues to be a primary tool for discussion within a clan. The members of an email group have already discovered some bit of shared language or understanding that has brought them together. Email discussion can reinforce and solidify language, providing stability from which action can be performed.    (PGG)

With both blogs and email, content tends to be relatively static. Typos may be corrected in a blog entry and email threads may carry on forever but there is little in the way of refinement of the content. This is where wikis step in: they are good tools for summarizing, annotating and connecting information. These are the actions of a knowledge enhancement system.    (PGH)

Wikis do not match all the requirements for a knowledge enhancement system, but experience has demonstrated that this is good. Wikis are here now, today, helping people to do good work generating and supporting communities, developing and creating shared language, and refining information into new knowledge. Their simplicity makes them available.    (PGI)

   (PGJ)

When I chose to join up with Socialtext back in September, it was an attractive choice because the people there believe in two things: people matter more than tools; and tools should help people do what they want to do, not get in the way.    (PGK)

Socialtext, in its various incarnations, is based on wiki but integrates concepts from email and blogs to allow the action and narration those systems support. The latest release is a fine improvement: it enhances email integration, adds support for backlinks (placing information in context, leading to deeper understanding) and for PC Forum 2005 we've created a special prototype of Eventspace, running under mod perl for improved response time.    (PGL)

Architecting these sorts of tools may not solve poverty and hunger, or alleviate suffering in the aftermath of a ? disaster, but the tools can augment people actively doing that work. I happen to be good at making the tools go, so that's where I look to fit myself into the puzzle.    (PGM)

Related writings:    (PGN)

• The Computer As Tool    (PGO)
• Hypertext and Knowledge Enhancement    (PGP)
• Collaboration Requires Goals    (PGQ)
• Blue Oxen Vision    (PGR)
• Anarchic Emergent Collaboration    (PGS)
• A Web for Augmentation, not Automation    (PGT)
• Community and Collaboratory Tools    (PGU)

Posted by cdent at 05:12 PM | Trackback This | | bl

Kwiki::Purple on CPAN

I've finally put Kwiki::Purple on CPAN, along with a few other new or refreshed Kwiki Plugins.    (PF0)

Kwiki-Purple is not yet done, but is far enough along where other people could play with it. If you want to give it a go have a look at    (PF1)

  http://www.burningchrome.com/pwiki/index.cgi?KwikiPurpleInstall    (PF2)

To help with Kwiki-Purple development, I put together a Kwiki-Test module. Traditionally Kwiki Plugins are rather lacking in tests, I hope Kwiki-Test helps change that. tdd++    (PF3)

My stuff at CPAN    (PF4)

Posted by cdent at 08:25 AM | Trackback This | | bl

At Least Two Pieces of Good News about Views: Mountains and Purple

Two nice things have happened today:    (PEG)

On the walk back from the grocery I found a good place from which to get my eyes on Mt. Rainier. This has been a long running problem for me. First the weather is usually cloudy, so none of the mountains (Cascades or Olympics) are in view. Second, in the neighborhood, views to the east are fairly plentiful, but narrow. Rainier is to the Southeast, usually outside the angle of view while tromping around the streets.    (PEH)

Today things are different. Very clear day. And I found a good spot for a view. Somewhere I walk past often, but usually with my back facing the view. At the northwest corner of a nearby playfield if I site across the center line of the soccer field and look a bit right there's the mountain. And when I say there, I mean THERE. On a day like today it is stunningly huge. Nails me to the spot in some kind of religious ecstasy.    (PEI)

Meanwhile, back inside, where my view is the brick wall of next door, I've finally cut a usable version of Kwiki::Purple with support for good linking and internal to the wiki TransClusion. See it: http://www.burningchrome.com/pwiki/    (PEJ)

This is the culmination of a huge amount of work and experimentation, and I'm sure there will be much more to come. Thanks again to Brian Ingerson, Matthew O'Connor and Eugene Eric Kim.    (PEK)

I hope to get it to CPAN asap.    (PEL)

Posted by cdent at 10:27 PM | Trackback This | | bl

PurpleWiki 0.95 test

PurpleWiki 0.95 is nearly out. I discovered a couple of bugs that may delay things briefly. If you are eager go to http://www.blueoxen.org/tools/purplewiki/    (OV8)

The combination of working on SocialText, where [Kwiki] plays a major role, and working on PurpleWiki is going to make my head explode, in the good way.    (OV9)

I've been slacking on the latter because of the former.    (OVA)

Oh to have many heads, so they could all do stuff, and explode as required.    (OVB)

Posted by cdent at 08:34 AM | Trackback This | | bl

PurpleWiki 0.94

I've just announced PurpleWiki version 0.94 with the announcement included below. This new version is way fancy and flexible. I've been playing on my PersonalWiki.    (ND2)

We're proud to announce not one, but two new releases of PurpleWiki.    (NCH)

The newest release, 0.94, is a quick bug fix to 0.93 which provides a large number of new and useful features that vastly improve the appearance and usability of PurpleWiki:    (NCI)

We're proud to announce not one, but two new releases of PurpleWiki.    (NCJ)

The newest release, 0.94, is a quick bug fix to 0.93 which provides a large number of new and useful features that vastly improve the appearance and usability of PurpleWiki:    (NCK)

• Support for a customized look and feel using: ** Templates and TemplateToolkit? ** XHTML 1.1 strict compliance with better CSS handling ** An improved default stylesheet ** CreateLinkBefore? and CreateLinkText? configuration settings that allow customized link styles for undefined wiki words    (NCL)

• Refactored user and session management that provides support for: ** Visited links breadcrumbs for easier navigation ** Basic access control, including a LoginToEdit? configuration item    (NCM)

• Support for Identity Commons i-names.    (NCN)

• Support for MoinMoin? style triple braces markup for sections of preformatted text.    (NCO)

• Support for converting MoinMoin? page databases to PurpleWiki.    (NCP)

• Support for built-in RSS syndication (action=rss), removing the need for external cron scripts.    (NCQ)

• Major bug fixes with the handling of old revisions and saving new versions. Viewing and reusing old versions of pages now works.    (NCR)

Please read the UPGRADE file included in the distribution for detailed instructions on the steps required to upgrade an existing wiki.    (NCS)

The latest version can be retrieved from the PurpleWiki distribution page    (NCT)

  http://www.blueoxen.org/tools/purplewiki/    (NCU)

and will be available via CPAN sometime today (August 11th). There is also a Freshmeat entry at    (NCV)

  http://freshmeat.net/projects/purplewiki/    (NCW)

To see the new version in action, visit the PurpleWiki Wiki:    (NCX)

  http://purplewiki.blueoxen.net/    (NCY)

If you have questions or comments about PurpleWiki, please subscribe to one of the mailing lists described at    (NCZ)

  http://purplewiki.blueoxen.net/cgi-bin/wiki.pl?MailingLists    (ND0)

and post there or comment on the PurpleWiki Wiki.    (ND1)

Posted by cdent at 06:24 PM | Trackback This | | bl

PurpleWiki 0.93

PurpleWiki version 0.93 is nearly ready to go. This is a test post to make sure it still works with the MovableType plugin.    (AAK)

New features include:    (AAL)

• Templating support so the look of the wiki can be dramatically altered.    (AAM)
• Sessions for users, allowing fun things like:    (AAN)
  • A LoginToEdit? config item    (AAO)
  • Visited links (a sort of breadcrumb)    (AAP)
• Better XHTML and CSS support    (AAQ)

etc etc. It's a rather dramatic set of changes. The full list will be published here and a few other places when the release happens (tonight or tomorrow). This is just a test post. So here's some tests:    (AAR)

I am a header    (AAS)

• And a mixed    (AAU)
  1. List    (AAV)
     • where things    (AAW)
  2. are weird    (AAX)
• and such.    (AAY)

Update: My primary wiki is now running the new code with some diddling done to the default css and templates. The purplewiki wiki is running the same code, with the default templates.    (ABH)

Posted by cdent at 12:12 AM | Trackback This | | bl

A Web for Augmentation, not Automation

Earl Mardle comments on Russell Beale's How the Web is Changing:    (8QZ)

I was going to write this as a comment on his blog and then decided to move it here.    (8R1)

In his posting and some others from around the same time, Earl seems to be bouncing around the difference between tools that augment and tools that automate.    (8R2)

Tools that augment extend a human's ability while still leaving the human in control. They are often small things (like purple number stuff) that provide a way to grab or manipulate stuff of all sorts.    (8R3)

Tools that automate "do it for you", often operate in large swaths, and are based on performing tasks that can be formally described.    (8R4)

There's an ethical or world view difference between the two. Some people prefer the latter, some people the former. I'm deep in the augmentation style, I hope. The Semantic Web, as imagined by the W3C, strikes me as in alignment with the latter.    (8R5)

Being in one camp or the other doesn't make someone wrong, but it does make conversation across the boundaries of the camps a little confusing and disorienting.    (8R6)

I first came upon the augmentation/automation split while writing my Computer as Tool paper:    (8R7)

Landauer's book:    (8R9)

is a good read.    (8RB)

Posted by cdent at 12:59 AM | Trackback This | | bl

Transclusion v Blockquote

In a comment responding to Purple Placement Michael Day asks:    (862)

That link is to a blog entry that addresses his thoughts more completely. Read that first if you want this to make any sense.    (864)

First, to correct a misconception in Michael's blog entry: PurpleNumbers were not originally created for assisting with TransClusion. That was something figured out later during the development of PurpleWiki 0.9. Their initial purpose was to provide an address for a paragraph or line.    (865)

I keep harping on TransClusion in this recent flurry of PurpleNumbers excitement because it was an unexpected consequence of purple numbers that has proven to be extremely useful. It also reinforces some important constraints on the identifiers used by purple numbers.    (866)

Michael has raised several points in his suggestion that blockquote be used instead of transclusion. I'll attempt to address each of them. Note that most of my comments speak both of the very limited implementation of TransClusion in PurpleWiki as well as the general notion (much more capable, in theory).    (867)

Transclusion is inefficent    (868)

A page doing transclusion of content from multiple servers will require multiple HTTP requests. This is certainly true. It's not unlike most web pages one visits today, where text is provided by one server, images by another, advertising from yet another. Michael's spartan site (which I like) is a notable exception.    (869)

I can't argue with blockquote being more efficient than transclusion, but you have to pay a price to get what transclusion is providing: live content that is up to date, expires less quickly (or sometimes not at all), and has the possibility of reference tracking.    (86A)

Transclusion is unreliable    (86B)

The web in general is unreliable and yes it can be quite irritating but there is no reason that the same measures used to cache full web pages could not be used to cache transclusions. A transcluding processor could even have the option of turning a transclusion that persistently fails into a stamp of the cached content, with an appropriate reference back to the dead site.    (86C)

The TransClusions in PurpleWiki are not this robust, but they are very much a prototype. A sort of demonstration to get people thinking, "oh this, is neat, let's learn from this and figure out how to do it right."    (86D)

Transclusion is dangerous    (86E)

I can't deny that there is a possibility that content loaded into a web page may not be the desired content. This happens with images now (which are a type of transclusion) and transclusions do, perhaps, enhance the possibility of trouble.    (86F)

There is also a danger when an entity publishes a link to offsite content: the content on the other side of that link may not be what is expected by the clicking user.    (86G)

But we're surviving. Coping. Well even.    (86H)

Transclusion is not expresive    (86I)

Can't dispute this one. It's true, if you transclude a chunk of something, it is the case that you can't change it. This is both bad and good. Bad because you can't emphasize or edit the content. Good because you can't edit the conent. There's a political juggling of who gets to control the content with Transclusion. It goes both ways with the winner not being clear at all.    (86J)

Transclusion belongs behind the scenes    (86S)

Here Michael argues that Transclusion should be kept in CMS, technical documents, knowledge-bases, wikis, whiteboards and other groupware. It's true that this is where I use it most, but that is only because those are the only place where I can use it. I would love to be able to transclude between blogs and wikis anywhere on the planet[1]. Why should closed-world systems have all the fun?    (86L)

If transclusions encourage productive collaboration in closed world systems, the benefits expand in open-worlds where the level of commentary and distribution of ideas vastly increases. That's the overarching goal: expanding commentary and distribution.    (86M)

Can the current architecture of the web support such things in a highly efficient, robust and secure way? Maybe not, but tools and people can evolve.    (86N)

(I feel to some degree that I've been provided a slow pitch or set up by Michael; or is it that there are just large differences in world view?)    (86O)

[1] There are designs and prototypes in PurpleWiki that support:    (86P)

• TransClusions amongst a network of commonly sourced PurpleNumbers, using a RESTful tool to register and resolve nids.    (86Q)
• TransClusions from sites that have granular addressability like purple numbers but are not part of a PurpleNumbers network.    (86R)

Posted by cdent at 05:18 AM | Trackback This | | bl

Purple Placement

In Purple Pilcrows Tim Bray explains how he's adapted his purpling of posts to use an exposed on mouseover Pilcrow which merges several ideas from this weekend's purple breakthrough. It's great how that works.    (854)

I like the pilcrow and the mouseover trick. When developing PurpleWiki and related tools one of the reasons we didn't do any hiding of the link was so that people would have the cognitive breakdown that makes them wonder what's going on and do a bit of investigating. For a first time visitor to Tim's posting there's no way of knowing the pilcrows are there without a mouseover. Once you are in the know, though, you're good to go.    (855)

This is the delicate balance of present-to-hand and ready-to-hand in tool design.    (856)

While I like Tim's building on shoulders solution very much I do have one quibble:    (857)

If the author of a document is in charge of where the anchors go, then the author of the document is in charge of what a reader can reference (and later, perhaps, transclude). This sets a precedent for authorial, uh, authority that I find distasteful. The linkability of content is a way of opening up the system to allow greater review, commentary and reuse. Tim's solution is reasonable (adding the links when there are sufficient granules in the document to warrant granular addressing) but leaves room for a later adopter to be less open.    (859)

This is why comments about granular linking reeking of ego struck me as way off base. PurpleNumbers and similar systems aren't there for the author. They are there for the reader, the responder, the critic.    (85A)

The mouseover solution makes it possible to id everything with abandon, so why not?    (85B)

Meanwhile, I'm going to keep mine as visible numbers because I like to transclude (the T marks the transclusion and links to the original source):    (85C)

Posted by cdent at 03:33 PM | Trackback This | | bl

My Plans for Purple Numbers

The last 24 hours or so of activity related to purple numbers has been very exciting for me. I've been sitting around for more than a year wondering when the concept might get some buzz. And now it has some and that's cool.    (835)

I have some personal hopes and goals for what I want to do with PurpleNumbers that I'd like to record for posterity.    (836)

In my world there are three types of content that have purple numbers. That which is stored in PurpleWiki's persistence system, that which is parsed by PurpleWiki but not stored there, and that which is made purple by some other means.    (837)

Goal number 1    (838)

Granular chunks of all three of those content types should be reachable by a domain and document independent identifier. By this I mean that the URL+anchor at which the content is found is not the identifer, just the NID (Node identifier).    (839)

This requires that content be generated with IDs that come from a networked service that can both provide a globally unique ID as well as resolve that ID back to the current (and possibly unstable) URL where the content is at the moment.    (83A)

Besides providing persistent identifiers pointing to granular content in a way that is more stable in the face of change than current possibilities, it also means that XPath or other tools can be used to transclude content from any source that has these sorts of identifiers.    (83B)

Note that I'm not saying anything about how the purple numbers are presented or how they are added to documents just that they are added, and that the identifiers have a certain nature.    (83C)

Goal number 2    (83D)

This one's quite a bit less generally applicable, but it describes a model of content on the internet of which I'm quite fond. Some might find it reminiscent of Xanadu.    (83E)

In the current release, PurpleWiki stores it's content in WikiText. Each chunk has a NID associated with it. Any chunk that does not have NID when the text is being prepared for a write to disk is given one. One of PurpleWiki's major coolnesses is that although it stores the content as WikiText, its in code representation is a parse tree that can be traversed in a variety of ways to create interesting views.    (83F)

NodaryPublic is a wiki page that describes an in-flight brainstorm from a few days ago of my plan to experiment with separating content, structure and the notion of document away from each other by keeping content in a pool, structure in a graph of nodes that point to elements of content in the pool, and documents as transients that point to single nodes of the tree that are used as starting points for view traversals.    (83G)

In this model everything is versioned, nothing is deleted, everything gets an id. Any node or element can be used as the starting point for editing. Any version of any node or element can be included by reference (transcluded) in anything else. All of it nicely indexed for easy discovery, of course.    (83H)

I'm not entirely sure what this will do. In my mind I see something not entirely unlike a wiki, but with less sense of a page, more granular versioning, and active reuse of content. I see it starting, much like PurpleWiki's TransClusion, as a single domain of content on one computer, and then expanding, from learning and experience, into something that works across networks.    (83I)

Is this practical? Maybe not. Does it cover trodden ground? Certainly. Where will it go? Dunno, but it sure seems interesting to me.    (83J)

Posted by cdent at 12:04 PM | Trackback This | | bl

Big Day for Purple Numbers

In the last 24 hours Tim Bray and Jonas M Luster have purpled their blogs. Tim at ongoing and Jonas at a preponderance of evidence. In the process they've both decided to not display the purple numbers themselves (the NIDs) but rather a '#' symbol. As I've been down this road to hashes and back again to numbers a little history may be in order.    (827)

• Simon Willison has put together plinks a javascript solution for displaying and creating ids on content that is extremely slick. His system has different goals from some I describe below.    (831)
• mnot has a similar thing for anchors. He chooses to be parsimonious in where he puts anchors. Different goals.    (832)
• Michael Day doesn't like the number solution. He would prefer granular addresses be created when text is selected. See his comment and my response to an earlier entry.    (833)

PurpleNumbers started as a way to provide granular addressability to content on the web. What this means is being able to point into a document directly to paragraphs or lists, or whatever else, with a high level of precision. This makes reference and citation much less fuzzy. One never needs to know which part of a document is the relevant piece, the URL takes you right to it.    (828)

Early but contemporary (purple is based on ideas in Doug Engelbart's Augment system) implementations of Purple Numbers for web content created numbers that are unique only in the current document (this is how Tim and Jonas have done things). Those implementations usually displayed the numbers. In part this was because it sort of made sense: we have a sequence of numbers, they indicate a certain structure, etc. In part this was because the documents thusly purpled had a strong chance of being printed, and seeing the number on the page was the best way to make reference to the content.    (829)

When EugeneEricKim and I created PurpleWiki we continued this trend. PurpleWiki gained a small but purposeful user base who used the numbers a lot. That was version 0.1. We got in the habit of calling the identifiers on each paragraph NIDs (for Node Identifier, at least that's what I think it means).    (82A)

For the next version I wanted to implement document independent NIDs. I felt this would provide us with more flexibility for the future when I hoped we would be saving PurpleWiki pages as series of Nodes, rather than as documents. Having document independent NIDs would allow content chunks to move from page to page without too much difficulty, and allow something I had always wanted: TransClusion.    (82B)

So we set about coming up with an identifier scheme. For reason lost to the mists of time (but probably in the PurpleWiki:MailingLists somewhere) we decided to use a 6 digit wide string of numerals and upper cases letters, with leading zeroes as necessary. Eugene and I felt then, as Tim and Jonas do now, that the numbers were distracting so we hid them under a '#'.    (82C)

At that time the NIDs were only being used for making reference to content, so using a right-click or ctrl-click combo to cut and past the URL and NID was all that was necessary: knowing the value of the NID was not.    (82D)

Soon after I implemented transclusion in the PurpleWiki libraries and was able, if I had a NID, to transclude content between my wiki pages and my blog.    (82E)

Somewhere in there, some of the users of PurpleWiki complained about the '#' because they were in the habit of printing WikiPages? and discussing them in person. The '#' was trouble when printing.    (82F)

And still around about the same time, a PurpleNumbers implementation for Zwiki made it clear that the six character wide NID was pretty much stupid: just increment as necessary instead.    (82G)

TransClusion in PurpleWiki is accomplished by using the NID in a special tag. To transclude the following I put '[t 7NY]' into my document for later display processing:    (82H)

(If you click on the purple T you will be taken to the source document.)    (82P)

The combination of smaller NIDs, needing to be able to talk about NIDs and print them, and needing the value for TransClusion pushed us back to displaying the NIDs. I was initially reluctant, but now am glad as it makes TransClusion somewhat more straightforward (it's still harder than it should be).    (82J)

With the setup Jonas and Tim are using in their blogs they cannot do Transclusion or have document independent NIDs. I wouldn't be surprised is they starting thinking about such things as they get used to having the numbers around. I'm extremely happy to see them using the granular addressing aspect of PurpleNumbers.    (82K)

One thing I've found very interesting in PurpleWiki development is what people imagine possible once they've had a glance at what's already been done. Eugene had created purple based on what he knew of Augment and some other similar tools. When he and I got together to do PurpleWiki, we were primarily shooting for granular addressability. Once we got that working, I started getting all jazzed about somehow, maybe, someday, being able to do TransClusion. Eugene was into the idea but I felt somehow that he didn't quite get it. Since then we've implemented TransClusion and new people have come along with ideas of things to do that I'm sure I don't quite get, but are probably a next step that will be great. A good example are the guys who have developed Perplog, a logging (creates purple numbered logs) IRC bot that allows TransClusion of content into the IRC channel. In my work group this has proven to be extremely powerful (our email archives, wiki pages, document repository and irc logs are all purple numbered so any time you need to remind someone of something, it is just a lookup and transclude away).    (82L)

For more info see:    (82M)

• PurpleWiki:HomePage    (82N)
• My purple category in this blog    (82O)

Posted by cdent at 09:57 AM | Trackback This | | bl

Atom IDs, permalinks and persistence

It's nice to see MarkPilgrim being relatively clear about the value of persistent and unique ID's in his How to make a good ID in Atom essay.    (7O4)

What's odd, though, is that all of the reasons he cites for why an Atom ID needs to be persistent apply equally well to permalinks, yet he describes many situations where permalinks have failed to be permanent. Further, he goes on to use the data in those permalinks as sources for Atom IDs.    (7O5)

This makes no sense to me.    (7O6)

If you want an identifier to be unique, your safest bet is to use as little meaningful information as possible. This is why primary keys in databases are often auto-incrementing integers.    (7O7)

And if you want something to be a permanent pointer, like a permalink, that means it is a persistent identifier, even though it is considered in the domain of labels. This means, as much as possible, you should strive to make your permalinks behave as identifiers.    (7O8)

In fact identifiers and permanent pointers are essentially the same thing. An identifier is not a resource, it is a pointer to it. It just so happens to be the only reliable pointer to it.    (7O9)

EugeneEricKim and I had a conversation about identifiers on IRC recently in which he, surprisingly, managed to convince me that XRI may be a good source of identifiers for content on the web.    (7OG)

My interest is in using them as PurpleNumbers but they seem to be able to address some of the issues with Atom IDs and permalinks as well. The important trick is that XRI supports both e-names and e-numbers. If I understand things correctly, an e-name is one of several labels for an e-number. An e-name can be resolved to an e-number and then an e-number can be resolved to a possibly moving resource.    (7OH)

I suspect the primary issue with using XRI is implementation. There's no, as far as I can tell, immediate path to making use of the stuff.    (7OI)

To be complete, I was led to Mark's essay from TimBray?'s ongoing entry on identifiers. I mostly agree with Tim given the current constraints of the web. But those constraints are huge.    (7OJ)

The problem is that, as currently used, permalinks are labels that are vulnerable to change. This is because they contain interpretable meaningful information that is dependent on the present day situation. Tim believes his permalinks are permament but what happens when he looses his domain name or (perish the thought) HTTP ceases to exist?    (7OK)

If we claim the permalink is only the file part of the URL, it is insufficiently unique to be considered stable and persistent.    (7OL)

Also, Mark and Tim, what's with the lack of TrackBack or comments? I guess I'll ping them by other means.    (7OM)

Update: Bill de Hora has joined the fray with his usual sensible statements about the way the world is versus how we might like it to be. "The deployed Web works against cool URIs not for them."    (7OP)

Yet another update: DannyAyers joins in, pointing to both Mark and Tim and saying: "Mark’s advice is very well put, but I’d suggest at least that if advice like the following is needed then something in the state of Denmark is edging towards it’s sell-by date[...]"    (826)

Posted by cdent at 05:49 PM | Trackback This | | bl

Purple Spreading

Jonas M Luster has once again suggested PurpleNumbers as a good aid for doing proper blog sourcing. His posting prompts me to put down some thoughts I've apparently forgotten to record in the past.    (7NP)

Jonas mentions some methods for purpling blog postings:    (7NQ)

• My Purple Plugin for MovableType.    (7NR)
• A filter for WordPress    (7NS)
• PurpleSlurple.    (7NT)
• Jonas is working on something for DruPal? (I'd love to hear more about this).    (7NU)
• Phil at Among Other Things has created an additional WordPress filter.    (7NV)

There's also EugeneEricKim's plugin for Blosxom.    (7NW)

One large difference between the plugins that Eugene and I use and other systems is that ours use the PurpleWiki libraries to create unique identifiers for each chunk of content. This allows TransClusion of content among blog entries and with associated Wiki pages. Follow the TransClusion link to see this in action or visit PlaNetwork:InternetRelayChat to learn how it is being used with an IRC channel associated with next week's Planetwork conference. In that setup purple numbered content from the wiki and irc logs can be transcluded back into the live IRC chat. That system is using another PurpleWiki related tool: Perplog.    (7NX)

The long term goal of TransClusion in PurpleWiki is to enable to direct granular quotation of content anywhere on the web, making citation sort of automatic. I have a working prototype of TransClusion amongst geographically disperse servers, but the current solution doesn't scale so there's more work to be done.    (7NY)

Another way to purple HTML content is with some Javascript to process the Dom of a page when it is loaded. There's probably a way to automate this, but if you have a page that you would like to quickly purple make these changes to the header:    (7NZ)

   <head>
    <script language='javascript' src='ator.js'></script>
  </head>
  <body onLoad="purp(window.document.getElementsByTagName?('body')[0])">    (7O0)

and in a nearby file (that I've called ator.js) put this:    (7O1)

  var tagsRE=/\bh|p|li|dt|dd|pre\b/i; 
  var nid = 0;
  var purpleStyle = "font-family:sans-serif;font-weight:bold;font-size:x-small;text-decoration:none;color:#C8A8FF"
  function purp(node){
      if (node.hasChildNodes?) {
        var hi_cn;
        for(hi_cn=0; hi_cn<node.childNodes.length; hi_cn++) {
            purp(node.childNodes[hi_cn]);
        }
      }
    if(node.nodeType == 1) {
        if (tagsRE.test(node.nodeName)) {
            var nidValue = "nid" + nid;
            node.setAttribute('id', nidValue);
            newNode = document.createElement('a');
            newNode.setAttribute('href', "#" + nidValue);
            newNode.setAttribute('style', purpleStyle);
            newNode.innerHTML = " " + nid;
            node.appendChild(newNode);
            nid = nid + 1;
        }
      }
    }    (7O2)

I originally posted this in a message to the BlueOxenCollaboratory. The code is adapted from PaulFord?'s The Passivator which itself is adapted from something else. Such is the way of the Internet and it is good.    (7O3)

Posted by cdent at 04:48 PM | Trackback This | | bl

PurpleWiki 0.9.2 Released

PurpleWiki version 0.9.2 has been released. See the ChangeLog for details on the changes. You can get the release either from CPAN or from the distribution page.    (4M8)

The parts that I like about this release are that it has:    (4M9)

• Much improved view drivers (the parts that take a parsed wiki page and turn into HTML or some other format) that make some forms of transclusion faster and more reliable.    (4MA)
• Support for remote NID and TransClusion handling. That is, if you configure things correctly, you can create content on one machine, and with some ease, transclude it on another.    (4MB)

Now I need to find some people who want play with remote TransClusion. Anyone?    (4MC)

Posted by cdent at 03:53 AM | Trackback This | | bl

PurpleWiki 0.9.1 Released

I posted the following to a couple of mailing lists today. Figured I better copy it here.    (2PQ)

I'm proud to announce the release of the latest version of PurpleWiki: 0.9.1.    (2PR)

This release fixes several bugs, notably a problem with viewing previous versions of files, and adds a few new features:    (2PS)

• Searching is provided by a set of pluggable modules that can be extended. Modules are provided for searching the wiki, bloxsom and MovableType weblogs, Google, Arts repositories and irclogs in wikitext format.    (2PT)
• Support for WikiWhiteboards?. See http://www.xml.com/pub/a/2003/11/19/svgwiki.html    (2PU)
• Transclusions can be retrieved as plain text in addition to the usual HTML and, if necessary, can be retrieved from sites requiring HTTP Basic Authentication.    (2PV)

Additional bug fixes and features are listed in the ChangeLog?, which can be found at:    (2PW)

  http://www.blueoxen.org/tools/purplewiki/ChangeLog    (2PX)

More information and links to the download can be found at    (2PY)

  http://www.blueoxen.org/tools/purplewiki/index.html    (2PZ)

and at the PurpleWiki PurpleWiki:    (2Q0)

  http://purplewiki.blueoxen.net/    (2Q1)

If you are upgrading an existing PurpleWiki installation, there are a small number of changes you will need to perform, described in the UPDATE file in the distribution. New installations should follow the instructions in the README file. In either case please check the ChangeLog? file to see what's new.    (2Q2)

If you are using PurpleWiki or interested in helping out with development please subscribe to the mailing lists described at:    (2Q3)

  http://purplewiki.blueoxen.net/cgi-bin/wiki.pl?MailingLists    (2Q4)

The developers have already started on the 0.9.2. Features in the works (only some of which will make it into 0.9.2) include:    (2Q5)

• Abstraction of the wiki page database (to eventually allow other storage formats)    (2Q6)
• Support for WikiRPCv2?    (2Q7)
• Server independent NIDs (to allow transclusions between servers)    (2Q8)
• Better handling of the transclusion database    (2Q9)
• Fully compliant XHTML output    (2QA)
• Better syndication of RecentChanges    (2QB)
• HyperScope? view driver    (2QC)
• Template support    (2QD)
• Improved documentation, better tests, cleaner code, and much more    (2QE)

Posted by cdent at 10:22 PM | Trackback This | | bl

PurpleWiki alpha Available

I've put together an alpha release of the latest PurpleWiki:    (2EV)

  http://www.burningchrome.com:8000/~cdent/tools/PurpleWiki-0.9.1.tar.gz    (2EW)

This version adds several features that seemed valuable:    (2EX)

• Pluggable search modules that uses a nice simple object model to all wiki searches to spread out from the wiki to other system. Thanks to David Fannin for the inspiration to do this. This part is woefully undocumented, ask me if you have trouble, several Config changes are needed. Modules can be made for anything that you can figure out a way to search from Perl. Modules are included for:    (2EY)
  • Wiki: the wiki itself. This just moves existing code out to the module.    (2EZ)
  • MovableType. It's very handy to be able to find BackLinks from the blog into the wiki. The blog and the wiki need to be on the same machine.    (2F0)
  • Arts (a simple knowledge base system. See http://collab.blueoxen.net/forums/tools-yak/2003-12/msg00001.html and related threads for more on arts.)    (2F1)
  • IrcLogger? (see http://collab.blueoxen.net/forums/tools-yak/2003-12/msg00003.html and related threads for more on that)    (2F2)
  • Google (SOAP::Lite and a google key required)    (2F3)

• A wiki whiteboard based on Danny's stuff. See it in action at PurpleWiki:WikiWhiteboard    (2F4)

• The ability to choose whether nids show up as '#' or the value of the nid. Set the boolean Config value ShowNid? to get this (uncomment it in the config file).    (2F5)

• Updates to the bloxsom plugin to support the bloxsom cooluri plugin from Rob Hague.    (2F6)

Note this is an alpha release. I'm using it in production environments but that doesn't mean it won't eat your wiki, so try with care. If you do try it, please send comments to the PurpleWiki development mailing list.    (2F7)

Coming Soon    (2F8)

Things we've talked about for future releases:    (2F9)

• A more modular database system to allow pages to be saved in formats other than the current (and sort of difficult to mess with) UseModWiki format.    (2FA)

• Template system for more configurable presentation.    (2FB)

• Server independent Nids and TransClusion to allow content from wikis and wikitext on different machines to be transcluded. There's some discussion of that in the development list archives.    (2FC)

Posted by cdent at 02:24 AM | Trackback This | | bl

More Purple Noodling

There's been discussion at the BlueOxenCollaboratory about making a ChurchOfPurple logo to go along with the hymns being bantied about.    (21D)

I fiddled about in Illustrator some, first making this:    (21E)

but quickly became dissatisfied, so made this, which might be better:    (21G)

Meanwhile, Matt Schneider countered my grumpiness with being able to understand PurpleNumbers with a good example from conversation with his grandfather.    (21I)

Update: Matt has corrected me: The gentleman in question is his father not grandfather. I'm not sure how I got that. It says father right there in the referenced bit. With server independent purple numbers, I could have just transcluded, and not had to worry about it.    (2PN)

Posted by cdent at 11:12 PM | Trackback This | | bl

Purple Hymn

PeterJones has composed a hymn for the church of purple    (20U)

  Church of Purple Hymn:    (20V)

  "Purple links all around my text,
  Lately things just don't seem so vexed,
  Acting happy and I now know why,
  'Scuse me, while I transclude the sky." # 
      by Jimmy Hotlinx. #    (20W)

This is perfect.    (20X)

Unfortunately like so many things in the PurpleNumbers universe, if you get it already this gives you a comfortable feeling of understanding. If you don't already get it, I bet this just makes you go "huh?".    (20Y)

How to fix that?    (20Z)

Posted by cdent at 11:12 PM | Trackback This | | bl

wikiPiki Pictures

In my last entry I posted some pictures of things going on in the yard. I've since thrown together some code that puts these pictures into the wiki so that I can add some narrative and other people can add some comments.    (T7)

I've automated the process of generating thumbnails, middle size images, and creating a series of pages in the wiki, including pages that are primarily used for sources of TransClusion, not for viewing. This makes it easy to suck in a transcluded image, like so:    (T8)

+ ++ T    (T9)

A problem with this, though, is that it is also possible to load up a page with a huge number of images. Anyway, it's a first go. Feel free to write some comments in there with the images. I suspect it will be weird at first, but maybe it'll become handy, or maybe I'll throw it out.    (TA)

TheYardContents    (TB)

Posted by cdent at 08:59 AM | Trackback This | | bl

PurpleBlog

I'm going to try a little experiment.    (JK)

Now that PurpleWiki has reached some degree of stability, it makes sense to create a demonstration site for the PurplePlugin that allows people to experiment with what I've been enjoying for a few months.    (JL)

So...I've created a MovableType / PurpleWiki combo that can be used by other people in two ways:    (JM)

1. There is a test blog where people can create entries that use the plugin.    (JN)
2. I can host blogs, if it doesn't use up too many resources, on this server that can use the plugin.    (JO)

Both options are linked to a shared purplewiki (not much there yet, you can change that, it's a wiki after all).    (JP)

What's most interesting, to me, about the second option is that the content that is generated in all the hosted blogs and the associated Wiki is available for TransClusion because they will all be using the same PurpleNumber sequence generator (assuming the blogs opt to use the PurplePlugin).    (JQ)

Let me know if you want to give either of these options a try.    (JR)

Posted by cdent at 01:26 AM | Trackback This | | bl

Purple Upgrade

With PurpleWiki's 0.9 release, I've had to upgrade my blog and wiki to use the released code. Since I've been using this blog to experiment with data formats for the last several months, this was no small feat.    (JG)

But it appears to be working with a few problems:    (JH)

1. Incoming #nid links will not work correctly. The link will land on the right page, but the because of sames changes in data storage and presentation the named anchors are oh so slightly different. This was pretty much unavoidable.    (JI)
2. Node ids in the wiki have completely changed so any references into the wiki or transclusions from the wiki are buggered. This was completely avoidable but I messed up a regular expression in a quick script that I didn't bother to test and I was bit...    (JJ)

Posted by cdent at 10:39 PM | Trackback This | | bl

PurpleWiki 0.9 Released

I'm pleased to announce the availability of the long awaited PurpleWiki version 0.9.    (0001HW)

PurpleWiki is a WikiWikiWeb? implementation derived from UseModWiki that adds several features and modularizes the code for easier development. Some of the features include:    (0001HX)

• Purple numbers, a system that allows fine-grained linking to content elements in a web page.    (0001HY)
• A flexible parser that supports pluggable output formats and use by other tools. Plugins for use with the MovableType and Bloxsom weblog tools are included.    (0001HZ)
• RSS feeds of recent changes.    (0001I0)
• TransClusion of content between pages managed by the parser (within and without the wiki).    (0001I1)

The release includes extensive code cleanup, refactoring and documentation.    (0001I2)

Access to the release, documentation, and development information can be found at http://www.blueoxen.org/tools/purplewiki/    (0001I3)

The distribution package itself: http://www.blueoxen.org/tools/purplewiki/purplewiki-0.9.tar.gz    (0001I4)

The fun usefulness that is PurpleWiki is better experienced than explained. Follow the links below for some samples:    (0001I5)

• The PurpleWiki home wiki: http://purplewiki.blueoxen.net/    (0001I6)

• This blog, using the PurpleWiki MovableType plugin, including a collection of entries on the PurpleWiki development process and many things purple.    (0001I7)

EugeneEricKim's blog, using the PurpleWiki Bloxsom plugin:    (0001I8)

  http://www.eekim.com/blog/    (0001I9)

There are announce, user and developer mailing lists for PurpleWiki. Find more information about these at:    (0001IA)

  http://purplewiki.blueoxen.net/cgi-bin/wiki.pl?MailingLists    (0001IB)

Posted by cdent at 08:31 PM | Trackback This | | bl

Purple commentary

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)

Posted by cdent at 05:39 PM | Trackback This | | bl

Why is it Purple?

Someone in the group I'm working with asked why PurpleNumbers are purple. My answer ended up being a big context provider, so I'm dumping it here. This is likely full of errors as the story as I've heard it is incomplete and I was unable to check some things because the network path to California was busted while I was writing. Saved here for later revisions.    (0001EX)

UPDATE: Eugene has filled in some of the gaps in this and corrected some misconceptions I had.    (0001HQ)

It's purple mostly by chance    (0001EY)

Back in the late 60s and early 70s Doug Engelbart's lab at the Stanford Research Institute was working hard on allowing people to work together to be more effective at solving problems. One of the first things they discovered was that people don't work together as well as they could and the tools and process for doing so were not well developed.    (0001EZ)

So, they set about working on those tools and processes. Some of the things they developed include: mice, personal workstations, hypertext, windowing GUIs, chorded keyboards, video conferencing, remote terminal manipulation and something called NLS.    (0001F0)

NLS was a do-it-all editing environment for communication and coding. It had a graph based document storage model that allowed structural/sectional and nodal identifiers to be placed on content of the documents, based on various rules depending on the type of content. Nodal identifiers stayed with the content, regardless of how it was edited. Structural identifiers were hierarchical from the start of the document, indicating nested sections and lists. As such they could change as the document was edited and published.    (0001F1)

The editor was customized to be aware of these things so that the identifiers could be made visible or invisible as necessary.    (0001F2)

When editing documents it was possible to use copy from other versions or other documents in several different ways:    (0001F3)

• copying, like cut and past    (0001F4)
• copy by referencing an identifier    (0001F5)
• transclude by referencing an identifier    (0001F6)

I don't know if they called it transclusion or not. That term comes from Ted Nelson and his Xanadu project. While Xanadu has some similar goals and concepts to NLS (later called Augment) it has a much different attitude toward hierarchy. NLS is all about hierarchy, Nelson doesn't like rules.    (0001F7)

What it means, though, is that you have the content by reference. If it is changed in the original source, the change shows up immediately in the place where it is transcluded.    (0001F8)

In both Augment and Xanadu you can jump around in and amongst documents in the now familiar hypertext way. In those environments, though, the links were bidirectional. If you followed a link to its destination, you could tell at the destination that there was an incoming link, and you could follow it back home. In both systems, links were highly granular: in NLS you can jump to any identifier, in Xanadu you can jump to anything.    (0001F9)

Fast forward a few decades to the Berners-Lee web. Hypertext the HTTP/HTML way comes into being and catches on like wildfire, in part because it is simple to implement. That simplicity left out some fun features:    (0001FA)

• granular addressability    (0001FB)
• bidirectional linking    (0001FC)
• transclusion    (0001FD)

Fast forward a few years later still: Doug Engelbart has never received the proper credit for the things he developed. Nowadays he spends his time sitting in a fairly pleasant windowed office just down the hall from the cafeteria at the Logitech building in Silicon Valley. He participates in a group called the Bootstrap Alliance ( http://www.bootstrap.org/ ) which still struggles valiantly on attempting to fulfill Doug's vision of coming up with ways to help society solve what he calls complex urgent problems.    (0001FE)

Part and parcel of that vision is, amongst many other things, granular addressability of content; as much content as possible. To help display the value of granular addressability, the content on the Bootstrap site is marked up with identifiers very similar to those in Augment. These NIDs, as they came to be called, were published in purple.    (0001FF)

A next step was to add purple numbering to mail archives, still considered one of the primary places for productive conversation. This allowed granular referencing. EugeneEricKim added a filter module to Mhonarc to make that happen. He then later created some code for processing well formed XML to add identifiers to arbitrary tags within.    (0001FG)

Still later he and I modified UseModWiki to create PurpleWiki, allowing the same granular referencing into wiki content. MattLiggett created the first iteration of the IRC logger, processing the output to HTML with purple numbers.    (0001FH)

Around Christmas of 2002 I started mooning over how to add transclusion to the already beneficial granular addressability. I had long been grumpy about the fact that the identifiers used with PurpleNumbers were only unique to the page on which they were presented. This struck me as a horrible violation of identifier ethics.    (0001FI)

I realized that if we started creating identifiers from a central source, all the tools that used that source would be able to transclude content from one another.    (0001FJ)

So that's what I did. TransClusion is now possible in a rudimentary form by screen scraping from web pages.    (0001FK)

The latest version of PurpleWiki is generic enough that its purple number tools can be used with a variety of applications. The new style of purple numbers have been implemented in:    (0001FL)

• PurpleWiki (of course)    (0001FM)
• Zwiki    (0001FN)
• Blog plugins    (0001FO)
  • MovableType    (0001FP)
  • Bloxsom    (0001FQ)
• Mailman pipermail archiving software    (0001FR)
• A new version of my Arts tool    (0001FS)

and coming soon:    (0001FT)

• Mhonarc mail archving software    (0001FU)
• The IRC logger    (0001FV)

As it turns out, if you are on a white background and the CSS is set up correctly, the fuzzy lavender purple looks pretty good, noticeable but not too intrusive.    (0001FW)

Posted by cdent at 10:31 PM | Trackback This | | bl

PurplePlugin Testing

Apparently it's been some days since I've made a posting about PurpleNumbers, PurpleWiki and the PurplePlugin. None show up on the front page. Shock. Horror.    (00019U)

This is a test of a bug fix. PurpleWiki 0.2 (soon to be renamed to 0.9) is stable and works marvelously.    (00019V)

Posted by cdent at 01:19 AM | Trackback This | | bl

PurpleWiki/PurplePlugin pre-release

After far longer than expected, version 0.2 of PurpleWiki, including a PurplePlugin for MovableType is available for pre-official-release download.    (00017E)

This version adds support for:    (00017F)

• Document independent node identifiers (NIDs)    (00017G)
• A more modular architecture for future improvements    (00017H)
• A more flexible configuration sytem    (00017I)
• Improved packaging and testing    (00017J)
• A PurplePlugin for MovableType (that's what makes this blog go, see BlogTweaks)    (00017K)
• Rudimentary TransClusion support    (00017L)
• Document authoring features    (00017M)

Be warned: this release is not yet well tested and not all the features have been fully documented. This pre-release is being made to seek feedback to clean things up for the official release. There will be changes between this release and the official release. That said, I'm currently using this version here, and on a test WikiBlog.    (00017N)

If you would like to try it out, read PurpleWikiInstructions and PurplePluginInstructions. The download link is there, along with step by step installation instructions.    (00017O)

If you have any questions feel free to contact me, leave a comment here, or leave comments in the wiki.    (00017P)

Posted by cdent at 04:52 AM | Trackback This | | bl

Purple Plugin Closer

Nearly there.    (00014I)

What's left:    (00014J)

• Some unitialized value warnings when entering new posts or new comments (testing for those is the real reason for this post).    (00014K)
• Three remaining global variables that ought to be killed.    (00014L)
• Installation docs.    (00014M)
• Use docs.    (00014N)
• Test cases for the database classes.    (00014O)

See PurplePlugin for more.    (00014P)

Posted by cdent at 06:20 PM | Trackback This | | bl

Purple Number Paradigms

Tom Coates comments on how the small revolution of permalinks brought about a paradigm shift in personal publishing. He makes several points on the value of a permalink that map directly onto the value of a PurpleNumber:    (000137)

• Both a PermaLink and a PurpleNumber "make it possible for people to link to something with a higher level of granularity than just the page".    (000138)
• Both inflict "more clutter on the weblog-page" that people get used to and provide what amounts to a nice cognitive handle.    (000139)
• Clicking on both doesn't "take you anywhere" but allows you to make a reference.    (00013A)
• Both provide a method for making a highly specific gesture, potentially encouraging discussion.    (00013B)
• Both provide a method for building bridges between content.    (00013C)

The value of the increased granularity of access provided by permalinks suggests, but does not guarantee, that the even greater level of granularity provided by PurpleNumbers will be valuable as well. It certainly has been for me.    (00013D)

(The PurplePlugin should be ready for testing by stalwarts sometime this week, a solution to the config problem is in the works. If you want to help with the testing, have a MovableType blog of the 2.6 or greater variety, and can install Perl modules, let me know.)    (00013E)

Posted by cdent at 05:51 PM | Trackback This | | bl

Purple Number Placement

Mike asked some questions in the comments to Purple Number Identity that boil down to why put the link at the end of the paragraph:    (00011I)

There are a few different reasons why the purple number follows its graf, none of which are conclusive, but frequent use seems to like them there:    (00011K)

• I find them less visually jarring at the end of the paragraph where they don't interrupt the flow of the reading quite as much. PurpleSlurple has used links at the start of lines, so there is a good place to look for comparison.    (00011L)

• I find them more useful at the end because that is when I want them. Imagine the flow of action when reading: I'm reading along and read a paragraph to which I'd like to make a reference. I don't know this until I've read the paragraph and lo, there at the end is my tool for helping with that reference.    (00011M)

• Having the anchor at the start of the paragraph and the link at the end makes parsing for TransClusion a good deal easier than it would be otherwise.    (00011N)

Part of the reason the purple numbers are done in their tasteful lavender style is to minimize their intrusion in the content.    (00011P)

Using section or graf markers might make sense in combination with hiearchical or section IDs but not as much with NIDs.    (00011Q)

Hiearchical IDs are designed to label ordered sections of a document. The second header is always the second header because it is second. NIDs indicate the content not the order. If you change around the order of the text, the NID goes with its original text.    (00011R)

Consider a non-NID example with poetry. I've written some poetry that for reasons beyond my understanding you like so you've made a reference to it. You read the first version:    (00011S)

  Lo, I was dead, speared by truth (01)
  Spread fast among the yearning (02)    (00011T)

You wonder what that second line means so you send me some email referencing purple number 02. Later I change my mind a bit and reorder:    (00011U)

  Spread fast among the yearning (01)
  I was dead, speared by truth (02)    (00011V)

When you wrote your email your HID pointed to "Spread fast among the yearning". When I read the email it pointed to "I was dead, speared by truth".    (00011W)

Using NIDs would have the second version like this:    (00011X)

  Spread fast among the yearning (02)
  I was dead, speared by truth (01)    (00011Y)

There is discussion of implementing both HIDs and NIDs in future versions of PurpleWiki. If we do, it is possible that HIDs would go at the start of the line. HIDs are very handy for printed documents, or other sitations where a human readable and speakable identifier is valuable, even if it might change between revisions.    (00011Z)

Posted by cdent at 06:34 AM | Trackback This | | bl

Purple Number Identity

I sat down tonight to write something about PurpleNumbers, as I have several things I need to write for the 0.2 release of PurpleWiki. This is what came out. It fills a different, but similar, purpose to the coolness draft.    (000103)

What is a purple number?    (000104)

A purple number is an identifier unique to a document or set of documents used to indicate and provide direct access to segments of content in a document.    (000105)

In practice a purple number identifies structural elements in a document such as headers, list items and paragraphs. When a new document is created or content is added to an existing document, the document is parsed to add identifiers where they are not already present. When a document is processed for presentation (usually, but not always, to HTML) these identifiers are used to create anchors and links in the document that can be used for later reference.    (000106)

Purple number identifiers are known, for reasons of history, as node identifiers, or 'NIDs' for short.    (000107)

In simple implementations NIDs are unique per document and may be generated per page, perhaps as a series of integers. More complex implementations create NIDs that are unique across a domain of documents. These NIDs are generated from a central sequencing source or service that provides the next available NID. If NIDs are paired with document identifiers (usually URLs) to create an index, references may be made by NID alone (some uses for this are described below).    (000108)

When a document that has been processed to add NIDs is presented as HTML, the NIDs are shown as links (<a href>) to named anchors (<a name>) within a stable URL for the current document. In some current implementations these links are shown in a purple color (thus the name).    (000109)

If the identifiers used are human readable (short, sensible), there are benefits to displaying the identifier as the text of the link: reference can be made to the identified segment of content in speech. When the identifiers are more complex a single character, such as the '#' popularized as a permanent link in some weblogs, has proven to work well.    (00010A)

Current purple number implementations process text, wiki formatted text, or HTML to either specially formatted wiki text or HTML. The resulting wiki text or HTML embeds text containing the NIDs for each segment of the document. When HTML or wiki text that contains NIDs is reprocessed that text which has already been assigned a NID keeps it's existing NID and that text which is new gets the next NIDs provided by the sequencing service. If content is deleted, NIDs must not be reused as references to NIDs must be allowed to go stale when content is removed.    (00010B)

HTML presentations of content with purple numbers adjusts the content in two ways to provide two different functions: the href provides the text of the URL that can be copied to make reference from other environments; the named anchor provides the location to which that reference points. The value of the name attribute of the anchor is the NID.    (00010C)

When NIDs for a set of documents are created from the same central source and the NIDs are paired with the URLs of the document in which they are to be presented the resulting index can be used to remotely make reference to content by NID alone. This has several benefits:    (00010D)

• Simplified URLs can be used to refer to content.    (00010E)
• By updating the index, content addressed by NID can remain addressable even when moved to a new URL.    (00010F)
• Content can be referenced and retrieved by NID and then easily parsed out of its context by NID. This allows for transclusion (include by reference rather than copy) of content from one document in another.    (00010G)

There are several existing implementations of purple numbers. Some examples are:    (00010H)

PurpleWiki    (00010I)

A descendant of UseModWiki that supports purple numbers. Version 0.1 with support for document based NIDs has been released. Version 0.2 with multi-document NIDs, document authoring features (metadata management), more modular code and transclusion support is being developed. Update 2003/06/02: PurpleWiki 0.9.2, faster, better stronger, has been released to CPAN.    (00010J)

PurplePlugin    (00010K)

A MovableType plugin that uses PurpleWiki 0.2 to format entries with purple numbers, to support transclusions and to provide WikiBlog functionality to MovableType.    (00010L)

Mhonarc purple plugin    (00010M)

An addition to the mhonarc mail archiving system that provides purple numbers on mail messages. source, demo.    (00010N)

Purple ZWiki    (00010O)

Modifications to ZWiki to support purple numbers. demo.    (00010P)

PurpleSlurple    (000111)

A proxy system that adds purple numbers to existing HTML documents anywhere on the net.    (000112)

Purple    (000113)

A processing system for creating documents with purple numbers. source    (000114)

See also: PurpleNumbers, PurpleWiki, PurplePlugin, TransClusion and the rest of the geek-glaxon category.    (00010Q)

Posted by cdent at 08:26 AM | Trackback This | | bl

Automation, Augmentation and Discipline

StuartHenshall and I have been talking in email about PurpleNumbers in relation to collaborative intelligence building, wikis and blogs. Parts of a recent email I want in my PurpleNet for later reference so I'm sticking it in here, with some edits because I'm an undisciplined writer.    (0000YI)

Stuart had asked for some thoughts on the differences and similarities between NexistWiki and PurpleWiki:    (0000YJ)

Posted by cdent at 06:44 PM | Trackback This | | bl

Pure Purple Plugin Testing

Until now the code for doing the PurpleNumbers on this blog involved some hacks down inside lib/MT. This made for some nastiness for trying thigns out. I've made some adjustments to make it all work from a plugin. This is a test of that. My fingers are crossed.    (0000VB)

It's working, at least so far.    (0000VC)

Posted by cdent at 11:28 PM | Trackback This | | bl

purple transclusion proxying

Putting this here because I want to remember it for later.    (0000UD)

Now that I have the blog and wiki doing TransClusion, I want it in my email. I often want to reuse content from the email I send and the email I receive.    (0000UE)

A hacky way to do this, using the hacky way that TransClusion is curerntly done would be to deliver all email to a modified mhonarc archive that purples messages using the same sequence genrator as the blog and wiki. Outgoing messages could be filtered either through the PurpleWiki parser or a simple text filter that would expand transclusion tags.    (0000UF)

At first glance this may seem a bit bogus as the archive content never changes: why transclude instead of copy. Well, for starters it gives you easy access back to the original content.    (0000UG)

And having purple numbers on all of one's mail would be handy.    (0000UH)

I'm to the point now where I'm hesitant to write something if it isn't getting purple numbers.    (0000UI)

Posted by cdent at 08:28 PM | Trackback This | | bl

Purple Number Coolness Draft

Draft, Work In Progress, Usual Disclaimers Apply, Help a Brother Out.    (0000SO)

(Explaining the value of PurpleNumbers without a show and tell has proven challenging. Suggestions for improving this document are encouraged: I'm convinced PurpleNumbers are a good thing and I'd like to convince other people but I'm so deep in kool-aid now that I have trouble seeing.)    (0000SP)

PurpleNumbers are a system for enabling granular addressability in networked documents. While in essence this is a pretty simple concept, the way it works and how it is used deserves some explanation.    (0000SQ)

One of the many benefits of the internet is the way in which it makes a vast quantity of information available. News, research and the drama of human life are available at the click of a link. Access to this information allows us to participate in many aspects of human communication over distances.    (0000SR)

Making use of this information (using it again), though, is somewhat constrained. Consider the following example:    (0000SS)

In either case you have to do some searching around in the document to find the original text. With granular addressability I could point you directly to the beautiful paragraph in one link and you can browse there and read Snoopy's extraordinary prose, in context. Here are three more examples:    (0000SU)

Granular addressability is a small, simple tool to help with these situations. It is not a new idea: The Bible provides easy access to Book, Chapter and Verse. Many works of classic literature are published with line numbers. It is also not an idea without a future: the Xpointer standard is specifically designed to provide (when browsers support it) granular addressability in valid XML documents (when they become more common) such as XHTML.    (0000SY)

PurpleNumbers fit in between printed line numbers and Xpointer as a tool for making reference to existing documents as well as creating documents that enable easy reference. PurpleNumbers provide handles to sections of documents that can be used as links in electronic documents that refer to the sections or used as labels in conversation about the sections. PurpleNumbers can address each of the scenarios above. In the first three cases PurpleNumbers allow the discovery and use of a direct URL pointing to the content being discussed. In the latter case, PurpleNumbers can provide a human readable label that points to the text and can be used in speech: "It's at purple number 52".    (0000SZ)

The PurpleNumbers systems that exist today are based on the addressing features of DougEngelbart's Augment system. The systems come in two forms:    (0000T0)

Document Processors    (0000T1)

These systems take new or existing content and process it to create a new document that has PurpleNumber identifiers and links in the text. Such systems are good for applications where filters can be used at the moment of storage such as mailing list archives, wikis and document transformation. Because of the way documents are processed, even in the event of changes the PurpleNumbers stay with the text they are originally associated with.    (0000T2)

Document Proxies    (0000T3)

These systems take existing documents and dynamically present them with PurpleNumbers attached. This works well with documents that are not expected to change and for which creating new documents may not be useful.    (0000T4)

See PurpleWiki and PurpleSlurple for links to more information on the tools used to create PurpleNumbers.    (0000T5)

Most graphical web browsers have a feature to copy the URL of a link to the clipboard. In some operating systems when using Internet Explorer and Mozilla you can right click on a link and "Copy Shortcut" or "Copy Link Location". When a document has PurpleNumbers there is a link, represented as a numeral or a '#' associated with each paragraph, list element and header in the document. Right click the PurpleNumber and, copy the shortcut and paste it into another document. The result? An instant granular reference, in context and with less navigational confusion.    (0000T6)

This may not seem like much, but with use the value of granular addressability increases until its absence feels quite the hindrance and an itch grows to add purple numbers wherever possible. They've been used on traditional web pages, mail archives, wikis, blogs, dialog maps, chat logs and many other places.    (0000T7)

Posted by cdent at 04:36 AM | Trackback This | | bl

PurpleWiki Transclusion Test

The next indented paragraph should be a transclusion from elsewhere on this blog.    (0000QA)

By transclusion I mean that text is there by reference, not by copy. If the remote text is changed (and the blog rebuilt) the text will change here too.    (0000QC)

If you click on the purple 'T' you'll go to the original, in context.    (0000QD)

If this still doesn't make sense, here is the content of this entry in the database, before I added this paragraph, and word wrapped for readability.    (0000QI)

Posted by cdent at 09:00 AM | Trackback This | | bl

More fun with Purple Numbers

This evening I spent some time with MovableType and PurpleWiki to get PurpleWiki parsing working in blogs comments instead of just entries. This enables a few features in comments:    (0000MJ)

• PurpleNumbers    (0000MK)
• WikiWord parsing    (0000ML)
• WikiFormatting possibilities, such as headers, lists, italics, bold    (0000MM)

Because of the way MovableType is set up, all comments get the same text formatting options, so PurpleWiki for comments is either on or off. It's on now. For those of you who don't care, just keep on as before; there shouldn't be any disasters. Give it a try.    (0000MN)

A project for this month is to merge the several disparate branches of PurpleWiki development into a new release and in the process:    (0000MO)

• Create a technical specification so that other tools can implement purple numbering features.    (0000MP)
• Create a roadmap for future developments.    (0000MQ)
• Write a Why Is PurpleWiki Cool evangelical sermon of sorts that spreads the good word and acts as a tutorial.    (0000MR)
• Address some usability issues that come about from conflicts that occur when optimizing for the internal (invisible) and external (visible) representations of the PurpleNumber.    (0000MS)

There are some more thoughts about this stuff at PurpleWikiScratchpad.    (0000MT)

A primary goal is to get this stuff more out there and for that I could do with help and advice from anyone who happens to be reading this. If you are familiar with PurpleNumbers and have some comments about them, please leave them here. If you see them, but just don't get it, let me know, as that's valuable too. If you have suggestions on how to build some bridges with other developers to integrate Purple ideas into their tools, that would be good too.    (0000MU)

What's lacking is a salient bit o' info that captures what makes these little purple things helpful. Thus far people either get it quickly or don't get it, and that's not good enough.    (0000MV)

Posted by cdent at 08:45 AM | Trackback This | | bl

PurpleWiki MovableType update

In a recent comment on an early entry about integrating PurpleWiki and MovableType, Danny Ayers asks about what sort of progress has been made. Here are some rough notes on what's up.    (0000GM)

The original goal was to create handles (PurpleNumbers) for granular addressing to paragraphs in blog entries. That's done and works just fine. The little purple hash marks that follow each structural section of this entry are href's pointing to named anchors within the text. You can copy and paste the URL under the # and make direct reference.    (0000GN)

Because the system is using the PurpleWiki parser to create the PurpleNumbers there are a few bonus features:    (0000GO)

• Wiki formatting such as lists    (0000GP)
• Wiki words such as FrontPage are parsed and point to a configured wiki    (0000GQ)

Thus far I have been unable to make this stuff work as a pure Text Formatting plugin for MovableType. This is because the plugins run each time an entry is formatted for output. The PurpleNumbers I'm using are domain unique ids that are created at the time the referenced text is created and stay with the text after that. The computation to create the numbers must be done before the text is saved into the data store. Ben Trott has provided a suggestion for how to override MT::Entry::save() outside the distributed code but I've not had time to mess with that, so these features require a patch down inside lib/MT. So, saving the text as PurpleWiki is not a plugin, but the presentation (the wiki to html translation) is.    (0000GR)

Further complicating the picture is the fact that my current development version of PurpleWiki is far off the current 0.1 release and not well packaged. My changes include:    (0000GS)

Sequence based purple number generation    (0000GT)

This allows for PurpleNumbers that are unique across a given domain and provides the basis for lots of future fun.    (0000GU)

Explicit naming of the URL that forms the base for the named anchor    (0000GV)

This was necessary for MovableType to ensure the PurpleNumbers point to the permalink.    (0000GW)

Support SpaceCGI    (0000GX)

Very rudimentary support for human and machine readable fake/manual TransClusion. Follow SpaceCGI for more info and a demonstration.    (0000GY)

That's the stuff that's being used on this blog.    (0000GZ)

Also in the works is a graph-based data storage mechanism for Wiki pages and other systems that use the PurpleWiki parser. The goal of that work is to implement true transclusions in wiki pages. It's fairly close at this point but I need some serious HeadSpace to get it to all come together and that hasn't been available lately. In the meantime I've considered hacking the mechanism that SpaceCGI uses into the PurpleWiki viewer code.    (0000H0)

In related news: TomMunnecke noticed on the collab list that MovableType comments don't get PurpleNumbers. I'd like to do this. I'll need to create a save() in MT::Comment and do in it what I've done in MT::Entry. The only issue with that is that it is an all or nothing sort of thing: people leaving comments will be leaving them in PurpleWiki style. That could result in some interesting formatting.    (0000H1)

In somewhat less related news: I also have in the works a text formatting plugin that automatically generates haiku from the text in an entry and sticks it on the end. Queer Barney wants to use it, so I tried it in an earlier posting. It's working but needs to have the better syllable detection method turned on (there are two) and it needs to be packaged. Packaging is always the hardest part for me.    (0000H2)

Posted by cdent at 07:23 AM | Trackback This | | bl

SpaceCGI

I've cleaned up the FrontPage and the rest of the wiki and added some more detailed information on the SpaceCGI tool. Once I get the MovableType issues worked out, I'll provide more info in the wiki about the MovableType PurpleWiki integration. Right now, the most complete information on that can be found in the Movable Type support forum.    (00008X)

Posted by cdent at 08:34 AM | Trackback This | | bl

More purple testing

I'm halfway there to getting the purple number parsing working with MT's new Text Formatting plugins. The display is by plugin, but the creation of the numbers is still in MT::Entry::save() with the double save, as described here:    (00007I)

  http://www.burningchrome.com:8000/~cdent/mt/archives/000034.html#nid00003X    (00007J)

This posting is a test of putting the 2.51 modifications back into 2.62, with some minor adjustments to check the convert_breaks value.    (00007K)

Posted by cdent at 10:11 PM | Trackback This | | bl

NID Sequence Testing

This entry tests writing the purple numbers to an index for later use by a thing I'm planning to call Space. Given a purple number from a single sequence source, find it's original document.    (000044)

Idea is that you use the same sequence/nid generator for all document creation in a domain, no matter what the document creation tool happens to be. In my case I've got this MovableType blog and its associated wiki pulling NIDs from the same generator.    (000045)

Space will take a NID and redirect to the original context, or parse out just the structural element that the NID points to.    (000046)

There's no reason the nid generator has to only work with local tools. It could be a remote service.    (000047)

Didn't work, don't have access to ID. Trying saving twice.    (000048)

Posted by cdent at 12:49 AM | Trackback This | | bl

Wiki and Purple Numbering for Movable Type

Inspired by the Wiki plugin at 0xDECAFBAD I've done the first steps of a dirty integration between PurpleWiki and MovableType.    (00003S)

I had hoped that I would be able to use Movable Type's plugin scheme but in the end I got confused and messed up, so I'm seeking feedback.    (00003T)

PurpleWiki is a modification of UseModWiki to support Collab:PurpleNumbers (the marks that should be on the end of each of the structural units of this entry). The marks identify addressable sections of content for more effective referencing and will eventually help transclusion.    (00003U)

Source for the parser is available at blueoxen.org. Source for the Movable Type changes are swirling around on my disk trying to settle down. Happy to share upon request.    (00003V)

Instead of using the plugins I made changes in MT::Entry::save() and MT::Template::Context::_hdlr_entry_body():    (00003W)

• save() has been modified to take the entry text, parses it to a PurpleWiki::Tree format, adds the purple numbers on nodes without them, serializes the tree as 'wikitext' and saves it. The purple numbers are unique for an established domain. If you look at some of the other PurpleWiki parsed entries in this blog (see the trackbacks) you'll see the numbers are distinct. Eventually it will be possible to have just a domain and a purple number and get stuff via a straightforward retrieval mechanism.    (00003X)
• _hdlr_entry_body() has been modified to, if the text contains purple number tags, to parse the wikitext format back to a PurpleWiki::Tree and from there into wikihtml. This does the formatting and also parses for WikiWords. When I was doing some testing with this portion using a filter plugin I ran into trouble because the test had already had some htmlification done to it before I had a chance to pass it to the parser.    (00003Y)

What I would like to know from anyone who cares to answer: Can I move these functions into plugins, or am I stuck in the bowels of MT? If you don't know the answer but know how to find out, that would be helpful too. Thanks.    (00003Z)

Posted by cdent at 11:33 PM | Trackback This | | bl

wikitesting

This is the PurpleWiki parser presenting pieces of pie.    (000038)

WikiWord    (000039)

Heading    (00003A)

• list 1    (00003B)
• list 2    (00003C)
• list 3    (00003D)

Home Page    (00003E)

Further testing shows MoreMore    (00003H)

Posted by cdent at 07:26 AM | Trackback This | | bl

PurpleWiki databasing

Blue Oxen Associates: PurpleWiki

Made some small headway in the direction of changing PurpleWiki to use a database for storage rather than delimited text files. The default format is freaky to say the least and getting the code changed is something of a nightmare.

Nevermind that this version of the schema will be scrapped when we move to storing nodes instead of pages. But this is good. It is progress.

Posted by cdent at 10:12 AM | Trackback This | | bl