TAG telcon

Admin

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: I appreciate Manu joining us, but I do have a request. We do not have anyone on this call who is closely connected with the microdata work. That was a mistake on my part, for which I apologize. Manu, if you would focus primarily on catching errors of fact in our discussion today, I would be very grateful. I don't want to discuss the positions advocated by those working on RDFa or microdata (or schema.org) until we can have appropriately balanced representation. Thank you.

NM: There has been some public fuss about the fact that JT's post is Member-only
... 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
... 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 specs]
... 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 organization.

<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> 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: http://lists.w3.org/Archives/Member/tag/2011Jun/0021.html

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 compatibility
... 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 functionality

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: http://lists.w3.org/Archives/Member/tag/2011Jun/0046.html

<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 reconciliation.

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 problematic.

<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 Force?

<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 space
... 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, consumers

<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 thought

<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 situation

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 space

<plinss> keep

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

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" case?

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 please.

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 solutions.

<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 together.

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 isn't.
... 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 position.
... 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].