osstag_prototype

By Linux Foundatio... - November 10, 2009 - 8:59am

<< back

1 Hosting
2 v0.3 final - planning
3 v0.3pre1 - 30. Jul 2006
4 v0.2 - 16. Jun 2006
5 v0.1 - 17. May 2006
- 5.1 Overview
- 5.2 Discussion

Hosting

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

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

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 .. :(

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)
);

tag permissions

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

Overview

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.