Thoughts about the architecture

Separation of Tags/SystemTags

To not consider SystemTags at various places, they could be kept separated in the post model. On the database layer they'd have to be merged (when writing) or separated (when reading) again. See Task No. 1

Import/Export of SystemTags

As of now SystemTags aren't exported. For users of the backup client they should be exported as well as imported (see Task No. 2). It needs to be debated whehter actions triggered by SystemTags should/must/may be repeated on import.

Where do SystemTags come into the System?

• postBookmark / postPublication dialogue (each 1 oder many posts!)
• updateBookmark / updatePublication dialogue (each 1 oder many posts (edit button)!)
• updateTags = edit (small edit without updatePost)
• rename tags function (in relations)
• ...?

How does the User see SystemTags?

• SystemTags are bothersome in the tagcloud since they do not describe ressources (e.g. sent:xyz)
• However they can form valuable links, e.g. toRead or myOwn
• To preserve both, an expressive tagloud and the links, SystemTags can be separated from other tags => extra cloud or list
• Eventually each user should be able to decide on his own which SystemTags should be displayed and which not :-(
• While toRead is always useful, sent:xyz is a matter of argument
• SystemTags could also be displayed separated from other tags, e.g. when updating two lines could be visible

Thoughts about the semantics

Types of Tags

• Tags can be differentiated by content, category, opinion, ownership, self-reference, task organization, social coordination (KI 2009 Tutorial 3, page 17)
• Consideration: Is it useful to manage some of these categories (e.g. ownership, self-reference, task organization, social coordination) if possible to handle them seperated from the other tags?
• Could be helpful for our work on tags (this way common tags like myOwn or toRead could be avoided)

One Approach

Basically it is to be differentiated between active and passive SystemTags. Passive SystemTags are interpreted by diverse components in different places (asynchronous), e.g. sys:toread triggers the view to color-highlight this entry.

Active SystemTags can trigger complex actions when saving a post, e.g. sys:for:<groupname> triggers a lot of database operations).

It's natural for each active SystemTags to be implemented by a respective code. Currently using Spring a HashMap is configured, mapping SystemTag names to implemented classes (systemtag-context.xml in bibsonomy-database).

A class structure models SystemTags, centrally defining, configuring, and managing them.

Another Approach

A tag is a tag is a tag. Some tags are interpreted by users, others by system components, and each in their own way. So sys:toread causes a view to highlight, and a search component to weight a post increased.

There is no central class structure to model all SystemTags, however a component to handle SystemTags, e.g. isSystemTag and extractArgument in bibsonomy-systemtags or in utility classes in bibsonomy-util.

However, it is to be minded that conceptionally different posts are provided with the same SystemTags, in this respect SystemTags form a semantic separately treated form of tags (comparable to meta tags).

Tasks

• In Separation of Tags / SystemTags: Localization of concerning places in DBLogic
• Import / Export of SystemTags in the API
• What happens if the only tag of a post is a SystemTag? What happens when this SystemTag is then deleted after its usage?