Tags and Attributes

[InjAnnuity_1]

Often, after using a tagging scheme for awhile, one realizes that a Tag (or group of Tags) makes more sense as an Attribute. One can easily define the desired Attribute, but converting the data becomes a tedious and error-prone manual task.

Conversely, an Attribute may make more sense as a series of Tags, esp. a Hierarchical series.

Conversions should be non-destructive, in case of mistakes. That is, don't automatically remove the old data. The user should have the opportunity to review the results, and revert them, if a mistake is found.

It would also help if an OPML Import could recognize and use the existing user-defined Attributes, instead of always defining its own. However, by converting the offending (duplicate, Imported Attribute) into a set of tags, and merging from there into the desired Attribute, one would at least have a workaround.

I should add, it should be possible to change the definition of an Attribute, and (in most cases) still preserve the Attribute values. For example, one may discover that what they thought was a single-choice Attribute should have been multiple-choice, or vice versa. Or what was Imported as a Text attribute really should have been single-choice, or boolean.

[Telesto]

Often, after using a tagging scheme for awhile, one realizes that a Tag (or group of Tags) makes more sense as an Attribute. One can easily define the desired Attribute, but converting the data becomes a tedious and error-prone manual task.

Conversely, an Attribute may make more sense as a series of Tags, esp. a Hierarchical series.

Same insight here . Often preferring using attributes instead of tags. I'm slightly more radical, not using tags at all, because I have hard time inventing the tag structure in advance. And if I start changing things (like adding additional tag type) I land in the tedious and error-prone manual task of adapting each and every note... But well slightly off topic

I should add, it should be possible to change the definition of an Attribute, and (in most cases) still preserve the Attribute values. For example, one may discover that what they thought was a single-choice Attribute should have been multiple-choice, or vice versa. Or what was Imported as a Text attribute really should have been single-choice, or boolean.

+1

Sidenote: Adding/ Removing or re-ordering the the in multi-select list attribute while entry's of the list being used already is a bit scary. It caused dataloss for me, in the sense that used attribute of the multi-select list got reset for all my notes

[InjAnnuity_1]

Adding/ Removing or re-ordering the the in multi-select list attribute while entry's of the list being used already is a bit scary. It caused dataloss for me, in the sense that used attribute of the multi-select list got reset for all my notes

This is what I would expect, if the list items were referenced purely by position instead of by value. (I will probably test that idea later.)

That works, IF you get Attribute definition exactly right the first time, or if you only ever had to add or rename a value. If you ever have to evolve the Attribute, by inserting, deleting, or re-ordering Attribute values, then MyInfo will need to know which of those things you are doing. Otherwise, it would not be able to adjust the references accordingly.

Unfortunately, we are not the only ones defining Attributes. Often, we get them from external sources, who can change them at will, with no prior notice or permission. So we may have no choice but to evolve them.

For this reason, I am starting to prefer Hierarchical Tags, instead of Attributes, for now. I will experiment with them further.