Thanks for your comments.
> Here's a question related to the use of "default" prefixes,
> and the @profile attribute in DC-HTML:
> I was investigating tool support with respect to resolving
> prefixes against actual URIs (Zotero apparently has "dc"
> hardwired to the "http://purl.org/dc/elements/1.1/"). (*)
> I was shortly considering to use a different prefix in my own
> pages, just to find tools that do not actually do DC-HTML.
> But then I decided to look at
> <http://dublincore.org/documents/dc-html/> first. It uses
> "dc" as well:
> <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
> So, I was going to suggest to change the prefix, to
> illustrate that the actual prefix "DC" is really just a convention.
Yes, you're correct that the prefix name is just a convention, and
there's no "hard-wiring" in the DCMI metadata profile.
In an earlier draft there was something in the profile transform XSLT to
allow for the DC/DCTERMS prefixes to be mapped even if they weren't
"declared" (using rel="schema.DC" etc) but that was removed in the final
The spec does currently say (in 3.1.2)
"Also, the characters used for the prefix in a DC-HTML Prefixed Name are
not significant, but communities often adopt a convention on the common
use of a prefix to facilitate human readability."
But, yes, I think it would have been helpful to include an example that
explicitly illustrated this point for the DCMI-owned namespaces, just to
remove any potential for ambiguity.
I'd be slightly reluctant to create a new version of the profile - i.e.
issuing http://dublincore.org/documents/2009/06/nn/dc-html/ and asking
people to refer to that profile URI in their X/HTML documents - in order
to do this, because it isn't changing any of the "semantics", rather
just clarifying a point of the existing spec.
What I suggest we might do is to amend the content of the existing
document, keeping the same URI, with an "erratum" to the current doc
without creating a new version, to insert an additional pair of examples
(between the current examples 5/6 & 7/8), illustrating that the prefix
"DC" might be mapped to an example.org "namespace URI" and maybe also
that a prefix "XYZ" might be mapped to a DCMI-owned namespace URI.
Tom (and everyone), does that sound OK please? Is that within scope of
what we can do with an "erratum"?
> But then, to my horror, I discovered something else:
> <head profile="http://www.w3.org/2003/g/data-view">
> Which conflicts with a must level requirement in the same spec
> "Where these conventions are used to represent a DC metadata
> description set in an X/HTML document, the value of the
> profile attribute of the X/HTML head element must include the
> URI of this X/HTML metadata profile
> I *do* understand what the GRDDL profile is used for, but
> shouldn't you then use both profile URIs in the profile attribute???
Just to clarify, this question is referring to the profile URIs used in
the profile document itself i.e. in the document
not in X/HTML documents citing/making use of that profile.
Yes, I think you're right. The profile document itself should be citing
both profiles, the W3C GRDDL one and the DCMI one.
What I think happened is the following:
The previous version of the profile doc  had referred to the Embedded
RDF profile  and not the W3C GRDDL profile. The Embedded RDF profile
also defined the rel="schema.XYZ" convention, so the use of that profile
"covered" both the rel="grddl.profileTransformation" _and_ the
Then in preparing the final version we switched to using the W3C GRDDL
profile, rather than the Embedded RDF profile. But that W3C GRDDL
profile only covers the
rel="profileTransformation"/rel="transformation", and not the other
stuff. So essentially the use of @rel="schema.DC" and @name="DC.[...]"
in the profile document is undefined.
I think I had some doubts about whether there might be a problem with
"recursion" - the profile doc itself referring to the profile it
describes - but I'll run a test on a copy to see what happens. If it
works OK, we'll add the additional profile URI. i.e. In the document
(assuming, as above, that we do this as an "erratum" to the current
And again, just to emphasises, there are no new requirements for X/HTML
instances citing the DCMI profile; this would be a change only to the
profile document itself.
Strictly speaking, I think we should probably also be citing a profile
for the use of rel="meta", as that link type isn't defined as part of
the X/HTML spec. Such a profile is defined here
So we could add that too? i.e. use
Thanks again for pointing out these two issues, Julian.
Technical Researcher, Eduserv
[log in to unmask]
+44 (0)1225 474323