Comments on CC/PP Structure and Vocabularies Last Call WD

Dear DI WG,

I have reviewed the CC/PP WD and this email contains my comments.
The comments do not regard only the changes since the Last Call WD but
include considerations about the entire document. I apologize for not having
found the time to review accurately the LC WD before.
Most of my remarks are editorial ones. However, there are even some points
that focus on very important issues and that require a rigorous resolution
(points 5, 8 and 14). I'd like to receive a clear response about these
points.
See my comments in the remainder of this email.

Regards,
Francesco

-----------

0. General editorial remark.

I have not been able to find any reference to a key term like "delivery
context" throughout the entire document. I don't think this is a good thing.

1. Section 1.1 Scope and normative elements (the last period before the
trailing note)

[[... (new CC/PP attributes sub-properties of ccpp:Attribute, new client
components based on ccpp:Component, etc.).]]

- It is not correct to say that attributes are "sub-properties of
ccpp:Attribute". ccpp:Attribute is not a property but is a class (it is an
instance of rdfs:Class, not of rdf:Property). Furthermore, "sub-properties
of" seems to refer to the rdfs:subPropertyOf property.
- "new client components based on ccpp:Component" could be a bit confusing
since a vocabulary does not define "client components" but defines component
classes (i.e. component types): it's a profile that defines the client
components by instancing proper component classes defined by a vocabulary.

2. Section 2.2 Extensibility and namespaces

[[There is a reasonable expectation that a designated (globally unique)
namespace will have associated semantics, including schema-related
semantics. Thus, there is a convention that a namespace URI is associated
with a corresponding schema document, though the specific mechanism for
determining such an association is not formally defined. (The RDF Schema
specification does say that the namespace identifier is also used as a
schema identifier.)]]

I think this paragraph is a bit confusing and is not correct at all. On the
one hand it is true that "the specific mechanism for determining such an
association is not formally defined". On the other hand it is false that
"the RDF Schema specification does say that the namespace identifier is also
used as a schema identifier". I let you note that every element defined
within a schema is unambiguously identified by an identifier (an URIref) and
the schema namespace is part of this identifier. One of the main features of
a schema is that it defines a vocabulary in the sense that it provides a
naming space for the vocabulary elements (properties and classes) and then
permits to leverage these elements in other contexts through the referencing
of their names, being provided that the use of these names is unambiguously
associated with the naming space of the vocabulary they belong to. This
association is made through the schema namespace URI: the schema namespace
does identify the vocabulary naming space and, therefore, identifies (at
least logically) the schema itself too. This goes beyond the fact that an
actual document that defines the schema has effectively been written or the
fact that such a document can (or cannot) be retrieved from the Internet
through the schema namespace URI.

3. Section 3.1 Components

[[A ccpp:Component resource MAY have an rdf:type property (or equivalent RDF
structure) indicating what kind of client component it describes]]

What does this mean?
I think that with "a ccpp:Component resource" you wanted to refer to a
profile component. If so, I let you note that being of type ccpp:Component
does not make of an RDF resource a profile component. A profile component is
the object of a ccpp:component property asserted for a RDF resource
representing a profile. Furthermore, note that if an RDF engine knows that a
resource is a "ccpp:Component resource" this means that the engine has
already read  some assertion about the type of the resource.
I suggest to change this period as follows:

[[The object of a ccpp:component property MUST be a CC/PP component, i.e. a
resource whose type is ccpp:Component or one of the sub-types of this class
that have been properly defined by a specific attributes vocabulary. Such a
resource MAY have an rdf:type property (or equivalent RDF structure) in
order for indicating explicitly what kind of client component it
describes.]]

4. Section 3.1 Components

[[However, CC/PP processors MUST be able to handle profiles that do not
contain component type indicators. As long as the CC/PP attributes used are
all specific to a given component type, a processor will have sufficient
information to interpret them properly.]]

This is not sufficiently expressive. I think it should be stated explicitly
that, in cases where the component type is not indicated, the attributes of
a component MUST all belong to the same component type and that the profile
component itself will be assumed to be of this type.
Consider the following example:
...
<ccpp:component>
   <rdf:Description rdf:about="MyComponent">
      <voc:screenSize>160x160</voc:screenSize>
      <voc:javaCapable>Yes</voc:javaCapable>
   </rdf:Description>
</ccpp:component>
...
If the attributes "screenSize" and "javaCapable" were defined as belonging
to different component types (say the "HardwarePlatform" and the
"SoftwarePlatform" classes) would this profile be valid?
I think it wouldn't be. However, in the sentences above this does not appear
sufficiently clear.
Therefore, I suggest the following changes:

[[However, CC/PP processors MUST be able to handle profiles that do not
contain component type indicators. As long as the CC/PP attributes used are
all specific to a given component type, a processor will have sufficient
information to interpret them properly. It is intended that all the
attributes contained in such a component MUST all be specific to the same
component type and, therefore, the profile component itself will be
implicitly assumed to be of this type. ]]

5. Section 3.1 Components

[[If a CC/PP profile uses any attribute that can appear on different
component types, then the type of any component on which such an attribute
appears MUST be indicated by an rdf:type property, or equivalent RDF. A
CC/PP processor MUST be able to use this type information to disambiguate
application of any attribute used.]]

This is unnecessary and, I think, even contradictory.
In order to see why it is unnecessary consider the following examples:
1)   <ccpp:component>
         <rdf:Description rdf:about="MyComponent">
           <ccpp-client:color>binary</ccpp-client:color>
           <voc:screenSize>160x160</voc:screenSize>
         </rdf:Description>
      </ccpp:component>
2)   <ccpp:component>
         <rdf:Description rdf:about="MyComponent">
           <rdf:type  rdf:resource="&ccpp-ns;Component"/>
           <ccpp-client:color>binary</ccpp-client:color>
         </rdf:Description>
      </ccpp:component>
3)   <ccpp:component>
         <rdf:Description rdf:about="MyComponent">
           <ccpp-client:color>binary</ccpp-client:color>
         </rdf:Description>
      </ccpp:component>
Here the ccpp-client:color attribute is taken from the CC/PP client
vocabulary for print and dislay and it can belong to components of whatever
type (i.e. it has domain on ccpp:Component and, therefore, since all
components are of this basic type, it could be asserted for every profile
component).
In profile 1) the lack of the component type indication does not create
problems since the component contains even the voc:screenSize attribute that
is specific to a certain component type (say the voc:HardwarePlatform type)
and, therefore, this latter component class is to be assumed as the type of
the profile component.
Profile 2) could be suitable for a printer whose capabilities are expressed
by relying on the CC/PP client vocabulary only. Note that the indication of
the component type does not provide any further information and that the
profile 3) would be equivalent as well. In fact, when parsing profile 3), a
processor would find a component having only an attribute that can belong to
components of type ccpp:Component. Therefore, since the component type is
not explicitly indicated and since the component does not contain other
attributes, the processor would automatically deduce that the type of the
component is ccpp:Component.

The reasons for which I think that the above paragraph is contradictory are
a bit deeper and regard the CC/PP structure itself. The contradiction ensues
from the fact that potentially all the CC/PP attributes could be suitable
for assertions about components of different types. In fact, the CC/PP does
not actually impede that a component class defined by a certain vocabulary
could be subclassed within another vocabulary. In point of facts, I neither
see any good reason for which the CC/PP should impose such a limitation.
Consider, for instance, a vocabulary that properly defines a general
component class like the voc:NetworkComponent class (subclass of
ccpp:Component) and either defines general attributes that are applicable to
components of this type like the voc:maxLatency attribute. It is possible
that another vocabulary defines two more specific component types like the
ext-voc:GSMComponent and ext-voc:UMTSComponent classes by subclassing the
voc:NetworkComponent class. Both ext-voc:GSMComponent and
ext-voc:UMTSComponent would now be valid CC/PP component classes since the
rdfs:subClassOf property is transitive. As a consequence, the voc:maxLatency
attribute could be asserted for components of different types, i.e. for
components of type voc:NetworkComponent, of type ext-voc:GSMComponent and of
type ext-voc:UMTSComponent.
Even if I agree that in most cases this would not be a good practice, I can
imagine practical application contexts where the leveraging of the this
possibility could be useful and could provide major advantages (here I
mentioned component classes describing network features only because they
appeared to me as quite intuitive examples). Furthermore, as I already said,
the CC/PP does not actually impede the construction of this kind of
hierarchies for the component classes and I think that this is a good thing.
In fact, I think that the real value of the CC/PP is its being an RDF
application. If the CC/PP specification was filled with lot of constraints
that prohibit from leveraging the RDF potentialities then the CC/PP would
become no more than a mere XML format.

6. Section 3.3 Defaults (paragraph following figure 3-2a)

[[If a component referenced by ccpp:default]]

ccpp:defaults instead of ccpp:default

7. Section 3.4 Distinguishing profile structure from attributes

[[... to describe all the non-RDF and non-CC/PP properties:]]

Maybe a reader misunderstands what "non-RDF properties" are?

8. Section 4.1.1.1 Values described by URIs

All this sub-section is, I think, contradictory and I really don't
understand what it aims at.
Originally the type anyURI was intended as the type for literal values
representing URIs. If it was still so, the section would contain errors but
its existence would make sense. But now I see that such a RDF type has been
deleted from the CC/PP schema and it does not exist anymore. Therefore, this
sub-section has become meaningless.
On the one hand, the section seems to say that even arbitrary RDF resources
can be indicated as values of attributes, i.e. that vocabularies can define
attribute properties that have as range a generic RDF class (e.g. the
rdfs:Resource class). If the aim of the sub-section is this, I let you note
that:
- the section is out of scope since it does not describe a CC/PP defined
data type;
- the section is redundant since it should be already intended that CC/PP
does not forbid the use of valid RDF forms for expressing attribute values
(note also that this is even stated explicitly in section 4.1.2: "Other
complex CC/PP attribute values may be represented by arbitrary RDF
resources");
- it is not in the scope of the CC/PP specification to provide the support
for interpreting the URIrefs that identify the RDF resources (this should be
a basic concern of RDF itself).

On the other hand, it seems that the section wants to say something more.
Like if it tried to overload the semantics of the RDF/XML constructs for
instancing an RDF resource as value of  an attribute property. It seems that
the sub-section almost says  that when the value of an attribute is a
resource the really meaningful part of the value is the URI of the resource
rather than the resource itself (note that the title of the section is
"Values described by URIs"). If the aim was this, it should be clear that
the section would cause potentially heavy incongruities with RDF and would
introduce serious limitations to the CC/PP itself since, in point of facts,
it would impede the use of arbitrary RDF resources as attribute values.

In all cases, I let you note that this section is a sub-section of the
section 4.1.1 ("Simple CC/PP attribute data"), which should describe the
data types for simple attribute values, where it's intended that "all simple
CC/PP attribute values are represented as RDF plain literal values". An RDF
resource is not a "RDF plain literal".

Maybe it's I that have not succeeded in understanding the contents of this
sub-section (?).
BTW, I feel to suggest that the ccpp:anyURI type is reintroduced and that
the section is properly corrected in order to describe this type. If this
was not possible I think that sub-section 4.1.1.1 should be completely
removed.

9. Section 5.1 CC/PP Document Conformance

What is a CC/PP document, a profile or a vocabulary schema? It seems clear
that this section assumes that CC/PP documents are the profiles.
Well, do conformance criteria for CC/PP vocabularies exist?

10. Section 5.1 CC/PP Document Conformance (conformance criterium 1)

[[The document MUST be valid RDFserialized in XML, and be based on a
vocabulary conforming to the RDF Schema in Appendix B.]]

What is the meaning of "based on a vocabulary conforming to the RDF Schema
in Appendix B"?
Unless you wanted to say that a profile can reference only one attributes
vocabulary "conforming to the RDF Schema in Appendix B" (but I do not think
you did), I believe that it would be far more correct and understandable to
say that a document MUST be "based on the vocabulary defined by the RDF
Schema in Appendix B"

11. Section 5.1 CC/PP Document Conformance (conformance criterium 5)

[[The component names MAY be in rdf:type statements.]]

I do not understand: where in the statement, in the subject or in the
object?
I do not think you wanted to say in the object since component names are
names of RDF resources that instance a component class and the object of an
rdf:type statement is here a component class (not a component). Therefore, I
deduce you intended the subject of a type statement. If so, I let you note
that such a subject is not the subject of a rdf:type statement only, but it
is also the subject of all the statements indicating the attributes of the
component (and there must be at least one of these statements).

12. Section 5.1 CC/PP Document Conformance (conformance criterium 6)

[[Components MUST be associated with the CC/PP namespace or some subclass
thereof]]

What is a subclass of a namespace?

13. Section 5.1 CC/PP Document Conformance (conformance criterium 11)

[[Defaults MUST be associated with the CC/PP namespace or some subclass
thereof]]

Same as the previous point.

14. Compatibility with UAProf

All the sentences concerning the compatibility with UAProf are, in my
opinion, not correct and contradictory.
The major feature of CC/PP is that it is an RDF application. Therefore, all
the sentences that state that an UAProf namespace can be used on behalf of
the CC/PP namespace have not real value since they do not indicate any
rigorous reason for such a logical equivalence at RDF level.
Note that all these sentences are even contradictory since, as you
explicitly (and correctly !) state multiple times throughout the document,
any new attribute vocabularies defined MUST be based on RDF classes and
properties defined by the RDF schema in appendix B.
It sounds like an alchemy to me to read that "for compatibility with UAProf,
the namespace used to qualify xxx MAY be a UAProf namespace". It seems like
a kind of magic that tries to make the reader overlook the formal problems
that impede the RDF compatibility between CC/PP and UAProf.
In point of facts, CC/PP and UAProf are parallel, i.e., equivalent but not
compatible RDF applications. UAProf won't be formally compatible with the
CC/PP till it won't rely on the CC/PP structural vocabulary to refer to the
semantics of the CC/PP structure.
However, even with the state of the art, it is possible to achieve RDF
semantic convergence between CC/PP and UAProf by relying on higher level
ontology languages. I let you note that this possibility is explicitly
mentioned as a possible use case of the Web Ontoligy Language (OWL), see [1]
(section 2.6, "Ubiquitous computing"). Here I won't say more about possible
approaches, if interested you can read the outcomes of the approach I
followed in the SADiC API I created [2][3].

In conclusion, since I don't believe that the DI WG wants to base the CC/PP
on any ontology language, I think that the CC/PP specification should treat
the compatibility with UAProf as an implementation issue. It would be far
better for the CC/PP to explicitly admit that there are formal problems that
impede rigorous RDF compatibility with UAProf rather than to ignore or
overlook these problems. Therefore, I suggest that the CC/PP specification
is provided with an apposite section that:
- explains the reasons for which the CC/PP and UAProf are not rigorously
compatible at RDF level,
- affirms the need for converging the two frameworks and
- explicitly permits and encourages implementers to overcome suitably this
incompatibility within their processor implementations while waiting for a
rigorous and general solution to come with the future specifications.

[1] http://www.w3.org/TR/2003/WD-webont-req-20030203/
[2] http://www.the-web-middle-earth.com/sadic/
[3] http://www.the-web-middle-earth.com/sadic/sadicSemantics.html