« Previous | Main | Next »

Microformats and RDFa and RDF

Post categories:

Michael Smethurst Michael Smethurst | 10:13 UK time, Wednesday, 25 June 2008

Improving the Acronym Karma

My original post on removing microformats from /programmes seems to have kicked off quite a debate. Unfortunately some of this seems to have resulted in RDFa people criticising microformats and vice versa. Which wasn't really the intention.

The post covered 3 things:

  • the decision by the BBC to ban the use of microformats which use non-human-readable data in the title attribute of the abbreviation element (most obviously the datetime abbreviation design pattern)
  • the impact of this on /programmes
  • the possibility of using RDFa on /programmes

so it's probably best to break these things apart.

Banning some uses of the abbreviation design pattern on bbc.co.uk

This is hopefully only a temporary ban until the microformats community come up with an alternative to the abbreviation design pattern that doesn't break BBC accessibility standards. It doesn't mean that hCalendar is banned or even the abbreviation design pattern is banned per se. Just that we can't use it where the title attribute contains non-human-readable data. Note that hCalendar can be used without the abbreviation design pattern but none of the alternatives fit with our needs.

The impact on /programmes

I concentrated on /programmes because:

  • it's the project I work on
  • it's probably the bit of bbc.co.uk that makes most extensive use of microformats

Obviously there are other bits of bbc.co.uk that use microformats that would break the new accessibility standards but we were aware of people screen scraping the /programmes microformats in lieu of a full API so thought we'd best flag up what was happening.


First it's probably important to note that interest in RDFa is pretty much an Audio and Music thing. I've spoken to other people in various bits of the BBC who've expressed an interest but so far the majority of discussions have been confined to Henry Wood House. So this next bit is with A&Mi hat firmly on.

A number of A&Mi projects are being developed in accordance with the principles of Linked Data. For these sites we intend to provide full-fat RDF at separate URLs. In the case of /programmes this has resulted in the development of the Programmes Ontology - an RDF vocabulary to describe programmes. We're following the same principles with the redevelopment of /music (where we'll be using the existing Music Ontology). Where we're providing full RDF it makes sense (at least to us) to reuse these ontologies and also produce RDFa.

Other projects might be data driven but might not want to go down the full RDF route. In this case they might opt for RDFa or they might choose accessible microformats.

For more lightweight, possibly hand-coded projects (still the majority of bbc.co.uk) accessible microformats would probably be most suitable.

So in short it's easy to imagine a BBC website with a mixed economy of microformats, RDFa and RDF. It certainly shouldn't be an either/or. So mostly I agree with Edd Dumbill except that I'm not sure that the accessibility of the abbreviation design pattern is a bug so much as an expected result of deliberate design decisions. Anyway it's a problem that seems to have been around for a while now - hopefully it'll get sorted soon and we can all get back to using microformats (where appropriate) with a bit more peace of mind.


  • Comment number 1.

    Hi Michael,

    One option would be content negotiation.

    If someone asks for:
    * text/html: then give them (X)HTML with Microformats
    * application/xhtml+xml: then give them XHTML+RDFa
    * application/rdf+xml: then give them RDF/XML.

    For testing (I'm sure you know this Michael, but for anyone else reading) this can be fetched for using curl, e.g. using your /programmes system and asking for rdf+xml:
    curl -H "Accept: application/rdf+xml" https://bbc-programmes.dyndns.org/programmes/b009wxzy

    I know that your system is capable of Content Negotiation, because if you don't specify then you get text/html. It is definitely possible to achieve this kind of working using OpenLink Virtuoso ( https://virtuoso.openlinksw.com/ ).

    Do you think that Content Negotiation is a possibility Michael? Or might it not be worth it, because essentially it can all be sponged into whatever format of triples anyway?

    Many thanks and blessings,

    Daniel Lewis
    * Technology Evangelist at OpenLink Software
    - OpenLink Software: https://www.openlinksw.com/
    - My Technology Blog: https://vanirsystems.com/danielsblog

  • Comment number 2.

    Hi Michael. Delighted to hear of your general intention of making the (lovely lovely) data available as RDF.

    Daniel's conneg suggestions sounds good, although it might be a little labour-intensive to set up. (The joy of .htaccess!!).

    While long-term it'd be great to see some full-blown RDFa deployed.In the interim there may be a low-effort compromise option.

    If you use just the microformat bits that fit accessibility requirements, the other data could be expressed using a custom GRDDL profile - write the HTML as appropriate, provide the appropriate linkage to an XSLT to flip that over to RDF/XML. Assuming @profiles are in place for the microformat data and the custom additions, net result is that a GRDDL-aware processor (which now includes pretty much all the well-known RDF toolkits) will see the RDF as intended.

    If you like the sound of this approach, I'd be happy to help myself, though best bet might be to ping the GRDDL mailing list (the WG is now technically defunct, but people are still around with an eye on deployment).




  • Comment number 3.

    @daniel We're looking into the conneg stuff for the full rdf. Still skirting round the edges of rdfa trying to get a foothold but we'll probably be asking questions in the usual places (including here). Would application/xhtml+xml 303 to a different url. We've been advised to redirect the rdf information resource to .rdf What would happen for rdfa?

    @danny We're still using hCard for cast and crew on episode pages. Unfortunately we don't have identifiers for 'talent' so they're not addressable yet. So basically they're fn and not much more. Not very interesting. When it comes to programmes a lot of the views are different cuts of broadcasts, so events, so the loss of hCal is a problem for us. But we're definitely interested in GRDDL for microformatted sites

    Are there any London based RDFa meetups to ask dumb questions at?

  • Comment number 4.

    For drama cast members, you could use hCard's "role" property for the name of the part played, and in all cases for crew roles like "director", "producer" etc.

    What do you mean by 'talent'?

  • Comment number 5.

    @pigsonthewing - yeah we should be using hCard role property. Not sure how we missed doing that

    Talent is just a BBC word for cast (as opposed to crew). So Jonathon Ross is talent, as is Terry Wogan, as is Jeremy Clarkson etc. Hopefully we'll have unique IDs for these people soon so we'll be able to give them their own URLs to aggregate their contributions

  • Comment number 6.

    "If someone asks for:
    * text/html: then give them (X)HTML with Microformats
    * application/xhtml+xml: then give them XHTML+RDFa
    * application/rdf+xml: then give them RDF/XML."

    This would be the most viable option in my opinion.


Copyright © 2015 BBC. The BBC is not responsible for the content of external sites. Read more.

This page is best viewed in an up-to-date web browser with style sheets (CSS) enabled. While you will be able to view the content of this page in your current browser, you will not be able to get the full visual experience. Please consider upgrading your browser software or enabling style sheets (CSS) if you are able to do so.