So far, most of the schemas I’ve been describing are ones that are not application specific. There are, however, plenty of schemas out there that are specific to a particular application. There are also plenty of tools that allow you to make your own metadata schema that is specific to your personal or institutional needs. Let’s take a look.
Application-specific metadata
Some applications support their own metadata schemas. This may be done to facilitate functions that no other metadata schema can support. Adobe Camera Raw Settings are an example, providing a way to note each rendering control in the program. Capture One does a similar thing with its rendering settings.
In order to be portable, this application-specific metadata needs to be exportable in some way, usually as XML, JSON or XMP. In most cases, the best way to do this is to embed the information in the file as XMP-formatted tags,or in a sidecar text file. In the figure below, we see how Photo Supreme writes the category metadata.
Here is category metadata from Photo Supreme, using their ICS notation. Notice that the application associates a unique identifier with the tag so that it can tell one instance of “Maddy” from another one. This structure can also support multi-level hierarchy.
Here is the XML notation that Capture One uses to save rendering settings.
Adobe metadata
Over the years, Adobe has created its own metadata schemas, which started by supporting the Dublin Core fields. As with Dublin Core, some of the Adobe schema has merged into the IPTC mothership, while some of it is specifically for Adobe software. Adobe-created fields include Ratings, Hierarchical Keywords and the Mark as Copyrighted fields.
Hierarchical keywords
Let’s take a look at the way that hierarchical keywords work, since it’s a different type of tag structure than Star Ratings or Mark as Copyrighted. The Hierarchical Keywords field actually functions as metadata about keywords (metametadata?) Let’s see how this can work.
There are four people in the image below, and each is tagged with a keyword that lives in a hierarchy. This hierarchy helps to define exactly what the keyword means.
The keyword hierarchy defines the relationship between these keywords (and is a representation of the relationship between these people). If we want to preserve this relationship in the metadata, we need some way to make a note of it. This is what the Hierarchical Keywords namespace does.
When you write this metadata out to standard “flat” IPTC keywords, the relationship between keywords is not recorded. Writing the hierarchical keywords to the file helps to preserve the relationship between the various keywords. The figure below shows the relationship between these two fields.
On the left, you see how the keywords are written to the file. On the right, you can see how the hierarchical keywords, also written to the file, help define the relationship between keywords, and also differentiate between two instances of the keyword Josie.
Hierarchical keywords are really valuable to help you describe what your keywords mean. And they also help you make keyword lists that are much easier to navigate since it’s not one giant list. But it’s easy for the dc:Subject and the lr:HierarchicalSubject fields to get out of sync as files are moved between collections.
Camera Raw settings
Adobe also has a robust metadata schema for Camera Raw Settings (CRS). All of the settings in Camera Raw can be written to the metadata of the file. This allows the settings to be persistent and portable even though the changes are not baked into the file.
While it’s theoretically possible for other applications to use the Adobe CRS settings, doing so is only marginally valuable. The way that all raw file converters work is unique to that piece of software.
Camera Raw Setting can be written to metadata. This table shows some of the different settings.
Saving and migrating these settings
Application-specific metadata introduces the possibility of trapping some of your work inside a specific program. Sometimes data may be trapped because the application does not offer a way to export the data for a collection. This is bad practice and should be avoidedd whenever possible. Of course, you may not realize that no export path exists until you have used an application for a long time. It’s important to gain this “pre-nup” understanding when you are deciding what applications to use.
It’s also possible that work can be trapped in an application because no other program can make use of the data. This is typically the case with rendering settings. In these cases, the decision to stop using a program may not present any good options.
In the next post, we will address the term Custom Metadata, which can have several meanings.