Oct 27, 2009
Setting up content structures in the dotCMS is pretty straightforward but the real trick is planning how your front end user will easily view relevant content entered into the content repository. Just like putting tabs on the top of folders in a filing cabinet, content needs to be labeled and segregated as it is entered so that dynamic pages naturally pull and display. The dotCMS has three basic data segregation strategies that you can take advantage of as you set up content structures and plan content contribution: Tags, Categories, and Relationships.
General Rules for Taxonomy Usage
If properly labeled and segregated, content and related content will always display in a relevant fashion on your dynamic webpages. Take the following into consideration before creating content structures so your site can take advantage of the full power and flexibility of dotCMS taxonomies:
Will front end users be able to keyword search for this type of content on any of my webpages? → Add a tag field to the structure
Can this type of content be categorized by a predictable and finite list of labels 30 or less?→ Add a category field to the structure
Does this type of content belong to a family or grouping which also needs to be recorded as content? → Create a relationship between the structures.
Scenarios and Use Cases
Tags - When users need to find content by keyword search, add a tag field. As content is entered, suggestions from the tag pool help keep tags consistent. Tag clouds can be used to list key words associated with a significant quantity of content. However, since content contributors can tag content with any keyword(s), tags cannot be used reliably to pull dynamic content lists and the use of categories or relationships becomes the better option.
Helpful hint: If you want to pre-populate your tag pool for content contributors, create a comma separated tag list, add a new piece of dummy content to the system, and paste the complete tag list on that one piece of content. All of the tags will now become part of your tag pool and suggest themselves when users start typing the first three letters of any of your tags. News items, press releases, etc., are structured content types that typically have tag fields because of the limitless number of topics they can cover. With proper tagging, front end users can easily search the proverbial “needle from the haystack”.
Categories - Due to their simplicity, categories are often over-used as a taxonomy. Categories are drop down lists of predefined labels. Webmasters typically prefer to present users with predefined drop down lists of labels because they can be used reliably on dynamic pages to pull content whereas tags are difficult to predict. However, categories are drop down lists and have limitations. Use Category lists for logical labels only. They should not duplicate content. Category lists should also remain relatively short in length (30 labels or less).
As a general rule do NOT use a Category Field if:
Your list of labels grows over 30 in the initial planning stages. Your category list will probably grow as you scale and become unwieldy.
Category names will also match content titles - use a relationship between two structures instead.
Relationships – When a piece of content needs to be found by the content family/sibling it relates to (or by the inverse), then relationships are a very powerful solution. For example, if you managed 50 little league sports Associations that each had 40 Teams with 35 Players per team, then relationships would help you build powerful dynamic pages. You would probably want to record multiple lines of information about your associations, teams, and players so they should be structured content and not categories. Secondly, you may want to find the association a player belongs to by searching for the player and also find the multiple teams the player belongs to at the same time. Only relationships can help you reliably here without any redundant labels or processes. One relationship between the Association and Team structures, and another between the Team and Player structures and you are done. Now you are now ready to build dynamic pages that search for relationships between any of the three content structures based upon the tri-part relationship chain you have created. With a properly built page(s), you can list/search associations, click to find teams, and then click a team to find players and any combination thereof.
Relationships scale with content. Categories are populated by webmasters, have a limited length in number of items, and are limited to one term or label. In our examples above, there is no limit to the amount of Associations, Teams, or Players that can be entered into the system and content contributors can relate content as it is entered into dotCMS. Your content can grow and expand without changing dynamic pages or the need to add new categories.
Tags, Categories, and Relationships are often used in combination on content structures. It is easy for webmasters to build powerful, dynamic pulls of content as long as the content in the repository has been logically grouped and labelled. The improper use of taxonomies can make content contribution redundant or confusing for content contributors and difficult to dynamically extract on webpages. For this reason, it is recommended that webmasters leverage the power of dotCMS taxonomies and preplan how content contributors will label and relate data before creating content structures, or the HTML pages envisioned by wireframes and designs.
Containers, virtual machines and serverless computing — three terms you’d expect to hear during a Sci-Fi movie — are all part of the enterprise computing debate that asks; What’s the best way to devel...
dotCMS Bootcamp 2018 is set to attract hundreds of developers, marketers, and enterprise company stakeholders this October in sunny Miami! Here are 11 reasons you should come.
Content is driving eCommerce sales like never before. We explored why, and what role microservice architecture has in delivering data-driven content that drives sales.