13:55:50 RRSAgent has joined #awwsw 13:55:50 logging to http://www.w3.org/2009/01/20-awwsw-irc 14:03:31 dbooth has joined #awwsw 14:03:47 Zakim has joined #awwsw 14:03:54 zakim, this is awwsw 14:03:54 ok, dbooth; that matches TAG_(AWWSW)9:00AM 14:04:04 Stuart has joined #awwsw 14:04:16 +DBooth 14:05:28 topic: http://www.w3.org/TR/HTTP-in-RDF/ 14:05:37 zakim, who is on the phone? 14:05:37 On the phone I see +1.781.643.aaaa, DBooth 14:05:46 zakim, aaaa is jrees 14:05:47 +jrees; got it 14:06:00 Meeting: AWWSW 14:06:06 Chair: JRees 14:06:50 +??P4 14:07:01 zakim ,?? is me 14:07:12 zakim, ?? is me 14:07:12 +Stuart; got it 14:08:30 Topic: Requests 14:08:43 jrees: If you get the same request twice, it is the same request? 14:12:35 http://www.w3.org/TR/HTTP-in-RDF/ 14:13:20 Is the dc:date of a Message the date/time at which it was sent? If so, doc should say so. 14:14:04 dc:date " A date associated with the creation or availability of the resource." 14:14:12 this is not specific enough I think. 14:15:27 Re 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/ 14:26:23 what's sent is only a single octet string... 14:27:03 only one entity is sent, thus only a single octet string, single content-type, single character encoding 14:27:25 hhalpin has joined #awwsw 14:29:07 would the three XXXContent things be created on the client side as needed? i.e. can all three exist, even though at most one was sent? the text implies yes. "it is always possible to point to a cnt:Base64Content resource" 14:29:37 "body" in RFC 2616 is the octet sequence 14:31:04 DBooth: So the three contents are different interpretations of the same entity body? 14:32:51 a message always has an entity, and it uninterpreted (possibly null) body, which is an octet sequence 14:33:27 some messages have entities that are interpretable as XML, or PDF, or whatever... then additional relationships hold between the uninterpreted stuff and other things 14:33:59 (other things = interpretations) 14:36:26 jrees: They could get some mileage out of subclassing. Headers could be superclass, RequestHeaders and ResponseHeaders could be subclasses. 14:36:46 ... Would be inclined to have a relation between headers and messages. 14:37:57 One could get some mileage from subclassing (rdfs or owl) to do some header validation... 14:38:51 introduce a new relation between Messages and Headers... 14:38:53 DBooth: Why do they have both methodName and method? One is a literal, the other an object. 14:38:55 There is this example which uses parseType=Collection: 14:38:56 14:38:56 14:38:56 Host 14:38:56 @@@TBD@@@ 14:38:56 www.example.org 14:38:57 14:38:59 14:39:01 User-Agent 14:39:03 @@@TBD@@@ 14:39:05 My User Agent 14:39:07 14:39:09 14:39:11 Accept 14:39:13 @@@TBD@@@ 14:39:16 image/png, image/gif;q=0.8 14:39:17 14:39:20 14:39:21 image/png 14:39:23 14:39:25 14:39:28 image/gif 14:39:29 14:39:29 oops. I started saying something in contradiction to Tim's advice, and I like Tim's advice 14:39:31 14:39:33 q 14:39:35 0.8 14:39:37 14:39:39 14:39:41 14:39:43 14:39:45 14:39:47 14:39:58 Tim says: the headers should all be relations between Messages and literals 14:40:13 wiki page: http://esw.w3.org/topic/AwwswHttpVocabularyInRdfComments 14:40:22 The domain of each header should be Message, Request, Response, as appropriate. 14:42:49 harry, you're not on the call... we're talking about http in rdf 14:48:01 The links in 3.1 and 3.2 are dead. 14:48:30 They would presumably answer the question of why you want the request methods and response statuses as objects instead of literals 14:48:57 ok 14:49:51 StatusCodeGroup could be done as classes: each status code group could be class of StatusCodes. 14:50:48 Or you could do classes of responses: Is R a redirect? 14:51:19 You could then eliminate status codes (hypothetically)... 14:51:58 dbooth: This gets us further away from RFC2616, though. 14:53:15 How about two layers - raw data (method, status code), then inferred classifications (classes of messages) 14:53:39 ok 14:53:43 Use OWL derived classes (not asserted classes) for the latter 14:55:44 dbooth: we should point the authors to our wiki page 14:57:03 ACTION on jrees: send email to http-in-rdf authors re our comments 14:57:03 Sorry, couldn't find user - on 14:57:06 ACTION: JRees to email the HTTP-in-RDF group about our comments in our wiki page. 14:57:06 Created ACTION-14 - Email the HTTP-in-RDF group about our comments in our wiki page. [on Jonathan Rees - due 2009-01-27]. 14:57:38 trackbot, status 14:57:46 -DBooth 14:57:48 -Stuart 14:57:52 -jrees 14:57:54 TAG_(AWWSW)9:00AM has ended 14:57:56 Attendees were +1.781.643.aaaa, DBooth, jrees, Stuart 14:58:01 rrsagent, make logs public 14:58:08 rrsagent, draft minutes 14:58:08 I have made the request to generate http://www.w3.org/2009/01/20-awwsw-minutes.html dbooth 14:59:58 Stuart has left #awwsw 16:29:40 Zakim has left #awwsw