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

Great!

Have a good trip, by the way.

On 10/08/07, Ivan Herman <ivan@w3.org> wrote:
>
>
> Mark Birbeck wrote:
> > 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. :)
> >
>
>
> I agree that we can postpone this issue! It is certainly more important
> to have a version out of the door, even _before_ October if possible:-)
>
> Ivan
>
> > 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
> >>
> >>
> >
> >
>
> --
>
> 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 15:07:10 UTC