The world drags on; The business rules are showing us the way; The organisation swirls onwards in an amorous flirt which at an excecutive level is dubbed "common sense."

Usability practices are usually talked about it terms of making perfect sense. "Naming this button 'blah' instead of 'fiddle' indicates to us that, according to our tests, our customers would buy more products." It is very convincing indeed, and, in another whirl of excecutive glee, it is ordered to put in these new usable stuff.

So, it is agreed upon that the usability focus is a good one. But going from "we really should do X" to actually doing X more often than not ends up somewhere between XX and XXXX. Not always a sexy sight.

The good

The good thing about usability is that we have a word and a best-practice methodology to give people when we want to point to the bleeding obvious.

For years, fights between opinions have rendered workplaces uninhabitual, seeded split between otherwise solid fractions, and created some of the worst possibly products ever known to man. Now, on the other hand, you can call the designer jerk a jerk by saying he doesn't follow usability guidelines. As everybody knows, if you don't follow the standards then you're a misguided individual indeed, and much shame will come to him who claims the guidelines are wrong.

The bad

The guidelines don't cater for individual needs, but are a set of ... er, guidelines. Not rules. Nothing is cast in stone. They are suggestions to what to do to get a better result.

Everybody knows that rules and laws are a thing of a controlling sadomasochistic governance, and as such, in all places where the opressed can fight back a little opression from the opresser, it will happen. If you don't have to oblige to a law by, say, risking death and burning of your CD collection, then good chances are they won't. Guidelines are treated as Laws Light. Wether the opressed are right or wrong in their interpretation of that law is, of course, irrelevant.

The ugly

People are people. If they don't need to oblige to a law, they won't.

"The button labelled 'persue' is better labelled 'explore'"

"Do we absolutely have to?"

"Uh, no."

"Good. What else on the list?"

A small amount of work

The thing is, most usability issues, unless they scratch the surface of stupidity, are easily solved. It is either the case of a simple change or a massive paradigm shifts; a bit of brevity for the former, and don't work for people who wants to do the latter. It is of course the fear of the total amount of little things when they add up that turns otherwise reasonable people into the zombie killer know as a Choosability Practitioner; they choose what to fix based on what they have to vs. what they should fix. Let's dig into a few examples;

Your usability testing comes back and tell you that tabbed resultsets are a terrible utter disaster, neither perfectly seeing sane people as well as low-vision and complete blind people can't work out, for the life of them, what the hell is going on. Do you;

• Make the tabbed results prettier, or
• Create a clearer list of results?

A Choosability Practitioner would of course go with the first; better to fix what we already have than to rethink our strategy. We are more concerned about it looking pretty in one page without scrolling than providing information that makes sense and has quality context attached.

Here's another; your usability testing comes back and tell you that the main menu bar has options in it that no one uses, not even when asked to do specific things that had to do with those pages; they did things another way that seemed more intuitive to them. Do you;

• Relabel those options, or
• Remove them because the other ways work better?

A Choosability Practitioner would of course go with the first; better to fix what we already have than to rethink our strategy. We are more concerned with functionality than with the simplicity of the user interface. Our customers are special and need all the bells and whistles in the world to do what they want to do. Testing our customers won't change our mind in this important business requirement.

Here's more; your usability testing comes back and tell you that lots of the focus points of your application are too similar for people to tell the difference between them. they couldn't work out the difference between four search interfaces that only hold slight differences to search the same data. Do you;

• Ignore the problem, because it is a business requirement and part of the functional specifications, or
• Work hard to merge the interfaces into one or two simpler and easier to use ones?

A Choosability Practitioner would of course go with the first; better to fix what we already have than to rethink our strategy. Maybe we could relabel things to make it clearer what the differences are? Let's ignore that the testing has clearly and beyond a doubt proved that four entrypoints confuses the hell out of customers; the business owners have clearly stated in our functional specification that there are four ways to search our data.

No more!

I've made my point clear; even if lots of people talk about the use of usability testing and guidelines, they are bloody choosability experts who don't really understand what it is all about. They are buzzword compliant, but not compliant with any usability guideline.

Why have we got processes and methods in place that makes late changes practically impossible? Why do we set up workflows and use project management methodologies that just tacks on 'usability testing' at the end of a development cycle, two weeks before launch? Why? Why?!?!

The buzzword is definitly mightier than the sword.

Permalink (Mon, 29 November 2004 13:00:00 GMT)| Comments (0) | Knowledge and information

Filesystems, taxonomies, ontologies, persistant identifiers and plum pudding

More often than not our information is spread far and wide, it is poorly organised, lacks sensible metadata and is semantically challenging to sift through. So we concuct various centralised and smart solutions to this widespread problem; portals, data-banks, databases, repositories, search engines, agents, wiki's, blogs, and so forth. They have different names and work differently, even serving quite different versions of the paradigm "How to serve information in the best possible way", but they all have at least a few things in common, such as to;

• Centralise the point of access to your information.
• Have as much information as possible for you to access.
• Make that information as relevant as possible to you.

The rest is technology. But first; the problem!

The filesystem and the directory structure

Inspired by the second use case of Thomas Passin's "Explorers Guide to the Semantic Web", here is a simple way to make any directory structure with files in them make a whole lot more sense. It is quite common in intranets for example that you have a wealth of files spread throughout a big directory structure, and then slap some kind of web interface on top to try to make sense of it all. Mostly they fail, and I don't think I have to argue strongly for this; people all over the world talks about this specific problem.

What's wrong with a directory structure, then? Let's assume you have one, and you've got tons of files in it. Let's go out on a limb and even pretend that your structure is, well, structured in a clever way. Let's even be crazy enough to assume that files placed in these directories belong there, that documentation really is in the documentation folder, and so on. Yes, it is an impossibility, I know, but bare with me for a moment.

Exhibit A : the file "//intranet/projects/pro1/docs/specs/specs-v1_2.doc"

Exhibit B : the file "//intranet/projects/pro2/specification-v2_2.rtf"

Exhibit C : the file "//intranet/division/div6/policy/development.doc"

Is there any relationships between these files? If we simply navigate through the structures knowing what we're looking for, then we might get some glimpse of relationships, but most of the time I would claim we don't know. So, let's break the path names down into traditional property values;

A:intranet, A:projects, A:pro1, A:docs, A:specs, A:specs-v1_2, A:doc

B:intranet, B:projects, A:pro2, B:specification-v2-2, B:rtf

C:intranet, C:division, C:div6, C:policy, C:development, C:doc

This gives us some assumed and distant relationships between files, and we already can do simple queries such as "find all files starting with 'spec' in projects", but what we really want to do is to see the close relationships between these files, dig into the semantic values of those relationships to uncover more exact patterns of recognising the meat. Let's take our first step into the world of Knowledge Representation, and create an ontology based on a list of the most frequently used words;

Documentation, specification, policy, division, project

Let's talk a little bit about this. In the world of Knowledge Representation (misguidedly also referred to as Knowledge Management) there is a misnomer that "unique identification of things leads to understanding of what those things are". This thought is what drives people to create ontologies, and the bigger and more complex the ontology, the bigger and better our understanding will apparently become. As an example we point to ourselves, and say "Homo Sapien Sapiens", find this item in our massive ontology and how it relates to other things, and derive some sentiment from this, such that a "Homo Erectus" was a distant ancestor and that I don't think I have many "Homo sexual" tendencies. And so forth.

But this is all a bit misleading, because in the real world these are very different things, namely two biological classes and one sexual preference. Apples and oranges, as they say, but it is even worse than that; it is apples and chapels; Not related, apart from the somewhat similarity in the order and idexes of the characters in those words of the English language. See where does this lead us? Down a very common but misleading path.

We think that similarities in certain things gives semantic similarity in meaning, but it is a false trap. Let's return to our exhibits;

A:intranet, A:projects, A:pro1, A:docs, A:specs, A:specs-v1_2, A:doc

B:intranet, B:projects, A:pro2, B:specification-v2-2, B:rtf

Quick, what are the similarities between these two files? They're on the intranet, they're both under a project, they both have filenames starting with 'spec', and they're both textual documents (doc and rtf). Good, good, but what does that mean? Is that valuable information? In fact, did all this info gain us any knowledge about those files at all that we couldn't have aquired from simply browsing the directory structure?

The first step in understanding something, is to group the similarities. We all know this, so let's do that;

A:intranet, B:intranet, C:intranet = A, B and C are on the intranet

A:projects, B:projects = A and B are in a project

A:specs-v1_2, B:specification-v2-2 = A and B might be specifications

A:doc, C:doc = A and C are documents, possibly B

These words are typically what we want to put in our ontology. Let's go back to it;

Documentation, specification, policy, division, project

Yes, this makes sense; we can now start matching some stuff up, because we live in a perfect world where people do the perfect thing? Before I answer that silly self-referetial question, let's have a look at the group for all things mismatched;

A:pro1, A:docs, A:specs, A:pro2, B:rtf, C:division, C:div6, C:policy, C:development

Getting some form of taxonomical "knowledge" from the grouped list is easy enough, and works well for visual humans browsing through lists like this. This is the primary way Knowledge Systems today work. Meaning, they're not really there to understand or interpret or otherwise push us on our way; they're simply systems for indexing and sorting and displaying things, hopefully in the best given way considering we're doing the pulling.

A few problems to consider, though; what if something is a 'project' instead of 'projects' (note the plural), or if someone writes 'spesification' instead of 'specification' (note the spelling mistake), or maybe they're Norwegian and writes 'spesifikasjon', and maybe they thought the specs are more related to the 'systems' folder, put it there, and called it 'systems_spec_001'? What if? What if?

Yes, we can create a humongous ontology to cater for all these things. Is that maintainable? Hell no.

First stab at the ontology

So, let's talk about that second ungrouped list, then. That's where the interesting things show up, because - and this may come as a shock to some people - we humans don't always put things were they belong, name them the best possible way or otherwise give hints to what they might be. We get things like 'pro1'. What the heck is that?

Now, this is where a dictionary / thesaurus / ontology sometimes is handy. We look up 'pro1' in our 'Corporate Ontology' (a magical system, indeed), and find out that it is designated to the following;

• The project "FIB"
• The software application that runs our finances
• The nickname for Andy

In our grouped list, one of the keywords (which they shall be know by from now on) were 'project', so we could place a rather safe bet on our first option. Seems trivial enough, doesn't it? We can create simple systems that traverse structures and match exploded keywords with items from a dictionary or thesaurus. Perfect.

But hang on; what if option 1 and 2 were the same? Or what if Andy was the name of a project and not some person? At this stage, we simply don't know, but it doesn't take too many of such false assumptions to render our "knowledge system" useless. The dictionary or the thesaurus must be totally clear about what they are describing. A word or an explanation means nothing to a sorting computer, and it is obvious that we need something more.

Um, that means you. The person. You assign the metadata 'project' to the file in question. This is obviously not going to happen to a filesystem with hundred of thousands of files. We need better means of matching resources (the files in our filesystem) with our ontology.

"Ah! I know! Uh, uh, pick me! Pick me!"

Yes, you in the back ... ? Using Persistant Identifiers as a means to make sure that we're talking about the absolute and specific same things in our ontologies? Well, yes, you obviously didn't read the beginning of this article, but I'll recap; Persistant Identifiers are fine and well in a closed environment where you can control all meassures, including the ontology, your users, your stakeholders, your objects and the things addressing it, the weather, the pitch of a perfect A (440Hz, no less) and a host of other measures.

There is a thick grey fog between your ontology and your data which cannot be expressed easily; knowledge. Because even when you - as a person sitting in front of the computer - know what bits belong to what part of the ontology, the computer has no idea. None. Zilch. Our quest for a "knowledge system" needs more than the tools we've discussed; The data itself, the ontology, a dictionary or a thesaurus, and persistant identifiers together can form quite good systems of course, and if you want a somewhat complex categorisation system, it's perfect. But it still has nothing to do with knowledge. You or someone - as a person - have to provide this.

Knowledge Representation

We need some piece of information to represent something, so that when I talk about my mum's plum pudding, I don't mean the one you find down the supermarket, but my mum's. Not as easy as it sounds.

First of all, who am I? We need some kind of representation for the object which is me. Let's create one;

https://shelter.nu

That's my homepage, so is that a good representation? Nah, not really, because there is more to my homepage than just 'me' (whatever that might be). Let's try to be a bit more specific;

https://shelter.nu/people/alexander.johannesen

Is this a piece of information we can safely use to pinpoint we're talking about 'me'? Well, it is good for a lot of purposes, but in this everchanging world we can't be too sure if;

• Is there only one Alexander Johannesen in the world right now?
• Will there only be one Alexander Johannesen in the world, in the past, now and in the future?

And once we've solved that;

• Will https://shelter.nu/people ever mention any other Alexander Johannesen's than this one we're trying to define?

Here we have the problem of a) identifying one single instance of something, and b) authentication and validity of the pointer to that identity. And to find the right plum pudding we need to go through this exercise with me, my mum and the plum pudding. There is an indentity crisis abound.

Identification

More and more people are heading the ways of trying to establish a set of rules to identity instead of the classic persistant identifier route. Here's a rule;

If person name is 'Alexander Johannesen', born in Norway, born in 1971AD, married to 'Julie Anne Johannesen', lives in 'Canberra, Australia' in the year '2004' using the 'AnnoDomine' system.

We're getting a bit closer. Genealogists have this down pat. But there is a problem, and that is that there's more to the world than people, and we're not really all that great at tracking this kind of metadata for things not a person. We have newspapers and books with editions and dates and authors, and this can be tracked fairly well, but what about our project documentation? Umm, yes, the stuff we really need to know now just before the board meeting is somewhere out there, and no one bothered to give a lot of metadata info about that file. Where is that fabled Knowledge Management system when we need it?

If we need to create persistant identifiers to all things, then that's all that we'll have time doing, because there is context that also needs persistant identifiers that map our project specification; people writing it, people who edit it, the people who thought of it, the resources needed to do it, the hours spent doing it, the picture that explains the concept of it, the graph that tells us the validity of it, the speech held my Mr. Dawson about why it's a bad idea, his collagues who agrees with him, and - of course - the black-list of people who disagree. And we need to map the conventions, such as editing the specs, writing the specs, agreeing to them, promote them, and so forth. And then we need corporate associations, such as DL3 is a higher position than a AB2, James is a curator, DL3, project manager and a promoter of things, the elevators are in the B section of the 3rd departement, and the toilets are bloody out of order!. Sigh. There is this, and so much much more.

Some practical thoughts

Surely some middle ground can be made. Surely using a bit of this and a bit of that is good enough to locate my mums plum pudding well enough for general use? Do we really need to map everything in the universe to make some small assumed guesses work? Of course not; there are thousands of systems doing that already. Assumption is the next black, you know, so let's get back to our examples and perform a little black art.

We've identified (pardon the pun) that the stuff we're interested in doing extra stuff with is this;

A:pro1, A:docs, A:specs, A:pro2, B:rtf, C:division, C:div6, C:policy, C:development

A simple and time-consuming solution to this is to assign some graduate student to add every single instance to our ontology, ask some weighted question to senior staff, and put the aquired "knowledge" into the ontology as well. Maybe this will work for you, but if you've got more than 5 people in your organisation, I'd suggest you look to other solutions.

Here's a few things we can do to squeeze a little more out of our ungrouped list;

• A list of all projects you know of that we might talk about; pro1, pro2, FImlBLE, whatever they are called. Make sure the list never changes. For persistance, use a thesauri and update the "use instead" links as you go.
• A list of all people you know that we might talk about. Make sure this list never changes either, see above. If people quit it doesn't mean the document they wrote magically disappears too.
• If you have a search engine, compare the list of "searched for words" against our ungrouped list. There might be hints there to what things need to be addressed.

Within the scope of this entry, there isn't too much more to do. We need a graduate student for sure. But, if you were to pursue a better tomorrow to enjoy my mums one and only true plum pudding, here's a few hints to how you can do Knowledge Representation that tad bit better;

• Don't underestimate the human interfaces to your systems. Use more resources on usability testing than on flashy designer. The simpler the system is to use, the simpler it will be for people to add value to it.

That rule needs a line on its own, to give it some air and a pause to ponder. Read it five times, think seriously about it, and then read on;

• First, create a filesystem harvester that can create simple ontologies.
• Add a processing ontology to your framework, and use resource metadata extracting tools to get more data.
• Never create specialist solutions! Never ever! Ever! Generalize your framework to cater for absolutely everything.
• Design plugin architectures in every system you have, so that importing and exporting of metadata is there.
• Install Google. 'Nough said.

In my next followup to this, I'll present a simple filesystem harvester that can create simple ontologies, ready to be downloaded. Stay tuned.

Permalink (Wed, 10 November 2004 13:00:00 GMT)| Comments (0) | Knowledge and information

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.

Permalink (Fri, 22 September 2004 13:00:00 GMT)| Comments (2) | Opinions Topic maps Knowledge and information

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.

Permalink (Tue, 10 August 2004 13:00:00 GMT)| Comments (5) | Topic maps Knowledge and information

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.

Permalink (Wed, 21 July 2004 13:00:00 GMT)| Comments (3) | Knowledge and information General Topic maps Programming

In two previous chapters I've been digging into human cognition and categorisation, and what have I learned? Quite a lot. This is fascinating stuff, learning about how we humans think, symbolise, deduct and infere from sometimes very vague notions. The most important lesson learnt was that the intuitive feelings I had about the way we categorise was pretty darn on the money.

The Prototype theory is what it is all about, where "something" is a better example of a category than others. Here's an example;

Category : Bachelor

• Example 1 : Young, hetrosexual man having multiple partners, can't settle down, likes to party, always out
• Example 2 : Old, homosexual man having no partners, looking for someone to settle down with, likes to read a lot, always at home

Both are bachelors, but example 1 is a more prototypical bachelor; he's more "bachelor" than example 2, yet they're both perfect examples of what fits into the "bachelor" category. Now, this is important because they are equal members of the category.

Next up is the example of semantic constructured categories, like "working mother";

Category : Working mother

• Example 1 : Married woman with a kid, who works during daytime
• Example 2 : Surrogate mother who doesn't have any kids herself, who works during daytime

They are both "working mothers" by technical terms, but not by semantic standards. A surrogate mother has no responsibility of a child, yet has had a child and works. This is important because they show differences between semantic and technical attributes.

Next is basic category, which is a category that is a non-constructed category;

Category : Chairs

• In the category "chairs" we find items that we can imagine, that we have some basic visual and physical representation we can use. This is probably the category we start out by describing.

Category : Furniture

• The category "furniture" is a construct; there is no single visual or physical representation for it (just try to imagine one single item that stands as a symbol for all types of furniture!) It is higher up the ladder from chair, so we call it a constructed higher category.

Category : Swivel chair

• It is a chair that doesn't hold the prototypical attributes of "chair", meaning a specialisation of "chair" that does not work in a strict taxonomy; some of these chairs don't even have four legs to stand on, is seldom made from wood (which is a prototypical attribute) and so on. These are lower categories, and are important because they alter prototypical attributes, proving that strict taxonomies doesn't bloody work.

Next, I've learned that our physicqe is an important part of categorisation, that our bodies are part of what makes them work. In my example above with furniture and chairs, the two chairs are called so not by appearance, but by bodily function. We may think it is about functionality, but let's whiff off some more examples of this;

Category : Glasses

• Let's quickly look at glasses compared to sun glasses; they're both glasses, but serve two different functions. We could add weldering glasses and swimming glasses to it too; it is about a bodily interaction more than it's about actual functionality.

Next up is the link between our language, our culture and categories. Lakoff dives into an Australian aboriginee language which - as the title of his book - puts "women", "fire" and "dangerous things" into the same category; it is cultural constructs, since the moon in Aboriginee mythology is a male, married to the female sun, who is hot and dangerous. The same with most birds are in the "female" category, while a handful of birds are in the "male" category; all birds are in Aboriginee mythology "old ladies", spirits of the dead, except some birds who are thought to be male spirits, hence birds of certain types gets placed in the "male" category. Confusing maybe to our western way of thinking, but perfectly natural to them. Their basic system of belief runs the categorisation, and this is important because traditional category theory makes the stand that categorisation is a universal construct of language. it is not.

Oh, and I've learned about different congitive models, where a "model" is a set of structured ideas that form category thought. For instance, our brain is a really good inference machine that can infer quite correctly from a very loose set of data; the cognitive models help us in "filling out the blanks" in such a way that we can make sense of it. Many belive that our imagination, even our gullibility, is there to help us to gain correct information where the sources we can use for this is lacking.

Anyways, I've got a new set of books to read that follows naturally from "Women, fire and dangerous things" by Lakoff (which comes highly recomended!), and I'll report back here with my ongoing waffle installments.

Permalink (Fri, 16 July 2004 13:00:00 GMT)| Comments (0) | Knowledge and information

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.

Permalink (Mon, 21 June 2004 13:00:00 GMT)| Comments (1) | Topic maps Knowledge and information

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.

Permalink (Mon, 3 May 2004 13:00:00 GMT)| Comments (18) | Knowledge and information Topic maps

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!

Permalink (Tue, 20 Apr 2004 13:00:00 GMT)| Comments (4) | Knowledge and information Topic maps

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.

Permalink (Mon, 5 Apr 2004 13:00:00 GMT)| Comments (0) | Knowledge and information Topic maps

|/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.

Permalink (Wed, 25 Jun 2003 13:00:00 GMT)| Comments (3) | General Topic maps Knowledge and information

Again, clever boy James Robertson of Column Two has produced an excelent whitepaper called Where is the knowledge in a CMS? outlining where the actual knowledge resides in a Content management system.

Also, from the announcement, he points to two related articles;

Losing sight of the content in a CMS

Why spend millions on managing content that no-one understands or needs? This article provides tips for getting the best value out of your business content.

Using usability to direct KM systems

KM has much to learn from usability, which can provide many useful starting points for structuring and managing KM projects.

This is all interesting stuff, and one that really inspires my current research for creating a Topic maps based content management system; when people add or edit information, where in the CM system are these changes reflected? In James' whitepaper I find that the approach of the CM system is pretty traditional, which I also think is the purpose of it, so while not adding to a revolution in how Knowledge management is or should be done, it certainly points us in important directions.

Permalink (Mon, 5 May 2003 13:00:00 GMT)| Comments (0) | Content management Knowledge management Knowledge and information

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.

Permalink (Fri, 4 Apr 2003 13:00:00 GMT)| Comments (0) | Topic maps Knowledge management Knowledge and information

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.

Permalink (Wed, 19 Mar 2003 13:00:00 GMT)| Comments (0) | Topic maps Content management Knowledge and information

I snapped up this excelent article through Column Two;

Making a Taxonomy for your company or area of expertise can be very political. The way information is organized helps define the information.

Permalink (Mon, 17 Mar 2003 13:00:00 GMT)| Comments (0) | Knowledge management Knowledge and information Information architecture