Know Idea

A half baked can of worms.

Friday, March 01, 2002

Metadata consumer/producer

Context

Content Management Systems (CMS) now proliferate. It is now common for content providers to have software that manages and categorises their content assets. Metadata standards now exist (RDF, XTM, RSS). Influential thinkers, such as Tim Berners Lee, have popularised the concept of the semantic web. Standards Organisations (ISO, W3C) have put effort into defining exchange syntax. The groundswell is rising slowly.

Problem

The problem is that there are few entry-level metadata consumers that can take metadata feeds, aggregate and (re) publish them. There are a lot of channels talking but not that many listening. The human agent is still doing the filtering. TBL vision of the semantic web is still a long way off. We need some smarter agents doing the work for us.

Solution

The solution is to do something practical about it and to do it in a way that will spread around the web. The solution is one cross platform metadata consumer and several platform specific metadata producers. The consumer can take registered feeds and publish aggregated and filtered channels. The producers are modules that sit on top of established CMS systems.
The use of public subjects (PSIs) such as those found in DMOZ can be used to merge channels from different sources. This is the different proposition with this system – sources can be merged. This relies on content producers marking up their content correctly.

Inspiration

I have been interested in CMS systems for quite a while. I was thinking rolling a generic version of my own from code cobbled together from various projects. The main feature of my CSS would be that it supported standard Dublin Core (DC) metadata attributes and that it could output RSS and Topic Maps. I quickly realised that this would be wasted effort because there were so many CMSs out there and that it would be better to concentrate on the interoperability aspects (metadata exchange). This lead to the realisation that a number of Metadata Producers could be written on top of existing CMS packages. The corollary was that the core of the system needed to be a cross platform metadata consumer.

Implementation

Most of the hard work has been done by the open source movement. There is an open source topic map engine, TM4J, which could be used to drive the topic map aspects of the application. The most difficult aspect is merging and an engine such as this one would save a lot of work.

http://www.tm4j.org/

The basic application would allow users to log on and customise their channels and how they would want them served. For example, UserX wants channel x,y,z and wants it delivered to their inbox every morning. Admins would also be able to go on and register new metadata sources and define merging rules. This is the real value add of the system.

The system could support a very basic metadata management system that allowed users to blog and to maintain CMS. Users could define their own subject areas and blog till their heart is content. They could then share their ideas. Users could be encouraged to reuse DMOZ PSIs.

Strengths and Weaknesses

There are a lot of nerds out there working hard on content. They belong to big companies with a lot of programming resources. However, we must remember that it is often the simple things that work on the web, e.g. HTML, RSS. Simple concepts tend to take off as well, e.g. Blogging. The right balance needs to be struck.

Business Model

The metadata consumer is the smart end of the system and we need to be able to get people to pay for the use of it. The users, those using the channels, will not pay. They can just use Google or some other source. However, content providers wanting to integrate their content might pay. E.g. those with a “topic brain” (associated subjects) publishing time sensitive resources. Content providers just get screwed from every angle, don’t they?

It might also be possible to do consulting work for the CMS providers to write the modules to output the metadata. Ie. Topic Map output routines which could dump XTM at a file location.

Outcome

I am yet to do any work on this project. Topic Map engine vendors have been stretched to come up with their basic engines. It is up to the next generation of developers to start building applications with these engines.

Tags



0 Comments:

Post a Comment

<< Home