Planning content type relationships is an essential part of improving search functionality. Layering content types by building parent/child relationships will make life much easier when building search queries to render your content.
Parent/Child Relationships
Let’s use documents as our example for this blog. When you create a new content type you have to choose a parent. What does this actually mean? Well, you will easily notice that when you choose a parent content type, your content type starts with the columns that have been assigned to the parent. What is not so apparent is the relationship of the ID that is assigned to the content type. Let’s examine what happens when you create 3 new content types called Draft Document, Final Document, and Special Document.
You’ll notice in the chart above that all three content types start with the same ID as the Document content type, 0x0101. Draft and Special Documents have unique ID’s after that point. Final Document, however, has the same ID as Draft Document except it has a 01 appended at the end. So what’s the significance of that?
Search Queries
When adding Content Search Web Parts or Search Results Web Parts to a page, you will often times be attempting to return a specific set of documents. The easiest way to find the documents you are looking for is to search based on content type. If you didn’t plan your content types and created them all with Document as the parent then all content types will have their own unique ID like Draft Document and Special Document do above. If your goal is to find all documents then you can just use this query:
ContentTypeId:0x0101*
That query will return any document that’s content type has 0x0101 in the ID, which is all documents. But what if you only want to return two types of documents? Well, then your query would look more like this:
ContentTypeId:0x01010069ED63EB3969D144BDA73C184AF4D8AF* ContentTypeId: 0x010100C3CD5B287A54A6419AB1D4DE364BA759*
Imagine if you need to return a lot of different content types that all have unique ID’s. That could get ugly pretty quick. Well, if you planned your relationships properly then you can dramatically reduce the length of your query. For example, if you wanted to return Draft Document and Final Document you can simply use a query that looks like this:
ContentTypeId:0x010100D25B4E51483A6B48AC7B1643830CCC8A*
Now you are returning Draft Document because that is its ID and you are also returning Final Document because it has the same ID but with 01 appended to the end. If Final Document had a child called Public Document its ID would look something like:
0x010100D25B4E51483A6B48AC7B1643830CCC8A0101
Note that the ID is the same as Final Document with another ‘01’ appended to the end. So the search query above would also return Final Document. That’s much easier than searching for three unique content type IDs right?
The Point
This exercise illustrates how parent/child relationships can be used to improve search functionality and save yourself time down the road. This is especially useful in search based intranets. Make sure you take the time to plan your content types appropriately before you begin creating content types or be prepared to spend a lot of time looking up IDs and writing long search queries throughout your intranet!
Cheers!
Share
