I started this essay last week on the train between Bath and Oxford, but then got side-tracked with writing up my XTech 2005 submissions and fighting off a nasty stomach bug before finishing it.
Poking into my aggregator this morning I was interested to see this exchange between Bill de hÓra and Danny Ayers. Bill seems to have having similar thoughts about the humble list:
The thing about lists is that they have a lot of untapped value. I believe a lot of information gets left behind when all you have to work with are <ol>, <ul> and <li>. In terms of moving up the semantic and social software food chain, lists + metadata are a natural next step. Arguably an Amazon wishlist or a list of people on LinkedIn have more value if they're decoupled from the sites themselves. Passing them around and sharing them might be cool.
Which echoes some of my points below. Any read on for ramblings about the list pattern, bookmark management, and thoughts on how applying simple conventions to list structures can help bootstrap some interesting applications.
I've been obsessed by lists lately.
This may have been triggered in part by the impending return to work after an extended Christmas holiday. Or maybe it was the endless "List Programmes" on the telly: Top Ten This, Best Ever That, The People's Choice of the Other. It's probably largely due to some early spring cleaning and re-organization of my bookmarks and blog subscriptions that I'vebeen undertaking. And being abstraction prone(*) I can only look at sequences of URLs and lists of subscriptions for so long without musing on the underlying patterns.
Lists are all around us, and they're typed either by their context or convention.
A list of placenames and times on one screen at the train station describes arrivals, next to it resides the departure list; A printed series of food items and prices in a restaurant is a menu, at the checkout it's a receipt; my aggregator presents me with a list of reading material; my IDE, a change history; the "Edit" menu a list of text manipulation functionality; and so on ad infinitum.
Whether or not we're neurologically well adapted to list processing is irrelevant: culturally we've certainly embraced the basic "titled list/list-item" pattern for organizing many kinds of information, and so there's a positive feedback loop in place that encourages the publication of new information in a similar form.
It's this positive feedback, and the simplicity of the abstraction that's at least partly behind the success of RSS. In fact at the syntactic level, the list/list-item pattern is an architectural form that's present in many different vocabularies: RSS, OPML (nested lists), HTML (ordered and unordered lists), to name but a few. The RDF Sequence and Bag collection types merely represent this pattern at a higher level of abstraction. The excellent list processing features of Python allow these abstractions to be manipulated with ease.
The most flexible way to maintain a list of URLs on the web is to use del.icio.us. Ease of use, maintenance, and a uncluttered (if sparse) interface are all important factors that contribute towards its success. The RSS views and API are other essential ingredients.
The easiest (as opposed to most flexible) way to maintain a simple list is actually a Wiki page. IMO, del.icio.us has the edge over a Wiki environment for maintaining lists of URLs because of the tailored pop-up interface presented by its bookmarklets, but also because it automatically timestamps each items when added. The extra metadata is important.
Because list maintenance is so easy with del.icio.us I've extended my use of it's tagging function beyond simply classifying web pages, I've begun to use it to organize other pieces of information: articles I want to read later, articles I've written, a list of services that I'm registered with, and a list of the data exports. I've organized these under a "Me" tag, with separate Me/ToRead, Me/Articles and Me/Data sub-categories.
del.icio.us automatically provides me with RSS feeds of this data so I can include them into several different kinds of application. My publications can be attached to my CV, my data automatically harvested (e.g. via a Scutter), and my reading list and service homepages added directly to my Firefox personal toolbar as Live Bookmarks.
To digress slightly, it's this last facility that has finally allowed me to nail my ongoing difficulties with bookmark management. I've always used bookmarks in two ways: as a list of items to come back to for later reading, and a list of items for future reference. The differences are subtle: in the first instance I simply need a list, in the latter I need some level of classification to make the reference material easy to find at a later date. Using del.icio.us I can not only "bless" one tag as my ToRead list, but I can also easily access that list from any location, and still classify the items for later reference by assigning them multiple tags. Difficult to manage with a plain browser bookmarking facility.
This is where we loop back into the list typing -- by context or convention -- that I mentioned earlier. My "Me" tags are a convention that I've adopted for my own benefit. But it doesn't have to stop there. Michael Lenczner recently suggested using a "commentlog" tag to record one's blog mostings (read more). I'd been toying with a similar idea, adding a Me/MailingList/XML-DEV type tag structure to record my mailing list and ultimately news group postings, so it's interesting to see others also exploring this avenue. I've always felt that keeping track of one's correspondence is important.
Without much effort it's easy to think of other "well-known" tags that a user (and by extension a community) could adopt to make it easier to manage certain kinds of information and facilitate a number of interesting applications. Or indeed how some social content applications could be simply expressed as lists of URLs in del.icio.us.
The following table contains the results of a quick brain-storming session, listing some suggested del.icio.us tags, what they might contain, and the functionality they could provide to the end user and at an "aggregate" level, i.e. analysing across the del.icio.us community:
| Tag | Convention | User Function | Aggregate Function |
|---|---|---|---|
| Friends | List of blogs run by friends | Simple to transform into FOAF, and arguable even easier to maintain and include in a blog than XFN | Simple social network analysis |
| Subscriptions | List of RSS Feeds | Simple to transform into OPML or an RDF Blogroll for importing into an aggregator; allows easy migration between aggregators | Subscription and network analysis; e.g. how many subscriptions to a particular blog? Whats the history of subscription numbers? |
| WishList | List of product links | Cross-vendor "wish list" or gift suggestions | Product popularity, broken down by community |
| Gigs | List of links to gigs or events one has attended or is attending | Record gigs and/or events one has attended, including short reviews | Where are your friends going? Where have they been? |
| Location | List of links to URL indentifying geo location. Could be created by automatically logging GPS co-ordinates at regular intervals. del.icio.us will automatically add timestamps | Real-world annotations | Community travel, geolocation |
One interesting property of these kind of tags is that they're easy to locate automatically, because they use "well-known" names. This is especially true when you have a mechanism that can associate your FOAF self-description to your del.icio.us account. (Aside: There are some other possibilities in that space too).
Many of the above examples would perhaps be better served by tailored interfaces that would collect and publish additional properties over and above the basic URL+title+comment+timestamp structure that del.icio.us uses. But I believe there are several advantages in using del.icio.us, in however limited a form, when exploring these kinds of application:
However for really serious use I believe we need something more: a service like
del.icio.us that allows storage of arbitrary properties against web resources. And it seems obvious to me that such a system would be based around an RDF data store. Jo Walsh has already created an RDF version of the del.icio.us API, and this tutorial on creating a social content engine in RDF provides some additional thoughts.
I wouldn't necessarily go so far as to argue that the interface or API itself needs to be be RDF-only, just that RDF provides the desirable level of flexibility upon which such a service can be constructed.
As an open source application, this social content engine could be used to build any number of applications, but its real power, like del.icio.us would being provided as an open web service: one that could be used by other tailored services as a basic metadata storage engine.
It seems obvious to me that there's going to be a real need for this kind of service; it seems to be a natural evolution of online hosting arrangements, rather than just empty disk space or a huge inbox, I get a structured metadata store into which I can drop my content, and to which I can grant varied degrees of access for various services. See Dare Obasanjo's essay "Social Software is the Platform of the Future" for more in this space.
(*) being "abstraction prone" is similar to being accident prone, except instead of falling down, you tend to be drawn upwards.
Posted by ldodds at January 10, 2005 10:41 AM | Feedback? | | TrackBack