Re: CCPP and P3P compatibility concerns

Dear Mr Koike,

Thank you for your consideration of my comments.  I think my concerns 
reduce to one area, which I shall try to explain below...

At 04:12 PM 4/13/00 -0400, Yuichi Koike wrote:
>Here are my comments on your concerns. Please let me know if I
>misunderstood something. I think that the CC/PP and P3P compatibility
>matter can not be solved easily. Therefore, let us continue the
>discussion.

Good!

>In my understanding, your concerns are:
>  1) The RDF model shown in the P3P specification does not fit for the
>CC/PP RDF model. That is, the client capability, such as "Memory" or
>"user.name.first", should be "Property" of the RDF triple in CC/PP,
>while it is "Literal" in P3P. (See Appendix 1)

While it's true that CC/PP uses properties where P3P uses literal object 
values, I don't think this is the core problem, except for the fact that 
that it leads to...

>  2) The client capability in P3P does not have arbitrary URI, while
>CC/PP requires it. (See Appendix 2)

I think this is the core problem.  I.e. that something _about which_ one is 
making assertions cannot be an arbitrary URI-labelled entity.

I understand that RDF is built on the presumption that everything (subject, 
property, object) is a first class entity identified by a URI.  Literal 
values appear to be a (much debated?) exception.

>As for 1), I think it is not a problem.

I agree (see above).

>As for 2), it depends on the CC/PP requirement. If CC/PP requires that
>the URI for each capability should indicate a machine-readable RDF
>schema definition, we have to write the CC/PP-style RDF schema
>definition of P3P base data set. Or, we may be able to figure out the
>automatic translation method from P3P's <DATASCHEMA> syntax to RDF
>schema. If CC/PP does not require the RDF schema URI for every
>capability, then you can use the P3P specification URI. Or, if a web
>service uses its own data set, you can use the URI of the extended
>schema.

Data point:  the emerging CC/PP requirement does _not_ look like insisting 
on machine-readable RDF schema for each capability, but the use of RDF 
schema to describe property constraints (initially, for documentation 
purposes) is anticipated.

I agree that P3P properties are easily embedded in an CC/PP capability 
expression.  (This would appear to be a small testament to the generality 
of RDF :-)

My concern is that a arbitrary CC/PP client property cannot be described by 
a P3P expression.  This is the primary use-case I can see right now;  e.g. 
client wishes to ensure that "if I tell you how many widgets I have on my 
gadget, you will use this information _only_ for the purposes of 
customizing content, and not disclose it to any other party".

In CC/PP (through RDF), the client property corresponding to "how many 
widgets I have on my gadget" is identified by an arbitrary URI, which in 
general does not correspond to a P3P data item identifier.  Thus, to 
encapsulate the above statement in a P3P contract would require an 
additional definition that associates a P3P data item name with an 
arbitrary URI, which I think creates undesirable barriers to adoption.

I think this concern would not arise if a P3P data item identifier syntax 
would allow any generic URI form.

For example, what would be the implications for P3P if the current data 
item identifier format were embedded into a URN namespace 
(e.g.  URN:P3P:user.name.last),  and the data item identifier format 
generalized to allow an arbitrary URI?

>So, I think that the RDF modeling shown in the current P3P
>specification does not bother the cooperation of P3P and CC/PP.

For embedding P3P elements in CCPP, I agree.  But for embedding CCPP 
elements in P3P, I think there is a problem.

#g
--



>===================================================
>Appendix 1: Difference of RDF models between CC/PP and P3P
>1) CC/PP uses RDF to describe data as follows:
>---------------------------------------
>  <rdf:Description about="Hardware">
>   <voc:Memory>32MB</voc:Memory>
>   <voc:CPU >Pentium </voc:CPU >
></rdf:Description>
>(This may be wrong, because I guessed the syntax.)
>---------------------------------------
>
>2) P3P uses <DATA> element to describe data:
>---------------------------------------
><DATA name="user.name.first">John</DATA>
><DATA name="user.name.last">Smith</DATA>
>---------------------------------------
>
>3) In order to use P3P vocabulary in CC/PP, the above P3P data should
>be written in the below format:
>---------------------------------------
><rdf:Description about="Privacy">
>   <p3p:user.name.first>John</p3p:user.name.first>
>   <!-"user.name.first" is "Property". It's OK -->
>   <p3p:user.name.last>Smith</p3p:user.name.last>
></rdf:Description>
>---------------------------------------
>or
>---------------------------------------
><rdf:Description about="Privacy">
>   <p3p:user>
>     <rdf:Description about="userdata">
>       <p3p:name>
>         <rdf:Description about="personname">
>           <p3p:first>John</p3p:first>
>           <p3p:last>Smith</p3p:last>
>         </rdf:Description>
>       </p3p:name>
>     </rdf:Description>
>   </p3p:user>
></rdf:Description>
>--------------------------------------
>
>4) However, the RDF model in P3P spec looks like:
>---------------------------------------
><rdf:Description about="Privacy">
>...
>   <rdf:Description about="DATA01">
>    <name>user.name.first</name>
>   <!-"user.name.first" is "Literal". It's NOT OK -->
>   </rdf:Description>
>   <rdf:Description about="DATA02">
>    <name>user.name.last</name>
>   </rdf:Description>
>...
></rdf:Description>
>---------------------------------------
>
>===================================================
>Appendix 2
>1) CC/PP uses RDF schema to define the data schema as shown in below
>example. Since every client capability is defined as a RDF property,
>it has own URI, like "http://www.w3.org/CC/PP-base-schema.rdf#Memory"
>---------------------------------------
><rdf:Property id="Memory">
>   <rdf:coment>Hardware's memory</rdf:comment>
>   <rdfs:range rdf:resource="#Number"/>
>   <rdfs:domain rdf:resource="#Hardware"/>
></rdf:Property>
><rdf:Property id="CPU">
>   <rdf:coment>Hardware's CPU</rdf:comment>
>   <rdfs:range rdf:resource="#Literal"/>
>   <rdfs:domain rdf:resource="#Hardware"/>
></rdf:Property>
>(This may be wrong, because I guessed the syntax.)
>---------------------------------------
>
>2) P3P uses <DATA> element to define the client capability,
>which does not provide an arbitrary URI to each capability.
>---------------------------------------
>  <DATASCHEMA>
>   <DATA name="user.name." type="personname."/>
>   <DATA name="personname.first" type="text"/>
>   <DATA name="personname.last" type="text"/>
></DATASCHEMA>
>---------------------------------------
>
>--
>Yuichi Koike (koike@w3.org)
>World Wide Web Consortium (W3C)
>Technology and Society Domain
>http://www.w3.org/People/Koike/
>
> > Folks,
> >
> > Writing as an individual who also happens to be a participant in the CC/PP
> > working group, and having a growing interest in RDF applications, I have
> > some concerns about compatibility between CC/PP and P3P.
> >
> >
> > 1. How does CCPP/P3P compatibility matter?
> > ------------------------------------------
> >
> > CCPP is defining a framework for describing client capabilities that may
>be
> > used by a server (or possibly a proxy) in the selection and/or generation
> > of content tailored to the client.
> >
> > Some of this information may have implications for privacy;  for example,
>a
> > particular type of client device may be generally used by a user with
> > certain disabilities.  Choice of language might indicate the ethnic origin
> > of a person.
> >
> > Thus, when interacting with a CC/PP and P3P enabled systems, we wish to be
> > able to contract that the server will appropriately limit its use of any
> > sensitive elements of capability information provided.
> >
> > For effective take-up of CCPP and P3P, we believe that it is important
>that
> > the introduction of new vocabulary for identifying client capabilities is
> > as simple as possible.
> >
> >
> > 2. CCPP background
> > ------------------
> >
> > CCPP is an application of RDF.
> >
> > The CCPP specification, and all the earlier work on which it is based
> > [http://www.w3.org/TR/NOTE-CCPP,
> > http://www1.wapforum.org/tech/terms.asp?doc=SPEC-UAProf-19991110.pdf],
>uses
> > RDF property arcs to denote attributes (capabilities, features) of a
>client
> > device.  Thus, individual capabilities are identified by URIs:
> >
> > So an RDF statement describing a particular feature of a client looks like
> > this:
> >
> >    (Client-profile) ---attribute URI---> [attribute-value]
> >
> >     {RDF-resource}     {RDF property}    {RDF resource or literal}
> >
> >
> > 3. My understanding of P3P
> > --------------------------
> >
> > P3P makes assertions about the purposes for which identified pieces of
> > information will be used, and information about other parties to which
>said
> > information may be disclosed, among other things.  The pieces of
> > information are identified by a P3P data schema, which defines strings
>that
> > may appear in a <DATA> element.
> >
> > The P3P specification does not use RDF.  Instead, it uses XML to construct
> > a data structure that denotes a privacy contract.
> >
> > The P3P model can be modelled in RDF, as demonstrated in appendix 4 of the
> > P3P specification.
> >
> >
> > 4. My concerns about P3P compatibility with CCPP
> > ------------------------------------------------
> >
> > Unfortunately, I don't believe that the ability to model P3P data in RDF
>is
> > sufficient;  the style of model also seems to be important.
> >
> > In the RDF model given for P3P data, the information item identifiers
>(that
> > appear in <DATA> elements) are modelled as RDF literals, with a particular
> > format defined by the P3P specification (section 3.3.6).
> >
> > Conversly, the CCPP model requires that client capabilities are described
> > using RDF properties, which are identified by arbitrary URIs.
> >
> > It seems to me, then, that P3P does not provide an automatic way to refer
> > to an arbitrary client capability that may be introduced into CCPP,
>without
> > also defining an explicit mapping to a P3P data schema.  This goes against
> > the need for minimal overhead to introduce new capabilities into CCPP.
> >
> >
> > --
> >
> > So those are my concerns.  Comments?
> >
> > #g
> >
> > ------------
> > Graham Klyne
> > (GK@ACM.ORG)
> >
> >
>

------------
Graham Klyne
(GK@ACM.ORG)

Received on Friday, 14 April 2000 05:08:51 UTC