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

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?


> - I am not sure, however, how your proposal handles the, say, openid or
> dublic core cases. Does it mean that we build in, as 'known', all the DC
> terms?

Yes, that's the proposal.


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


> What about openid? Would we also pre-build those, too?

Yes, that's the proposal.


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

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

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="..." />

Are we going to map 'service.' to an Atom base URI? That might be
incorrect for other uses of 'service.'. And Really Simple Discovery is
probably more common at the moment than OpenID, and whilst it doesn't
use a '.', it does use the @type technique:

  <link rel="EditURI" type="application/rsd+xml" href="..." />

So we already need to 'know' about a lot of predefined values if we're
going to process legacy formats--or of course we could leave it all to
GRDDL.


> Again, I agree and understand that the '.' notation is not nice to have
> but, in this case, I believe pragmatism has a value.

Pragmatism always has a value. :) And since we're all rational people,
I think we're all quite pragmatic, so I don't see the point in raising
this in discussions.

Anyway, the point here is that since there is no systematic use of the
'.' notation, we can't define any generic rules for it. The question
is therefore about which of the different 'taxonomies' we want to
accommodate--such as DCTERMS, OpenID, Atom, RSD, etc.--and once we've
determined that, we will have to add special namespace processing
rules for those that are chosen.

So the case needs to be made for adding processing-specific rules for
different taxonomies--which sounds to me like microformats.


> I think Dan's
> formulation is the best one: we make it clear that we accept those in
> the header part as deprecated, but still existing features. Not in the
> body, though.

The case needs to be made for the taxonomies that are so special that
we need to have specific processing rules for them.

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, 10 August 2007 12:42:11 UTC