The PurpleUniverse is a term to cover a suite of services that provide granular addressability and transclusion of content within a domain. At various times these services have been implemented in different ways with different languages and forms. They all share some general concepts described below. In a real implementation it is often easier for some of the conceptual areas to be merged into one tool.

sequence

The source of the numbers (usually called nid) themselves. In early implementations this was implemented as an incremented base 36 number. The numbers are unique across the domain of use. Because of this some consideration was given to using UUIDs but in practice the numbers are spoken, typed and cut and pasted, so this doesn't work out well.

node index

An index that associated a nid with the URL of the document where it can currently be found. This is updated when nid is first given to a document or when a node moves between documents. In most implementations a nid is always associated with the most recent revision of a document, not some moment in the past. This is intentional as it helps to keep dialog moving forward.

There have been experiments with revisioned nids and documents but they have not led to the kind of collaboration that the purple universe is trying to drive.

document container

A web-addressable repository of documents that are included in the domain managed by the sequence. In the past this has been wikis, mailing list archives, semi-static documents and mailing list archives. In theory this can be anything on the web.

processor

A parser or other tool that ensures that a document entering or changing in the document containers is given a nid or nids. The processor gets nids from the sequence, associates urls in the index, and stores the nids with the document so the presenter (below) can display them in the appropriate place.

In some instances this is relatively simple: An IRC bot gets a line of chat, gets a nid, appends it to the line in some fashion, stores it in the log.

In other instances it can be quite complex: a wiki page needs to be parsed for structure, and nids associated with each block item. Those nids then need to be saved with the document. In the past this has been done by putting the nids directly in the document. For people comfortable with inline markup this is no big deal. For others it is a huge deal.

presentor

A suite of services that take documents with embedded or associated nids and shows those nids in a way that ensures they can be used for granular addressability (anchored links) and transclusion (copy the nid somewhere else). How this is done is entirely dependent on the type of document.

transcluder

A service that when presented with a request to transclude a nid can return the content at that node. This is a two step process: the URL associated with the nid is looked up, that URL (and the nid) are used to inspect the document and parse out the relevant content.

A transcluder is usually used either in concert with a presentor (it resolves transclusion markup when creating a representation) or a live tool, such as an IRC bot.

There are various ways to hack some optimizations into these processes. Originally the way to resolve a transclusion was to parse the HTML document created by a presentor. Behind the scenes this meant making a request, parsing the returned DOM, extracting the content. This is useful because it is the most general solution: if a page has purple numbers marked up in the usual way you can extract the associated block of text.

However because the processor controls the parsing of nids and the saving of URLs to the index, it is possible to save a URL which is a service which provides the content pre-extracted. For something like wiki content this can be very useful: it can return the wikitext rather than the HTML.

There are lots of options.