Comments on http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/

First, I want to let you know you have a really nice protocol here. I'd also
like to congratulate you on choosing RDF for your spec, I think it is a
great fit. Oh, one more thing: thanks for inviting SWAG[2] to comment on
your draft.

Here are some comments/corrections to your Last Call Working Draft[1]:

> other xml document types.

I believe XML should be capitalized here.

> this document is created from merge of

I believe you mean "this document is created from the merge of" (notice the
added "the").

> HTML <alt> tags

There is no HTML <alt> tag (that I know of). I believe you mean the alt
attribute.

> any new attribute vocabularies defined MUST conform to the RDF schema in
> appendices B and C.

I don't believe RDF schema supplies any definition of conformance, so you
will have to explain what you mean by conformance here. How do I make a
vocabulary that conforms to your schema?

> Section 2 provides [...]

It would be nice if these section references were links.

> The term "CC/PP attribute" [...]

It may be a little too late to change this, but the term attribute conflicts
with the XML syntactical element of the same name. FWIW, Dublin Core and
SWAG use the term "term" to refer to properties and classes, etc. Since
attributes appear to be just RDF properties, you may just want to call them
properties also.

> another RDF resource names 'Object-resource'.

I believe you mean "named" not "names".

You also use rdf:about attributes with relative URIs that reference other
documents. (like rdf:about="xxx") I believe this is a clear mistake. These
should be replaced with either rdf:ID or rdf:about="#xxx".

In Figure 2-1b, you omit the rdf: prefix on the about attribute of the third
ccpp:component.

In Figure 2-2b (and other examples), you show an rdf:type property with a
value of "BrowserUA" (and other similar values). This seems like a mistake,
since such a value would mean that the type of the property would change
every time the document was parsed by an RDF parser. Surely this is not what
you want. It seems like it would be more effective if you used the typedElt
syntax, like:

<ccpp:component>
  <BrowserUA rdf:about="#xxx">
     <!-- ... -->
  </BrowserUA>
</ccpp:component>

Of course, you provide no default namespace, so all of your unprefixed
attributes have no way to live. I'm not quite sure what happens when you
don't provide this default namespace, but I do not it's not a good idea.

For section 2.1.3 you again use unprefixed references and do not explain how
a client would find these defaults and connect them to the references in the
profile. ... Oh, wait. You explain this later. Perhaps this explanation
should come sooner.

In section 2.1.4, you describe how proxies can provide their own profiles,
but do not explain how this should be integrated with the client profile.
Furthermore, the example shows the proxy passing along its own OS (Linux)
and other information that seems irrelevant to the server. Is this a mistake
or is more explanation needed to make this use case clearer?

> refer to the RDF Schema specification [4].

It seems that some references are linked, but some (like to [4] in section
2.3.1 as quoted above) are not. Is this a normative/non-normative reference
distinction? If so, it should be clearer.

> see Section 6.2.1.

In the same section, this reference is also unlinked.

Figure 2-12 is a broken image (404).

> RDF Model and Syntax specification [3] defines two ways to name RDF resources,
> namely "ID" and "about". RDF resources named by "about" are fully identified,
> whereas those named by "ID" can not be referenced from outside the containing
> document, unless some additional information is available that allows the full
> (absolute) base URI to be determined. The RDF specification is not currently
> clear about how a base URI should be determined [34].

Actually, I think you misunderstood Ralph's letter. RDF clearly defines how
to determine the absolute URI, and how a base URI should be determined is
clear. The problem is that there is no mapping from a fragment identifier to
the ID attribute in RDF. However, most people assume this mapping, although
it is not officially specified. Especially since the spec refers to the
value of ID attributes using fragment identifiers itself! So, while you may
continue to require that the about attribute is used, please correct your
statements about the RDF spec.

> the namespace identifier <http://www.w3.org/2000/07/04-ccpp-proxy#>.

You don't really need to wrap that in angle brackets if it's surrounded by
tags. It'll probably just confuse people.

With the proxy chaining described in 3.2.1, how would an implementation find
the outmost layer in the chain? How should implementations deal with
nextProxy cycles, dead-ends etc. Perhaps you could provide an algorithm to
make this easier.

Also, why do you make a separation between request profiles and proxy
profiles? It seems this just adds unnecessary bulk. It would make more sense
just to have chains of proxyProfiles pointing down towards the client.

In Figure 3-13b:
> <rdf:li>text/xml</rdf:li>

I remember some discussion about this, so maybe it's been decided, but why
don't you just use the content-type URIs and stick them in the schemas
section. It seems much simpler. The official URIs are:
    ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/
as defined in ftp://ftp.isi.edu/in-notes/rfc2048.txt

(I keep track of this at: http://logicerror.com/contentType )

> <rdf:li>http://example.org/example/XHTML-1.0</rdf:li>

Are you sure you don't mean:

<rdf:li rdf:resource="http://example.org/example/XHTML-1.0" />

These mean two totally different things. One is a string of characters, the
other is a URI. I'm pretty sure you mean to use a URI here.

With an example, like:
>           +--type---------> { "text/xml", "application/xml"}
>           +--type---------> { "text/html", "application/html"}
>           +--schema-------> { "http://example.org/example/XHTML-1.0" }
>           +--uaprof:HTMLVersion--> { "3.2", "4.0" }

I'm not clear about the semantics of a container here.
    - Why are there two separate lists of types?
    - Are these terms anded or ored together (i.e. text/xml [and|or] HTML
3.2)?
    - Does the support of application/xml mean it can read any XML? How is
it to be interpreted?

In 4.1.1.1:
> A URI is represented as a text string, but is subject to comparison rules set
> out in RFC 2396 [28], which may require 'absolutization' of the URI as
> described there. 

You should be careful there, RDF recognizes URIs as something special, not
just strings.

WRT 4.1.1: How come there's no decimal? It'd be really nice to say
HTMLVersion > 2.1 or some such.

In A.1 the term Anonymization isn't bolded like the rest.

> Some communication process that provides definite and tamper-proof
> information about the identity of a communicating party.

Why is there a line break there?

> This term has been the subject of much dispute. Broadly speaking, it is
> a process that prevents a party to a communication from subsequently denying
> that the communication took place, or from denying

more line breaks...

> accessed, the parties with
> whom communication occurs, etc.

yet another!

> rdfs:Literal
>   ccpp:URI                  {A URI value of a CC/PP attribute}

A URI is not a literal, but a resource!

With Figure B-3, the RDF spec recommends not using entities as you do for
your namespaces since they might be removed in a future version of XML.

Also, why do you declare your own ccpp:Resource? It doesn't seem you get any
benefit from that, but simply pollute the namespaces.

Also, you may not want to use rdf:ID in these schemas, unless you specify
the base URI since you'll effectively be defining all these terms with the
namespace of the specification itself!

>       A proxy profile has an arbitrary number of ccpp:proxy-behavior
>       properties, each of which indicates an individual
>       ccpp:Proxy-behavior value.

Actually, there is no proxy-behavior property. I believe you mean
proxyBehavior. BTW, why the inconsistent naming of that one property? --
you're right to be confused.

>       When this type is
>       used, the value of the CC/PP attribute is the URI rather than the
>       resource identified by the URI.

I'm a little confused -- when would you ever use this? I can't expect that
you'll need to talk about URIs.

>       This class is used to represent any CC/PP attribute value that
>       is arbitrary text.

How is this different from literals?

You may also want to declare that the Defaults property is deprecated, or
some such.

> This is one of three properties to describe a proxy behavior.

This is unnecessary, and sort of limits extensibility. You can keep it in
the text, but you don't need it in the schema.

>       If this property is present, the behavior associated with the
>       corresponding ccpp:Proxy-behavior resource is applied only if
>       the outbound request profile indicates capabilities that match
>       all those of the Component that is the object of this property.

This is a bit confusing. Isn't a request profile inbound, not outbound?
Second, if this is true, why even bother to specify applicability. The proxy
should just look at the profile and provide the information that's
appropriate. I think you really mean something different (i.e. that for this
type of data, this is what's done) and this should be specified.

> URIs and optional fragment identifiers

According to the URI spec, a "URI reference" includes a fragment identifier,
so I don't think you need to be so explicit about this.

> All properties used as CC/PP attributes must be instances of the class
> ccpp:Attribute, which itself is a subclass of rdf:Property.

How should this be defined? Should the subclass declaration be included in
every CC/PP request? Should it be at the namespace? Should it be mailed in
to the W3C? Please elaborate. I wouldn't complain, but this is a MUST
requirement, which it seems is effectively useless. ("Yeah, it's a
subclass." "Where is that defined?" "Well, I wrote it down on this stickie
note, you see!") Also note that some clarifications of this could prevent
the use of terminology created for another purpose (and thus, wasn't
specified as a subClassOf ccpp:Attribute) which would be a bad thing.

> NOTE: the proxy vocabulary described later [...]

Actually, I believe it was defined "above".

>[...] of attribute names in a profile.NOTE: if there a [...]

You're missing a paragraph break and a capital at the beginning of the
second sentence.

> We recommend [interCap style] be used for CC/PP attribute names

Then how come all your attributes are hyphenated?

> An attribute defined very broadly might be subject to different privacy or
> security concerns when applied in different circumstances. For example, having
> a text-to-voice capability on a mobile phone type of device might be a
> generally useful feature, but a similar feature in a PC might be indicative of
> a personal disability.

This doesn't make sense. It seems if anything, a specific attribute would be
more of a privacy concern. supportsScreenReader is a disability giveaway,
where as the broader textToSpeech is less revealing. Having well-defined
attributes is good practice, but the reasons provided should be sound.

In Appendix E, you mention a large number of formats without providing URIs,
or really any information applicable to CC/PP. Why? If there's no good
reason, this section should be removed. Even so, you may want to say it's
non-normative.

Also, why don't talk about CCPP in HTTP, or at least point to the note?

The use of a special textual syntax to make the RDF graph more clear, but it
might be better to use an established format like Notation3 (which has
software to convert it to RDF XML) rather then inventing yet another syntax.
It may also be smart to eliminate the textual version in some examples, and
just go with RDF document fragments (not full documents).

http://www.w3.org/DesignIssues/Notation3

For example, using N3, this:

[Profile]

 |
 +--ccpp:component-->[TerminalHardware]
 +--ccpp:component-->[TerminalSoftware]
 +--ccpp:component-->[TerminalBrowser]

becomes:

:Profile
  ccpp:component :TerminalHardware ;
  ccpp:component :TerminalHardware .

or, optionally:

:Profile
 >- ccpp:component -> :TerminalHardware ;
 >- ccpp:component -> :TerminalHardware .

The use of examples is nice, but there is no need to illustrate every point
with both a textual and XML representation. It quickly gets repetitive. I
suggest that you explain as clearly as you can in prose and possibly refer
to an appendix with more complicated examples that demonstrate many
features.

Furthermore, the seemingly arbitrary separation of "architecture" and
"structure" makes the spec confusing and hard to follow, as well as very
repetitive. Actually, it might be best to rethink the whole structure of the
document. You should probably start with some simple RDF explanations, then
demonstrate extensibility, and _then_ demonstrate the specific feature of
CC/PP. I feel this would significantly simplify and shorten the document
while making it more understandable.

You will of course want to stick copies of your schema in your namespaces.

> World Wide Web Consortium Recommendation: http://www.w3.org/TR/PR-rdf-schema

I believe the correct URI is: http://www.w3.org/TR/rdf-schema/

Also, in terms of URI tidiness, you may want to have:
    http://www.w3.org/TR/CCPP-vocab/
    http://www.w3.org/TR/CCPP-struct/
redirect (instead of just providing) to the new draft. That way people won't
continue to give out bad URIs.

Phew, all done. Does this mean I get to go in the acknowledgements section?
;-)

[1] http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/
[2] http://purl.org/swag/
-- 
Aaron Swartz <me@aaronsw.com>|           my.info
  <http://www.aaronsw.com>   |   <http://my.theinfo.org>
AIM: JediOfPi | ICQ: 33158237|  the future of news, today

Received on Sunday, 18 March 2001 23:37:19 UTC