Description

• In his project Steffen Schaake and Markus Jordan are working on a general overhaul of the framework
• SystemTags are tags with a certain function
• SystemTags are usually in the form <prefix>:<name>:<argument> or <name>:<argument>
• prefix is either sys or system - both prefixes can be used interchangeable and lead to the same results
• Exception the tag MyOwn has the ability to mark own publications, e.g. for showing in a Curriculum Vitae, however this tag has not yet been integrated into SystemTagFramework. TODO

State of the "Art"

• Initially handling of these SystemTags have been implemented in Tag-Models
• Now there is a SystemTag-Framework handling these Database-Access-Layers centrally (bibsonomy-database/.../systemtags/*)
• The SystemTag-Framework should be changed and improved to easily write new SystemTags

Overview over different types of System Tags

The following types of SystemTags are (as of now) differentiated:

Executables SystemTags

An executable SystemTag belongs to a post. At a given point of time (e.g. saving, updating, deleting, reading) of a post a certain action will be triggered and executed

An ExecutableSystemTag should make at least the following decisions:

• Decision: Will it be displayed along the post? (possibly different visibilities)
• Decision: Will it be deleted? (e.g. after it has fulfilled its purpose or has been executed successfully)
• Decision: Will it be deactivated or changed into a noram tag (e.g. send:... to sent:...)
• Decision: Should it be activated once or each time when the post is displayed / edited / etc.?
• Decision: May it be used by the user? (must be regulated in the methods before/after saving/updating a post)
• Decision: When will the action be executed? (implementation so far: Before/After saving/updating/TagUpdate)

Here a list sorted by frequency of execution

executeOnceDirect

This kind of SystemTags will be executed once right before/after posting/updating.

As of now the following Executable System Tags are available:

for:<groupname> (exists)

• Action when creating or updating a post
• Post will be "gifted" the group groupname
• Implementation: ForGroupTag.java

send:<username> (exists)

• Action when creating or updating a post
• Post will be "send" to user username
• Implementation: ForFriendTag.java
• After using this tag once, it will be renamed to sent:<username> and thusly be deactivated
• TODO can be extended to ForUserTag or SendUserTag according to settings who may send posts

system:doIE (dbe)

• Conducts information extraction
• TODO describe more accurately (what kind of IE?)
• if the information extraction may not be executed before/after posting/updating, but rather to a fixed time -> move to group executeOnceScheduled

executeOnceScheduled

This kind of SystemTags will be executed once to a fixed time. Here, the following Tags are planned:

system:expires:<date>

• Action when reading a post
• Deletes post at date

system:revise:<date>

• It's common to adjust own publications as a "rough draft" (without totale number of pages, booktitle, ...) because some information aren't available on just accepted papers.
• Though it's known when these information will be available
• Some kind of reminder-function would be useful ("Please update post XYZ")
• The SystemTag sends a mail to the owner on this respective date

system:reminder:<date>

• generic reminder function
• Action will be triggered at fixed time date (e.g. reminder mail, see system:revise:<date> above

executePeriodically

This kind of executable tags are similar to cronjobs and will be executed regularly (defined time intervals)

The following tags could belong to this group:

system:checkIfModified

• Checks regularily if the content of a page has changed
• If yes, an action (e.g. mail to owner) will be triggered
• For this we need storage to save the current state of the page => Postpone

system:trackUsage

• gathers in regular intervals the "level of distribution" of a resource R, e.g.
• Sum of users having posted R
• used Tags
• ...
• triggers an action, e.g. a mail with the collected information to the owner

Search SystemTags

Such a tag isn't bound to a specific post, but is rather entered in the search box. This tag limits the searched space, rather than searching for this exact tag.

• We build the complete URL-scheme using systags, don't we? (dbe)
• Do these tags have effects pnly in the search box, or as well in other places where "normal" tags may be used? (dbe)
• If search systemtags can be used everywhere where tags are used, then which precedence do these tags have on e.g. /user/dbenz/myown+sys:user:hotho, resp. how do we deal with such conflicts? (dbe)
• How do we deal when a combination of SystemTags not supported are used (e.g. system:bookmark+system:hasPDF)? (dbe)

So far the following SystemTags exist:

system:user:<username>

• limits by user username

system:author:<authorname>

• limits by authoer authorname

system:entrytype:<entrytype>

• limits by the type of the (publication) entry

system:tag:<tagname>

• limits by tag tagname

system:group:<groupname>

• limits by group groupname

system:year:<year/years>

• limits by BibTexFeld year:
• argument = 2000 => all from year 2000
• argument = 2000-2010 => all from years between 2000 and 2010
• argument = 2000- => all from year 2000 or later
• argument = -2000 => all from year 2000 or earlier

These Search SystemTags may be planned right now:

system:concept:<tagname>

• limits by tag and subtags

system:mindate:<date>

• minimum publication date

system:maxdate<date>

• maximum publication date

system:posted:<number>

• number of posted entries

system:description:<text>

• limits by description text

system:bookmark

• only bookmarks

system:publication

• only publications

system:userExperience:<number>

• only posts of users with at least number publicated elements

system:authorExperience:<number>

• only posts of authors with at least number publicated elements

system:hasURL:<>

• only posts having an URL

system:hasPDF:<>

• only posts having an attached PDF file

system:hasPrivateNote:<>

• only posts having a private note

system:numberTags:<number>

• only posts with at least a number of number tags

system:citingme

• only publications citing me

Meta SystemTags

Tags have different uses:

• toRead rather describes the organizatorial planning than the actual ressource
• myOwn is a self-reference and already has a special meaning in BibSonomy: defining the content of the CV page

It's a logical idea to highlight these tags, e.g. with a special color.

Limitation: By setting certain TagNames a vocabulary is preset, contradicting the idea of free tagging.

Alternative: Colored highlighting with the use of relations, i.e. each user may define tags to be highlighted (e.g. sys:red<-toRead), preserving the free tagging model and each user may regulate the selection and coloring of their own tags. Additionaly it may be a good way to recall the relation feature to the user's mind.

• That's a great idea! "System-Relations!" [[Benutzer:Rja|Rja]] 16:47, 31. Mär. 2010 (CEST)

MarkUp SystemTags

This category includes tags written to posts by certain processess within BibSonomy. After their creation these tags are permanently attached to the respective post.

system:linkchecker:404

• Marked as unreachable by the linkchecker

system:from:<user>

• Result of the send:user tag
• Marks the post as being sent by user

sys:relevantfor:<GROUP>

• Marks the post as being relevant to a certain group
• Induces displaying available "group tags" on the editPost page
• All posts by the group with this tag appear on [http://www.bibsonomy.org/relevantfor/group/<group>]
• Thus the link under this tag should point to the page [http://www.bibsonomy.org/relevantfor/group/<group>] instead of [http://www.bibsonomy.org/group/<group>/sys:relevantfor:<group>] (even though they technically are the same pages)

Control SystemTags

This category includes SystemTags routinely configuring / controllig current processes in BibSonomy.

system:linkchecker:ignore

• To be ignored by the linkchecker (e.g. for local files)

SystemTags in the WebApp

Idea: hide SystemTags in the WebApp, i.e. they should perform their function (in the database or in the WebApp), but they shouldn't be displayed (or only on keypress or mouseover or the like). - So far there are only 2 SystemTags concerned by this: (for: and send:) - Deactivated SystemTags then also should be hidden, though the idea of delivery confirmation, e.g. in send:, gets lost.

TODO

• SystemTags in the WebApp - where should they be displayed? at the post, in the tagcloud (e.g. annoying)
• SystemTags on copying of posts, e.g. at forGroup, should MyOwn tags like sent:sdo get hidden if the post is sent or forwarded to someone else?
• ErrorHandling in SystemTags: e.g. sys:days:blubb => parseInt throws exception if blubb is not an integer / NaN.
• Variant 1: ErrorMessages
• Variant 2: silent ignore (problem: if it is the only tag, then what?)
• Implementation everywhere that always at least one not-systemTag has to be at the post, because they can disappear now and then and untagged posts emerge
• When are Search SystemTags usable? Which of the many search modes, currently this is not clear, especially as a user it's unclear what each tag can do, etc.
• Rules for what happens with contradicting SystemTags, e.g. sys:group and sys:user overwrite each other in random order
• How does it help the user to use SystemTags?
• e.g. google advanced search => SystemTag Menu with description
• e.g. on entry in WebApp => SystemTag suggestions

Not further explained or unassociated SystemTags

TODO Associate and explain these SystemTags

system:ignore

• Display post only when explicitely queried
• Doesn't the functionality of this SystemTag overlap with visibility=private? (dbe)