More on microdata vs ‘rel’ attribute

Thanks Ed Summers for referencing my post suggesting a microdata solution to ‘alternate format’ advertisement for citation harvesting.

Ed’s basically arguing for simply using the ‘rel’ attribute on an <a> tag (with value ‘alternate’) instead.

In my original post, I wrote at length at why I think microdata is preferable, at least for my use case, than just rel tag. (Primarily that there is no legal way to provide a non-user-visible link using just the rel tag. well, except hiding it with css, which just seems dirty).

But it’s worth saying more, in more concrete detail, and in process I think illuminate how really nice microdata is.  I will suggest and try to show that microdata, part of the official HTML5 standard, is simply a very elegantly generalized evolution of the ‘rel’ attribute on <a> and <link>.

Basically, the microdata approach and the ‘rel’ approach are almost identical in semantics and implementation, really, they are VERY close. A user-agent could certainly support both and probably should.

<a
  type="something"
  href="http://get.alternate"
  rel="alternate">
Link
</a>

<a
  type="something"
  href="http://get.alternate"
  itemprop="http://example.org/alternate-format">
Link
</a>

Almost exactly the same thing; I think microdata is simply a more generalized and flexible evolution of ‘rel’. You can do the semantic equivalent of ‘rel’ with microdata, but you can also do other things with microdata you can’t do with ‘rel’, things that aren’t about ‘a’ or ‘link’ tags and urls.

(note ‘http://example.org/alternate-format&#8217; is just a stand-in for some URI we establish to mean this. Microdata let’s user communities establish their own property semantics with URIs).

COinS is a great example

And okay, Ed mentions replacement for COinS. I’d suggest the exact same approach,using microdata again, and I think this very simple example — still only using a fraction of microdata’s power, still a very limited use case — already demonstrates the utility of the more generalized microdata over the more limited ‘rel’.

If you have a context-object available at an external URL, and you don’t mind it being user-visible, sure you can use ‘rel’ (again, the lack of actual registered content types for openurl context object serializations is a problem, but let’s just use an x- type I prefer).

<a
  type="application/x-openurl-kev"
  href="http://get/the/openurl"
  rel="alternate">
Get your OpenURL here
</a>

Or pretty semantically equivalently with microdata:

<a
  type="application/x-openurl-kev"
  href="http://get/the/openurl"
  itemprop="http://example.org/alternate-format">
Get your OpenURL here
</a>

But let’s say you do NOT want the link to actually be user-visible. COinS itself focuses on the case where you do not, because ordinarily you don’t — a user does not want to see a raw OpenURL context object, pretty much ever. No problem with microdata, which allows you to use a ‘link’ tag in body (but only legal in html5 with microdata, link tag with rel in body not legal).

<link
  type="application/x-openurl-kev"
  href="http://get/the/openurl"
  itemprop="http://example.org/alternate-format"/>

No good way to do that with old style ‘rel’. (Again, I emphasize, a ‘link’ tag in body was not legal at all in html4, and is legal in html5 only with a microdata ‘itemprop’ attribute, not with a ‘rel’ attribute — which to me suggests that the HTML5 drafters have chosen microdata over ‘rel’ — why fight the standard?).

Oh, but let’s say you don’t even have the context object at an external URL, that’s inconvenient for you, you’ve only got it for embedding in the source. It’s not great RESTful design, but oh well, it happens. Again, no way to do that with html4 ‘rel’ alone. In a comment on my original post, Peter Sefton suggests embedding as a “data:” uri, which seems actually pretty reasonable to me — especially on a microdata ‘link’ in body — it would make little sense to use a ‘data:’ uri on a user-visible ‘a’ tag I think. (It does require more of the user-agent to interpret, so I’m not sure if it makes sense to include it in my original proposed suggestion, but maybe, if it’s a crucial use case. It can always be added in later too, as it’s fundamentally consistent with the exact same microdata approach, and requiring no new microdata property names).

At first I thought maybe microdata ‘meta’ tag could be used too, but you can’t put a ‘type’ on a ‘meta’ tag, so I guess you’d need to use a specific microdata ‘itemprop’ name meaning ‘openurl context object kev representation’, rather than re-using the one meaning ‘alternate format’, which is unpleasantly unparsimonious.

Nonetheless, I think this demonstrates what I mean when I say that microdata is essentially a more flexible and generalized evolution of ‘rel’. The benefit of both is that they can be very very simple — taking no more complicated code or parsing than is justified by the very simple thing we want to do.

If we limit our microdata scenario to what I proposed for the particular use case I was talking about, it’s just as simple as ‘rel’ (and just as much “just html”, since microdata is part of html5) — but also allows the use of non-user-visible ‘link’ tag. But then if you want to you can start expanding the microdata possibilities (and complexities) just a bit, while still using the same parsimonius itemprop name, say, using “data:” URIs. But it’s part of the more flexible and general purpose microdata spec, instead of the dead-ended ‘rel’ attribute.

Microdata is simply ‘rel’, generalized

I think microdata essentially is what happened to ‘rel’, expanded, enhanced, and generalized. A ‘rel’ attribute on an ‘a’ tag or a ‘link’ tag (only legal in ‘head’ section) is something that describes the nature of the ‘href’ attribute (you could say it’s meta-data about the ‘href’ attribute on an ‘a’ or ‘link’). Microdata can do exactly the same thing, and just as simply, but is also generalized to be able to describe the nature of any text on the HTML page, or even formatted data or text that is not visible on the html page.

Sometimes generalizing/abstracting something ends up making it into a complex monster (OpenURL 1.0 itself is a great example), but the html5 microdata drafters have done a great job of avoiding that. It is just as simple as ‘rel’ when using it for equivalent semantics; and it gets more complex at about the right curve as it’s used to express more complex semantics.

So I totally agree with Ed’s motivation to avoid overly complex solutions, or inventing custom solutions when standards will already do. But using microdata does neither; it’s still quite simple, and just as standard as ‘rel’ attributes. (It’s worth saying that inventing custom solutions when existing standards will do is bad; but so is trying to shoehorn poorly fit existing standards into your use case! But that’s not the case here.)

Additionally microdata lets user communities define their own relationships using URIs instead of relying on a standardized controlled vocabulary like ‘rel’ does. And, too,  microdata through the ‘itemscope’ attribute usefully lets you say which region of the HTML page describes the thing this data element belongs to, new functionality if you choose to use it.  Microdata is simply what happens when you take ‘rel’ and generalize and abstract it, while still trying to support doing simple things simply. And it’s pretty nicely done as a standard, keeping simple things simple.  microdata is officially part of html5. Why not move on and use it?