Tagging |The Semantic Puzzle

Yesterday we dealt with reports, user interaction and interface questions, today is usage data model day (or morning) in the KiWi – Knowledge in a Wiki - Project. Usage data model means that it is concerned with an abstract conceptualization of the data as perceived by the user (and not by the developer/implementer) – at the same time, it is not immmediately concerned with the visualization of data on screen. FranÃ§ois Bry gave us an overview of the proposed core concepts and objects which are currently: content item, tag (and tagging), link, rule, user, and access right.

There is no need for me to repeat his full presentation, as FranÃ§ois had already in advance made his presentation available on the KiWi-project wiki. Nonetheless, I’d like to highlight a few aspects:

A content item is to be understood as a slight generalisation of a wiki page: Every wiki page is a content item, but not every content item is a wikipage, and content items that are no wiki pages are part of a wiki page. This could include, for instance, media content such as pictures, diagrams or tables. This modularization (content items within pages) meets the demands of the proposal that Kiwi-pages must be composable.

Consequently, not only wiki pages but content items too must be taggable (which takes us to: tagging). Furthermore, it was proposed to make a distinction between atomic tags (short; consisting of a tag name and an associated content item instead of a description) and structured tags (that are made up of atomic tags), as well as between explicit tags (that are applied by users) and implicit tags (that are generated on the basis of rules that have been defined by users).

To illustrate this distinction, I’ll paste in a few illustrating explanations from FranÃ§ois’ wiki report:

The tags assigned to the content item of an atomic tag T can be seen as tags assigned to the atomic tag T itself. Tagging of tags in this way can serve, for example, to distinguish between the atomic “hotel” in English and the same atomic tag “hotel” in French or to group or classify tags. [...] A structured tag is build up from atomic tags. [...] Examples of structured tags are as follows:

hotel(3stars downtown)
hotel(location(downtwon))
hotel(comfortable)

A heated debated ensued (which I quite like, because that is the point where our own, yet unchallenged assumptions are exposed), in particular with regard to the implementation of structured tags: Wouldn’t that mean to raise the cognitive barrier too high if users were required to enter complicated tags?

Much was clarified with the agreement that users may use structured tags, but that this wouldn’t be a requirement. Using complex tags (e.g. a structured tag that includes dates or deadlines) might make sense to a particular set of users (e.g. project managers in the Logica use case) – and whether a software feature is going to be used (successfully) or not is primarily depending upon the question whether the user sees a benefit in it or not. Also: The concept of structured tags within the data model does not yet say anything about the way they will be represented on screen – in most cases, users won’t see a hotel(location(downtwon)) spelled out.

On to the coffee break!

[Image: Physical tagging on a tree, by Jean Etienne Poirrier]

In May, a new bookmarking service, Faviki, started which, unlike other bookmarking services, comes to the public semantically enhanced. ReadWriteWeb already had a first look at it and described it as follows:

Faviki is a new social bookmarking tool that offers something that services like Ma.gnolia, del.icio.us, and Diigo do not – semantic tagging capabilities. What this means is that instead of having users haphazardly entering in tags to describe the links they save, Faviki will suggest tags to be used instead. However, unlike other services, Faviki’s suggestions don’t just come from a community of users and their tagging history, but from structured information extracted straight out of the Wikipedia database. Faviki’s backend uses DBpedia, a community-maintained database created by extracting structured info from Wikipedia and turning that into a database which you can query.

What Faviki does, from a user’s perspective, is to suggest tags based on Wikipedia/DBpedia terms – one of the side effects of this procedure being that e.g. “Safety (disambiguation)” can also be chosen as a possible tag – I am not so sure yet whether this is an option that makes sense (although one can probably argue that it neither does any harm, because people should be smart enough not to use such tags). And as the above screen shot of Faviki’s tag cloud reveals, it currently seems to be mainly used by people who are interested in the semantic web and search engines (with semantic search being the most promising area of application of semantic technologies). It’s probably going to take a while (if ever) before Faviki is going to reach such a diverse user-base as can be guessed from del.icio.us’ tag cloud – but then again: Maybe Faviki isn’t going to need that, as it doesn’t rely on collective tagging, but already benefits from Wikipedia’s diversity of entries!

As was also regretted by ReadWriteWeb: It’s a pity that there is currently no opportunity to import tags from del.icio.us or other services to Faviki. Who is going to win the bookmarking race? Del.icio.us has the advantage of a broad user-base, and many users already have their networks of fellow bookmarkers which they probably wouldn’t want to give up (I personally wouldn’t). Bibsonomy has the advantage of an extra feature that allows to bookmark publications and later export them as a uniformly formatted bibliography. If I could make a wish, I’d rather have a service that brings together the best of Faviki, Bibsonomy AND del.icio.us!

	if not otherwise specified