10 Personalization Tags

Personalization Concepts

Personalization is a mechanism to tailor recommendations to application users, based on behavioral, purchasing, rating, and demographic data. Recommendations are made in real-time, during a user's application session. User behavior is saved to a profile in a database repository for use in building models to predict future user behavior.

In future user sessions, the models are used to predict behavior and desires of similar users (or, within a single session, the same user), such as products or services to purchase or Web sites to visit. The user will receive recommendations based on these predictions.

The OracleAS Personalization tag library exposes two key functions of personalization:

• Choosing the most relevant content to deliver, based on past user behavior as collected in the user profile

• Embedding this personalized content into application output or Web pages in a flexible manner

A typical personalization scheme might take any or all of the following into account:

• User Web-surfing patterns

• Past user purchase activities

• Past user ratings of items

• Anticipated nature and degree of user interest (such as "buy" versus "like")

• User demographics, such as age, sex, and income

  
  

  Note: The concept of personalization is not limited to Web sites and Web applications. You can use personalization in any application where there is appropriate data and a need for personalized recommendations, such as CRM applications. Web applications are the focus of this particular document, however.

  
  

Personalization Versus Customization

Personalization, as implemented by Oracle and described in this chapter, is a complex and dynamic set of features that result in content being chosen automatically and implicitly. It should not be confused with simpler and more static Web site mechanisms that are often referred to as "personalization" but are really simply "customization".

Many sites offer customization such as giving a user a set of possible topics of interest—local weather, stocks of interest, or favorite sports, for example—then displaying output based on the chosen topic. Although it is true that this personalizes the content that is delivered, the process is static and requires explicit user involvement. The focus of the content does not change until the user has an opportunity to change it explicitly through another topic selection.

Personalization chooses content for the user automatically, without direct user request. The process of choosing content is hidden. Moreover, as the system becomes more familiar with user habits by observing behavior, it achieves increased accuracy in predicting future behavior and interests.

Basis for Recommendations

Depending on the configuration and tuning of an OracleAS Personalization environment, recommendations are based on one or more factors such as the following:

• Past behavior of similar users, according to demographics

• Behavior of past users who have shown the same interests, such as a general trend being established that users who look at items 1, 2, and 3 are likely to be interested in items 5 and 6 as well, without considering the demographics or profiles of the users

• Behavior of the same user earlier in the current session, allowing user-specific personalization even for first-time users or anonymous visitors, as well as providing a high degree of tuning regarding the purpose of the current visit

• Hot picks recommendations, based on current promotions, features of the week, and so on, which might or might not account for user identity

Key Components

OracleAS Personalization includes the following key components:

• Mining table repository (MTR)

• Mining object repository (MOR)

• Recommendation engine farm, consisting of one or more recommendation engines

• Recommendation engine Java API

These are all introduced in upcoming sections.

Introduction to Mining Table Repository

The OracleAS Personalization Mining Table Repository (MTR) contains the schema and data to be used for data mining. It is a set of database tables and views containing the following:

• Records of previous user behavior

• Data collected elsewhere and imported into the repository

• User demographics

These factors are taken together for use in building models to predict future user preferences.

Introduction to Models

A model is essentially a collection of rules deduced from user data. A simplified example of a rule is "female over 55, income between $150,000 and $200,000, recently purchased scuba tank and mask, likely to buy fins and thermal suit".

In OracleAS Personalization, a model is developed according to recorded facts gathered from the mining table repository. Rules in the model are deduced strictly from available data, not from general or common-sense assumptions of what might be typical for a certain classification of person. How close a particular user's characteristics are to the rules of the best available model determines the likelihood of the resulting recommendation being correct or appropriate.

Introduction to Mining Object Repository

The OracleAS Personalization Mining Object Repository (MOR) is a database schema that maintains mining meta data and mining model results as defined in the OracleAS Personalization data mining schema. The mining object repository serves as the focus for logging in to the data mining system, logging off, and scheduling OracleAS Personalization events. The building of models out of the mining table repository is accomplished according to OracleAS Personalization data mining algorithms.

It is possible to build different models out of the same data by tuning the relevant algorithm to weigh different characteristics of the data more or less heavily. Therefore, there might be multiple models in the mining object repository for a given situation, but only one model is deployed into a recommendation engine at any particular time.

Introduction to Recommendation Engines

An OracleAS Personalization Recommendation Engine (RE) is an Oracle Database schema that downloads an OracleAS Personalization model during deployment, then fetches appropriate user profile data from the mining table repository when processing a request for recommendations. Each engine is responsible for activities such as the following:

• Loading and holding model data

• Processing recommendation requests

• Collecting user profile data

A recommendation engine processes recommendation requests at runtime and produces personalized recommendations. It also tracks current user behavior at the Web site, collecting user profile data during a session. This latter features allows session-specific personalization for anonymous users and registered users alike.

Populating a recommendation engine involves building a model and then deploying it to a recommendation engine schema, steps that happen behind the scenes. The calculation of particular recommendations is accomplished by PL/SQL stored procedures in the schema.

Introduction to Recommendation Engine Farms

A recommendation engine must be part of a recommendation engine farm. All engines in a farm are loaded with the same model and can be used interchangeably. It is permissible for a farm to consist of only one engine; however, for load-balancing and failover purposes, it is advisable to have multiple engines in the farm. To accomplish the desired effect, these engines would reside in different databases on different physical systems.

Visitors Versus Customers

The recommendation engine has two classifications of users:

• Visitor: This is an anonymous user who is not recognized and does not have a demographic profile or a stored history of past behavior, preferences, and actions.

• Customer: This is a registered user who is therefore recognized and has a demographic profile and stored history of behavior to be used in generating accurate recommendations.

  
  

  Note: An anonymous visitor can be converted into a registered user in the middle of a session. See "Personalization setVisitorToCustomer Tag".

  
  

Items, Recommendations, Taxonomies, and Categories

In OracleAS Personalization, item is a generic concept referring to a single article or the smallest unit of information. Following are some examples:

• Product

• Service to purchase

• URL selected by a user

• Piece of demographic data such as a user's gender or age

Items are used in several ways:

• They can be passed to item-recording tags for the recording of user data. In this situation they are sometimes referred to as data items.

• They can be returned as suggestions. In this situation, they are referred to as recommendations. For each item returned as a recommendation, there is also a prediction value, which is either a rating or a ranking. These terms are discussed in "Ratings and Rankings".

• They can be passed as input when the application requests recommendations. This is done for cross-selling, where recommended items are based on past items, or to evaluate and rate or rank a particular set of items.

All individual items in an inventory system must belong to a taxonomy. In OracleAS Personalization, a taxonomy refers to a structural organization of items. Typically, the organization of items has a hierarchical structure like a tree or collection of trees, branching from broader groups at the trunk to individual items at the leaves. Item membership in a taxonomy is not exclusive. It is possible to include the same item in multiple taxonomies. A taxonomy is represented by a taxonomy ID, which is a long integer.

Catalog or Web site hosting applications can distinguish among their client data sets by using different taxonomy IDs for different client catalogs or Web sites. Appropriate processing is used to distinguish between classifications of users so that an appropriate taxonomy can be used in each case. For example, a customer at www.oracle.com might indicate that she is a DBA or Web developer. This will determine the taxonomy used in personalizing her future visits. The offering of promotional campaigns, banners, and available books and training, for example, would be drawn either from a Web productivity tools taxonomy or a database administration tools taxonomy.

Individual items within a taxonomy can be grouped into categories. In the structure of a taxonomy, categories are intermediate nodes consisting of groups of related items. Note, however, that any given item can belong to multiple categories. As an example, the movie The English Patient might belong to categories such as "Screen Adaptations of Novels", "Oscar Winners", "Foreign", and "Drama".

Generally, an item is uniquely identified by a type parameter and an ID parameter, although a rating item also requires a parameter for the rating value itself. It is assumed that an application will be able to rely on some sort of inventory system that determines a type and ID for each item. A type might be something like "shoes" or "sporting events". An ID is an identifying number. Within any single taxonomy, no two items can have the same ID.

Be aware that for some personalization filtering settings, a recommendation will represent a category, such as "Drama", rather than an item, such as a specific movie title. In this case, the item type of the recommendation is "Category". Also see "Recommendation Filtering".

The OracleAS Personalization tag library provides a convenient public class to simplify the use of items and recommendations in JSP pages: the oracle.jsp.webutil.personalization.Item class. Use this class to access type, ID, and prediction values. See "Item Class Description" for more information.

Ratings and Rankings

Items returned as recommendations include a prediction value, as follows:

• For a rating item, the prediction value of each item is its rating. This is a predicted measure of user interest.

• For a purchasing or navigation item, the prediction value indicates a relative ranking among the returned items, based on the estimated probability of user interest.

A navigation item can represent anything a Web application might consider a "hit", such as viewing a page, selecting a link, or clicking a button.

Stateful Versus Stateless Recommendation Engine Sessions

Web applications can be either stateful or stateless. That is, an application might choose to maintain a user session and user-specific information on the server between requests, or it might not. The recommendation engine API and tag library are designed to handle both situations. Although there are obvious benefits to maintaining user information on the server between requests, there are also high-volume sites that rely on stateless applications for better throughput.

Note, however, that the recommendation engine will always track open user sessions in the recommendation engine database schema, regardless of the session behavior of the Web application.

The recommendation engine tracks a user session by its user ID. Therefore, care must be taken in assigning temporary user IDs to anonymous visitors. If the same ID is used for all anonymous visitors, and their behavior is being tracked, then data collected from all such visitors will be attributed to a single recommendation engine session and therefore behavior of any one anonymous visitor would influence recommendations to the others. You can avoid this problem by assigning each anonymous visitor a temporary ID that is unique within the recommendation engine.

Requests for Recommendations

After a recommendation engine session is established and populated with data, an application can request recommendations from it. OracleAS Personalization returns the appropriate recommendations to the calling application, then the application decides what to pass to the user and how to pass it.

In JSP pages, an application can request recommendations through one of several "recommendation tags". The recommendation engine returns a set of suggested items according to user data, with respect to tuning and filtering settings. In using the OracleAS Personalization tag library, you can specify tuning and filtering settings through tag attributes or in a configuration file.

A set of recommendations is generated in the recommendation engine database schema through a JDBC call. The time spent in the call may vary. This depends on the criteria, how many data records must be processed, and such factors as the size of the rules table, the size of the user profile data, and specifics of the recommendation request. Recommendations will be chosen according to the personalization model, which is deployed into the recommendation engine that the application is connected to. When you use OracleAS Personalization tags, use attributes of the startRESession tag to specify the recommendation engine to use.

For cross-sell recommendations, the application must pass in as input one or more purchasing or navigation items of past user interest. The cross-sell recommendations will be based on the item or items passed in, and perhaps on past or current user data as well.

Recommendation items are returned in an array, with a prediction value for each recommendation—either a rating or a ranking, as described in "Ratings and Rankings"—and an interest dimension value for the array as a whole. For items returned as recommendations, the interest dimension indicates how the items will be of interest to the user—as purchasing items, navigation items, or rating items.

The recommendation engine API allows filtering of recommendations before they are returned, based on the taxonomy.

Starting a Recommendation Engine Session

The startRESession tag takes the recommendation engine name and other information from some combination of tag attribute settings and personalization.xml configuration file settings.

A startRESession tag will result in no operation if the recommendation engine session was previously started for the same Web client, with no endRESession tag executed in between. This is for convenience; it allows flexibility regarding the order in which JSP pages are executed. You can place startRESession tags in multiple pages of an application without negative consequences.

See "Personalization startRESession Tag" for more information about this tag. Also see "Personalization Tag Library Configuration Files".

Using a Stateful Application

For a stateful application, which uses HTTP sessions, session information is maintained in the JSP implicit session object, a standard HttpSession instance.

When the startRESession tag is encountered, if its session attribute is set to "true" (the default), then the session object is created automatically if it does not already exist.

Using a Stateless Application

For a stateless application, the tag library will maintain internal session tracking through the use of cookies. Therefore, be aware that if you want to use a stateless application, personalization tags will work only if the client browser accepts cookies. If that is not the case, either because the browser chooses to decline cookies or due to lack of capability, then stateful functionality is required (session="true" for the startRESession tag).

Ending a Recommendation Engine Session

When a stateful application no longer needs a given recommendation engine session, you can use the endRESession tag. As with startRESession tags, repeated executions of endRESession tags result in no further operations, so you can place them in multiple pages of your application without negative consequences.

The endRESession tag has no effect in stateless applications.

Using endRESession tags in stateful applications is sometimes optional, but is necessary in the following circumstances:

• If the application intends to subsequently start a new recommendation engine session with a different recommendation engine user ID from the same browser or within the same HTTP session

• To connect to a different recommendation engine from the same browser or within the same HTTP session

In these cases, the endRESession tag must be executed before the next startRESession tag.

Use of endRESession tags is also advisable if an application stops using its OracleAS Personalization tags significantly before the HTTP session is over, so that recommendation engine resources can be released.

See "Personalization endRESession Tag" for detailed information about this tag.

Overview of Item Recording and Removal Tags

The following tags are for recording data items into the recommendation engine session cache or for removing items that were recorded earlier in the session:

• recordNavigation and removeNavigationRecord

• recordPurchase and removePurchaseRecord

• recordRating and removeRatingRecord

• recordDemographic and removeDemographicRecord

  
  

  Note: During the session, recorded items are periodically flushed to the recommendation engine. Removing an item after that point still works, but requires a database round-trip. See related information about REFlushInterval in "Personalization startRESession Tag".

  
  

To record or remove a purchasing, navigation, or rating item, you must specify the item to record or remove by providing either a type and ID (and a value, for a rating item), or an item array and an index into that array. See "Specification of Input Items" for more information. To record or remove a demographic item, which implicitly applies to the current user, you must specify the demographic type, such as AGE, and a value, such as 44. See "Demographic Items".

There is typically little need to use the removeXXXRecord tags. If you place your recordXXX tags in "receiving pages", there should be no need to use removePurchaseRecord or removeNavigationRecord tags. Using removeRatingRecord and removeDemographicRecord tags would be necessary only in situations where users changed their minds after their initial input had been recorded. See "Mode of Use for Item Recording Tags" for related information.

For detailed tag information, see "Item Recording and Removal Tag Descriptions".

Overview of Recommendation and Evaluation Tags

The following tags return an array of items as recommendations:

• selectFromHotPicks

• getRecommendations

• getCrossSellRecommendations

• evaluateItems

For the selectFromHotPicks, getRecommendations, and getCrossSellRecommendations tags, which are referred to in this document as recommendation tags, the array of items is a set of recommendations returned from an entire taxonomy or from hot picks groups within a taxonomy. The getCrossSellRecommendations tag must also take a set of purchasing items or navigation items as input, on which to base the recommendations (known as cross-selling).

Hot picks might be promotional items or other specially selected groups of items. The picks to choose from can be specified through a tag attribute. See the Oracle Application Server Personalization Administrator's Guide for more information about hot picks.

For evaluateItems, you must input a particular set of items for which you want evaluations. Some or all (or in some cases, none) of the same items are then returned, either rated or ranked depending on the interest dimension. See "Ratings and Rankings" for background information.

For the getRecommendations and evaluateItems tags, the results are based on the particular user. The user identity is specified through the startRESession tag and is implicitly applied to all subsequent personalization tags. The getCrossSellRecommendations tag depends on the set of input items.

Use of Tag-Extra-Info Scripting Variables for Returned Items

For each tag that returns an array of items, there is a tag-extra-info (TEI) class that provides functionality allowing you to use a scripting variable of the following array type:

oracle.jsp.webutil.personalization.Item[]

The array of items is returned in this variable. Each of these tags has a storeResultsIn attribute that you use to specify a variable name. You can loop through the array in your application to display all the items, such as in an HTML table. Use the length attribute of the array to determine how many items were returned.

The selectFromHotPicks, getRecommendations, and getCrossSellRecommendations tags can also return a TEI String variable indicating the interest dimension for the items in the array, either NAVIGATION, PURCHASING, or RATING. Use the storeInterestDimensionIn tag attribute to specify a variable name for the interest dimension.

Specification of Input Items

There are two general situations where you must input items:

• To provide input items to a getCrossSellRecommendations or evaluateItems tag

  In addition to the getCrossSellRecommendations or evaluateItems tag, this can involve one or more nested forItem tags. The forItem tags are used to select desired input items.

• To record an item into the recommendation engine session or, using similar syntax, to remove an item that was previously recorded

  This involves a recordXXX or removeXXXRecord tag.

You can specify items in the following general ways:

1. Specify the type and ID of each desired item, and also the rating value for a rating item. Or, for a demographic item, specify the type and value.

2. Supply an item array, and the index into the array for each desired item.

3. Supply an entire array of items (not relevant for recordXXX and removeXXXRecord tags).

For scenarios #2 and #3, see the following section, "Inputting Item Arrays", for more information.

You can input one or more items into a getCrossSellRecommendations or evaluateItems tag as follows:

• Nest one or more forItem tags inside the tag, using the type and ID attributes of each forItem tag to specify a desired item (scenario #1 above).

or:

• Nest one or more forItem tags inside the tag, using the itemList attribute of each forItem tag to specify an item array and using the index attribute to specify a desired element of the array (scenario #2).

or:

• Specify an Item[] array through the inputItemList attribute of the tag (scenario #3). The entire array is taken as input.

Note that you can use more than one of these procedures simultaneously. The getCrossSellRecommendations and evaluateItems tags can take input from multiple sources.

You can specify an item for a recordXXX or removeXXXRecord tag as follows:

• Use the type and ID attributes of the tag, and the value attribute for recordRating or removeRatingRecord, to specify the item (scenario #1 above). Or, for recordDemographic or removeDemographicRecord, use the type and value attributes.

or:

• Use the itemList attribute of the tag to specify an item array, and the index attribute of the tag to specify the desired element of the array (scenario #2).

Inputting Item Arrays

For situations where you input an array of Item[] objects to a tag, you must specify the array through a JSP expression. This can apply to any of the following tags:

• getCrossSellRecommendations or evaluateItems, when you use the inputItemList attribute to input an entire array

• forItem (inside getCrossSellRecommendations or evaluateItems), recordPurchase, recordNavigation, recordRating, removePurchaseRecord, removeNavigationRecord, or removeRatingRecord, when you use the itemList and index attributes to input an array and specify one element of it for use

You can supply the array in the following ways:

• Create it in a scriptlet and specify it through a JSP expression:

  <% Item[] myList = newItem[] {newItem("shoes", 1)}; %>
  <op:evaluateItems inputItemList="<%=myList %> .../>
  
  

• Supply it by using a TEI variable that contains the output from a recommendation tag:

  <op:getRecommendations storeResultsIn="myRecs" .../>
  <!-- First tag is closed, but TEI variable is still in scope. 
  Later use it in second tag. -->
  <op:getCrossSellRecommendations inputItemList="<%=myRecs %>" />
  

  
  

  Note: See "Recommendation and Evaluation Tag Descriptions" for detailed syntax information for the tags shown here.

  
  

Demographic Items

Demographic data items, consisting of background information about the user such as gender and age, are used in only the recordDemographic and removeDemographicRecord tags. Because they do not contain purchasing, navigation, or rating information, they cannot be returned by a recommendation tag or input to a getCrossSellRecommendations or evaluateItems tag.

Demographic items, instead of being identified by type and ID as for purchasing and navigation items, are identified by type and value. These are the only two attributes for the recordDemographic and removeDemographicRecord tags. There are several pre-defined types, which exist as columns in the mining table repository in the MTR.MTR_CUSTOMERS table:

• GENDER

• AGE

• MARITAL_STATUS

• PERSONAL_INCOME

• HOUSEHOLD_INCOME

• IS_HEAD_OF_HOUSEHOLD

• HOUSEHOLD_SIZE

• RENT_OWN_INDICATOR

There are also 50 columns you can customize: ATTRIBUTE1 through ATTRIBUTE50. To use a custom type, you must do the following:

1. Map the ATTRIBUTEx column to an existing enterprise database, thus defining what the attribute is.

2. Define the corresponding value boundaries in the MTR.MTR_BIN_BOUNDARIES table.

Tuning Settings

Several tuning settings determine some of the qualifications and logic used by the recommendation engine in returning recommendations. There must be a value for each setting, determinable in one of the ways described here.

You can specify these settings through the tuningXXX attributes of the selectFromHotPicks, getRecommendations, getCrossSellRecommendations, and evaluateItems tags, as summarized in Table 10-1. Alternatively, you can use the tuningName attribute to get the settings from the specified <Tuning> element in either the application-level personalization.xml file (preferred) or the server-wide personalization.xml file. Also see "Personalization Tag Library Configuration Files".

If there are no attribute settings and no <Tuning> element, default values will be chosen according to the following steps, in order:

1. According to a <DefaultTuning> element in the application-level personalization.xml file.

2. According to a <DefaultTuning> element in the server-wide personalization.xml file.

3. According to the following hardcoded settings:

   tuningDataSource="ALL"
   tuningInterestDimension="NAVIGATION"
   tuningPersonalizationIndex="MEDIUM"
   tuningProfileDataBalance="BALANCED"
   tuningProfileUsage="INCLUDE"
   

   
   

   Note: To use the hardcoded defaults, do not use any of the tuningXXX attribute settings. If some tuning settings are defined in a tag, then none of the hardcoded values will be used. In this case, if any setting cannot be found in a tag attribute or personalization.xml file, an exception will be thrown.

   
   

For more information about tuning settings, refer to the Oracle Application Server Personalization Administrator's Guide.

Recommendation Filtering

In addition to tuning settings, there are filtering settings that you can specify for a recommendations request. There must be a value for each setting, determinable in one of the ways described here.

You can specify these settings through the filteringXXX attributes of the getRecommendations, getCrossSellRecommendations, and selectFromHotPicks tags. (Filtering is not relevant to the evaluateItems tag.) Alternatively, you can use the filteringName attribute to get the settings from the specified <Filtering> element in either the application-level personalization.xml file (preferred) or the server-wide personalization.xml file. Also see "Personalization Tag Library Configuration Files".

If there are no attribute settings and no <Filtering> element, default values will be chosen from the <DefaultFiltering> element in either the application-level personalization.xml file (preferred) or the server-wide personalization.xml file.

These are the filtering parameters:

• filteringTaxonomyID: This is a Java string representing an integer, where the integer is the ID of an item taxonomy in the OracleAS Personalization environment.

• filteringMethod: This is one of ALL_ITEMS, INCLUDE_ITEMS, EXCLUDE_ITEMS, SUBTREE_ITEMS, ALL_CATEGORIES, INCLUDE_CATEGORIES, EXCLUDE_CATEGORIES, SUBTREE_CATEGORIES, and CATEGORY_LEVEL. Table 10-2 summarizes the meanings. These methods always apply to the taxonomy specified through the filteringTaxonomyID value.

  For the getCrossSellRecommendations tag, only the ALL_ITEMS, INCLUDE_ITEMS, EXCLUDE_ITEMS, and SUBTREE_ITEMS settings are supported.

• filteringCategories: This is a Java string of integer IDs, delimited by a single plus sign (+) after each ID, identifying existing item categories in the given taxonomy. Categories are defined in the MTR.MTR_CATEGORY table of the mining table repository.

  
  

  Note: Do not provide a filteringCategories setting when filteringMethod is ALL_ITEMS or ALL_CATEGORIES.

  
  

For any of the XXX_CATEGORIES settings, recommendations are returned in the form of categories, such as "drama", rather than specific items, such as a particular movie title. The item type is Category in this case, and categories must first be defined in the mining table repository.

For more information about filtering settings, refer to the Oracle Application Server Personalization Programmer's Guide.

Sorting Order

You can sort returned items according to the prediction field of each item, which is either a rating or a ranking. See "Ratings and Rankings" for information about how to use this field.

Use the sortOrder attribute of the selectFromHotPicks, getRecommendations, getCrossSellRecommendations, or evaluateItems tag to specify a sorting order of ASCEND, DESCEND, or NONE (default). Ascending order lists the best match first; descending order does the opposite. An ascending order of five ranked items would be 1, 2, 3, 4, then 5, because 1 is the highest rank. An ascending order of five rated items would be something like 4.5, 3.9, 2.5, 2.2, then 1.8, because a higher number means a higher rating.

Personalization startRESession Tag

This section provides syntax and attribute descriptions for the startRESession tag, which you use to start a recommendation engine session. Also see "Recommendation Engine Session Management" for related information.

The startRESession tag must be executed before any other OracleAS Personalization tag that executes within the same recommendation engine session.

<op:startRESession REName = "recommendation_engine_connection_name"
                 [ REURL = "rec_engine_database_connection_URL" ]
                 [ RESchema = "rec_engine_schema_name" ]
                 [ REPassword = "rec_engine_schema_password" ]
                 [ RECacheSize = "kilobytes_of_cache" ]
                 [ REFlushInterval = "milliseconds_to_flush" ]
                 [ session = "true" | "false" ]
                 [ userType = "visitor" | "customer" ]
                 [ UserID = "user_ID_for_site_login" ]
                 [ storeUserIDIn = "variable_name" ]
                 [ disableRecording = "true" | "false" ] />

<op:startRESession REName = "RE1"
                   REURL = "@jdbc:oracle:thin:@sid"
                   RESchema = "scott"
                   REPassword = "->scott" />

Personalization endRESession Tag

Use this tag to explicitly end a recommendation engine session in a stateful application. This is usually optional, but is required under some circumstances. (See "Ending a Recommendation Engine Session".) It is also advisable to use this tag in a stateful application if application logic determines that the recommendation engine session is no longer required. This will free unneeded resources.

For situations where you do not use endRESession, note the following behavior:

• If you started the recommendation engine session with the session attribute of the startRESession tag set to "true", then the recommendation engine session will be closed implicitly at the end of the HTTP session.

• If you started the recommendation engine session with session set to "false", then the recommendation engine session will be allowed to time out once it has been inactive for a sufficient period of time. The timeout interval is specified as a configuration parameter of the recommendation engine schema. The endRESession tag has no effect.

<op:endRESession />

Personalization setVisitorToCustomer Tag

Use this tag for situations where an anonymous visitor creates a registered customer account. Upon execution of this tag, the existing recommendation engine session is converted from a visitor session to a customer session. Previous data gathered in the session will be retained. This tag does not actually create the new customer, nor does it execute a new login. It only converts the ongoing recommendation engine session.

The customerID is a request-time attribute and must be provided by the application.

<op:setVisitorToCustomer customerID = "<%=registered_customer_name%>" />

Personalization getRecommendations Tag

Use this tag to request a set of recommendations for purchasing, navigation, or ratings. Items from a particular taxonomy are considered, with tuning and filtering as specified. Recommendations are returned in an array of the following type:

oracle.jsp.webutil.personalization.Item[]

Although other tags, such as getCrossSellRecommendations and evaluateItems, require items to be input for use as a basis for recommendations, the getRecommendations tag does not. Recommendations are based on user identity and profile (user session and historical data), not on specific items.

The resulting recommendations can optionally be stored in a TEI variable of type Item[], with the variable name specified in the storeResultsIn attribute of the tag. The recommendations are also available implicitly within the getRecommendations tag. You can optionally use a tag body with nested getNextItem tags for any desired processing of the items. See "Personalization getNextItem Tag".

<op:getRecommendations 
  [ from = "top" | "bottom" ]
  [ fromHotPicksGroups = "string_of_Hot_Picks_group_numbers" ]
  [ storeResultsIn = "TEI_variable_name" ]
  [ storeInterestDimensionIn = "TEI_variable_name" ]
  [ maxQuantity = "integer_value" ]
  [ tuningName = "name_from_config_file_Tuning_element" ]
  [ tuningDataSource = "ALL"|"NAVIGATION"|"PURCHASE"|"RATING"|"DEMOGRAPHIC" ]
  [ tuningInterestDimension = "NAVIGATION"|"PURCHASING"|"RATING" ]
  [ tuningPersonalizationIndex = "LOW"|"MEDIUM"|"HIGH" ]
  [ tuningProfileDataBalance = "HISTORY"|"CURRENT"|"BALANCED" ]
  [ tuningProfileUsage = "INCLUDE"|"EXCLUDE" ] 
  [ filteringName = "name_from_config_file_Filtering_element" ]
  [ filteringTaxonomyID = "integer_value" ]
  [ filteringMethod = "ALL_ITEMS"|"EXCLUDE_ITEMS"|"INCLUDE_ITEMS"|
            "SUBTREE_ITEMS"|"ALL_CATEGORIES"|"INCLUDE_CATEGORIES"|
            "EXCLUDE_CATEGORIES"|"SUBTREE_CATEGORIES"|CATEGORY_LEVEL" ]
  [ filteringCategories = "string_of_integers" ]
  [ sortOrder = "ASCEND"|"DESCEND"|"NONE" ] >

...

</op:getRecommendations>

<op:getRecommendations storeResultsIn="myRecs">
<% for(int i = 0; i< myRecs.length; i++) {
   Render(myRecs(i).getType(),myRecs(i).getID());
} %>
</op:getRecommendations>

Personalization getCrossSellRecommendations Tag

Like the getRecommendations tag, the getCrossSellRecommendations tag returns a set of recommendations in an array of type Item[] for purchasing, navigation, or ratings. Items from a particular taxonomy are considered, with tuning and filtering as specified.

To use getCrossSellRecommendations, however, you must input a set of purchasing or navigation items of past user interest that are used as a basis for the resulting recommendations. The items must all be from the same taxonomy.

You can input items through a specified item array or through a tag body with nested forItem tags. See "Specification of Input Items" for more information. Also see "Personalization forItem Tag".

The recommendations from the getCrossSellRecommendations tag are stored in a TEI variable of type Item[], with the variable name specified in the storeResultsIn attribute of the tag.

<op:getCrossSellRecommendations 
    storeResultsIn = "TEI_variable_name" 
  [ storeInterestDimensionIn = "TEI_variable_name" ]
  [ fromHotPicksGroups = "string_of_Hot_Picks_group_numbers" ]
  [ inputItemList = "item_array_expression" ]
  [ maxQuantity = "integer_value" ]
  [ tuningName = "name_from_config_file_Tuning_element" ]
  [ tuningDataSource = "ALL"|"NAVIGATION"|"PURCHASE"|"RATING"|"DEMOGRAPHIC" ]
  [ tuningInterestDimension = "NAVIGATION"|"PURCHASING"|"RATING" ]
  [ tuningPersonalizationIndex = "LOW"|"MEDIUM"|"HIGH" ]
  [ tuningProfileDataBalance = "HISTORY"|"CURRENT"|"BALANCED" ]
  [ tuningProfileUsage = "INCLUDE"|"EXCLUDE" ] 
  [ filteringName = "name_from_config_file_Filtering_element" ]
  [ filteringTaxonomyID = "integer_value" ]
  [ filteringMethod = "ALL_ITEMS"|"EXCLUDE_ITEMS"|"INCLUDE_ITEMS"|
                      "SUBTREE_ITEMS" ]
  [ filteringCategories = "string_of_integers" ]
  [ sortOrder = "ASCEND"|"DESCEND"|"NONE" ] >

...

</op:getCrossSellRecommendations>

<% long[] ids = ApplicationPackage.getUserHistory("Smith01");
   Item[] DVDs = new Item[ids.length];
   for(int i=0; i<ids.length; i++) {
      DVDs[i] = new Item("DVD", ids[i] );
   }
   pageContext.setAttribute("pastInterest", DVDs);
%>
<op: getCrossSellRecommendations inputItemList="pastInterest"
                                 storeResultsIn="moreDVDs"
                                 maxQuantity = "4"
                                 sortOrder="ASCEND" />
<!-- display 4 best cross-sell items -->
<h1> You will also enjoy these titles! </h1>

ApplicationSupport.displayItem(moreDVDs[1].getType(), moreDVDs[1].getID() );
ApplicationSupport.displayItem(moreDVDs[2].getType(), moreDVDs[2].getID() );
ApplicationSupport.displayItem(moreDVDs[3].getType(), moreDVDs[3].getID() );
ApplicationSupport.displayItem(moreDVDs[4].getType(), moreDVDs[4].getID() );

Personalization selectFromHotPicks Tag

Use this tag to request recommendations from a set of hot picks groups only, instead of from the taxonomy as a whole, and without considering the user profile. Tuning and filtering are still applied to items in the specified groups.

Other than the fact that selectFromHotPicks does not consider user identity and profile, it works in essentially the same way as the getRecommendations tag with a specified fromHotPicksGroups setting. See "Personalization getRecommendations Tag" for detailed information about that tag.

You can optionally store the resulting recommendations in a TEI variable of type Item[], with the variable name specified in the storeResultsIn attribute of the tag. The recommendations are also available implicitly within the selectFromHotPicks tag. You can optionally use a tag body with nested getNextItem tags for any desired processing of the items. See "Personalization getNextItem Tag".

<op:selectFromHotPicks 
    hotPicksGroups = "string_of_Hot_Picks_group_numbers"
  [ storeResultsIn = "TEI_variable_name" ]
  [ storeInterestDimensionIn = "TEI_variable_name" ]
  [ maxQuantity = "integer_value" ]
  [ tuningName = "name_from_config_file_Tuning_element" ]
  [ tuningDataSource = "ALL"|"NAVIGATION"|"PURCHASE"|"RATING"|"DEMOGRAPHIC" ]
  [ tuningInterestDimension = "NAVIGATION"|"PURCHASING"|"RATING" ]
  [ tuningPersonalizationIndex = "LOW"|"MEDIUM"|"HIGH" ]
  [ tuningProfileDataBalance = "HISTORY"|"CURRENT"|"BALANCED" ]
  [ tuningProfileUsage = "INCLUDE"|"EXCLUDE" ] 
  [ filteringName = "name_from_config_file_Filtering_element" ]
  [ filteringTaxonomyID = "integer_value" ]
  [ filteringMethod = "ALL_ITEMS"|"EXCLUDE_ITEMS"|"INCLUDE_ITEMS"|
            "SUBTREE_ITEMS"|"ALL_CATEGORIES"|"INCLUDE_CATEGORIES"|
            "EXCLUDE_CATEGORIES"|"SUBTREE_CATEGORIES"|CATEGORY_LEVEL" ]
  [ filteringCategories = "string_of_integers" ]
  [ sortOrder = "ASCEND"|"DESCEND"|"NONE" ] >

...

</op:selectFromHotPicks>

Personalization evaluateItems Tag

Use the evaluateItems tag to evaluate the set of items that are input to the tag. The items must all be from the same taxonomy. For an interest dimension of PURCHASING or NAVIGATION, the items are ranked. For an interest dimension of RATING, the items are rated. A subset of the evaluated items—anywhere from none to all of the items, depending on effects of the tuningDataSource setting—are returned in a TEI array variable of type Item[]. You must specify the name of the variable through the storeResultsIn attribute. For each item in the array, the prediction attribute contains the ranking or rating value.

See "Ratings and Rankings" for background information about item ratings and rankings.

You can input items through a specified item array or through a tag body with nested forItem tags. See "Specification of Input Items" for more information. Also see "Personalization forItem Tag".

<op:evaluateItems 
    storeResultsIn = "TEI_variable_name" 
    taxonomyID = "integer_value"
  [ inputItemList = "item_array_expression" ]
  [ tuningName = "name_from_config_file_Tuning_element" ]
  [ tuningDataSource = "ALL"|"NAVIGATION"|"PURCHASE"|"RATING"|"DEMOGRAPHIC" ]
  [ tuningInterestDimension = "NAVIGATION"|"PURCHASING"|"RATING" ]
  [ tuningPersonalizationIndex = "LOW"|"MEDIUM"|"HIGH" ]
  [ tuningProfileDataBalance = "HISTORY"|"CURRENT"|"BALANCED" ]
  [ tuningProfileUsage = "INCLUDE"|"EXCLUDE" ] 
  [ sortOrder = "ASCEND"|"DESCEND"|"NONE" ] >

...

</op:evaluateItems>

<% Item[] saleItems = ApplicationSupport.getSaleItems(); %>
<!-- Choose the sale items of greatest interest to this user -->
<op:evaluateItems storeResultsIn="bestItems"  taxonomyID="1"
                  inputItemList="<%=saleItems%>" />

<% ApplicationSupport.displayItem(bestItems(1)); %>

Personalization forItem Tag

Use this tag to specify individual items for input to a getCrossSellRecommendations tag or an evaluateItems tag.

See "Specification of Input Items" for conceptual information about how to use the forItem tag.

<op:forItem 
          [ itemList = "item_array_expression" ]
          [ index = "index_into_item_array" ]
          [ type = "type_of_item" ]
          [ ID = "item_ID_number" ] />

<op: getCrossSellRecommendations storeResultsIn="shoeItems" >
   <op:forItem type="shoes" ID="20" />
   <op:forItem type="shoes" ID="26" />
   <op:forItem type="shoes" ID="45" />
   <op:forItem type="shoes" ID="93" />
   <op:forItem type="shoes" ID="101" />
</op:getCrossSellRecommendations>
<p> Based on past shoe purchases, here are the shoes we recommend! </p>
<%= ApplicationSupport.displayItemArray(shoeItems) %>

Personalization getNextItem Tag

You can optionally use nested getNextItem tags within a getRecommendations or selectFromHotPicks tag body to access the recommendations that the outer tag returns. (The alternative is to access the items through the storeResultsIn attribute of the getRecommendations or selectFromHotPicks tag.)

The first time a getNextItem tag is executed it accesses the first item, then subsequent getNextItem executions proceed through the item array one by one, with each getNextItem execution taking the next item. When the end of the item array is reached, the tag puts null values into each of its tag attributes.

Use tag attributes to store either the type and ID of the next item, or the Item instance itself.

Be aware of the following:

• Using the explicit item array from a getRecommendations or selectFromHotPicks tag, through the storeResultsIn attribute, does not preclude the use of getNextItem tags. The item array accessible through storeResultsIn is unaffected by processing through getNextItem tags.

• If you use one or more getRecommendations tags nested inside another getRecommendations tag, or one or more selectFromHotPicks tags inside another selectFromHotPicks tag, then only one of the tags can use nested getNextItem tags to access implicit tag results. Other tags in the nesting chain must use the storeResultsIn attribute. No such restriction exists for a getRecommendations tag inside a selectFromHotPicks tag, or for a selectFromHotPicks tag inside a getRecommendations tag.

<op:getNextItem 
          [ storeTypeIn = "TEI_variable_for_item_type" ]
          [ storeIDIn = "TEI_variable_for_item_ID" ]
          [ storeItemIn = "TEI_variable_for_Item_instance" ] />

<op:getRecommendations from="top"
                       tuningName="BalancedTuning"
                       filteringName="GeneralFiltering" >
<p> Top Picks selected especially for you: </p>
        <% String type=null;
           String ID=null;
           while(true) { %>
             <op:getNextItem storeTypeIn="type" storeIDIn="ID" />
             <% if(type==null) break;%>
             <li> type: <%=type%> ID: <%=ID%> </li>
        <% } %>
</op:getRecommendations>

<op:selectFromHotPicks hotPicksGroups="1+5"
                       tuningName="HotPicksTuning"
                       filteringName="GeneralFiltering" >
<p> We know you enjoy Horror and Musical movies. Look what we have on
sale this week! </p>
        <% Item item=null;
           while(true) { %>
             <op:getNextItem storeItemIn="item" />
             <% if(item==null) break;%>
             <li> <%= ApplicationSupport.displayItem(item) %> </li>
        <% } %>

</op:selectFromHotPicks>

Personalization recordNavigation Tag

Use this tag to record a navigation item into the recommendation engine session. This is to record that a user demonstrated an interest in the item by navigating to it. For example, he or she may see an icon that represents something of interest, then click a Tell Me More button next to the icon. See "Personalization removeNavigationRecord Tag" for information about the tag to remove a navigation item.

You can disable actions of the recordNavigation tag by setting the disableRecording attribute of the startRESession tag to "true". See "Personalization startRESession Tag" for more information.

<op:recordNavigation
          [ type = "type_of_item" ]
          [ ID = "item_ID_number" ] 
          [ itemList = "item_array_expression" ] 
          [ index = "index_into_item_array" ] />

Personalization recordPurchase Tag

Use this tag to record a purchasing item into the recommendation engine session. This is to record a purchase the user has made. See "Personalization removePurchaseRecord Tag" for information about the tag to remove a purchasing item.

You can disable actions of the recordPurchase tag by setting the disableRecording attribute of the startRESession tag to "true". See "Personalization startRESession Tag" for more information.

<op:recordPurchase
          [ type = "type_of_item" ]
          [ ID = "item_ID_number" ] 
          [ itemList = "item_array_expression" ] 
          [ index = "index_into_item_array" ] />

<%@ page session="true" %>
<op:getRecommendations storeResultsIn "myRecs" />
...display recommendations...
<% session.setAttribute("recommendationList", myRecs); %>

<%@ page session="true" %>
<op:recordPurchase itemList="<%=session.getAttribute(\"recommendationList\") %>"
                   index="<%=request.getParameter(\"index\" %>" />

Personalization recordRating Tag

Use this tag to record a rating item into the recommendation engine session. This would be based on a user rating of the item. See "Personalization removeRatingRecord Tag" for information about the tag to remove a rating item.

This tag differs from recordNavigation and recordPurchase in that a rating value must also be specified.

<op:recordRating value = "rating_value"
          [ type = "type_of_item" ]
          [ ID = "item_ID_number" ] 
          [ itemList = "item_array_expression" ] 
          [ index = "index_into_item_array" ] />

Personalization recordDemographic Tag

Use this tag to record a demographic item into the recommendation engine session. A demographic item consists of a piece of personal information about a particular user. See "Personalization removeDemographicRecord Tag" for information about the tag to remove a demographic item.

This tag differs from the other recordXXX tags in that it has only two attributes: type and value. The type attribute indicates what kind of information the item contains, such as "AGE". The value attribute contains the corresponding value, such as "44".

<op:recordDemographic 
        type = "GENDER"|"AGE"|"MARITAL_STATUS"|"PERSONAL_INCOME"|
               "HOUSEHOLD_INCOME"|"IS_HEAD_OF_HOUSEHOLD"|"HOUSEHOLD_SIZE"|
               "RENT_OWN_INDICATOR"|"ATTRIBUTE1"|...|"ATTRIBUTE50"
        value = "item_value" />

Personalization removeNavigationRecord Tag

Use this tag to remove a navigation item that had been recorded into the recommendation engine session earlier in the session. See "Personalization recordNavigation Tag" for information about the tag to record a navigation item.

To remove an item, you must use the removeNavigationRecord tag during the same recommendation engine session in which the item was recorded. The session cache is periodically flushed to the recommendation engine database schema during the course of a session. If you remove an item after it has been flushed, execution of the removal tag will require a database round-trip.

<op:removeNavigationRecord
          [ type = "type_of_item" ]
          [ ID = "item_ID_number" ] 
          [ itemList = "item_array_expression" ] 
          [ index = "index_into_item_array" ] />

Personalization removePurchaseRecord Tag

Use this tag to remove a purchasing item that had been recorded into the recommendation engine session earlier in the session. See "Personalization recordPurchase Tag" for information about the tag to record a purchasing item.

To remove an item, you must use the removePurchaseRecord tag during the same recommendation engine session in which the item was recorded. The session cache is periodically flushed to the recommendation engine database schema during the course of a session. If you remove an item after it has been flushed, execution of the removal tag will require a database round-trip.

<op:removePurchaseRecord
          [ type = "type_of_item" ]
          [ ID = "item_ID_number" ] 
          [ itemList = "item_array_expression" ] 
          [ index = "index_into_item_array" ] />

Personalization removeRatingRecord Tag

Use this tag to remove a rating item that had been recorded into the recommendation engine session earlier in the session. See "Personalization recordRating Tag" for information about the tag to record a rating item.

This tag differs from removeNavigationRecord and removePurchaseRecord in that a rating value must also be specified.

To remove an item, you must use the removeRatingRecord tag during the same recommendation engine session in which the item was recorded. The session cache is periodically flushed to the recommendation engine database schema during the course of a session. If you remove an item after it has been flushed, execution of the removal tag will require a database round-trip.

<op:removeRatingRecord value = "rating_value"
          [ type = "type_of_item" ]
          [ ID = "item_ID_number" ] 
          [ itemList = "item_array_expression" ] 
          [ index = "index_into_item_array" ] />

Personalization removeDemographicRecord Tag

Use this tag to remove a demographic item that had been recorded into the recommendation engine session earlier in the session. See "Personalization recordDemographic Tag" for information about the tag to record a demographic item.

This tag differs from the other removeXXXRecord tags in that it has only two attributes: type and value. The type attribute indicates what kind of information the item contains, such as "AGE". The value attribute contains the corresponding value, such as "44".

To remove an item, you must use the removeDemographicRecord tag during the same recommendation engine session in which the item was recorded. The session cache is periodically flushed to the recommendation engine database schema during the course of a session. If you remove an item after it has been flushed, execution of the removal tag will require a database round-trip.

<op:removeDemographicRecord 
        type = "GENDER"|"AGE"|"MARITAL_STATUS"|"PERSONAL_INCOME"|
               "HOUSEHOLD_INCOME"|"IS_HEAD_OF_HOUSEHOLD"|"HOUSEHOLD_SIZE"|
               "RENT_OWN_INDICATOR"|"ATTRIBUTE1"|...|"ATTRIBUTE50"
        value = "item_value" />

RecommendationSettings Element

Use this element to set a default value for maxQuantity, the maximum number of recommendations that can be returned, for the getRecommendations, getCrossSellRecommendations, and selectFromHotPicks tags.

The maxQuantity setting must be a string representing a positive integer.

<!ELEMENT RecommendationSettings EMPTY>
    <!ATTLIST RecommendationSetting  maxQuantity  CDATA #REQUIRED>

RE Element

Use this element to specify the name of a recommendation engine connection and to make the connection. See "Personalization startRESession Tag" for information about the attributes.

<!ELEMENT RE EMPTY>
   <!ATTLIST RE Name CDATA #REQUIRED>
   <!ATTLIST RE URL CDATA #REQUIRED>
   <!ATTLIST RE Schema CDATA #REQUIRED>
   <!ATTLIST RE Password CDATA #REQUIRED>
   <!ATTLIST RE CacheSize CDATA #REQUIRED>
   <!ATTLIST RE FlushInterval CDATA #REQUIRED>

Password="->scott"

Tuning Element

Use this element to define named tuning settings. See "Tuning Settings" for information about the attributes.

<!ELEMENT Tuning EMPTY>
   <!ATTLIST Tuning Name CDATA #REQUIRED>
   <!ATTLIST Tuning  DataSource 
             (NAVIGATION|PURCHASING|RATING|DEMOGRAPHIC|ALL) "ALL" >
   <!ATTLIST Tuning InterestDimension (NAVIGATION|PURCHASING|RATING)
             #REQUIRED >
   <!ATTLIST Tuning PersonalizationIndex (LOW|MEDIUM|HIGH) #REQUIRED >
   <!ATTLIST Tuning  ProfileDataBalance (HISTORY|CURRENT|BALANCED)
             #REQUIRED >
   <!ATTLIST Tuning ProfileUsage (INCLUDE|EXCLUDE) "INCLUDE" >

DefaultTuning Element

Use this element for tuning settings if there are no individual tuning tag attributes and no tuningName tag attribute (with corresponding <Tuning> element in personalization.xml).

Attribute meanings are the same as for the <Tuning> element discussed immediately above.

<!ELEMENT DefaultTuning EMPTY>
   <!ATTLIST DefaultTuning  DataSource 
             (NAVIGATION|PURCHASING|RATING|DEMOGRAPHIC|ALL) "ALL" >
   <!ATTLIST DefaultTuning InterestDimension (NAVIGATION|PURCHASING|RATING)
             #REQUIRED >
   <!ATTLIST DefaultTuning PersonalizationIndex (LOW|MEDIUM|HIGH)
             #REQUIRED >
   <!ATTLIST DefaultTuning ProfileDataBalance (HISTORY|CURRENT|BALANCED)
             #REQUIRED >
   <ATTLIST! DefaultTuning ProfileUsage (INCLUDE|EXCLUDE) "INCLUDE" >

Filtering Element and Category Elements

Use these elements to define named filtering settings. See "Recommendation Filtering" for information about the attributes.

Use the filtering Name attribute to provide a unique name to be referenced from personalization tags.

One or more <Category> elements must be nested within a filtering subelement, except for the AllItems and AllCategories subelements. Contents of a <Category> element must be a string representing a long integer.

<!ELEMENT Filtering   (ExcludeItems|IncludeItems|ExcludeCategories|
                       IncludeCategories|CategoryLevel|SubTreeItems|
                       SubTreeCategories|AllItems|AllCategories) >
   <!ATTLIST Filtering Name CDATA #REQUIRED>
   <!ATTLIST Filtering TaxonomyID CDATA #REQUIRED>

<!ELEMENT Category (#PCDATA) >
<!ELEMENT ExcludeItems ( Category+ ) >
<!ELEMENT IncludeItems ( Category+ ) >
<!ELEMENT ExcludeCategories ( Category+ ) >
<!ELEMENT IncludeCategories ( Category+ ) >
<!ELEMENT CategoryLevel ( Category+ ) >
<!ELEMENT SubTreeItems ( Category+ ) >
<!ELEMENT SubTreeCategories ( Category+ ) >
<!ELEMENT AllItems EMPTY >
<!ELEMENT AllCategories EMPTY >

DefaultFiltering Element

Use this element for filtering settings if there are no individual filtering tag attributes and no filteringName tag attribute (with corresponding <Filtering> element in personalization.xml).

<!ELEMENT DefaultFiltering (ExcludeItems|IncludeItems|ExcludeCategories|
                            IncludeCategories|CategoryLevel|SubTreeItems
                            SubTreeCategories|AllItems|AllCategories) >
   <!ATTLIST DefaultFiltering TaxonomyID CDATA #REQUIRED>

<!ELEMENT Category (#PCDATA) >
<!ELEMENT ExcludeItems ( Category+ ) >
<!ELEMENT IncludeItems ( Category+ ) >
<!ELEMENT ExcludeCategories ( Category+ ) >
<!ELEMENT IncludeCategories ( Category+ ) >
<!ELEMENT CategoryLevel ( Category+ ) >
<!ELEMENT SubTreeItems ( Category+ ) >
<!ELEMENT SubTreeCategories ( Category+ ) >
<!ELEMENT AllItems EMPTY >
<!ELEMENT AllCategories EMPTY >