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

Hi,

> 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.

I agree with that, I have already discussed some issues related to this in
the delivery context workshop (INRIA Sophia antipolis, France) [1]. UPS
schemata addressed the description of more than the device capabilities in
order to facilitate the adaptation and the negotiation of the content.



[1]
http://www.w3.org/2002/02/DIWS/submission/tlemlouma-W3CPositionPaper03-2002.
htm

Tayeb*

----------
Tayeb Lemlouma
http://opera.inrialpes.fr/people/Tayeb.Lemlouma/index.html
WAM project
National Research Institute in Computer Science and Control (INRIA
Rhône-Alpes, France )
Office B213, phone (+33) 04 76 61 52 81, Fax (+33) 04 76 61 52 07.


----- Original Message -----
From: "Patrik Osbakk" <pjo2@ukc.ac.uk>
To: <www-mobile@w3.org>
Cc: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>;
<claudia@telemidia.puc-rio.br>
Sent: Monday, April 07, 2003 1:07 PM
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 09:15:03 UTC