See also: IRC log
<jar> hello. looks like you've got the robots with you
hi jonathan - amazingly enought I am awake
<jar> amazingly. how's the kid.
sleeping. hopefully purged of the devil
<jar> i need to dial in
<jar> phone# 761-6200, yes?
there are uk numbers too...
<jar> foo! doesn't recognize conference code
blast invalid passcode
<jar> i didn't reserve - thought it was all set up already. now what, should i ask for admin assistance? guess so
<jar> passcode should have been AWWSW
<Stuart> you might have some luck on the sysreq channel
<jar> dialing in again, will *0 this time
<Noah> Am I the only one having Zakim trouble? Doesn't know the dialin code.
<Stuart> What time is it in Boston?
<Noah> 9 am
blast. I asked for biweeky zakim but on review it looks like they did a one shot
<jar> "please hold for an operator"
I wasn't sure if this should be attributed to the TAG, but I couldn't find "AWWSW." Let me know if it should be attributed to a different group. Otherwise, you're all set.
Tuesday, 13 November
9: 00am-10:00am/ 14:00-15:00 UTC
Zakim Bridge +1.617.761.6200, conference 29979 ("AWWSW")
At 04:19 PM 11/5/2007, Alan Ruttenberg wrote:
This is a request for booking Zakim.
1. Day(s): Tuesday
2. Date(s): 2007-11-13
3. Time: from 09:00 to 10:00 EST (Boston Time)
4. One Time or Recurring. Recurring biweekly
5. Number of participants: 8
6. Name of teleconference group (OR subgroup): AWWSW
7. Preferred conference code (4 or 5 digits): 29979
On behalf of the TAG
scrambling for a freeconference dial in . hang on
<jar> no operator yet.
<Noah> Hmm. From http://www.w3.org/1998/12/bridge/Zakim.html :
<Noah> W3C Zakim Teleconference Bridge Status
<Noah> 2007-03-28T1800Z - The Zakim phone bridge is in service but not with full port capacity.
<jar> did whatever you did enable dialin? can't tell whether to hang on fr operator
<jar> no operator yet.
<jar> on hold
<Stuart> Hummm... alan beat me to it... I sent in:
OK. Shall we use freeconference? It is scheduled for 9:15
<Stuart> Dear Admins,
<Stuart> This is a request for booking Zakim.
<Stuart> 1. Day(s): Tuesday
<Stuart> 2. Date(s): 2007-11-27
<Stuart> 3. Time: 09:00am to 10:33am EST (Boston Time)
<Stuart> 4. Recurring (every 2 weeks)
<Stuart> 5. Number of participants: <12
<Stuart> 6. Name of teleconference group (OR subgroup): AWWSW (affiliate to HCLS and TAG)
<Stuart> 7. Preferred conference code (4 or 5 digits): 29979
<Stuart> I'm sending this request in on behalf of Jonathan Rees who chairs this group.
<Stuart> Many thanks
<Stuart> Stuart Williams
<Stuart> co-chair W3C-TAG
<jar> stuart will have to pay higher rate for freeconference
<jar> still holding for operator
OK. Shall we use freeconference? It is scheduled for 9:15. 1-712-432-2500 x696446
<jar> (sorry, i was trying to think why we shouldn't use freeconference, stuart, are you ok calling a different US number?)
<Noah> So, should I dial that?
<Stuart> though w3c does have a local number in the UK
ok. I am there now
<jar> ok, we'll do it. the 712 number. i'm going there now
Alan is scribe
<dbooth> ScribeNick: alanr
Jonathan: Interested in what stuart has to say
<jar> there's more than just 200 or 303
<Noah> Sorry, could you please (re)paste link to what we're discussing.
Stuart: Wondering how much we feedback we can give the ietf as they own the spec
Stuart: Infer the absolute
minimum in anything from these codes?
... aware that httpRange14 sanctions 200 response => information resources. Heard it questioned whether 303 => rdf response
Noah: Reading both http spec for
303 and for rdf relation seealso. Do they say the same
... Leave each alone. If it works for you does it work both ways?
<dbooth> 2616 doesn't give any machine-processable rules
<Zakim> dbooth, you wanted to say we do not have to limit our inferences to what 2616 says, because we can build upon it for SemWeb arch.
dbooth: don't have to limit to what 2616 says because we can build upon it for SW + we need machine understandable
<Noah> I do think we need to limit ourselves to what 2616 says in a specific sense: that is the normative spec for HTTP. We have to be consistent with it. We can do additional things that are consistent with it.
<dbooth> 2616 doesn't give any RDF, so in some sense whatever we do will be building on top of it.
<Stuart> concur with Noah...
<jar> jar's 3 possible stances: (1) interpret 2616 as rdf, add nothing
<Stuart> I am also troubled by the quantifiers:
<dbooth> i disagree with noah. how could we ever build on anything that way?
<jar> (2) 'best practices' a la awwsw
<jar> (3) layered protocol - give it a name & talk about conformance to layered spec
<Stuart> "for all http applications" or "for all semantic web applications"
<dbooth> there is no sense of contradicting 2616 in RDF, because 2616 does not give an RDF
<Noah> What I just said was:
looks like I'm back
<jar> example of layered protocol: SOAP on HTTP
dbooth: Can't contract 2616 in RDF because 2616 doesn't say anything about rdf
noah: semantics contradict
<Noah> I don't think we can avoid the fact that when we claim that an RDF statement necessarily doesn
<Noah> doesn't conflict with the RDF specification
alan: noah please tell us about interacting with 2616 standardization effort
noah: need to be prepared for lack of interest on 2616 author parts
<Noah> Let's say we made an RDF statement that a status code 200 meant that there was no representation provided. That would clearly contradict RFC 2616. So, we need to admit that when we make any RDF statement about the meaning of, say, 303, we risk contradicting RFC 2616.
alan: look at jonathan's proposal - layered protocol. E.g use a header to say "Member of the SW tribe"
dbooth - means we have to abandon 303?
<Noah> If we're going to, in that sense, rewrite the HTTP RFC, then we need to do it with the cooperation of the community that owns it.
JAR- no. conventions allow us to retrict what 303 means in this context
<Noah> I also said that I had some doubts as to whether key members of the community responsible for 2616 would all view that as a worthwhile exercise.
<dbooth> where is the layered approach described? uri please?
<jar> i'm just kicking the idea around.
stuart: Big protocol. Subgroup says we want to use it in a specific way
x-header: mot + response: 200 => information resource
stuart: Not just external knowledge, like some rdf statements?
jar: Not necessary
alan: Not sure that it is not necessary - how to know given some rdf statement - which URIs have dopplegangers that play by the rules
stuart: what is 2)
jar: following lead of AWWSW
jar 2) says it would be nice if you did this thing
jar 3) you can actually tell if someone is doing it
stuart: for the most part likes
... reason for backing off from inferring from response codes - do for general versus more narrowly for SW applications
jar: is there a difference between sw and non-sw applications? Tim might argue about that
<jar> noah: social issue of who owns the spec
noah: Feelings are close to stuart. But there is a social issue on who can say something about how the protocol works. What do you do when there are conflicts. Who gets to resolve
<jar> option (4) we take a major role in new http spec
noah: who wins 1) Community
believes that this is so important that we will get consensus
on what to go. Don't object on principle. But practically may
be too difficult
... If we decide to layer then we give precedence to what 2616 says. If we contradict then we lose.
Jar: that's what layered means to
... start with HTTP which comes out of one community. Take it as a given and say that's what we're building on, recognizing that it is what it is
<Noah> I was asked my thoughts on the 3 options. My answer is mainly: I think we have to be careful about who owns these specs and how conflicts would be resolved. In principle, one could rewrite 2616 to include RDF normatively, in which case the community owning that spec resolves conflicts. I doubt that will go over well in the short term.
dbooth: One way to view what rdf
inferences can be inferred from rdf. one interpretation is http
interpretation of the the http spec. maybe lossy but we can
... both 2) and 3) sound like layered approaches.
<Noah> Given that we don't do that, then we can build a layered spec, but in that case it's crucial to say up front that in case of conflict, the new spec loses. 2616 is the normative spec for HTTP, and the specification for the RDF embodiment would have to ensure consistency with that.
dbooth: Wary of ietf getting involved.
<jar> http mentions representations
<Stuart> A network data object or service that can be identified by a URI,
<Stuart> as defined in section 3.2. Resources may be available in multiple
<Stuart> representations (e.g. multiple languages, data formats, size, and
<Stuart> resolutions) or vary in other ways.
<Stuart> An entity included with a response that is subject to content
<Stuart> negotiation, as described in section 12. There may exist multiple
<Stuart> representations associated with a particular response status.
<Stuart> both from: http://www.ietf.org/rfc/rfc2616.txt
alan: would need to adopt language of 2616, e.g. entity body and make clear relation to representations
dbooth: take our best guess at what 2616 says and then bounce it off them
jar: Agree - we will need to work here. Interpret what it says.
<Stuart> The information transferred as the payload of a request or
<Stuart> response. An entity consists of metainformation in the form of
<Stuart> entity-header fields and content in the form of an entity-body, as
<Stuart> described in section 7.
noah: elephant in the room. They are not trying to speak with quite the precision we are sometimes
alan: points out resource: A network data object or service, not consistent with a resource can be a person
noah: aimed at people who are trying http clients
alan: This is an example of were we might try to interact
<Stuart> A great may early URI scheme spec use language of the form "URIs from scheme <X> are used to designate things of kind <Y>", which, as a defn, is somewhat open.
noah: On the list of things worth doing, maybe not top.
jar: what is homework for two weeks from now.
tim not on call
<Noah> Please post a link to the "brainstorm page"
stuart: All take review pass over brainstorm page and mail responses
alan: Could spend time on 2616 trying to gather important bits of definitions
stuart: good paper on entities.
<scribe> ACTION: Stuart to send us a link [recorded in http://www.w3.org/2007/11/27-awwsw-minutes.html#action01]
<trackbot-ng> Created ACTION-1 - Send us a link [on Stuart Williams - due 2007-12-04].
<dbooth> dbooth: In what way is TimBL's ontology http://www.w3.org/2006/gen/ont insufficient? What else does it need?
<jar> jeff mogul hawaii
Jar: Don't believe that http://www.w3.org/2006/gen/ont is the real thing. Thinks tabulator has more. What was sent out was unsatisfying
dbooth: what's wrong with it
jar: doesn't talk about requests, responses, essences etc.
alan: started to rework this in owl and some issues have come up already
jar, dbooth: Alan should bring what he is comfortable on.
<dbooth> I thnk we should start putting RDF on the table to discuss.
try again in two weeks. We will end now
<Noah> I've dropped off. Please send email outlining any followup plans. Thank you.
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/someone/stuart/ Found ScribeNick: alanr Inferring Scribes: alanr WARNING: No "Topic:" lines found. Present: Jonathan Noah Stuart DBooth Alan Got date from IRC log name: 27 Nov 2007 Guessing minutes URL: http://www.w3.org/2007/11/27-awwsw-minutes.html People with action items: stuart WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]