[microformats-discuss] Discovery of microformats

[Danny Ayers]

On 7/12/05, Joshua Porter <porter at bokardo.com> wrote:

> Therefore, I wonder if there are some applications for which a
> separate format are better suited, and presumably some applications
> for which microformats are better suited.  Does anybody have a take
> on this?

I was originally very skeptical of the whole notion of microformats -
I mean, what do you need XFN (embedded) for when you've got FOAF
(linked)? But they've grown on me, and I do think there's a range of
applications for which they do make a lot of sense. As a rough
characterisation I'd guess:

* persistent
- because there are loads of things that you might e.g. want to put in
an RSS feed that you wouldn't necessarily want to hold onto forever on
a HTML page.

* having both human-readable (doc) and machine-readable (data)
components, with significant overlap
- I'd look for the overlap, because if you can avoid repeating
yourself that's usually a good thing. A lot of the time you could
generate both a human-readable and a machine readable representation
from the same source, e.g. a database producing a blog in HTML and
RSS. I'm not sure, but where there's more metadata than content it's
probably better separate, and vice versa (i.e.  in retrospect Really
Simple Syndication might have been simpler done completely as HTML).

* when it's easier that way
- a tricky one to judge - I think hReview works very well as a
microformat (even though I've personally done an RDF/XML format for
reviews), perhaps because it's simply structured. I suspect where
multiple vocabularies are needed then an external file may be more
appropriate.

Regarding tool support, PiggyBank is promising :
http://simile.mit.edu/piggy-bank/

> A possible issue to address would be: should I provide OPML or XOXO?

I've a heuristic for that too : What is the data you wish to provide?
For what purpose? If the answer to either question is "Radio Userland"
then the answer's OPML. Otherwise XOXO's probably a better bet.

Cheers,
Danny.

-- 

http://dannyayers.com