W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2012

RDFa Lite and non-RDFa @rel values

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Mon, 23 Apr 2012 22:49:47 -0400
Message-ID: <CAGR+nnGCZ=We0Rf8=T4Xjrq=pj9CvMox8M=4MkJwFzWpypq39w@mail.gmail.com>
To: RDFa WG <public-rdfa-wg@w3.org>
(by RDFa Lite, I really mean the new behavior of the property attribute)

It is common for web developers to add a rel attribute in 'a' elements,
e.g. rel="nofollow" or rel="author". According to the current processing
steps of RDFa 1.1, if this kind of @rel is used in an element containing a
property attribute (such as an RDFa Lite snippet), it can impact the
processing and change the triples which are generated. I'd like to explore
ways to avoid this in HTML+RDFa.

First of all let's start with an example:
<p vocab="http://schema.org/" typeof="Person">
   My name is <a href="http://example.com/" property="homepage">Stéphane

which generates:
<> a schema:Person;
   schema:homepage <http://example.com/>.

Add a @rel to the mix:
<p vocab="http://schema.org/" typeof="Person">
   My name is <a href="http://example.com/" property="homepage"
rel="nofollow">Stéphane Corlosquet</a>.

and @property no longer targets the @href but the innerText instead:
<> a schema:Person;
   schema:homepage "Stephane Corlosquet";
   schema:nofollow <http://example.com/>.

Option #1: ignore @rel if it only includes HTML Link types as defined at

Option #2: ignore @rel if it does not include any explicit CURIE. I think
it's safe to assume that the intentional use of RDFa terms in @rel will be
limited in comparison to the use of RDFa Lite and the new @property
behavior. Therefore requiring CURIEs to be used in @rel would allow us to
detect whether @rel is used in an RDFa context or not, and from there
decide whether it should be ignored or not.

In both options, it is important to emphasize the "ignore", as an empty
@rel would still have the same effect of switching the behavior of
@property to the old way.


Received on Tuesday, 24 April 2012 02:50:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:31 UTC