Hi Antoine,
On Tue, May 29, 2012 at 10:48:52AM +0200, Antoine Isaac wrote:
> I think the idea was to get examples of real DC metadata deployed, for
> which schema.org annotation would be needed. We can then use these
> example to guide and/or validate the mapping effort.
Thank you for an excellent summary of the goal (at least as I had
understood it!).
Let me try to tease out a few more assumptions. As I had understood it,
the Schema.org/DC mapping exercise has hitherto worked on the following
implicit requirements:
Given Web pages with Schema.org/Microdata, express the extracted
metadata using DCMI Metadata Terms in order to make it comparable or
mergible with DC-based metadata.
and (though perhaps less)
Given DC-based metadata, expose that metadata in Web pages using
Schema.org/Microdata.
As I understand it, the idea is that information providers should not
have to make an EITHER/OR decision -- to use Schema.org/Microdata or
DC/RDFa -- but should ideally be able to publish their structured data
in both forms. I'm assuming that this is a conversion that would be
built into an automated workflow, much like RDF/XML, Turtle, and
RDFa/HTML representations can be generated from a single source.
> Dan and I have posted some examples from Europeana during the call.
> For instance:
> http://www.europeana.eu/portal/record/03919/FCD38BDE7A03579F24BEDA5D157943B75BB36F11.html
> has RDFa, which currently uses DC. The question of relevance for us
> would be, what should the schema.org microdata (or RDFa) be on that
> page?
Re: "on that page".... What is not clear to me -- and perhaps this is
"just" an implementation detail, though it would be good to make this
explicit -- is whether we are talking about resolving the EITHER/OR
dilemma by creating Web pages that expose the same information using
BOTH/AND -- both Schema.org and DC properties, in parallel.
The other take-away from the Schema.org discussions, for me, is the
notion that Schema.org successfully provides off-the-shelf,
"good-enough" solutions for webmasters who do not want to invent
everything from scratch. In the Dublin Core community, the provision of
this sort of finished solution has been seen as a goal for years, but
with some notable exceptions that goal has been largely elusive. Part
of the problem has been the lack of a fully-baked way to express those
solutions in a syntax-independent way (the "DCAM problam"), whereas
Microdata provides a turnkey solution (as long as you want to publish
your data into Web pages).
As I see it, then, focusing on BOTH/AND solutions for describing common
types of resources in Schema.org/Microdata (or Schema.org/RDFa?) and in
DC/RDFa (or DC/Turtle or whatever) not only provides a context for
prioritizing Schema.org/DC mappings according to actual use, and for
expressing mappings that are anchored in real descriptive examples.
Rather, focusing on BOTH/AND solutions also provides a context for
a renewed push on the largely unrealized potential of application
profiles.
Focusing on simple Schema.org/DC solutions -- "simple solutions" being
very much part of the Dublin Core genome -- is a good warm-up exercise
that could lead, by way of slightly more complex descriptive
requirements such as ISBD, to application profiles using more complex
vocabularies and descriptive theories such as RDA and FRBR.
Tom
--
Tom Baker <[log in to unmask]>
