This document:Public document·View comments·Disposition of Comments·
Nearby:Ubiquitous Web Applications Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-1768 LC-1769 LC-1770 LC-1771 LC-1772 LC-1773 LC-1774 LC-1775 LC-1776
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[1]. 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 using those. For Bag-s, multivalued properties could be a clear alternative; lists (collections) are a clean alternative for Seq-s. Ivan [1] http://www.w3.org/TR/CCPP-struct-vocab2/#ComplexAttribute
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: <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalHardware" ex:displayWidth="320" ex:displayHeight="200"> <rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" /> </rdf:Description> </ccpp:component> which is, in terms of RDF/XML, equivalent to: <ccpp:component> <rdf:Description rdf:about="http://www.example.com/profile#TerminalHardware"> <rdf:type rdf:resource="http://www.example.com/schema#HardwarePlatform" /> <ex:displayWidth>320</ex:displayWidth> <ex:displayHeight>200</ex:displayHeight> </rdf:Description> </ccpp:component> 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 <ex:htmlVersionsSupported> <rdf:Bag> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </ex:htmlVersionsSupported> 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 <ex:htmlVersionsSupported> <rdf:Description> <rdf:type rdf:resource=".....Bag"/> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Description> </ex:htmlVersionsSupported>
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, item #9
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, item #12
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 to CC/PP Ivan
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.