From W3C Wiki
(See also: AwwswHome)
This page is a set of comments by the AWWSW group on the HTTP in RDF vocabulary from the EARL folks. Using the prefix htp: for the HTTP in RDF vocabulary (the wiki gets confused if one used http : )
I (tbl) much prefer to have
- x httph:contentType "text/plain".
htp:header [ htp:name "content-type"; htp:value "text/plain" ]
Use of rdf:alt rdf:Seq is deprecated. In the case in 2.2.1 concerning the HTTP body, the relationships between a message and its body as a string, its body base64encoded and its body as an XML document are three quite different relationships.
[dbooth] Section 2.2.1 uses rdf:Alt to indicate multiple Content instances for an htp:body. But in RFC 2616, AFAICT an HTTP entity body only has one body. So why multiple Content instances?
[jar] (answering dbooth) I think what's meant is that there may exist (in a Platonic sense, or on the client side) multiple interpretations of the entity, even if only one version is sent. That is, the Message contains an Entity, whose body, an octet sequence, can be interpreted as being a string (under some encoding) or an XML infoset (ditto). If it were me I would create a class Entity that corresponds to RFC2616 'entity', which is useful because unlike the body it carries content type and possibly character encoding and is therefore interpretable. Then I would make separate classes for the various levels of interpretation (string, XML, OWL, OWL-DL) related to one another appropriately.
[dbooth] Section 2.2.1 has a Note saying "for multiple representations of the same entity body, an RDF container must be used to describe the relationship". Are you using the word "representation" in the AWWW http://www.w3.org/TR/webarch/ sense or in the generic English sense?
[dbooth] Why is MessageHeader a subClassOf RDF Collection? I am looking at the RDF in http://www.w3.org/2006/http . It seems to say that a MessageHeader is a collection having two elements, both of which are owl:Restrictions. I would think the MessageHeader itself should be a subclass of the owl:Restrictions.
[jar] dc:date only says that the date is somehow relevant to the object. You need your property, perhaps a subproperty of dc:date, that says in particular that the date in question is a timestamp, assuming that's what you mean for it to be.
dc:date "Definition: A point or period of time associated with an event in the lifecycle of the resource." from http://www.dublincore.org/documents/dcmi-terms/
MethodName versus Method
[dbooth] In section 2.3 http://www.w3.org/TR/HTTP-in-RDF/#requestClass Why is there both a methodName and a method property? One is a literal, the other indicates an object. What is done with the object?
[jar] I found the documentation for HeaderElement hard to follow. The example should show the original header as transmitted by the client or server. The word "element" needs more explanation because it's not used formally in RFC 2616, and there is some dissonance with HTML and XML.
Domains and ranges
Every property should have a specified domain and range. headerElements and some others don't have ranges. Use Collection if necessary. (This points out the awkwardness of using collections - see below.)
This should be done using classes of StatusCodes, not objects.
Alternatively, you could do all of your higher-level interpretation as derived classes on Messages. For example, rather than have a class of RedirectStatusCodes (of which status code 301, 302, ... would be members) you would have a subclass Redirect of Responses, those responses whose status codes indicate that they're redirects.
The hyperlinks in 3.1 and 3.2 are dead.
- Please specify properties as either object properties or datatype properties. E.g. StatusCodeNumber needs to be a owl:DatatypeProperty. Generally speaking, any property given as an rdfs:Property with a range of rdfs:Literal should be an owl:DatatypeProperty instead, and all others should be owl:ObjectProperty. The reason for doing this is to be able to take advantage of OWL reasoners for sanity checking and validation.
- Some additional work beyond the above needs to be done to make the ontology be OWL-DL.
- Your modeling of the requestURI as either a literal or the resource named by 'asterisk' is going to be a problem for OWL; I suggest modeling this in some other way, perhaps with a new property that is true when the request URI is wild and false when it isn't.
- Collections don't work in OWL. I suggest introducing redundant properties relating messages (and other things) to the members of collections. E.g. you could have a 'request' property with (connection) request (request) asserted for each request that is a member of the connection's 'requests' collection. In the case of 'headers', this, in conjunction with Tim's suggestion of creating a property for each kind of header, would enable validation of admissibility of request-headers and response-headers using OWL. (I.e. OWL could tell you that you incorrectly used a response-header with a Request and vice versa.)