The Future of Purple: Distributed Transclusions

One of my main interests is collaborative tool interoperability. In that vein, I’ve participated in many conversations, but I’ve been actively involved in two initiatives: Purple Numbers and Identity Commons. On the surface, these two technologies solve different problems, but when you dig a bit deeper, you can actually combine the two to do some very interesting things.    (1N1)

Purple Numbers enable granular addressability, which enables you to attach metadata to finer-grained chunks of data. Instead of having an author of a document, you have authors for each paragraph of a document. This is an especially useful concept for collaborative authoring tools, such as Wikis (hence PurpleWiki).    (1N2)

If you can address granular chunks of data, you can also transclude them. This is generally more useful than transcluding an entire document. (You are more likely to want to quote a sentence from a paper than the entire paper.) So, one consequence of tools that support Purple Numbers is that they also support granular transclusions.    (1N3)

One of the limitations of Purple Numbers as currently implemented is that addresses are only unique in a local context. What we really want are globally unique, persistent Purple Numbers. That would allow me to transclude a paragraph from another blog into this one. If that paragraph moves, the transclusion should still work.    (1N4)

Guess what. XRIs are globally unique, persistent addresses. In fact, they were specifically designed to address data. (See the excellent whitepaper, “The Dataweb: An Introduction to XDI” for more on this.) In other words, we can use XRIs for Purple Numbers.    (1N5)

Even better, Identity Commons is developing schemas for link contracts that allow you to attach permissions with your data. While Identity Commons will use these link contracts for protecting profile data, they could certainly be used for other things as well, such as protecting purpled data.    (1N6)

Suppose Alice writes a paper, and she only wants Bob and Carl to see it. She could attach permissions to the entire paper that says as much. Now Bob wants to write a paper, and he wants to quote a paragraph from Alice’s paper via a transclusion. However, he also wants to make his paper available to the public. So, he transcludes Alice’s paragraph and makes his paper publically available. When most people view the paper, they’ll see everything except for Alice’s paragraph because the link contract associated with that paragraph denies them permission. However, when Bob or Carl view the paper, they see everything, including Alice’s paragraph, because they have permission to view that.    (1N7)

More thinking needs to be done. This originally started as a fancy, but a conversation with Gabe Wachob over IRC a few months helped convince me that using XRIs for Purple Numbers was not only possible, but a good application. Two issues are:    (1N8)

  • What should the Purple Numbers look like? It’s the age-old question. XRI e-numbers are definitely not pleasing to the eye.    (1N9)
  • What should the numbers do when you click on them? The way it works right now is that the addresses are named anchors. But this won’t work out-of-the-box with XRIs, because most XRIs are not valid XML IDs.    (1NA)

Chris Dent has mentioned handles on several occasions as another direction we could go. We need to examine this possibility as well.    (1NB)

4 replies to “The Future of Purple: Distributed Transclusions”

  1. First Question:

    I’m not sure “e-number” (an XDI term, not an official XRI term) are neccesarily the right syntax to use for Purple Numbers — you could argue either way that Purple Numbers are a type of “persistent identifier” in the sense that XRI means them. There’s no reason you couldn’t use a more convenient syntax for purple numbers that doesn’t use the “persistent identifier” syntax in XRI.

    Second Question:
    I don’t know what they should do, but perhaps they should resolve to HTTP URLs which *can* have named anchors. That would be my “first cut” at the problem…

    As for handle – I think you’ll see there are some issues with the way the handle hierarchy is managed – you’ll have to decide if its workable for you. Of course, if you are going to use a XRI GCS, there’s some namespace issues as well, especially in the short term….

    Where’s the wiki page on this topic going to be?? 😉

  2. I totally understand where Mark Baker is coming from.

    Having a plan to get XRI support into Firefox/Mozilla and IE initially sounds interesting, though it seems to me that there’s a bunch of questions to answer first about what that would mean, functionally.

    I actually would like to see browser support for XRIs as an early-on community-based project. If nothing else, perhaps just having XRIs resolve into RDDL documents…

Leave a Reply