Does anyone have a thought or experience on using one over the other?
I have a request to create a new filter in Author for keywords model and photographer. Why the business isn't using the metadata (IPTC extension) for these is an outstanding question (are they using Bridge, Capture 1, etc.) But it raises my curiosity about the recommended use of keywords or metadata? I've been operating on the notion that "tags and keywords" were best for augmenting (personalizing) an asset (i.e., flirty, fun, resort) whereas metadata would be specific (i.e., model, photographer, year, etc).
Solved! Go to Solution.
Views
Replies
Total Likes
An asset's Tags and Keywords *ARE* Metadata. Both are data about the asset.
Generally, it's best to align to industry-standard namespaces/properties. You'll see AEM even does this OOTB; instead of inventing its own custom "dam:title" metadata property, it uses the Dublin Core's "dc:title". Using industry-standard namespaces/properties certainly makes your metadata more portable across applications that might use your assets (these apps might be able to reason about industry standard fields that have clear semantics, whereas the best they can do with custom fields is simply display them).
In terms of "tags and keywords" metadata, I'd agree these are typically more generic, shared vocabularies, whereas other metadata properties such as those in the IPTC space can be quite specific to the asset.
In the context of AEM, Tags have extra considerations since they have a UI that lets you manage them (and translate the labels!) as well as integrations in various AEM UI's for selecting and associating Tags with other content. There's also a TagManager Java API that let's you search for content by Tag easily. So, with all these extra trappings AEM adds to Tags, it positions as a nice way to apply a taxonomy to ACROSS content in AEM, using a centrally controlled and managed vocabulary.
An asset's Tags and Keywords *ARE* Metadata. Both are data about the asset.
Generally, it's best to align to industry-standard namespaces/properties. You'll see AEM even does this OOTB; instead of inventing its own custom "dam:title" metadata property, it uses the Dublin Core's "dc:title". Using industry-standard namespaces/properties certainly makes your metadata more portable across applications that might use your assets (these apps might be able to reason about industry standard fields that have clear semantics, whereas the best they can do with custom fields is simply display them).
In terms of "tags and keywords" metadata, I'd agree these are typically more generic, shared vocabularies, whereas other metadata properties such as those in the IPTC space can be quite specific to the asset.
In the context of AEM, Tags have extra considerations since they have a UI that lets you manage them (and translate the labels!) as well as integrations in various AEM UI's for selecting and associating Tags with other content. There's also a TagManager Java API that let's you search for content by Tag easily. So, with all these extra trappings AEM adds to Tags, it positions as a nice way to apply a taxonomy to ACROSS content in AEM, using a centrally controlled and managed vocabulary.
Views
Likes
Replies
Views
Likes
Replies