GNOME Bugzilla – Bug 345405
Write tag hierarchy to the XMP part
Last modified: 2018-07-12 00:02:21 UTC
When writing the tags to the XMP part in the photo, F-Spot should also write the Tag hierarchy. For instance, if we have the following tag hierarchy Places Country Australia City Melbourne People Family Daughter And we have a photo of Daughter, taken in Melbourne/Australia. Instead of writing only the tags (Australia, Melbourne, Wife), also write the Tag Hierarchy. This could be done as follows: Tag Australia --> "Places","Country","Australia" Tag Melbourne --> "Places","City","Melbourne" Tag Daughter --> "People","Family","Daughter" Yes, it would take a bit more space, but a complete re-creation of all the tags and their hierarchy could be restored by simply importing a photo. Embedding the Tag within quotes ("), and separating the tags with a comma (,) would ensure we do not have to use some special characters. This enhancement bug is created from a request in bug #342137
No comments on this one? Time to look at this one a bit more I think now, since F-Spot read the stored tags now.
Could we end up with contradicting tag hierarchies when importing different photos? For example, when "city" is renamed to "town" or removed between two photo taggings. Photos A contains: "Places","City","Melbourne"; Photo B contains "Places","Town","Melbourne"... What happens now with re-import?
I'd like to support this feature request. I would be usefull when exporting to Flickr by example. About the potential problem when importing, I think it could be solved by implementing a "tag merge"
I would really vote against this idea - I have frequently reorganised the heirachy of my location based tags (see also bug 170314 on using the relevant XMP/IPTC field for the location). For example, once I have a lots of photos from a given location (say "South England") then I might break up that tag into the counties ("Kent", "West Sussex", ...) or simply "South East", "South West". Thus: Beachy Head, South England, England, Places Becomes: Beachy Head, East Sussex, England, Places Or perhaps: Beachy Head, East Sussex, South England, England, Places Another example, suppose I have several tags under "Events" for friends weddings, say "Jill's Wedding", "Frank and Anne's Wedding", ... and I decide to introduce a general "Wedding" tag under events: "Jill's Wedding", Events "Frank and Anne's Wedding", Events becomes: "Jill's Wedding", Weddings, Events "Frank and Anne's Wedding", Weddings, Events Now, if I then move any of these JPG files between machines, or re-import them from a backup, the contradicting tag hierarchies issue raised in comment 2 would be a pain. Another example of how easy it is to get a conflict, in the original report Bengt's example used a photo tagged with "Melbourn" and "Australia". In his heirachy that means: i.e. "Australia", "Country", "Places" and "Melbourne", "City", "Places" Storing just the two basic tags "Melboune" and "Australia" would make it much easier if I wanted to import his photos because my heirachy would be: "Melbourne", "Australia", "Places" There is also the major issue of how other tools would try and interept a stored "Tag Hierarchy". Old versions of F-Spot would treat this as single long tag which contains quotes and comments. In the absence of a globally accepted standard can't we just keep things simple?
*** Bug 509777 has been marked as a duplicate of this bug. ***
I think writing a hierarchy is probably a bad idea (for the reasons listed above), but I do think F-Spot needs to have a way to easily write the whole hierarchy of tags to a given image if desired (the reason I personally would like it is for export to Flickr). Take this example: I have a photo of the Empire State building, and I wish to tag it. I have the following tag hierarchy set up: Places > North America > United States of America > New York > New York City > Manhattan. Now, I can easily tag that image "Manhattan." Within F-Spot, I can filter by Manhattan and it will show up. I can also filter by North America and it will show up. However, a problem arises when I go to export my photo to Flickr. Because of the fact that it is only tagged with "Manhattan," and Flickr has no idea what my F-Spot tag hierarchy is, another user who is looking for a photo tagged "New York" won't ever stumble upon my photo. There are probably quite a few ways to handle this, and I wouldn't be surprised if there was a standard for exactly this situation, but here are a few options off hand. 1. Have an option in the Flickr export dialog to "Export tag hierarchy." Currently, there is an option to "Export tags." This option would be disabled until the "Export tags" was enabled. When this was selected, if a photo was tagged as Manhattan in F-Spot it would tagged as "Places, North America, United States of America, New York, New York City, Manhattan" in Flickr. 2. Have an option in F-Spot to always recursively tag. In this case, if I tag a photo as "Manhattan" it would tagged as "Places, North America, United States of America, New York, New York City, Manhattan." For simplicity, this is a one time event and the removal of the tag "Manhattan" after this has happened would not remove any of the lower levels. 3. Same as 2, but keep a record of if a tag is user created or automatically generated. Whenever a change is made to the tags of an image, check to see if the automatically generated tags are still valid. I have no idea how this fits into the metadata standard; this would likely be something that is handled within the F-Spot internal database. Thoughts?
I would vote for tag hierarchy with using a special charactes, such as '/': Then the tags would be: Places/Europe/Italy/Rome instead of just Rome. There are pros and cons for both the cases, the current one and the proposed one, it could be an option (GUI or gconf)
Is there a standard way of storing hierarchical tags in XMP? We're only supporting this if it helps others. Also, no configuration option for stuff like this, unless you can demonstrate how it fits in the vision statement: http://f-spot.org/Goals
(In reply to comment #7) > I would vote for tag hierarchy with using a special charactes, such as '/': > > Then the tags would be: > Places/Europe/Italy/Rome if this is not a standard, this will end in an horrible tag handled by every other program/website. The first proposal is the best, imho
Some tools use '/' others use '|' A rather old article can be found here: http://www.dharma-blues.com/eng/2008/09/04/hierarchical-keyword-madness-in-digital-photos/ It has to be checked for other tools. The tools that know nothing about tag hierarchy will display the full path (not that bad) instead of having to make each hierarchy change in each and every tool used. Instead, the tools that know about hierarchy, will import the exported photos perfectly. When we change the hierarchy of the photos in one program we will see the updated one in the other program. Also, as a result we can have the same tag name under different categories, like the Places/Paris People/Paris example
Hm. Reopening as I think the question raised in comment #8 has been resolved.
There is the standard proposed by the Metadata Working Group: mwg-kw There is the defacto standard used by Adobe: Xmp.lr.hierarchicalSubject In both cases, I have provided working patches to exiv2 to write to these.
exiv2 0.25 was released on June 21 2015 with support for the following hierarchical keyword properties: Metadata Working Group keywords: nested in the form - Keywords -- Hierarchy --- <Property> Digikam TagsList: '/' separated Lightroom hierarchicalSubject: '|' separated mediapro and expressionmedia CatalogSets: '|' separated ACDSee categories: complex XML-like structure MicrosoftPhoto LastKeywordXMP: '/' separated The lightroom format seems to be a defacto standard, many photo management applications use that format.
F-Spot has moved to https://github.com/f-spot/f-spot/issues If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.