August 08, 2005

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)

Each paragraph, each item in a list, might thus have it's own permalink. The only purpose that I can think of, is when you want to quote some text from someone else. But the question is whether the quoter and quotee have the same idea of quotable pieces. I doubt that.    (PUB)

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) | Technorati cosmos | bl | Categories: purple

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) | Technorati cosmos | bl | Categories: purple

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) | Technorati cosmos | bl | Categories: purple

Dimensions in Group Communication Media

Anyone who has ever used a combination of email, phone, meetings and other media to communicate in a small group has experienced at least one moment where they've thought, "this would be going much better if we were having this conversation using X".    (PTD)

While the choice of X is often driven by personal preference and comfort levels (as someone who spent a few years being a sysadmin, my X is email), I believe there are several scales along which the various media can be measured. The resulting values (which are very much dependent on the context of the medium's use) can be used to choose a medium depending on the goals of the group or the individual initiating the conversation.    (PTE)

The three scales that are usually most relevant for me (I'm primarily concerned with enabling action and reflection) are:    (PTF)

Degree of Synchrony    (PTG)
Does the medium provide for synchronous or asynchronous responses. This depends not so much on the quickness with which a participant responds but rather whether the communication to which a response will eventually be made is stored for review. On the phone you can wait for a long time to make a response, but eventually you may forget what the other person said. This isn't the case with email.    (PTH)
Desired result of communication    (PTI)
Action versus Reflection. Should the participants be inspired to perform some action or to continue thinking at the end of the conversation? How does the medium encourage one or the other?    (PTJ)
Degree of Ambiguity    (PTK)
How clearly does the medium transmit already clear concepts? How effectively does it indicate there is doubt? What degree of doubt or noise does the medium inject into the conversational space?    (PTL)

These scales can be used to make three axes defining a three dimensional space. Each medium fits somewhere in the space. Each scale impacts the others.    (PTM)

  • synchronous ... asynchronous    (PTN)
  • action ... reflection    (PTO)
  • ambiguity ... clarity    (PTP)

Neither end of any scale is bad. Each is good in some ways: effectively expressing doubt is a way of showing that there is room for reflection or a need for more information. However, using a medium that introduces or enhances ambiguity in a setting where quick action is required is a bad idea.    (PTQ)

Wikis, Weblogs and Email are all asynchronous media (the content is stored for later use) but they work more effectively in different areas. Email, because it is pushed to the reader, is often more effective at causing action. RSS feeds from wikis and weblogs could inspire action, but thus far there is not much of a tradition of use along these lines. They are more effective at reflection, especially wikis, which allow in place refactoring of content.    (PTR)

IRC, phone calls and face to face meetings are synchronous. IRC can introduce a great deal of noise where processes of use have not emerged. It can be a place for causing action, but leadership is required. It is often good for dipping into a shared pool of understanding for a bit of reflection. An unexpected phone call can inspire action while a pre-arranged conference call or face to face meeting is only effective with the help of processes and structures that facilitate the use and construction of information artifacts that will live on after the call.    (PTS)

Where would you map the various media? What dimension matters most to you? Someone could make a graph.    (PTT)

Posted by cdent at 02:39 AM | Trackback This | Comments (1) | TrackBack (0) | Technorati cosmos | bl | Categories: collaboration

Home from OSCON 2005

Last week I was at OSCON 2005. It was interesting, but not quite as fun nor personally relevant as YAPC 2005 (my other conference for the summer). At YAPC there was a great deal of participation. At OSCON it was more about observation.    (PT4)

Despite the lack of ripping yarns to relate, it's clear there are some things afoot:    (PT5)

  • There's more money floating around than there has been in some time. Companies are hiring again, especially Google, and they think that people with open source experience are worth a look.    (PT6)
  • Related: companies are interested in following an open source model for pursuing revenue.    (PT7)
  • The latest developments on the linux desktop (wiggly windows!) are suhweet. Miguel de Icaza did a fine job of making me feel guilty for joining the soulless legions that left Linux for OSX.    (PT8)

My favorite parts:    (PT9)

  • Paul Grahams's keynote, since turned into an essay, had some nice (in the nice because they are damning sense) things to say about professionalism and work.    (PTA)
  • why the lucky stiff gave an awesome presentation, ostensibly about Ruby. It was a multimedia extravaganza of elegant insanity that pushed me past the few remaining barriers preventing Ruby code in my life, despite having very little in the way of traditional pedagogical method. I've started working on something called rubead that I'll post about in a while.    (PTB)
  • Seeing Matthew, Joe, Kevin and Brett and finally meeting and chatting with Kragen.    (PTC)
Posted by cdent at 01:53 AM | Trackback This | Comments (0) | TrackBack (0) | Technorati cosmos | bl | Categories: