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]