[Registry-dev] Dropping the tags tagle (was Suggested Registry changes/improvements)

[Jonathan Marsh]

Just a +1 to merging the tags and tagging table.  I think I proposed
separating tags and taggings in the design, and I repent!  More rationale:

Today we separate a tagging, which links a particular user with a particular
resource and a particular tag, and timestamps the act of creating this
relationship.

A tag shouldn't exist before a user does a tagging with it.  If the user
does a tagging, the tag should be created automatically, and if all taggings
of a particular tag are deleted, the tag itself isn't reached by any normal
navigation of the data model.  However, the presence of orphan tags
complicates things like generating tag clouds (clearing out tags with 0
uses), garbage collecting unused tags, etc.

So the tags table currently just has tag "values" stored in it and an
automatically generated identifier.  However, the name itself is sufficient
to identify the tag.  We are realizing that a tag is special in that name of
the tag and its "value" are identical.  A table full of tags is essentially
a single column.  At best at present all it provides is an index of unique
tag values, but that seems more of a sql capability than a registry one.

One use for a tag table would be to add another column if there is one that
has value.  We looked somewhat into having "friendly names" for tags and
looked at a number of sites which seem to do this.  But even those that
provided friendly names seemed to allow different users to have different
friendly names, which would translate to keeping a friendly name in the
taggings table.  Searching over friendly names needs to perform some
canonicalization, such as space removal or normalization and case folding.
But we preferred a model where the UI would do any necessary
canonicalization so the user can understand what's going on better (we're
going for a programming-savvy crowd).

If we replace the tagid in the taggings table with the tag name (or value,
however you want to think about it), we can drop the tags table.  In which
case renaming the taggings table to tags also makes sense.

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 
> -----Original Message-----
> From: registry-dev-bounces at wso2.org [mailto:registry-dev-
> bounces at wso2.org] On Behalf Of Chathura C. Ekanayake
> Sent: Thursday, November 08, 2007 9:53 AM
> To: registry-dev at wso2.org
> Subject: [Registry-dev] Suggested Registry changes/improvements
> 
> 
> Below are the changes and improvements suggested in the discussion with
> Glen and Jonathan.
> 
> 1) Drop the Tags table
> 
> Currently Registry has two tables for handling tags. Tags tables stores
> the tag strings used in the system. Tagging tables contains the
> relationships between tag strings (from the Tags table), Resource IDs
> (from the Resources table), user name and the tagged time.
> 
> We can achieve the same functionality without having the Tags table.
> Tags table is needed only if Registry admins want to pre-populate the
> tags that can be used in the system and want to restrict users to only
> use those tags. Currently such feature is not used in the Registry
> code.
> So we can remove the Tags table and handle the tags only using the
> Taggings table.
> 
> 2) Inherited permissions
> 
> Currently when a resource is created permissions for all actions on
> that
> resource is granted to the user who created the resource and to the
> admin user. Instead, we can make the child resources to inherit all
> permissions from their parent resources. So that managers can configure
> permissions for a subtree of the registry and let his team work on that
> subtree without worrying about the permissions. We can also make the
> inherited permissions configurable if some one doesn't need that.
> 
> 3) Properties with arbitrary content
> 
> Currently properties of resources can only store strings as their
> values. Glen suggests that we should be able to associate any arbitrary
> content with resources as properties. There are two possible ways to do
> that. One method is to change the data model of the registry, so that
> we
> can store blobs as resource properties. Then we can associate a media
> type with properties to specify whether it is a string or binary
> content.
> 
> Second method is to store the content of the property as a normal
> resource in the registry and store the URL of that resource as the
> property value. Then, when ever we look up a property we should
> determine whether it is a string or a URL. If it is URL, we should get
> the content of the corresponding resource and return it as the property
> value. This look up functionality can either be implemented in the
> registry or in the product that uses arbitrary property contents. This
> method does not require changes in the registry data model.
> 
> Comments...
> 
> Thanks,
> Chathura
> 
> 
> 
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev