Fun with Hubjects

What happens when you are standing in the shower at oh-dark-thirty in the morning and you start thinking about hubjects? It goes like this.

A hubject is the result a phonetic accident when two memes, subject and hub, have a translocation error performed on them. This accident is part of what we now call directed evolution. By contrast, the philadelphia chromosome, known to be behind several cancers, the most prominent being chronic myelogenous leukemia, is a translocation error, not thought to be directed, between chromosomes 9 and 22. That error splices part of 9 with part of 22 into the famous BCR-ABL splice, characteristically referred to as "ph+" (because it was the first cancer gene discovered -- in Philadelphia -- following Watson&Crick). But, there remains the other parts which did not become famous, but which also get together. A dissertation at UCLA showed that object to be benign.

So, what's that got to do with hubjects? That's what hits when you've got soap in your eyes. In America, we have this whole thing about suburbs. Stay with me here; don't try to guess where this is going. We speak of living in the 'burbs. Could we say that a SubjectProxy (aka: Topic) living in a topic map is, um..., living in the 'bubs? Only if we had a different phonetic accident on the same memes and came up with, brace yourself, sububs.

You know, we can do that. Language is the longest running open source project in the entire universe. We can make up names for things till the cows come home, and beyond. At the core, however, the identity of the subject remains the same. Go figure.

We Are the Web

Jack pointed this to me, certainly to temper the mood in my previous post. Not sure we wanted that, but certainly it's happening.
What will most surprise us is how dependent we will be on what the Machine knows - about us and about what we want to know. We already find it easier to Google something a second or third time rather than remember it ourselves. The more we teach this megacomputer, the more it will assume responsibility for our knowing. It will become our memory. Then it will become our identity. In 2015 many people, when divorced from the Machine, won't feel like themselves - as if they'd had a lobotomy.


Seeking sustainable IT (not yet desperately, but still ...)

Underlying recent debates I've been involved here and there was a similar question : "Who cares about yet another language specification?". I found myself answering quite at the same time "Yes, please" on one side, and "No, thanks" on the other. And in this latter case, I was striken by a remark from Jim Mason - whose background in standard matters makes me always consider very carefully whatever he brings.
Let's face it. We're building these things for ourselves, and they're proliferating because we have fun doing it.
And any sofware vendor or consultant around could have added : " ... and because we hope to sell more technology build on top of it."
It made me wonder about the relevancy of some of the implicit assumptions which pushed me into Knowledge Engineering quite a while ago, and which I explicited at some point in a nutshell as : "Knowledge is sustainable information". Information is consumable and volatile, will be tomorrow at best redundant, at worst obsolete. By opposition, knowledge is supposed to be sustainable and building up with time. The more knowledge you have already gathered, the more you are likely to transform new information into more knowledge. So I envisioned "Knowledge Technologies" (KT) as another name for "Sustainable IT", along the lines of the European IST program spirit : "From Information Society to Knowledge Society". All of it was supported by my background, which made me consider Maths as the most impressive accumulation of (sustainable) knowledge ever, after natural languages of course.
Right opposite to this cumulative and patient build-up of knowledge we see in Maths and Science, proliferation of technology for the sake of it is clearly anything but sustainable. And actually, the current trend in which languages, software and hardware are all tied up in technological packages leads to this annoying conclusion that languages and specifications are bound to follow the same kind of "product life cycle" logic than their supporting software and harware. If Knowledge Technologies keep up following such a track, they clearly more belong to the technology-for-the-sake-of-it market logic than to sustainable knowledge building.
A very pernicious trend indeed, for many obvious reasons. Beyond the sheer issues of managing semantic interoperability between current, past and future languages and formats, lost of critical knowledge and data embedded in obsolete formats (see e.g. the Pionneer Anomaly), there are the human aspects of it : playing with a language is always more or less formatting your way of thinking. Dealing with too many different languages is difficult and confusing. Concepts are embedded in their representations, so considering language product life cycle means also considering concept life cycle. Not a very pleasant perspective.
I'm not sure what the requirements for sustainable IT would be. But surely one on them would be considering concepts the same way as life forms, with their needed diversity, fragility, and need for care.


Mission 2007

This is maybe the most important KM project around. Objective is the creation of Knowlege Centers in each one of over 600,000 villages in India by 2007.
From the mission page :
What is now needed is the launching of a self-propelling, self-replicating and self-sustaining model of ICT for rural regeneration and prosperity [...] The term “knowledge center” was chosen because at the village level there is need for value addition to generic information by converting it into local-specific knowledge [...] The Mission will be top-down in its approach to technological connectivity, but bottom-up in relation to content and knowledge management.
Watch this space ...


News Metadata Framework Technical Specification

News is a critical test-bed for identification and categorization issues. This draft delivered by the International Press Telecommunications Council is really worth a look.

What is a document?

Just discovered the excellent Kevin Clarke's Worklog.
"What is a document" is a quite long and thoughtful entry (this blog is very verbose, many entries look like full papers), certainly relevant to recent debates about "information resource" vs "other resource", and more subtle than the recent resolution of httpRange-14 issue.


Ambiguity and imprecision

I jumped on this thread on Forthcoming blog, after a similar exchange with TMRM folks on the same subject of ambiguity. It is deep down in the comments, so here is the quote.

I think there is two ways to consider ambiguity :

Way 1. Subjects are ill-defined, everything is fuzzy, nothing can be asserted for sure.
Way 2. Subjects are well defined, but in many ways, as so many views in/from different frameworks/perspectives.

Way 1 is good for unformal and cheerful conversation, like the one you used to have in forums, and now blogs, RSS, tagging and the like. But it is IMO pernicious : people either think they agree, though they speak passed each other, or the other way round think they disagree because they have no way to figure if they actually have different viewpoints, or if they speak about different things. Billions of examples available everyday.

Way 2 is what TMRM and hubjects are about : subjects are ambiguous, contradictory, fuzzy, moving targets, OK. But each view on a subject has better be well defined, and the rules for this definition explicit (perspective disclosed). You know your view is not exhausting the subject, you can explore different views, see if their logics are compatible, if they can play nicely with each other or are too orthogonal for that etc ... So you can agree that you agree or disagree on clear grounds, and go to war if needed, but with crystal clear reasons.