Merus Mercatum

Adding new catalogue attributes

Catalogue superusers can create new attributes on the system. They can also modify any existing attribute. Note that an attribute can never be deleted, as the system always needs to know how to deal with any value data it finds when loading a product. It can be renamed to move it out of the way, or configured to be hidden to the administrator, so it is possible to eliminate it should the need arise.

Fig. 1 - Example of a fully indexed attribute

To modify attributes, an admin user should follow the "Configure attributes" link on the main catalogue tab. This will open in a new browser window, so you don't need to worry about saving any product/folder changes beforehand.

Attribute name/type

An attribute can have any name. This name can be translated into multiple languages when displayed on the main site, but not in the administrator, so if your system is multi-lingual you should standardise on a language for these names.

Attribute types are detailed elsewhere, but take note that you cannot change an attribute's type once it has been set. The system stores attribute values in different ways depending on their type, so even if you changed just one the entire catalogue would have to be rebuilt. This is very slow, and for this reason this action is not supported.

Value sets

A string attribute that consists of a small number of possible values can be made more efficient by configuring it as a value set. This has two effects:

1. First, when a value for this attribute on a product or folder is stored, in the database the full string value is not written into the record. Instead, an integer is written, indicating which string from the list should be used. This keeps the size of the data down to a minimum.
2. When editing the attribute through the administrator only the permitted values will be selectable, there will be no free-text entry.

Value sets may be configured as either strict or lenient. When strict, only the permitted values may be selected. In lenient mode they behave just like standard strings from an administrator's point-of-view, in that any value can be enteted, but they will be stored as integer references regardless; values that have not been encountered before will automatically be appended to the set.

An attribute can only be configured as a value set at creation time. New values can be added to the set manually at any time. Values may also be removed from the set; any folder or product that used them will appear to have no value for the attribute.

Context-sensitive properties

Whereas the type of an attribute describes the final value, the following properties can be configured to change how an attribute's value is looked up, based on context. Any combination of them is permitted, but bear in mind the more that are used the slower it is to look up an attribute value.

• Inheritance

  In many cases, you may wish to give a whole range of products the same value for an attribute. There are two ways you could accomplish this. The first way would be to manually set the value on each individual product, but if there were many products this would rapidly become tedious. The second way is to group the products together into a subfolder within the hierarchy and make use of attribute inheritance.

  Attributes marked as inherited are initially looked up on the product. If a value is set against that product, that is the value used. However, if there is no value set, instead of reporting that the attribute is empty Mercatum will move up the hierarchy requesting the same attribute for each parent folder, until a value is found.

  This means that, in the above example, instead of setting the same value on each product you can mark the attribute as inherited and set a single value on a parent folder. This will achieve the same result. It also has the benefit of only requiring a single change to that folder's value to immediately change it for all the descendant products, making maintenance that much easier.

  Fig. 2 - How to create a new attribute

  Note that inherited attributes do not prevent some products from having values for that attribute themselves, as values found closer to the product simply override those further away.

  There is an additional flag that be applied to inherited attributes that are also lists. Ordinarily, if a product has a value for the inherited attribute, that value will be used in place of any value that may exist on a parent folder. However, by setting the "inheritance extends" flag, this behaviour can be modified so that the value found on the product is concatenated with any value found on the parent folder. This is primarily useful for specifying a list of attributes that should be displayed in some way when browsing the catalogue, the closer to a particular product the user browses, the more specific the information displayed becomes. Search refining makes use of this feature to determine which filters to display on search results.

• Hierarchy-specific attributes

  These are only really relevant for products. If an attribute is marked as being hierarchy-specific, then a product can have multiple values for that attribute, one for each hierarchy it is a member of. The value used depends on what hierarchy a particular user is browsing.

  Hierarchy-specific attributes can also be used in conjunction with inheritance in order to inherit from the browsed hierarchy. This is actually the most correct usage of inheritance, as an inherited attribute that is not hierarchy-specific still needs to traverse some hierarchy, so one is picked arbitrarily. This can yield unpredictable results.

  N.B. hierarchy-specific attributes must be populated for each hierarchy a product is in if it is to return a value for that hierarchy, even if they all should return the same value.

• Multi-lingual attributes

  For systems that have multiple configured languages, it is possible to create a value for an attribute for each language. The appropriate translation will be displayed to users who have chosen that language for their session.

  Translations will fall back to the next best language if a value doesn't exist, so it is possible to create a specific language variant for a small section of the catalogue or a handful of attributes, without needing to populate everything else with an identical translation to that of the base language.

  As with the other context-sensitive attribute properties, it is possible to use languages alongside inheritance, you simply have to provide multiple translations for each folder in the hierarchy you wish to inherit from.

If none of these properties are set, then an attribute is considered to be "global", in that a particular catalogue entry will always have the same value, regardless of where it is in the catalogue or who is requesting it.

Units

Numeric attributes may be assigned a unit suffix that can be displayed against the attribute on item pages and when refining a search. When used in a search refinement it is quite sophisticated, in that it will convert the value into something a little more suitable for display. For example, if you have an attribute with the units "MB", it will automatically convert the display into "GB", "TB", etc, should the number get too large.

Search weights

Some attributes are more relevant than others when used in a keyword search. For example, if you search for "HP LaserJet", products that contain this string in the actual product name should be considered better matches than those that contain the same string in some secondary marketing text.

This is achieved by assigning a higher weight to the more important attributes, such as the product name. Products that match only the lighter weighted attributes will still be returned in search results, but they will be listed last when the result is sorted by relevance.

Search indexing

There are 3 different types of search indexing available for use in Mercatum; each one has its own separate flag. Any combination of them is permitted.

1. Indexed

   An attribute that has this flag can be searched for by value internally to the Mercatum system. This means it can be used as a product identifier, to varying degrees. Additionally, it can be used in the administrator to find products that match a certain criteria, such as searching for a specific brand.

   Indexed attributes cannot necessarily be used in a more complex search involving keywords or refinements, unless they also have one of the other two flags, as these kinds of searches are performed by an external subsystem that uses its own set of indexes.

2. Refineable

   If an attribute is refineable, then it can be used to narrow down a previous search, or filter products out of a range by comparing them to a requested value.

   Numeric attributes and prices can be compared to a range, such as "between A and B", whereas attributes of other types can only be compared to an exact match.

3. Keyword indexed

   The words in the value of any attribute with this flag will be stored in an index, allowing the product to match partial attribute values against a user's search query. For example, if the product name attribute was indexed in this manner, a user could search for "Microsoft" and it would match against products with the name "Microsoft Windows", "Microsoft Office", "Shiny happy thing from Microsoft", etc.

Unique identifier attributes

A uniqueness constraint can be added to any string attribute, as long as that attribute is both global and is also indexed. This constraint will ensure that only a single product in the entire catalogue can have that value, and is generally used for product identifiers.

At least one of these attributes must exist before any products can be created, as it is impossible to save a product without at least one identifier. If there are multiple identifier attributes available, they do not all have to be set on all products. For example, if the administrator is running in "catalogue management" mode, controlling two sites with different product identifiers, a product that is only published to site A need only have the identifier attribute used by site A.

Required attributes

It is possible to force all products in the catalogue to require certain key attributes. A good example of this would be a description which would be displayed on the main item purchase page. If an attribute is required then no product can be saved unless that attribute has been given a value. Attributes are never required on folders, only on products.

When used in conjunction with the hierarchy-specific or multi-lingual options, then values are required for all possibly valid contexts, i.e. all hierarchies the product is in, or all configured languages.

Note that while it is possible to have an attribute that is both required and inherited, doing so negates much of the usefulness of the inheritance property as the product must have its own value as well.