Re: [AgileWiki] Faceted Classifiers (and Tag Types)

[Bill la F. <bil...@su...>]

OK Norm,

I will soon be implementing property tags, but my question is regarding 
indexed tags. Sorry for the confusion.

I am thinking that ANY rolon which has a document that includes 
references can serve as the basis for indexed tags, as the references 
are extracted to the (TKS) table, _ref-. See 
http://agilewiki.org/aw3/AwServlet?cmd=rid%20519608d74a67454ed4dc4f3629f4eb52

So all I need to do is to tell one rolon to use another as a source of 
indexed tags. And this notation ("telling") could be as simple as adding 
the rolon to the applicative context, though I would prefer to have an 
intervening ClassifierSection that identifies the relationship. (A 
similar case for includes--the included rolon would not be put in the 
_ac- table, but rather there would be an intervening ClassifierSection 
that indicates that the relationship is inclusion.)

Bill

Norm Kashdan wrote:

>Bill,
>There's two ways to think about tags (referrer and referent) --
>unfortunately, the general descriptions on the web don't make these
>distinctions quite clear enough, so I'll introduce a couple of terms.
>
>I make a distinction between Property Tags and Indexing Tags.
>
>Property tags are tags that belong to a structure (the referent rolon).
>They are, of course, classifiers.  A good example of property tags is the
>photo website www.flickr.com that allows users who have permission to add
>tags to each photo.
>
>Indexing tags are NOT part of the referenced structure and reside somewhere
>else (the referrer).  Again, they are classifiers, but of another rolon.
>The premier example of this is http://del.icio.us/ that allows users to
>maintain their own tag space (i.e. rolon) and tag URLs across the web.
>Del.icio.us manages tags across user tag spaces thereby introducing some
>rolonic structure.  The user only gets a partial view of this (as is true of
>most software implementation).
>
>As you and I know well, all four aspects of a rolon are ALWAYS present in
>every implementation (it's impossible for them not to be), but they are most
>often not explicit or balanced in proto-rolonic implementations.  History,
>of course, is usually partial and disguised as "state".
>
>;-norm
>