Nothing of course is perfect in all respects but my management teachings have always emphasized a philosophy of "adapt or perish" and in that I try to utilize (and maximize) with the available resources.
On 13-07-05 09:54 AM, Alexander Wagner wrote: > On 06/30/2013 05:36 PM, David Vincent-Jones wrote: > > Hi! > >> The concept that dt has little or no database management >> capability is wrong wrong wrong! > > I never said that. > > The weakness is /not/ the concept. One could discuss the > weak coupling from xmp to raw, but once the stuff is in the > db I am perfectly fine with dt's concepts of displaying > information and searching the db. > > The major weakness is the dublin core simple metadata scheme > applied in dt. This just that just misses crucial fields. > Expand that to a more decent scheme (IPTC is there for a > reason) most of the issues are gone. Yes, Dublin Core fields would be a bonus .... I agree. > > Besides that, GUI for adding keywords is suboptimal. Here a > simple substring search instead of only searching the > beginning of a chain (a currently open bug, AFAIK) would > already help a lot. I have no problem in that area ... sub-string searches work well on my system. > > One should think about displaying hierarchical structures as > a hiearachy. Why is this working for search but not for > adding keywords, e.g. Give my vocabulary a tree structure + > the ability to start typing a word to come up with all > matching terms and this gets quite fast in a slick GUI. > >> I am a 'refugee' from Digikam and certainly in earlier >> days I had many misgivings over dt's way of approaching >> this area. it is different; that I will give you; it also >> requires adapting to some new thinking. > > I admit, not to me. I just miss some fields and a bit of GUI > polishing. > >> I now manage my files as a whole and not as individual folders. > > Having them organised in (meaningless) folders is just very > handy for backups. My folders represent the size of one > external medium, nothing more. > >> Collections spread over the system become more cohesive. > > This is a nightmare for backups ;) So I have some struture > here. This is a difference in our visions. I maintain multiple comprehensive backups over two systems and I sleep well at night. > >> Layered tagging >> reduces the clutter of exhaustively long lists. > > I always used what you call "layered tagging". Though I call > it hierarchical keywords, and I admit I do /not/ use tags > but only keywords from a normalized set (vocabulary), so I > call it "indexing". I do sometimes have a need to reindex/retag (or whatever name one wants) and find this very easy to accomplish in dt. Am I the only one? I suspect that since dt's system has very rapidly evolved without a published set of 'master instructions for use' most of us have, on the fly' determined how to best adapt the system to our specific needs. Those who arrive, from other more highly structured and documented systems, can certainly find this problematic. > > Keeping such a vocabulary at bay is one of the other > functions missing in dt's metadata area. Sometimes you have > to add terms and later on you find that you didn't come up > with the proper relation so you need to change the ordering > in the hierarchy. Would be great if this could work by D&D > in the vocabulary tree and it get's assinged to the images > in question. (Well, I have a dream ;) > > Anyway, concerning your example of what you call layered > tagging: > > France|Paris|Churches|mice > > is IMHO suboptimal, as it mixes various concepts in one > keyword chain. This is not good and thus should be > separated. The concepts in question here are a location, a > type of a building, and some mamal. One can argue about the > usage of pluar or singular, I tend to use the latter. To > "tag" (I don't like that word and it' very concept, > "indexing" is a far better concept) that, I'd use at least > > Location|France|Paris > Building|Church > Mamals|Mouse > > This would allow you to search for all mice in Paris but > also in New York e.g. You only need the mouse-chain for this > concept, while in your handling you'd have another one > USA|New York|mice. > > To come to my mentioned weakness of dt here. In this example > I "like" (in my index it is more elaborated, but for the > example it's fine) the two chains > > Building|Church > Mamals|Mouse > > I absolutely dislike > > Location|France|Paris > > as there're decent, normalized, defined fields for exactly > these conceptis in IPTC Core > > IPTC Location / Country > IPTC Location / City > > To improve on your tags I'd further like to have > > IPTC Location / Sublocation > > to give the name of the Church in question (most likely it > doesn't fit into the title tag and even if it's not the > place where it should live as title is another concept). > Addtionally, > > IPTC Location / CountryCode > > can be very handy if you've a lot of traveling stuff. (3 > keys normalized). > > Of course I could model that as > > IPCT|Location|City|Paris > IPCT|Location|Country|France > IPCT|Location|CountryCode|FRA > IPCT|Location|Sublocation|Note Dame > > But this spoils interchangabilty, as not other tool will > know how to handle those chains, while almost any other tool > will know how to extract the city et al from the IPTC core. > > So for sake of interoperability one should add the decent > vocabulary to dt. You of course are right ... and so (I believe) am I. ......... I am sure that the db will change over time to suit more users needs as has the rest of the program but the perfect model that suits all users will still be an illusion. David ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
