W3C

- DRAFT -

AWWSW

20 Jan 2009

See also: IRC log

Attendees

Present
+1.781.643.aaaa, DBooth, jrees, Stuart
Regrets
Chair
JRees
Scribe
Stuart

Contents


 

 

http://www.w3.org/TR/HTTP-in-RDF/

Requests

<dbooth> jrees: If you get the same request twice, it is the same request?

<jrees> http://www.w3.org/TR/HTTP-in-RDF/

<jrees> Is the dc:date of a Message the date/time at which it was sent? If so, doc should say so.

<jrees> dc:date " A date associated with the creation or availability of the resource."

<jrees> this is not specific enough I think.

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/

<jrees> what's sent is only a single octet string...

<jrees> only one entity is sent, thus only a single octet string, single content-type, single character encoding

<jrees> 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"

<jrees> "body" in RFC 2616 is the octet sequence

<dbooth> DBooth: So the three contents are different interpretations of the same entity body?

<jrees> a message always has an entity, and it uninterpreted (possibly null) body, which is an octet sequence

<jrees> some messages have entities that are interpretable as XML, or PDF, or whatever... then additional relationships hold between the uninterpreted stuff and other things

<jrees> (other things = interpretations)

<dbooth> jrees: They could get some mileage out of subclassing. Headers could be superclass, RequestHeaders and ResponseHeaders could be subclasses.

<dbooth> ... Would be inclined to have a relation between headers and messages.

<jrees> One could get some mileage from subclassing (rdfs or owl) to do some header validation...

<jrees> introduce a new relation between Messages and Headers...

<dbooth> DBooth: Why do they have both methodName and method? One is a literal, the other an object.

There is this example which uses parseType=Collection:

<http:headers rdf:parseType="Collection">

<http:MessageHeader>

<http:fieldName>Host</http:fieldName>

<http:headerName rdf:resource="http://www.w3.org/2008/http-header#host"/>@@@TBD@@@

<http:fieldValue>www.example.org</http:fieldValue>

</http:MessageHeader>

<http:MessageHeader>

<http:fieldName>User-Agent</http:fieldName>

<http:headerName rdf:resource="http://www.w3.org/2008/http-header#user-agent"/>@@@TBD@@@

<http:fieldValue>My User Agent</http:fieldValue>

</http:MessageHeader>

<http:MessageHeader>

<http:fieldName>Accept</http:fieldName>

<http:headerName rdf:resource="http://www.w3.org/2008/http-header#accept"/>@@@TBD@@@

<http:fieldValue>image/png, image/gif;q=0.8</http:fieldValue>

<http:headerElements rdf:parseType="Collection">

<http:HeaderElement>

<http:elementName>image/png</http:elementName>

</http:HeaderElement>

<http:HeaderElement>

<http:elementName>image/gif</http:elementName>

<http:params rdf:parseType="Collection">

<jrees> oops. I started saying something in contradiction to Tim's advice, and I like Tim's advice

<http:Param>

<http:paramName>q</http:paramName>

<http:paramValue>0.8</http:paramValue>

</http:Param>

</http:params>

</http:HeaderElement>

</http:headerElements>

</http:MessageHeader>

</http:headers>

<jrees> Tim says: the headers should all be relations between Messages and literals

<dbooth> wiki page: http://esw.w3.org/topic/AwwswHttpVocabularyInRdfComments

<jrees> The domain of each header should be Message, Request, Response, as appropriate.

<jrees> harry, you're not on the call... we're talking about http in rdf

<jrees> The links in 3.1 and 3.2 are dead.

<jrees> They would presumably answer the question of why you want the request methods and response statuses as objects instead of literals

<jrees> ok

<jrees> StatusCodeGroup could be done as classes: each status code group could be class of StatusCodes.

<jrees> Or you could do classes of responses: Is R a redirect?

<jrees> You could then eliminate status codes (hypothetically)...

<jrees> dbooth: This gets us further away from RFC2616, though.

<jrees> How about two layers - raw data (method, status code), then inferred classifications (classes of messages)

ok

<jrees> Use OWL derived classes (not asserted classes) for the latter

<jrees> dbooth: we should point the authors to our wiki page

<jrees> ACTION on jrees: send email to http-in-rdf authors re our comments

<trackbot> Sorry, couldn't find user - on

<dbooth> ACTION: JRees to email the HTTP-in-RDF group about our comments in our wiki page. [recorded in http://www.w3.org/2009/01/20-awwsw-minutes.html#action01]

<trackbot> Created ACTION-14 - Email the HTTP-in-RDF group about our comments in our wiki page. [on Jonathan Rees - due 2009-01-27].

trackbot, status

Summary of Action Items

[NEW] ACTION: JRees to email the HTTP-in-RDF group about our comments in our wiki page. [recorded in http://www.w3.org/2009/01/20-awwsw-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/20 14:58:14 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: Stuart
Inferring Scribes: Stuart
Default Present: +1.781.643.aaaa, DBooth, jrees, Stuart
Present: +1.781.643.aaaa DBooth jrees Stuart
Got date from IRC log name: 20 Jan 2009
Guessing minutes URL: http://www.w3.org/2009/01/20-awwsw-minutes.html
People with action items: jrees

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]