Glacial Erratics

Purple response

May 10, 2005

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

In practice, are purple numbers stable enough to be useful? Or are there certain cases where they are more useful than others? ps    (PKO)

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)

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)    (PLB)

Better would be something like one of these:    (PLD) {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 better
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)


On May 10, 2005 03:23 PM phil jones said:

Good posting. I agree on the granularity thing and disagree on the "labels posing (miserably) as identifiers." thing.    (PLP)

Full response on my blog here :    (PLQ)

On May 10, 2005 06:24 PM Bill Seitz said:

Some incoherent points on Phil's area of concern...    (PLR)    (PLS)