[microformats-discuss] FYI: Boyd on Microformats and Structured Blogging

[Danny Ayers]

http://www.corante.com/getreal/archives/2005/10/10/microformats_v_structured_blogging_a_small_war_with_big_consequences.php

On 10/11/05, Tantek Çelik <tantek at cs.stanford.edu> wrote:

> All in all a very good article.

Yup.

> > I don't see it as a war.
>
> Right.  There is no need to see it as a war.

Yup.

> > I fully expect the two to be compatible and
> > translatable - preferably with XSLT? I would be very disappointed if
> > this proved to be impossible.

I'm not so sure either, nor do I really think it's cause for
disappointment. I'm no doubt biased by my fondness for RDF, but it
seems to me that the way the data is expressed is less interesting
than the data itself - syntaxes can be interchangeable if there's a
common data model. This is why I don't think full translatability is
essential. If there are overlapping parts of the domain models, the
data can be interoperable. (Mmm, that's a big reason why I'm fond of
RDF ;-)

On the issue of the "war", correct me if I'm wrong, but I believe
there are actually three leading ways of associating explicit data
with a HTML document:

1. Inline : i.e. microformats
2. Embedded: e.g. Structured Blogging, trackback, Creative Comments
3. Linked: e.g. RSS/Atom, FOAF etc (as RDF/XML)

There are pros and cons of each for different purposes, which I think
could be summarised as being how close the data is to the doc content.

Where the data is (conceptually) very close, 1:1 even, it makes sense
to use a notation that reflects that - microformats. At the other
extreme, where the relation is not so direct, linking makes most
sense. The author of a particular article is good information to go
inline, but you probably wouldn't want to include information about
their interests, PGP signature and profiles of their pets. (What
format the external doc takes is another matter - a lot of stuff might
be appropriate as a linked HTML page). In between there is the
embedded approach. Putting stuff in comments is awful, but I don't see
any problem in principle with embedding data in <script> elements. The
assumption in the HTML specs is that the script should be executable,
but that seems very weak to me. The embedded approach has the
advantage that the data doesn't have to be relevant to the content,
the disadvantage that where it is there may be a tendency towards
duplication.

With most CMSs, in practical terms there isn't much to choose between
the three approaches. They each have their own issues when it comes to
parsing and extracting the data too, I'm not sure there's much
practical difference there either.

All three formats are usually delivered over HTTP, the only difference
really is that microformats already have a very useful hook into the
protocol through links. (There's potential for that in the other two
approaches, but not in such a standard fashion).

One other little positive side effect of microformats is the
encouragement of CSS conventions, which long term will hopefully lead
to more interchangeable styling. (I expect there are some in the HTML
community that see that as a primary benefit, but I'm just an
old-fashioned datahead ;-)

> We even have a whole process (albeit small) for cooperatively coming up with
> new microformats (if they're even necessary).  All this is essential to
> doing open standards in a community.

Yup.

> BTW, I've personally invited the SB folks (Bob in particular) to please come
> join the discussions in the microformats.org community and contribute their
> SB ideas to help improve microformats as a whole.  However, I have yet to
> hear anything in response.
>
> In the mean time, we, the microformats community, should just focus on doing
> the right thing for the community and succeeding, with the assumption that
> nothing succeeds like success. ;)

Yup.

Cheers,
Danny.


--

http://dannyayers.com