bliki [kb : heavy industries]

kb : heavy industries ??? home -recent -index -about   ???/DIV>
bliki
Trace: ?bliki
Last modified: 2005/07/17 10:21
"Bliki, it‘s a philosophy"
Intro
For the longest time I抳e been looking for that perfect CMS. And by longest I mean about almost a year since when I planned to relaunch my personal site with a whole new format. The first thought that came to mind was a blog. The most obvious choice, because that抯 pretty much what you assume a personal site is these days. However as time went on I realized a blog didn抰 offer all the functions I was really looking for.
My first idea at solving this problem was with my comatose project I calledomniPortal/Taiga. The idea was early. To create some sort of homepage software which had a scope much large than I anticipated. Taiga died pretty quickly. However at that same time I began a phase of testing with various blogging software includingTextpattern,Blogger,Wordpress,MoveableType, and the super minimalWhisper. I still came out short.
Around December I replaced the though of using log software with wiki software. My first choice was phpwiki which I抎 say is sloppy, and bloated. The next choice in wiki was DokuWiki which I抳e had a hell of a fun time playing with. DokuWiki itself is your typical wiki, but in a more simple context. Again, I came out just a little short.1)
After playing with DokuWiki for a while (submitting some bugs andhacks along the way) I came across theblog of Rui Carmo. Though not really a blog, I抣l leave it at that for now. Here we had a blog, but with something different, nodes. Not only was there the sequenced, linear, blog postings, but sprinkled in every post was internal links to a node system. Yes, a blog with a wiki, or as the official term would seem to be, abliki. A bliki is a true mashing of each of the finer points of blogs and wikis.
Integrating Blogs and Wikis -- A Higher Unifying Framework2)
揟he more I think about it, the clearer it is to me that Blogs and Wikis are really instances of the same meta-level idea. They should be unified into a single system. Blogs organize information temporally along a single thread. Wikis organize information spatially around a set of nodes representing ideas. Blogs have no concept of space. Wikis have no concept of time. What we really need is a single framework that enables information to be organized freely in space and time.?
A bliki should be able to aggregate new content ala blog style, but at the same time be able to self reference itself and other nodes. In this vein, you no longer are posting, but in a more wiki sense, noding. Your website goes from linear (assuming you抮e blogging) to a more natural system of interconnected nodes. Or your wiki will now have a sense of time, a linear connection of nodes.
From here, this idea has not only been explored (though a formal concept is still infantile at best) but it has been implmented quite a few times, dating back to1999.
My Implementation
So why all of a sudden this zeal for blikis? Simple, I didn抰 even know of a bliki until I found a link on the DokuWiki website of someone who justhacked together Wordpress and DokuWiki. It was obvious this guy had the same idea of merging blogs and wikis. Little did I know the bliki has been around for years now, yet it抯 obvious the bliki concept is still pretty new and fresh
This is where I share my ideas on blikis. First and foremost I think wiki to bliki is the more obvious choice. Blog to bliki seems less logical as the change would be more radical. Wikis already have most of the blog features, postings, archives, edits, etc. At the most basic level, you can turn a wiki into a blog by aggregating a collection of wiki articles sorted by edit date. Using either a 揵log?category or 揵log:?namespace would be easiest.
Bliki Conventions
Blog Linking
Linking to blog postings should be simple. Take this example link to a posting fromRui.
http://the.taoofmac.com/space/blog/2005-03-01
It抯 close but I抎 prefer
http://the.taoofmac.com/space/blog/2005/03/01
Where the exclusion of day, or month for example would generate monthly/yearly archives. I think there could even be further classification. Say there was a post titled 揙ut of Breath? the link would be
http://mysite.com/blog/2005/03/01/OutofBreath
This is along the lines of typical Blogger archive links, but unlike blogger, OutofBreath now becomes a wiki node. So we have both a blog link, and a wiki link to the same information.
Of course, this could cause trouble if you post something called ?ACRONYM title="Rich Site Summary">RSS?but want to maintain a seperate RSS node. A simple way to work around this would be to put post references in similar titled nodes. So the RSS node?
mysite.com/RSS
厀ould have a link to you blog post ?ACRONYM title="Rich Site Summary">RSS?
mysite.com/2005/03/01/RSS
Section Posting
So what is another way to bring nodes and posts together, how about section posting? Think of it like this, on the wiki side of things you have a dynamically updated article at will. Over on the blog side, there are posts that are edited once and move down into the archives. Section editing is a nice way to combine both of these. As the title implies, a section post is a blog [er, bliki] post that is added to a wiki node at the same time.
This enables your wiki nodes to be a mixture of aggregated blog posts and old school wiki edited text. The key to this is to make all of this look transparent. So if a node consists of some bliki postings, it shouldn抰 look like a miniblog on your website. All the normal blogging features, pings, trackbacks, comments, will be available just not in this wiki view.
For example, a section title would like like
Out of Reach (from blog/05/03/01) Out of Reach (from OutofReach)
or you can be even simplier and the software will turn section titles based on section postings into links to the actual post.
This makes sections somewhat more dynamic. Section edits might need to be recorded now instead of just saving a section edit as a whole page edit like most wiki software does. Another little tidbit that could be helpful is if the table of contents reflects edit dates:
Table of Contents Intro [05-3-34] What [05-3-02] When [05-5-23]
Though section edit dates, could be considered more of a general wiki issue.
Based On
Section posting is a good idea on paper, but what happens when you have a section on some node that you need to edit. Well from the wiki end a section edit might also edit the blog post. After a while the blog post could become something totally different.
Now the 1-1, section edit to blog post edit could work, but what if in that old blogging sense you don抰 want to wikify blog posts. Thats where the 揃ased On?concept comes in. When a section is edited that was orignally a blog based section post, the link to the original blog post will remain but on a 揃ased On?basis. So even say after a hundred edits, the section will still reference the original section posting. This basis could be represented by simply keeping the link, or making a 揃ased On?link a different color than a section posting link.
Information Architecture
Placeholder
Bliki Links
Bliki ?Wikipedia on blikis, with some more links.wiremine ?by Brian Tol. Great example of a bliki, though it抯 still a work in progress at best. Powered by his custom bliki softwareIdeaGlue (formerly cardboard), he抯 got some great stuff onBlikis. As well as just good content all around.A New Wiki/Bliki Movement Afoot? ?prespective on blikis and overall bad design of wikis.Of weblogs and wikis ?A case for blikis.A Bliki made of WordPress and DokuWiki ?HackedWordPress and DokuWiki together. A very early work in progress.
1) Credit to DokuWiki deserved as it is the most fun package I抳e found so far. I use fun because not only was it easy to setup, it抯 small, and very hackable, and just plain fun to use. And obviously I抦 writting this in it.
2)via wiremine
show source |show revisions
login