A journey to Data Mountains

Seems about time to revisit a famous Zen aphorism (more verbose translation here)

Morning mountains, only mountains

Noon mountains, more than mountains

Evening mountains, simply mountains

How does this apply to what we have been speaking about here? We've tried in the morning of our ignorance to pile up mountains of data, and had hard time making sense of them.

In the broad daylight of our powerful abstract thought, both intuition and logic, we found out that useful data were data about some thing(s). Making explicit the things data are about was really the way to follow to organize, understand, search, query, in a thousand ways make data more useful, more meaningful. So we went through those mountains with this "about-ness" in mind, and they looked indeed more than mountains, they looked like information about things. We called it classes, properties, relations, and started re-engineering data in all sorts of smart ways : metadata, RDF, topic maps, ontologies and the like. Happy to bring more and more meaning into data, we called it knowledge, and we thought we had found answers to some fundamental questions, discovered the information lost in data, and the knowledge lost in information. Captured the mountain's spirit.

Then came the time to harvest, to weave it all together. I had knowledge in my information system, and so did you. Or so we figured. But looking into your system, I found only data, and so did you when you looked into mine. Where are the things gone? Where is the knowledge hidden? Only data, which we had to figure again together how to weave.

So we'd not captured the mountain's spirit after all. But we did not travel in vain, because we've felt it blowing by. We know it's hidden somewhere beyond the data, beyond information, beyond what we have called knowledge, and that without this spirit our data would be completely meaningless and useless indeed. And what is more, we have at least found a piece of wisdom lost in knowledge : data are only data.

A bit of Chinese

I've been dreaming about learning a bit more of Chinese than the few characters I've been playing with ever since I discovered the excellent introduction by Kyril Ryjik's "L'Idiot Chinois", around 1980 or so (this book is unfortunately sold out now). I've decided that now is the time to learn Chinese, for all sorts of obvious reasons. Hence the extract of the original Chinese text of the now famous "wheel and hub" quote in this page. If your browser does not support Chinese characters, you should do something about it right away.
I've tried to come out with my own translation. Note that I got rid of any capitalization, because Chinese has no notion of Absolute Capital Things. The concepts represented by Chinese characters are most of the time both concrete and abstract, generic and specific. No definite or indefinite articles, no clear distinction between grammatical nature and function. Depending on the context, the same character may be translated as a noun, a verb, or adjective.
In a way, Chinese characters are by nature ... hubjects.

Adieu to Published Subjects

I've learnt those days that the OASIS Published Subjects Technical Committee, which I've chaired for two years from its foundation in August 2001, was closed. Actually it was officialy closed by OASIS in November 2006, but I had not received any notification from anyone. Sounds like learning the death of an old friend months after.
Actually the activity of the TC was dormant since the publication of its first and somehow unique deliverable Published Subjects: Introduction and Basic Requirements. This output does not seem much after two years of work, but it figures there was not much more we could achieve. In a recent private exchange about the future of Published Subjects, Patrick Durusau, who chaired also this TC after 2003, still wants to believe that it is not the end of it, that the work has stalled mainly by lack of task force, but maybe anyway this TC was a case of premature specification.

I think that the notion of a published "identification" of a subject, whatever you want to call it, is probably a good idea, so long as anyone can add their identification of the same subject. On the other hand, a notion that this *is* the identification of a subject, well, that leads to losing propositions like the stuff you find at Swoogle. How many different identifications of person are there?

I already set this question here two years ago. Amazingly enough, the figures does not seem to have changed since (399 answers by today).
I take the opportunity to point to this paper by Patrick. If you have not figured out what a subject can be, even after an extensive reading of this blog (or don't care going into so much reading) this is a must. Short, clear and to the point.

Linking Open Data

This is a challenging project for Semantic Web technologies. Weaving together open public data, such as Wikipedia or Geonames, and public ontologies and vocabularies such as Wordnet, etc. Of course I had to be involved in that. But consensus will be hard to achieve. Initiators are folks from Leipzig and Berlin universities, involved in dbpedia, a project to RDF-ize Wikipedia content.

I've pushed the idea that linking concepts from different schemes should not be done on the basis of too strong ontological commitment, but of some kind of loose coupling using e.g., SKOS mapping vocabulary, and why not blank concepts. This proposal has not been well received, to say the least.

Chris Bizer says:

I'm in general against using bnodes for anything! They should be deleted from the RDF spec and they are especially harmful in a linked data context, where everything should be dereferencable.

And Richard Cyganiak adds:

Yes, sure ... I understand why you want to introduce the blank node. But I don't like it. Why do you generate data? You want it to be useful. How does this blank node increase its usefulness? It doesn't. It's just a fig leaf to cover up the fact that your model is just an approximation of the real world. But we know this. Every model is. And these "semantic rubber bands" don't change this fact -- they just make your data harder to work with. Be bold! People who want to re-use your data will learn to work around its quirks and idiosyncrasies. Dealing with the quirks is a part of re-using data, it always was, and it always will be.

So much for my hubjects ... but this is not the end of it. More to come.

Changing blog title

I know, changing names, like changing URIs, is a silly idea. Cool names never change. But I decided yesterday to re-activate the original univers immedia in French. And since 'The wheel and the hub' has definitely been for a while and certainly will continue to be, the motto of this blog, it had to make its way up to the title.

Every subject is a blank node

Two discussion threads made me move a step forward towards a general theory of blank nodes. One thread I already mentioned is about languages. The other one was started here by John Black on Semantic Web list, about representation of concepts having contextual semantics, such as "I', "You", "Here" etc. Using a blank node to represent the context is the solution I propose today here.

Classifying is hard, tagging is worse

My work for Mondeca has been for years to help building classification schemes, ontologies and the like for a variety of customers. Most of the time this means formalization of implicit ontologies they already have in their data. And I don't have either to make any decision about actually populating the schemes, this task is left to human editors or automatic text mining engines. I sometimes take care of automatic migration of legacy content, but following rules decided with the customer. I'm very happy with all that, because I'm not good at classification. I tend to see so many subjects in anything, any interesting resource to classify seems so multi-dimensional that choosing a category always brings me to the fringe of undecision, and any decision I eventually make about it seems always arbitrary. Comes maybe from an ancient traumatic experience as Open Directory editor.

Sounds familiar? I already hear the folksonomy people crying : "Hey, of course, that's why tagging is so cool". As far as I am concerned, tagging is worse, it means more arbitrary decisions, because not only do I have to choose a category, I can choose more that one, or none at all, and I have to figure them myself. Way too many decisions ... That's why my browser bookmarks and email folders are a mess, why I have no del.icio.us account, why my Technorati profile is so low, etc ...

Beyond my own decision difficulties, there is something to be added as this now long discussion obout ontologies vs tagging. What I've learnt in science is that a good theory is a falsifiable one. What you assert using an ontology, whatever language or framework with declared formal semantics, is falsifiable. No formal semantics, no notion of true and false, hence no falsifiability. In other words, and to make it simple, an RDF assertion can be declared or inferred true or false vs a given ontology, a OWL class can be proven unsatisfiable etc. Nothing of the like with tags. Assignation of a tag cannot be proven true or false, or inconsistent. Tags are not falsifiable.
By the way, the same distinction is to be made for RDF vs Topic Maps. Topic Maps are not falsifiable, because they have no formal semantics. Now the question is to know is falsifiability, which has been proven to be critical in science, is also critical in information technologies.

That said, since the new Blogger version enables easy tagging (maybe the older version did also, but was never aware of it), and since there is now quite a bunch of posts on univers immedia, I decided to be brave and start tagging them, as thoughtlessly as possible. Starting by the more recent ones, I then shifted to the most ancient, a good occasion to revisit them if nothing else. The result you see on the left under "What". First impression is of course there are too many of them, but I will try to keep up that way throughout the blog just to see how it flies, then maybe keep only the most frequent ones if I end up with a too long list.