Peter, I appreciate the MediaBeacon lead and they are in the Adobe XML partners list as well. I had time to go through their website and I like the idea of the web based software. No client software to deal with.

Roger Howard, Thanks for your extensive insights and comprehensive vendors list to research. Would you be willing to elaborate a little more on your dissatisfaction with Extensis Portfolio and why you feel it's falling behind in the market?

Be careful of blanket statements such as Portolio is XMP aware - the devil is always in the detail. While it does have good support for reading and writing XMP format data, that really needs to be broken down into specifics. It will read XMP data which is in the media asset, and its own fields can be made to get data from any specific XMP address. It will write XMP data directly to files too, but only to JPEGs and TIFs. If you are talking sidecar-based XMP, it will neither read nor write it (though I have scripted sidecar creation).

There is a solution via its integration with Version Cue and Bridge, though I think that's only in the more expensive server edition - which is where Extensis are increasingly focussing the product.

>Peter asked: Glad to hear that's working. What kind of business is this in?

I work in a museum. They have a huge database for their artifacts but only images of the artifacts themselves are stored in this database. They resist the idea of calling an image an artifact in its own right. Therefor all other images such as those of exhibits, field trips, brochure and poster shots, production documentation, special events etc. are cataloged in xMedia. This is for two reasons: 1) There is no funding for another expensive database (it's amazing how much money can be sunk into one of those enterprise size databases, especially when you factor in all the training, consulting, database management and IT upkeep they involve)2) No-one on staff wants to learn more operating procedures of another complicated asset management program. The interface and ease of use of a program, especially for people who will not be working with it every minute of the day and for that matter maybe only once a month, is of crucial importance. We've already gone through one other enterprise style database that was eventually turfed because it was so obtuse that everyone was just spending their time finding ways to not use it.

>Peter asked: The other drawback is that as individual users look through catalogs, they can't add their organizational information back.

This would have been great but often it can actually be a benefit that they can't. Not everyone thinks about the information the same way and people sometimes write in the weirdest things (going back to an earlier database where you wrote things into fields). It depends on what they think is important and often they do not look at it from the point of view of a person doing the searching. This can make search results very inconsistent.

>Chip asked: Aniemann, do I understand correctly that you maintain two copies of each file? One in the locked folder and one in the distribution folder?

Yes. Two copies of the database file. The data entry person works with the unlocked version and the rest of the staff always view the locked version. Because the editted file is automatically copied it doesn't feel complicated. However this can be a nuisance when someone else that's an expert in their field should also be editting the info and have to be given write access.

What we are doing with xMedia is definately a workaround but I don't see a better solution for us for now. My ideal would fit the following criteria:- a centralized server style database that was as easy to use as iView/xMedia, - did not need speciallized IT skills to install and manage, - did not cost such an exorbitant amount, - was produced by a company that has a good chance of being around for a while - had as large an information/user base as iview/xMedia so we wouldn't need to always hire expensive consultants to come figure things out for us.

I'm generally loathe to pan products in public forums, particularly as an existing customer. That said, my career has given me access to a range of products (DAM and otherwise) - from the extremely high-end enterprise solutions, to workgroup and desktop products, to open source projects from the tech world and academia & cultural heritage. Among other things, I spent 5 years in one of the major museums in the US, working on DAM (and collections management) so I'd be more than willing to share my thoughts from my time in that particular field - we had sizable budgets, but I also advised smaller institutions without the same level of funding, so I'm familiar with DAM projects in cultural heritage even where there is essentially no funding. I'm also quite familiar with the push and pull of DAM vs Collections Management.

I would say that having an existing collections management practice and system can greatly streamline your DAM operations, since much of the metadata you'll want attached at the image level is already provided in the collections catalog at the object/artifact level. In the end, you may *well* be able to get away with a much more modest application with minimal cataloging tools, and a focus simply on providing the search/browse function for your image library. The DAM, if it's limited to collections object media, can largely be auto-populated with metadata from the CMS. If this was your approach, an application like ResourceSpace and maybe a few weeks of development by a savvy young Web developer, may give you a system you can load pre-named files into, and through integration with your collections system automatically tag and organize your assets. There may be a handful of additional, asset-level fields you might need to collect, but if you already have a collections system then you should be leveraging the data they already capture.

As John said, XMP support is not black and white - Portfolio, for instance, can read and write XMP, but has a number of limitations - one of the toughest is the inability to map a single Portfolio field to multiple embedded fields, so it's all but impossible, without custom scripting, to write say an image name to the several XMP and IPTC-Core, and IPTC-IIM fields that data should be embedded in... in other words, it's basically impossible to follow the guidelines of the Metadata Working Group in writing metadata from Portfolio without custom scripting (via VB or AppleScript).

Feel free to contact me offline if you'd like to share notes at some point on museums and DAM.

ResourceSpace has limited XMP support - it's free (and open source) and has a pretty active community of developers around it. It's not quite in the same league as those above, but it's a nice little product that looks like it's going to do well... would be great in some environments, for instance - not a production DAM but looks great for exposing a collection at a small institution to internal and external users.

ResourceSpace's metadata support is improving quickly. The method is highly unique and flexible, yet quite simple in concept. It features:

-the security of knowing that your original assets will always be left untouched, in case metadata writing corrupts a file (which can happen any time a file is modified). The metadata write happens upon download, so if the downloaded file is corrupt, the original asset is still accessible.

-Exiftool, which efficiently reads an enormous quantity of tags from all kinds of files, and writes to many formats.

-The ability to map any tag in a file to any ResourceSpace field.

-The ability to map multiple tags to the same ResourceSpace field. So, for example, you have a few places to pick up a Caption depending on different files you have, and ResourceSpace will attempt to level the field by writing its extracted info to all of those tags upon download.

-Different Resource Types can have different mapping strategies.

-A metadata report gives a full exiftool report on the original file, showing all possible metadata that could have been indexed, sorted by metadata type (IPTC,XMP,EXIF, etc). It also shows which tags are mapped to which RS fields, and a diff report showing how any tags have been subsequently modified in ResourceSpace fields (which gives an indication of how the file will be modified on download).

-ResourceSpace fields can be mapped to custom XMP panel tags. With a modification of the exiftool config file, it can also write to those fields.

I'm looking for feedback about how to improve these features even more.