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

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.

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