Add details to tagging section import export

[grubernd]

Add description what import file formats are understood.

[elstoc]

Looks pretty good to me. @phweyland as you're the tag expert would you mind taking a look at this for me please.

[phweyland]

Excellent. That's good for me too. Maybe it's worth to add the fact that synonyms are also treated {xxx}.

[phweyland]

I have just seen the last changes. That seems technically OK (but on mobile without computer, I may be mistaken). However it would make more sense to me to use "places" instead of "Austria" as a category example.

[grubernd]

However it would make more sense to me to use "places" instead of "Austria" as a category example.

From a pure structural approach, maybe. But in my opinion that would void the examples showing the difference between the two formats and their result after import. I tried to pack as many potential information in as short examples as possible while reusing the "places" idea from up the page.

[phweyland]

I think it's just a matter of exchanging the role of places and Austria. The first set would be:

[places] 
places|Austria|Graz
places|Austria|Vienna

The second set: [places] Austria __Graz ____Vienna

The 2 sets give the same result except that the second one creates also places|Austria.

Should cover the items you wanted and it's also a nice example of category usage.

[grubernd]

.. and that would exactly negate the whole point of showing how different the import of darktable vs Lightroom style look after the import. So no, I am against such a change.

[phweyland]

Can you explain?

[grubernd]

My example was chosen to show the effect of "every line a tag" where imports from Lightroom style will create an extra tag for parent nodes. That might not matter for a small example like here, but when you e.g. import a full geo-location list with thousands of entries and instead of having a single tag you end up with an extra – potentially never to be used – tag for every level of nodes you have in your hierarchy, that are a lot of items.

I consider that an important hint in the manual for the user to see and being made aware of.

[phweyland]

Ok, that exactly what does show also my version. Instead of places the lighroom example adds places|Austria.

[phweyland]

Your example is wrong in two ways. As already said it unlikely corresponds to a real use case. And then it's useless to add the line [places|Austria] as the nodes which are not a tag are already considered as a category.

The right way to demonstrate your view could be this one. First example:

places|Austria
places|Austria|Graz
places|Austria|Vienna

Second example:

[places]
__Austria
____Graz
____Vienna

In the first example we create only the needed tags. "places" is a node treated as a category.

In the second example all the nodes of the tree are created and "places is set as a category.

In both examples we get the same logical result. The second example creates more tags.

[grubernd]

The only right workflow is the one that works .. drumroll .. for you. Everything depends on your use case.

I use tags where the full node-path is set as a category to organize my stuff internally while avoiding export to tags. I might have to write a tutorial on how to use hierarchical tags set as categories for IPTC export without cluttering the keywords output. Short version: [places|Austria] is needed as a sole category because not every picture can be assigned a city, but something like "Austria" in the tags is unwanted clutter.

So .. no, my example is not wrong, it represents a very valid use case. So please do not try to dumb things down, give the user who reads the manual some credit.

[grubernd]

And no, I do not wish to discuss this further. We are entering bike-shedding territory here. I would prefer @elstoc to approve and merge the edits. Anyone not happy with examples should open their own PR.

[elstoc]

I'm not the expert on how tagging works, hence my ask for @phweyland to review, and I really haven't followed these discussions. I'm not sure I'm comfortable merging without some consensus on what's needed here because I can't adjudicate as to who is right.

[grubernd]

I hope that Philippe and I can agree that noone is right here. It's different views on the same topic with varying use cases.

But as the one who put in the effort to write this part of the manual, I plead to stop the discussion over minute details of abstract examples and call it a day.

[phweyland]

I'm also tired of this conversation.

To propose something does not give you any right.

I'm questioning your example to make it understandable for the reader. The examples are not for you.

@elstoc, Sorry I'm not sure I can help more. Apart the examples, which would need explanation not to be misleading, I think this is good stuff.

[quovadit]

Some questions:

1. how (and why) do you set Austria as a category?

When attaching the tags places|Austria|Graz and places|Austria|Vienna there are only these 2 tags in the db.

places|Austria (and places btw) are no tags, they are free nodes and by implication categories displayed italic in the tree-view.

But when exporting the tag list, there is no [Austria] with brackets because it is no tag set as category but just a free node.

2. How do I get a file in darktable tag format?

   "darktable tag format : The tag hierarchy is written in a single line where nodes are separated by the pipe symbol."

3. Why are categories even necessary for your description?

In my opinion the easiest example to show the difference between dt and LR would be just the 2 tags resulting in 4 lines in lightroom format which leads to 4 tags when (re-)importing this file to dt.

[grubernd]

Some questions: how (and why) do you set Austria as a category?

Because I want to. =)

I am not here to bikeshed those examples any more than we already have done before.

Accept or change.

[quovadit]

This was no critique at all, I really want to understand it! I don't understand the usecase, why Austria should be a category, and I failed trying to reproduce your example.

In order to accept or change, I first have to understand. That's why asked my 3 questions.

[github-actions[bot]]

This pull request has not had any activity in the past 60 days and will be closed in 365 days if not updated. Please verify it has no conflicts with the master branch and rebase if needed. Please add a comment if you need help or give permission to other people to finish your work.

[github-actions[bot]]

This pull reguest has not had any activity in the past year has therefore been closed.