On 2009-01-01 15:24, Toby A Inkster wrote:
The use cases for RDFa are pretty much the same as those for Microformats.
Right, but microformats can be used without any changes to the HTML language, whereas RDFa requires such changes. If they fulfill the same use cases, then there's not much point in adding RDFa.
For example, if a person's name and contact details are marked up on a web page using hCard, the user-agent can offer to, say, add the person to your address book, or add them as a friend on a social networking site, or add a reminder about that person's birthday to your calendar. If an event is marked up on a web page using hCalendar, then the user-agent could offer to add it to a calendar, or provide the user with a map of its location, or add it to a timeline that the user is building for their school history project. Providing rich semantics for the information on a web page allows the user-agent to know what's on a page, and step in and perform helpful tasks for the user. So why RDFa and not Microformats? Firstly, RDFa provides a single unified parsing algorithm that Microformats do not. Separate parsers need to be created for hCalendar, hReview, hCard, etc, as each Microformat has its own unique parsing quirks. For example, hCard has N-optimisation and ORG-optimisation which aren't found in hCalendar. With RDFa, a single algorithm is used to parse everything: contacts, events, places, cars, songs, whatever.
This is not necessarily beneficial. If you have separate parsing algorithms, you can code in shortcuts for common use-cases and thus optimise the authoring experience. Also, as has been pointed out before in the distributed extensibility debate, parsing is a very small part of doing useful things with content.
Secondly, as the result of having one single parsing algorithm, decentralised development is possible. If I want a way of marking up my iguana collection semantically, I can develop that vocabulary without having to go through a central authority.
You can develop vocabularies without going through a central authority already, via class or id, and many people already do.
Because URIs are used to identify vocabulary terms, I can be sure that my vocabulary won't clash with other people's vocabularies.
Again, you can do this with class, by putting your domain name in the class attribute. It also depends on how much of an issue you think clashes will be with an iguana collection-- I would suggest that due to the specialised nature of the markup, clashes would be quite unlikely.
It can be argued that going through a community to develop vocabularies is beneficial, as it allows the vocabulary to be built by "many minds" - RDFa does not prevent this, it just gives people alternatives to community development.
RDFa does not give anything over what the class attribute does in terms of community vs individual development, so this doesn't really speak in RDFa's favour.
Lastly, there are a lot of parsing ambiguities for many Microformats. One area which is especially fraught is that of scoping. The editors of many current draft Microformats[1] would like to allow page authors to embed licensing data - e.g. to say that a particular recipe for a pie is licensed under a Creative Commons licence. However, it has been noted that the current rel=license Microformat can not be re-used within these drafts, because virtually all existing rel=license implementations will just assume that the license applies to the whole page rather than just part of it. RDFa has strong and unambiguous rules for scoping - a license, for example, could apply to a section of the page, or one particular image.
Are there other cases where this granularity of scoping would be genuinely helpful? If not, it would seem better to work out a solution for scoping licence information instead of bringing in a whole new vocabulary to solve it.
What would you do with scoped copyright information, anyway? I can see images being an issue, but ideally information about a resource should be kept in that resource, and as such the licence should be embedded in the image rather than given by a Web page. In the case of particular sections having particular licences, is there any practical use of marking up different sections with different licences over just doing that with text?
RDFa was largely borne of looking at Microformats, looking at what was successful about them, considering problems with them, and finding ways to resolve those problems.
Andi
