For a very long time it has occurred to me that what I would create isn't always necessarily a series of stories, and a blog is merely a time-ordered series of journal entries. However, many times one simply wishes to write down some simple facts or thoughts that will be referenced in other entries, or perhaps even write lengthier articles, and this doesn't translate well at all to such a format. Indexing via time isn't the most efficient use of the medium for all uses.

This doesn't preclude one major and valid argument, however: time indexing of writing is very useful for many types of content. Thus, it should still be available, just not a requirement to enter and organize all content.

One should be able to index on multiple parameters.

Building on this idea, the wiki is a good model for such a site. After all, a wiki allows for time-ordered changes in nodes (a "recent changes" script that shows all new and edited nodes) as well as versioning of individual nodes (keeping previous revisions of a text so you can track changes in content over time). Information can be organized in that way, but then other metadata could be added to nodes to allow for organization through different parameters than time (categories, locations, moods, etc.).

However, a wiki typically only allows for simple text and inline image content typically, which isn't exactly what I want. I want other types of complex content. Certainly these changes could be done with a wiki's "special pages", or scripts that can be called as wiki nodes to generate special content on the fly. However, that's a kluge; it's not a part of the wiki style, and I wanted to make something more fluid rather than building a hack bolted onto a wiki engine.

The obvious solution that has been practiced up to now is that one should implement node types; a node can be a wiki page, or it can be something else defined by a type that marshals different scripts and data in the node that acts as parameters. For instance, I have a script on my server that allows me to record my blood pressure readings. Perhaps I want a script that generates a graph of my blood pressure and list out the last several readings in a table. This would have to be handled by a very different set of scripts than a standard blog or wiki. Basically, when I create the node, I'd have to attach it to this different nodetype, and that would tell the site what scripts to use to build the output page; I could even embed parameters into the node to tell it to only generate for my username (so Marilynn could have her own node for such a thing), use only the last month's readings, or what have you.

The trick with that is that it's not as flexible as I'd like, still. Suppose I want a node that is a list node, where I keep an ongoing list of to-do items, but at the same time, I want to have some textual information at the head of the output page. Or, maybe I want to have a node that is part biographical information about a person I write about a lot. It would have text like a wiki page attached, plus a picture gallery attached, as well as lists of information, web links, etc. Rather than writing a whole set of node type scripts that support all these things, I'd rather use the base functionality of a wiki page object, a picture gallery object, a list object, a links object, etc. Why reinvent the wheel for each thing that uses these items of information? I should be able to simply put them within another page.

Therefore, rather than a node being an instance of a node type, each node can have certain types of information attached to it, perhaps laid out in the node's base description. I can edit each one independently, and then attach them to the output page, and then arrange the output page, or let it automagically lay itself out and live with that.

The long and the short of this leads to one simple design, that takes me back to where I was to begin with:

• The content of each node in the bliki is a wiki markup page with some objects attached and/or embedded. Oddly enough, this leads back to the "special wiki tag" argument as above, but in all my thinking, I have concluded that this is perhaps the most generic case of this embedding.
• Additional metadata may define relations to other nodes, categorizations or parameters and attributes. Membership, instance, examples and supersedence can be defined, as well as many other relationships to other nodes. Categorization of entries can be done by defining a relationship such as "OfCategory". Publication information, dates, visibility, permissions and the like can be defined as metadata attributes attached to a node.
• Nodes to metadata is a many-to-many relationship. In effect, there is now this kind of structure defined:
• A table holding all the nodes, their wikitext and basic layout.
• A table of metadata that one joins to the table of nodes to find all the relevant metadata.
• A table of objects defined for use.
• For each object type, one or more tables and collection of scripts and data stores to use for those objects. The scripts may be files extending a basic object, to allow for inheritance and an OOP design.

All in all, a simple, elegant design for the bliki. It's not too far off many other wikis in design, and shares a lot more in common with a wiki than a blog. Of course, there will have to be some additions to make it more bloglike, like trackback and pingpack, comments, RSS or Atom feeds and the like. Those will come in time; finally, though, I have a basic structure to work within.

restlessmind