Chatlog 2010-09-16

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

13:53:51 <RRSAgent> RRSAgent has joined #rdfa
13:53:51 <RRSAgent> logging to http://www.w3.org/2010/09/16-rdfa-irc
13:53:53 <trackbot> RRSAgent, make logs world
13:53:53 <Zakim> Zakim has joined #rdfa
13:53:55 <trackbot> Zakim, this will be 7332
13:53:55 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 7 minutes
13:53:56 <trackbot> Meeting: RDFa Working Group Teleconference
13:53:56 <trackbot> Date: 16 September 2010
13:53:59 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Sep/0081.html
13:54:02 <manu1> Chair: Manu
13:54:14 <manu1> Present: Steven, Manu, Toby, MarkB, Knud, Shane
13:56:42 <manu1> Regrets: Ivan, Benjamin
13:56:42 <manu1> scribenick: Knud
13:57:41 <markbirbeck> markbirbeck has joined #rdfa
13:58:11 <markbirbeck> zakim, codes?
13:58:11 <Zakim> I don't understand your question, markbirbeck.
13:58:13 <tinkster> tinkster has joined #rdfa
13:58:17 <markbirbeck> zakim, code?
13:58:18 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), markbirbeck
13:59:02 <Knud> Knud has joined #rdfa
14:00:24 <Zakim> SW_RDFa()10:00AM has now started
14:00:32 <Zakim> +??P27
14:00:40 <manu1> zakim, I am ??P27
14:00:40 <Zakim> +manu1; got it
14:01:58 <Steven> zakim, dial steven-617
14:01:58 <Zakim> ok, Steven; the call is being made
14:01:59 <Zakim> +Steven
14:03:30 <Zakim> +Knud
14:03:32 <Knud> zakim, mute me
14:03:45 <Zakim> Knud should now be muted
14:04:19 <Zakim> +ShaneM
14:04:21 <ShaneM> ShaneM has joined #rdfa
14:08:23 <Zakim> +??P2
14:08:31 <markbirbeck> zakim, i am ?
14:08:31 <Zakim> +markbirbeck; got it
14:09:11 <Knud> TOPIC: RDFa API Heartbeat publication
14:09:28 <manu1> http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/
14:10:00 <Knud> manu: this version includes all of Ivan's comments, incl. two class diagrams
14:10:15 <manu1> http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/#the-rdf-interfaces
14:10:31 <manu1> http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/#the-linked-data-interfaces
14:11:07 <Knud> ... still not 100% perfect, need to be adapted
14:11:12 <markbirbeck> q+
14:11:58 <manu1> ack mark
14:12:06 <Knud> ... diff still needs to be created
14:12:17 <Knud> mark: document looks pretty good!
14:12:56 <Knud> manu: for certain things, there are still issue markers in the document
14:14:04 <manu1> PROPOSAL: Publish the latest RDFa API draft as a heartbeat draft, adding diff-marked version: http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/
14:14:14 <manu1> +1
14:14:14 <markbirbeck> +1
14:14:17 <Knud> Knud: +1
14:14:19 <tinkster> +1
14:14:32 <ShaneM> +1
14:14:35 <Steven> +1
14:14:38 <Knud> (Ivan and Benjamin gave their approval for publication in W3C-archived team e-mail and public RDFa WG mailing list, respectively)
14:14:50 <manu1> RESOLVED: Publish the latest RDFa draft as a heartbeat draft, adding diff-marked version: http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/
14:15:12 <Knud> TOPIC: Signal RDF/SemWeb/Linked Data of RDFa Heartbeat publication
14:16:18 <Knud> manu: we need to involve the RDF community into the RDFa API, because they feel we are in fact creating an RDF API
14:17:07 <Knud> ... groups to contact: SWIG, RDF-Core, browser vendors, ...
14:17:44 <markbirbeck> q+
14:17:48 <Knud> ... LOD community
14:18:33 <tinkster> webapps wg!
14:19:46 <Knud> steven: possible problem: our charter doesn't ask us to do anything more general than an RDFa API
14:20:25 <manu1> ack mark
14:21:30 <Knud> mark: see last call, Ivan: changing the name should be discussed internally
14:22:19 <Knud> ... publish heartbeat first, then carefully find out what the community thinks: is the general nature of our API a problem?
14:22:54 <Knud> ... if we get pushback, we might think about what we could remove from the API
14:23:24 <Knud> ... we have a good architecture in place, now we can possible factor out some things
14:23:30 <manu1> q+ to discuss extending the charter re: RDFa API
14:23:40 <Knud> ... we should leave as is for now
14:23:41 <manu1> ack
14:24:05 <Knud> manu: extending the charter is possible, but probably the last thing we want to do
14:24:22 <markbirbeck> q+
14:24:37 <manu1> ack
14:24:39 <manu1> ack 
14:24:42 <Knud> ... we have a good story about integrating things like microdata, etc.
14:24:44 <manu1> ack manu1
14:24:44 <Zakim> manu1, you wanted to discuss extending the charter re: RDFa API
14:24:48 <manu1> ack markbirbeck
14:24:52 <Knud> ... so maybe we _do_ want to change the charter?
14:25:04 <Knud> mark: maybe we should let the community ask us to do this?
14:25:50 <Knud> ... then we would have a discussion, and a good argument for changing the charter
14:27:49 <Knud> manu: judging from respnse to sandro h's questionnaire, there is a lot of interest in where RDF goes next
14:28:11 <Knud> ... but there wasn't a question on an RDF API, so we don't know how much desire there is for one yet?
14:28:56 <Knud> ... anyway, we should start getting a lot of feedback for the RDFa API
14:29:27 <Knud> TOPIC: Processing remote documents via RDFa API
14:29:37 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/44
14:30:13 <Knud> manu: concern is: how do we make sure the API can process triples from external/remote documents
14:30:37 <Knud> ... security issues
14:31:52 <Knud> ... CORS might solve this in the future
14:32:07 <Knud> (http://www.w3.org/TR/cors/)
14:32:46 <Knud> ... this discussion is important e.g. for getting RDFa profile document
14:35:32 <markbirbeck> q+
14:35:38 <manu1> ack mark
14:35:57 <Knud> ... we could be bold and suggest a special kind of communication policy for fetching RDFa documents
14:36:33 <Knud> mark: maybe suport some other formats
14:36:55 <Knud> ... don't think security is our concern (at the spec level)
14:37:10 <Knud> ... don't talk about http requests, cookies, CORS, etc. at the spec level
14:37:14 <manu1> q+ to discuss CORS vs. no cookies.
14:38:51 <Knud> ... we could move away from expressing profiles in RDFa and then use a policy such as for iframes, css, etc.
14:39:28 <ShaneM> I agree with Mark - rely upon other specs.
14:39:38 <manu1> ack manu1
14:39:38 <Zakim> manu1, you wanted to discuss CORS vs. no cookies.
14:39:56 <ShaneM> but I wouldn't object to an implementors guide
14:40:11 <Knud> manu: I don't think there is any particular other spec we can rely on for the cookie problem
14:40:48 <Knud> ... what makes RDFa unique is that currently, there isn't a whole lot of RDFa out there
14:41:28 <Knud> ... this gives us the opportunity to start from a blank slate. We can establish policies, best practices.
14:41:45 <markbirbeck> q+
14:42:00 <ShaneM> q+ to ask why this is more serious for us?
14:42:35 <manu1> ack mark
14:44:14 <manu1> q+ to discuss creating a wall for the developer
14:44:32 <manu1> ack shanem
14:44:32 <Zakim> ShaneM, you wanted to ask why this is more serious for us?
14:45:34 <Knud> shanem: it might be good to provide implementation guidance as non-normative text ...
14:45:54 <Knud> ... but be probably can really defer this to other specs
14:45:56 <manu1> ack manu
14:45:56 <Zakim> manu1, you wanted to discuss creating a wall for the developer
14:46:17 <Knud> ... yes, we have an opportunity here, but I don't want one. I don't see why.
14:46:21 <markbirbeck> agree with ShaneM
14:47:44 <Knud> manu: if the developer were to fetch a remote documents, they would not have access to that complete document, but only to the extracted triples
14:49:45 <manu1> q+ to say that we can "violate" the security model.
14:50:06 <Knud> mark: but we have to rely on xml-http request anyway - we can't add any other ways of accessing documents
14:50:21 <manu1> ack manu1
14:50:21 <Zakim> manu1, you wanted to say that we can "violate" the security model.
14:50:24 <Knud> ... we have to build on the existing stack, which has its own rules, which we inherit
14:51:30 <ShaneM> q+ to talk about data in RDFa
14:51:36 <markbirbeck> q+
14:51:42 <manu1> ack shane
14:51:42 <Zakim> ShaneM, you wanted to talk about data in RDFa
14:51:47 <Knud> manu: again: we might be in the position to actually establish a _new_ security model for RDFa, which could be different than for HTML pages
14:51:53 <tinkster> For in-browser JS implementations, we have to build on XHR, so must inherit its limitations. For native browser implementations, and non-browser implementations, we needn't inherit those limitations.
14:52:50 <manu1> ack mark
14:52:56 <Knud> mark: this sounds a bit naive. Just because the data is in RDFa, it doesn't mean it's not sensitive!
14:53:06 <Knud> s/mark/shanem
14:53:18 <ShaneM> I agree with tinkster - but I think that means we need to appreciate the limitations of the minimum.
14:53:50 <manu1> q+ to disagree that it's not desirable.
14:54:51 <Knud> mark: we don't need to discuss CORS, cookies, etc. We just need to rely on the security stack in the browser.
14:54:56 <ShaneM> I agree with mark on this.  native browser implementations should adhere to the stack just like a JS implementation would.
14:54:57 <manu1> ack manu
14:54:57 <Zakim> manu1, you wanted to disagree that it's not desirable.
14:56:04 <markbirbeck> q+
14:56:37 <markbirbeck> Definitely agree with that.
14:56:58 <manu1> ack mark
14:57:11 <Knud> manu: maybe get some browser implementers input to see what they think
14:57:51 <manu1> q+ to discuss research at our company on bypassing CORS.
14:58:34 <Knud> mark: yes, getting things from other places (remote documents) is desirable. Something has to be done about it. But probably not in our spec.
14:59:21 <Knud> shanem: "What, does the Semantic Web require a Web?!"
15:02:29 <manu1> ack manu1
15:02:29 <Zakim> manu1, you wanted to discuss research at our company on bypassing CORS.
15:02:36 <manu1> q+ to end the telecon
15:04:00 <manu1> PROPOSAL: RDFa API heartbeat draft to be published next Thursday (2010-09-23).
15:04:08 <Knud> Knud: +1
15:04:09 <markbirbeck> +1
15:04:11 <manu1> +1
15:04:13 <ShaneM> +1
15:04:40 <manu1> RESOLVED: RDFa API heartbeat draft to be published next Thursday (2010-09-23).
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000168