This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Ubiquitous Web Applications Working Group
Other specs in this tool
Quick access to LC-1768
There are 9 comments (sorted by their types, and the section they are about).
The document makes use of Seq and Bag for Complex attributes. The
problem is that, from an RDF/RDFS point of view, both of these are quite
ill-defined semantically. Though formally they are not deprecated in the
latest (2004) version of RDF, this was more due to chartering and
administrative reasons rather than anything else. From a Semantic Web
perspective it would be better if a new W3C recommendation could avoid
For Bag-s, multivalued properties could be a clear alternative; lists
(collections) are a clean alternative for Seq-s.
The Note right before 2.1.2, right after Figure 2-1b refers to the
issues on the RDF/XML encoding and the restrictions thereof.
First of all, I presume the intention was to refer to he RDF/XML Syntax
specification and _not_ the RDFPrimer as said in the note. It already
appears among th normative references under the heading [RDFXML].
However, it is not clear to me whether a more 'crisp' statement is true
or not. Is it correct that the _only_ RDF/XML feature of RDF/XML that is
_not_ allowed in a CC/PP application is the typed node syntax (this is
the way I read the note)? Ie, am I allowed to write something like:
which is, in terms of RDF/XML, equivalent to:
If yes, I think it is worth stating this more clearly (as my sentence
above says). If not... well, then a more systematic list of what is
allowed and what is not allowed should be listed somewhere.
It is of course the decision of the Working Group in which direction the
decision is taken. As far as I am concerned, from an RDF point of view,
I would prefer to require a full acceptance of RDF/XML rather than
defining a subset. But I understand the constraints with UAProf. (I had
a quick look at the UAProf2 document that CC/PP refers to, but it is
also silent on the details of this, by the way)
Note that, strictly speaking, the current spec _violates_ this
restriction! Indeed, the idiom
makes use of the type node feature of RDF/XML, ie, in case you maintain
this restriction on RDF/XML, then all your examples should be encoded by
Section 3. CC/PP Structure, 3.1. Components, 1st paragraph says
"For compatibility with UAProf, the namespace used to qualify component
MAY be a UAProf namespace."
I do not understand this statement. Does it mean that you may have _two_
different "component" resources that one can use, one not defined by the
current document? This strikes me as wrong; they are the different
resources in RDF terms.
Maybe an extra statement should be put into ccpp-schema that binds these
two instead (eg, an rdfs:subclassOf in one direction or, if you accept
to use OWL statements, an owl:sameAs or something like that...)
Note that this entry appears in the conformance criteria, section 5.1,
Section 3. CC/PP Structure, 3.3, 3rdf paragraph says
"Defaults can be encoded inline or as separate documents referred to via
URI, but can not be encoded both inline and as a separate document."
I do not understand this requirement. From an RDF point of view there is
no difference between the two, as long as the URI of the default
component is identical (and the examples in the document show that!)
Note that this entry appears in the comformance criteria, section 5.1,
Conformance criteria, section 5.1
Entry #1 says
"The document MUST be valid RDF serialized in XML".
The introduction says that XML (ie, RDF/XML) is only one of the possible
serializations. I presume this entry should simply say
"The document MUST be valid RDF in some serialization format".
Also, Entry #2 seems to be a pretty meaningless requirement in the sense
that any serialization of RDF that is valid also means conformance to a
valid syntax to namespaces. That is _not_ a CC/PP requirement but simply
a valid RDF serialization requirement. The same holds for Entry #5: it
refers to the way a valid serialization handles URI-s. Nothing special
3. Overall in the document: the examples as well as the figures use,
sometimes, the rdf:li idiom of RDF/XML, while sometimes they use the
rdf:_1, rdf:_2 properties. From RDF/XML point of view these are both
o.k. and mean the same thing. The document is consistent in the sense
that if a figure uses, say, rdf:li, then so does the corresponding code.
However, I still wonder whether it is wise to mix the two idioms in this
document. (Examples: Figure 3-2c uses the rdf:_1,... idiom, whereas
Figure 2-2b uses the rdf:li approach.)
This was discussed before and, as far as I remember, the decision to
keep both in the document to show that this can be done and both are
valid. If this is the reason, it may worth stating this explicitly
somewhere and refer to 2.15 section of the RDF/XML spec
1. In the abstract, bulleted item on using RDF classes: to avoid
misunderstandings it may be worth saying "RDF Schema aware processors"
rather than "schema-aware RDF processor". There is a possibility of
confusion between RDF Schema and XML schema (unfortunately...)
2. In the introduction, 3rd paragraph. The text refers to TURTLE as an
alternative serialization of RDF, which is fine. I wonder whether it
would be worth adding a reference to GRDDL, too. CC/PP strikes me as a
relatively simple vocabulary that could be written down as part of an
XHTML file with some sort of an agreed microformat or RDFa, and then
GRDDL-d to extract the RDF/XML information. (This is really just a
proposal, and no problem if the WG does not want to go down that road...)
4. Section 3.1 Components says: "However, CC/PP processors MUST be able
to handle profiles that do not contain component type indicators." In a
strict RDF and RDFS environment this statement is, in fact, redundant.
Indeed, the ccpp schema (correctly) indicates that the range of a
ccpp:component property is ccpp:Component, ie, when used, an RDFS
processor would automatically infer the type.
I understand that a CC/PP processor is not necessarily an RDFS
processor, too, so adding this as a requirement might be o.k. But making
it clear that this requirement is not completely out of the blue might
help the reader.
Add a comment.