With the growth of the web, the amount and the nature of information available on the web encompasses many different cultures and lifestyles. One frequent requirement from web users has been to be able to select resources based on content. One approach to this problem is the Platform for Internet Content Selection (PICS) as described by Resnick and Miller []. The basic idea is to create a platform for the definition of labels attached to resources.
Each label describes a rating of a resource based on a particular rating service. It is important to notice that PICS itself does not define any labels or rating services, it only defines a standard format for the exchange of information based on the model of labels and rating services. The most common uses of PICS labels is in filtering products that block access to certain resources based on labels associated with those resources. The following components are important in the PICS architecture:
Clients using PICS can be configured to handle resources based on the PICS labels associated with them. A common use is to inhibit the display of particular web pages based on labels from rating services.
A server supporting PICS understands requests containing the PICS-specific Protocol-Request header field and generates responses containing the labels associated with a resource, using the PICS-specific Protocol and PICS-Label header fields.
A proxy can perform filtering based on PICS labels. The most common scenario involves a proxy used as a firewall between an intranet and the Internet and filtering out responses based on labels from particular rating services.
PICS defines three different ways of label distribution. A label can be embedded in a document, can be transmitted together with a document using PICS-specific HTTP extensions, or it can be separately requested (using a special protocol) from a different server (called label bureau) than the resource itself. PICS label distribution mechanisms are described in detail in section 10.5.1.2.
A rating service is an organization creating PICS labels based on a particular rating system. These labels may be distributed together with the resource, or they can be made available through a label bureau.
PICS defines the components of the architecture in three specifications. In the PICS Rating Services and Rating Systems, described in section 10.5.1.1, a language for the description of rating services is defined. Section 10.5.1.2 explains PICS Label Syntax and Communication Protocols, effectively describing how labels based on rating services are specified, and how these labels are distributed. Finally, in section 10.5.1.3 PICSRules are described, a language for writing profiles, being filtering rules that allow or block access to URLs based on PICS labels that describe those URLs.
W3C's PICS Rating Services and Rating Systems [] recommendation describes a language for the description of rating services. A rating service is described by some administrative information and as the most important information the rating system. A rating system specifies the dimensions used for labeling, the scale of allowable values on each dimension, and a description of the criteria used in assigning values.
The W3C recommendation specifying PICS Label Syntax and Communication Protocols [] describes how labels according to a given rating system have to be coded for distribution. The most important part of a PICS label is the rating. The rating is a set of attribute-value pairs that describe a document along one or more dimensions.
Once a rating service creates a label for a document, the label has to be made available to clients interested in the rating. PICS defines three different ways of label distribution.
The easiest way to distribute PICS labels is to embed them into HTML documents. With this method no protocol mechanisms are necessary for label distribution. Labels are embedded in HTML documents using the META element. The HTTP-EQUIV attribute is used to designate the META element as specifying a PICS label, and the element's CONTENT attribute contains one or more PICS labels.
If a label is not embedded in the document, but stored on the same server, it can be transferred with the documents. PICS defines HTTP extensions which have to be used by clients being interested in PICS labels. The following additional information is exchanged when a client requests PICS labels:
A client that is interested to receive PICS labels of resources uses the Protocol-Request header field. The content of this header field specifies the PICS version being used, and the services for which PICS labels are requested.
A server supporting PICS sends back the resource along with the associated PICS information. The Protocol header field specified the PICS version, and the PICS-Label header field contains all labels associated with the resource.
PICS labels are distributed selectively, a client requests labels for particular rating services, and the server only replies with the labels for these services. If many and potentially large labels are associated with documents, this is a significant advantage over embedded labels.
It is possible to requests labels independently from the resource. In this case, a client sends a request for a resource's label to a label bureau. The label bureau responds with the PICS labels associated with the response. The PICS label bureau query protocol is used for label requests to label bureaus. This protocol defines a particular query syntax for HTTP requests, so basically a label bureau is a specialized HTTP server for this query syntax.
The rules interpreting PICS labels are entirely local to clients. A client receives a PICS label and decides the effect that this particular label should have, based on local rules. Although these rules can be specified in a product-specific way, W3C has defined a language for them. This language is PICSRules []. PICSRules has the following advantages over proprietary approaches:
The creation of profiles (a certain set of rules) can be complicated, and by using a common language, a profile can be created and installed on a large number of machines.
It is possible to transmit a profile to a server and to have only resources returned from the server matching the profile. For example, a search engine could use a PICSRules profile (among other things, such as search strings) as a search criterion, only returning matches that also satisfy the PICSRules profile.
By defining a common language for specifying filtering rules, the same set of rules will work with any product supporting PICSRules.
A PICSRules rule can specify one or more PICS rating services to use, one or more PICS label bureaus to query for labels, and criteria about the contents of labels that would be sufficient to make an accept or reject decision.