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