Chatlog 2010-04-29

From RDFa Working Group Wiki
Jump to: navigation, search

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

13:42:54 <RRSAgent> RRSAgent has joined #rdfa
13:42:54 <RRSAgent> logging to
13:42:55 <trackbot> trackbot has joined #rdfa
13:43:01 <manu> trackbot, start meeting
13:43:03 <trackbot> RRSAgent, make logs world
13:43:05 <trackbot> Zakim, this will be 7332
13:43:05 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 17 minutes
13:43:06 <trackbot> Meeting: RDFa Working Group Teleconference
13:43:06 <trackbot> Date: 29 April 2010
13:44:20 <manu> Agenda:
13:44:22 <manu> Regrets: Knud, BenA, Markus, Ivan
13:44:49 <manu> Present: Benjamin, Manu, MarkB, Steven, Shane, Toby
13:44:57 <manu> Chair: Manu
13:48:20 <dongmei> dongmei has joined #rdfa
13:53:37 <Steven> Steven has joined #rdfa
13:57:58 <ShaneM> ShaneM has joined #rdfa
13:59:20 <Zakim> SW_RDFa()10:00AM has now started
13:59:27 <Zakim> +Benjamin
14:00:10 <Zakim> +[MIT528]
14:00:31 <Zakim> +??P13
14:00:34 <manu> zakim, I am ??P13
14:00:34 <Zakim> +manu; got it
14:00:37 <tinkster> tinkster has joined #rdfa
14:01:23 <Zakim> +Toby
14:01:51 <Steven> zakim, dial steven-617
14:01:51 <Zakim> ok, Steven; the call is being made
14:01:55 <Zakim> +Steven
14:02:18 <Zakim> +ShaneM
14:03:21 <markbirbeck> zakim, code?
14:03:21 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), markbirbeck
14:03:59 <Zakim> + +0208761aaaa
14:04:06 <markbirbeck> zakim, i am aaaa
14:04:06 <Zakim> +markbirbeck; got it
14:05:07 <ShaneM> Scribe: ShaneM
14:05:15 <tinkster> zakim, mute me
14:05:15 <Zakim> sorry, tinkster, I do not know which phone connection belongs to you
14:05:23 <tinkster> zakim, who's here
14:05:23 <Zakim> tinkster, you need to end that query with '?'
14:05:29 <tinkster> zakim, who's here?
14:05:29 <Zakim> On the phone I see Benjamin, [MIT528] (muted), manu, Toby, Steven, ShaneM, markbirbeck
14:05:31 <Zakim> On IRC I see tinkster, ShaneM, Steven, dongmei, trackbot, RRSAgent, Zakim, manu, Benjamin, markbirbeck, kennyluck
14:05:38 <tinkster> zakim, i am Toby
14:05:38 <Zakim> ok, tinkster, I now associate you with Toby
14:05:46 <tinkster> zakim, mute me
14:05:46 <Zakim> Toby should now be muted
14:05:55 <ShaneM> Topic: RDFa DOM API Review
14:06:31 <ShaneM> manu: Thanks to Benjamin on all the hard work!  We might not all agree with everything, but we have a solid basis to discuss.
14:08:02 <manu>
14:08:07 <ShaneM> Benjamin: Quick update on what has changed in the last week.
14:09:09 <ShaneM> ... not many technical changes.  Renamed RDFAObject is now called RDFaProjection.  URIs are now called IRIs.
14:09:23 <ShaneM> s/RDFAObject/RDFaObject/
14:10:13 <ShaneM> ... decided to stringify triples in N3.  Stringify IRI and blankNodes as text to ease comparisons.
14:10:17 <tinkster> N-Triples syntax right? Because N3 is something else.
14:11:02 <ShaneM> s/triples in N3/triples in N-Triples notation/
14:11:29 <Steven> good catch toby
14:12:11 <ShaneM> manu: Made some editorial changes to reorganize the document a little.  Introduce concepts first, then base objects, then higher level objects, then the API itself.
14:13:23 <manu> shane: I made a spin through the document looking at technical issues first.
14:13:34 <tinkster> q+ triples versus statements
14:13:39 <manu> Shane: I raised a number of points on the mailing list, Manu updated the document to address those concerns.
14:13:46 <tinkster> q+ to ask about triples vs statements
14:14:19 <manu> Shane: The second review I did was more editorial in nature, the document reads better now.
14:14:36 <manu> Shane: I like the new organization changes, in general, I think the language reads well.
14:14:57 <manu> Shane: At the end of the day, we want to make sure the technical parts of it are useful.
14:15:05 <manu> ack toby
14:15:06 <tinkster> zakim, unmute me
14:15:06 <Zakim> Toby, you wanted to ask about triples vs statements
14:15:09 <Zakim> Toby was not muted, tinkster
14:15:41 <ShaneM> Toby: A lot of the the interfaces use the term 'triple' and that is a bit jargon-y.  Better to call it RDFstatement or something.
14:15:55 <tinkster> zakim, mute me
14:15:55 <Zakim> Toby should now be muted
14:16:01 <ShaneM> manu: Shane had raised that it was superfluous to prefix things with 'RDF' at all.
14:16:05 <tinkster> no
14:16:15 <tinkster> zakim, unmute me
14:16:15 <Zakim> Toby should no longer be muted
14:16:28 <tinkster> zakim, mute me
14:16:28 <Zakim> Toby should now be muted
14:16:38 <ShaneM> manu: Does Toby need this changed before FPWD?  He says no.
14:17:02 <ShaneM> manu: Knut had also sent in a review, and most of them have been addressed.  
14:17:22 <ShaneM> ... might want to do examples differently.  Might want to show some HTML markup and then show API calls that would extract from it.
14:17:32 <ShaneM> ... Have not made these changes yet, but its a great idea.
14:18:29 <ShaneM> ... suggested some other things too.  Has indicated he is fine with going to FPWD without the changes integrated.
14:18:47 <ShaneM> ... Mark has some issues too.
14:19:20 <ShaneM> Topic: Should RDFa DOM API be published as FPWD?
14:20:10 <ShaneM> markbirbeck: The root object and where it sits is a big issue.  Toby raised this.
14:20:45 <manu> other APIs that float in the ether: Database API, WebWorkers
14:20:53 <ShaneM> ... Traditionally W3C specs have attached new things to the document object or to nodes within the document.
14:22:18 <ShaneM> ... even if you argue that the rdfa object should be free floating (equivalent to XMLHTTPRequest), the new objects that we have created should still be within the rdfa object, not on their own as well.
14:22:29 <ShaneM> ... Things like IRI, PlainLiteral, TypedLiteral
14:24:10 <manu> q+ to discuss next steps after RDFa DOM API
14:24:20 <manu> (FPWD that is)
14:24:37 <ShaneM> markbirbeck: What is the status of an FPWD?
14:25:00 <ShaneM> Steven: The status is that it is currently agreed, but anything and everything can change in any working draft at any time.
14:25:27 <ShaneM> ... We should agree as a group that existing implementations must not influence future changes to the spec.
14:25:46 <manu> ack manu
14:25:46 <Zakim> manu, you wanted to discuss next steps after RDFa DOM API
14:25:49 <ShaneM> ... We should not be scared off by the idea that people might implement it.
14:26:07 <ShaneM> markbirbeck: Actually I am more worried about the impression it gives than about whether it gets implemented.
14:26:33 <ShaneM> manu: We have asked groups for input, and they have said they will do that once there is a draft.  So we need something out there so we can get feedback.
14:26:54 <ShaneM> ... if someone starts blogging and there is negative feedback, that's still okay.  Feedback is important.
14:27:06 <ShaneM> ... we shouldn't use this as a reason to not publish a draft.  
14:27:42 <ShaneM> ... Web Apps working group, for example.  A review from them is important.
14:28:26 <ShaneM> markbirbeck: The underlying question is 'why are we pushing this now?  why one week vs another week?'
14:29:16 <ShaneM> manu: the reason it is now instead of later is because of the timeline we have.  We have lots of things we need to get to, and we are already late.  Two weeks ago the document didn't hang together.  Now it is more solid.
14:29:53 <ShaneM> ... we need to start working on the RDFa Primer.  There is an issue queue.  If we don't get on with churning through the queue then we are in danger of slipping the rest of our schedule.
14:30:26 <ShaneM> ... It might be better to have an FPWD and get issues against it to drive future discussion and evolution of the spec.
14:31:27 <ShaneM> markbirbeck: Concerned that the spec hasn't really thought about the DOM and the browser.  bent over backwards to make the spec language independent.  Not sure what the use case is for something that is not browser / DOM centric.
14:34:24 <ShaneM> manu: The current API spec is targeted at extracting triples from RDFa documents.
14:35:23 <ShaneM> markbirbeck: Thinks the goal is to manipulate the DOM based upon the information that is marked up in RDFa.
14:35:34 <ShaneM> ... you want to reduce the distance between the DOM and the action.
14:35:49 <manu>
14:36:22 <ShaneM> ... the examples are all done from the command line.  What does that have to do with the interesting use case?
14:36:27 <Benjamin> q+ to speak about retrieving DOM nodes in the RDFa DOM API
14:36:47 <ShaneM> ... we have a mindset that keeps it generic, but that perspective is coloring the whole design.
14:37:46 <manu> ack benjamin
14:37:46 <Zakim> Benjamin, you wanted to speak about retrieving DOM nodes in the RDFa DOM API
14:37:51 <ShaneM> ... the discussion of hanging this on the document object on the mailing list got a response from Manu that this couldn't be done in other languages.
14:37:55 <Benjamin>
14:38:19 <manu> q+ to address Mark's concerns about DOM element tie-ins.
14:38:34 <markbirbeck> q+
14:38:34 <manu> ack manu
14:38:35 <Zakim> manu, you wanted to address Mark's concerns about DOM element tie-ins.
14:38:41 <ShaneM> Benjamin: Thinks we have addressed many of the topics. There are easy ways in the API to get the Nodes with specific characteristics.
14:39:32 <ShaneM> manu: A lot of the API spec addresses the use cases that were raised.  Unfortunately, we don't have good examples right now.  But we are not completely ignoring the DOM.  Every single literal or subject or predicate that comes back is tied into the DOM Nodes.
14:41:56 <manu> q+ to discuss solid proposals.
14:41:58 <ShaneM> markbirbeck: the spec does a good job of pursuing its goal.  I just think the goal is wrong.  The API is so RDF oriented that people who are not RDF experts are going to have trouble doing the things that are going to be most wanted (e.g., find all the nodes that have a specific type, then make changes to those nodes).
14:42:30 <ShaneM> ... the API we have is very generic.  We need more specifics.  And the things that are interesting should be right at the top.
14:42:55 <Benjamin> q+ to reply on this 
14:43:07 <manu> ack markbirbeck
14:44:18 <manu> ack manu
14:44:18 <Zakim> manu, you wanted to discuss solid proposals.
14:44:37 <ShaneM> manu: I might agree in general.  But I don't understand what we can do specifically to address your concerns.  There might be organizational changes.  There might be examples that could improve things?  But what are those?  We need a solid proposal.
14:45:03 <ShaneM> markbirbeck: Agrees the onus is on me to make a solid proposal.  Have been busy but have some cycles finally.  
14:46:12 <ShaneM> ... one possibility is a completely different spec.  Another is that some additional methods toward the top that can do specific things to the DOM.  Put the at the top for the common use cases.  Keep the detailed generic API as 'advanced operations'.
14:46:20 <manu> ack benjamin
14:46:20 <Zakim> Benjamin, you wanted to reply on this
14:46:45 <manu> q+ to move towards a straw-poll.
14:46:59 <Benjamin> look at
14:47:26 <ShaneM> Benjamin: use cases.  At  the beginning of the work there was a request for use cases.  Those use cases were 'get triples out' and 'extract dom nodes via filters'.  Those are important, and I really like the second one.  The current spec supports these use cases.
14:48:38 <ShaneM> ... it is easy to say 'give me all the nodes where X or Y'.  Yes the API is RDF centric, but it is flexible and you can filter on any criteria - even complex criteria.
14:49:13 <ShaneM> markbirbeck: can you find everyone who has a twitter account and get their twitter account name?
14:49:22 <ShaneM> Benjamin: I am not sure what the path expressions are?
14:50:22 <ShaneM> manu: Yes, it is possible.  It could be made easier with convenience functions.  But the core functionality  is already there though.  You do it with a filter function that remembers state.  You examine the triples and only return triples that match your criteria. 
14:50:53 <ShaneM> markbirbeck: you call the filter function repeatedly?
14:51:31 <markbirbeck> s/filter function/getElements function/
14:52:21 <ShaneM> manu: no...  the filter function is called by the RDFa DOM API repeatedly.  You don't call it.  You could do something more complicated too.  Only give me twitter account names for people who have twitter accounts and are also at the W3C.  Could do it in 2 passes.  Or you could have a state object that remembers things that match.
14:53:03 <ShaneM> manu: It isn't easy - certainly not as easy as Mark wants it to be.  Adding some content at the top of the document with convenience functions might help make that easier.
14:55:20 <ShaneM> markbirbeck: The key is that it should be easy.  The problem is that the API is too RDF-centric.  If we publish this we could lose some good will.  I would like to see the convenience functions, better examples, HTML fragments, use of opengraph protocol.  Come out with guns blazing.
14:55:31 <tinkster> I have to go now. I agree with a lot of Mark's views, but I think we should go ahead with FPWD. I'll post a message to the list with some examples of how I think the API should work in an ideal world.
14:55:36 <Zakim> -Toby
14:57:31 <ShaneM> Steven: If we are worried we should make it clear what we are doing and how it is likely to change right at the top.
14:58:12 <manu> Shane: I do have a comment - you often raise the issue what people are going to write or what they are going to say.
14:58:58 <manu> Shane: At the end of the day, I don't understand what it affects - we are chartered to do this, we're doing it - why do we have to be affected by every single blogger out there?
14:59:18 <ShaneM> markbirbeck: That's not the concern.  The concern is what people are going to write.  We need to look like we are relevant and addressing current use of semantics on the web.
15:00:02 <ShaneM> markbirbeck: people need to get the right impression about what we are doing.  this isn't insurmountable, and people's impressions are important.
15:00:44 <ShaneM> manu: I think this is a false argument.  You assume there will be bad things said but we don't know that.  We don't have any feedback so we don't know what people want.
15:02:36 <ShaneM> ... this is creating a false choice.  We all want this to be successful.  We recognize that you (mark) disagree with how the current document is structured.  Can you live with the document going out and getting feedback, then updating.  Or do you completely object to it going out at all.
15:03:56 <ShaneM> markbirbeck: It's not about polish.  Its about direction.  I want a week to help get this right.
15:04:54 <ShaneM> manu: Let's take a straw poll as to whether the document should go to FPWD as is.

15:05:22 <ShaneM> Toby, Ivan, and Knut have said it is okay to go FPWD prior to or during the call.
15:06:02 <manu> PROPOSAL: We publish the RDFa DOM API FPWD as is under the short name rdfa-dom-api on May 6th 2010.
15:06:09 <manu> +1
15:06:10 <Steven> +0
15:06:12 <markbirbeck> -1
15:06:17 <Steven> I can live with either way
15:06:18 <ShaneM> Shane: -1 - give mark the week.
15:06:18 <Benjamin> +1
15:06:28 <Steven> we're  a public group, so
15:07:13 <ShaneM> manu: based upon this we should delay a week.  Mark, what can you do in a week?
15:07:18 <Steven> you can see our FPWD anyway
15:07:41 <ShaneM> markbirbeck: I will write up a proposal for my changes.  a new section and other changes.  
15:08:00 <Steven> Regrets for two weeks from me (vacation and W3C workshop)
15:08:02 <ShaneM> manu: We need something to review and discuss onlne by next Monday.  Exact spec language, please.
15:08:39 <Zakim> -markbirbeck
15:08:40 <Zakim> -manu
15:08:41 <Zakim> -[MIT528]
15:08:42 <Zakim> -Steven
15:08:44 <Zakim> -Benjamin
15:09:00 <markbirbeck> thanks the group...and promises he will not have the nerve to ask for any further delays. :)
15:09:18 <manu> looking forward to your changes :)
15:13:44 <Zakim> disconnecting the lone participant, ShaneM, in SW_RDFa()10:00AM
15:13:47 <Zakim> SW_RDFa()10:00AM has ended
15:13:48 <Zakim> Attendees were Benjamin, [MIT528], manu, Toby, Steven, ShaneM, +0208761aaaa, markbirbeck
15:49:11 <ShaneM> ShaneM has joined #rdfa