connecting*the*dots

Dave Winer has expanded on his “It’s the users, dummy!” statement and I couldn’t agree with him more:

There’s actually a neater solution, especially if you’ve put a piece of software on the user’s desktop to facilitate uploading and editing of the data — keep a copy of all the data on the user’s desktop, and just mirror it in your web app. There goes the problem (or is it an excuse) that your competitor would be using your CPU cycles to grab a copy of the user’s data (with the user’s permission, I should add, you need a username and password to get access, so the argument that they’re protecting against scrapers and abusers doesn’t hold water).

Following the Beyond Broadcast conference in May, Nate Aune and I began jamming on a similar concept; something we loosely called myTag.

(click for entire .pdf)

The major difference in our approach is that we’re trying to create a “piece of software” (actually, an online service) that can work across all online services, serving as a meta-data hub for all personally tagged information objects — blog posts, photography, video, audio, social bookmarking and possibly service metadata, such as Amazon tagging.

Unlike Dave’s example, we would scrape external services for newly updated, tagged objects. The goal is to centralize people’s meta-data and provide ownership of said meta-data, not to interfere with people interacting with these decentralized services. The scraping would only occur when a person accesses myTag to review their current tag universe, so the impact on external server CPU cycles would be innocuous at best.

Dave’s idea focuses specifically on the data editing and management issues that exist when users attempt to move their data across existing services:

With a local copy, the user can point any service at the data, and it can suck up a copy, and the competitor’s app would run on the user’s desktop too, using their (abundant) CPU cycles. The vendor’s server (in this case Flickr) wouldn’t even know that a copy of the data has been made, and since it’s the user’s data, that’s exactly as it should be.

Yet another reason to use rich clients. I use Flickr Uploadr, always. It’s just a bit easier to work with than the browser-based method of uploading, and that bit of easiness has proven to be worth it. Then of course the competitor has to offer a desktop tool as well. We do it with the OPML Editor. The server components, the directory browser, blog renderer, work with a copy of the data, the originals reside on the user’s machine. It also protects against a system failure, or a company failure.

I completely agree with his ownership point regarding meta-data, and his perspective of safeguarding information objects from system or company failure is extremely valid as well.

So how could we extend his concept of locally managing data (both the information object itself and its meta-data) across same-type services (flickr, zooomr, riya, etc.) to include culling meta-data across different-type services that leverage tagging (del.icio.us, YouTube, flickr, WordPress, etc.)?

See, the reason we’re sketching a thin client is because our primary goal is to enable individuals to be able to review and curate various slices of their own concept terminology — meta-data or tags — as they’ve been applied to information objects over various services and periods of time.

The way I look at it, an aggregate of tags can serve as a looking glass into the personal linguistic structure of each of us, as we make explicit choices when applying specific concept terms to our objects. As competition to flickr and YouTube enters the market, our POV’s will undoubtedly become further dispersed across the web, increasing the findability of our objects, yet conversely affecting our own understanding of our perceived output.

If we’re going to arm citizens with media tools, then we need to provide intuitive, smart representational interfaces for accessing and modeling our own strategic output. Why? Well, we need to be on-point, constantly iterating our understanding of our own perspectives and biases as we venture further into producing our own media.

Otherwise we fall into the same trappings of the mainstream media.

An example… take the limited nature of my tag cloud on this blog as an example. Click on a term, such as Greensboro, and a narrative will unfold over the period of time that you choose to explore and read. While it’s useful to understand more about my relationship with and perspective on Greensboro, the cloud doesn’t include my photos tagged with Greensboro, nor my video clips tagged with Greensboro.

Citizen media operatives need an centralized interface to access decentralized information objects. From my perspective, the value of these interfaces is huge — both to the content creators and potentially to the content consumers.

The first two scenarios I mapped out in the above sketch were for searching and browsing ones existing tag library. Any other primary scenarios jump out at you?