GNOME Bugzilla – Bug 364047
Store Places (and others) related tags at correct XMP field
Last modified: 2018-07-01 09:05:08 UTC
Right now F-Spot stores Country, State, City, Location as a normal Subject Bag (tag). These should be stored on the appropriate XMP place. const string Credit = MetadataStore.PhotoshopNS + "Credit"; const string Category = MetadataStore.PhotoshopNS + "Category"; const string Source = MetadataStore.PhotoshopNS + "Source"; const string State = MetadataStore.PhotoshopNS + "State"; const string Country = MetadataStore.PhotoshopNS + "Country"; const string City = MetadataStore.PhotoshopNS + "City"; const string Location = MetadataStore.Iptc4xmpCoreNS + "Location"; const string RdfType = MetadataStore.RdfNS + "type"; One way to fix this would mean modifying the Tag handling a bit to ensure special tags will always be found, no matter which language. Also, those tags should not be possible to delete (move perhaps, but not delete)
when we were discussing the import patch originally this is one of the issues that came up. If we were to end up doing this the way to handle it would be to associate certain tags with specific XMP predicates. This would be interesting to do with other predicates as well. For instance people could point to foaf entries. I'm not against this idea but it definitely requires real design thought.
See also: Bug 170314 – Option to see Country, location etc tags
Just an idea that would be relatively easy to implement for the time until a better design is ready: In the tag property dialog, a new selection could be added: "This tag is a [keyword]" Default could be "keyword" to keep the current behaviour. Other options would be "Location", "City", "Country", "State", "Source", "Category", "Credit", "RdfType". Instead of "This tag is a" one could also state "This tag denotes:" or some other sentence provided by a native english speaker could provide. Just giving a tag a bit of knowledge about what it describes would have some advantages. It would keep the user's freedom to build a tag tree without constraints regarding names and structure. By default, nothing would change at all, keeping happy users happy.
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.