Weblogs: Intelligent Agents

Knowledge-based file systems and content files

Monday, February 24, 2003

Spent a bit of the weekend implementing a virtual file system for my app. Its just a thin layer above the normal file system, but with a few useful additions. Since portability is key to this application I've organised the file structure to reflect it. At the moment all my knowledge base files are under D:/pim/ so the typical default layout is:

So this is effectively one drive with two knowledge bases (default and help). All the dbf files per knowledgebase are stored in the $knowledgebase/data directory, while the $knowledgebase/file contains directories for each topic and the meat of the content. This feels right at the moment, allowing a user to just copy out the knowledgebase directory over to another machine when required.

After the first implementation and a bit of thought it quickly became obvious that the ability to map multiple drives would be useful - especially for replication. What this also allows is knowledgebases used as raw Usenet repositories, or HTML caches to be separate from the core knowledge, so a user could have a large harddrive to store these and leave the Microdrive completely free to hold cleaned or polished information.

At the moment, a canonical way of addressing knowledge bases is by $driveIdentifier.$knowledgebase:, so any article is uniquely referenced by $driveIdentifier.$knowledgebase:$topicName/$articleName . What I thought would be useful is to have a seamless integration between wiki data and the application. So a good starting point would be using raw wiki files as the content storage. These files are essentially text-delimited Perl hashtables, but about three levels deep. The text-delimeter is however two characters, so StringTokenizer objected to that and went a little silly. Looks like I'll have to write my own parser.


[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]