Am Montag, 8. Juli 2013, 18:42:53 schrieb Alexander Wagner: > On 07/05/2013 10:40 PM, David Vincent-Jones wrote:
[...] > >> 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. > > It currently /IS/ Dublin Core (DC simple to be a bit more > precise). That's the point. While DC is nice for exchange as > it defines the most simple scheme applicable to everything > (and thus any decent scheme should think about a mapping to > DC), it is no good idea to build a database on top of DCs > obvious limitations for the description of complex entities. > It is just as it's name suggests: simple. The reason I didn't implement more than a subset of DC is that I personally don't use these things and was more interested in providing some infrastructure to handle this stuff. Before anyone decides to add more fields (which would be quite easy) we should seriously review and discuss the design choices I did back then. Maybe some things should be done differently, maybe some can stay the way they are handled right now. [...] > There're actually several interesting things concerning > metadata in dt's readmine, many of them unfortunately quite > old. True, mostly because we developers don't use these things. At least that's my guess. Once the design is solid the actual coding should be simple and well encapsulated so it would be a nice task for someone who wants to start contributing. *hint* > >> 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? > > You miss the point here. Sure I can search for a tag delete > it, even delete the whole chain, and assign a new one. > > What I was talking about was the management of a controled, > structured, hierarchical, vocabulary. Ie. if I change the > ordering in the /vocabulary/ by e.g. hooking up another > layer or moving an entry around, then that change in the > vocabulary should get automagically transfered ot the > indexed images. Computers are quite good at that. Unfortunately it's not that simple. You can change the tags that are assigned to the images that you currently have in your DB, but these changes will not be applied to images that are currently not imported but have the corresponding tags in their sidecar files. So you would end up with inconsistent tagging. IMO that's even worse. So again, there needs to be a solid design how to do it. Just starting to write some code that allows to rename a tag and change all images in DB accordingly would shortsighted and ill advised. > [...] > > > I am sure that the db will change over time > > Sure. Unfortunately, metadata are not very attractive for > most of the people. :) [...] Tobias
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
