I have been using IDimager for years and love it for its powerful image database capabilities. One particular feature I just love: label (or keyword) mapping to XMP.
What it is?
Imagine you use hierarchical keywords to catalog your images. So far so good. Lightroom does that very well. Now you have a keyword hierarchy "photographer - Tom Taylor". You add that keyword to all the photos that Tom Taylor took. But there is also a metadata field for the creator of those images. Would it not be neat if adding the keyword "photographer - Tom Taylor" that metadata field "image creator" actually gets assigned "Tom Taylor" automatically. That is what label mapping does - in IDimager it fills the XMP metadata fields with catalog keywords (called labels) automatically as soon as those keywords are assigned to an image. The user can customize any keyword so that it is not just used as part of the catalog but also written into the corresponing metadata field.
This means, instead of having to fill metadata fields with custim templates simply cataloging your images, tagging them with keywords, will do the job.
Would be really neat to have such a feature implemented in Lightroom as well....
let me ask a stupid question: are keywords not written into XMP ?
Do I understand your proposal correctly, that I would have the same meta-content twice afterwards: once inside the IPTC-fields, once as keywords?
Your filling method would be convenient if one needs the IPTC-fields filled. But do you?
I had the feeling they were intended as a standard to describe images, but somehow abandoned by *public interest* ...
keywords are written do xmp, but xmp includes may other fields, noy just keywords [In fact lightroom writes them in a proprietary fashion, as l"ightroom keywords", in a hierarchcical fashion quite unlike most other programs do, a problem when you try to have other programs read lightroom keywords, but this is quite another topic...].
Anyway - xmp field are essentially text fields for fo specific purposes, like a text field for "country", "creator", "copyright", "copyright notice", etc. etc.
Now, you are right, of course, that one xmp field are "keywords" and mapping some keywords to specific other xmp fields seems at first somewhat redundant. If you already have a photographers name as a keyword, why repeat it in the xmp field "creator"?
XMP fields serve quite a different purpose than just plain, simple keywords. XMP fields are more specific. A textual description of a photo, for example, is not quite the same as a keyword. A copyright notice can describe specific usage terms, such as whether you are allowed to use a photo under a particular creative commons license, or if you have to ask the creator of the photo for permission etc., etc. I find these fields very useful and don't think they should be abandonned. Yes, tagging photos with keywords is powerful and indeed for the purpose of getting your photos organized, databaseing your files, for that purpose alone, kewords seem quite sufficient. However, if you want to describe photos better and share their metadata with others, XMP is much more powerful.
A simple example: a lot of people use iTunes. If you look at the metadata of an iTunes music file you see that it uses quite a few descriptive fields such as the name of a band, the name of an artist, the title of a song, etc. If you share that file with a friend, his or her iTunes library can read the same data and, even better: because of the name of the field where the data is stored, that program will "understand" what that data refers to. Therefore you can download a song in iTunes and it will "tell" you what song it is, who plays the song, etc. etc.
Even if that friend of yours does not use iTunes, he is likely to use other software that will equally be capable of extracing that same metadata stored within the appropriate fields. His iTunes library (or whatever other program) will also know, that an "artist" is an "artist" and a "title" is a "title". These fields are therefore more valuable than simple, plain keywords, they are not just tags, but they are descriptive labels, they describe the files, because these specific fields have names that indicates what their content actually means. To extrapolate this example: what keywords in lightroom are more like playlist in iTunes. You may have some of your own playlists "songs for the beach" or "songs for long car drives", but your friends may use different ones. Nevertheless your songs of Bob Dylan are songs of Bob Dylan as well, when your friend imports them in his/her iTunes library.
All that descriptie stuff that can be categorized, does not work quite that well with keywords. You and your friend might decide to use the same kind of label hierarchy, the same kind of playlists, but he also might decide to use some different ones. That is where metadata fields come in handy, they are more powerful than simple keywords...
Now, mapping keywords to specific xmp fields only works for a few fields. You might decide to map the keyword "France" to the xmp field "country", but nobody will have a keyword "A spring landscape in southern France before the sunset" being mapped to the xmp description field... Although you might have a longer keyword mapped to copyright notice? Perhaps...
Anyways, like I said. I am using IDimager for databasing my image files and find the option to be able to map keywords to specific xmp fields very powerful. You say "I had the feeling they were intended as a standard to describe images, but somehow abandoned by *public interest* ..."
I believe the opposite is true: they are being abandoned not because nobody is "interested", xmp tends to be ignored (sadly) because most software makes it so difficult to use these fields. The way metadata panels work in Lightroom, Photoshop and Bridge is really, really cumbersome. No wonder nobody bothers. And these programs dominate the market. Partially for a good reason, they are powerful programs, still they fail miserably when it comes to efficient support of xmp. It is a bit of a shame, because xmp could be really powerful... Why Adobe developed such a fantastic standard and then decides not to support it with powerful software is a bit of a mystery to me...