Category: News

Syndicate Microformats

The two day Syndicate Conference finished up yesterday. Lots of good news about and more and better support for microformats was announced both during the conference and the weeks leading up to it. I’m still collecting/collating all the recent announcements.

For now, check out the following:

And that’s just a taste. More to follow.

Additional tags:

, , ,

Rel vs. Rev

Another note in my very-neglected series on Semantic XHTML basics started awhile back.

It seems that everytime I present microformats, I need to explain the difference bettween the rel and rev attributes. Its understandable that most people don’t grasp the difference, as I’m sure most webdevelopers haven’t needed to make use of these semantics.

We have a good document on the wiki about this, so consider this an introduction.

First of all, rel is an attribute which can be applied to <a> and <link> to define the relationship between the linked document and the current one. So, a very common example is a link to a feed. This blog has:

<link rel="alternate" type="application/rss+xml" href="http://www.microformats.org/feed/" />

This can be read as http://microformats.org/feed/ is an alternate for http://microformats.org/ (Incidentally, the feed could link to this blog with rev="alternate", which would have exactly the same meaning. More on rev in a minute.).

rel is used by XFN, rel-tag, rel-directory and rel-payment microformats.

Now, rev is just like rel, but the relationship is reversed (I think of rev as “reverse relationship”). It gets used in the vote-links microformat like this:

<a href="http://supr.c.ilio.us/blog/" rev="vote-for" title="supr snark">supr.c.ilio.us rocks!</a>

…which would be read as “this document is a vote-for http://supr.c.ilio.us/blog/”.

rel and rev are useful for describing the relationships between two resources on the web. Remember, it is only the relationship between the documents, not the documents themselves which are described. Describing the documents themselves is another topic altogether.

Again, see the wiki for more info.

Tags:

Digital Web Magazine Microformats Primer

Garrett Dimon has written an excellent introduction to / primer for microformats. He provides simple straightforward examples of , , and .

He discusses several reasons for using microformats including: Standards, CSS Convenience, Plug-and-Play JavaScript, and Machine-Readability. I like this explanation of some of the subtler essences and nuances of the of humans first, machines second (emphasis mine):

When writing markup against deadlines and priorities, it’s easy to forget that somebody else will eventually have to maintain it. Conveniently, some of the central ideas behind microformats revolve around the fact that they are designed for humans first and created with simplicity in mind. This means you’ll have markup that is easy to understand and maintain for everyone, including:

  • The engineer integrating your code next week
  • You updating your code next month
  • The new guy taking over your job when you get promoted next year

Read the whole article.

XFN Grandeur

Jennifer Goldbeck has written an post over on an Oreillynet weblog called XFN Delusions of Grandeur.

She seems to be a fan of the ideas behind XFN, but has some criticisms of the microformat. Unfortunately, I think her criticisms come from misunderstandings of XFN. These misconceptions come up often, so I’ll try to give a thorough treatment of them here.

First, she says

The problem with this is that we are annotating URLs of webpages, not people.[…]

Indeed, XFN uses URLs as a way to talk about social relationships. However, in the case of XFN, URLs are used as a proxy for people, which is a practice in common use on the web. When I talk about a friend on my blog, I will commonly link to their homepage or blog. I use their URL, then, as a proxy reference for them.

Jennifer goes on to ask:

How do we actually know who the person is that is described on the webpage? Short answer: we don’t.

We don’t. At least, XFN doesn’t tell us. This lack is intentional- the XFN background document says:

The third design principle is that XFN values should describe the nature of a link between two people, rather than the people themselves. It is our feeling that the content of one person’s site (such as a weblog) will say far more about them than any set of values could ever capture.

So, in essence, the creators of XFN (Tantek, Eric and Matt) didn’t even try to solve the problem of identifying and describing people. For them, it was more worthwhile to create a simple, useful microformat (though they weren’t called microformats yet) which solves a specific problem, rather than trying to solve several problems at once.

More from Jennifer:

This format is only allowing us to annotate links between web pages, not links between people. It may be a socially knowledgeable network of webpages, but it is not a social network.

Says who? People already treat blogrolls (around which XFN was modeled) as a social network- people link to their friends and even treat certain relationships differently (it is common to put a “*” after people whom the author has met). XFN is merely a formalization of this emergent behavior.

More from Jennifer:

Perhaps that is ok – if the end consumer of this information is human, he or she can figure out that the person who owns one page knows/is friends with/has met the person who owns the linked page. If that were the intent, I may look more favorably on XFN. However, their website claims it as something that can be machine processed and aggregated. The site talks extensively about the potential for extracting social networks from XFN, but contains no details about how we actually identify who the people are.

I have several responses to this bit. First, this analysis reflects one of the design principles of microformats, they they’re designed for “humans first, machines second”.

Second, why can’t URLs be used to identify people? Homepage URLs are as meaningful as email addresses (or hashes of email addresses, as I believe FOAF uses), so why can’t they be used to identify people?

Third, at the time XFN was created, there was no useful, machine-parseable, web-friendly way to encode personally identifiable information in webpages. Today, we have a useful option- hCard. An <address> with an hCard is more than enough to identify details about a webpage’s author. Of course, for people more interested in encoding things in RDF could use XFN‘s rel=”me” property to link to their FOAF file.

So, I can link to my coworker, Tantek, with rel="co-worker" and any user agent can traverse that link and use the <address class="vcard"> to contact info, which is personally identifiable.

So, yes there are illusions of grandeur, but even though XFN isn’t taking over the world, it provides a very simple, understandable way to annotate social networks. We’ll use other formats to solve other problems.

Technorati Tags: