Faceted Navigation Engine Nomenclature

This article is the second of a series describing the faceted navigation system for EPiServer that we have internally developed in Cognifide, that’s already proven to be a robust solution for delivering tagged content a heavy traffic site, which will be released shortly as an open source project.

First of all we have to explain the nomenclature as it is going to be used quite a bit. A few terms we use pretty extensively are:

Facet – this is roughly an elaborate version of an EPiServer (or WordPress) category. One of the problem with EPiServer category is that it is just that and absolutely nothing more. There is no way for attaching metadata and conditional structuring of the category tree. There is no way to assign them roles. Facets provide you with much, MUCH more.

Navigation space – Facets just like categories are structured in a tree, this is good for browsing them in a back end for tagging and organizing them. However we sometimes need to have a different view at facets structure based on the place we are in on the site. a good sample of that is Setanta Sports site. you want to have a different navigation in the Sports (news) section and a different navigation when you browse blogs. Facets can have a different set of children and other facets that they expose based on the navigation space you are in.

Facet collection – a simple set of any facets.

Facet context – this is a special collection of facets possibly of many roles, but also abiding to the rules stated by Facet roles. Most notably a “current context” is a collection of facets the request has been performed with.

Facet role – a facet can be a tagging unit like a category, but a facet can be much more. for that we came up with a concept of facet roles which allows us to profile facets:

ability to use for tagging – not all facets you necessarily want to be used for tagging. Some tags are indeed used to identify a content, but some tags play more utilitatian way like “locale” that we are in – you would not necessarily tag a content as being only available within a certain locale (although you might want to do that anyway), therefore a role “locale” may be set as not taggable.
uniqueness – You may want to limit a role to only be able to has one of its member in any facet collection (IFacetrCollection). After all a user cannot be in 2 places at once so yet another logical extension for locale. Also request can only be performed within a context of one navigation space – therefore a navigation space representing tag need to be unique.
separating facets of different roles – once you are presented with a context of tags, you may want to categorize them. e.g. to color a header in a control you may want to know which “sport” the tag represents.
menu visibility – you may choose to display or not some tags in your navigation- this is the simplest way to specify that a meta-facets like say.. “flash video” should not generate a menu item as this is quite irrelevant to user.
context mandatory – this indicates that any given context has to have at least one facet of that role – if a context does not have any of the facets of this role – a default facet for this role will be used. For example – a user cannot be placed in a null locale, he has to be “somewhere on earth”, doesn’t he? ;)
availability for selection – this allows us to tell whether a facet can be used by editors and be visible on the site or whether it’s use is of more esoteric nature and the editor should not have it visible anywhere on the site – after all why would the editor want to see the navigation space representatives.
System Role – this indicates that a role is crucial to the operation of the faceted navigation and as such should never be deleted.

Facet mappings – allows us to link facets to external id’s available outside the system. for example when you import an rss feed – you want to be able to always tag the articles from it with a proper facet – so for mapping “Rss Feeds” there will be mutually unique relation between a tag and a URL of the rss feed.

Facet Navigation Info – allows the engine to specialize the facet structure within the navigation space – the navigation is a cross-section between a facet and a navigation space.

Preferred Facet Hub Page – all facets can carry the information on what is their preferred page to be displayed(this is defined in the navigation info) . In any given context you don’t really care what page are you on – the page is just a visualisation of content that is defined by facets. But you may want your facet to cause a switch of this visualisation once it is becoming the dominating facet in the context (a facet with highest priority in the context) – So for any given set of facets – you query the URL provider with it and it will check the context and select the dominating facet and get the hub page for displaying the context from it. For example when you’re on a sports page and you click on a football – you want a more specialized page that might have some football tables on it rather than the generic sports page.