{"action":"created","issue":{"url":"https://api.github.com/repos/oniony/TMSU/issues/22","labels_url":"https://api.github.com/repos/oniony/TMSU/issues/22/labels{/name}","comments_url":"https://api.github.com/repos/oniony/TMSU/issues/22/comments","events_url":"https://api.github.com/repos/oniony/TMSU/issues/22/events","html_url":"https://github.com/oniony/TMSU/issues/22","id":56098460,"number":22,"title":"Tag grouping","user":{"login":"0ion9","id":115782,"avatar_url":"https://avatars.githubusercontent.com/u/115782?v=3","gravatar_id":"","url":"https://api.github.com/users/0ion9","html_url":"https://github.com/0ion9","followers_url":"https://api.github.com/users/0ion9/followers","following_url":"https://api.github.com/users/0ion9/following{/other_user}","gists_url":"https://api.github.com/users/0ion9/gists{/gist_id}","starred_url":"https://api.github.com/users/0ion9/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/0ion9/subscriptions","organizations_url":"https://api.github.com/users/0ion9/orgs","repos_url":"https://api.github.com/users/0ion9/repos","events_url":"https://api.github.com/users/0ion9/events{/privacy}","received_events_url":"https://api.github.com/users/0ion9/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-01-30T23:19:38Z","updated_at":"2015-02-04T12:05:51Z","closed_at":null,"body":"To be quite clear, **this issue has nothing to do with the upcoming release of 0.5.0**. I was thinking about implementing this myself as an extension, and then started thinking about whether it might belong in core TMSU.\r\n\r\nThe basic idea is that many kinds of files which may be tagged can usefully be said to have 'groups' of tags.\r\n\r\nFor example, supposing you have a photo collection including, among other things, photos of Alice and Bob. Alice and Bob are often seen together in these photos. Alice doesn't wear hats as a rule, but Bob does. Being able to group tags, like `{alice hat}` and do group queries '{alice hat}`, allows you to find photos where -Alice- is wearing a hat, as opposed to (a few pictures with Alice wearing a hat, hidden within hundreds with Alice and Bob being both in the picture, and Bob's usual hat being in the picture); The logical grouping {alice hat} is more useful in this case than the undifferentiated 'alice bob hat'\r\n\r\nHopefully, the mechanism described above is quite simple and obvious: each file has an arbitrary number of groups, identified only by ID number, and each group has an arbitrary number of tags. One might propose that 0 is a valid group id, which can be logically thought of as 'anything else' (that is not otherwise in a logical grouping. For example, the background in photos is usually not going to be worth grouping tags in, it might reasonably be seen as an undifferentiated set of tags like 'beach sand palm_tree tree water sea plane'. \r\n\r\nOne complication that may not immediately be obvious with the above is that you may want a tagging to participate in multiple groups -- certainly, there is no guarantee that only one person in a photo is going to wear a hat.\r\n\r\nThe obvious implementation, AFAICS, would expand the file_tag table to have four fields and use all four as a compound PRIMARY KEY, similar to the current implementation with tag values.\r\n\r\nThe non-obvious implementation might separate tag groups into a separate (group_id, tag_id, value_id) table, with each unique set of tag=values occurring exactly once, and then have file_tag be keyed only by (file_id, group_id). This is rather more radical, I mention it mainly because I think it has better performance characteristics for querying.\r\n\r\nThe most complicated part would be querying; specifically, querying at an acceptable speed. The mentioned table refactoring is the only way I have seen so far to minimize use of recursive SQL queries -- it would allow finding the groups which match the query (recursively) in the most likely much smaller (group_id, tag_id, value_id) table, and then non-recursively finding the (file_id, group_id) tuples which reference one of those group_ids. However, this would make normal ungrouped queries more complex to perform. (It also probably wouldn't be that fast for cases where many groups match the query)\r\n\r\nThere are significant technical challenges involved, however I felt I should propose the idea so that it can at least be considered."},"comment":{"url":"https://api.github.com/repos/oniony/TMSU/issues/comments/72843824","html_url":"https://github.com/oniony/TMSU/issues/22#issuecomment-72843824","issue_url":"https://api.github.com/repos/oniony/TMSU/issues/22","id":72843824,"user":{"login":"0ion9","id":115782,"avatar_url":"https://avatars.githubusercontent.com/u/115782?v=3","gravatar_id":"","url":"https://api.github.com/users/0ion9","html_url":"https://github.com/0ion9","followers_url":"https://api.github.com/users/0ion9/followers","following_url":"https://api.github.com/users/0ion9/following{/other_user}","gists_url":"https://api.github.com/users/0ion9/gists{/gist_id}","starred_url":"https://api.github.com/users/0ion9/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/0ion9/subscriptions","organizations_url":"https://api.github.com/users/0ion9/orgs","repos_url":"https://api.github.com/users/0ion9/repos","events_url":"https://api.github.com/users/0ion9/events{/privacy}","received_events_url":"https://api.github.com/users/0ion9/received_events","type":"User","site_admin":false},"created_at":"2015-02-04T12:05:51Z","updated_at":"2015-02-04T12:05:51Z","body":"Yes, in general I had considered that an object would usually be identifiable by its tagset; in cases where this is not true, AFAICS it would usually be desirable to address objects by id number, as this is the usual approach to object instancing. As I implied, I'm aware of the \r\n\r\nPersonally, I find the prospect of naming each object tedious. This may be because I am more focused on a GUI type of application (using dmenu or lighthouse as a wrapper around TMSU tagging) and so have the presumption that selecting a group is easy. OTOH, it seems that ZSH completion is a comparable tool to this  (describe -1 with a list of its member tags beside it, -2 ditto...)\r\n\r\nThe `-a,b,c` syntax was a logical progression from -1 style type syntax that identifies an object by id, but when I think about it I agree it is not that intuitive to pick up.\r\n\r\nThe `$FNAME#bob` syntax is interesting for the single-group case. \r\n\r\nYou write:\r\n`tmsu tag /home/paul/scene.jpg country=uk landscape --object=bob hat sunglasses --object=sally smiling`\r\n\r\nPresumably abbreviatable to `tmsu tag /home/paul/scene.jpg country=uk landscape -obob hat sunglasses -osally smiling` ? or `tmsu tag --tags 'country=uk landscape -obob hat sunglasses -osally smiling' /home/paul/scene.jpg`\r\n(i guess so, just wanted to try it out with the different possible ways it could appear.. still seems reasonably intuitive no matter which formulation you use.\r\n\r\n\r\nHm, it just occurred to me that we probably have different preconceptions about the function of this. For example, I proposed numeric ids because transferability between pictures (ie. \"true\" object identity) is not significant to me; but after thinking about what you have written, I suspect that transferability between pictures *is* significant to you: you would want to be able to ask for any files containing a group named bob, perhaps, with the assumption that that is all the same Bob, not a variety of Bobs, and certainly not some person Bobs and some ..hair bobs ;)\r\nIf that is the case, I'll have to think about how those could be optimally reconciled."}}