11.3 Other Standardization Efforts by the IETF and W3C

In addition to the tools and descriptions specified in MPEG-21, other standardization bodies have also conducted work towards the support of context-aware applications and the assistance of adaptation operations. Such standardization organizations include the W3C and the Internet Engineering Task Force (IETF), both of which have delivered related specifications for a few recent years.

Content adaptation at the network edges is already being performed by content distributed mediators in order to balance the network load or in an attempt to satisfy different user groups' profiles and redirect requests based on geography and/or other profile characteristics. This is being achieved through the use of content distribution networks (CDNs), peer-to-peer (P2P) technologies, and personalization techniques [34].

In the mobile networking world, content filtering services are being added to most caches. Wireless network proxies transform both protocol and Web content, converting HyperText Markup Language (HTML) into Website Meta Language (WML) for small-screen displays and HyperText Transfer Protocol (HTTP) into Wireless Datagram Protocol (WDP) for wireless delivery purposes. Adaptation of content, aiming at increased penetration, is already happening, in particular in the mobile world. However, it still offers somewhat limited functionality, as it essentially accounts for bandwidth restrictions and limited device capabilities. The focus is still on the adaptation of the layout of the service rather than on the content itself. The same is happening in the TV broadcasting world, aimed at the adaptation of interactive applications and Web-based content to multiple non-interoperable platforms.

The IETF has produced the Internet Content Adaptation Protocol (iCAP) specification, which is basically an HTTP-based remote procedure call protocol that allows clients to send HTTP messages to instruct iCAP servers, or generic Web servers to perform some kind of operation on the content. iCAP servers are dedicated to performing specific tasks, and thus are expected to perform such tasks better or more efficiently than the generic Web servers. The targeted adaptation operations were defined from a business perspective, and are seen as value-added services to the client. Examples of the envisaged adaptation operations are virus scanning, advertisement insertion, and also some forms of content translation or filtering.

The Mobile Alliance Forum has standardized the User Agent Profile (UAProf) specification [45], which provides an open vocabulary for Wireless Access Protocol (WAP) clients to communicate their capabilities to the servers. It defines the data structure to describe client devices and to transport that information to the servers. This information may include hardware characteristics, such as screen size or type of keyboard; software characteristics, such as browser manufacturer; and also user preferences (e.g. sound enabled, color choices, etc.). The idea is to empower the service provider with information that may assist them in customizing the service to the end-user needs to a certain extent. The UAProf vocabulary has six components:

  • HardwarePlatform: Characteristics of the hardware of the terminal, including the type of device, model, display size, and memory.
  • SoftwarePlatform: Characteristics of the operating environment of the device.
  • NetworkCharacteristics: Information about the network infrastructure, such as bearer information.
  • BrowserUA: Identification of the browser application available on the device.
  • WapCharacteristicslists: The WAP capabilities of the terminal.
  • PushCharacteristics: Push specifications of the device, such as maximum size of a push message.

The Resource Description Framework (RDF) [46] and OWL [5] are specifications of the W3C that constitute the general description frameworks suitable for expressing the context.

RDF is a generic specification for representing metadata, in particular metadata related to resources on the Web,1 being strongly associated with the Semantic Web or Web 2.0 concepts. RDF can be represented in one of three different formats, as follows:

  1. XML syntax, which is the format commonly used to exchange RDF data between machines.
  2. Triple representation, consisting of sets of (Subject, Predicate, Object) values.
  3. Graph representation.

Figure 11.13 provides examples of the same metadata represented in RDF in each of its three possible formats. In this figure, the metadata is a simple sentence written in English, which is then represented using RDF in: i) its triplet format; ii) the XML format; and finally iii) the graph format.

The W3C has also delivered the CC/PP specification [47], which defines an RDF-based framework for describing device capabilities and user preferences. It provides the means to specify client capabilities (i.e. the “user agent” information) and user preferences using uniform resource identifiers (URIs) and RDF text sent in HTTP requests. The user agent specifies the preferences of the user in the header of the client HTTP request, such as versions of content or languages, and is empowered with negotiation capabilities.

images

Figure 11.13 The three different formats for RDF representation

Although the CC/PP specification was originally developed to be used mainly on wireless devices, it can be applied to any Web-enabled terminal. It uses RDF in its XML serialized format to exchange profiles between devices with information on the user agent's capabilities and the user's preferences. A CC/PP profile can be seen as a two-level tree containing components and attributes of those components. Components can be the hardware or the software platforms of the terminal, or any specific application running on top of those platforms. Different components may appear in one CC/PP profile. A reference to the schema that indicates the types of component that appear in that profile as well as the rules concerning the attributes of those components is included in the profile, so that the recipient may correctly interpret and use the information contained. Since the CC/PP specification uses RDF, its profiles are composed of sets of (Subject, Predicate, Object). The components (the Subject) have named attributes (the Predicate) and values for those attributes (the Object). The most common components in CC/PP refer to the hardware and software platforms of the terminal device, and thus are related to the capabilities of the terminal. However, there are other types of component that can be described in a CC/PP profile, such as the location.

CC/PP uses a vocabulary to define the format and language for specifying the names and values of components as well as their attributes. However, different CC/PP profiles or applications may use different vocabularies. This is a particular feature of CC/PP that allows different applications to define and use particular vocabularies that suit their particular needs. One of the vocabularies that has been traditionally used in CC/PP profiles is the UAProf in the mobile world. For other application areas, and in general terms, the W3C recommends the use of RDF to define vocabularies. In Figure 11.14, an example of a CC/PP is illustrated for a hypothetical personal digital assistant (PDA).

The W3C is quite active in the field of context-aware applications, and as such is contributing to the enabling of content adaptation. Many of the current specifications and approaches being studied or developed towards the implementation of content adaptation operations rely on the use of W3C technologies. Butler provides in [48] a survey of technologies that can be used to enable devices to communicate their capabilities to the providers of services, enabling them to customize content for use. This work is focused on the use of W3C and Mobile Alliance technologies for use in mobile environments. The work also concentrates on designing a system that enables mobile clients to negotiate the format of the content delivered to them through the use of the CC/PP and UAProf specifications [49]. Furthermore, Gilbert and Butler [50] defined a data model to allow the use of profiles with multiple vocabularies when using the CC/PP specification to allow mobile devices to communicate their capabilities to servers.

In spite of its wide applicability, the CC/PP model presents some limitations when addressing more complex context-aware scenarios. Although in principle any kind of contextual information could be described using CC/PP as long as that context information could be described using RDF, it does not provide the mechanisms to carry additional information, such as temporal information or resolution of the contextual information. However, the most important limitations may come from the fact that CC/PP components and attributes (or subtypes of them) have a limited set of values and a restricted syntax. For example, CC/PP does not provide any support for expressing relationships or constraints. It also has some limitations regarding the type of information.

images

Figure 11.14 Example of a CC/PP

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset