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,

> Mark, my apologies, but I do not have the time now to give a long
> answer, just some small points of reply...

No problem.

>From your replies I'm almost certain that we can repose this
discussion to focus on DC--does that sound fair enough? The reason I
say that is that they are the only people proposing a generic
mechanism--OpenID, RSD, etc., don't have a way to get from the
prefix/value to a URI, so if they are processed at all, they should be
treated as 'known values'.

So we're really saying that we might have two generic namespace
processing mechanisms in RDFa, and the justification for that is that
we think we can't convince others to adopt our core one, and it would
be a good idea therefore, to accommodate theirs.

If that is a reasonable summary, I would suggest that this goes onto
our list of things to debate immediately after we have version one out
of the door (hopefully in October). Otherwise we're the ones with the
moving target. :)

Regards,

Mark

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


-- 
  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 14:02:19 UTC