Promoting Resource Over About
This is a suggestion to consider
@resource as preferable over
@about. The purpose is to promote a slightly simpler and more uniform practice of RDFa use, especially in the RDFa Lite subset.
Technically, it is already possible (since RDFa 1.0) to use
@resource to set the current subject. That is, instead of:
<p vocab="http://schema.org/" about="#manu" typeof="Person">
You can write:
<p vocab="http://schema.org/" resource="#manu" typeof="Person">
The reason for why this works is to support nested descriptions. That is, when using
@src, nested elements containing RDFa will have that resource as the default subject. There is no restriction to this rule, so it is effective even at the top level (i.e. even if there is no
This form has not been generally promoted for a number of reasons, both historical and pedagogical. First and foremost,
@about has always been the primary mechanism to set the current subject. It is named to properly convey this. Also, the behavior of
@resource changed during the development of RDFa 1.0, so that it acquired this feature later on, as more use cases came forward and features like chaining and hanging rels were introduced.
(Note: It is important to understand that
@resource work quite differently when combined with other RDFa attributes! So they are not interchangeable in general. It is only when used alone or combined only with
@typeof that they have the same effect. When a predicate attribute (
@property) is present,
@about always takes on the role of subject and
@resource is always the object. So if you need to make an entire statement in one element (apart from
@about is needed. It is also needed if you want to create a hanging rel with a new subject in the same element.)
There are some potential benefits in promoting
@resource to be the preferred mechanism of giving a subject, and thus pushing
@about into the more advanced concepts. There are drawbacks as well. In the light of recent changes to RDFa 1.1, in comparison to microdata and based on existing usage patterns, it is wise to evaluate this, and thus re-evaluate the preferred form and a current best practice of RDFa.
There are some advanced aspects to
@about which can be omitted from Lite if
@resource is promoted instead:
- The "magnetism" of
@about, that is that
@aboutif present (since otherwise, due to a recent change in 1.1, it creates or types the *object* (given with
- The possibility to make many different statements with one element.
@about isn't part of Lite, markup like this would not be promoted:
<a about="#manu" property="foaf:knows" href="#ivan" typeof="foaf:Person">...</a>
Notice the detail of what
@typeof attaches to here (i.e. the "magnetism" of
@about), as well as the fact that this one element creates two triples:
<#manu> rdf:type foaf:Person . <#manu> foaf:knows <#ivan> .
Instead, by promoting
@resource, the above would have to be written e.g. like:
<div resource="#manu" typeof="foaf:Person"> <a property="foaf:knows" href="#ivan">...</a> </div>
The consequence is that each element here leads to only one statement. Also, the shape becomes more uniform. This is even better illustrated if we add the type of the link object:
<div resource="#manu" typeof="foaf:Person"> <a property="foaf:knows" href="#ivan" typeof="foaf:Person">...</a> </div>
Here we see that the shape is "normalized". I.e. a resource attribute (
@href respectively) are present in both, are typed in both, and are connected by a predicate attribute (
@property) in the nested element.
Note that since
@href, things like this would effectively be "allowed" in Lite:
<div resource="#manu"> <a property="foaf:knows" href="/ivan" resource="/ivan#i" typeof="foaf:Person">...</a> </div>
While that's not the simplest concept, it is probably still easier to understand than e.g. the magnetism of
@about, or the various effects of combining
@rel in the same element.
Furthermore, this can be beneficial due to the current rules for the value spaces of
@src in HTML5. These do not allow for very kind of IRI, but are restricted to URLs (rules are defined to transform IRIs to URLs using URL-encoding).
Also consider scenarios with richer markup. Starting with the example above, let's change the link into a div, with the intent of describing a group of friends in detail:
<div resource="#manu" typeof="foaf:Person"> <div rel="foaf:knows" resource="#ivan" typeof="foaf:Person">...</div> </div>
Then we decide to wrap this in a list using a hanging rel *(note: not described in Lite)*:
<div resource="#manu" typeof="foaf:Person"> <ul rel="foaf:knows"> <li> <div resource="#ivan" typeof="foaf:Person">...</div> </li> </ul> </div>
What I'm trying to illustrate here is how the markup is less surprising, with only
@rel moving up to the list element. There is no functional change, which there would be by using first
@href in a link, then changing to use
@about in the richer blocks. Granted, we switch to
@resource, but this works exactly the same as
@href. Adding new elements using
@property in the blocks above is very simple, and if a predicate attribute is used on any of the elements using a resource attribute, the effect is also straightforward: it would link it to the parent resource. Hanging rels would have to be put by themselves in a wrapping element.
(It also appears that
@resource and @itemid from microdata are pretty much functionally equivalent. Thus this conceptual change seemingly leads to a further alignment of the shape of these formats.)
(See also the discussion in the thread starting with the original proposal at <http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0119.html>, and the resulting ISSUE-119 <http://www.w3.org/2010/02/rdfa/track/issues/119>.)
There are arguments against this direction:
- The name "about" bears more meaning, and has always been the primary tool for supplying the subject - "What are you talking /about/?"
- Existing examples and tutorials would no longer exemplify the best practice. In effect this change of practice would be a departure from the original shape of RDFa, which may confuse web developers looking at old tutorials.
- This behavior of
@resourcehasn't been used very much in practice.
- Changing this best practice would prevent us from removing @resource in RDFa 2.0, if it sees little usage/adoption.
- This change may not actually lead to better markup since it is very nuanced. There has been no field testing done on the feature and not everyone in the Working Group believes it will result in more accurate author markup.
- The change is being made very late in the standardization process, essentially just a few weeks before entering Last Call, adding (instead of removing) the perception of instability in the final spec.
This change in recommended practice would repurpose
@about as an advanced concept. As such, this suggestion definitely changes the perceived shape of RDFa. But as stated, this has technically worked since RDFa 1.0. We may come to consider this "new" take on RDFa as more preferable due to the other reasons outline above. Regardless, we should carefully consider the consequences of this on teaching, uptake and general usability.
(This change could certainly also affect the other RDFa documents, for instance the Primer could be changed in ways described in <http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0185.html>.)