Tags & Attributes tools

I wonder if a ‘Tag to Attribute’ conversion tool might not be useful?

If a Tag could be converted to an attribute, then the value of both tags & attributes would be enhanced.

  • Consistently setting an Attribute would become easier. (Create a Tag, do an extended selection {or filter}, apply the Tag, convert the Tag to an Attribute)
  • Filtering on Attributes is difficult. A Tag equivalent would add this functionality.
  • Overly long Tags lists could be dynamically simplified.
  • WIP Tags could be converted to Attributes thus causing less clutter in charts or final output of graphical reports & the Narrated Website. Then converted back to Tags to continue work.
  • The covert persistency of Attributes and the overt accessibility of Tags would become interchangeable.

Possible options:

  • Applying custom filters for the Tags of objects (or secondary objects enclosed by filtered primary objects)
  • segmentation by object Type
  • Have a corollary functionality that set a Tag for every object with a specific Attribute
  • Option to clear (or keep) the originating tag/attributes being converted
  • RegEx Pattern matching for the Tag name or Attribute Value (e.g. all Tags with ‘Import’ )
  • Select Originating & Target from list of Existing Tags/Attributes
  • Use the originating Tag name as the target Attribute Value
  • Create a new (override) Tag name or Attribute Value as the target
1 Like

There is a Set Attribute tool A filter on a Tag can be set to add an Attribute.

There are two major drawbacks.

  1. The set attribute only works on People records.

  2. Once a certain attribute Type is set, running the tool to set a new Value under the same Type, the tool will edit the existing Attribute and not add a new Attribute with the same Type and a different Value.

2 Likes

@cdhorn has proposed a Tag view be added for the 5.2 version of Gramps.

I wonder if this means that GEPS 11: Tagging should be re-visited?

There are several things about the Tag implementation that is rough around the edges.

The way that Tag colors are defaulted to black hides one of the great values from new users: colorizing list rows for organizational purposes. It could cycle through the spectrum of colors in the Colors tab of Preferences. (The too-narrow scope of the labels makes developers overlook how these color swatch spectrums could be more broadly leveraged for feature that run in parallel. Currently, they are only used in Charts view. But they could be used to control Pins in Geography view, Tags in list view, And so forth.)

My biggest concern with Tags is that applying one modifies the Last Changed stamp of records. This make applying Tags during import a REALLY bad idea. You lose the ability to find the newest data. And you would not want to use them to create a Worklist for the same reason.

Should not Tags be given Gramps IDs if they get their own view? And they probably need a Tree hierarchy if some of the Discourse forum postings accurately reflect the sheer volume of Tags people are adding. And the ability to be hidden.

1 Like

I use Tags often, but I only use them to assist me, the user, as I flesh out my family tree/history. I do not use tags to permanently store genealogical data. For something like that I use the Attribute.

The only major enhancements to Tags I would like is to have Tags that are specific to the view. Tags for People, Families, Places, etc. With maybe a few universal tags that can be used in all views. Create a tag in a view, the tag belongs to that view. Create a tag on the Dashboard, it becomes a universal tag.

When I first started exploring @cdhorn’s CardView, the first thing I did was to squash tags showing in all the views. Thankfully he had programmed that functionality.

1 Like

My use of Tags is similar to @DaveSch’s. For me Tags are work-in-progress tools flagging the progress of my research. If some “property” is to be permanently attached as genealogical data, I use an Attribute.

A record in “final” state ends up with no Tag. By “final”, I mean I have full factual knowledge about a person (birth and death records) or family (spouses, marriage record, children). Notes (anecdotes, oral tradition, special facts, …) are not counted in “final” state and can be added freely.

A special “no posterity” Tag (family without children, person) displays the records gray in list views. There is also a “no hope” Tag when records have been destroyed or are considered definitively missing so that the lines are broken without any hope to follow them.

Other Tags are “new” when nothing is known yet about the record apart from skeleton data (person, family), “partial”, “restricted” when privacy law forbids access to data (then my descendants will have to do the job if they are interested), …

Each of these tags has a specific colour so that I can see at a glance where to focus my attention.

Everything which is related to the records themselves (not to the way I work) goes into an Attribute.

Personally I segregate Tags and Attributes and I won’t use a conversion feature between them. But as experience shows, there are many ways to use Gramps and what a user does is not the same as another user.

Technically, since an Attribute can have several possible values (e.g. Eye colour or Size), how can this be converted to a Tag? A Tag has no value, contrary to an Attribute. Squatting the colour property of a Tag to store a value could work for integer numeric data but not for string.

1 Like

This is exactly how we intended tags and attributes to be used.

In addition to indicating research status I tend to use them for grouping if I want to pull up a list of all my revolutionary war ancestors, or presidents to whom I am related, and things of that nature.

An Attributes Gramplet might be beneficial for entering the data similar to the data entry Gramplet. Just a thought.