Most DAM's allow you to setup custom metadata fields which allow you to create your own templates. Usually you can then embed that custom metadata into the XMP of a file, most DAM's support lots of metadata standards and its not usually restrained to just IPTC. Have you spoken to your vendor? Be great to understand what you are trying to achieve, Im happy to help or put you in touch with people that have far greater knowledge than I. Good luck.
Apologies I only read up to your IPTC line and just expanded the rest of your post. What you are asking for seems totally possible, you usually do a search and then use filters to display the required content, from here you should be able to export report but it all depends on the vendor's functionality. If the vendor has an API you may also be able to create your own reports based on your criteria.
We are working with the vendor. They are working to get it the way we’re looking to get it. But they seem a bit surprised at how we’re using it. When they saw that we were really almost not using keywords or the caption field at all and instead created fields for almost everything and prepopulated most of them with enforced metadata language it surprised them. So it just got me wondering if the way we’re looking to use it is different than the way most of the industry uses it or if it’s just our vendor having a very specific workflow that they designed around.
The tricky bit about metadata tooling is that Photoshop and Bridge only supports IPTC , which is intended for a limited subset of usecases, far less than most organizations need. These tools have no facility for displaying custom metadata schemas other than looking at raw XML. Using custom fields in DAMs, if they support XMP at all, at best specify their own custom XMP namespaces, which means you have to be in the DAM to read and work with the metadata. The two approaches I've seen are to either go with DAM custom fields and limit yourself to working within one DAM, or to try to cram things into a vocabulary of key-value pairs in the keyword field: "ethnicity-white", "ethnicity-asian", etc., and rely on the naming convention. This means foregoing many of the advanced search capabilities of your DAM, and hoping they have good tools for filtering/grouping/reporting with keywords. Schema.org makes an attempt at creating standard schemas for common subjects. For your purposes, it includes Patient, but Patient/Person only has nationality, not ethnicity. In any case I don' t know of any DAM tools that read schema.org schemas yet so it's a moot point. In short, schemas are hard--your choice is between being fit-for-purpose and tied to a tool, or being free from lock-in but limited in what you can accomplish. Also, hire a librarian to guide you through this—not a DAM vendor.
We have a librarian helping us with this. She is the driving force behind most of our schema. Her recommendation was to go with fields, not just for reporting purposes, but also to allow the user easier accessibility to the information about the subjects in the image. We photograph our own patients so its important for people viewing the image to see at a glance what their condition(s) is, who their care team is, whats departments they've been seen by, what staff or family members are in the picture, etc. There would be an immense amount of metatdata in the keywords field if we went with the keyword approach so we chose to reserve that for descriptive words that don't fit into the clinical, demographic areas (Things like hat or scarf or bubbles). One issue we're having is that the reports in the system are single image focused rather than entire system focused. In an attempt to keep speeds fast reports are based on searches and limited to 5000 assets. We need to run reports on the entire asset library. And we need these reports to be able to compare multiple custom fields.
Fields definitely makes sense for your usecase (though I pity the poor intern who has to enter all of that data for each image). Reporting in DAMs is typically an afterthought compared to search. If the DAM doesn't have sufficient reporting tools, don't let them bilk you for an extra $100k to build something custom when it should be built into the product. Instead, consider getting something like Jasper, Metabase, Tableau, or some other lightweight BI/reporting framework and point it at the database underlying your DAM. (And tell the vendor to build it as a proper feature.. mention the possibility of leaving a review on Capterra or G2Crowd and their ears will perk right up).
Maybe I'm not understanding your point here @joshwand, but this statement seems just completely incorrect: "The tricky bit about metadata tooling is that Photoshop and Bridge only supports IPTC , which is intended for a limited subset of usecases, far less than most organizations need. These tools have no facility for displaying custom metadata schemas other than looking at raw XML. Using custom fields in DAMs, if they support XMP at all, at best specify their own custom XMP namespaces, which means you have to be in the DAM to read and work with the metadata." The Adobe CC toolset fully supports XMP custom schema, which we have been utilizing for years with our clients. Adobe developed XMP internally,, and then submitted it as an ISO standard that was approved in 2012. XMP custom schema is a perfect way to handle unique schema scenarios such as a hospital vs. a retailer, while still maintaining accessibility to that metadata in both the Adobe suite and in almost all modern DAMs.
You're correct, Adobe CC does support custom XMP panels across its apps, but you have to deploy them to all the desktops that might need to read/write that metadata, which is a non-trivial exercise, and doesn't readily extend to external collaborators (agencies, photographers, etc). You'll need to have a very good integrator (like @ericfulmer !) to make this work, as chances are slim you'll find anyone at a DAM vendor who has a clue about this.
Just to clarify @joshwand's statement, the metadata itself travels within the file header and is available to any application that is "XMP aware." Adobe's specific implementation of XMP in the Creative Suite & Cloud requires metadata "templates" to view the XMP fields in a "pretty" way (the raw XMP data is always visible via File/Info). Distribution of metadata templates to anyone in the ecosystem (internal teams as well as external collaborators) is a once-and-done exercise easily automated via a scripted installer, so it takes the local user about 20 seconds to set up. As long as the XMP schema remains constant, this is not a major barrier to utilizing XMP for this purpose.