RE: CC/PP Structure and Vocabularies last call working draft - a couple of questions/issues from Claudia

Hi Claudia and Mark,

I have some comments on the questions and issues especially regarding "Is
CC/PP only useful to describe client capabilities?".

I find that CC/PP can describe much more information than just client
capabilities and that this is indeed useful. Understandably CC/PP focuses on
describing device capabilities as this is a key issue with the growing
number of limited devices in use. However by including different types of
context information such as location, current activity, data about the
current environment, etc. content personalisation and adaptation services
can be improved. I feel that this is not only useful but also economically
desirable as it increases the added value of such services.

As Mark points out regarding the inclusion of personal preferences privacy
is an issue. And of course the use of such extended information as mentioned
above greatly increases the privacy concerns but it should be noted that
even with simple device capabilities privacy is an issue. I therefore feel
that extended use CC/PP should not be rejected due to concerns over privacy
as this issue needs to be addressed irrespectively.

The research I am undertaking is investigating the privacy issues in
context-aware mobile computing and includes the use of CC/PP to communicate
general context information. So far the experimental work has shown that
CC/PP is indeed suitable for this more general use although some limitations
exist. To address the issue of privacy a combination of P3P as well as more
classical access control techniques such as Role Based Access Control are
being evaluated. For some more information about the early stages of this
work, which focuses on CC/PP, have a look at
http://www.cs.ukc.ac.uk/pubs/2002/1553/. The main emphasis of the current
work is on the development of a privacy protecting infrastructure for
context-aware environments, in which CC/PP is used to communicate context
information.


Regards,

Patrik Osbakk (pjo2@ukc.ac.uk)
Computing Laboratory
University of Kent
Canterbury, Kent
CT2 7NF
UK

Facsimile: +44 (0)1227 762811

Homepage: http://www.cs.ukc.ac.uk/people/rpg/pjo2/


-----Original Message-----
From: www-mobile-request@w3.org [mailto:www-mobile-request@w3.org]On
Behalf Of Butler, Mark
Sent: 04 April 2003 16:24
To: 'www-mobile@w3.org'
Cc: 'claudia@telemidia.puc-rio.br'
Subject: FW: CC/PP Structure and Vocabularies last call working draft -
a couple of questions/issues from Claudia



FYI - anybody else got any views on the issues Claudia raises?

-----Original Message-----
From: Butler, Mark
Sent: 04 April 2003 11:08
To: 'claudia@telemidia.puc-rio.br'; 'luu.tran@sun.com'
Subject: FW: CC/PP Structure and Vocabularies last call working draft -
a couple of questions/issues from Claudia


Hi Claudia

See my responses to your questions and issues below

-----Original Message-----
From: Claudia Alvarez Rolins [mailto:claudia@telemidia.puc-rio.br]
Sent: 04 April 2003 00:30
To: Butler, Mark
Subject: Fw: CC/PP Structure and Vocabularies last call working draft -
a couple of questions/issues from Claudia

> Questions and Issues

> 1)	What is the difference between content adaptation and
contextualization?

Content adaptation is the process of adapting content (say in XML) to
various target devices (e.g. HTML, WML, XHTML). As for contextualization,
I'm afraid I don't know what that means - but the W3C DI-WG has been working
on a glossary which presumably defines it - Luu? Is the term
contextualization used in the CC/PP WD? If so is it not defined in the
glossary at the end?

> 2)	Proxy behavior was removed from CC/PP Structure and Vocabularies
> and nowdays this specification indicates the use of CC/PP as a profile
> data format to guide/orient a server on determining the most appropriate
> form of a resource to deliver to a client. However content adaptation
> can also be performed at the client side during the content presentation
> (also known as dynamic adaptation).

Yes you can do content adaptation at the client side, but at the moment the
technology I would recommend there is Cascading Stylesheets Media Queries -
see the W3C CSS work for more details. Whereas CC/PP only defines a data
format, CSS MQ also defines a query format. Therefore it is easier to use.
Of course, CSS MQ defines its own vocabulary. There was some disagreement in
the W3C about whether CSS MQ should exist, or whether it should use CC/PP.
However as I've described in many of my reports I think CC/PP is much more
complicated to deploy than it needs to be, and this is due in part from
unnecessary complexity it inherits from RDF/XML. CSS MQ is a much more
pragmatic approach to the problem. I see the DI-WG core device
characteristics work as addressing the need for a common vocabulary here.

> Is CC/PP not indicated to describe context information (e.g.: the origin
> server capabilities) that would be helpful to support the content
adaptation
> process at the client side?

You could use CC/PP in this way and then use a process a bit more like
transparent content negotiation in HTTP. One of my earlier papers describes
a content negotiation approach with CC/PP. However it is actually quite
difficult to do things like this in CC/PP, because if you strictly follow
the CC/PP WD, CC/PP can't express disjunctions or preference ordering.

> Is CC/PP only useful to describe client capabilities?

For the moment, that is how most people are using it, so that is what is
reflected in the current WD. In the future this may change though. The CC/PP
work needs more support so if you are interested in this perhaps you would
consider joining and helping?

> 3)	If a proxy behavior was removed from CC/PP Structure and
Vocabularies,
> is it correct to maintain the sentence "It is structured to allow a client

> and/or a proxy to describe their capabilities by reference to a standard
> profile...." at the fourth paragraph of the Introduction section?

No, this sentence probably needs rewording so I suggest you raise it
formally with the DI-WG as they describe.

> 4)	Why the issues on profile resolution mechanism not addressed is the
> Working Draft from 25 March 2003? Will resolution rules adopted by UAPROF
> (override, locked, append) and data types be treated within the
rdfs:comment
> property?

because unlike UAProf, CC/PP does not have any standardised processing or
resolution policy. I think this is a mistake - without a standardised
processing model, different processors might do very different things. I
have raised this issue with the CC/PP WG, but it has been very hard to
introduce changes to the CC/PP WD for two reasons
- lack of group members and interest in the group
- restrictions due to the current WG charter
therefore it was decided not to address this in the current version.

I'm sure the issue list would be interesting reading for you, but at the
moment it isn't public. Try writing to Luu or the DI-WG and ask if you can
see a copy, because the DI-WG has a public policy so it would be interesting
to see if this extends to the CC/PP Work.

In JSR-188, we solve this problem by just adopting the UAProf resolution
model. In a way, JSR-188 is really just focusing on UAProf as that is the
only CC/PP application that is defined in enough detail to be implemented.

> 5)	Is there any test or example that shows how CC/PP can be used
> to describe users personal preference? Or CC/PP not applied to
> describe this type of context information?

this is a difficult one. There are a couple of viewpoints i.e.

i) if we express personal preferences, then there are privacy issues so we
have to adopt a privacy framework like P3P

ii) does P3P really work? It is just a way of a site claiming it has a
certain privacy policy - what if it lies? Therefore surely if there is
privacy concerns about a piece of information surely we should not send it?
Privacy is a complicated issue. For example people have suggested that if a
PC says it only audio capable, then it indicates a blind user, so there is
the possibility of discrimination, so we should use a privacy system.
However how do we avoid this - if we send no information, we are in the same
situation as if we don't use CC/PP? Personally I don't understand how you
can use specs to stop discrimination, because you don't know how people are
going to discriminate. For example I might decide to discriminate against
Nigerians, because that's where all the spam comes from, and I might do that
by maintaining a list of Nigerian IP subnets - how do you stop me doing that
(this is a theoretical example of course)?

iii) it sounds like to send personal preferences, we need something more
complicated than CC/PP. However we need CC/PP to solve some real issues
today e.g. whether a device supports frames, whether it is mime/multipart
capable etc. So why not just use CC/PP for describing client capabilities
for now?

iv) The other adaptation information that servers need is language
preferences? Is this personal information?

>6) 	Why does Tayeb Lemlouma propose the Universal Profiling in a
> different direction than UAPROF? Could the efforts be joined?

The best person to ask here would be Tayeb. I could tell you my opinion, but
it would just be my opinion and Tayeb might disagree. However I think you
are highlighting that there is a need for a standard vocabulary here, not
lots of separate ones like UAProf, Universal Profiling etc and that need
should be addressed by the DI-WG in the core device characteristics work.

> 7)	While reading the CC/PP Structure and Vocabulary I
> always have the feeling that CC/PP only supports the three
> components: hardware, software and browser. Shouldn´t this
> specification be more explicit and describe that other
> components could be created such as UAPROF did?

No, because the spec just defines a structure, not a vocabulary. The
components it gives are examples, so you don't have to use them, you can
create others. Despite the specs length, it doesn't really say that much.

Personally I don't think that components actually serve any purpose in
CC/PP, and they actually make processing more difficult so I think they
should be removed. If we were starting CC/PP again, then the way I would do
it would be to start with a number of focused use cases, then use these use
cases to check that there was sufficient complexity in the spec to meet the
use cases but no more. At present, there is quite a bit of unnecessary
complexity in the spec, but sadly it is not possible to address this in the
current version. The hope is to get the current version out the door, then
if there is sufficient interest, may be there will be a version 2.

thanks, best regards

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

Received on Monday, 7 April 2003 07:08:32 UTC