Re: CCPP and P3P compatibility concerns

Dear Mr. Klyne,

Thank you for your comment about the CC/PP and P3P relationship. I think
that P3P WG members also understand that these two activities should
cooperate with each other.

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.

-----------------------------------------------------
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)
 2) The client capability in P3P does not have arbitrary URI, while
CC/PP requires it. (See Appendix 2)

As for 1), I think it is not a problem. There are several ways to
model P3P policies in RDF. One of them is shown in the P3P spec, but
not limited to it. So, we may be able to show another model fitting
for CC/PP, after the CC/PP model is (almost) fixed.

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.

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

===================================================
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)
>
>

Received on Thursday, 13 April 2000 16:13:05 UTC