FOAF approach to Microcontent creation

As already noted several times, it is impossible to define all the types of Microcontent beforehand. There are to many imaginable: weblogs, reviews, playlists, resumes, etc., etc. Each piece of Microcontent has however something in common. A Microcontent piece basically consists of a list of fields. More advanced forms of Microcontent can have lists of fields within a field. It reminds a bit of what one can do with Outliner software. What is (often) lacking in this outliner software is the possibility to define the meaning of each field. This can be done by adding a keyword to each field and remembering what is meant by it (within NoteTaker one can do this). A piece of Microcontent is a hierarchical structure of fields with each field a keyword-value pair (think XML).

Within outliner software these keywords have only a meaning for the person that created it. A next step would be the standardisation of these keywords. In a standard such as RSS these keywords have been defined for BlogEntry MicroContent. And each piece has fields such as a title, a link, a description, a subject, a creator and creation_data. And the meaning of these fields has been well defined. And there are more standards for keywords out there (FOAF, Atom, ...).

But why only these fields? What if I a want to add an image? Or a rating? Or a person? Or a link? Or ...?  One could embed such information as HTML in a description field, but this not very satisfacory. One would like to add an extra field to a blog entry. This extra field should have a clear meaning. When a blog entry describes a location, just add a location field (which consist of two subfields: longitude and latitude). Is a blog entry about a person? Add a (FOAF-)link to his FOAF-file (think op the in FOAF). Is a blog entry a review? Add a link the article reviewed, or a link to the identifier of the book (ISBN-number). The possibilities are endless. What I describe here is a very free way to extend the basic weblog_fields-template. A user can do as he likes. There shouldn’t anything be forced upon him. But if he wants to conform to common practice, there must be ways to do this.

Now how would this work in practice? In the first place web-log services should be able to support structured content, i.e. an Microcontent item should consist of multiple fields and subfields. And this might vary with each blog-entry. Nothing is known of the structure of the entry beforehand. The meaning and structure can be known through keyword/value pairs.

When a user creates a new weblog-entry, he first choses the type of Microcontent he intends to write, i.e. select OpenReview, OpenResume, etc. This is a kind of template with the appropriate standard fields. As needed the user can add fields to the entry from a list of available standardised fields. Thus if you want to add a location to a review in order to describe where you read the book, pick the location field from the list. But the user is also free to add free-format fields.

The standard Microcontent types (templates) and fields reside somewhere in machine readable format in a central repository. Weblog-creators and -applications can retrieve the latest fields and types from this repository. One might compare this to the FOAF website, but with a machine readable interface to be used in clients. And there must be a mechanism by which new fields and types can be entered in the repository.

Categories/tags: general
PermaLink • Comments • TrackBacks