Re: New version of Atom+RDFa

On May 21, 2012, at 18:33 , Toby Inkster wrote:

> On Mon, 21 May 2012 16:59:28 +0200
> Ivan Herman <> wrote:
>> - Process comment: personally, I would like to see this document end
>> up as a W3C WG Note.
> As would I.
>> 7th of June. This means moving the document to W3C space, ask for a
>> short name from Thomas and... that is about it...
> That's rather short notice, but I'm already using ReSpec.js, so it's
> probably not a lot of work.
>> 1. The document defines a default vocabulary URI. It is, however,
>> silent on whether the RDFa Core initial context terms, defined in
>> are valid for Atom as
>> well or not. There is no inheritance of those terms, so it must be
>> stated explicitly. I would think these should be valid for Atom, too.
> The RFC 4287 explicitly says that when (for example) rel="alternate"
> occurs in an Atom feed, it is just a shorthand for
> rel="". Atom was
> ahead of RDFa in putting compacted URIs into @rel by several years. :-)
> RFC 4287 says that this is the case for anything that matches
> "isegment-nz-nc" as defined by IRI (effectively the same as terms in
> RDFa). Thus rel="next", rel="previous" and so on are also expanded to
> URIs in the same namespace.
> It's my intention that this remains the case under Atom+RDFa 1.1, so
> the default XHTML+RDFa terms cannot have effect. It's my understanding
> that @vocab "wins" over the default terms now, however it probably
> needs to be made clear that (in the case of Atom), the host
> language's default vocab also "wins".


> I would however want Atom+RDFa to inherit the namespaces from RDFa Core.

Indeed. Which means that if you say that Atom uses the RDFa core namespace prefixes, that would be fine. But that should be put into the spec.

>> 2. I am not sure I understand the rationale for the rules in the
>> <link> element. Can you explain?
> There are basically two restrictions on link[@rel] in Atom+RDFa 1.1.
> You can't use CURIEs, and you can't use terms in the scope of a
> default vocabulary except
> To put it concisely, it's because in either of those situations, an
> Atom+RDFa 1.1 processor would expand the CURIE or term to a different
> URI than a plain Atom 1.0 processor would.
> For example, rel="foaf:homepage" would be expanded to
> <> by an RDFa processor, but to
> <foaf:homepage> (it's a valid IRI syntactically, but not a registered
> scheme) by Atom processors.
> Similarly, rel="homepage" with vocab="" would
> be expanded to <> by an RDFa
> processor, but to <>
> by Atom processors which would ignore @vocab.

Ok, I understand. Seeing that, I wonder whether the spec should not be more restrictive and _ignore_ CURIE-s rather than saying that an RDFa processor should process through everything and rely on document conformance.

> There may well be other restrictions that make sense to add: for
> instance, forbidding @about on <link>.
>> I should have my Atom implementation updated soon in pyRdfa...
> Mine still follows the old spec, but I intend to update it tomorrow.

Mine is done by now:-)


> -- 
> Toby A Inkster
> <>
> <>

Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153

Received on Monday, 21 May 2012 16:42:23 UTC