• 1 Hosting
• 2 v0.3 final - planning
  • 2.1 Features we want to implement in v0.3
  • 2.2 Current state as of 0.3pre1
  • 2.3 How-To maintain history
  • 2.4 tag permissions
• 3 v0.3pre1 - 30. Jul 2006
• 4 v0.2 - 16. Jun 2006
• 5 v0.1 - 17. May 2006
  • 5.1 Overview
  • 5.2 Discussion
    • 5.2.1 3-Level-Tagging
    • 5.2.2 Easy Integration
    • 5.2.3 Appearance is configurable

Project Homepage: http://osstag.sourceforge.net

A demo installation can be found at http://prevalent-digest.de/osstag/current/

As 0.3pre1 implements a complete meta-project-information website, we now may focus on the tagging itself.

• timestamps of tags
• complete history of tags
• edit of tags
• non-editable tags (by project owners)

• tags are organized as lists
• each information that is tagged may have n tag-lists attached, not just one
• each tag-list is assoziated with a semantic-mapping, which basicly is a description of what (which aspect) is to be tagged

Example:

physical mapping: backup.tar.bz2

might have 2 semantic layers wich should(?)/can be tagged seperately

-> semantic mapping: encoding
-> semantic mapping: content as intended

both semantic mappings can have a individual tag-list:

-> taglist for encoding of backup.tar.bz2: tar, bzip2, file-structure
-> taglist for content as intended: backup, before 2006, restore, customer-data

Because each taglist is attached to one semantic mapping, each change could result in a new semantic mapping entry, marking the old one as revised. The attached tags would also be copied. User/Author/Date information could also be attached to the semantic map / tag list.

Example for sem-map 'encoding' of file backup.tar.gz of some project:

id: 1
sem: encoding
tags: bzip2, tar
author: jan
date: 08-AUG-2006

after edit by naj:

id: 1
sem: Encoding
tags: bzip2, tar, bunzip2, compressed, taper
author: naj
date: 09-AUG-2006

id: 1
sem: encoding
tags: bzip2, tar
author: jan
date: 08-AUG-2006

→ so the most recent date determines which taglist is the current head revision

For the implementation there are the following options:

1. copy the edited semmap/taglist to another table, referring to the original semmap-id, then updatee the original semmap/taglist
2. insert new semmap with new id, maintain 2nd column with IDs to identify belonging semmaps/taglists, optional maintain addiotnally an 'head'-tag for easyier identification of head-versions (but this would violate normal-form .. :(

Decision:

We'll use the 2nd option without head-tags, following the motto: no optimizations during initial development, leave this to profiling later.

Resulting in the change form (v0.3pre1):

-- semantic mapping
CREATE TABLE osstag_semmap (
  id int(11) NOT NULL auto_increment,
  phymap_fk int(11) NOT NULL,
  sem_desc varchar(2000),
  sem_aspect_fk int(11) NOT NULL,
  PRIMARY KEY  (id)
);

-- assoziations (taglists)
CREATE TABLE osstag_assoziations (
  id int(11) NOT NULL auto_increment,
  semmap_fk int(11) NOT NULL,
  original_tag varchar(255) NOT NULL,
  normalized_tag varchar(255) NOT NULL,
  PRIMARY KEY  (id)
);

to (v0.3pre2)

-- semantic mapping IDs
CREATE TABLE osstag_semmapid (
  id int(11) NOT NULL auto_increment,
  phymap_fk int(11) NOT NULL,
  visible boolean default true,
);

-- semantic mapping
CREATE TABLE osstag_semmap (
  id int(11) NOT NULL auto_increment,
  semmapid_fk int(11) NOT NULL,
  sem_desc varchar(2000),
  sem_aspect_fk int(11) NOT NULL,
  date DATETIME NOT NULL default NOW(),
  user_fk int(11),
  PRIMARY KEY  (id)
);

-- assoziations (taglists)
CREATE TABLE osstag_assoziations (
  id int(11) NOT NULL auto_increment,
  semmap_fk int(11) NOT NULL,
  original_tag varchar(255) NOT NULL,
  normalized_tag varchar(255) NOT NULL,
  PRIMARY KEY  (id)
);

The question is on how we are going to handle the permissions. For now I just implemented a flag-field (one per tag-list id), which we could use as follows:

• open taglist, everybody may add, edit, remove, ..
• add only, so others may only add new tags to this specific list but may not change or remove existing ones
• fixed, these taglists are as they are, only changeable by the project owners

The project owner would be the one who defines the flag

OSSTag comes now with a complete Web-Interface to tag just about any project. It supports User-Login/Registration and you can freely provide any Meta-Information on projects you want to be tagged. The whole release is separated into 4 modules:

• osstag - the tagging engine with xml/http-request interface
• xsltwf - a xml/http-request framework for user-management
• projectpointer - a xml/http-request framework for project meta-informations
• tagaproject - a website combining above three modules in one website, using xml and xslt.

Download: osstag-0.3pre1.tar.bz2

• aspect oriented tagging
• This release comes with 6 slightly different variants of how OSSTag could be used. As example we chose the FireFox extension Morse for all 6 variants.
• project column added to phymap (→ enables tags to project and sub-parts of project via phypointer)
• minor fixes + 6 variants for testing
• project tag-cloud
• Download: osstag-0.2.tar.bz2

This is my first introduction into this. It's purpose is more to have a common base to discuss about OSSTag rather than a fixed solution that can not be changed.

As Introduction take a look at my example at http://prevalent-digest.de/osstag/osstag-0.1/examples/freshmeat/ .

Here I just added some tags to the project 'mdadm 2.5'.

If you follow the link 'mdadm 2.5' to the project-page, the same tag-list can be seen, as well as a simple form to add new tags.

Yes, this is yet only a plain flat tag-structure. So let's start to figure out how 3-level-tagging can be applied on a web-based interface :)

I tried to provide simple and explanatory functions for easy integration into existing websites.

A quick introduction can be found in the src/doc directory: http://prevalent-digest.de/osstag/osstag-0.1/src/doc/osstag.html

How the tags appear is quite configurable via the osstag_config.pm file: http://prevalent-digest.de/osstag/osstag-0.1/src/doc/osstag_config.html

<< back