Rob Kaye of MusicBrainz writes about their RDFa dilemma. My summary of the short post and comments:
- Someone paid to have RDFa added to MusicBrainz pages a few years ago.
- The code adding RDFa is brittle, hasn’t been maintained through MusicBrainz schema changes, thus is now broken.
- There are no known consumers the RDFa in MusicBrainz pages.
- Unless someone volunteers to fix and maintain the RDFa, “we’re ready to remove the broken code from our pages in an effort to remove technical debt that has accumulated over the past few years.”
- A few people want RDFa in MusicBrainz pages maintained because “Very long term I think this is a sensible way forward – the web site as its own API” and compatibility with other semantic web initiatives.
- Some people tentatively volunteer to help.
Kaye’s post is a model for how to remove features — inform the relevant community, ask if anyone cares and is willing to maintain the feature in question. This could be applied in a commercial context, eg asking customers if they’re willing to pay to maintain a feature or to keep a service alive. It is somewhat odd that transaction costs are high enough/coordination poor enough that such is not as commonplace as feature removal and service shutdown.
I’ve long liked the notion of the web site as its own API, to the extent of feeling a strong dislike for many RPC APIs for web applications, and like RDFa, but mostly I think most metadata implementation is premature, and as with choosing a metadata format, it is best to just ignore it till there’s an unambiguous and immediate gain to be had from implementation.
People pitching metadata as a solution, public or private good, are frighteningly like SEO pushers, except usually not evil. The likeness is that the benefits are vague, confusing, apparently require experts to discern and implement, and almost everyone would be better off wholly ignoring the pitchers/pushers.
I apologize for doing a bit of pitching over the years, wasting people’s time, making whatever I was actually trying to sell more difficult, lowering my intelligence (had I woken up on the other side of the bed some day, I’d have been pitching another layer of snakeoil) and adding technical debt to the world.
Mitigating all this: there’s often no clear separation of “data” and “metadata”. It’s all data of course..
Perhaps people who prefix with “meta” are another class deserving a punch in the face. Note that Kaye’s post does not include the string “meta”; I’m just exploiting the appearance of “technical debt” and “RDFa” in the same text here!
[…] is probably most immediately pertinent), transitioning ownership or stewardship of services is hard, and the software isn’t free (but, at least non-software copyright may not be much of a […]
[…] metadata deployed. See Metadata is technical debt. Deployment as an ugly hack makes it an even more obvious no-brainer no-go. Also, the uselessness […]
[…] painful to use, the list is a good starting place for figuring out what vocabularies to use (if you must), perhaps even for non-RDFa applications — the list is machine-readable of course; I was […]