[whatwg] Trying to work out the problems solved by RDFa

[Andi Sidwell]

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