Microformats and RDFa and RDF
Post categories: Technology
| 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 . 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 ³ÉÈË¿ìÊÖ 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 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 that doesn't break ³ÉÈË¿ìÊÖ 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.
RDFa
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 ³ÉÈË¿ìÊÖ 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 . For these sites we intend to provide at separate URLs. In the case of /programmes this has resulted in the development of the - an RDF vocabulary to describe programmes. We're following the same principles with the redevelopment of /music (where we'll be using the existing ). 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 ³ÉÈË¿ìÊÖ website with a mixed economy of . It certainly shouldn't be an either/or. So mostly except that I'm not sure that the accessibility of the abbreviation design pattern is a bug so much as an expected result of . 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.
At 25th Jun 2008, danieljohnlewis wrote: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"
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 ( ).
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
--
Daniel Lewis
* Technology Evangelist at OpenLink Software
- OpenLink Software:
- My Technology Blog:
Complain about this comment (Comment number 1)
Comment number 2.
At 25th Jun 2008, dannyayers wrote: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).
Complain about this comment (Comment number 2)
Comment number 3.
At 26th Jun 2008, fantasticlife wrote:@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?
Complain about this comment (Comment number 3)
Comment number 4.
At 27th Jun 2008, Andy Mabbett wrote: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'?
Complain about this comment (Comment number 4)
Comment number 5.
At 8th Jul 2008, fantasticlife wrote:@pigsonthewing - yeah we should be using hCard role property. Not sure how we missed doing that
Talent is just a ³ÉÈË¿ìÊÖ 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
Complain about this comment (Comment number 5)
Comment number 6.
At 10th Jun 2009, sweeppicker wrote:"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.
Adam@.com
Complain about this comment (Comment number 6)