Implementation of a CC/PP processor

Hi All,

 

I'm a newly graduated Electronic Engineer and in my degree thesis I was called to implement a CC/PP processor. 

My project focused on the definition of a platform which acts as an intermediary between the Web and web-enabled devices accessing its resources. The goal of the platform is to have web contents and services accessed in a device independent way: the platform acts as an HTTP proxy retrieving contents from the Web on behalf of the users and then performing an adaptation process whose output is a custom representation of information, appropriate to delivery context's specific capabilities of the access-mechanism through which a resource must be enjoyed.

What I developed is a platform which met the requirements for context-aware provision of web contents and services. It does not address content adaptation, instead, it represents a processing infrastructure where any specific adaptation process can be deployed  and can perform its tasks by exploiting the rich APIs exposed by the platform.

My work fits into a larger project, the @Terminals European project, whose goal is to perform content adaptation too. You can find out more about the project at the link:

 http://www.cefriel.it/activities/research/projects/default.xml?id=18&_euro=1&old=1&dc=1&aid=0

 

Here I want to say something on my work, explaining briefly some of the troubles and holes I detected in CC/PP and UAProf, and how I succeeded in overcoming them. Consider this as a comment on CC/PP WD too.

 

The first point I want to focus on is about UAProf and its compatibility with CC/PP. Many things have been said about this. Someone says that UAProf is an implementation of CC/PP, others say that UAProf and CC/PP are equivalent and compatible standards. My opinion is that UAProf is not a standard: it's many subsequent standards and each one does not comply with the others and with CC/PP.

I say more. The goal of CC/PP is to build a base for the interoperability of applications which want to exchange delivery context information on the Web (and not only). In order to do so, the main ideas of CC/PP are:

·        introducing a structural representation for delivery context information; that is, delivery context information is expressed by means of a set of instances of attributes defined in some vocabulary and grouped together in a profile;

·        introducing the primitives to define attributes' vocabularies that contain the definition of the attributes which can be used to represent specific capabilities of a delivery context.

This is achieved through RDF: CC/PP defines a structural vocabulary that provides the RDF primitives to define attributes' vocabularies and to construct profiles, that is, to instance the structure of a profile in an RDF model and to populate this structure with attributes defined in one or more vocabularies. It's by this way that CC/PP accomplishs interoperability and extensibility:

·        all applications share the concept of profile and know how to recognize and to construct it through an RDF model: a profile constructed by an application is recognizable by all others; 

·        an application can define its own vocabulary that contains the definition of attributes useful to represent specific capabilities, and such vocabulary can be used by all other applications to construct profiles.

What's wrong in UAProf is that in the UAProf schema it redefines the whole structural vocabulary. So, even if the structural properties defined in the UAProf schema have the same semantic as those defined in the CC/PP structural vocabulary, these are different RDF properties with different usage constraints: the attributes defined in the UAProf schema, formally, can be used only to build a profile whose structure is instanced through the RDF properties defined in the UAProf schema itself. This goes beyond the fact that these properties have the same meaning of the CC/PP structural properties: a schema-aware RDF engine would not validate a profile whose structure is instanced through the CC/PP structural properties and is populated with attributes defined in the UAProf schema. So, as CC/PP is an RDF application, it's true too that UAProf does not comply, formally, with CC/PP.

But there's more. In UAProf the possibility to extend the attributes' vocabulary was intended in the sense that new schemas are proposed, and these contain not only the definition of the new attributes that must be added to the attributes' vocabulary, but they redefine the whole structural vocabulary and the attributes already defined in previous schemas too . This causes many problems that most of you should know. Here I say something only about the main one problem. That is: every new schema, as a matter of fact, redefines the entire standard. So UAProf is not, as I think it should be, a standard that enhances itself, from time to time, by enlarging the vocabulary with new attributes (or, if you prefer, by adding new attributes' vocabularies), instead, it's a sequence of standards, and each one is intended to override the previous (with which it does not comply).

So, when it's said that "CC/PP is designed to be broadly compatible with the earlier UAPROF specification ... That is, any valid UAPROF profile is intended to be a valid CC/PP profile", in order to have this assertion acquire real value, it should be specified what it exactly means by a formal point of view. In my opinion, this is not done in the CC/PP structural and vocabulary specification. 

 

The second main group of problems I encountered is concerned with the poor means provided by CC/PP to specify the semantic of an attributes' vocabulary. This regards tow main aspects:

  1.. the guidelines to perform profile resolution; 
  2.. the possibility to specify the data structure for the values of attributes.
As regards the former point, it's to say that even if CC/PP does not depend on the protocol used to transport a profile over the net, it's true too that some assumption about the way a profile can be communicated is made. That is, a profile can be communicated in a composite way, by means of a set (or a sequence) of independent CC/PP descriptions, eventually referred indirectly. It's obvious that the advantage of transporting a profile in such a way depends on the possibility, for who must read such a composition, to assembly correctly the pieces and so recognize the equivalent profile. This operation is what is intended as profile resolution, and the equivalent profile is the resolved profile. Profile resolution should be performed through the application of resolution rules. These are rules that let determine the correct value which must be selected for an attribute instanced, with different values, in subsequent segment descriptions of the same profile. But CC/PP says nothing about profile resolution. It's very strange that in CC/PP exchange protocol is said:

"The latest reference in the Profile header field-value has the highest priority. Therefore a CC/PP description which is represented by the latest reference can override CC/PP descriptions which are represented by the precedent references. This is the default behavior in the absence of schema rules.

NOTE: The CC/PP schema provides its own overriding/protection rules. When applying these schema, a CC/PP description which is represented by the latest reference must not override the precedent CC/PP descriptions."

 

But how should a vocabulary's schema specify the resolution rules (that is, the "overriding/protection rules")? 

CC/PP provides no means to specify these rules in an attributes' vocabulary!

In UAProf the importance of transporting a profile in a composite way was fully understood. In fact, in the UAProf schema(s), resolution rules are effectively defined and associated to the various attributes. However this was made informally, by means of comments in the schema.

 

Consider now the latter point, that is the possibility to specify, in a vocabulary's schema, the data structure for values of attributes defined in the vocabulary. One of the main duties of a CC/PP processor should be, in my opinion, to validate the syntax of a profile before providing the information it stores to a client application (e.g. an adaptation process): the value of an attribute instanced in a profile should be validated by a CC/PP processor. But CC/PP does not do more than defining four data types, it does not let an application define, in a vocabulary, a new data type that could be useful to represent the value of a specific capability. In CC/PP it's intended that specific values should be represented trough the generic type "ccpp:Text". I think that's not enough. Moreover, CC/PP does not let specify both the attribute's data type and the structure of its values. In a vocabulary, when, for an attribute, the structure is specified (e.g. rdf:Bag), it can't be possible to specify the data type of the structure's elements too. In UAProf the importance of specifying the full data structure for attributes' values was understood. In fact, in the UAProf schema(s) the structures and data types for attributes defined in the schema are effectively specified and associated to all attributes. However this was made, again,  informally, by means of comments in the schema.

 

In the framework I developed, I succeeded in overcoming the actual difficulties detected in CC/PP and UAProf by defining a processing model that takes into account all the semantic aspects concerned with recognizing delivery context information communicated by a terminal. This model is designed in such a way that the specific semantic of an operation, so as intended in a specific attributes' vocabulary (e.g. resolution rules and typed validation of attributes' values), is mapped and executed automatically and dynamically in the process. In order to do so, I needed to define an intermediate format to represent a vocabulary into the platform. This format is neutral with respect the formal methods that could be used to define a vocabulary: it's only a way to represent the information needed to process a profile, which must be provided with the definition of a vocabulary.

In order to overcome the formal incompatibilities between CC/PP and UAProf, the format lets a vocabulary define an ontology as regards the structural semantic of a profile. A vocabulary can specify RDF properties other than the structural properties of CC/PP, which let instance the semantic structure of a CC/PP profile in an RDF model. So, the structure recognized by a vocabulary can be instanced, in a profile, both with the  CC/PP structural properties and with other RDF properties (with the same semantic): the vocabulary's attributes can be used to populate both these equivalent structures.

However the CC/PP processor I implemented is not vocabulary-dependent at all: profile processing is accomplished even when a vocabulary is not recognized (installed). In this case, only CC/PP structural validation is made and resolution is performed through the default resolution rule defined in CC/PP exchange protocol.

 

Excuse me for having been too long (and for my imperfect English too :-)).

 

Best regards,

 

Francesco