My first flirt with Topic maps started about 5 years ago, and I wanted to share a little bit about my journey from Web user interface developer (which I was at that perticular point in time, although before that I've been everything from CTO, C hacker, movie-maker, musician, poet and driftwood through the rivers of gloom) to whatever I am today, especially in regards to Topic maps.

First of all, Topic maps re-introduced me to epistomology, being the buzz-word within the knowledge management scene in which I was working. (another rant for another day is how 'knowledge management' is a false meme) With Topic Maps I could take an important step away from buzz and towards the actual meaning of the word; how do we know?

In my past I spent over 7 years in the security industry creating real-time video motion analysis tools with Artificial Intelligence and other methods, pondering about how we can make computers look at things a little bit more like a human. The key to these systems were to make them very analytical for processing, but rather fuzzy in their conclusions, a trait which today is recognised as good human values. But to make computers think like humans - being binary entities and all - this will never happen, at least not within that limited framework, but we surely can use them to fake and simulate some human traits.

So. How can we make the computer a little less machine, and a little more human? We introduce ontology. Yes, it's a buzz-word, but it is one of those that have come and gone through the ages. I remember it being there 15 years ago, and it is highly buzzwordly these days, perhaps even more now than ever. So what is it?

Ontology is a bunch of human words for whatever we want to work with. If we're in the lolly-business, words would be 'sugar', 'color', 'mixing', 'process', 'sales', 'consumation', and 'profit'. If we're in the mafia, words could be 'cousin', 'protection', 'gun', 'mama', 'godfather', and 'profit'. And so on. Often - but not always - within the concept of an ontology sits relationships between these words. And ontology is a set of words or even phrases that describe your area of interest. The bigger the interest, the bigger the ontology. (This growing ontology is also a problem in itself, and can often render your whole ontology useless, but that's a rant for yet another day. Hmm, someone should ask me to write a book.)

Because ontologies are "more human" in their approach to labeling things we do in the realm of computers, it is often thought that we're a step closer to making computers more usable. At least, that is what I thought. It is why Topic maps was so tempting for me to venture into. I did not only venture into it, but swallowed it and immersed myself in it.

What good does that do?

After drinking the Topic maps Kool-aid and devised my own Topic Maps tool, I wanted to use it more and more. Perhaps it was for getting more experience with it, to test its basis, to see if it really was as good as I thought. But sadly, finding projects that involves Topic maps has proven to be a bit of a challenge, and along the way I got entangled with just plain vanilla life, apart from the rare opportunity here and there. I've written a few articles about it, and I've held seminars and presentations, and use the core model of Topic maps in pretty much everything I do. And this last point is an important one!

Being exposed to ontologies, where words have relationships, and these relationships are important and have meaning, made me see things in a new light. As in epistomology, how do we know that the word 'fish' means those 'swimming' things in the 'sea'? How do we know what 'swims in' really mean? For example, when we swim in the sea we do it rather differently from when we swim in money, yet it's the same words that shape the relationships.

The meaning of the semantics of our relationships between things have huge impact on how we percieve things. For example, in a content management system you can have one blob of information that 'belongs to' another piece of blob, but is that true for all blobs? We give blobs names or types, as in 'this blob is a policy document', but will all policy documents fit into the type of whatever blob you originally thought your one policy document would fit into?

All this context and all these relationships and concepts and notions, they're a big part of how we percieve things. And how we percieve things is the key to how we further can make computers (and other tools as well) seem more human and friendly and helpful to us. The presentation and handling of information goes hand in hand, and in the past they've been two very different things. The ontology-based systems try at least to shorten the gap between them.

Conclusions

Working with Topic maps has made me think about the meaning of what my solutions present. And the meaning of what I present digs deep into the world of usability, and hence is the amalgam that saturates my work, and often my life. The psychology of human cognition has more to say about software development than any book about computer languages, methodologies, techniques or logic.

Unfortunately I've seen a lot of people getting excited about Topic maps, and then see the flame of promoting the standard slowly die out. The good news is that the spirit of it still remains. Perhaps its a weakness of Topic maps itself that it teaches you more about the surrounding thinking and practices than of the technicalities of the standard itself. Maybe, but I owe it a lot of thanks.

It is interesting for me to think back on my years of Topic maps experience, because it strike me that my main interest in it isn't the technical side of things but the philosophical side. And I guess that fits in well with my personal opinion on the Topic maps standard per se that it can be quite difficult to grasp for most people; you got to overcome the new ways of thinking about relationships first (quite a huge hurdle in itself!), you need to surpass the difference between a data-model, a mental model, the ontology and a technical specification (they are all different abstraction of the idea of "Topic Maps"), and you've got to have simple to use tools to see it in action (and none of them are currently simple, not even my own stuff. The closest I can think of is Ceryle ). All this is not easily done in an afternoon. In fact, as I recall, it took me months and months to get to a confident level with the whole shebang, perhaps even a couple of years! And now, after 5 years, I'm not willing to even remotely call myself an expert in it (even if others foolishly might do so :) ).

Having said all that, I'm still doing lots Topic maps stuff, albeit not with XTM (the Topic Maps XML interchange format), and I'll let you all see it in action in a few weeks time. Exciting times abreast.

The Semantic Web is one of these things that a lot of poeple want to see happen. The W3C concucted / embraced / created / hacked it together, releasing it as the solution to all our information integration and sharing problems. But perhaps prematurely.

I am myself very much interested in all these things, and I was the technical editor of 'The explorers guide to the semantic web' by Thomas Passin. I eat Topic maps for breakfast and have RDF for lunch, fiddle with and explore semantic data modelling all the time. I breathe XML formats, I devour notaion languages, suck in microformats and I live for the intrisic semantic hints in any good schema out there.

And I don't like the Semantic Web. Or put more accurately, I don't like the current implementations and models used for it. I hate them! I don't like their technical design, nor the fundamental philosophy behind those designs. By and large, and in contrast to Topic maps, it seems a rushed job, and I stumbled upon a very good roundup from someone I agree wholeheartedly with, which has triggered something in me; I'm no longer supporting or going down the dark alleys of RDF.

I'm sorry Danny, I'm sorry Thomas, but ... I can't go along with this any longer. The 'view source' for the Semantic Web isn't RDF in any current form, and hence, not something that I want to back anymore. 'View source' is what built the net. It is what will continue to grow it.

G'day! After threatening to put "Topic Maps Interest Group Australasia" together for a long time, I've finally found a break inbetween all the Topic maps stuff I'm doing to get it done, and hereby invite you to come and join the Australian, New Zealandish and Asian interest group for all things Topic maps, be it somewhere between and including philosophy to technical implementation.

The site tells the story much better than me (well, apart from the fact that I wrote that, too), so go have a look, and if you fit within the hard and terrifying selection criteria (which includes, um, anybody, really), please join in. I'm looking forward to seeing you there.

Today is Norway's independence day; in 1814 we broke free from our union with Denmark, only to forced into a union with Sweden, which we today celebrate breaking free from exactly 100 years ago (1905). I attended the celebration here in Canberra in sunday, which was great; I ate Wiener sausages with lompe. Happy birthday, Norway!

Also today, my second part of my Topic maps article for Hardware Bedrift was launched. Check it out if you understand a word of norwegian.

Yesterday a new site in Norway launched called Hardware Bedrift which is going to be a new place especially for people who administer companies hardware and their developers. One of the people involved knew someone who knew me, and they asked me to write for them. And I have. In norwegian. And about Topic maps, of course.

My article is called "Emnekart for vanlige dødlige" (1st part of 2) which translates to "Topic Maps for mere mortals", and is meant as a gentler introduction to not only Topic maps but also to the world of knowledge representation. If you know any norwegian, go and have a peak and let me know what you think.

I have started some serious work on the xSiteable Publishing Framework which combines a lot of things I've been working on for the last few years. This is a framework that's been brewing for quite some time, and hence I've decided to can the xSiteable project as a stand-alone thing; the good stuff developed for xSiteable version 0.95+ will be part of this new framework. Here is the rundown;

• Support for DocBook documents, xSiteable templates and content, MARC XML (which is exciting to all the librarians out there!), and Topic maps (using CSXTM).
• Conversion tool : MARC XML to Topic maps which I'm personally very excited about. I have basic support already finished.
• Small-scale cache machine support for PHP (and Java, C# and Python close behind) making it really scalable and flexible.

The most important and exciting part of this framework is that I can now create fully dynamic sites based on sets of MARC XML records. The project that triggered this is a smaller folklore project where I was handed a set of MARC XML records with annotations. Not only can I now display info about this set, but show off the synergetic effects of putting them into a Topic maps instead of a traditional RDBMS. My prototype is looking really good, and I'll share more info here as I go along.

For librarians : If anyone wants to join me in my quest for a MARC XML => Topic maps brigde, please drop me a line. What is needed the most is an MARC compatible ontology.

The tale

It was the best of times; it was the worst of times. The thick metadata fog lifted into a bright sunny day of calm and peace, and the land of Software Engineering was buzzing into life again. As the morning sprang from its long sleep, so did I, opened the windows and breathed a heavy sigh of relief.

It wasn't that long ago I had walked down littered alleys and dirty roads. Never had I been so hungry as I was walking the streets of Metadata City. It used to be a promising place, you know; nice clean abstractions and good clear labels on every door, road, trunk, box and tub, but all of that changed as more and more people expanded and exploited those plans. It could have been a wonderful box of chocolates with a simple label 'Chocolate' on it, but people soon started this whole 'Sjokolade' / 'brand' / 'I like white not brown' / 'small bits of cocoa powder mixed with milk and caking agents, having different flavours including caramel, truffles, marsipan, liqurish and brandy, sometimes with filling' labelling all over, and noone could agree on the best label.

My hunger was for clean, straight-up metadata. I had seen the idea as a bright shining lighthouse on the infoglut horizon, and I wanted to find my way to that glimmering place of 'simple and elegant means of finding what I wanted.' I know now that ideas are king, while the joker is ... well, us. No matter how good a plan, it takes only one simple glitch to render it useless. I am such a fool.

There were a few wise men and women that sometimes got together to discuss these problems, but as committees went, they went the way committees usually go; against the grain of the intended purpose. They said 'Strict Standards!', and as people started using those standards it became quite apparent how those standards didn't work or even worked together. It became the hotch-potch stew that we know Metadata City to be today.

But things are changing. People have started taking things into their own hands. Strict standards are being replaced by human and loose standards. Since we can't agree on the best label, why not accept them all? I drifted into a recap of old snapshots ...

Snapshot!

In the old days, software programs were developed by the snapshot mentality. A specification is a formalisation of a given set of requirements that tries very hard to be a roadmap for developing a specific program. It of course can't be right, but since we all think in todo-list terms, it's the best we've got, and we do it repeatedly so that at least some of our attempts works out good enough to be called success. The fact that most fail doesn't seem to pursuade us away from the comforting thought that it "works well enough."

A specification is a snapshot. It is an attempt to freeze time. "Now! Nobody move! This is our specification, and we will build a system based on these needs! Quick; write everything down, and make sure we all agree to it!" And off they go thinking they've got it down pat. Then time and life goes on, everything changes, and the finished product ain't what they want now. This is known as scope creep, but I dare say that that is a misguided label; it is the wrong approach alltogether. Isn't it funny that there is a progrom in the world that states; "The only constant is change." And isn't it funny why don't we embrace it?

The only constant is change

There is some ultimate truth to this; things change all the time, be it systems, people, societies, needs, wants and desires. The latest onslaught of so-called 'social software' really taps into this paradigm; if you design your software for change, embracing it, then there may not be a need to change it when the change comes. Let's see an example;

Someone designs and develops an online store. It uses a specific database and a specific framework written in a specific language. It has specific requirements, such as viewing, selecting and purchasing items, and then handle the communication between customer and seller, let's say email and fax, using a creditcard such as VISA and American Express.

Now what happens if the customer wants to call? Or use a credit card not listed? Or something else changes, as they will do over time? What happens? Well, the people in charge lay out some new requirements, pass these on to the developer, who develops the new feature, rolls it out, and everybody's happy ... provided the customer hangs around for that long and hasn't gone to your competitor that does support whatever feature you needed.

Note that I said needed, not wanted; there are many things in this life we want, but to do certain things you need certain things to do that. For instance, to buy something with a VISA credit card, you need a VISA credit card. It doesn't matter that you have a Fumbles Daily Credit card at all. Pretty self explanatory really, but traditionally we haven't designed systems with this in mind. Instead, we used to say "to use this online shop, you need to have a VISA or an American Express credit card." And that's the flaw; it is us telling people how to use our system, instead of them telling us how they'd like to use our system.

Back to Metadata City and social software; the thing here is that it isn't software telling the users what standard to use and exactly how to use it, it is the users who are free to use the software they would like to use it. It isn't a fixed specification of an idea, but a loose concept of a tool. We're going from specific to abstract tools, daring to trust their users to use it outside a given specified way.

Metadata is reaching that same thing these days. In Topic maps we speak of fixed points of reference, of persistant identifiers, but the new Topic maps standards are taking a more flexible turn, saying that the identity of something is a process more than an ID badge. In the RDF and Semantic Web world, the fuzziness of what a resource really are may have - and I think quite unintentional - pushed them in the same direction. More and more systems out there are starting to understand this very progrom;

As the world is fuzzy, design for fuzzy.

Basically, we must design for change, with change in mind, changing the mindset of our changing world. Anything else is a costly legacy hog that will be costly, painful, wasteful and outright stupid.

So while I've been at home mending sick wife and children for the last three days, I've been visited and deemed worthwhile by Whitespace. Thanks for that, although the added traffic focused on my pohr speling skils more than anything. Slik er livet.

In other news, yesterday I received in the mail my own copy of 'The explorers guide to the semantic web' which I was technical editor for. It is just amazing how nice that book is and how it feels good to hold and touch and let my fingers run through those crisp papers, not to mention how nice it was to see my name mentioned twice. Thanks Tom.

In more news, a librarian standards group at ISO may involve Topic maps in a standard for interlibrarian loan systems, and I might be taking part in that process, but don't quote me on it.

I built a window box yesterday from scratch using recycled bits from a cubby house I built with my father-in-law a few weeks ago. It turned out great, and the cubby house now has a cute window box under its window sporting a hanging rose flower. I'm enjoying the tranquil moments of carpentry.

I'm also (don't I ever rest?) finishing up something I call a Topic Maps Starter Kit, a Java Servlet-based web application (distributed as a WAR, maybe?) that is a full-fledged dictionary/thesaurus editor/viewer with full Java sources using and examplifying the TMAPI and possibly distributing the TinyTIM Topic maps engine, but I'll chat with Stefan about that first. It will make an excelent package you can a) use for your dictionary/thesaurus purposes, b) look at the code and extend to learn about TMAPI, and c) use to learn about Topic maps. I'll keep you posted.

In final news, I'm returning my loaned copy of by David Allen about 2/3 read, simply because I haven't had the time to finish it. Oh the irony. Luckily his method weren't too far off from what I already had in place (I'm a blogger and Wiki user, so how wrong can I be?), and good thing that this Wiki exists, courtesy of the ever wonderful Jen Vetterli.

I've invested quite a bit of time in developing social software for libraries as part of my quest in spreading the good word of Topic Maps. So where am I at?

Well, I'm not that far off; the problem I very often focus on is that the technology still is in its infancy, and tailored systems are hard to come by. Think corporate/organisational blog aggregators such as the FeedOnFeeds or even BlogLines.com itself; they work quite well, but do not fit the bill of easily implemented in an intranet, for instance. Oh sure, the features needed may come one day down the track, but they're not here right now. But I'm not sure this is the right thing to focus on.

Next up is Wiki's. Some offer RSS feeds for comments to a page, changes to a page, news about a set of pages and so on, but may not fit into the current infrastructural scheme of things. Maybe it's in Python. Our business support group won't have anything to do with it. I'm hence stuck. I'm using a terribly simple Wiki for infrastructure stuff, one that I can easily hack to make sure we've got the tools in there that we would use. Here the tool is so simple, it can hardly be called a legacy system. But it will be in time as it grows. And that, too, can be a social software pattern that at the same time increases tacit knowledge in the organisation. It doesn't matter what blogging tool I use, as long as I provide a means of communicating. A lot of people rely on trackbacks for instance, which I don't a) have a clue how works, and b) obviously not implemented. Yet I'm able to communicate. So, don't focus too much on the tools, and focus more on what it is. Project and people management will soon follow those patterns as opposed to the technology used.

What about Topic maps? Well, they are great (not that I'm biased or anything), but the lack of any systems actually having open support for them (apart from the odd closed system) makes it hard to push it onto anywhere, even though Topic maps would be perfect for library systems, such as those I use and want to use. What to do? Should we conduct awareness seminars? I did and things are slowly moving about, but unless I keep strongly at it, it will fizz out and die. And as a busy type person, I'm going to let it fizz out because my time is spent elsewhere than evangelising. Social software is more about letting the concept seep into the organisation than actually trying to push it in the door.

The same problem is for social software in general; there are great ideas, infancy technology and a lot of buzzwording going on. These things combined is not going to get us anywhere near actual implementations. The only thing that works are maturity of tools and the will of the management. Grassroots movements works fine with personal blogs, but can be really tricky for anything corporate/organisational. Even personal blogs can get into problems if they are too corporate/organisational, as many have lost their jobs because of it. Prepare everyone of it. Talk about it in productive ways. It is not "fun way of communicating", but "communicating using social patterns."

What is social software? It surely isn't for socialising, but more to do with aknowledging the social aspects of interaction between computer users. Note this, because it is important, and quite possibly the very thing that keeps social software from getting in the door. Don't let the buzzword "social software" equal software to socialise with, because that is why the coffee-room was invented; no, talk about how the social patterns that are currently untapped can be utilised to make the corporate / organisational life excel and work better together. I think that will work much, much better.

As part of setting up the upcoming tmiga.org site (Topic Maps Interest Group Australia) I wanted to list all sites and blogs that has a Topic Maps interest. Please, if you have a blog or know of one that has a Topic maps interest, let me know. I often stumble upon blogs by people who's even held small Topic maps seminars or use it for some KM purpose that I have never heard of or not met on the Topic Maps mailing-list, and I feel the need to collect and share these blogs, because we've got a very special common interest. Anyways, please let me know, and spread the word. Thanks.

As a follow-up to and closing of my journey through , I'd like to quote (quite a bit) from what I feel is its strongest and most shattering argument for why we need to stop the world for a moment and re-think our strategies;

The objectivist Legacy (pages 183-184, paperback edition, 1990)

According to the objectivist paradigm, true knowledge of the external world can only be achieved if the system of symbols we use in thinking can accurately represent the external world. The objectivist conception of mind must therefore rule out anything that can get in the way of that: perception, which can fool us; the body, which has its frailties; society, which has its pressures and special interests; memories, which can fade; mental images, which can differ from person to person; and imagination - especially metaphor and metonymy - which cannot fit the objectively given external world.

It is our objectivist legacy that we view rationality as being purely mental, unemotional, detached - independent of imagination, of social functioning, and of the limitations of our bodies and our memories. It is our objectivist legacy that leads us to view reasoning as mechanical and to glorify those kinds of reasoning that in fact are mechanical. It is our objectivist legacy that leads us to view machines that are capable of algorithmic computation as being capable of human reason. And it is our objectivist legacy that we view it as progress when we are able to structure aspects of our physical and social environment to make it more like an objectivist universe.

[...] People have been treated as numbers and collections of records for a long time, and they will be treated much more so in the future.

Such treatment serves an important function in our society. There is a major folk theory in our society according to which being objective is being fair, and human judgement is subject to error or likely to be biased. Consequently decisions concerning people should be made on "objective" grounds as often as possible. It is the major way that people who make decisions avoid blame. If there are "objective" criteria on which to base a decision, then one cannot be blamed for being biased, and consequently one cannot be criticized, demoted, fired, or sued.

Another reason for the attempt to construct our institutions according to objectivist metaphysics is that is is supposed to be efficent. In some cases it may be, in others it may not be. But an awful lot of time and effort goes into trying to make matters of human judgement fit what are supposed to be objective pigeonholes. If the classical theory of categorization is not correct, the then wholesale importation of objectivist metaphysics into our institutions may not only be inhumane, but it may in the long run be an inefficent way for human beings to function. At the very least we should be aware that our institutions are being structured in terms of a perticular metaphysics and a psychological theory of categorization which, as we shall see, is highly questionable.

One of the reasons why the classical theory of categorization is becoming more, rather than less, popular, is that it is built into the foundations of mathematics and into much of our current computer software. Since mathematical and computer models are being used more and more as intellectual tools in the cognitive sciences, it is not surprising that there is considerable pressure to keep the traditional theory of classification at all costs. It fits the available intellectual tools, and abandoning it would require the development og new intellectual tools. And retooling is no more popular in the academy than in industry.

For people working with SemWeb related technology this implies "taking a long hard breather" before continuing. Lakoff uses the rest of this book to crush the idea of classical categorization theory, giving strong evidence and use-cases and - probably most importantly - common sense and "Duh!" moments.

Yes, even if my last post was a bit of a contradiction, some new and interesting ways forward for xSiteable seems to resurface these days. I'm going to have xSiteable split in three distinct projects in the future;

• xSiteable Core : pretty much as the XSLT framework it is now (er, as in the 0.9 series, which will be release "some time soon" ...)
• xSiteable Cache : Various cache machines that will work with xSiteable, creating a fully dynamic CMS system, where if a page gets added or changed the cache will recompile it for you simply by refreshing it through the browser. (Think JSP recompile) The first cache machine offered (as in "out of the box") will be PHP, and Asbjorn has been sniffing at a .Net version, and anyone can contribute their favourite technology if they like.
• xSiteable Content Editor : As it says, a content editor with a web interface, works as a plug-in to Core, and will - together with Cache - create a full CMS system. This module is very similar to the PHP Admin application that was shipped with xSiteable up and including version 0.88.

The idea here is that you add on each module to create a more complex system as needed. If a static page compiler is what you need, then settle with only Core. If you want a dynamic site where you easily can change something, and it is dynamically updated, you add on the Cache. And if you want a remote content editor, chuck the Content Editor on top of the Cache (which already sits on top of Core) to have all the whistles and bells you like. Extensions to this Content Editor is things like multiple users.

The two reasons all this has come up now is that 1) I might have a work-related project that seems to fit the xSiteable bill, and 2) interest in xSiteable from various users have crept up. I'll update here as things move along (it has a current "to the end of the year" scope), but if you have any ideas and such, please let me know.

On friday I held a Topic Maps awareness seminar here at the National Library of Australia, and in addition to being well received and jolly good for beginners and learners, it was also done with a 112 slides bullet-point free PowerPoint presentation! You'll find the presentation on this NLA Staff Paper page when some notes are written down, but it is available on that server from here in the mean time. It has notes on every slide, so be sure to run it in notes-mode. Enjoy, and please post your feedback here. Thanks.

There is a new book out on the semantic web by Thomas Passin that I need to recomend (Oh, and Danny Ayers has spotted it), because it is good and I'm in it. Well, that's not entirely true, but a few spelling and technical mistakes that is not in it could have been there if I was not there as a technical editor, bugging Tom with them, and letting him know what I thought of his prose. Which I thought was excelent, btw.

The book 'The explorers guide to the semantic web' is now available in eBook form at 20$, or you can wait a couple of weeks for the dead-tree version for about the double of that. The gory details are 'June 2004, Softbound, 304 pages, ISBN 1932394206'. It contains mostly information about the semantic web, but has also got quite a lot of Topic maps in there too, one whole chapter and interspersed bits, and a use case using the excelent TM4Jscript Topic Maps engine. The blurb from the Manning website says;

This Guide acquaints you with the basic ideas and technologies of the Semantic Web, their roles and inter-relationships. The book's basic, conceptual approach is accessible to readers with a wide range of backgrounds and interests. The key areas covered include knowledge modeling (RDF, Topic Maps), ontology (OWL), agents (intelligent and otherwise), distributed trust and belief, "semantically-focused" search, and much more.

Enjoy, and congratulations to Tom on a book project long in the making.

After my last installment, I guess you saw this one coming; My experiment with PHP5, XML and Topic Maps did succeed, and I hereby bring you a truly rocky beta of it. Not rocky as in 'unstable pile of crap', but as in 'haven't got time to polish it further'. It works well, and simple testing done on my machine (a 1 point something GHz something ... ) here reads, parses and indexes the famed Opera.xtm file in 0.28 of a second, which could be cached for faster performance. The searching through the whole map for topics of type '#opera' was rather fast; 0.000028 of a second.

Anyways, I'm releasing this in the wild, because it is a quick hack and I don't have time to polish it, but if someone does, please let me know that my hatchling is doing ok, huh? There are three files in total PHP, and whatever XTM file (search around til you find one) you like. You need tm.php, the engine topicmaps.php itself, and a helper template thingy called html.php which you don't really need, but makes the tm.php example look better. :) They're all wrapped up nicely in this handy-dandy ZIP file. Anyways, enjoy. And if I'm peer-presured to do something serious with it, my email address can be found over here.

As an experiment to see what PHP5 can offer us Topic Mappers in terms of XML power, I fiddled a bit and came up with ... something quite interesting; a quite capable Topic maps engine. I've parsed most XTM files I could find through it, and it responds pretty well to them all. Bare in mind that this was a four hour experiment, but as such, it turned out that PHP's XML capabilites coupled with the new OO Zend2 engine and indexed arrays, I've churned out an engine that handles quite a lot of topics rather fast and effective. And I haven't optimised anything yet.

Here's what I'll do; Over at DotGeek.org I've obtained some hosting just dying to get used, and since I like the current results so much, I've decided to create an online Topic maps browser there. The engine is almost ready for some early beta application testing, so I'll make some simple "upload your XTM to this server" page and a general TM browser there. What do you think? Any other good uses for a Topic maps engine example? (Yes, don't remind me of the upcoming tutorials I'm writing ... :)

As you know, the version 0.95 is almost becoming legendary for not being released. I've had quite a lot of requests and questions about it lately, and thought I'd give this little update here.

What's going on?

Well, not too much, as my time and efforts are drenched these days. There is a beta of 0.95 sleeping here on my harddrive (and for those brave, brave people out there, I've chucked an unfinished beta version here for your pleasure, but it comes without any guarantee to solve any world problem!) still awaiting some polishing up and finishing. Time schedule? Why knows. Maybe within a month or so.

What's in store?

Quite a lot, which is why I jumped from 0.88 to 0.95 without any versions inbetween. One of the major things is of course the rewrite and refactoring of most code, and in that I've made everything configurable through nice little XML configuration files. Now you can do things quite the way you like it.

And?

And, it it isn't backwards compatible out of the box. But there is a nice document explaining a simple procedure of how to convert from pre-0.95 to the new system in a few simple steps. It isn't all that hard. The reason for the uncompatibility is of course that the file structures have been altered.

Why?

All the changes made are done for one important reason; flexibility. I know that spouting "flexibility" can be seen upon as cursing in a church, but let me explain. There are many good and clever bits in xSiteable; libraries to do notation translation, importing of complex XML or XTM data, dealing with Topic Maps, creating various menues and breadcrumbs, advanced CSS, and so forth, all done in XSLT. In the old days, you could only use this goodness from and through xSiteable itself. Now you can use bits of it in other applications.

Huh? Other applications?

A goal of mine is to create a CMS based on Topic Maps, and as much as 0.88 was a legacy CMS system, I wanted more. What I specifically wanted was a way to link xSiteable into an appropriate dynamic cache of sorts, so that it could be used as a backend CMS engine for a ASP/.NET/PHP/JSP framework. Now it can, and the famed old PHP administration application that came with 0.88 has been taken out.

What!? That was the cool part of the application?

I know, I know, but hold on. My time doesn't stretch far enough to maintain the PHP package. I din't have time to convert it into the 0.95 format. So I leave this as an exercise for other developers to do. Take the old admin package, and create versions of it for ASP/.NET/PHP/JSP or whatever you fancy. The new 0.95 structure makes this really, really simple and easy. (If, and only if, I find myself in massive amounts of time and boredness, I might convert the old PHP app, but I doubt it. Unless you all threaten me or something. Maybe.)

And there you have it. There are of course lot's of other things I'd like to say about this, but I'll leave that for a time closer to release. If anyone has any comments, leave them in this blog entry or mail me at [alex at shelter dot nu]. If you want to help out with any development of the system, like a administration app or something, do NOT hesitate! You know who you are, Asbjørn! :)

I've just published an essay about Topic Maps, the concepts and how it all works. It includes name calling, Amazon.com bashing, conceptual waffling and philosophical musing of RDBMS as compared to "do the right thing." Enjoy.

It is hard to be under pressure; there is no secret to this, it is acepted by all and one as a normal part of being a human being. But being human suggests so much more at the same time, so how do we get to "under pressure" as a state of things when it is only a part of things?

Did all of that sounds a bit cryptical? Possibly, but it underlines a very human trait; we overexadurate. How are you today? "Boy, I'm pooped" they say. Normal greetings are often met with such things as "good", "tired", "excited" or "bored" or some other one to two word explanation of the overly complex status of being alive. They are, as so many things in life, too easy and at times an outright lie. How come we have to meddle in the simplistic black and white of things? It isn't interesting, does not lend itself to learning, is poorly guided and hold no long-term values.

It is all about rituals and traditions, I'm afraid. It is tradition that if someone asks you how you are, you lie and tell them "good" or "sad" or "alright". it is part of living in a society that doesn't really care one bit about how you are, but have developed this technique to seem like it cares. Here are two versions of the same conversation in two different countries;

"Hi Alex, how are you?"

"Oh, pretty good. How about you?"

Vs.

"Hi Alex, how are you?"

"Oh kinda alright, but I have this gnashing sadness these days eating away at my very soul, probably due to being so far away from all things that are familiar to me and matters to my life. I'm sure it is a passing stage, though. How's things with you?"

Can you guess which one is the Australian one and which is the Norwegian one? That's right; the one with the full truth in it is Norwegian, because it isn't expected nor wanted in Australia. In Norway your actual status is important, and the questions are important. If they don't want your actual status, they won't ask it. In Australia it is the other way around; they are asking because they don't want your actual status. This shall stand as the example of cultural differences that you should try to understand before you launch into your life's story to people who mostly couldn't give a toss to wheter you live or die.

I am under pressure these days; work have a project deadline coming up, I have a Topic maps tutorial to finish, two Topic maps projects to finish in prototype status, a new house full of little projects to complete with two small kids who don't know what being under pressure even means. And now for the fulcrum; do I? Do I know what "under pressure" means?

I use it to describe myself these days. A friend asked me in the general Australian manner "How are you?" and I answered him in the Norwegian manner "under pressure", totally confusing him of course, but I had the good excuse of being under pressure and hence choosing the wrong version. He understood.

But what does it mean? Does it mean that all the time I'm under pressure, not being able to think straight or do good deeds in the presence of anyone, because they are pressuring me in this or the other way? Of course not. Last night I even had a rather plesant conversation with my lovely wife, and then a wonderful bed-time conversation with my oldest daughter. And I listened to some Bach Recorder Sonatas. And I went to bed, listening to cicadas for a little while. All wonderful and nice experiences, hardly classified as "under pressure." I didn't feel "under pressure" during these happenings, yet I classify myself as such. What goes?

Part one : Human perception

We humans suck at complexities. We can remember a handful of data about one given thing, but without tiresome repetition, we can't hold the info long enough to understand it. We need to write it down, look at it, study it, think about it, and then we can start to grasp it, but only start. This is why most debates are a total waste of time; people can't get their heads around the info to a grasping level, which is why debates always end up in "black is wrong, white is right" bullshit. Any intelligent person knows that it is never black and white, yet we all seem to push black and white as our underlying protocol of understanding. "How are you" "Good, thanks." Black and white.

Within science, there is black and white, which is why all good scientists must publish a million articles and win a dozen awards before they can say that all our knowledge about a certain fraction of the universe is wrong. In religion, you have to be the hardiest and most devout follower, a publisher of million copies of "this is how it is" before you can write your "this is how it's not". We must build our credentials and reputation on wrongs before we can try to set them right. No, I'm not talking about things that are gray, like "the missing link" or "gospel of Thomas", but the backbone of the given line of culture; what if there really was a God, or what if God really is made up? To both camps, these truths would be pretty earth-quakal.

Human perception and epistomology combined gives us some-part genetics and some-part environment beings learning through behavior of themselves and others, guided by the simplicity of the data we're given. We perceive things very much like a computer; there are options one, two or three, and our backbone knowledge is based on these simplicities. Add 100 options to any complex problem, and the human can't possible perceive anything, crawl into a corner and yell "under pressure."

Part two : Human knowledge

We know because we think, some say. Others point out that we know things before we think, like instincts. Ah, says others, what some call "thinking" others call "feeling" and vice-versa. And, shouts yet others, knowledge is the explicit result of thinking, and can't possibly be mistaken.

Epistomology is a lot fun and a lot of bullshit. The fun is thinking about it, and the bullshit is when you formalise it, and as such I won't even dare to confront it; for me it just is. Now, that is a pretty vague and spineless statement as any, I'm reminded by voices of past encounters. But is it? Is it spineless that something just is? First of all, philosophy - in its basic form - are questions, and for most humans, questions demand answers, and answers comes from thinking about the question with all your knowledge. Do you know how you think? I personally can "think" in several languages, and a lot of other people do to. Do I think alike in two languages? Is dreaming thinking, a possible third language? What is thinking? Can you - off the top of your head - formalise just where a thought begins? Is it that you see a cow, and think "Heh, a cow" or is it that out of nowhere - assumed by random - you think "Hey! A cow! Now that's a cool animal." What is the process from "blank" to "cow"?

For me, it just is. There might be a myriad of things affecting how the thought appears, but to formalise it? Forget it. It just is. It just happens. For me. And, let me ask, why do we need it to be anything else?

Just like religious people say "Why does God have to be a man or woman or anything resembling a physical being? It just is." Or in science when asked about what gravity is. It just is. there are many things in this world where I'm happy to say "it just is", like how they make perfectly round chocolate marbles with biscuit inside; shouldn't there be a deformation where the marble cooled off, or something? I don't know, yet my life goes on, and I can write complex articles about the influence of Basso Continuo in Monteverdian Operas at the beginning of the 17-th century. I'm willing to accept "it just is" with this, same with trying to formalise any thought. I often call it bullshit, because "it just is" and "bullshift" so often are interchangable. try it; a methodic formalisation of thought processes leading from void to idea. Bullshit. The best you can do is to get at some core stimula in which you might - might! - have come to some idea.

Human knowledge is a lot about bullshit; we filter it, extend it, dwell on it and suck it in. Black and white. Simplicity vs. complexity.

Part three : Stupid idiots

What stupid idiot asks "Can I have some cake?" without wanting some cake? According to the general state of things, a great lot of them. So many of us have some principle, some political agenda, philosophical standing or stubborn opinion that asks for cake, but it comes down to it, when it comes down to actually eating the stuff, what happens?

There is capitalists that wants social rights. There are communists that enjoy commercial success. There are socialists that wants to get rid of the whingers and leaches of society. There are warmongers that really wants peace, and peace doves that tells funny war-jokes and laughs about them. In short; there are highways with little intersections running off it in all directions. This is the human mind. the highway give people a sense of direction, but they take an intersection if they feel that the direction is somewhat bumpy, crowded, wrong, slow, mellow, dramatic, hard, etc. Just like the human mind. We have a hypocrit mind, let's make no mistake about it. the most devout human mind has hypocritical tendencies.

Does that make them a stupid idiot? Not at all; it makes them human. It is the people who think that there should be no intersections and smaller, less-travelled roads that are stupid idiots. Why can't a capitalist also hold certain socialist values? Why can't science have a bit of religion in it? Why can't politics have a bit of sense in it? Why must we insist on the classification of simplicity?

Ah, I bet you didn't see that coming!

Well, I actually bet you did; classification is a large part of how we perceive things, how knowledge works, and how I can put people in a box labelled "stupid idiots." It makes it easy. Simple. Thinking is a real-time ever-changing query language to a massive graph of simple knowledge. Why does simplicity persist? Because most knowledge is simple in form, and complex in relationships. "A house" is a simple construct. "Houses" is a complex relationship with several simple "A house" constructs.

Now, this is why graph theory is so appealing to Artificial Intelligence researchers, and possibly why Topic maps was so appealing to me. it makes sense. Isolated topics; simple and good. Context; complex and difficult.

How can we simplify context? A lot of people are creating ontologies for this purpose. It might work for some things, but for the most parts you can't fit it all in. Even the Cyc ontology is rather complex, and it isn't so intuitive that any human can whiz out their thoughts in it just like that. Specialist tools and processes are needed, and unfortunately that leads us back to the tries to formalise the human thought patters. Ugh.

Languages

We've brushed gently on the side of languages, and let's go back; inside a language are constructs to thinking and knowledge. The mix of audiovisual stimulants with language is - as I've thought for a long time - the key to successful AI systems. A lot of research has gone into this, but there is that step which seems to drag it all down - logic and formalisation - which essentially stop things being human.

Is that a philosophical stand? More like a principle? Well, no; it is all about how human perception goes. We perceive things, and know things, and have instincts on top, and if the system designed hasn't got all of this, it isn't going to represent any human trait. It might be a good mockery, it might even pass a Turing test and make some good estimate on the odds of something or other, but will it be viable? Oh, there are lots of practical things that can be done, but by viable I'm referring to "gather that messages from Liz and Elisabeth are the same person, but has different implications as going to friends (Liz) and others (Elisabeth), and how to use this in writing a first draft letter of admiration.

Finally!

If you've come all the way down here, I congratulate you; it was something of an experiment, having watched "Finding Forrester" a few days ago, I decided to try to write with my heart, and no editing before publishing, just to see what comes out the other end.

And the conclusion is clear; I'd better go and classify and formalise my thought processes before I publish the edited version!

There has been a lot of activity in my head lately, in major philosophical ways, and I'm getting somewhat close to a fulcrum of sorts. There are still some things I need to chink out, so I'm holding my breath (as I'm sure you all do too) about it until next week, but I'm writing again on something that should slightly resemble an article of sorts.

In the mean-time, I'll just note that I also have started writing a Topic maps tutorial entitled "How to sort your CD collection with Topic Maps", and Peter Van Dijck must be happy now. I'll push it out at the end of the week.

I had a flare of inspiration last night to write about the philosophy of trust, based on a book that I'm currently doing technical review for; how easy it is for us to give and take trust. Ever heard someone say "SuchAndSuch.com is crap! It was down all last night, and I couldn't buy the wife some hockey-boots!" All the time. And we, as perceptive beings, we take this one tiny fragment of someones experience with a company, in their tiny, tiny fragment of existance, and paint "ureliable" all over its timeline and hard-working staff with big brushes. Silly, ain't it? Yet, this is how we work. Trust.

Peter Van Dijck has a blurb on the difficulties in learning Topic maps. Now, I trust Peter and a lot of others do too. He's a figure in various domains, has written an apparent excelent book about Information Architecture, devised the XFML format for faceted info and sharing, and set up and initiated EasyTopicMaps.com the Topic Maps common Wiki. His word and expertise is good. And James Robertson of Column Two agrees with him. I trust James too. James is an expert, and knows his stuff. If he says jump, I'll probably do it. Same for Peter. Goodie.

Are they right, though? The thing is that I've had similar (or probably exact; memory is a bugger) conclusions about Topic maps in the past; the XTM format is too verbose, the spec too diverse, the datamodel too much, the psychological impact too distressing, and so forth. But they - and the old me - are not right.

The general issue raised is that the Topic maps examples and tools are too far away from practical real-world stuff developers do that people simply give up; it becomes too much to get going with it. First, let me give you my bias in this; this is why I created xSiteable (a real-world site generator, used to create a number of sites on the net, including this my own) and helped Thomas Passin set up TM4Jscript, a TM engine and editor (and soon a bookmarks application) for JavaScript (meaning, super-easy to get going with as every major browser has got JS in there). I'm not saying Peter and James got it wrong because I've done these things, but let's think about it;

There are a number of smaller and big applications using Topic maps around, some fancy smoke-and-mirrors, others down to the core and solving problems. There are a number of sites that are smokey demonstrations, and others that solve real issues with it. Fine, we can point to these, and say "Aha!"

Let's talk about the real world, and the need to reflect it in terms of Topic maps; the reality lies in what Topic maps should and should not be applied to. If you want a relational database, then use a relational database. It is the most real-world application out there. If you want a Topic Maps database, use a Topic Maps database. I feel a bit silly for stating the bleeding obvious, but some of the real-world problems people often want to solve can be handled with traditional methods just fine. There is no reason to enforce the wonderfulness of Topic Maps on them ... unless they want to take some steps further, and it is knowing about these steps which is the paradigm shift promised by Topic Maps, nothing else.

Peter points this out quite rightly. We call the cross-over to Topic maps for "a paradigm shift", no small statement.

"Huh? I can do this database just as well as Topic Maps using plain vanilla SQL databases! What's the fuzz?"

That's right; what's the fuzz? The thing is that if you can do the same, then don't do it, and most Topic Mappers know this. Their applications are outside of the scope of the traditional way of doing things, hence so few examples of them. We are hard-working people who write specialised and clever applications, and so we don't really have the time to write "how to sort your CD collection with Topic Maps." If a relational real-world thing that has been solved a million times over is what you want, then Topic Maps will be a pain in the hindsight, and you'll say "Topic Maps are hard to learn! I was fiddling all last night, and I didn't have time to buy the wife some hockey-boots!"

Get smart; that is why you'll dig into Topic Maps, and people who knows about those extra steps, who knows the value of semantic-rich metadata instead of the crap we mostly put out these days, will prevail with Topic Maps. It is not about showing someone a real-world problem, because they are mostly solved by proven method already. It is about showing people better ways. It is why we call it a paradigm shift, and not simply "another way of doing it"; it will tilt your mind, and push you further. That is why Topic maps can be hard to learn. Paradigm shift. Repeat it a few times until you understand it. It is 20% ideas, 70% philosophy, and 10% application.

Peter raised a few questions on a few mailing-lists and asked if anyone knew about easy applications or frameworks for Topic maps that could help us in evangelising our lamb. He states;

There are no hackable applications that I know of you can use to learn topicmaps. This means that there are no beginners tutorials that let you hack a useful application together based on topicmaps. All the tutorials I've seen teach you topicmap concepts and how to create a topicmap. They don't help you create an application to organize your CD's.

So, in Peter we trust, and even though I've seen most of the responses (I added some myself) he still says there are no hackable applications that you could use for easily learning about Topic maps. How does he come to that conclusion? I surely don't agree, but it is hard to fight this one back as I don't have the readership he's got. In fact, both Peter and James agree on this, and it is - in my opinion - far more harming to the ways of Topic Mapping than anything, as people trust what they say, and so it must be true.

To state the reality; There are lots of applications, some half-done, some bigger, some complex, some easy, some small, some big, some free, some commercial, some ugly, some pretty, and so on and on. If we are to take at face value that there are no hackable applications, please let us know the formular you're using. Hmmm, he puts a qualifier on it;

All the tutorials I've seen teach you topicmap concepts and how to create a topicmap. They don't help you create an application to organize your CD's.

Maybe he's right, but I have seen tutorials and / or documents that tell you how to use XSLT to create a website (there is also the excelent chapter 9 of the that is an extention of this; source available.), how to harvest a Topic Map using XSLT and how to create a Topic Maps engine in a relational database. Just a few off the top of my head, very real-world stuff. Of course there are overwhelming "concepts" tutorials out there; the concepts are new, and often don't solve "how to sort your CD collection" at all.

What is the purpose of Peters blurb? That Topic Maps can be hard for some? Anything that doesn't apply to? That there are no hackable application? Hogwash. No real-world tutorials? not true. That RDF with FOAF is suceeding? Politics. That we need more of whatever? Help us out. What we need is not 'this is hard', but 'this is clever.'

The promise of the Semantic Web (TM) is a good one, albeit I'm getting more and more to the point where I think it won't fix what we want, and it will fix what we didn't think needed fixing, and it will create more problems and challenges, and is only a small part of the evolution to whatever Really Good Technology (TM) that we really need. But what do I know? "Prove it!"

First off, the state of RDF today, deomnstrated through a mail snippet from the RDF interest mailing list with Bin Zhu asking the most basic question ;

I have a very basic question. RDF statements are

all triples. But if I want to express "Tom borrowed

a book from Mike", how do I express this sentence

using triples? Thanks in advance!

Basic, simple and should be trivial to get done. Here is the reply from Benja Fallenstein (who seems to know his stuff) ;

The usual thing is to have a bnode ("anonymous node") that has connections on different properties to Tom, the book, and Mike -- for example:

_:a rdf:type x:Borrowing

_:a x:who prs:Tom

_:a x:fromWhom prs:Mike

_:a x:what _:b

_:b rdf:type x:Book

Of course, if you just want to say that Tom borrowed *some* book from Mike, you could also have a special property, like so:

prs:Tom x:borrowedBookFrom prs:Mike

but I don't think that's what you're looking for.

The "borrowing" may be a bit of a strange concept -- i.e., so see the-book-is-borrowed as an object. An example where this maps a bit easier to familiar concepts would be "Anna met Ginny at the office on 2004-03-14". This could be represented as

_:a rdf:type y:Meeting

_:a y:person1 prs:Anna

_:a y:person2 prs:Ginny

_:a y:where y:office

Here instead of the concept of a "borrowing" between Tom and Mike we have the more familiar concept of a "meeting" between Anna and Ginny. But really, the two are very much the same thing conceptually: representing the relationship between different things as an object that we can make additional connections to.

Huh?

Clear as glass, ain't it? It is not that I don't understand what is being said, but this is not the easy way to do the Semantic Web. Heck, this was an easy question, which should have an easy answer. But RDF is centralised around the triplet notion (because someone once said you can explain anything through triplets and it seems to have stuck to the SemWeb community like moss to rocks, and while logically true, it ain't the simplest nor the best way). What should have been done was ;

#Tom borrowed #Book from #Mike.

A car doesn't borrow, neither does the sky. Heck, wasn't this all about logical deduction? I'm sure it started out that way, but that ain't what it is turning into; yet another item-property jungle.

It is the promise that RDF declare what is not declared, hence using namespaces like prs:Tom, and if not defined in our statements, it is assumed that there is a person named Tom. Looks good on the surface, but what if we several namespaces for almost but not identical persons? Enter OWL which could clear this up, but really muddles the waters further. Entering another namespace, declaring ID for the new items and a whole heap of predicates isn't going to make it clearer that prs:Tom, person:Tom, spr:Tom or p:Thomas is or isn't the same person, what he is or isn't. It is all about ... (wait for it) ... interpretation, and - as the promise goes - the intelligent agents of the Semantic Wec can use some order of logic to deduct who the person really is. But that ain't interpretation, that is deduction.

Interpretation lies with people. We have to do it. In the end, all errors and logical disomalities require a person to come in and save them from total logical backlash of context. Here is some nice RDF ;

_:a rdf:type x:Person

_:a x:Person prs:Tom

_:b rdf:type x:Person

_:b x:Person _:a

Recursive, bloaty and misinformative nodes traversed by strictly logical agents will fail. For RDF to work, all input must be "correct" (as in be in terms with what the logic agent wants to deduct) and all references must be unique, a pretty simple thing to pull off on your own machine in the lab, but applied to the world at large ... um, no. It takes only a few wrong nodes of info to corrupt a whole graph. It ain't hard at all. Sneak in a little;

_:a rdf:type x:Person

_:a x:Person prs:Thomas

And already you need several nodes of information to verify if prs:Tom and prs:Thomas are related. And even then you've got to figure of in what scopes they are and are not related, and so on. You'll need rather big machines to figure out the tiniest and insignificant data. To do loops through massive (and one can boggle at the shere thought of just how massive) amounts of nodes and data you need quite large guns, a lot of patience, some killer "fuzzy" logic apparatus and bucketloads of data integrity tools to help you out. Not quite the dream of small PDA's with agents doing the grunt work for you so that you can have your favourite pizza ordered in the area you're currently in. Yeah, yeah, centralised services, and all that jazz, and yet another step out from the one thing that was to bind them all; simplicity.

And to top it off, some random references; . Thanks for listening to a tired pratt. I'm sure I'll get back to creating triplestores in a couple of days.

I've been planning a new project for some time, and this is the initial Release of Ideas. The project has been brewing for some time, but needs have arisen for me to actually get it up an running in a somewhat fast pace. I need a system for updating project areas with documentation, people involved, business cases, history and so forth (the usual suspects), more as a collobarotive system more than specialised editors of content. Very much like a Wiki, but fixing the (for me) appearrant flaws of current Wiki's.

The project is called Topiki, and is a Wiki- and topic maps based application for intranet/internet collaborative documentation / CMS. It works almost like other Eiki's, but has subtle Topic maps features that would make it ideal, and really is one of the big bugbears I have with Wiki's today. Here is the feature list;

• Topic maps based Wiki (the definition)
• PHP as the underlying technology for easy distribution (flat files, no database)
• xSiteable notation, because it is powerful and works
• Taxonomical classification, so that Wiki elements can be hiercally viewed
• XTM, XFML, RSS and ATOM feeds of changes, announcements, pr. page and pr. site
• Subversion and WebDAV (WebFolders on Microsoft platforms) support for versioning

Why is this project different from other Wiki's? Normal Wiki's have binary links to pages, so the relationships between them is non-exsistant / singular. This is a major flaw to fix. Also, normal Wiki's focus on having backend databases for storage, which hinders easy distribution and setup. Also, Topiki introduces scoped topics, various names for the same thing and faceted classification.

Anyways, I would really appreciate feedback on this before I get too gritty with it. All the problems from Wiki's, CMS and KM systems are wanted.

Update, 26th of February : A mail I sent to the Topic Maps mailing-list to explain a few queries;

The main idea of doing this project was to "plonk" two files in a file structure somewhere (with a property in it telling it what Project Manager [the magical software called Topiki Mama] it was attached to) using only the capabilities that comes with a PHP default installation. This basically means "install PHP if you haven't got it, download and extract Topiki somewhere, and plonk your two files (index.php and config.xml, or edit existing ones). That's it; run and use."

All links in the Topiki network will be binary when they are created, but all links (associations) can be edited to be of any association type. Same with links to resources (documents, images, etc).

At the moment I have a few classes that do all the magic stuff, so after installing Topiki to get a page to have Topiki capabilities it is as easy as ;

// Where is Mama?

define ( "TOPIKI", "/some/path/here/to/topiki/install/" ) ;

// Configure, and let Mama know where we are

require ( TOPIKI."topiki.php" ) ;

// Show thyself!

$project->display() ;

?>

There is a template engine in there as well, so you can have existing code wrapped around this as well, and in your config.xml file you flag templating on or off.

Anyways, there will be at all times an XTM file in the Topiki Mama home directory that reflects the whole node-tree and its content. (Since Topiki uses notation for content, this is easily handled in the XTM) To extract information from your tree-nodes is a piece of simple XSLT or whatever you'd like to use. (I havn't thought much about XTM import, but I can rip out some stuff from xSiteable to do just that)

As for libraries and stuff, nothing but the default install (this is so that it is easier than easy to dump this in a intranet to get Wiki capabilities in there) I use flat files for storage and content (so no heavy-duty traffic, but it will do for most intranets). (At the moment I'm possibly, maybe, probably, definitly thinking of using PHP5, for both better OO system and a few underlying XML/XSLT goodies that would make a lot of code redundant and improve performance. Strong objections will be considered. :)

I have tons of ideas popping up right, left and center, so I'm trying to jot down a small spec, and somewhere in there lies a small PoC that can be tested and commented upon before the juicier bits gets done, but all in all I think it can prove itself interesting.

Comments still very much wanted.

I bought the domain xSiteable.org some time ago, and linked it in to the exsisting xSiteable site structure, but forgot to tell the world about it; xSiteable now has its own domain, its own life, and is ready for the normal poundering of developers seeking a neat way to create complex static sites.

Many have warned us; using XSLT for Topic maps is probably not your best option, and to a certain degree they're right. However, xSiteable uses XTM 1.0 directly, but it has reached a point where things gets too messy.

Insert CSXTM (Compact Simplified XTM), a simpler and more compact version of XTM 1.0, which is by far easier to grok in XSLT and hence improve both speed of excecution and the ease of use.

I'm rewriting the core engine of xSiteable to use CSXTM for the upcoming 0.9 version.

|/On the train home yesterday I cought myself asking that dreaded question: "Who am I?"current work with Topic maps and Knowledge and information. I'll dig up my old code and models, and see what good they can do now 10 years later. Maybe - and hopefully - they are like wine; better with age.

So, who am I? I am the map, and all emotions inbetween which makes things ... interesting. Let's see if I can make my map more emotional.

• I've hacked a comment system into xSiteable, and hence - also this site. Tell me if it works. :)
• xSiteable is getting a configuration overhaul. Let me know of any features you feel lacking.
• I promised to release a 0.86 version of xSiteable last week, but I'm sorry to say that I just couldn't find the time to do it. My wife is approaching labour (we're expecting a second child in a week), and preparations and excitement over this rated higher that writing documentation. Sorry, will get it out this week. I promise. Really.
• I've started making a distributed topicmaps editor in the .NET framework. Plans are even to create a service so that everybody (who's ISP don't have .NET installed) can edit and create topic maps, and give us the possibility of sharing them across the net. More on this as things progress.
• I'm involved with a huge Topic maps project at work, and I may have the chance to use the amazing OKS to create a true knowledge-base. I'm quite excited about this work.

So, there you have it. There has been quite some movement in various mailing-lists lately about the whole social software thing, but I don't know what started people on this old thing. Social software has been around for years in some form or other. That the buzzword should emerge now I guess is due to a few different things, but mostly I think it is due to the fact of a) blogging, b) value of online time and c) "added value" to whatever sites that makes/tries to make money.

Graphviz is an open-source graphing tool that now can create nice topic maps graphically through xSiteable. This is just the humble beginning; I've got some nifty ideas for where to take this. Comments are welcome;

The demo site is over here, and it is a direct re-compile with graphs added of the xSiteable Site. Enjoy.

I held a presentation of xSiteable at the Rica Hotel in Oslo at the Emnekart Norge (Topic Maps Norway, a specialist-group within the SGML/XML user-group of Norway) initiation seminar with an audiance of about 100 people.

Both Steve Pepper and Lars Marius Garshol (from Ontopia were there presenting their stuff, and Steve held a primer, too. It was about portals and how to make the most of them using Topic maps. Good fun, good stuff.

Steve Pepper of Ontopia has written the paper "Curing the Web's Identity Crisis" which deals with the idea of identity on the net and how it revolves around the Resource Description Framework of W3C.org.

It is a most interesting paper that anyone with an interest in a semantic web should read. It of course promotes Topic maps as a solution.

A new quick-fix bug-fix release of xSiteable has been released.

After some time of serious hacking, the new xSiteable version 0.8 is out the door. It contains a number of interesting features;

A GUI admin tool, flexible ontology, automagic taxonomy, blogging, metadata feeds (RSS, XFTM, DC, RDF, XTM), XTM imports, a host of new templates and supported items, and lots of new documentation.

This release is the cleaned-up version of the very package that runs my site, so do check it out either at the xSiteable homepage or directly at SourceForge.

Lars Marius Garhol from Ontopia has written an essential and excelent article about the two standards, how they came to be, their similarities and differences. If nothing else, it tells me that my choice of Topic maps is the right one for me.

This excelent article, written by Marc de Graauw, is a great way of lending topic maps to people who live in the world of relational databases. Quite a few of the programmers at work came back with a "Aha!" after reading it, saying they finally understood what I have been talking about for the last year.

The xSiteable project has got some new exciting metadata features;

• Site delivers a RSS 2.0 formatted channel file for recent entries.
• Site delivers a XFML 1.0 (eXchangeable Faceted Metadata Language) formatted categories and entries file.
• Site delivers a full XTM 1.0 topic map of the site.
• Each page delivers Dublin Core metadata wrapped in RDF (Resource Description Framework).

All the files are delivered at static placeholders.