About static ranking

When you add managed attribute values with PutManagedAttributeValues, you can add (and later update), the static ranking of the particular value, within this managed attribute. Static ranking affects how Endeca Server displays the values when returning refinements to the end users.

You specify static ranking as rank, in this structure of the Configuration Web Service:

<ns:putManagedAttributeValues>
  <ns1:mav>
    <name>?</name>
    <spec>?</spec>
    <parent>?</parent>
    <managedAttribute>?</managedAttribute>
    <synonym>?</synonym>
    <rank>?</rank>
  </ns1:mav>
</ns:putManagedAttributeValues>

Note: You can only control ranking if you use the PutManagedAttributeValues of the Configuration Web Service. This interface operation lets you add ranks and also resolves ties and prevents duplicate ranks. However, if you use the Data Ingest Web Service for adding managed attribute values (as records, via ingestChanges:addRecords request, while you can still add ranks, this operation does not resolve ranking ties.

The following statements describe how the Endeca Server uses rank values:

Managed attribute values within a specific managed attribute are ordered according to their ranks (if they are specified), in the ascending order. If you did not specify a rank for any of the values, Endeca Server considers their rank as zero (0), and ranks the values accordingly.
Ranking occurs within all values that are added for the specific managed attribute. Ranking is independent of the managed attribute's hierarchy. For example, for a managed attribute "location", two managed attribute values, "MA", and "NY State" can be ranked 1, and 2, accordingly. Then, the child values of MA, "Boston" and "Springfield" can be ranked 3, and 4.
You can specify a rank when initially adding or updating a managed attribute value, or by using putManagedAttributeValues to update an existing value. In the case of an update, a new rank is used and any affected values are reordered.
If the rank of any managed attribute value (when using the putManagedAttributeValues request) is tied with the rank of any another value of the same managed attribute, the ranks of the pre-existing values change according to the following algorithm. For each value A that is being added, if A is assigned a rank (A) and there is already a value B of rank (B) that is equal to rank (A), then B is assigned a rank (B)+1 instead. If the new rank(B)+1 is tied with the rank for an existing value C, ties are broken again as if B is a new value. (That is, C's rank become rank©)+1). This process repeats until there are no ties. The ranks of all other values specified in the request remain as specified unless changed by a subsequent request.
(For putManagedAttributeValues requests only). No two managed attributes specified in the same request may have the same rank (the Configuration Web Service request is rejected). The entire request fails if any of the values is specified incorrectly. (Note that if you use the Data Ingest Web Service request, then this checking does not occur.)
Overall, you can order refinements (which comprise both standard and managed attribute values), either globally or per query.
- For the global order, you specify either the record-count, or lexical values on the system-navigation_Sorting property in the associated PDR for the attribute (both standard and managed).
- For the per-query order, you specify OrderByRecordCount="false" in the RefinementConfig of the specific Conversation Web Service request, for that query. The query-time control overrides the global order.
Depending on which of these methods is used, Endeca Server uses the following logic for breaking ties with static ranking specified for managed attribute values:
- If record-count is enabled, Endeca Server first uses record-count, then it breaks ties with static ranks on managed attribute values, and returns the results.
- If lexical is enabled, Endeca Server uses static rank numbers first, and then orders refinements based on their lexical order. In other words, if any managed attribute values have rank numbers associated with them, Endeca Server takes into account these rank numbers when returning and sorting these refinements. Note that if no rank is specified, a rank of 0 is assumed. This means that in practice, lexically-ordered refinements may be returned first, followed by those that have a static rank on their managed attribute values. As a workaround, in such cases, you can add negative ranks, which will result in ranked managed attribute values sorted earlier than unranked values.