How tagging and rating works in the portal

Use this topic for administrative information about tagging and rating in the portal.

Community and personal tags and ratings

Tags can be considered to be personal tags or community tags. All statements made for tags in the following also apply to ratings. Community tags and ratings are those that other users have applied. By definition these tags are also public, otherwise they would not be visible to other users. Personal tags and ratings are those public tags and ratings that the current user has applied. Private tags and ratings are those private tags and rating that the current user has applied.

• Personal tags - Personal tags are tags applied by a specific user. When a user tags a resource, the user applies the tag to the resource as a personal tag. Public tags can be seen by everyone who belongs to the community. Private tags can only be seen by the user who created the tag.

• Community tags - Community tags are the collection of public tags that have been applied to the resource. Public tabs become community tags when they are shown to users. Community tags are always public. Community tags can be seen by all users who belong to the community, not only by the user who created the tag.

Public and private tags and ratings

Users can choose between applying a tag or rating as a private or public tag or rating. The differences between private and public tags and ratings are described in the following. All statements made for tags in the following are also applicable to ratings.
Private tags

• A private tag can be seen only by the user who applied it

• A user can apply the same private tag only once to one specific resource.

• A user can apply the same private tag to multiple resources. This means that an individual user can use the same tag more than once, but only once per resource.

• Users can only delete private tags that they have applied themselves. (Users with a Manager role have more rights.)

Public tags

• All public tags and ratings are visible to all users who belong to the community and who have access to the resource itself, independent of who created the tag or rating.

• A user can apply the same public tag only once to one specific resource.

• A user can apply the same public tag to multiple resources. This means that an individual user can use the same tag more than once, but only once per resource.

• The same public tag can be applied to the same specific resource by multiple users. In other words, all users can apply the same tag or rating to a resource once; as a result, the resource can have the same tag applied to it multiple times.

• Users can only delete public tags that they have applied themselves. (Users with a Manager role have more rights.)

• Public tags are also community tags.

Tag and rate with anonymous users

Anonymous users of the portal can tag and rate portal content, if an administrator adds the anonymous user to the appropriate roles on the virtual resources as described in the topic about Security for tagging and rating.

As the portal cannot distinguish one anonymous user from another, there are some side effects that need to be understood:

For tagging, the same user can normally not apply the same tag to the same resource more than once and an anonymous user can apply the same tag more than once.

For rating, the same user can normally rate a single resource only once and an anonymous user can rate the same resource more than once. Anonymous users cannot view their personal tags, and they cannot delete tags or ratings.

Grouping tags and ratings via resource categorization

Users apply tags and ratings to resources. This can be all resources that can be uniquely identified, for example:

• A URI that consists of a type schema and an SSP (scheme specific part), such as an article bar code: item:item_bar_code_number

• The ISBN number for a book: book:isbn_number.

These resources must be registered with the tagging and rating engine. The portal performs this registration whenever an existing resource is tagged or rated. To categorize tags and ratings, administrators can group resources. You can group resources by URI or by category specification:
Resource categorization per URI

When the portal registers resources, it assigns them a URI. The URI consists of a type schema and a scheme specific part (SSP). For example, users could register media as follows:

• some books under content/books/action:/isbn, where content/books/action is the type schema and isbn is the SSP

• some other books under content/books/thriller:/isbn

• some DVDs under content/dvds/action:/some_ID

• some other DVDs under content/dvds/romance:/some_ID

Categorization of resources becomes important when tags or ratings are aggregated. For example, tags are aggregated in tag clouds. For details refer to the topic about Configuring the tag cloud. For example if a user wants to aggregate a tag cloud that shows all tags that are associated with the action books mentioned above, you could aggregate tags for resources that have been registered under the type schema content/books/action. For details about how to scope tag clouds for certain type schemas refer to the topic about Configuring the tag cloud.

Resource categorization per category specification

When resources are registered, they can be explicitly associated with one or more categories. A category is represented by a non-localized unique string based identifier. For example, users could register media as follows:

• some books under content/books/action:/isbn and the isbn is SSP

• some other books under content/books/thriller:/isbn and the category bestseller

• some DVDs under content/dvds/action:/some_ID and the category promotion

• some other DVDs under content/dvds/romance:/some_ID and the category bestseller

For example, if you want to aggregate a tag cloud that shows all tags for promotion articles, you could aggregate tags for resources that have been associated with the category promotion, in the example above action books and action DVDs. For details about how to scope tag clouds for certain type schemas refer to the topic about Configuring the tag cloud.

Normalization and localization

The portal provides several options for normalizing tags. Normalization is a process of transforming a text fragment, such as a tag, into another, more generic representation. This bundles different spellings or grammatical versions of the same lexical word that users might use as tags, for example color, Color, COLOR, colour, colors, colored.

The standard normalization algorithm provided by the portal removes all diacritical marks from all letters of words. This documentation refers to the diacritic free morphological variation of a word as the normalized form of the word.

This is important when considering which tags you want to be aggregated together when they are displayed as part of a tag widget, or, even more important, part of a tag cloud. It is also important when considering which tags you want to provide as suggestions for the type-ahead feature. For example, you might want to configure normalization in a way that diacritical marks such as French accents or German Umlaute are ignored so that the portal regards the French words côte and cote as well as the German words Küste and Kuste as equivalent. In that case the tags côte and cote (or Küste and Kuste) would not appear separately in a tag cloud; instead they would be grouped together as one tag which would appear as cote or Kuste respectively as these are the normalizes forms. For type-ahead you might want to configure the system in a way that if the user starts to enter Küs or Kus is equally provided with the suggestions Küste and Kuste.

You can control the normalization behavior by various configuration parameters. To configure normalization behavior, go to Resources -> Resource Environment -> Resource Environment -> Providers -> WP CPConfigurationService -> Custom Properties. You configure normalization by using the following parameters in the CP Config Service resource environment provider in the WAS administrative console:

You configure normalization by using the following parameters:
normalization.displayNormalizedName = (false)

This parameter defines whether the normalized tag names are displayed (exposed) in the tag cloud. The default value for this parameter is false.

com.ibm.wps.cp.tagging.normalization.displayNormalizedNames = false#@PUBLIC

normalization.typeAhead = (normalized)

This parameter defines the tag names that the type ahead for tag creation mechanism displays to the user. The default value for this parameter is normalized.

Type-ahead feature for tagging

A type-ahead feature supports users when they work with tags, for example when they apply tags using the tag widget, or when they search for tags, for example by using the open search functionality. For details about this refer to the topic about Searching for tagged content. The type-ahead feature makes it easier for users to find suitable tags. As the user starts typing tag text, one or more possible matches for that text fragment are found and immediately shown to the user. This immediate feedback allows users to select one of the listed options rather having to type the entire word or phrase they were looking for. User can also choose a closely related option from the presented list. Thus, the type-ahead feature allows users to explore the tag space as they type. This can make it easier to find the right term they want to use as the tag.

Another advantage of the type-ahead feature is that it reduces tag space littering; different users use different spellings for certain terms. An example is the term Web 2.0. Users might spell it as Web 2.0, Web2.0, Web 20, Web20, or Web2. Semantically all these morphological variations refer to the same term. Therefore it would be inconvenient to present all these variations in separate tag clouds. If most users have already entered the term as Web 2.0 and new users want to tag something with a variation of this term and start typing, the type-ahead feature would suggest Web 2.0, and most users would probably select this term form the list. This reduces the amount of variation.

The type-ahead feature starts suggesting tags after a users types the third character in a type-ahead enabled input field, for example in the tag widget.

Filtering content for tagging

You can use filtering mechanisms to control which terms can be used as tags and which cannot be used. The portal provides a blacklist and a white list filter. You enable and disable both filters in the WAS administrative console under the Resource Environment Provider -> CPConfigurationService. For details refer to the topics about Portal configuration services and Setting service configuration properties.
Blacklist filter

The blacklist filter allows you to block selected terms from being used as tags, for example for example terms that could be perceived as offensive. If you enable the blacklist filter, the portal checks every term that users type as a tag before it is eventually applied and stored. If a user types a term listed on the blacklist, the portal blocks this tag and responds with a message. You can determine the terms that you want to be on the blacklist by using the XML configuration interface.

To enable the blacklist filter, the following configuration property in the CP Configuration Service to true:

com.ibm.wps.cp.filter.tagging.blacklist = true

Whitelist filter

The white filter allows you to limit the set of tags that users can apply If you enable the whitelist filter, the portal checks every term that users type as a tag before it is eventually applied and stored. If a user types a term that is not listed on the whitelist, the portal blocks this tag and responds with a message. You can set the terms that you want to be on the whitelist by using the XML configuration interface.

To enable the whitelist filter, add at least one entry to the whitelist filter database and set the following configuration property in the CP Configuration Service to true:

com.ibm.wps.cp.filter.tagging.whitelist = true

The portal applies the filter only if you activate it and add at least one entry to the whitelist filter database.

You can configure both filter lists by using the XML configuration interface. The following examples show how to add or remove terms to the blacklist. To work with the whitelist, adapt the examples by changing the ID of the filter from DefaultBlacklistFilter to DefaultWhitelist Filter . Sample scripts for the XML configuration interface are located under the directory $PORTAL_HOME/doc/xml-samples .
Example: Create new words to the blacklist filter:

<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
    type="update" create-oids="true">
    <!-- sample for creating a filter with some sample entries -->
    <portal action="locate">
        <filter-instance action="update" id="DefaultBlacklistFilter">
            <filter-data value="badword_1" action="update"/>
            <filter-data value="badword_2" action="update"/>        
        </filter-instance>
    </portal>
</request>

This sample snippet registers the two words badword_1 and badword_2 with the blacklist filter for all locales. Note that specify DefaultBlacklistFilter for the attribute id of the tag filter. You can optionally specify the attribute locale for the tag filter data. After you run this XML script, users will not be able to use badword_1 or badword_2 as tags.
Example: Create or deleting individual words:

<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
    type="update" create-oids="true">
    <!-- sample for creating a filter with some sample entries -->
    <portal action="locate">
        <filter-instance action="update" id="DefaultBlacklistFilter">
            <filter-data value="badword_1" update="delete"/>
            <filter-data value="badword_3" update="update"/>
        </filter-instance
    </portal>
</request>

This sample snippet removes the term badword_1 and adds badword_3 from the blacklist.
Example: Deleting all terms from the blacklist filter:

<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
    type="update" create-oids="true">
    <!-- sample for creating a filter with some sample entries -->
    <portal action="locate">
        <filter-instance action="delete" id="DefaultBlacklistFilter">
        </filter-instance>
    </portal>
</request>

This sample snippet deletes all terms from the blacklist.

Parent

Tagging and rating
Search for tagged content

Related tasks

Set service configuration properties
The tagging and rating user interface
Tag and rate for static pages
Allow own custom content to be tagged and rated
Configuration reference
Security for tagging and rating
Use the XML configuration interface to administer tags and ratings
Hints and tips for tagging and rating
CP Configuration Service for tagging and rating
Configure the tag cloud

  Removed hint to section edit Shared Settings no defect #. Add topic references Under T&R for anonymous users added link to Security for T&R. Submitted by Carl D on Nov 17, 2010 11:03:48 AM

How tagging and rating works in the portal: wp7

I'm reading many '...' in this article, looks like it is incomplete. Those completed references would be very valuable.

+

Search Tips   |   Advanced Search