So, Triplr isn't reading my site correctly. Yep, people have complained about it in the past. And I've found out what the problem is. 
Triplr greps for hCards and then automatically applies the hCard profile transformation. Thing is, on my site, I have already added the hCard profile URI to my page. I've been on #swig today testing out the problem, and it seems that Triplr is automatically applying the microformats profiles to all pages, and if they are already there, applies them twice.
While we are on the subject of the profile attribute, it is still not part of either the HTML 5 working draft or the XHTML 2 working draft. This is bloody infuriating!
Rather than try and battle with the new vested interests of arbitrary 'pragmatism' (ie. "this is pragmatic, that isn't, just because I say so") and even more arbitrary 'real world usage' (there is no reliable way of finding out what real world usage is, since Google does not equal the Web). I have a funny feeling that neither the HTML WG or the XHTML WG will include the profile attribute - either due to malfeasance, ignorance or short-sightedness.
So, I'm taking this in to my own hands. GRDDL must continue to exist, because it's a useful approach to the Semantic Web and keeps format creators equal - kind of like how XML has provided a level playing field for formats to compete on.
Therefore, to pre-empt the eventual and unpreventable slaughter of the profile attribute, I propose that we enable GRDDL processors to process some new profile URIs.
The XPath for these would be //html:*[contains(concat(' ', @rel, ' '), ' grddl ')][@href]/@href
In practice (on HTML 4, XHTML 1 and HTML 5 documents), this would mean using the link and a elements to invoke GRDDL profiles. They could appear anywhere in the document. For XHTML 2 documents, you could use any element that can have both a @rel and @href attribute.
This has a number of advantages over just using head/@profile - it makes the data visible. Some people think this is the best thing since sliced bread. I’m not so sure, but since people seem to think it’s important - we might as well make it so that they can enable it on their pages.
Secondly, it enables people to use GRDDL-based semantics anywhere on their pages. One of the problems that people have with eRDF is that you have to have access to the HEAD to use it. RDFa sort of requires that you use namespace declarations. And pure GRDDL still requires you put stuff in the head/@profile. This new, more liberal GRDDL can be done in HTML fragments - in a blog post, for instance, or a widget or sidebar.
Thirdly, it can provide linkback. On my blog, I have a mini-colophon-style list at the bottom with “XHTML, XML, CSS”. I may as well add hCard and FOAF to that list. Since you are making a hyperlink already, why not make it visible. People might then be able to see “oh, I can pull FOAF out of this page! I never knew that!”
On IRC, we had some discussions about whether or not to use nested GRDDL (danja seemed to have brought it up, although I don’t have the full logs) - but I think it’s probably not a good idea. It’s far too complex and I can see my brain frazzling straight away with inheritance and parsing issues.
Maybe in the future, if this works, we could come back to it. If anyone comes up with a decent way of doing it, then we could play with it. But personally, I think that it’s not a good idea. We already have GRDDL working reasonably well, and applying it to fragments would break existing GRDDL profiles. Best not to do that.
Again, this field is kind of wide open - because of the loose semantics of (X)HTML, we can have a bit of fun building this quite unofficially. I’d love to hear your comments on how we can proceed with this.
