RDFa - Dublin Core Metadata - [Fwd: Draft of revised version of Expressing DC in X/HTML meta/link elements]

Hi everybody,

DCMI has just published a proposal for the inclusion of DC metadata into
an (X)HTML content. See below some questions/comments from the DC
architecture guy on the mailing list relevant to RDFa. I have also
provided an answer to that mailing list, archived at:

http://lists.w3.org/Archives/Member/w3c-archive/2007Aug/0024.html

However, I think we are talking about a major constituency here and it
may be worth giving some thoughts ourselves. Here is what I picked up:

- I think we still have a pending issue whether we would or would not
have a @profile for RDFa. It would be urgent to decide on that to make
our message clear (I know that the very future of @profile is at risk,
but let us put that aside for a moment).

Personally, I think we should define a @profile.

- There is a small remark on the <meta> element. Essentially, the issue
is that @name is used for what we use as @property elsewhere. I wonder
whether it would not be possible (and very simple) to allow for @name as
an alias to @property in the context of a <meta> element and use it
accordingly. This is not unlike what we do with @src for <img>...

- The most controversial issue, just raising it (please, do not eat me
alive here). The syntax used in a <link> @rel is the dotted notation.
Ie, dcterm.title. The also use <link> to, essentially, _declare_ those
prefixes.

We use dcterm:title because, well, we use namespaces. Hm, we use the
_syntax_ of namespaces, but we do _not_ use them in the XML sense,
right? More as a concatenation sense like in RDF. So, well, can we
reconcile these two syntaxes? To be able to handle quite a lot of
information out there in terms of DC already? Or to come?

Bear with me:-) I could see the following alternatives:

- Accept the a.b notation for @rel, @instanceof, @rev, @property, as an
alias to a:b (or a replacement thereof?:-)

- Accept the special link notation as, essentially, global namespace
declarations

I think we must keep the xmlns notation, because that provides us with
the copy paste facilities. But the others, well...

Of course, we may ask/hope that the DCMI proposes a namespace-like
notation all the way down. I am not sure that would happen.

Just food for thoughts....

Ivan



-------- Original Message --------
Subject: Draft of revised version of Expressing DC in X/HTML meta/link
elements
Date: Sat, 4 Aug 2007 23:03:21 +0100
From: Pete Johnston <Pete.Johnston@EDUSERV.ORG.UK>
Reply-To: DCMI Architecture Forum <DC-ARCHITECTURE@JISCMAIL.AC.UK>
To: DC-ARCHITECTURE@JISCMAIL.AC.UK

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

[snip]

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: pete.johnston@eduserv.org.uk
Tel: +44 (0)1225 474323

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf