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

--
Stephane Boyera		stephane@w3.org
W3C				+33 (0) 4 92 38 78 34 
BP 93				fax: +33 (0) 4 92 38 78 22
F-06902 Sophia Antipolis Cedex,		  
France
 

-----Original Message-----
From: www-mobile-request@w3.org [mailto:www-mobile-request@w3.org] On
Behalf Of Patrik Osbakk
Sent: Monday, April 07, 2003 1:08 PM
To: www-mobile@w3.org
Cc: Butler, Mark; claudia@telemidia.puc-rio.br
Subject: 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 08:20:42 UTC