Wikipedia defines metadata as “structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use or manage an information resource.” Examples of the most basic metadata associated with documents include informational properties such as author, date created, date modified and file size.
It goes on to say, “Failure to manage metadata properly will hamper critical activities such as information management, business process management and service-oriented architecture (SOA) initiatives.”
Without wandering further, let us understand the importance and the process of metadata management in the Tridion Content Management System. The content manager items such as Pages, Components , Templates, Structure Groups etc… all of these items have metadata associated with them .
These Metadata are further categorized into System Metadata and Custom Metadata.
System Metadata represents information like: Publication ID, Last Publish date, Last Modified date etc. When a page is published, the Page item’s information such as Publication ID, Title, Major & Minor versions are published along with information such as Last Publish date, Modification date and any assigned Categories & Keywords metadata.
These system metadatas are sent/published to Content Delivery , usually in Tridion Broker database under appropriate tables such as ITEM_CATEGORIES_AND_KEYWORDS, COMPONENT_PRES_META_DATA .
The System Metadata pertaining to Pages, Components, Component Presentations, Binaries, Dynamic Templates will be covered in a separate post.
Custom Metadata represents the data you define using Metadata Schemas ( a Metadata schema can be associated with Templates, Pages, Components(Metadata Design tab) , Binaries ). On publishing items such as Pages, Components, their metadata, more appropriate to say associated Custom Metadata, is also published and stored in Content delivery data store ( broker db ) under CUSTOM_META table .
Custom Metadata in Content Manager:
Metadata stored in Content Manager are defined using Schemas, Metadata Schemas and are associated with the items itself. For example , a Component has metadata associated with it as defined in its Schema’s ‘Metadata Design‘ tab.
For Pages, Publications, Structure Groups metadata is associated by creating Metadata Schemas and linked using the Metadata Schema field, as seen below for a Page:
For a Publication/Structure Group, the Metadata Schema field can be seen by using the Properties option.
All such metadata values are stored in the Content Manager database Tridion_cm and are retrieved every time we read the Component using Tom.Net API, Core Service API and when we open/view the Component in Content Manager Explorer as well.
[ A next blog post of mine will cover in detail how to read all these custom metadata at CM side using the Tom.Net API, Core Service API ]
Custom Metadata in Content Delivery Data Store :
Metadata stored in Content Delivery data store is present inside the Tridion Broker database. Basically the metadata, better to say custom metadata defined using Schemas, associated with Components, Pages etc… are sent to the content delivery on publishing of these items.
Entries are made inside database: Tridion_Broker, in the table: Custom_Meta, using a Key Value pair format, with Key representing the Metadata field name and Value representing the Value of field.
Understand that there are appropriate Type Mappings for different Metadata types such as ComponentMeta, PageMeta, BinaryMeta etc in cd_storage_conf.xml file which determines what all metadata gets published and where they are published.
Below sample shows the settings done specific to SDL Tridion 2011 ( these are deprecated in future versions )
<Item typeMapping=”BinaryMeta” storageId=”defaultdb” />
<Item typeMapping=”ComponentMeta” storageId=”defaultdb” />
<Item typeMapping=”PageMeta” storageId=”defaultdb” />
Starting with SDL Tridion 2011 SP1, the above type mapping values are replaced with a single type mapping called Metadata.
<Item typeMapping=”Metadata” storageId=”defaultdb” />
The storageid here points to one of the Storages configured using the <storage> element in the configuration file.
[ A next blog post of mine will cover in detail how to read all these custom metadata by querying the broker database and will also discuss the structure of the table used to store such metadata ]
Hope you enjoyed this post. I have kept this post more of theoretical to first grasp the basics on metadata and then move on to querying them.
That’s really nice article on MetaData.
LikeLike