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

Hi Ivan,

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

I thought we'd resolved to create a profile, but to make it optional.
That allows those who want to be able to say "my document definitely
contains RDFa" to do so, at the same time as aloowing those who want
to say "I'm going to process every document as if it contains RDFa" to
also do so.


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

Both should be allowed already, but I don't think we've ever discussed
it. And I know for sure that we've never said what would happen if
both attributes were present.


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

I think you are right. We've discussed a number of different ways to
allow support for alternative namespacing mechanisms in the CURIEs
syntax, but we haven't nailed any down yet. However, so far in this
group the pain of _not_ having CURIEs doesn't seem to have promoted
widespread support for it...maybe this is the straw? ;)


> 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?:-)

"As well as", is ok, if we have a way of defining it clearly. As I've
argued before though, "replacement" just seems odd--we have a
namespacing mechanism in the W3C.


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

CURIEs would help here, since they define a namespacing mechanism that
stands outside of a document and is independent of languages. (For
example, CURIEs can be used by SPARQL.)

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Thursday, 9 August 2007 14:00:29 UTC