My Plans for Purple Numbers
May 30, 2004
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)
Comments
Looking at NodaryPublic, several thoughts occur. (844)
Leo is an example of a data organization tool which permits you to place a node under multiple parents. Have you played with it? Although ostensibly for a form of literate programming, has wider application and it might stimulate some ideas. I see James Tauber has lately been fooling around with it to develop some PIM notions. (845)
Larry and Sergey's original intention with Page Rank was to "annotate the web." I wonder if Google might be able to provide some of the functionality of NodaryPublic by overlaying annotation on their indexed web. I'm thinking of something like Marc-Andre Lemberg's Tagging Engine from mxTextTools?. (846)
Thanks for the pointer to Leo. I hadn't heard of it before, looks like it has some interesting ideas. (84F)
And the Tagging Engine; lots to farm there. (84G)
There's so much going on, how does anybody keep up? (84H)
Yep, sounds like Ted Nelson. You might want to check out Simon St. Laurent's presentation: "How Embedded Markup Can Learn From its Detractors"[1] (84Y)
Simon says: "Just to explore whether markup was capable of supporting the kinds of things Nelson wanted to do, I wrote a set of processors which separate the content from the markup in one phase, and which recombine the content and the markup in another phase. Maintaining the relationships between markup and content is much more difficult when they are separated because of the obvious problem of maintaining correct connections if the content changes." (84Z)
Ground you've covered? Likely. But might have something you've not considered. (850)
[1]http://www.idealliance.org/papers/xml02/slides/stlaurent/index.html (851)
I don't think paragraphs can be context free, they must have an initial context which create them (adds to the pool) and that context should be marked different than the other transclusions. (85T)
What I ment to say above (85T) is that a paragraph in a document may have different meaning in different contexts, and the original/initial context should be flagged. (85U)
That's why the T link in PurpleWiki TransClusion is for, to access the context of the transcluded content in order to gain the full meaning of it. (85V)
I believe this should be addressed in NodaryPublic. (85W)
Also in PurpleWiki it would be cool to flag in the `original document' that a fragment is transcluded, and where it is transcluded, kind of a trackback mechanism. (85X)
That's why the T link in PurpleWiki TransClusion is for, to access the context of the transcluded content in order to gain the full meaning of it. T (86T)
This is exactly right. When we first put TransClusion in PurpleWiki we knew this was necessary and didn't much care for the T (it's sort of ugly) but decided it was necessary: context is everything. (86U)
Also in PurpleWiki it would be cool to flag in the `original document' that a fragment is transcluded, and where it is transcluded, kind of a trackback mechanism. T (86V)
If I mange to make NodaryPublic work as I want, it will make providing a referrer or trackback mechanism considerably more easy as it will allow chunks of content to be accessible by a clean URL, without using an #anchor. The URL seen by the web server when retrieving content will include the PurpleNumber. (86W)