Trying to come back to the thread... Mmmmm, I find your opinions founded and interesting... However still my proposal is not so complex as the level the discussion reached. Long story short:
- Automatically tagging (liked the word tag you have been using) assets based on the timeline hierarchy everybody shares and, - Additionally, if desired and UI/UX aspects prove to be light for the end user, asking for a title for the last time period (remember, year->season->month->week->day->hour...), to provide a "chapter" view of your media (your trip, your visit, your new nephew, your camel ride...). If possible, I would rely just in file-system abstractions to keep it simple and interoperable, my impression is that it is feasible. That is all about it. Some more opinions about the feature as I just described it? Thank you very much for your time and interest in advance. Regards! 2015-03-24 1:54 GMT+01:00 Alexis <[email protected]>: > > Matthew Caron <[email protected]> writes: > > (a) i don't always know ahead of time that i might in future want to >>> reference a file by a particular keyword for which i can create a >>> folder and put a symlink in it. >>> >> >> I fail to see why this is a problem. When you want to add the keyword >> reference, make a new folder. It's like making a new tag. >> > > Creating a new folder isn't the 'problem'. The 'problem' is that i don't > always anticipate the keyword which, in future, i'll have in mind when i > want to find the file. So i might initially associate the keywords X and Y > with a file, and create folders for those keywords; but in the future, i'll > be looking for the file via keyword Z, for which i haven't yet created a > folder, and so which can't be used as a method of locating the file. > > However, i put the word 'problem' in quotes because, of course, this issue > applies to tags as well! So i acknowledge that tags here don't get me > anything that folders+symlinks don't. It seems to me that what i need for > this situation is the ability to do full-document searches - which > obviously i can do from the command line with some form of grep-like tool, > but which i think would be nice to have in the form of an interface within > the oC GUI itself. > > (b) This becomes increasingly unwieldy as the number of keywords/tags >>> associated with a given file increases. With tags (e.g. like in >>> Calibre), i simply add a list of tags to a file, and that's that. But >>> let's say i have four tags, for each of which i want to have a folder. >>> Then the file 'officially' lives in one folder, but i have to manually >>> create symlinks to that file in each of the other three folders. >>> (This is not purely theoretical; i have a document indexed by Calibre >>> with the four tags 'behaviour', 'economics', 'gametheory', 'sociology'.) >>> >> >> So, you write a program to do this to make it less tedious. :-) >> > > Yes, i could do that. i'm a developer and sysadmin, and i've written and > maintained programs - of various sizes - in Perl5, JavaScript, Emacs Lisp > and shell to add functionality to software that was 'missing' in terms of > the preferred workflows of both myself and others. But doing so, and > maintaining them, takes time and resources away from doing other things, > and so if it's possible for the developers/maintainers of a system to > create the functionality i'd like, that's my preferred option. > In this particular context, if tag-like functionality was added to the oC > frontend, which used folders+symlinks as the backend, that would be fine > with me. (Although i'm only familiar with *n*x-style platforms, and don't > know how practical that approach is on e.g. Win systems.) My primary > interest is in having a tag-based frontend, as i've found tags simply too > useful to not care whether they're available. > > > Alexis. > > _______________________________________________ > User mailing list > [email protected] > http://mailman.owncloud.org/mailman/listinfo/user >
_______________________________________________ User mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/user
