StrumentiResistenti
Too many levels in triple tags, IMHO
In my humble opinion, triple tags have got too many levels / directories:
- namespace
- key
- operator (eq, lt, gt, inc)
- value
Could we maybe get rid of the operator level / directory? Do you use it regularly and extensively? In my view, it adds too much complexity. Everytime, I add a new tag (key+value) to the same file, I have to click/go through all these levels again. If I give three extra tags, I have to go through 4x3 = 12 levels, of which the operator takes three, although the operator is always "eq". AFAIK, you could achieve "lt"/"gt" also with bash, e.g. by specifying /home/user/tagged_files/audio:/time_of_recording/{2005,2006,2007}/@/ Isn't it GNU/Linux philosophy KISS - keep it simple and stupid? Thank you in advance for your opinions!
Also, as the title says, they should be triple tags (with three levels), not quadruple tags (with four levels).
Of course you are aware that the fourth level you're referring to is not a real level, because it's an operator. So the name of triple tag still holds.
I do personally use the operator especially with date and time. In other dimensions the gt and lt ops are less useful, but there the inc operator is handy to find tags that include a string in their names. But I do agree with you that an operator would be unnecessary for direct match (equality) only. So if the user does not need the other ops, he or she could find interesting a command line option to disable them. Implementing this feature implies a lot of rework in the parser code and in the RDS layer, but it's doable.
I would like to argument on you example. You write that the lt and gt ops could be replaced by a set syntax, like in:
tagged_files/audio:/time_of_recording/{2005,2006,2007}/@/
Omitting the fact that an open interval can't be represented by a set (i.e. lt/2005/ or gt/2007/), your syntax is typical for a shell user, but very impractical for the filemanager user. The string {2005,2006,2007} is a token inside a path for a filemanager and if the software does not provide the possibility to write paths by hand, the user is unable to enter the previous query. I know: I'm a command line user too, but I strongly feel that a compromise on this had to be done.
I'll keep tokens in a query independent from each other to ease the inputting from any kind of interface, but I'm positive on the possibility of optionally disable the operator in triple tags with a command line switch given at mount. However I have very scarce time to implement this kind of feature in the next months. If you feel comfortable with C and Tagsistant, please try and send me a pull request.
Btw, KISS means "keep it simple, stupid". There's no "and" because "stupid" is intended for the developer, to kindly exhort him or her to keep its design simple. No one would ever be in favor of a "stupid" design. ;-)
As an additional element, I'll add that a feature I'm thinking about since long time is a pluggable API for ontology. It's clear that a date can be described as:
time:/year/eq/2000/time:/month/eq/01/time:/day/eq/01/
or without the operators:
time:/year/2000/time:/month/01/time:/day/01/
But this way doing a comparison between two dates is really painful. How about a time:/ companion plugin that defines the date/ key and applies special semantics to it? With such a plugin, comparing two dates could be much easier:
$ cp file.mp3 store/time:/date/eq/2000.01.01/@/
$ ls store/time:/date/lt/2002.01.01/@
but even more interesting:
ls store/time:/year/lt/2001/@
because the time:/ plugin knows how to compare time:/year/ and time:/date/. The plugin would be called when building the SQL query that involves a time:/ tag, providing the right SQL syntax. What do you think about this?
To expand what I've written on your example, the set syntax is good and is already available in the query DSL. However an interesting extension could be making it available for key values, as in your example:
store/time:/year/{/2001/2002/2003/}/@/
This still preserves the token independence principle but also provides a set syntax for multiple values of a key. By the way, using the slash to separate values and braces just adds two characters more than your proposal:
store/time:/year/{2001,2002,2003}/@/
Sounds like an acceptable compromise?
You had some really good arguments, sounds good what you are proposing. Unfortunately, I am studying something quite different to programming and have to learn for some tests. That's why I don't know much about C, and also wouldn't have much time to code and help. Thank you very much anyway for your commitment, I'll be patient!
Another argument in favour of operators is the possibility to write check queries. And while I write this, I propose another operator to negate a triple tag. Assume that a ne/ operator exists for matching all the keys that have a value different from that provided in the query:
store/time:/year/ne/2000/@/
Used with eq/ on date/ keys, this operator would allow you to spot semantic inconsistencies in your repository:
store/time:/date/eq/2003.01.01/time:/year/ne/2003/@
Clearly this query should return no results, because it does not make any sense to tag an object as date = 2003.01.01 and year != 2003. If you find such an object, you could correct its tagging. Btw, your proposal in issue #31 would be very useful, because using the move approach to retag a file does not make any sense in this contex:
$ mv store/time:/date/eq/2003.01.01/time:/year/ne/2003/@ store/time:/date/eq/2003.01.01/@/
will not remove the undesired time:/year/ tagging.