Tag grouping/hierarchy question

[CintaNotes Developer]

Hi all,

it seems that I need your help to decide how exactly tag grouping in going to work
in the upcoming version of CN. Huge thanks in advance for your advice!

Basically, the choice is between two models of how parent tags are applied. Both of them
have advantages and drawbacks, so it is difficult to see a clear winner. But CintaNotes
should aim at practicality while remaining easy to understand, so I hope that your responses
will help me choose.

Ok, so here's the story. Imagine that you have the following tag hierarchy:

Code: Select all

vehicles
  cars
    ferrari
    honda

According to how tag hierarchy operates, when you assign tag "ferrari" to a note,
it automatically gets tags "cars" and "vehicles" assigned (or they are implied, which is
not very different). So far, so good!

After awhile you realize that you don't want to see notes tagged "ferrari" in the list of
cars, but would rather create a new tag hierarchy related specifically to Formula-1.
So you create a top-level tag "formula1" and move the tag "ferrari" into it.

Code: Select all

formula1
  ferrari

vehicles
  cars
    honda

Now comes the question: what should happen to the notes tagged "ferrari" (and, by implication, "vehicles" and "cars")?

Should they automatically get tags "cars" and "vehicles" removed and tag "formula1" added?
At first it seems that yes, they should - according to the hierarchy the notes are now about
Formula 1 than about vehicles, but read on!

Here is a second example:

Code: Select all

tasks
  urgent
    project-a

After some time you decide to move the tag "project-a" to the top level, like this:

Code: Select all

project-a
tasks
  urgent

If changes in tag hierarchy are automatically tracked, then urgent tasks on project-a
will cease to be tagged "urgent", and also, cease to be tagged "tasks"! This is clearly
not what you have intended! In order to do what you want, you'll need to do something
like this:
- rename tag "project-a" to "project-a-urgent-tasks"
- select all notes with this tag and add a new tag "project-a" to them, which will be top-level
- remove tag "project-a-urgent-tasks"
- select all notes with tag "project-a" and explicitly assign them "tasks/urgent".
Quite a bit of work!

So here are the options that we have, summarized:
1) Tag hierarchy is dynamic: it is always in sync with what you see in the tag sidebar
(solves the problem with Formula1, but you can lose some needed tags);

2) Tag hierarchy is static: parent tags are assigned automatically together with child tags,
but are treated independently after that (solves the problem with urgent tasks, but you can end up
with some stale tags)

3) CintaNotes should prompt user ("UI-designer is a coward" approach ).

4) Some other option?

Which one would you prefer and why?
Thanks in advance!

[mhf]

Hi Alex,
interesting question.

It reminds me of Taxonomy discussions :
...
Class
Order
Family
Genus
Species

For instance, in your example of car, ferrari and formula1, strictly speaking it should go :
vehicle
car
formula1
ferrari

whereas with the honda it would go :
vehicle
car
honda

so here in the first example above vehicle is the Order, car is the Family, formula1 is the Genus and ferrari the Species but in the second there's like a jump : Order, Family then Species.
Also we are presuming that the vehicle tag pre-exists the car tag, if this is not the case then how would we be able to insert tags into the order that would then "collect" the "Genus" and the "Species" - seems difficult.

In your second example :

tasks
urgent
project-a

if you move project-a upwards for me that means that I have decided that everything in project-a is urgent so project-a should still have the urgent tag.

My opinion is that none of this should be automatic - or, if automatic, then at least optional - so I'd go for No. 3).

Thanks - again - for this excellent program.

[Noddy330]

Agree that tags higher in the tag hierarchy should automatically be assigned when a note is tagged or re-tagged.

Regarding tag removal - I’d vote, initially, for “3) CintaNotes should prompt user”, and I’d want to be asked something like
“The following tags, which are relevant to the position of the currently assigned X tags hierarchy, will be removed unless you select some/all of them to be retained”
With a tick box or radio button against each tag that may be removed.

That is, unless it is just too complicated considering that
- The same tag may be in several hierarches (unless prohibited)
- Tags may get moved around the tag hierarchy (unless prohibited)
- The dialogue suggested above may be too tricky to implement and/or ask the user in a very clear manner
In which case I would not remove any tags, and would vote for “2) Tag hierarchy is static”

Also I would not have CintaNotes remember which tags were assigned automatically due to tag hierarchy.

Nod

[Midas]

[...] Options that we have, summarized:

1) Tag hierarchy is dynamic: it is always in sync with what you see in the tag sidebar (solves the problem with Formula1, but you can lose some needed tags);

2) Tag hierarchy is static: parent tags are assigned automatically together with child tags, but are treated independently after that (solves the problem with urgent tasks, but you can end up with some stale tags)

3) CintaNotes should prompt user ("UI-designer is a coward" approach ).

4) Some other option?

Which one would you prefer and why?

Thanks in advance!

This issue is in fact the Schrodinger's Cat of my trade; subject description and structuring has persistently proven to be the real quadrature of the circle. Although the problem has been debated and dealt with in the LIS technical field time and time again, I'm still unable to provide a clear-cut answer; maybe I also don't have a clue about how the implementation will really work out.

I believe this -> http://www.elearnspace.org/doing/classification_ontologies_taxonomy.htm could provide plenty of clues to how the issue should be defined, but it might also not be so rich in short-term recipes and answers.

One thing I know for sure: everybody's perceptions will change -- or at least fluctuate -- regarding this, and the best solution is bound to be the more open, flexible and user oriented one; that makes 3. perhaps the best current solution, allowing for a user consensus to emerge...

[CintaNotes Developer]

Thanks guys for your input! You gave me really something to ponder about)
And Midas, thanks a lot for the interesting read! I was hoping to get some advice from you here since this is right up your alley

One thing is clear for me - in general we cannot count on users building and maintaining a valid taxonomy.
Many users will treat tags hierarchy as folder or virtual folder hierarchy, and CintaNotes should not hold some
nasty surprises for such users.

So here are my considerations:
1) CintaNotes should automatically maintain tag integrity - at no point in time there should exist notes which have
some child tags without corresponding parent tags. This means that when a tag is added, parent tags of this tag are
also added. And when a tag gets removed, child tags of this tag also get removed.
2) When the user edits tag hierarchy directly like in the examples above, CintaNotes being in doubt should ask
additional questions to determine the best way to proceed.

What do you think?

[mhf]

So here are my considerations:
1) CintaNotes should automatically maintain tag integrity - at no point in time there should exist notes which have some child tags without corresponding parent tags. This means that when a tag is added, parent tags of these are also added. And when tags get removed, child tags of these tags also get removed.

2) When the user edits tag hierarchy directly like in the examples above, CintaNotes being in doubt should ask additional questions to determine the best way to proceed.

What do you think?

I don't yet understand 1) : if I add a tag how would CN know that it is meant to be a child or a parent tag and even if it does know how will CN know what the parent tag should be named ?
E.g. : if I add the tag car, how would CN know that this is a child tag of a (future) parent that should be called vehicle ?

2) - no problem there.

Cheers, Martin.

[CintaNotes Developer]

I don't yet understand 1) : if I add a tag how would CN know that it is meant to be a child or a parent tag and even if it does know how will CN know what the parent tag should be named ?
E.g. : if I add the tag car, how would CN know that this is a child tag of a (future) parent that should be called vehicle ?

The "/" symbol will get special meaning in the tag entry fields. So you will write the tag name not just as "car" but "vehicle/car" in the tags field (autocomplete will help with long parent names). If neither of the tags exist, then upon save CintaNotes will create a top-level tag "vehicle" and "car" as its child. If the tag "vehicle" already exists, "car" will be added as a child to it.

Of course if both tags already exist, you can just write "car", - "vehicle" will be added automatically unless there's another tag "car" somewhere else, in which case CintaNotes will require disambiguation.

You can also add the tags separately and later rename "car" to "vehicle/car".

Also there will be a couple of other extensions, this is how I envision it now:
Now tags only exist as long as there are notes having them. It won't be so anymore, commands "Create tag" and "Create/delete subtag" will be available in the tag sidebar context menu ("Rename" and "Delete" are already available). If you want old behavior, you will be able to set the "Transient" flag in the (also new) tag properties dialog which will make sure tag is automatically deleted as soon as there are no notes having it).

If I have enough time I'll also implement drag and drop in the tag-sidebar, but no promises here

[Noddy330]

Hmm - Thinks - how will this be implememted?
Maybe a note only gets the tags you give it.
But when you search for that tag you get all notes tagged higher (lower?) in the tag hierarchy.
QED?
Nod

[Thomas Lohrum]

Your example raises another question. "ferrari" is a vehicle, a car and a formula 1 team. How to handle the following situation:

Code: Select all

formula1
  ferrari

vehicles
  cars
    ferrari
    honda


Yes, tags must be unique, but in that case the tag is unique within it's group. At last for me as a human reader. Also when i initially created a note ferrari for model f40, this is clearly a car/vehicle. When changing the meaning of the tag, saying ferrari now means "ferrari f1 team", this would just not be correct for the f40 note.

As for your "parent-a" example, i think there should be a tag action "make it a parent tag", right?

[Midas]

One thing is clear for me - in general we cannot count on users building and maintaining a valid taxonomy. Many users will treat tags hierarchy as folder or virtual folder hierarchy, and CintaNotes should not hold some nasty surprises for such users.

I am affraid I can't completely agree with you on this, Alex. No matter how naive or ignorant an user may be, that is still his/her prerrogative... But I understand your position.

1) CintaNotes should automatically maintain tag integrity - at no point in time there should exist notes which have some child tags without corresponding parent tags. This means that when a tag is added, parent tags of this tag are also added. And when a tag gets removed, child tags of this tag also get removed.
2) When the user edits tag hierarchy directly like in the examples above, CintaNotes being in doubt should ask additional questions to determine the best way to proceed.

1) No. Don't remove user input without at least notifying user of the extent of the impending removal and providing for backup -- it's his/her data, after all...
2) Yes.

I was trying to avoid getting into this, but here goes...

The issue here is that the popularity of the tags approach is really a reaction to former content description orthodoxy -- meaning that you had only two avenues to follow, the pre-coordinated description language (i.e., Thesauri like the Eurovoc, for instance), and the post-coordinated approach (sometimes called 'keyword'ing, usually relying upon computer tools for the harvesting, structuring and weeding). But the issue here for the common user isn't the time-frame for the metadata management but the inflexibility of the hierarchies created, whose hindrance factor sooner or later exceeds any help they might provide (usually as soon as metadata maintenance overtakes any usability and retrievability gains -- following a ratio exceeding the squared inverse )...

If you still want to be serious about this path, then you'll be facing a full fledged metadata relationship manager, making (at least) use of prescribed terms (T), non-prescribed terms (NT, usually synonyms, which point to the corresponding T), scope notes (SN, clarifying use of T), and generalizing/specifying relations between T (pointing more generic/specific T, i.e., defining prescribed term hierarchy)...

Enough of this gobbledygook jargon already: it suffices to say that the so called faceted approach is nowadays triumphant over the classic hierarchies... hence the tags success, vouching for more free-from and open solutions -- even if ever they're only sustained by ever growing brute force computer power.

I can not stress enough the enormous contribution of Ranganathan (see http://www.slais.ubc.ca/courses/libr517/03-04-wt2/projects/ranganathan/bio.htm since the elearningspace.com previously provided link is dead); also of interest here for the hardcore hierarchist (as I'm professionally obliged to be) are the tools created by a Canadian specialist, Professor Tim Craven.

[CintaNotes Developer]

Hmm - Thinks - how will this be implememted?
Maybe a note only gets the tags you give it.
But when you search for that tag you get all notes tagged higher (lower?) in the tag hierarchy.
QED?
Nod

This will introduce two levels of tagging: explicit and implicit. I think this will confuse the users and it is better to make all tags explicit. This way you also have more flexibility when you want to move a subtag, but want to keep the parent tags applied (as in the "urgent tasks for project a" example).

[CintaNotes Developer]

Your example raises another question. "ferrari" is a vehicle, a car and a formula 1 team. How to handle the following situation:

Code: Select all

formula1
  ferrari

vehicles
  cars
    ferrari
    honda


Yes, tags must be unique, but in that case the tag is unique within it's group. At last for me as a human reader. Also when i initially created a note ferrari for model f40, this is clearly a car/vehicle. When changing the meaning of the tag, saying ferrari now means "ferrari f1 team", this would just not be correct for the f40 note.

CN will require explicit tag names in cases where there is ambiguity. After entering "ferrari" tag autocomlpete will offer to use "formula1/ferrari" and "vehicles/cars/ferrari". If you don't pick either of them, a new top-level tag 'ferrari' will be created.

As for your "parent-a" example, i think there should be a tag action "make it a parent tag", right?

No, there will be no need for that. Any tag can be a parent by default. All you need to do to add a child tag to it, is to name another tag with its name and a "/" as a prefix.

[CintaNotes Developer]

I am affraid I can't completely agree with you on this, Alex. No matter how naive or ignorant an user may be, that is still his/her prerrogative... But I understand your position.

You don't agree that the users are likely to misuse the tag hierarchy, or that CN should be resilient?

1) No. Don't remove user input without at least notifying user of the extent of the impending removal and providing for backup -- it's his/her data, after all...

But how can I _not_ remove child tags if their parent tag got removed? This will violate the rules of tag hierarchy (or set theory, if you like). Of course CN will warn about pending removal and will give the user the chance to abort the whole procedure.

Enough of this gobbledygook jargon already: it suffices to say that the so called faceted approach is nowadays triumphant over the classic hierarchies... hence the tags success, vouching for more free-from and open solutions -- even if ever they're only sustained by ever growing brute force computer power.

Thanks for a different point of view and for the references. The tag hierarchy I want to build should model the generalizing/specifying relations between tags only. Synonyms and scope notes may come later, but most probably there will be no real need for them.

Do I understand correctly that you are wary of the idea of implementing this feature in CN? I understand that this path can be thorny, but I face the need of organizing tags myself - having more than 100 tags is already unmanageable, and ability to bring some structure to them should be good. There is a reason so many CN users have votes for this idea, after all

[kranor]

I think this discussion is a little bit moot
At the end of the day no matter how you design the system to work people will develop their own ways of using it. (consider the fact that we have had 2 add-ons made already!!)
Personally I think that if a mid level tag is moved then child tags should follow. and if a child tag is moved then links to upper level tags and mid level tags should be broken i.e

1
2
3
4
5
6
7
if we move 4 it should become
1
2
3
4
5
6
7
and if we move 5 it should become
1
2
3
4
5
6
7

I think really that this is the only sensible way of doing this and if nothing else it would give you a starting point for users to try and play with the concept.

[Midas]

I am afraid I can't completely agree with you on this, Alex. No matter how naive or ignorant an user may be, that is still his/her prerrogative... But I understand your position.

You don't agree that the users are likely to misuse the tag hierarchy, or that CN should be resilient?

I am squarely convinced it will be misused, if the slimmest possibility exists, and yet I expect CintaNotes manages to stay resilient even then; I also still totally think user's prerogatives should be upheld, if any broad range support is to be expected...

1) No. Don't remove user input without at least notifying user of the extent of the impending removal and providing for backup -- it's his/her data, after all...

But how can I _not_ remove child tags if their parent tag got removed? This will violate the rules of tag hierarchy (or set theory, if you like). Of course CN will warn about pending removal and will give the user the chance to abort the whole procedure.

I think the set theory approach might provide some answers: for example, if B is a subset of A and A is removed which do you think is more intuitive for the common user? That B is removed alongside A, or that B becomes the new top-level set? (To make this clear, in the second case removal would thus affect only all members of A that are not also members of B...) I'm aware this may contradict the underlying science, but human thought processes are not entirely logic...

In an altogether completely different field of application, please take notice of the various modalities/solutions for referentiality/structure maintenance the developer of freeware Link Shell Extension (http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html) saw necessary to implement, and notice how it takes painstakingly minutious reading to make sense of all the different options? I may be wrong, but I definitely see a common pattern here...

Enough of this gobbledygook jargon already: it suffices to say that the so called faceted approach is nowadays triumphant over the classic hierarchies... hence the tags success, vouching for more free-from and open solutions -- even if ever they're only sustained by ever growing brute force computer power.

Thanks for a different point of view and for the references. The tag hierarchy I want to build should model the generalizing/specifying relations between tags only. Synonyms and scope notes may come later, but most probably there will be no real need for them.

Do I understand correctly that you are wary of the idea of implementing this feature in CN? I understand that this path can be thorny, but I face the need of organizing tags myself - having more than 100 tags is already unmanageable, and ability to bring some structure to them should be good. There is a reason so many CN users have votes for this idea, after all

I feel your pain. For what is worth, I think a visual management interface (think 'mindmapping') would probably be the best form to solve this...

And fair enough, before that I was just replicating the standard 101 theory -- to avoid any charges of obfuscating the matter or spreading FUD. But I am wary of the foreseeable implications, since I would rather like to see CintaNotes evolve to become the absolute top of its class, instead of some rather good but idiosyncratic application with a steep learning curve, where casual newcomer mistakes are paid dearly, turning them away from further use/exploration (plenty of those around).

To cut a long story short, I'd advise very much against an 'omniscient' developer stance here, since what's evident for some is totally opaque for others... One thing I know (let me profit from whatever credit I have here) is that this is a thorny path that leads into muddy waters... it could easily put you in a 'world of pain', so to speak... but your judgement will rule, won't it?

[DONN]

It wouldn't matter too much which hierarchy you chose if you did something like Google does and included an over-ride symbol that users could attach to a tag. I'm thinking of the + and - tags. Perhaps the + would be all you would need. Except I guess it would have to work a little differently for Cinta than Google.
Instead of + for "always include this word", it would have to be "put + before any words you need grouped together."

[CintaNotes Developer]

I'm really sorry guys that I had to withdraw myself from this discussion for some time. I'm ready to continue now)

Personally I think that if a mid level tag is moved then child tags should follow. and if a child tag is moved then links to upper level tags and mid level tags should be broken

Yes, this is the way I intend to implement it. And you are right that if something about this feels wrong, people won't hesitate to tell us about it;)

I am squarely convinced it will be misused, if the slimmest possibility exists, and yet I expect CintaNotes manages to stay resilient even then; I also still totally think user's prerogatives should be upheld, if any broad range support is to be expected...

There's no arguing about that but what exactly do you understand under "users prerogatives"?

I think the set theory approach might provide some answers: for example, if B is a subset of A and A is removed which do you think is more intuitive for the common user? That B is removed alongside A, or that B becomes the new top-level set? (To make this clear, in the second case removal would thus affect only all members of A that are not also members of B...) I'm aware this may contradict the underlying science, but human thought processes are not entirely logic...

For the common user the former approach would be less unexpected since it will model the way how folders behave in the filesystem.
But also in the strict science sense: when you select the set A and select the "remove" command, you are basically saying "remove all notes from the set A" (I admit this is not how tags behave now, now only the tag is deleted). Now if there were some notes which belonged to set B, but didn't belong to set A, set B would continue to exist. But by your definition B is a subset of A. This means, that after the notes are deleted, there will remain no notes from the B set, which is equivalent of deleting set B as well.
So yes, this is how I would expect it to work: if B is a subset of A, it will be deleted when A is deleted.

Okay, now let's get back to the "delete only the tags" mode (when you right-click on a parent tag and select "remove").
Here I would also argue that all child tags should be removed, just because people would expect that to happen. Or a question
can be popped up, asking wether the child tags should be removed (I think this is the best approach here).

Please note that B can be a de-facto subset of A even if they are on the same level in the hierarchy - this will happen if all notes tagged B are also tagged A. So the tag hierarchy will not only define the "strict" subsets, but also impose the set "ownership".

In an altogether completely different field of application, please take notice of the various modalities/solutions for referentiality/structure maintenance the developer of freeware Link Shell Extension (http://schinagl.priv.at/nt/hardlinkshel ... llext.html) saw necessary to implement, and notice how it takes painstakingly minutious reading to make sense of all the different options? I may be wrong, but I definitely see a common pattern here...

Are you sure the analogy is valid here? We just have one object: tags and one kind of relationship: parent-child.
There, he has to deal with symlinks, hard links and junctions - that's quite a zoo

I feel your pain. For what is worth, I think a visual management interface (think 'mindmapping') would probably be the best form to solve this...

Frankly, I've always disliked mindmapping - probably because it's basically a glorified hierarchical list with some unnecessary 2D drawing freedom (which is more distracting than it is helping..) But again, I'm no specialist here and this is just my personal experience. You're welcome to prove me wrong.

To cut a long story short, I'd advise very much against an 'omniscient' developer stance here, since what's evident for some is totally opaque for others... One thing I know (let me profit from whatever credit I have here) is that this is a thorny path that leads into muddy waters... it could easily put you in a 'world of pain', so to speak... but your judgement will rule, won't it?

Well if I was feeling "omniscient", I wouldn't start this thread in the first place Don't worry, if I see that the feature can't be implemented in an easy to use and transparent way, I'll scratch the code and get back to the drawing board without hesitation)
On the other hand, I want to avoid the "designed by committee" syndrome, when no one is taking responsibility for difficult decisions and the product slowly degrades into an amorphous blob of cryptic functionality..)

[CintaNotes Developer]

It wouldn't matter too much which hierarchy you chose if you did something like Google does and included an over-ride symbol that users could attach to a tag. I'm thinking of the + and - tags. Perhaps the + would be all you would need. Except I guess it would have to work a little differently for Cinta than Google.
Instead of + for "always include this word", it would have to be "put + before any words you need grouped together."

Hi Donn,
I'm not sure I understand your idea. How would the "+" sign organize tags into groups? Would it turn the search box into some kind of command line? Mind that we want these groups to be persistent.

[david_c]

If B is a subset of A, and you delete A, 3 outcomes regarding B are possible:

1) Ask the user if he/she wants to delete B.
2) Delete B unless it belongs to another parent tag.
3) leave B intact as an orphan tag.

#1 is disruptive and the user may later need to retain B.
#2 is also dangerous because it leaves no tracks.
#3 is too messy.

Suggested solution to resolve all 3 issues:
Add a new "Orphan Tags" category to the Edit" or "View" menu.
When this is selected, only the orphaned tags are listed in the sidebar. The user could then decide which to retain or delete permanently.

Such an approach seems to be a clean and safe way to handle this particular problem.