File tagging/searching (Was: Now, if DOpus did THIS...)

Does it matter to you whether it's an NTFS command or an Opus description (stored in a descript.ion file that lots of other programs also understand)?

They're both text strings that you can set to whatever you like.

[quote="nudel"]Does it matter to you whether it's an NTFS command or an Opus description (stored in a descript.ion file that lots of other programs also understand)?

They're both text strings that you can set to whatever you like.[/quote]

I think so. Because there isn't an elegant solution yet, and I'm going to have to cobble it together, I might have to reorganise my folder hierarchy around a fair bit. I'd already done an experiment with descript.ion files... if I write comments on a bunch of files in the same folder, all the comments will be stored on the same descript.ion file. If I then relocate one of those files elsewhere, none of that data travels with it. That just won't do.

If I write to the NTFS metadata, providing I don't relocate the file to a FAT/FAT32 partition, all the data travels with it.

Turn on Preferences - File Operations - Copying Files: Preserve the descriptions of copied files and the descriptions should travel with the files that you copy and move. (Even if you copy/move them to a FAT/FAT32 drive, like a memory card.)

Thanks for the tip! I'm not sure I'm entirely sold on the idea of using descript.ion files, but I'll certainly try it out.

Paraselene.

Jon-

Here is exactly what they are all talking about. And the logic to implement it is clear....er jargonless....

http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html

Looks like implementation details to me. What does it let people do which they can't do already using comments or descriptions and the existing Find (Advanced) tool in Opus?

I don't think GPSoftware need help with how to implement such a feature. They need convincing that such a feature is useful and need to understand what is lacking from the way things are at the moment. For example, Is the problem that the GUI for setting descriptions isn't as good as something that would let you tick/untick tags? Or do descriptions not work well because the get populated automatically with other data in addition to the tags you set on them? Or other things?

Concentrate on "what" and "why", not "how." :slight_smile:

[quote="leo"]Looks like implementation details to me. What does it let people do which they can't do already using comments or descriptions and the existing Find (Advanced) tool in Opus?
[/quote]

I guess it's not what can be done, but how it can be done.

While current GUI is OK for entering comments/descriptions, it is less comfortable fot tagging.
The same goes for searching. It obviously can be done using Find dialog, but it isn't nearly as fe. comfortable as ticking checkboxes in a tree of available tags.
And of course speed of operations must be here.

Personally, I dislike the descript.ion system. I simply just don't want some other files sitting around in my directories. I know I can 'filter' them out through a few means... but I just don't want them. I'd rather have such info stored in metadata tucked away in the MFT or wherever (i.e comments or keywords).

But in whatEVER way such info appeals to others insofar as how and where it's stored, I think a few things that might help ppl make better use of the existing capabilities would be to make relatively minor enhancements such as:

a) offer raw command/function to modify any of those information sources (comments, keywords, descriptions, whatever).

b) offer some other mechanism than 'free text' entry in order to assign tag values... Some users talked about ticking 'checkboxes'. While this might sound trivial, it could be important to eliminate user error. Maybe something like a {dlgchooseM} or some such control code that could display the items like what happens with the dlgchoose and dlgchooseS codes, but in a checkbox style dialog that would let you select Multiple values...

If you had the sort of command options mentioned in (b) above, then we'd do well to have other facilities to make USING multiple selection dialogs meaningful. We'd want to do stuff like:

SetAttr DESCRIPTION {dlgchooseM|Select tag values to assign...|Metal+Rock+Classical+Jazz}
SetAttr COMMENT {dlgchooseM|Select tag values to assign...|Metal+Rock+Classical+Jazz}
SetAttr KEYWORD {dlgchooseM|Select tag values to assign...|Metal+Rock+Classical+Jazz}

It doesn't look like you can 'add' descriptions though... So I imagine we'd need a few MORE extensions to the SetAttr arguments (ADD,CLEAR,SET ???).

Plus, it might be nice to run a Find operation in a way that would let you re-use the same sort of 'multi-select' dialog, but we'd need a way to do so and still be able to easily define whether we want to search for Metal AND Classical, vs Metal OR Classical. I suppose you could do it using filters though... but having to maintain the list of keywords in different 'places' like buttons, context menus, filter definitions, etc could become a pain in the arse... I'm just thinking of relatively basic logical extensions to the current Opus command set that would make heavier and more frequent use of such a 'tag' system a bit easier and faster than lot's of clicking and additional typing in diaogs etc.

If you wanted to go a slightly DIFFERENT way... offer users a way to maintain and display a single GLOBAL list of keywords (in Prefs or something) that could easily be made use of from various commands (like those mentioned here). For the Find operation, it might even be nice to include a 'default' filter that includes all of the keywords from such a global list, which you could load up into the advanced find dialog and just start unchecking/checkign items... btu which you wouldn't have to maintain separately from a 'global' list...

I don't know... just thinking out loud. If GPsoft didn't think ppl would even use such methods, and would still be shouting for crazy database driven meta-management, then we probably won't see any changes...