MicroContent Lifecycle

With all the microcontent formats springing up, publishing possibilities, aggregation possibilities, we should start thinking about a MicroContent Lifecycle. Joe Reger has already some thoughts about this, but does not yet formulate it in this way.

I’ll have a go at it:

• Imagine - the first step should be the end-users. He wants to define something new, a new MicroContent type. For this he must imagine what he wants to express. What does he want to record? What should the fields be? A service such as offer by Reger.com to might help users defined new MicroContent types. Such tools will also help to integrate new MicroContent types into existing namespace. Thus one has to build upon the core (a weblog) as Joe Reger says;
• Formalise - the next step is to formalise a new MicroContent types. This might be done by creating a definition file, such as is done by StructuredBlogging in the form of XSD-files;
• Adopt - now that a formal definition exists, any bloghosting system, service or client should be able to use the formal definition to create new MicroLog based on that definition;
• Create - now that the new MicroLog is created the user can start creating items in this MicroLog. MicroContent clients, systems or services should help the user here;
• Publish - the next step is to get the MicroLog published on the computer, local network or Internet. The user does have multiple publication options here:
  • Webpage - the user adds the MicroLog items to his web-page. The webpage might not contain all the Items a user has published and additional pages might be necessary, such as archives. The main purpose of a web-page that is human readible. Here either the Structured Blogging or the MicroFormat solution is used;
  • Feeds - the user adds his MicroLog items to his RSS/Atom feeds. The feed offers a sliding window of the items a user has created. The main purpose of a feed that it is machine readable by a News aggregator (service of client);
  • Repository - a user adds each item to his personal repository. The repository contains each item as a separate instance. The main purpose of a repository is that it contains information that can be used by WebServices or just drag&drop by the user. I think here of the way MacGourmet publishes it’s recipes as separate files. Just by dragging a link on a web-page and dropping it on your recipe library you can add a recipe;

• Use - now that the information is open one can think of using it. There are many ways of using it. Probably the list is endless. Some examples are:

  • Aggregate - service providers aggregate the MicroContent a user publish and offer searching facilities, etc.
  • Reference - one can link to the PermaLink (URI) of a single item for later reference. Or make a reference to a specific MicroContent Item in your own Item. Think of enclosures in RSS-feeds here. Or a link to a FOAF-file of a person you are talking about, etc.
  • Copy - add the published Item to your own MicroContent repository. Great for music, video’s, recipes, etc. But it can also be used to populate your MicroContent item, as is done by any Book management applications, which uses Amazon;
• Update - change the content of a MicroContent item. If all is well, all published variants are updated as well.
• Remove Item - remove the MicroContent item from publication. Most publications will be removed, however any archived or copied version will be living on eternally.

What I describe here are really two life-cycles: one for the MicroContent type and one for the MicroContent item. Guess I should create a drawing and have another go at it. Anyway I will come back to this.

Categories/tags: MicroContent • general ,
microlog; microcontent; microformat; structuredblogging; life-cycle
PermaLink