RE: Implementation of a CC/PP processor

Hi Francesco

Firstly thank you for interesting comments and the pointer to this project.
Have you published the results of your work anywhere?

Secondly some comments about the issues you raise:

1. UAProf not using the CC/PP Structural elements

This is an important issue. In fairness to the UAProf drafting committee,
they are aware and concerned about this problem. It is possible that future
versions of UAProf will address this problem. 

However I have been having some discussion with them about this, and I have
been arguing that this is not a problem with UAProf - I think it is with RDF
Schema. If RDF Schema possessed a mechanism to say that two URIs are
identicial, then the UAProf Schema could define components and defaults.
However it could also note that these elements are identical to the elements
defined in the CC/PP Schema and the problem would be solved. This way UAProf
profiles stay unchanged, so existing UAProf profile processors continue to
work. However if you have a more powerful processor which is schema aware,
it will analyse the UAProf schema and match it to the CC/PP Schema. The
alternative solution, which involves altering UAProf profiles so they use
CC/PP constructs, will break existing UAProf processors. 

You can do this kind of mapping in DAML+OIL, or OWL, but not RDF Schema.
However it seems so important for dealing with vocabulary versioning, so I
would argue that it ought to be available at the RDF Schema level. However
it is not clear what the future is for RDF Schema once OWL has been adopted,
and what the implications of this will be for CC/PP. 

The reason the mapping is better is I've already had to help a number of
companies correct profiles where they were confused about whether elements
were in the UAProf or RDF namespace. If you add the CC/PP namespace also,
then things get more complicated because you have three namespaces to choose
from, not two. There is a tension here: we can make things more correct from
an RDF / Semantic Web point of view, but this may be at the expense of
making things harder and more complicated for device vendors providing the
information. We need to make things easy for the vendors, because then they
are more likely to make sure the information they provide is correct. 

Does this seem reasonable? Would the URI mapping approach solve the problem?

2. CC/PP's ability to specify vocabularies

I agree with this issue. Things have become slightly better / worse
recently. Things are better because RDF Core made a decision about how to do
datatyping in RDF, so this should make it possible to use that datatyping
mechanism in CC/PP. Things got worse though because you would have to do the
datatyping in the profiles, not the schemas, so this would mean that CC/PP
would no longer be backward compatible with earlier versions / CC/PP. CC/PP
will adopt a workaround here, but the situation is not ideal. The relevant
issues here are discussued in the appendix of Charles Smith's / my report of
profile validation. 

CC/PP currently uses RDF Schema to describe vocabularies, so one way to
solve this problem would be to extend RDF Schema in some way to capture this
information. It sounds like your intermediate format tries to overcome this
problem. I have raised this issue with the CC/PP Working Group, but they
decided it was outside the scope of the Working Group. However we have had
to consider this in JSR-188, the CC/PP Processing Spec. So we (JSR-188)
would be very interested to hear more about how you are doing this - can you
describe your approach in more detail?

best regards

Mark H. Butler, PhD
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

-----Original Message-----
From: Francesco Cannistrą [mailto:fracan@inwind.it]
Sent: 28 November 2002 19:27
To: www-mobile@w3.org
Subject: 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:
the guidelines to perform profile resolution; 
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

Received on Friday, 29 November 2002 06:02:18 UTC