GNOME Bugzilla – Bug 338558
fully-qualified tag uniqueness (multi-inheritance of tags)
Last modified: 2018-07-12 00:08:57 UTC
It would be nice to have duplicate tags, with the tag stored being the full path to the tag. i.e. consider the following situation. model boats -boat1 --construction -boat2 --construction It would be nice to have the construction tag twice.
Wouldn't it make more sense to have: Boats: Boat 1 Boat 2 Boat Phases: Planning Construction Maiden Voyage ? :) The only reason I can see that being limiting right now is that F-Spot doesn't allow for ANDing tags - but that should change soon. Allowing tags with the same name complicates the mapping between F-Spot hierarchal system and flat systems.
I guess that would work. Just isn't as intuitive to my brain.
But how do you resolve this Person: Paris Places: Paris With Paris like Paris Hilton and Paris, capital of France ?
Changing title to reflect that tag (inlcuding its parents) should be unique. Not just the end tag.
I don't think I want to change away from the unique name only approach otherwise we quickly have problems converting back and forth between keywords (which are all most metadata systems allow these days) and f-spot tags.
Larry (comment #5), What about writing the fully-qualified name for the tag in metadata ? as suggested in bug #345505 ? For now, as we only export tags in metadata, allowing duplicate won't break anything... I'm currently working on a patch to solve this 'duplicate tag names' issue, but it need a little more work to have the TagTyping tab completion running fine.
Stephane, (comment #6) > > What about writing the fully-qualified name for the tag in metadata ? as > suggested in bug #345505 ? This bug seems to be about WiFi problems and not F-Spot. Which bug are you thinking about?
my mistake. instead, read bug #345405
I just started importing my collection of concert pictures (five years, 7000+ pics) to F-Spot, and this issue is a real stopper for me. I have lots of pictures of the same bands playing at different venues, and bands playing twice at the same festival. The way I organize my pictures: festivalX>2003>friday>smallstage>bandX [..] festivalX>2003>saturday>mainstage>bandX [..] venueX>2006-11-10>bandX I don't see any way of doing this with the current system without making it look ugly (like appending a number to the band name). To take it a step further, shouldn't it be nice to be able to organize by leaf-name? In my previous example it would be possible to browse my collection this way: bandX +-festivalX>2003>friday>smallstage +-festivalX>2003>saturday>mainstage +-venueX>2006-11-10 But maybe that's something for a search function.
Intead of tagging in a way that seems to be replicating a directory structure, eg festivalX>2003>friday>smallstage>bandX wouldn't it be better to tag like this festivalX > smallstage Bands > bandX Days > Friday Years > 2003 The way F-Spot treats tags and the tag hierarchy, the first method doesn't make sense, because subtags are assumed to have a "is a subset of" relationship to their parent tag (and smallstage is not a subset of friday, but of all the stages). You can then find your photos with the query festivalx & 2003 & friday & smallstage & bandX
Well, that makes sense. I used directory names as tags in Picasa, but this way it's much better. Thanks for the reply.
I think the problem is, that until now tags and hierarchy in the sidebar are mixed together. But that's not the meaning of tags. Tags describe certain properties of a picture and the system of tags should be flat. The hierarchy in the sidebar then should come from different combinations of tags. Actually it's what happens if I make a query. So, what is shown in the sidebar shouldn't be the tags, but it should be saved queries. For the example with the bands we could give the following tags: picture 1: bandX, smallstage, festivalX picture 2: bandX, mainstage, festivalX picture 3: bandY, mainstage, festivalX The hierarchy in the sidebar could be one or more of the following: hierarchy 1: Festivals festivalX smallstage bandX (saved query: bandX, smallstage, festivalX) bandY (saved query: bandY, smallstage, festivalX) mainstage ... festivalY ... hierarchy 2: Bands bandX festivalX smallstage (saved query: bandX, smallstage, festivalX) mainstage (...) festivalY ... bandY ... The hierarchy now would be totally independent from the tags and could easily be changed if one decides. It avoids the recurring dragging and combining of tags everytime I want to see bandX on smallstage at festivalX. It also avoids the suggested same-name tags. I have seen some other bug-reports which address similar problems and I think it could be solved with this solution.
Maybe this is a documentation problem? The original poster had a suggestion. The very first comment suggested a better way to use tags and the original poster liked the suggestion. I have seen a few articles with tagging recommendations. Much of the current documentation tells you how to do something, such as add a tag. There is almost no documentaion telling you why you should do it and the best way to do it. My 85 year old mother-in-law would not know a tag if it bit her and could care less about them, but a few examples and recommended best practices would go a long way helping her understand why I think they are important and might have helped the original poster avoid the problem he had.
I know the original poster liked the suggestion he was given. Actually I just didn't want to start a new thread, because there are already so many threads about tagging issues. And most of them arise in my opinion because the tagging system is not fully satisfying. No offense, I really like f-spot and I think it's one of the best photo-managing applications these days using it for my 5000 photos (perfect compromise between ease of use and functionality). But f-spot claims to be intuitive, so more documentation may be the wrong way. And the suggestions especially in comment #10 is to build a query out of different tags every time I want to see a special event (which means 5 drag'n'drops in this case). A single click in an hierarchy which already has the query is easier, more efficient and way more intuitive at least in my opinion. It's what's also done in music players using the id3tag information (eg Rhythmbox, iTunes...). The "intelligent songlists" are queries which hold different filters for playing songs that meet the criterias. Well, it's just a suggestion and I'd be glad to hear counter-arguments.
*** Bug 429780 has been marked as a duplicate of this bug. ***
*** Bug 556698 has been marked as a duplicate of this bug. ***
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.