The current DCMI Recommendation, Expressing Dublin Core in HTML/XHTML
meta and link elements [1], preceded the development of the DCMI
Abstract Model, and so is not based on the DCAM description model.

I've had a go at drafting a new document which specifies a mapping of (a
subset of) the DCAM description model to HTML/XHTML meta and link
elements i.e an X/HTML metadata profile for encoding DC metadata in
X/HTML which is based on the DCAM. See

http://dublincore.org/architecturewiki/DCXHTMLGuidelines/2007-07-27

A few things to note:

(i) this is an X/HTML metadata profile (See [2]). I'm suggesting we use
a different profile URI for this profile from that used for the profile
defined by the current recommendation. I _think_ that would be the right
thing to do so that it is explicit that an instance is to be interpreted
in this way, but I could probably be persuaded that it isn't necessary!

(ii) this profile supports only a subset of the DCAM description model.

(iii) statements with a literal value surrogate are represented using
X/HTML meta elements, and statements with a non-literal value surrogate
are represented using X/HTML link elements. The scheme attribute is
available only on the meta element, and so is to be used only for the
encoding of syntax encoding scheme URIs, not vocabulary encoding scheme
URIs. i.eThe profile does _not_ support the encoding of vocabulary
encoding scheme URIs.

(iv) this profile does not suppport the "double name" convention in the
prefixed name i.e. the property URI http://purl.org/dc/terms/created
must be represented as a prefixed name like "dcterms.created", not
"dc.date.created".

(v) I've suggested using the title attribute of the link element to
encode a single value string within a non-literal value surrogate. I'm
not sure whether this is too much of a stretch of the way X/HTML defines
that attribute. If it is, then I think we'd probably have to exclude
value strings within non-literal value surrogates from the subset of the
model that is supported.

DC-HTML & GRDDL
===============

There's an XSLT transform which maps this profile to RDF/XML i.e.
supports GRDDL [3] for this profile

http://www.incognitum.net/petej/projects/dc-html/xslt/2007/08/02/dc-html
2rdfxml.xsl

And a small set of examples

http://www.incognitum.net/petej/projects/dc-html/xhtml/2007/08/02/

I've used a www.incognitum.net URI 

http://www.incognitum.net/petej/projects/dc-html/2007/08/02/

for the profile URI in those documents, in order to provide access to
the transform for a GRDDL processor for those examples, but if this was
adopted the profile URI would be a DCMI-owned URI.

DC-HTML & eRDF
==============

Like the profile defined by the existing recommendation, this profile is
compatible with the Embeddable/Embedded RDF profile (eRDF) defined by
Ian Davis of Talis. See

http://purl.org/NET/erdf/profile

I think Ian chose the conventions for eRDF with the intent of making
that profile compatible with the existing DCMI recommendation.

The suggested profile differs from eRDF in (I think) four ways:

(i) it doesn't define any conventions for DC metadata within the body of
the X/HTML document.

(ii) it has "built-in knowledge" of the DC and DCTERMS prefixes i.e.
"prefixed names" using those prefixes will be mapped to
http://purl.org/dc/elements/1.1/... and http://purl.org/dc/terms/...
URIs even in the absence of a "namespace declaration" (link
rel="schema.DC" href="....") (I'd be happy to drop this and make it a
requirement to provide a "namespace declaration").

(iii) the value of the scheme attribute of the meta element is mapped to
the URI of the datatype of the literal object.

(iv) the title attribute of the link element is mapped to an additional
triple with an rdf:value predicate. (As I say above, this might be a
stretch!)

So the results of

XHTML -> DCAM --> RDF

would be consistent with

XHTML -> RDF

via the eRDF profile, though the former would generate some additional
triples.

DC-HTML & RDFa
==============

What this new draft _doesn't_ address is any RDFa [4] interpretation of
an XHTML 1.0/1.1 doc using this profile. 

I must admit I'm still a bit unclear about how RDFa applies to XHTML
1.0/1.1 docs. But my understanding (and I could be wrong about this!) is
that RDFa will not be defined as an X/HTML metadata profile, so there
will not be a profile URI for RDFa. However - at least in XHTML 1.1 -
there will be some other "hook"/"trigger" to signal that an XHTML 1.1
doc contains RDFa - a reference to a specific DTD in the DocType
declaration, I think?

If I'm wrong about that, and if an RDFa processor _is_ going to extract
triples from an XHTML 1.0/1.1 doc regardless, then, given that RDFa uses
a QName-like convention based on XML Namespaces for representing URIs,
and this profile (and eRDF) uses a different convention, I'd expect an
RDFa processor to generate some rather nonsensical triples e.g. given

<meta name="dc.title" content="My title" /> 
<link rel="dc.creator" href="http://example.org/Fred" /> 
<link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />

a GRDDL processor using the dc-html profile transform would generate

<> dc:title "My title" .
<> dc:creator <http://example.org/Fred> .

but an RDFa processor would generate (I think?)

<> <http://www.w3.org/1999/xhtmldc.creator> <http://example.org/Fred> .
<> <http://www.w3.org/1999/xhtmlschema.dc>
<http://purl.org/dc/elements/1.1/> .

(I think the meta element would be ignored because RDFa uses a different
attribute for the predicate URI.)

But I'm hoping that my concern here is without foundation, and an RDFa
processor _does_ need some hook before it goes to work on an XHTML
1.0/1.1 doc, and so it will _not_ generate those spurious triples.  

But I suppose this begs the larger question of whether DCMI should
recommend shifting from this current approach (an X/HTML metadata
profile compatible with the eRDF profile and accessible to a GRDDL
processor) to an explicitly RDFa-based approach. 

Given that RDFa is still under development at this point in time, I'm
hesitant to recommend that change right now, and I think there is
considerable value in a GRDDL-able profile. 

But at some point in the future once RDFa is done, it may be worth
producing a separate note on encoding DC metadata using RDFa.

Anyway, comments on any aspect of this welcome - though I'm on leave for
a week, so I won't be replying for a few days ;-)

Cheers

Pete

[1] http://dublincore.org/documents/dcq-html/
[2] http://www.w3.org/TR/REC-html40/struct/global.html#profiles
[3] http://www.w3.org/TR/2007/PR-grddl-20070716/
[4] http://www.w3.org/TR/2007/WD-xhtml-rdfa-primer-20070312/


---
Pete Johnston
Technical Researcher, Eduserv Foundation
Web: http://www.eduserv.org.uk/foundation/people/petejohnston/
Weblog: http://efoundations.typepad.com/efoundations/
Email: [log in to unmask] 
Tel: +44 (0)1225 474323