Thanks for the explanations. It seems the difference is hard to understand without trying it. Does declare mean I cannot write a|b|c but have to “declare” a| and a|b| in a separate dialog, but I still can enter a as a tag?
a tag a|b|c|d created (declared) alone provides an explicit keyword d and three implicit keywords (*) a, b and c.
if you want a to be a category you have now to create (declare) the tag a and set it as a category (or collection in your words or helper for others).
(*) before the change a, b and c were implicit categories.
NB: if you create a|b and a|b|c|d, then set b as a category, a will be an implicit category, b an explicit category, c an implicit keyword and d an explicit keyword.
Does that help ?
1 Like
Yes, thank you so much 
. Seems we will have the manual ready if we continue like that 
.
With collection I meant a tag “search” in the collect images module. Now, the only missing link is how categories affect the search in this module and the wildcard handling there.
implicit wildcard (not needed), search is done through full tag names (whatever category or keyword) and synonyms. EDIT: in tagging module. this is different in collect module (which has not changed and doesn’t know the notion of category nor synonym).
1 Like
Big thank you again. To answer your original question for the user perspective, I think I don’t care as both seem not to change my workflow in darktable. But still, the new tagging features ahead are great!
This post to provide some more information about new tagging categories coupled with metadata export configuration.
In the hierarchical view of tag dictionary the user can set any tag (at any level) as a “category”.
The main point to remember is that a category is never exported in a tags list (xmp.dc.Subject or $(TAGS)).
So the first application is to use category to structure your hierarchical tags without polluting the exported tags list.
Example: in places|India|Tamil Nadu|Kanchipuram|Kamakshi Amman Temple
I set “places” as a category (displayed in italic), keeping the four next levels as normal keywords (as such they will be exported in tags list (xmp.dc.Subject or $(TAGS)).
But you can make an ad hoc usage of this structure at images’ export time.
In metadata configuration the formula $(CATEGORY0(places)) provides “India” (to be placed in a country related exiv2 tag) or $(CATEGORY2(places)), “Kanchipuram”, (to be placed in a city related exiv2 tag)
The second usage of category is to define the metadata you need in your specific workflow(s) and to deal with exiv2 tags only at images’ export time. (This covers pretty well some lr collection use cases as well).
For example you can have two categories “agency” and “creator” in which you list the needed names, set also as category.
In that case they will appear in image information like this:
And of course you can use them in formulas at images’ export time.
NB: The list of exiv2 tags, usable in formulas, is today limited to the most current tags but it is easy to add new ones in future dt updates. Exiv2 site gives the complete list. A lot of them can be added to the dt list without any other change.
NB2: tagging module is not suitable to add free text metadata (i.e. specific to each image) like title, description, comments …
I hope that helps.
3 Likes
@phweyland will you also be able to use those category tags in the export dialog as part of the export file name?
1 Like
Yes. The variables $(TAGS) and $(CATEGORYn(xxx)) are available for file name too.
2 Likes