- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Sat, 18 Jun 2011 20:49:05 +0100
- To: www-tag@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
are now available at
http://www.w3.org/2001/tag/2011/06/16-minutes.html
and in text form below.
ht
- ----------------
- DRAFT -
TAG telcon
16 Jun 2011
[2]Agenda
See also: [3]IRC log
Attendees
Present
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
Chair
Noah Mendelsohn
Scribes
Henry S. Thompson, Manu Sporny
Contents
* [4]Topics
1. [5]Admin
2. [6]ISSUE-35 -- Microdata/RDFa relationship
_________________________________________________________________
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: 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
... 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
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> [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:
[8]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:
[9]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].
_________________________________________________________________
Minutes formatted by David Booth's [10]scribe.perl version 1.135
([11]CVS log)
$Date: 2011/06/18 19:45:13 $
References
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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFN/QEykjnJixAXWBoRAk3VAJ4tdrMXeA5kbjhTzb7zAq78/K3hygCdF7co
Yd7lPV7RnsS4GEauWPnIJRw=
=XeWq
-----END PGP SIGNATURE-----
Received on Saturday, 18 June 2011 19:49:50 UTC