W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > September 2007

Re: ISSUE-10: RESOLVED - XHTML 1.1 namespace doesn't end in / or #

From: Niklas Lindström <lindstream@gmail.com>
Date: Fri, 28 Sep 2007 14:52:08 +0200
Message-ID: <cf8107640709280552i607c994ane0fb20aa02723bea@mail.gmail.com>
To: "Mark Birbeck" <mark.birbeck@formsplayer.com>
Cc: "Ben Adida" <ben@adida.net>, RDFa <public-rdf-in-xhtml-tf@w3.org>, "SWD WG" <public-swd-wg@w3.org>

Hi Mark!

Thank you for the attribution. :) I find your reasoning and resolution
very good.

That 'relations' was too narrow actually crossed my mind too, so I'm
happy you didn't pick it.


It was a little "overshadowed" though, by my pondering of the
pros/cons of interpreting @profile as (input to) an "importing
mechanism" for names as local, non-prefixed names. Though I admit that
it sounds quite magic, to some extent I still feel that it is more
manageable than opening up the possibility of uncontrollably declaring
URIs. Since such would be minted "on the fly" by a default mechanism
which prepends '.../vocab#' to *any* non-prefixed names (foo, bar and

To me it hints of a scenario akin to what microformats face -- the
need to ad-hoc standardize "wild" names. That because <.../vocab#foo>
may not mean the same thing to two authors (being minted if @rel="foo"
was interpreted), hence being a poor excuse for an URI in RDF land..
Basically amounting to the same semantic value of a plain literal..
(Although <.../vocab#DC.title> would reasonably be owl:sameAs
dc:title, I expect most things will be much less precise).

Sorry for ranting; I really just want to say I feel that ignoring any
non-prefixed names in @rel (other than the predefined of course) may
be the wise course. They *may* mean something (as at least GRDDL
reasonably proves), but *what* should be outside the scope of RDFa for
now, IMHO.

(The initially mentioned "importing mechanism" right now is GRDDL;
perhaps hGRDDL would be a more lean alternative in the future. Perhaps
even a more scoped, declarative mechanism could be devised just for
this (local name importing). Just thinking loud again..)

Best regards,

On 9/28/07, Mark Birbeck <mark.birbeck@formsplayer.com> wrote:
> Hi Ben,
> > Today, we resolved [1] ISSUE 10 regarding the XHTML1.1 namespace not
> > ending in / or #.
> >
> > We will use the following prefix URL:
> >
> > http://www.w3.org/1999/xhtml/vocab#
> >
> > for all default values of @rel (next, prev, copyright, etc...)
> I hope you don't mind if I add a small note to this, so that people
> can see where Niklas' original suggestion went to. (It might look like
> it has dropped off the map.)
> The suggestion that we didn't need to be bound to the XHTML namespace
> for our URI mappings came from Niklas. He suggested that we add the
> word 'relations' to the current XHTML namespace, to indicate more
> clearly that we were dealing with a vocabulary of link types. I think
> most people thought that it was a good idea, so I took the action to
> raise the issue on the XHTML 2 call to see if anyone had any
> objections.
> That group _also_ thought it was a good idea, but then both Roland and
> Shane pointed out an important point, which was that whatever we did
> had to harmonise with @role. (The technical reason is that if RDFa and
> @role were to use different URI mappings then they wouldn't be able to
> share any defaulting mechanism that we might devise, such as 'no
> prefix'.) Also, since the @role taxonomy defines types rather than
> relationships we felt that making them share the name 'relations'
> wasn't ideal.
> Which is how we ended up with 'vocab'. :)
> Sorry for the long explanation, but I just wanted to clarify that
> Niklas' idea was essentially sound, but that it had to be tweaked a
> little to fit with other initiatives, such as @role.
> 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 Friday, 28 September 2007 12:52:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:52 UTC