Well, this won't solve the folksonomy argument, but it is a useful tool. Here's to the power of web service APIs.
« December 2004 | Main | February 2005 »
Well, this won't solve the folksonomy argument, but it is a useful tool. Here's to the power of web service APIs.
January 31, 2005 in Knowledge Management | Permalink | Comments (0) | TrackBack (0)
Ben Lund suggests that tags and folksonomies can be seen in a Darwinian light. A nice idea.
The four pre-requisites for a Darwinian process are Reproduction, Variation, Inheritance and Selection. Let's say our individuals are tags and our species is a folksonomy:
- Reproduction: Certainly. New tags are created with almost every entry, be that bookmark, article, or photo.
- Variation: Absolutely.
- Inheritance: Probably. When I copy a bookmark, I often copy the tags too.
- Selection: Yep. 'Edit tag' was the first feature requested after we launched Connotea.
I think there's some mileage in this idea, but I'm not sure that individual=tag, species=folksonomy works perfectly. Then again, it's an analogy, let's not get too worked up about it. More importantly, "edit tag" isn't enough on the selection front. Tags need to die on a large scale, and that isn't happening. Nor is it obvious how it can happen without things that were tagged no longer being tagged, or old tags being ignored, which seems to lose too much value.
January 29, 2005 in Knowledge Management | Permalink | Comments (0) | TrackBack (0)
Let's try again.
Shelley Powers has written a good summary of some arguments about the relative merits of tagging and more formal metadata. Nice pics, too.
Shelley is worried that the rise of "cheap" metadata, in particular tags, will inhibit development of tools to make "real" metadata available to the masses.
Theory: the value of terms in any metadata system used in an uncontrolled way tends to zero with time.
That's just as true for rich, formal so-called “ontologies” as it is for tag soup. There is a difference, however. Tags don't lie about their status. We know, right off, that they're just terms which people have attached to things, for some reason. We know that we don't know what sense the term is meant in, of the undoubtedly many possible. We know that we don't know the intention of the tagger in tagging. The spam problem arises from this: spammers are applying tags in order that pictures show up in certain places, not because they think those tags are relevant. The business of tagging flickr photos with the "offensive" tag is another case in point, where the intention is now to stop items showing up in certain places, and really has nothing to do with offensiveness.
Problematic, perhaps, but not unique to tagging. Exactly the same is true of uncontrolled use of any classification system, however good the tools are which provide access to it. Things will be tagged in a way which is inconsistent with the intended use of any system, either through ignorance or intent.
The rel="nofollow" tag which Google has announced it will use to control the inclusion of links in its PageRank calculations is indeed a nice demonstrator of an important point here. It's meaning is very well defined: it is grounded not in human understanding, but in machine behaviour. Nofollow can't be spammed: either Google honours it, or they don't. The web now has a mechanism for systematically witholding page rank. What it does with it is out of Google's control.
Point is, that some terms have meaning in this, mechanical way, like those which make up a programming language. Others have meaning in a fluid, human way. The latter will always be as fluid as they are human; no fancy tools will change that.
Fancy tools to make use of formal taxonomies easier would be great, of course. Very useful for those who care enough to put in the effort to understand, and make sure they stick to, the formal intended meanings of terms. But however easy that is made, it will always be hard, and people will always get it wrong. And as people get it wrong, the extensional definition of the term becomes less precise, and the value of the term tends to zero. You might slow the process down, but you can't, simply can't, stop it.
And, of course, because the effort involved in understanding and carefully applying the terms of a formal taxonomy is relatively high — independently of tools, which can reduce the accidental difficulties but cannot attack the essence — it is just not useful in the sort of "fire and forget" systems like del.icio.us, where any effort is too much.
In the comments to Shelley's post, Nick Sweeney writes:
I’m a bit of a Saussurean about this, in that I think that taxonomy (or ontology, depending upon your disciplinary point of origin) is crystallised/calcified folksonomy. Authorised folksonomy, if you like.
Right on! Those two terms, “crystallised” and “calcified” are a really useful duo. The one has connotations of order, beauty, and value. The other of dull rigidity. Well designed formal taxonomies have the first of those in abundance. Both have the second, and you can't avoid it. A taxonomy can only ever be an encoding of one incomplete and imperfect view of the world.
Shelley:
I agree with Clay that the semantic web is going to be built ‘by the people’, but it won’t be built on chaos. In other words, 100 monkeys typing long enough will NOT write Shakespeare; nor will a 100 million people randomly forming associations create the semantic web.
100 monkeys indeed will not write Shakespeare, but 100 Shakespeares didn't write Shakespeare either. Shakespeare did. The situation we have is that of 100 million people (or, at any rate, some large and growing number) who need tools to organise stuff, and to help them find stuff. 100 million people who will go right on randomly forming associations, whether the results pretend to be anything other than randomly formed associations or not.
We're dealing here not with the formal space of so-called ontologies and logic, but with the messy, human space of language and meaning. The processes involved are, essentially social. Tools which deny this will fail.
Shelley:
Clay believes that ultimately ontologies will fall to folkonomies, as the latter gain rapid acceptance because of their low cost and ease of use; I believe that ultimately interest in folksonomies will go the way of most memes, in that they’re fun to play with, but eventually we want something that won’t splinter, crack, and stumble the very first day it’s released.
When you design a building to ride out earthquakes with minimal damage, you build in flexibility. Of course, the clever part is in deciding where and how to build in that flexibility. Tagging provids an abundance of flexibility, so much that the building can barely stand up.
But in some ways it works. Delicious is already very useful, on an individual basis, and has some use at a social scale. I follow what other people post about Lisp, Scheme, and Smalltalk for example. These are well defined terms, referring to programming languages rather than highly ambiguous and mis- or differently interpretable concepts. With less well defined concepts, the problems lie as much in the nature of the concepts as in the tagging approach.
Simply aggregating tags a la Technorati as it stands doesn't show a great deal of promise, but it is possible to envisage tools which show tag clouds and, by presenting these to the user, encourage convergence around particular tags. The results will never be complete, never perfect, but always changing, and sometimes useful.
When you have a Web-load of people, things happen from the bottom up. That's the way the Web works.
January 29, 2005 in Knowledge Management, RDF, Web/Tech, Weblogs | Permalink | Comments (0) | TrackBack (0)
Damn. Firefox ate my homework. I'd just spent some (too much) time commenting on the debate about taxonomies versus folksonomies, particularly as summarised by Shelley Powers, when it crashed, taking my efforts with it.
It crashes quite a lot, really, often after freezing up for a while. If I switch to a different application then switch back, particularly to a page with text fields in a form, it often takes a while to update and come back to life, and sometimes dies before it does so.
I guess I'd better just get used to using a desktop client rather than the TypePad web form to post. Another app to fiddle with proxy settings for depending on whether I'm at home or at work. Rats.
January 29, 2005 in Knowledge Management | Permalink | Comments (0) | TrackBack (0)
January 27, 2005 in Current Affairs, Web/Tech | Permalink | Comments (0) | TrackBack (0)
Blogs matter because they have a URL. They have a permanent web address. So often on the Internet, or in technology, but particularly on the Internet because of the social effects, a little tiny thing makes a huge difference. So this is a little thing, that weblogs have a permanent web address, because what that does for them is give them permanence, so we can keep going back to them and learn about the person.
The importance of the humble URI has been coming up on and off recently. The quote above is from an after dinner speech Dave Weinberger did at the Blogging, Journalism & Credibility conference, which I had a listen to on my walk home (the walk home's too short — I had to listen to the end while I was making a cup of tea and some toast). In a discussion on the geo-reasoning mailing list, I commented regarding RDF that,
This could have been avoided if the TimBL and co had adopted a well establish knowledge representation language and "webified" it by using URIs for terms, rather than starting over.
To which Malcolm McClure replied,
I think that hypertext links, etc are very much a secondary issue, …
Aaargh. No! URIs — for all their faults — are very much the primary issue. And then there are all those broken web sites. The UK notional rail enquiries site has much more pressing problems to address (it's just broken) but if it worked at all it would still be a nuisance that you can't bookmark a train. Sure, it'd take some thought to work out how to encode a journey in a URI, but it'd be well worth the effort in the usability increase. How do we get this message over: if it doesn't have a URI, it's not on the web. If it matters, give it a URI.
Update (2005-02-01 (Oh heavens, it's February already!)): Make them nice URIs as well, of course. It's not hard. I found ISAPIrewrite, which has a free limited version, when we were sorting out the School's web site to fix this very problem recently. Apache does full regex-based rewriting out of the box, of course.
January 26, 2005 in Web/Tech | Permalink | Comments (0) | TrackBack (0)
I'm horrified that I hadn't come across these concept/terms before. From the Free On-Line Dictionary of Computing:
Heisenbug: (From Heisenberg's Uncertainty Principle in quantum physics) A bug that disappears or alters its behaviour when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code, such as that which relies on the values of uninitialised memory, behaves quite differently.)
Schroedinbug: (MIT, from the Schroedinger's Cat thought-experiment in quantum physics) A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though (like bit rot) this sounds impossible, it happens; some programs have harboured latent schroedinbugs for years.
Follow the links for more related terms.
January 16, 2005 in Funny, Programming | Permalink | Comments (0) | TrackBack (0)
We've had no hot water for a while. It took us some time to get round to contacting the letting agent about it -- the shower is electric, which made it less than essential, and we kept forgetting to call during the day. They had someone round here minutes after I spoke to them today, which is better service than I was expecting (credit where it's due) since we're still waiting for them to fulfill promises made before we moved in.
The problem was an airlocked radiator in the hot water tank, but chasing it out involved doing something (I wasn't paying much attention) with the header tank in the attic. Opening the hatch revealed what you see in the photograph (click for a larger version).
Stroke of luck the heating broke, really. And that it hasn't rained since the storms!
January 15, 2005 | Permalink | Comments (0) | TrackBack (0)
A nice line:
Hierarchies. Cannot think within them. Cannot think without them.
Arthur Koestler in "The Ghost in the Machine" (amazon.com, amazon.co.uk) talks about arborisation and reticulation as complementary. Hierarchical structuring is powerful, but a closed hierarchy is restrictive. The leaves of the hierarchy (at least) must connect with those of other hierarchies to form powerful structures.
I think Koestler's insight provides quite a conceptual leg-up when thinking about the composition of system representations ("models") with which to drive simulations. Considered as gross components, subsystem representations are assembled in a composition hierarchy which is a straightforward tree. The leaves of this tree are atomic components which are defined in some way other than by composition. Composites do something useful because they define connections between the inputs and outputs of their component parts, and ultimately this alsways means connecting the inputs and outputs of the atomic leaf components. Thus the modeller is simultaneously defining a tree and a network.
When a single-purpose model is being constructed, this will result in a single tree. We can imagine, however, that long-running systems expose the data flows at their leaves in some way (publish and subscribe). In this case it should be possible to define new systems which connect to these flows, and then we start to define a forest of individual trees.
January 15, 2005 in Knowledge Management | Permalink | Comments (0) | TrackBack (0)
I guess I should have mentioned this here a long time ago; my eye wandered from a lot of balls over the last few months. Things can only get better …
I am organising a special session at MODSIM05 entitled, "Languages and metamodels for model composition." The abstract (find it under "Special Sessions" in the menu at the left of the page; the fixed masked URI stops easy linking grumble grumble) reads,
A lot is being invested at present in the production of facilities to support the composition of model components into integrated models. Any such framework embeds an ontology of models, or metamodel; this is a fundamental prerequisite of interoperability. This metamodel finds expression in the form of a composition language, be it as an API in a general purpose programming language, an application of XML, or language built on a logic-based formalism such as RDF. This combination of language and metamodel acts as a "strong pair of glasses", bringing certain things into sharp focus and obfuscating others, making some constructs easy to express, others intractably difficult. Papers are invited discussing composition languages and the metamodels they embed and express. Topics of interest include, but are not limited to: description of the metamodel embedded, by design or otherwise, in a particular composition language; the power of particular metamodel in terms of the range of model types and model structures which can be described and the parsimony of description; analysis of the strengths and weaknesses of the chosen foundation layers (programming language, XML, RDF, etc) and the influence of these; comparisons of two or more languages or metamodels; the relationship between the metamodel and the modelling domain ontology; reports on difficulties encountered in model linking resulting from metamodel or ontology mismatch and possible approaches to resolving these.
Getting any fish to bite with this bait is a long shot, perhaps, and getting longer if I don't get more specific invitations out. If anyone has any ideas about people who might have something to contribute, even if they don't know it, please let them, or me, know. The abstract should be interpreted broadly; if in doubt, err on the side of submitting an abstract (deadline March 18) or drop me an email.
January 14, 2005 in Modelling | Permalink | Comments (0) | TrackBack (0)
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
Recent Comments