I agree that if XMP can support this then it should be used. However – and this may highlight some ignorance on my behalf – I can’t see how XMP really helps. As I understand it XMP allows you to store data inside a file that can then be used by any application that is XMP compliant. My issue is more to do with where I get the data from, not where I put it!
What is needed is a tidy way to select from vocabulary set(s) and put data into various existing fields, such as location and keywords. If you take the US example I’ve taken pictures in 12 of the 50 states. That gives me 12 templates to start with. When I was in Las Vegas I took pictures of about 10 of the casinos. Now the number of templates starts to go up! We’d have USA/Nevada/Las Vegas/Bellagio and USA/Nevada/Las Vegas/Mirage and so on. I reckon that just for Country/State/City details I need maybe 200 templates. If you add location to this then it starts to get unmanageable, but only because everything uses a flat structure.
Now if, taking Bridge as an example, there was a way of structuring the selection of templates then it would make life so much easier. So when I append Meta data instead of a massive flat list I see Country, with choices hanging off of this for each country. Each country would then have a choice of states, and each state a choice of cities and so on. It would be similar to the nested menus in Windows routines – I guess there’s an Apple equivalent. The question is how to control this structure. If Bridge has to build it by looking at all the templates it's an overhead, plus the structure is based on how Bridge thinks it should be done. So what about using directories to provide the tree structure? Then the structure would up to us. We could create, to a standard layout, exchangeable vocabularies. These would be XSL’d into appropriate templates. They would then need to be put into a directory tree of our choice. Then cataloguing could really begin!
So my template for Yosemite National Park could be in USA\California\Yosemite or National Parks\USA or indeed both. This then gives me the flexibility to work the way I want to work. It also allows for different types of template, work and pleasure, to be easily kept apart.
I’d also prefer if the template name came from a field within the template, rather than the file name (use rdf:about ?). This is because the file names out of XSL process would probably be long e.g. USA_California_Yosemite National Park_Half Dome.xmp could come from the following vocabulary snippet:
<Description>Country / State / City/ Location</Description>
<Value>United States of America</Value>
<Value>Yosemite National Park</Value>
It would be XSL'd into the following template:
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.2-113">
<rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="" xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/">
<rdf:Description rdf:about="" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/">
<photoshop:Country>United States Of America</photoshop:Country>
<photoshop:City>Yosemite National Park</photoshop:City>
You could handle internationalisation with this by creating separate templates for each language and having root directories called English, Francais, Deutsch etc.
I'm learning to use iView at the moment. Found out the other day that it can see the templates I set up in Bridge. This means it would need the exact same change as Bridge to also use the tree structure. I wouldn’t have thought that too hard? But then what do I know!