How tagging and rating works in the portal

How tagging and rating works 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 ratings that the current user has applied.

Personal tags 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 Public tags that have been applied to a resource. Public tags 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. For more information see Security for tagging and rating.

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. For more information see Security for tagging and rating.

Public tags are also community tags.

Tagging and rating 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 effecto 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 URL 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. We 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 clouthat shows all tags associated with the action books as previously mentioned, we 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 category promotion

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, to aggregate a tag clouthat shows all tags for promotion articles, we could aggregate tags for resources that have been associated with the category promotion, in the previous example 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 worthat 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 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 to provide as suggestions for the type-ahead feature.
For example, we might want to configure normalization in a was 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 we might want to configure the system in a was that if the user starts to enter Küs or Kus is equally provided with the suggestions Küste and Kuste.
We 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 using the following parameters in the portal CP Configuration Service resource environment provider in the WAS admin console:

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

normalization.typeAhead = (normalized)

This parameter defines the tag names that the type ahead for tag creation mechanism displays to the user. Valid values are normalized and unnormalized.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 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 correct 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 separately in a tag cloud. 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

We 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 admin console under the Resource Environment Provider > CPConfigService. For details see Portal configuration services and CP Configuration Service for tagging and rating.

Blacklist filter

The blacklist filter allows us to block selected terms from being used as tags, for example termthat 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. We can determine the termto be on the blacklist using xmlaccess.sh.
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 us 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. We can set the termto be on the whitelist using xmlaccess.sh.
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.

Configure both filter lists using xmlaccess.sh. 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 xmlaccess.sh are located under the directory PORTAL_HOME/doc/xml-samples .
Example: Creating new words to the blacklist filter:
<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd"
    type="update" create-oids="true">
    
    <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. We 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 delete individual words:
<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd"
    type="update" create-oids="true">
    
    <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_8.0.0.xsd"
    type="update" create-oids="true">
    
    <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
Related:
Search for tagged content
Federating tags
Search for tagged content
Related:
Set service configuration properties
Related reference:
The tagging and rating user interface
Tagging and rating for static pages
Allow our own custom content to be tagged and rated
Configuration reference
Security for tagging and rating
Use xmlaccess.sh to administer tags and ratings
Administration of tag federation
Tips for tagging and rating
CP Configuration Service for tagging and rating
Configure the tag cloud
Security for tagging and rating

Personal tags	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	Public tags that have been applied to a resource. Public tags 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.