<< back 
Project Homepage: http://osstag.sourceforge.net 
A demo installation can be found at http://prevalent-digest.de/osstag/current/ 
v0.3 final - planning
As 0.3pre1 implements a complete meta-project-information website, we now may focus on the tagging itself.
Features we want to implement in v0.3
- timestamps of tags
- complete history of tags
- edit of tags
- non-editable tags (by project owners)
Current state as of 0.3pre1
- 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
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
How-To maintain history
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:
- copy the edited semmap/taglist to another table, referring to the original semmap-id, then updatee the original semmap/taglist
- 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 .. :(
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) );
-- 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
v0.3pre1 - 30. Jul 2006
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 
v0.2 - 16. Jun 2006
- 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 
v0.1 - 17. May 2006
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