Draft minutes for TAG telcon of 2011-06-16

Hash: SHA1

are now available at


and in text form below.

- ----------------
                                   - DRAFT -

                                  TAG telcon

                                  16 Jun 2011


   See also: [3]IRC log


          Dan Appelquist, Tim Berners-Lee, Ivan Herman, Yves Lafon, Peter
          Linss, Ashok Malhotra, Larry Masinter, Noah Mendelsohn,
          Jonathan Rees, Manu Sporny, Jeni Tennison, Henry S. Thompson,
          Thomas Roessler

          Noah Mendelsohn

          Henry S. Thompson, Manu Sporny


     * [4]Topics
         1. [5]Admin
         2. [6]ISSUE-35 -- Microdata/RDFa relationship


   Regrets for 23 June: Larry Masinter

   Scribe for 23 June: Peter Linss

   NM: Minutes from f2f are OK as far as substantive stuff, but have
   clerical errors
   ... Happy for Jeni to go ahead with her blog post
   ... But lets hold off publishing the minutes until scribes can do some
   link checking
   ... PL, are you OK with the planned f2f dates/locs?

   PL: Modulo travel restrictions, about which I am hopeful, those are
   all fine
   ... I will be at TPAC

ISSUE-35 -- Microdata/RDFa relationship

   NM: There has been some public fuss about the fact that JT's post is
   ... That's what we asked for, and it was entirely appropriate
   ... I hope to move to public discussion as soon as possible
   ... This session is for the TAG to decide what to say going forward
   ... So to our guests, please focus on keeping us correct on the facts
   ... You'll have your chance to disagree with our conclusions in public
   ... JT proposes that the TAG host a Task Force
   ... I want to be sure that if we do it, we can do it well

   <Larry> think we should ignore noise about 'member-only', our results
   are public, but every group has member-only conversations

   NM: JT notes an incompatibility between steps 1 and 4 in [one of the
   ... There's a bit of wording many of us are unhappy with, which we
   should either agree to or remove: "irresponsible"
   ... Floor is open

   <Larry> Who is responsible for doing something that they haven't done?

   MS: Overall JT's summary is accurate, and very helpful
   ... I personally don't think the RDFa community will have much to
   disagree with
   ... 5 points I want to make wrt the way forward:
   ... 1) Having two syntaxes is leading to developer confusion;
   ... 2) Big table required for any t-f -- at least microformats,
   microdata, RDFa, MSoft, Yahoo!, Google;
   3) Any proposal for actual technical changes has to have buy-in from
   all the communities;
   4) With hindsight, it was a mistake for W3C to allow two competing
   specifications in nearly the same space;
   5) W3C should push hard to get these communities to work together.

   MS: Not sure how W3C can do that, but it really needs to be done

   <ivan> note: if google, microsoft and yahoo, we may want facebook, too

   <jar> not comfortable with 'rdfa community' or 'microdata community'

   <noah> Thanks Ivan, good point. We'll have to do some thinking and
   iteration on who participates >if< there is a task force, but
   certainly the goal would be representation from an appropriate cross
   section of those concerned.

   <ivan> turtle and rdf/xml are wrong analogies

   <JeniT> CSS and XSL are better analogies

   NM: We intend to get input from microformat and microdata concerns
   into this TAG process ASAP

   <manu> My points:

   <manu> * Having two syntaxes that do almost the same thing is leading
   to developer confusion for a variety of reasons

   <manu> * Task Force must include people from Microformats, Microdata,
   RDFa, Best Buy, UK Govt, Data.gov, Google, Microsoft and Yahoo

   <manu> * Ensure that before technical changes are made, that there is
   an agreement on the exact technical issues and commitment to use the
   newly changed spec

   <manu> * Hindsight being 20/20 - it was a mistake to signal that W3C
   would allow two competing specifications that do almost exactly the
   same thing.

   <manu> * W3C must push the communities to work together.

   <manu> This is my personal opinion - not the opinion of any

   <noah> Right -- I welcome the comments from Manu, but this is not the
   meeting where I'm looking for detailed positions form either those
   involved with RDFa or microdata. I expect to reach that point within a
   day or so, but the goal here is to for the TAG to develop its initial
   position, and for us to ask our guests to help us catch factual errors
   as we do that.

   JT: I would suggest that any task-force should be time-boxed -- say
   "You only have two months" would be a way of making sure it didn't
   take up too much of everyone's time

   JAR: In framing this, I'm uncomfortable with talking about "RDFa
   community" or "microdata community" -- in general people have been
   talking about "structured data", which is a common goal

   <Larry> i agree with Jonathan that the separation into 'communities'
   is dangerous

   <Larry> +1

   <manu> I agree that language shouldn't be used to create divisions.

   <Larry> at the end of the day there is one web and one community, and
   there are some camps that may have developed some technology

   JAR: Maybe some people are "invested" in particular approaches, but we
   should do our best to avoid exacerbating perceptions of antagonism

   <manu> Also, don't forget about the Microformats community - I've been
   working with them for many years.

   <manu> [7]http://manu.sporny.org/2011/microformats-2/

   <manu> (link to: Microformats 2 and RDFa collaboration)

   <noah> Thanks, Manu. My apologies for not having been more informed
   about your earlier work.

   <jar> i'm more comfortable with "those who are invested in rdfa" or in
   microformats... since that's factual

   LM: One community, one web -- currently different approaches, purpose
   of task force is to bring the community to work on their joint problem

   <noah> Discussing Jeni's note at:

   NM: JT, please take us through the document

   <Larry> paragraph 1: I think the problem isn't as much that there are
   two different approaches but also that they seem to be incompatible,
   and that if you choose one you can't convert to the other. So the
   emphasis is on *incompatible*

   TBL: Let's make this as quick as we can

   <manu> Do I need to re-hash feedback I sent to the TAG?

   JT: Para 1 is a summary

   LM: Having two ways to do something isn't unusually, so our emphasis
   should be on the incompatibility

   LM: In particular, there is currently no demonstration of
   ... No discussion of workflows from one to the other, for people who
   want to change
   ... That suggests that there is no such flow

   <Larry> you could argue that SVG and Canvas are also overlapping

   TBL: I disagree with the point -- sometimes overlap is OK, but in this
   case there is only loss from not integrating them

   <Larry> how is this different from having both SVG and Canvas?

   TBL: It's like having ; as an alternative to : in HTTP headers

   NM: I prefer a change to the wording: s/W3C should not publish/there
   are drawbacks to publishing/

   HST, TBL, AM: prefer the stronger wording

   NM: But there is already substantial deployment. . .

   TBL: I think we can get agreement on a unified approach

   JT: I can hear what you are saying, as giving the Task Force space to
   come up with their own solution

   NM: But I hear considerable opposition, so I'll drop this

   LM: Why aren't we making the same argument about SVG and <canvas> ?
   ... Obvious parallel, SVG already deployed, considerable overlap

   TBL: I think that doesn't go through, there is real difference in

   LM: It's the failure to work through the impact of the two competing
   specs that I'm complaining about

   TBL: This is simpler than that
   ... These two specs are using similar-but-different mechanisms to get
   to the same place

   <manu> These are the core differences between Microdata and RDFa:

   <manu> 1. No prefix-based indirection (remove CURIEs)

   <manu> 2. Tree model is better than Graph model (key-value over RDF)

   <manu> 3. Datatyping is not required (remove @datatype)

   <manu> 4. URLs for properties are overkill

   <manu> (that is from the Microdata perspective)

   JT: We shouldn't focus on the solution -- that's for the Task Force
   ... We need to frame the problem, so others can take the time that's
   needed to solve it

   NM: Do you have what you need for Para 1, JT?

   JT: Yes

   <Larry> the task force should include those who produce metadata and
   those who consume it to work through the workflows

   <manu> My thoughts on the opening prose are here:

   <ivan> I had some private technical discussion with Jeni on some of
   the issues, I do not think it is worth repeating them here

   TBL: We can't create a task force, we can suggest its creation

   NM: I'm not happy to suggest a task force unless one of us is willing
   to run it

   TBL: I think we can expect W3C staff to find people to be on it and
   chair it

   <manu> I agree - someone that has no prior involvement in
   Microformats, RDFa, Microdata groups be in charge of putting the Task
   Force together and running it.

   NM: I think that needs to be spelled out in the document
   ... So, s/we intend to create/we intend to encourage the W3C to
   create. . ./

   <noah> suggest s/We therefore intend to create a task/We therefore
   encourage the W3C to create a task/

   JT: Done

   <Larry> we want there to be consensus that two methods are needed

   <manu> +1 to Larry - that is a very good approach

   <Larry> W3C is a consensus organization. You can have competing
   technology and agree that you need both, but that hasn't happened

   HT: Several people have commented on the use of the word
   "irresponsible". It's not accusing other people, we're saying the TAG
   would be irresponsible.
   ... What I would change is the last sentence before the
   bullets....where it says "irresponsible for the TAG to let". That's
   not up to us.
   ... What would be irresponsible is for us not to attempt

   JT: So add "without comment"

   <manu> +1 to "better reconcile/unify" language.

   NM: No, more like "we have to help"

   JAR: Not obvious that the Task Force is the right solution
   ... So I wanted to work on a statement of the ideas first, before we
   consider the solution

   <Larry> +1 agrees that the wording should identify the problem we want
   solved first, and noting a task force is one way to insure that the
   problem is solved

   <Zakim> manu, you wanted to claim that separate syntaxes will be

   <timbl> +1

   MS: JT offers a "separate syntax" option. I think two sets of
   attributes will continue to create confusion -- which to use when, can
   you use some of one with some of another, etc.

   <noah> Speaking for myself, I don't think we should rule out solutions
   like keeping both syntaxes is appropriate at this point. A task force
   can consider the pros and cons.

   IH: Well technically speaking, I agree, given the background, allowing
   the Task Force to include this consideration from the beginning is a
   good idea -- let them draw that conclusion

   <JeniT> +1 to Ivan

   TBL: But if they end up with two, I think that would be failure

   <noah> I think the task force needs to the opportunity to determine
   that the requirements (e.g. for simplicity vs. power) may be more
   varied than we would hope.

   TBL: If it has two, that will really be a third, some kind of merger

   <JeniT> Maybe we should not say anything about the scope of the Task

   <Zakim> Larry, you wanted to ask to recast the nature of the
   communities as "those who create metadata" and "those who build tools
   that process metadata" and "those who consume metadata"

   IH: I think we can't stop a representative group from wanting to look
   at the status quo

   LM: We need to be careful about the nature of the problem
   ... Strengthen the problem statement, don't pre-judge the solution
   ... We are a consensus organization -- we evidently don't have
   consensus that we need two mechanisms
   ... nor any effort to establish that we do
   ... The 'communities' I'm referring to are creators, tool builders,

   <jar> lm: There is not consensus that there needs to be two
   mechanisms. We suspect we don't need two. But if there is community
   consensus, then ok.

   TBL: I hear that as a comment about a general problem
   ... but this case is special, and we don't need to allow for the
   general case

   NM: I'm close to LM here
   ... I don't want to pre-judge this
   ... I think we should allow for the possibility that the Task Force
   comes back with an analysis that there isn't so much overlap as we

   <Larry> looking at the documents, that there is no need for two
   competing specifications, and we would need proof that there was such
   a requirement, and the proponents havent' done that. they're just
   proposing competing technologies, without looking for consensus.

   <Larry> Doing that is irresponsible

   NM: So I would suggest we make clear that we expect one solution, and
   anything else should be justified by extensive analysis and use cases

   <Larry> at least with Canvas vs SVG there was some credible arguments

   TBL: The Task Force may fail -- but I don't want them to come back and
   say "We succeeded -- no change is necessary"

   <noah> NM: OK, Tim, I understand you. That makes some sense (which is
   to say I'm somewhat convinced)

   IH: WRT the first bullet point for the TF: based on my own
   implementation experience, these two specs are very clearly
   technically overlapped
   ... so there is little technical justification for two
   ... But I see there may be social reasons for keeping two

   IH: But I want to emphasize that if two syntaxes are kept, they should
   produce the same RDF for the same intent

   <noah> Ivan's point on the same RDF for comparable situations seems
   important to me.

   <noah> Do we have agreement on that?

   <JeniT> Or at least a subset

   <JeniT> it's not practical to say that they should produce exactly the
   same RDF

   <tlr> My $0.02: any conclusion that the tag can help people arrive at
   is the most powerful.

   IH: Moving on to the Task Force -- maybe a Team member to manage the
   basic admin, but whoever actually chairs the Task Force should have no
   association with the recognised contending groups

   <manu> +1 this is not a technical problem at it's core - it's a
   political one.

   IH: I'd go further and at least consider that we not even include
   anyone heavily identified with one of the established approaches

   TBL: Obviously the choice of chair is important, but the TAG can't
   meddle in the details

   <noah> I disagree. We should include experts with roots and expertise
   on all sides. The chair, of course, should have the respect of all as
   being astute and as impartial as possible.

   <Zakim> timbl2, you wanted to support manu's point that we should
   remove th eoption of 2 separate syntaxes.

   <JeniT> noah, experts don't have to be prominent proponents

   IH: I think the TAG can and should say that the Task Force should be
   as independent as possible of the war that brought us to the current

   JT: So where are we wrt the first bullet?

   <timbl> remove

   <JeniT> keep

   <ivan> keep

   <manu> remove (if I get a say)

   HST remove

   <noah> Somewhat toward keeping

   TBL: I'm happy to leave it in as JT was trying to cover the whole

   <plinss> keep

   JT: The other option is removing the entire list of candidate

   NM: I hear that it's not an acceptable final outcome for some here,
   but surely they need to look at it

   <manu> Can you put that in the text: Task Force could discuss it, but
   that end result would be seen as a failure.

   <manu> ?

   HT: I agree with Jeni. Let's remove all that.

   <manu> "A unified way forward for structured data on the Web"?

   <noah> Strawperson proposal. Remove text starting with: "The task
   force will..." and continuing to BACKGROUND

   TBL: Giving examples makes the document clear
   ... Moving to the meta-level will just obscure things
   ... You could try to define the scope philosophically
   ... RDFS is an example of the sub-optimal outcome of too-high-level
   goal setting

   NM: JT, you ready to go on this?

   JT: I plan to reverse the bullets, adding something to the now-first,
   will-be-third bullet to require the creation of consistent RDF

   LM: It may be that the 'right' answer is neither RDFa nor microdata -
   if the two communities couldn't live with the other solution, maybe
   that's for good reason

   NM: I think that's covered by the existing "not limited to"

   NM: We need to move to procedural discussion in 10 mins or so

   <Larry> maybe there are other metadata/linked data communities who
   would actually get involved if there wasa focused task force ... they
   haven't participated because HTML WG is chaos and no possibility of
   actually getting involved without undue resources

   <Zakim> DKA, you wanted to note it might be a bit patronizing to tell
   people we know they are acting in good faith. (P4)

   DKA: Could we be a bit more positive about the communities that have
   been working so far
   ... "good intentions" seems to almost suggest the opposite
   ... [scribe can't hear]

   HT: This is a technical point, just for you to consider. Don't have to
   answer here. As a naive reader: in para2 of the whole text, you
   outline differences that arise when there's no markup at all...
   ... ...whereas the first bullet of the differences section appears to
   contradict that. Do both mean what they say about the "no markup"

   JT: It's because the RDF from the microdata includes things not
   explicitly marked as items. Will clarify.

   TBL: Under microdata rules, the <TITLE> is turned into RDF.

   JT: OK, I get it. Will think about it.

   HT: You can't tell me I didn't hear these as contradictions...if what
   you're talking about is the no markup cases, say that. If it's what
   microdate processor does with RDF markup and vice versa, say that

   HT: With respect to Dan's point, I like what JAR and LM said 45 mins
   ago. There aren't two communities; there is one community, with one
   set of problems, and perhaps coming in with multiple proposed

   <jar> +1 ht - there's only community - two approaches

   <Zakim> manu, you wanted to say that TAG should state that people will
   be pro-actively pulled in from Microformats, Microdata, RDFa.

   MANU: In response to what was said about not having anybody for the
   Microdata, Microformats or RDFa communities...that will make all of
   these communities hate you. Will look like W3C is going off and
   imposing solutions.

   <Larry> thinks the representatives from the communities should be
   locked in a room until they agree on something

   MANU: Important to say "we're not just interested in the {RDFa, HTML,
   Microformats} community by not inviting anyone.

   IH: We do need to choose people who will work well together.

   Noah: We want W3C to include those that are knowledgable with all of
   the technologies. We should include Microformats, Microdata, RDFa and
   others as well
   ... Whoever is chosen to chair needs to be balanced, impartial,
   straight shooter. It is the chairs job to get people to work together.
   ... We just need to make sure all of these folks will work well

   Noah: in short, I wouldn't shy away from people with strong opinions
   or roots in one set of work or another.

   Noah: We're going to ask Jeni to update the document... what should
   she do?
   ... One more round where she tries to capture what she's heard here?

   <JeniT> I'd also be very happy to get comments by email

   Noah: Or, we could try to have her put the next draft out on www-tag -
   but people may act as if that's the final version, even though it
   ... I think we're a bit too far from having a final version of this
   letter to put it out right now.

   Larry: I have an issue with that.

   Noah: I think caution would be good at this stage.

   <noah> So, Jeni's note currently says:

   <noah> "As we agreed at the F2F, I have drafted the text below to be
   sent to the HTML WG as an issue on microdata and RDFa."

   <jar> ambiguous wording. it can be fixed.

   TimBL: I think that we can put this out as a draft to make progress.

   Jeni: I would like to make changes and do another round before it's
   sent to HTML WG.

   Noah: Do one more round on TAG member list - we'll wait for e-mail
   responses and see if people agree that this should be the TAG's
   ... If TAG members are not happy with the wording, we can discuss it
   further at a future call

   TimBL: This is just the first step

   Noah: How quickly can you do the next draft?

   JeniT: Probably by end of day Friday?

   <Larry> thinks Jeni should send whatever she drafts to www-tag

   Noah: Once Jeni sends it out, we'll give two days for people to
   object. If you don't object, you are accepting the document.
   ... Next Wednesday, this will go out to HTML WG, RDF Web Apps WG, and
   anyone else that should get notification of this.

   <noah> ACTION-571 Due 2011-06-16

   <trackbot> ACTION-571 Write up comments on microdata and RDFa due date
   now 2011-06-16

   <DKA> +1 on this course of action.

   <noah> ACTION Noah to send Jeni's note to HTML WG, RDFa, and W3C staff
   on Wed 22 June 2011 if there are no objections received by the 21st
   Due 2011-06-22

   <trackbot> Created ACTION-573 - Send Jeni's note to HTML WG, RDFa, and
   W3C staff on Wed 22 June 2011 if there are no objections received by
   the 21st Due 2011-06-22 [on Noah Mendelsohn - due 2011-06-23].

    Minutes formatted by David Booth's [10]scribe.perl version 1.135
    ([11]CVS log)
    $Date: 2011/06/18 19:45:13 $


   1. http://www.w3.org/
   2. http://www.w3.org/2001/tag/2011/06/16-agenda.html
   3. http://www.w3.org/2011/06/16-tagmem-irc
   4. http://www.w3.org/2001/tag/2011/06/16-minutes.html#agenda
   5. http://www.w3.org/2001/tag/2011/06/16-minutes.html#item01
   6. http://www.w3.org/2001/tag/2011/06/16-minutes.html#item02
   7. http://manu.sporny.org/2011/microformats-2/
   8. http://lists.w3.org/Archives/Member/tag/2011Jun/0021.html
   9. http://lists.w3.org/Archives/Member/tag/2011Jun/0046.html
  10. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  11. http://dev.w3.org/cvsweb/2002/scribe/

- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Saturday, 18 June 2011 19:49:50 UTC