keywords in LightRoom
oak at uniserve.com
Tue Oct 6 11:20:42 EDT 2009
On Tue, Oct 06, 2009 at 09:14:14AM +0200, AlunFoto scripsit:
> 2009/10/5 Graydon <oak at uniserve.com>:
> > That "tree" is really an acyclic directed graph,
> I'm sorry, I think we belong to different tribes... :-)
Oh, quite possibly.
> > and because of the
> > one-and-only-one-path property of those graphs (there is only one way to
> > get to any node in the graph from the root of the tree), if you move
> > "leaves" like that, you're defining a different node, because it has
> > different ancestry.
> Ah! You belong to the Object-Orientation tribe, don't you? :-)
Actually, no. They're over the next hill. I'm from the Functional
> Sorry, just teasing. Don't put too much into the allegory. I don't
> think fancy explanations for why it doesn't work is actually
> necessary. The most important thing is to know why things work the way
> they do.
Which is what I thought I was talking about.
> By what I do for a living, I have to deal with dynamic controlled
> vocabularies. The "dynamic" thing is what set my thoughts spinning re:
> LR too. At work we define a plethora of business rules to deal with
> it, in terms of "Change Control Procedures", "latency times" and so
> on. We also have ways to encode the status of different values in the
> hierarchy, like "temporary" and "deprecated".
> At the end of the day, you need rather complex XML for exchange
> formats, and rather complex applications/databases to keep track of it
> all. Far beyond the current scope of the keywording in LR.
> What could amend quite a lot of the issues for my own part, though, is
> an option to mark certain keywords as "deprecated". Meaning that they
> are still searchable and show up in the hierarchy with statistics, but
> are not possible to assign to new photos.
I'm surprised that isn't in there already, and it certainly ought to be
fairly easy to add.
Maintaining a taxonomy of labels, long-term, is a lot more work than
most people expect it to be, I find. Rather like terminology for
indexes and similar, even if you don't have to translate it.
More information about the PDML