This section describes how to configure Endeca property behaviour.
Enabling record list display means that any records tagged with this Endeca property display the property as part of their entry in the record list.
Note
You must enable a dimension for record list display before you can access its dimension values using the methods in the Endeca Presentation API.
To enable display in a record list for an Endeca property:
Fully implementing this feature requires additional work outside of Developer Studio. Please refer to the Endeca Basic Development Guide for details.
Enabling record display means that any records that are tagged with this Endeca property display the property as part of their entry on the record page.
Note
You must enable an Endeca property for record display before you can access it using the methods in the Endeca Presentation API.
To enable display on a record page for an Endeca property:
Fully implementing this feature requires additional work outside of Developer Studio. Please refer to the Endeca Basic Development Guide for details.
Although users can sort on any record at any time, it is also possible to optimize a property for sort in Developer Studio. This mainly controls the generation of a precomputed sort, and secondarily enables the field to be returned in the API sort keys function.
Sorting functionality allows an Endeca-enabled Web application to define the order of records returned with a query. When making a query request, the application may define a series of sort keys (property/order or dimension/order pairs, where order is either ascending or descending). The MDEX Engine then returns records according to those keys.
All of the records corresponding to a particular navigation state are considered for sorting, not just the records visible in the current request. For example, if a navigation state applies to 100 bottles of wine, all 100 bottles are considered when sorting, even though only the first ten bottles may be returned with the current request. The sort key's data type determines the type of sort that occurs—numeric, alphabetical, geospatial, time, datetime, or duration. If an Endeca record does not include a value for the specified sort key, that record is sorted to the bottom of the list, regardless of whether the sort order is ascending or descending.
Note
An explicit record sort key, specified as part of a MDEX Engine query, takes priority over any other type of record sorting (default sorting and relevance ranking). See Controlling the order of record results for details.
If the Web application does not specify sort order as part of the query, the MDEX Engine returns records in the default sort order, if one has been specified. See Specifying a default record sort order for details.
Record sorting only affects the order of records. It does not affect the ordering of dimensions or dimension values that are returned for query refinement. You use dimension and dimension value ranking to affect the order of dimensions and dimension values.
The data type of an Endeca property determines the sort order of records sorted by that property.
To configure an Endeca property so that it can be used for record sort:
In the Properties view, double-click the Endeca property you want to change to open its Property editor.
In the Type list, verify that the property’s Type attribute is correct. This attribute affects sorting in the following ways:
If Type is: Records are sorted: Alpha In alphabetical order, when sorted by this property. Integer or Floating Point In numeric order, when sorted by this property.
Geocode According to the distance between the specified geocode property and a given reference point.
Time According to the length of time between the specified time property and the start of the day (midnight or 12am).
Datetime According to the length of time between the specified datetime property and the start of the epoch (12 am on January 1, 1970).
Note
A negative datetime indicates time before the start of the epoch.
Duration According to the length of time represented by the duration property.
Note
Duration can be a negative number, for example, to express timezones relative to GMT/UTC time.
Note
The file path and reference property types are deprecated.
If an Endeca-enabled Web application does not specify sort order as part of the query, the MDEX Engine returns query results using the default sort order, if one has been specified.
You specify the
default sort order and sort direction (ascending or descending) by using the
--sort flag when running Dgidx. The
--sort flag has the following syntax:
--sort "key|dir"
where key is the name of an Endeca property or dimension on which to sort and dir is either asc for an ascending order or desc for descending (if not specified, the order will be ascending).
You can also specify multiple sort keys in the format:
--sort
"key_1|dir_1||key_2|dir_2||...||key_n|dir_n"
If you specify multiple sort keys, the records are sorted by the first sort key, with ties being resolved by the second sort key, whose ties are resolved by the third sort key, and so on.
Note
If you are using the Endeca Application Controller (EAC) to control your environment, you must omit the quotation marks from the --sort flag. Instead, use the following syntax:
If you are using the Endeca Application Controller (EAC) to control your environment, you must omit the quotation marks from the --sort flag. Instead, use the following syntax:
--sort key_1|dir_1||key_2|dir_2||...||key_n|dir_n
Relevance ranking is used to control the order of results that are returned in response to a keyword search. Record sorting is used to control the order of records that are returned in response to any type of MDEX Engine query that returns records.
Relevance ranking and record sorting are closely related features but there are some distinct differences.
Relevance ranking determines which results are more relevant to the user, based on a set of rules you define. For example, you can configure a rule that says "for multi-term searches, rank records that match more of the terms higher than those that match fewer terms." Relevance ranking is configured either as part of a search interface, where each search interface has its own relevance ranking strategy, or is specified in the record search query itself.
Unlike relevance ranking which is limited to keyword search queries, record sorting can be used with any type of query that returns records. Record sorting is based on a sort key. The sort key can either be defined as a default, or identified by the Web application as part of the query.
Generally, if you have relevance ranking enabled, you would not specify a record sort key within a record search query because record sort keys take priority over all other types of ordering, making the relevance ranking settings useless.
Note
A search interface is a named collection of properties and dimensions, each of which has its Enable Record Search option checked. Search interfaces allow your end-users to search on multiple properties and/or dimensions simultaneously. The search interface's name is used just like a normal property or dimension when performing record searches. A record search query on a search interface returns results that match any of the properties or dimensions in the interface.
Specify an explicit sort key in the MDEX Engine query, set a default sort order, or use relevance ranking (for records returned in response to record search queries).
There are three ways of controlling the order in which records are returned:
Specifying an explicit sort key in the MDEX Engine query, either via a URL parameter (Ns) or an ENEQuery setter method (setNavActiveSortKeys())
Using relevance ranking, for records returned in response to record search queries only. Relevance ranking settings can either be implicitly defined as part of the search interface, or explicitly defined in the search query itself.
The priority of record sorting/relevance ranking is as follows:
If none of these three sorting methods is specified, records are returned in an arbitrary, but consistent, order as determined by an internal ID generated by Dgidx during indexing.
If the MDEX Engine query includes an explicit sort key parameter, that sort key overrides all other sorting and relevance ranking settings.
If a default sort key is specified, and no other sort parameters are set, records are returned in default sort order. Ties are broken using the arbitrary internal order described above.
When searching against a search interface that incorporates a relevance ranking strategy, the relevance ranking strategy takes priority but ties are broken using the default sort key, if one has been specified. If there is no default sort key, ties are broken using the internal ID order described above.
If the MDEX Engine query includes a relevance ranking parameter, that setting overrides any relevance ranking strategies configured in the search interface that is being searched against.
A search interface is a named collection of properties and dimensions, each of which has its Enable Record Search option checked. Search interfaces allow your end-users to search on multiple properties and/or dimensions simultaneously. The search interface's name is used just like a normal property or dimension when performing record searches. A record search query on a search interface returns results that match any of the properties or dimensions in the interface.
Note
Fully implementing this feature requires additional work outside of Developer Studio. Please refer to the Endeca Basic Development Guide for details.
You can add properties to Endeca records that represent latitude and longitude pairs. These properties are known as geocode properties.
Result sets that have geocode properties can be sorted by the distance of the values of the geocode properties to a given reference point. For example, if the records of a particular dataset represent individual books that a large vendor has for sale at a variety of locations, each book could be tagged with a geocode property named Location that holds the store location information for that particular book. Users could then sort those books so that books that are more closely located are displayed first.
Note
Geospatial sorting is closely related to geospatial filtering.
Your geocode data must be specially formatted as floating-point values in order to be successfully indexed by Dgidx.
In order for Dgidx to successfully index it, your geocode data must be in the form d,d where each d is a double precision floating-point value:
The first d is the latitude of the location in whole and fractional degrees. Positive values indicate north latitude and negative values indicate south latitude.
The second d is the longitude of the location in whole and fractional degrees. Positive values indicate east longitude, and negative values indicate west longitude.
Example 3. Example
For example, a company’s main office is located at 42.365615 north latitude, 71.075647 west longitude. This geocode should be supplied to Dgidx as:
42.365615,-71.075647
If your source data is not available in this format, it can be assembled from separate properties using a Perl manipulator. See the Forge API Guide for Perl for examples of using a Perl manipulator to concatenate separate properties into one.
Before you can map a geocode source property, you must configure the Endeca property that it will map to as geocode.
You map a source property to an Endeca property in order to make the source property available in your Endeca implementation. To configure a geocode Endeca property:
You map, present, and sort geocode properties using similar techniques to those you use for alphanumeric properties.
To fix issues with record sorts, check for property type, number of values assigned to each record, and uniqueness of property and dimension names.
If the records returned with a navigation request do not seem to respect the sort key parameter, here are some things to check:
Was the Endeca property specified as a numeric when it is actually alphanumeric, or vice versa? In this case, the MDEX Engine returns a valid response, but the sorting may not be what you expected. Also, if you are sorting by a dimension, then the sort is always alphabetic.
In general, properties and dimensions that are enabled for sorting should only have one value assigned per record. If a record has multiple property values or dimension values for a single Endeca property or dimension, the MDEX Engine sorts the records based on the first value associated with the key. If the application is displaying any value other than the first one, then the records may not appear to be sorted correctly.
If an application has properties and dimensions with the same name and a sort is requested by that name, the MDEX Engine will arbitrarily pick either the property or dimension for sorting. In general, all properties and dimensions should have a unique name.
You must enable record search for Endeca properties in order for records to appear in search results.
Record search finds all records in an Endeca application that are tagged with a dimension value or Endeca property that matches a term the user provides. In order for an Endeca property to be considered during record searches, you must enable it for record search.
To enable record search for an Endeca property:
Fully implementing search features requires additional work outside of Developer Studio. Please refer to the Endeca Basic Development Guide for details.
A range filter allows an Endeca-enabled Web application to select a subset of the total dataset for display, based on an arbitrary, dynamic range that uses an Endeca property or dimension as the filter key.
Navigation queries that use a range filter return only those records that are included in the selected data subset, along with the refinement dimension values that are appropriate for the filtered records. Range filters are supported for:
For values of properties and dimensions of type Floating point, you can specify values using both decimal (0.00...68), and scientific notation (6.8e-10).
It is important to remember that range filters are simply modifiers for a navigation query. The range filter acts in the same manner as a dimension value, even though it is not a specific system-defined dimension value. Consider the following records and examples:
|
Record ID |
Sample Dimension Value (Wine_Type) |
Sample Property (Price) |
Sample Property (Description) |
|---|---|---|---|
|
1 |
Red (Dim Value 101) |
10 |
Dark ruby in color, with extremely ripe… |
|
2 |
Red (Dim Value 101) |
12 |
Dense, rich and complex describes this '96 California… |
|
3 |
White (Dim Value 102) |
19 |
Dense and vegetal, with celery, pear and spice flavors… |
|
4 |
Other (Dim Value 103) |
20 |
Big, ripe and generous, layered with honey… |
Properties of numeric, geocode, time, datetime, and duration type may be enabled for range filtering.
Note
You may also use a dimension as the key for a range filter. See Enabling a dimension for range filtering for details.
To enable an Endeca property for range filtering:
In the Properties view, double-click the Endeca property you want to change to open it in the Property editor.
In the Type list, make sure the type is compatible with range filters: Integer, Floating point, Geocode, Time, Datetime, or Duration.
Note
Be careful of dollar signs or other frequently found characters in property values that would prevent a property from being defined as numeric. For values of properties of type Floating point, you can specify values using both decimal (0.00...68), and scientific notation (6.8e-10).
Result sets that have geocode properties can be sorted by the distance of the values of the geocode properties to a given reference point.
You can add properties to Endeca records that represent latitude and longitude pairs. These properties are known as geocode properties.
For example, if the records of a particular dataset represent individual books that a large vendor has for sale at a variety of locations, each book could be tagged with a geocode property named Location that holds the store location information for that particular book. Users could then filter the books to show only those books within a certain distance from their current location.
Note
Geospatial filtering is closely related to geospatial sorting.
You map a source property to an Endeca property in order to make the source property available in your Endeca implementation. Before you can map a geocode source property, you must configure the Endeca property that it will map to as geocode. To configure a geocode Endeca property:
Aggregated records allow you to treat a collection of separate records as one if the rollup key is the same for any number of records.
An aggregated record is a collection of individual Endeca records that have been rolled up based on a rollup key (an Endeca property or dimension name). All records in the current record set that have the same value for the rollup key are collected together into an aggregated record. For example, rolling up on a Name key causes all wines in the current record set that have the value 'My Red Wine' for the Name key to be rolled up into one aggregated record.
Commonly, aggregated records are used to eliminate duplicate display entries. For example, in a music store catalog, an album by the same title may exist in several formats, with multiple prices. Each title is represented in the MDEX Engine as a distinct record. However, from a business perspective, it might be useful to treat these separate records as a single record by creating an aggregate record.
Record aggregation affects the current record set only. In other words, if you have 10,000 Endeca records total but only 3,000 are displayed in the current record set, then the aggregation affects those 3,000 records only.
The aggregated records feature requires that each record should have at most one value from the dimension or Endeca property that has been specified as the rollup key. Also, if an Endeca record has a unique value for the rollup key, it is 'rolled up' into an aggregated record that contains only one sub-record.
Note
Fully implementing this feature requires additional work outside of Developer Studio. Please refer to the Endeca Basic Development Guide for details.
When an application user provides individual search terms in a query, the automatic phrasing feature groups those individual terms into a search phrase and returns query results for the phrase.
Automatic phrasing is similar to placing quotation marks around search terms before submitting them in a query. For example, 'my search terms' is the phrased version of the query my search terms. However, automatic phrasing removes the need for application users to place quotation marks around search phrases to get phrased results.
The result of automatic phrasing is that a Web application can process a more restricted query and therefore return fewer and more focused search results. This feature is available only for record search.
The automatic phrasing feature works by:
Comparing individual search terms in a query to a list of application-specific search phrases. The list of search phrases are stored in a project's phrase dictionary.
Returning query results that are either based on the automatically phrased query, or returning results based on the original unphrased query along with automatically phrased 'Did You Mean?' (DYM) alternatives.
Point three above suggests the two typical implementation scenarios to choose from when using automatic phrasing:
Process an automatically phrased form of the query and suggest the original unphrased query as a DYM alternative.
In this scenario, the automatic phrasing feature rewrites the original query's search terms into a phrased query before processing it. If you are also using DYM, you can display the unphrased alternative so the user can opt-out of automatic phrasing and select their original query, if desired.
For example, an application user searches a wine catalog for the terms "low tannin." The MDEX Engine compares the search terms against the phrase dictionary, finds a phrase entry for "low tannin," and processes the phrased query as "low tannin." The MDEX Engine returns 3 records for the phrased query "low tannin" rather than 16 records for the user's original unphrased query "low tannin." However, the Web application also presents a "Did you mean low tannin?" selection so the user may opt-out of automatic phrasing, if desired.
Process the original query and suggest an automatically-phrased form of the query as a DYM alternative.
In this scenario, the automatic phrasing feature processes the unphrased query as entered and determines if a phrased form of the query exists. If a phrased form is available, the Web application displays an automatically-phrased alternative as a "Did you mean?" option. The user can opt-in to automatic phrasing, if desired.
For example, an application user searches a wine catalog for low tannin. The MDEX Engine returns 16 records for the user's unphrased query low tannin. The Web application also presents a "Did you mean "low tannin"?" option so the user may opt-in to automatic phrasing, if desired.
There are two tasks to implement automatic phrasing:
Note
Implementing search features requires additional work outside of Developer Studio. Refer to the Endeca Advanced Development Guide for details.
In order to use an Endeca property as a rollup key, you must enable its Rollup attribute.
To enable record rollup for an Endeca property:
Note
This feature requires that each record should have at most one value from the Endeca property or dimension that has been specified as the rollup key.
Fully implementing this feature requires additional work outside of Developer Studio. Please refer to the Endeca Basic Development Guide for details.
Wildcard searching allows user queries that contain a wildcard character (*) to match against fragments of words in a property value. You must enable each property that you want available for wildcard searching.
To enable wildcard searching for an Endeca property:
Fully implementing this feature requires additional work outside of Developer Studio. Please refer to the Endeca Basic Development Guide for details.
