Metadata schemas

Transcript

Metadata schemas define the UI that expose asset metadata in AEM. The schemes describe both the Read and Write interface of asset metadata, and can be applied to assets. Using a combination of approaches, we’ll explore. Schemas or form-based interfaces that are organized by tab and comprise the various fields. On the surface metadata schemas may seem like simple constructs. However, there are nuances that must be understood when creating and configuring them.

Schemas are managed under Tools, Assets, Metadata Schemas. First, let’s review the schemas AEM provides out of the box. Default, collection and content fragment. These are considered the default route schemas and are used for the respective content types if no other schema has been configured to do so. As you’d guess the content fragment schema is the default schema for all content fragments.

And collection is the default schema for asset collections.

Default, however, is more nuanced. Default defines a hierarchy of schemas. Clicking through it, we see there are two levels of sub schemas. The sub schemas resolve to assets via the assets MIME type. To understand this, let’s jump over to the whiteboard.

First things first, let’s make sure we understand MIME types. MIME types are standard that indicate the nature and format of a document or file, and are composed by a type followed by a slash followed by a subtype. So, for example, application/PDF is the MIME type for a PDF document, with application being the type and PDF, the subtype. Similarly, image/JPG describes JPEG image files that type of image and subtype of JPEG. You’ll notice that types are generic, effectively name-spacing the more specific subtype all assets in AEM should have a MIME type. Okay, now that we understand MIME types and their format of type/subtype, let’s jump into metadata schemas. On the left is a slimmed down example of the metadata schema hierarchy that defines schemas for PDFs, JPEG images, and TIFF images. Let’s look at how a PDF asset would resolve to one of these schemas. First, we have to understand the PDF assets MIME type, which is application/PDF, AEM takes the MIME type for the asset and splits it into the type and subtype. In this case, the type is application. So AEM looks for a schema name that under the root schema. If a matching schema is found, AEM then tries to locate the schema named after the subtype, in this case PDF, if a match is found here, then that metadata schema is used as the closest match to the full MIME type. Now let’s look at a case with a partial match against assets MIME type, for this we use a PNG image asset with a MIME type of image/PNG. Just like before, the MIME type is split into the type of image and subtype of PNG, AEM looks for a schema named image under the default route schema, which it finds. It then looks under that schema for one named after the subtype or PNG. In this example, there’s no schema named PNG under image. So, it uses the best matching schema, which is just the image schema. Alright, let’s do one more where the assets MIME type doesn’t resolve to any schemas. Let’s say we have an audio asset with the MIME type of audio/MPEG. So, the type is audio and subtype is MPEG.

AEM looks for schema name audio under the default route schema, and none can be found so AEM stops looking and uses the default route schema for this asset.

Okay, so now we should have a clear idea how metadata schemas are resolved by an asset MIME types type and subtype and how the metadata schema hierarchy can be constructed to provide three levels of granularity, at the subtype level, the type level or using the default route schema. As noted before, the AEM provided schemas resolved globally across all asset folders, however often you need assets in two different folder hierarchies to have different metadata for the same type of asset. AEM supports this by allowing multiple root schemas to be created and applied to different folder hierarchies. The MIME type base resolution of sub schemas still occurs. However only type and subtype schemas defined under the applied root schema are evaluated. Over here on the left we have an asset folder weekend English adventures that has an adventurous root schema applied to it. And similarly, on the right, the asset folder magazine with a different route schema applied. Note that the name of the route schema can be anything and does not have to be the same name as the folder it’s applied to. And the schema can even be mapped to multiple folders.

Using the same schema resolution rules, we just went over AEM first resolves the assets type to schemas directly under the applied route schema, and then the subtype to the subtype schema, completing the resolution to the JPEG schema under adventures image. Using the same logic, a JPG under the magazine folder will resolve to the closest matching schema under the applied magazine route schema. First, the type is resolved to the image schema under the route magazine schema and the subtype to the JPG schema. Even though we have the same asset type, JPEG images, were able to have them resolve to two discrete metadata schemas by applying different route schemas to the folder trees that JPEGs live under. Ok, enough of the whiteboard, let’s head back to AEM and see what this looks like.

Let’s make a new schema tree for our magazine assets. Typically, the best way to do this is to start by copying the out of the box default schema, give the new root schema query semantic name. Let’s keep our example simple and name its magazine to match the folder. But remember, schemas can be applied to more than one folder, so, name them according to what they represent and how they will be used.

Select magazine and tap edit to open the schema editor.

Schemas are organized by tabs across the top and you can make any number of tabs to organize the metadata fields in a logical manner.

As you can see, the default schema has a number of fields that are mapped to both industry standard, as well as AEM specific metadata properties. It tends to be easier to compose new schemas by starting from this baseline and modifying as needed, versus starting from a blank slate and re-adding all the fields from scratch.

Let’s keep our magazine schemas simple and get rid of the IPTC and camera temps. A best practice is to make consistency in the organization of fields across all your schemas. If the location of fields drastically change between schemas, it can quickly result in confusion for users.

So, let’s go through and add a few fields specific to magazine assets.

We can add new fields by dragging and dropping from the build form tab on the right.

Select the field on the left to activate the settings tab, which provides the Edit options for that selected field. Depending on the field we have different setting options however, most field types share two important configurations. Field label, which is the descriptive label for the field displayed to aim users in the asset properties interface, and map to property which is the property in AEM relative to the DAM Asset Node, where the metadata value is persisted in red. Metadata fields should almost always be stored on the JCR content/metadata resource. Properties can be industry standard metadata names such as those derived from Dublin Core, well known AEM properties, or they can even be completely custom. Be aware when using custom properties, it’s best to provide a custom property namespace, which prefixes the property name with a colon. The reason for this is namespace property values are written back to the assets binary as XMP metadata in order to use a custom namespace, your technology team needs to have registered that custom namespace with AEM.

Properties that do not have a namespace or in other words are not preceded by namespace colon are persisted to AEMs data store, however, they’re not written back to the assets original binary as XMP metadata. When possible, it’s best to leverage industry standard properties, assuming their intended use matches your use case, as it keeps the metadata most portable. That said custom properties are common and shouldn’t be shied away from if required. The Rules tab allows further behavior to be defined on a field, such as making it read only, required, or even more advanced behavior, such as showing or hiding the field based on configurable logic, fields can be easily rearranged via drag and drop.

And existing fields can be removed by selecting and tapping the trash button. It’s important to remember though, if metadata values have been added via schema field, and the field is removed, any added metadata values will continue to exist on the assets themselves. Removing the field from the schema only removes the field from the asset properties UI and not any underlying data on the assets.

As you can see, there are many field types you can select from. So, take a look at Adobe documentation and play around with them to get a feel for how they work and what they do.

When we’re happy with our changes, just tap Save. So now we understand the basics of defining and managing the definition of individual schemas. Let’s take a look at the relationship and inheritance between the root schema, the second level type schema, and the third level subtype schema. For this, let’s jump back to the whiteboard. Just a quick refresher, schemas have three levels, the default route, type schema and the subtype schema. With the last two being optional. Tabs and fields inherit down the schema tree. If field one and two are defined on the route schema, then all type schemas under that route will inherit these fields and they cannot be changed or removed at the type level. New fields specific to the type can be added here and will live together with those defined at the root. Similarly, subtype schemas inherit from their parent type schema. And just like type schemas, inherited fields or tabs cannot be changed or removed, and only additions can be made.

Let’s see what this looks like in AEM.

Remember, we customized our magazine route schema, so, any type schema under it should inherit the tabs and fields defined therein.

Editing the image type schema, which was copied over from the AEM provided default schema. We see this hold is true. Inherited fields are denoted with the outline with a lock, indicating they’re inherited and unmodifiable on the schema, we see a new tab product data which was copied over from the default image schema. Since this tab is not inherited, we can delete it. Likewise, we can create new tabs or add new fields that will only show up for assets whose MIME type results to image.

Let’s save changes and verify the subtype schemas under this image schema respected inheritance as well.

In the subtype, we see we’ve inherited the same route magazine tabs and fields along with the new fields defined on the image schema. And these are all marked inherited and locked. Now that we understand that a data schema inheritance, you can see how AEM provides efficiencies in defining and managing metadata schemas through inheritance and not requiring the same fields to be defined over and over and managed across multiple schemas. Before we apply our schemas to asset folders, let’s do a quick cleanup of the magazine schema and sub schemas. Since it did come from a copy of the default schema. Let’s remove the dm_video and video type schemas since our magazines will not have video assets. And know if a video asset is uploaded to the magazine folder tree, it will resolve to the default route magazine schema until we re-add the appropriate type schemas.

Let’s remove the subtype schemas under image as it sufficient to manage all our magazine images using the same schema. And we really don’t need image subtype specific metadata fields.

Now that we’re happy with this metadata schema set, let’s apply it to a folder. To do this, simply select a route schema and tap apply to folder. From here we can select an existing folder to apply the schema to. Remember the schema applies to all assets in the applied folder or sub folders. Unless a difference schema is applied lower down in the asset folder tree.

Similarly, to remove or un-apply a metadata schema from the folder, select it, tap remove from folders, and all the folders it’s applied to will display. Let’s cancel out for now since we want to see our metadata schema in action. Let’s head back to Assets files and navigate to our magazine folder.

We’ll open the asset properties for an image asset and review the metadata schema. And there we have it.

We’re presented with the image metadata schema just as we defined.

If we head over to a folder that doesn’t have the magazine root schema applied to it, like adventures.

And open one of these assets. We still have the metadata schema as defined by the default global schema, just as expected.

I know we packed a ton of information on configuring metadata schemas into this one. But I hope you can now build and apply schemas with confidence. -