[[:osapa:osstag|<< back]]
=====Contents=====
* [[https://www.linuxfoundation.org/#Hosting|1 Hosting]]
* [[https://www.linuxfoundation.org/#v0.3_final_-_planning|2 v0.3 final - planning]]
* [[https://www.linuxfoundation.org/#Features_we_want_to_implement_in_v0.3|2.1 Features we want to implement in v0.3]]
* [[https://www.linuxfoundation.org/#Current_state_as_of_0.3pre1|2.2 Current state as of 0.3pre1]]
* [[https://www.linuxfoundation.org/#How-To_maintain_history|2.3 How-To maintain history]]
* [[https://www.linuxfoundation.org/#tag_permissions|2.4 tag permissions]]
* [[https://www.linuxfoundation.org/#v0.3pre1_-_30._Jul_2006|3 v0.3pre1 - 30. Jul 2006]]
* [[https://www.linuxfoundation.org/#v0.2_-_16._Jun_2006|4 v0.2 - 16. Jun 2006]]
* [[https://www.linuxfoundation.org/#v0.1_-_17._May_2006|5 v0.1 - 17. May 2006]]
* [[https://www.linuxfoundation.org/#Overview|5.1 Overview]]
* [[https://www.linuxfoundation.org/#Discussion|5.2 Discussion]]
* [[https://www.linuxfoundation.org/#3-Level-Tagging|5.2.1 3-Level-Tagging]]
* [[https://www.linuxfoundation.org/#Easy_Integration|5.2.2 Easy Integration]]
* [[https://www.linuxfoundation.org/#Appearance_is_configurable|5.2.3 Appearance is configurable]]
====== Hosting ======
Project Homepage: [[http://osstag.sourceforge.net|http://osstag.sourceforge.net]]
A demo installation can be found at [[http://prevalent-digest.de/osstag/current/|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: [[http://prdownloads.sourceforge.net/osstag/osstag-0.3pre1.tar.bz2?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 + [[http://prevalent-digest.de/osstag/osstag-0.2/examples/variants/index1.pl|6 variants for testing]]
* project tag-cloud
* Download: [[https://sourceforge.net/project/showfiles.php?group_id=169679&package_id=193548&release_id=425243|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/|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 [[http://prevalent-digest.de/osstag/osstag-0.1/examples/freshmeat/project_mdadm.pl|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.
===== Discussion =====
==== 3-Level-Tagging ====
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 :)
==== Easy Integration ====
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|http://prevalent-digest.de/osstag/osstag-0.1/src/doc/osstag.html]]
==== Appearance is configurable ====
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|http://prevalent-digest.de/osstag/osstag-0.1/src/doc/osstag_config.html]]
\\ [[:osapa:osstag|<< back]]