DRAFT3: RDF Web Applications WG Position on RDFa/Microdata Task Force

Please review and send explicit change suggestions before midnight on
Friday. If we need to revise, we will do so by Sunday (midnight). The
final version will go out to the TAG on this coming Sunday.

Gregg: Struck "What is the range of data.." statement.

Tom: Reworded the last paragraph a bit to make it more clear that
technical issues/bugs need to be filed.

DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3

This is an e-mail response from the RDF Web Applications Working Group
to the Technical Architecture Group at the W3C regarding a recent
concern[1] that was brought to our attention.

We have already submitted a list of people[2] that we believe should be
a part of the RDFa/Microdata Task Force. Additionally, we have had a
discussion[3] in the group about the intended purpose and goals of the
Task Force.

In general, the group believes that a unified approach to structured
data on the Web will reduce confusion in the marketplace and thus
accelerate the growth of Linked Data and the Semantic Web. The group
also thinks that the effort will be fruitless without broad
participation and implementation of the Task Force's findings.

The rest of this e-mail covers the concerns that the RDF Web
Applications Working Group has regarding the new Task Force and attempts
to provide guidance for addressing each concern.

CONCERN: Multiple specifications for the same task

During the TAG discussion, Larry Masinter produced a question that is at
the heart of the issue. "Does anyone want there to be more than one
structured data syntax published by W3C that accomplishes the same task?"

In hindsight, it was a mistake for the HTML WG to allow the publication
of two specifications that accomplish effectively the same task (from
the viewpoint of the public). It is natural that nobody wanted to block
the work of others - but since that hard decision was not made, and
since some very large companies are attempting to make that decision for
their customers, it is creating a great deal of confusion in the
marketplace.

We recommend that the question that Larry asked is required to be
answered by the Task Force.

CONCERN: Scope of structured data in HTML not clearly defined

What are the goals of the structured data in HTML work? Is it to support
the RDF data model? Support some other Microdata-like data model?
Support all of the use cases identified? Only support use
cases that are "mainstream" for Web developers? Provide a browser API
and unified view of structured data on the web? How much complexity
should be exposed to a beginner of structured data? If there is to be a
unified path forward for structured data on the Web, it is important to
understand which use cases we're supporting and which ones we're leaving
behind.

We recommend that the Task Force identify a clear set of goals and use
cases that are to be supported by the structured data in HTML work. The
questions above are provided as suggested discussion points.

CONCERN: Consensus on "No Change"

There is a concern that the group will be provided with very difficult
decisions and instead of wanting to make a hard decision, they will
resolve to not change anything. This will be viewed as a failure of the
group.

This issue is an opportunity for the W3C to demonstrate that the
organization is capable of finding consensus and driving positive change
among a broad constituency.

We recommend that a "no change" result should not be an option for the
Task Force.

CONCERN: Key implementers will choose to not be involved.

It is vital that companies that have deployed, or intend to deploy,
structured data are active participants in the Task Force. This includes
having the right set of people there as well as ensuring that they are
committed to the work of the group. The XForms/WebForms and XML/HTML
Task Forces largely failed in their mandate due to inactivity by major
participants.

We recommend that personnel from relevant companies are involved and
that those personnel have decision making power to enact change in their
organizations related to the Task Force findings.

CONCERN: Agreement and then non-action

It could be that there is agreement among the Task Force participants to
do something, but there is no follow-through. Solid commitments should
be made and the Task Force should follow-up to report on progress
regarding those commitments. Perhaps the HyperText Coordination Group
should play a part in this work.

We recommend that the Task Force gather commitments to enact change at
the end of the discussion phase and then follow-up and report on
progress regarding the commitments.

CONCERN: Slow creation of Task Force

The HTML WG expects Last Call to end in early August for the HTML+RDFa
and HTML+Microdata specs. Similarly, the RDF Web Apps WG was one week
away from entering Candidate Recommendation with RDFa 1.1. It is
questionable whether or not the Task Force will be able to be formed in
the near future. The announcement of this Task Force has effectively
placed a hold on work in both Working Groups. There is concern that work
that is done over the next 3 (or more) months will be invalidated by the
Task Force or by a formal objection by the TAG.

The note by the TAG is effecting both Working Group time lines. It is
imperative that the Task Force is put together quickly and performs its
work in an expedient manner, or is dissolved and another path forward is
chosen.

It is vital that the TAG and both Domain Leads step forward and take
responsibility for the efficient creation and management of this Task
Force. That is, it seems that neither the RDF Web Apps WG nor the HTML
WG thinks it is their job to create or manage this Task Force. Since the
original note came from the TAG, the ball is in your court.

We recommend that the creation of the Task Force is made to be a
priority of the TAG, Domain Leads, and the Director.

CONCERN: TAG Note is not actionable

There is concern in the HTML WG and the RDF Web Apps WG that the note
provided by the TAG is not actionable[4] without further information
from the TAG (formal objection or bug reports) or Task Force (findings
turned into bug reports). The result is that the Working Groups must
either ignore the TAG note until the Task Force has completed their
work, or halt their work until the Task Force has completed their work.

We recommend that the TAG submit a formal objection containing technical
issues for both specifications, or that the TAG submits a series of bugs
for both HTML+RDFa and HTML+Microdata in addition to RDFa Core 1.1 in
the RDF Web Apps WG.

DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3 DRAFT3

-- manu

[1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jun/0058.html
[2] http://lists.w3.org/Archives/Public/www-tag/2011Jul/0011.html
[3]
http://www.w3.org/2010/02/rdfa/meetings/2011-06-30#Official_Position_on_WWW__2d_TAG_issue
[4] http://www.w3.org/2011/06/30-html-wg-minutes.html#item09

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Sunday, 10 July 2011 17:33:45 UTC