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

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

From: Ivan Herman <ivan@w3.org>
Date: Fri, 10 Aug 2007 15:51:43 +0200
Message-ID: <46BC6D6F.1050104@w3.org>
To: Mark Birbeck <mark.birbeck@formsPlayer.com>
CC: Dan Brickley <danbri@danbri.org>, Niklas Lindström <lindstream@gmail.com>, W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
Mark, my apologies, but I do not have the time now to give a long
answer, just some small points of reply...

Mark Birbeck wrote:
> Hi Ivan,
>> what you propose is, in fact, orthogonal to the other issue.
> Not at all; we currently have a mechanism for dealing with 'known'
> values that are not processed in the 'normal' way, and I am suggesting
> we add to that list of 'known' values.
>> - I fully agree that, for example, the 'next' should be used with the
>> xhtml namespace (or some similar one). I think that is true _regardless_
>> of the '.' issue, and I should have raised that before on the mailing list.
> Yes, of course processing of HTML @rel values is true regardless of
> the '.' issue; it's been defined that way for a long time. So I don't
> know what you mean by you "should have raised that before"--do you
> mean that you have a problem with it?

Absolutely not. Well, this is where not having an up-to-date spec
document (not even an editor's version) begins to really bite:-) I was
not sure whether this is formally accepted or not!

>> That would create much more problems, because any implementation
>> should know all the dublin core terms (and we are talking about a moving
>> target here!).
> But if they are deprecated why would we add to the list?

This is not the issue of being deprecated. On the contrary. DC is
expanding, they define their own notions of profiles, etc. So it is a
moving target in the good sense. Do you mean that we will have to define
a subset of the DC terms that we _do_ have in RDFa and then we
continuously update that? This is the effect I do not like...

>> What about openid? Would we also pre-build those, too?
> Yes, that's the proposal.

And again, pretty much of a moving target, afaik...

>> This is a bit of a mess, requires a precise documentation (which may
>> become a pain in the back), etc.
> It's already a mess, though. Take OpenID for example; it doesn't use
> the same 'namespacing' mechanism as DCTERMS at all, since all you need
> to add to your document is the following:
>   <link rel="openid.server" href="http://www.myopenid.com/server" />
>   <link rel="openid.delegate" href="http://yoururl.myopenid.com/" />
> In this example, the 'openid.' part at the beginning is not a
> namespace as such, it is merely a nice convention for trying to reduce
> clashes with other names. This means that there are no generic parsing
> rules that you can apply to turn the value into some kind of URI for a
> predicate, which in turn means you will need to 'know' about these two
> values in exactly the same way that we have to know about 'next'.

True. I am not sure of OpenID, but the interesting point is that the
DCMI community is proposing _exactly that_, ie, to put explicit
'namespace' mechanism into XHTML, using the @rel="schema.XXX" mechanism.
I am not sure we would have a chance convincing them to use our
mechanism; let alone the fact that, from where they stand _today_, they
would want a mechanism that works with GRDDL and eRDF, too (they
explicitly refer to that problem).

> Now, you could say that rather than 'knowing' about each value
> ("openid.server" and "openid.delegate") it is better to 'know' about
> the 'openid.' prefix and map _that_ to a base URI--then you can parse
> any new OpenID values that come along in the future. But if we do
> that, all we have done is added another namespacing mechanism to our
> growing list, which now stands at three:
>   * the ':' namespacing mechanism which we already have;
>   * the DCTERMS namespacing mechanism that uses '.' and 'scheme.';
>   * the OpenID mechanism that uses 'openid.'.

No. We would indeed need to have a <link rel="scheme.openid" href=".../>
or the equivalent xmlns added to the file. That is, I think,
unavoidable. And the same holds for DC but, as I said, _they_ are the
ones moving in this direction...

> But it doesn't stop there. Not only are there other uses of the '.'
> notation that are like OpenID and don't define the prefix anywhere,
> but there are also uses that require the @type attribute to provide a
> proper interpretation of the predicate. For example, in Atom you can
> add this to your documents:
>   <link rel="service.post" type="application/atom+xml" href="..." />

See above.




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

Received on Friday, 10 August 2007 13:51:54 UTC

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