- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 09 Sep 2008 21:34:48 +0000
- To: public-wai-ert@w3.org
- Message-Id: <p06240804c4ec946314e5@[10.100.0.140]>
This document appears to be somewhat confused about the basics of RDF, or may simply be poorly worded. "2.1. Connection Class A resource of type Connection represents a connection that is used for the HTTP transfer. The following properties may appear in nodes of type Connection:" This is wholly unclear. It seems to conflate the notions of resource and RDF description. First, if Connection is an RDFS class (as seems to clearly be intended, though it is not explicitly asserted) then a resource of that type does not ordinarily "represent" anything: rather, it is itself represented (that is, described) by being an element of the class. I believe that what this is intending to say is that the elements of the class Connection are (not represent) connections used for HTTP transfers. However, that issue aside, the next sentence is wholly inappropriate, as the use of the 'may' construction seems to imply that the properties are 'permitted' to be applied to the elements of the class. But in RDF there are no permissions, as there are no prohibitions. Thus, the 'may' construction is meaningless. "connectionAuthority Property representing the connected authority (server host and port) as a Literal." Again, the wording is inappropriate. RDF properties do not "represent": they have values when applied to resources. I presume that the final phrase "as a Literal" is intended to mean that the property value is a literal value: that is, in OWL-DL terms, that the property is a literal-valued property. However, the example given immediately below (example 2.1) does not have a literal value in the relevant position, which casts doubt on this interpretation (and makes the intended meaning quite opaque.) "2.2. Message Class A resource of type Message represents an HTTP message. The following properties may appear in resources of type Message:" This repeats the confusions noted earlier in a more egregious form, as to speak of properties "appearing in" resources is meaningless. "2.2.1. Body Property The body property represents an HTTP entity body as defined in [RFC 2616]. It can appear in resources of both type Request or Response. The object for this property must be a resource of the type cnt:Content or a subclass thereof." (This also repeats the confusions noted earlier, which permeate the document and will not be commented on further.) The phrase "must be" is inappropriate. RDF does not support constraints or restrictions such as this. It would be more appropriate to use the RDFS vocabulary to assert domain and range properties of the relevant properties, though this would not carry the same force as that which seems to be intended here. "2.3.1. Request URI Property The requestURI property represents the request URI as specified in section 5.1.2 of [RFC 2616]. The value of the property is either the constant value http:asterisk or a Literal value of the absolute URI, the absolute path, or an authority. " The phrase "Literal value of ...absolute URI, .." is meaningless. A literal value is the value of an RDF literal. Absolute URIs, absolute paths and authorities are not RDF literals. -------- Similar errors to the above are found throughout the document, but these examples will suffice for now. Pat Hayes -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell http://www.ihmc.us/users/phayes phayesAT-SIGNihmc.us http://www.flickr.com/pathayes/collections
Received on Tuesday, 9 September 2008 23:54:24 UTC