Preference Profiles For Content Adaptation

  • November 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Preference Profiles For Content Adaptation as PDF for free.

More details

  • Words: 1,732
  • Pages: 10
Composite Capabilities/Preference Profiles for Content Adaptation

Dr. W.U.Khan

Kalyan Bemalkhedkar

Computer Engineering Department Shri G.S.Institute of Technology and Science Indore

Abstract A CC/PP profile is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device. The Resource Description Framework (RDF) is used to create profiles that describe user agent and proxy capabilities and preferences. The structure of a profile in CC/PP includes structure of client capability and preference descriptions, structure of proxy behavior description, as this modifies the set of capabilities and preferences to which an origin server may respond and use of RDF classes to distinguish different elements of a profile, so that a schema-aware RDF processor can handle CC/PP profiles embedded in other xml document types. CC/PP vocabulary is identifiers (URIs) used to refer to specific

capabilities and preferences, including the types of values to which CC/PP attributes may refer, a description of how to introduce new vocabularies, a small client vocabulary covering print and display capabilities, and a survey of existing work from which new vocabularies may be derived. This paper attempts to study and analyze CC/PP (Composite Capabilities/Preference Profiles) structure and vocabularies. 1. Introduction A CC/PP profile is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device. As the number and variety of devices connected to the Internet grows, there is a corresponding increase in the need to deliver content that is tailored to the capabilities of different devices. Some limited techniques, such as HTTP 'accept' headers and HTML tags, already exist. As part of a framework for content adaptation and contextualization, a general purpose profile format is required that can describe the capabilities of a user agent and preferences of its user. CC/PP is designed to be such a format. CC/PP is based on RDF, the Resource Description Framework, which was designed by the W3C as a general purpose metadata description language. RDF provides the framework with the basic tools for both vocabulary extensibility, via XML namespaces, and interoperability. There is a specification that describes how to encode RDF using XML, and another that defines an RDF schema description language using RDF. RDF was designed to describe the metadata or machine understandable properties of the Web. RDF is a natural choice for the CC/PP framework since user agent profiles are metadata

intended primarily for communication between user agents and resource data providers. A CC/PP profile contains a number of attribute names and associated values that are used by a server to determine the most appropriate form of a resource to deliver to a client. It is structured to allow a client and/or proxy to describe their capabilities by reference to a standard profile, accessible to an origin server or other sender of resource data, and a smaller set of features that are in addition to or different than the standard profile. A set of CC/PP attribute names, permissible values and associated meanings constitute a CC/PP vocabulary. It is anticipated that different applications will use different vocabularies; indeed this is needed if application-specific properties are to be represented within the CC/PP framework. 2. CC/PP architecture The architecture of the CC/PP is concerned with components and attributes. This has been explained as follows. 2.1 CC/PP profile structure A CC/PP profile is broadly constructed as a 2-level hierarchy: • a profile having a number of components, and • each component having a number of attributes. 2.1.1 Profile components

The initial branches of the CC/PP profile tree describe major components of the client. Examples of major components are: • The hardware platform upon which software is executing, • The software platform upon which all applications are hosted, or • An individual application, such as a browser. Figure 1: Complete CC/PP profile example [MyProfile] | +--ccpp:component-->[TerminalHardware] | | | +--rdf:type---> [HardwarePlatform] | +--display----> "320x200" | +--ccpp:component-->[TerminalSoftware] | | | +--rdf:type---> [SoftwarePlatform] | +--name-------> "EPOC" | +--version----> "2.0" | +--vendor-----> "Symbian" | +--ccpp:component-->[TerminalBrowser] | +--rdf:type---> [BrowserUA] +--name-------> "Mozilla" +--version----> "5.0" +--vendor-----> "Symbian" +--htmlVersionsSupported--> [ ]

|

-------------------------

| +--rdf:type---> [rdf:Bag] +--rdf:_1-----> "3.0" +--rdf:_2-----> "4.0"

2.1.2 Component attributes A CC/PP profile describes client capabilities and preferences in terms of a number of "CC/PP attributes" for each component.The description of each component is a sub-tree whose branches are the capabilities or preferences associated with that component. Though RDF makes modeling a wide range of data structures possible, including arbitrary graphs, complex data models are usually best avoided for profile attribute values. A capability can often be described using a small number of CC/PP attributes, each having a simple, atomic value. Where more complex values are needed, these can be constructed as RDF subgraphs 2.1.3 Defaults The attributes of a component can be included directly, as in the previous case, or may be specified by reference to a default profile, which may be stored separately and accessed using its specified URI. This use of an externally defined default properties is somewhat similar to the idea of dynamic inheritance. It makes possible some important optimizations. As a separate document, it can reside at a separate location and it can be separately cached. This is particularly useful in wireless environments such as cellular

networks, where the profiles may be large and the client link slow and expensive. Using default values, only a small part of the overall profile is sent over the wireless network. 2.1.4 Proxies and content handling intermediaries It may be that an intervening network element, such as a transcoding proxy, has additional capabilities it wishes to advertise on the behalf of its clients. For instance, a transcoding proxy may be able to convert HTML to WML. The means to provision such a proxy (meaning to provide or not provide the service for some client) is beyond the scope of this work. But assuming such a proxy based capability is provided, CC/PP provides means for a proxy to describe its own capabilities as part of the CC/PP profile communicated to an origin server. 3. Proxy behavior The proxy vocabulary is not a mandatory part of the CC/PP specification, but is defined for use by CC/PP aware applications that may need to deal with proxies or other intermediaries that play an active role in content handling. Designers of CC/PP applications that need to deal with mediating behaviors should use this vocabulary rather than define new structures. A proxy is a component that sits on the network path between a content consumer and a content provider, and modifies or filters the content passed toward the consumer. This in turn affects what the provider may send to a given client, so the consumer's CC/PP information needs to be augmented with information corresponding to the proxy's behavior. (For typical web access, the origin server is the provider, and the client is the consumer.)This approach to describing proxy behaviors

does not force a proxy to analyze and rewrite a client profile. Rather, the applicability, proxyAllow and proxyBlock properties allow a proxy describe its behavior in a way that takes account of a client's capabilities. As a result, the structure is very easy for a proxy to create, though it does place some additional responsibility on an origin server to analyze and combine the various parts appropriately. 4. Capability chaining A proxy's role as a content modifying component between client and server is represented by chaining a description of the proxy's behavior to the profile supplied by the outbound client or proxy. For any given request containing a CC/PP profile, the proxy creates a new profile that refers to a CC/PP description of itself, and to the CC/PP capability in the request it received. This new profile is passed on towards the origin server. Figure 2: Graph for client and single proxy [] +--proxyProfile--> [] +--nextProfile---> []

5. Request processing in HTTP CC/PP is envisaged to be used with HTTP in the following fashion:

+------+ |Client| (Resource) | UA | data ) +------+

(5) (4) +-------+ +------+ <==response== | Proxy | <==response== |Origin| <====> ===request==> |

| ===request==> |server| (3)

(

(1)

| +-------+ (2) | +------+ | | v v (Client ) <--- (Client profile) <----- (Request profile) (defaults) + local values | v (Proxy ) <--- (Proxy profile) (defaults) + local values

Figure F-1: HTTP request processing

(i) The client sends an HTTP request, with an accompanying CC/PP client profile. The client profile may contain references to default profiles describing a range of common capabilities for the client concerned), and values that are variations from the default profile. (ii) The HTTP request may pass through a firewall/proxy that (a) imposes constraints on the kinds of content that can be accessed, or (b) can adapt other forms of content to the capabilities of the requesting client. This proxy extends the CC/PP profile with a description of these constraints and adaptations, and sends this with the HTTP request on to the origin server. The request may pass through several such proxies. (iii) The origin server receives the request and interprets the CC/PP profile. It selects and/or generates content that matches the combined proxy and client capabilities described in the profile. This is sent to last proxy in request chain in HTTP response.

(iv) If required, the proxy applies any content adaptations, and any other functions it is designed to perform. The resulting response and content is passed back toward the requesting client. The client receives the HTTP response and presents the content it contains. 6. Conclusion Content Adaptation is becoming very important aspect for development of web based applications. CC/PP provides a flexible and generic approach for content adaptation on the internet. The main advantage of CC/PP is that it provides a very convenient way to describe device capabilities and user preferences that can be used to guide the adaptation of content presented to that device. This paper has explained the CC/PP architecture, proxy behavior, capability chaining and request processing in HTTP. These things are useful for implementing CC/PP based web applications. References [1] Conceptual Structures: Information Processing in Mind and Machine; John F. Sowa; [2] Extensible Markup Language (XML) 1.0; Tim Bray, Jean Paoli, C. M. SperbergMcQueen [3] Resource Description Framework Model and Syntax Specification;Ora Lassila, Ralph Swick [4] RFC 2506: Media Feature Tag Registration Procedure; K. Holtman, A. Mutz, T. Hardie; [5] Composite Capabilities/Preference Profiles: Requirements and Architecture; Mikael

Nilsson, Johan Hjelm, Hidetaka Ohto;

Related Documents