I’ve talked about HTML link metadata in the past. In that earlier article, I glanced over one detail that gave me a serious headache this week. That issue was the difference between the
rel attributes, and how the two interoperate when used on the same
The short version is that the
property attribute describes string literals, and the
rel attribute describes link relationships. Okay, so use
rel for link elements and
property for every other element, and you’ll be fine, right? Yes, and no; it depends.
The following example is similar to most examples you’ll find on Schema.org (e.g. the Product examples). Because of these examples, you’ll find code snippets and articles recommending the following syntax all over the web:
The Google Rich Results Test (GRRT) utility will interpret the value of
schema:license to be the value of link value in the
href attribute. So this is an example where a
property attribute unexpectedly has described a link relation instead of a string literal! Had it done its job properly, it would have been interpreted as “CC License” instead. However, it’s not wrong. This is where I need to take a quick detour and introduce RDFa Lite; a simplified subset of RDFa Core.
RDFa Lite is intended to make it easier for web authors to adopt RDFa. One of its design goals was to make it possible to “upgrade” the markup to full RDFa Core by simply adding more attributes. In an effort to simplify it, the specification authors also introduced some incompatibility!
Let’s assume you don’t know anything about RDFa or RDFa Lite, but you do know some of the built-in link-relationships in HTML. Let’s expand the above example to incorporate a couple of HTML’s standard link-relationships:
This incorporates HTML’s standard way to declare a license, and tells search-engines not to follow the link and assign it any “link juice.” Both of these link relationships have been recognized by the leading search engines for years. However, we get an error message when we run it by GRRT again:
The interpreted value of
schema:license this time around is “CC License”. The
property attribute no longer describes a link relationship, but the text node decedent of the link! By including a
rel attribute on the
a element, you’ve upgraded it from RDFa Lite to RDF Core! Congratulations, I guess!
The silent upgrade is triggered by setting an
rev attribute on the same element. It only applies for that one element and not the entire document. The following example shows the same element fully migrated to RDFa Core version:
This version should be compatible with HTML and RDFa compatible clients. You’ve got your RDFa and HTML link descriptors on the same element and GRRT no longer has any problems parsing your element.
You can’t automatically fix these types of issues by blindly merging your
property attributes into
rel attributes. Sometimes you want to interpret the element as both a link and a string literal! Here’s an example describing this blog:
In the above example, the interpreted value for
schema:url is “https://www.ctrl.blog/” and
schema:name is “Ctrl blog.” This is the type of compact and data-rich markup RDFa was designed for. You may also realize that it’s more compact than many of the code examples on Schema.org.
I've previously discussed bugs in Facebook and Twitter's webpage metadata extraction methods. I thought that I’d run into another issue like that when I first encountered this behavior. It was unexpected, even to me given my prior knowledge of RDFa. RDFa Lite oversimplified things to a point where it would break in unexpected ways when used together with HTML features. Web authors just need to be aware of the mines on the field when authoring HTML+RDFa.