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

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