On Mon, May 28, 2012 at 12:51:07AM -0400, Tom Baker wrote:
> Schema.org Alignment Task Group telecon - 2012-05-14 - report
> This report: http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120514_Report
> Agenda: http://wiki.dublincore.org/index.php/Schema.org_Alignment/Telecon_20120514
We decided on the last call to stick with our approach of editing and
approving mappings in Github, and of using the Github issue tracker 
to keep track of issues. This means _not_ moving issues to the W3C
issues tracker in the Web Schemas TG, as had been proposed, though we
can and should periodically report progress to the public-vocabs mailing
We all really like the idea of maintaining the documentation for the
mappings in RDFa, as Antoine has started on Github at . For the
purposes of issue tracking, we all like the idea of being able to cite
specific mappings not just by line numbers (which change as files are
edited, though it is possible to cite specific commits), but with
anchors such as .
We also liked the idea of using a status vocabulary, such as , to
indicate the status of specific mappings.
As Tom notes, however, the RDFa mapping file that Antoine started by
hand  cites definitional information that Tom had cut-and-paste
laboriously by hand from DCMI and Rdfs.org sources. For one thing, we
are leaning towards using Schema.org sources, not Rdfs.org, so this
information is arguably not what we need to have on the page anyway.
More to the point, however, cutting-and-pasting by hand is not a
realistic and maintable approach moving forward.
Gregg notes that the RDFa group has had success in maintaining
information in Turtle and using that to generate RDFa through templating
The group applauded Gregg for tweaking the DCMI XSLT scripts to generate
HTML with embedded RDFa output (e.g., , distilling ).
Regarding whether Rdfs.org documentation should be used as the source
for mappings (as we had decided on an previous telecon) in preference to
Schema.org documentation, it seems that Rdfs.org has played an important
transitional role but we should now be mapping to Schema.org
documentation, which Dan is busy improving -- notably with an
experimental RDFa 1.1 representation of the Schema.org core schema .
Dan also intends to write software to keep the OWL representation more
The use of RDFa both for DCMI Metadata Terms and the Schema.org
documentation would make it unnecessary to replicate so much basic
definitional information by cutting-and-pasting into the DC/Schema.org
A bit orthogonally to the documentation issue, questions remain about
the implications for mappings with DCMI metadata terms of the Schema.org
notions of "domain" and "range" as defined in .
Dan points out that DC and Schema.org terms are often, in practice, used
rather loosely. He suggests that we shift our attention to collecting
and presenting example descriptions so that people do not have to
agonize about whether to use Microdata or RDFa or see it as an either/or
proposition. It would be good if we had a better understanding of when
stakeholders prefer lighter versus heavier metadata. We should make it
easier for people to publish data in multiple channels.
Dan wonders if anchor links such as  might be put into the Schema.org
RDFa representation  as well. Might they draw the mappings from a
Jon has some ideas on how these documents might be designed in a
maintainable way, but I'll let him elaborate.
Tom Baker <[log in to unmask]>