Research Microformats and recommend ways they could be used in Drupal

Claimed by mgccix, and stuff to review at http://code.google.com/p/google-highly-open-participation-drupal/issues/...

Reviewing the draft writeup here: http://mgccl.com/2007/12/1/microformats-use-in-drupal

It's much easier to follow now that it's broken up into sections. However, it still needs more complete examples of each microformat, particularly hCard and hCalendar. I'm also unclear how "rel" microformats differ from XFN. Don't they both use the rel attribute of the <a> element?

Do you have a source for the statement that in-site rel="" attributes will confuse search engines? I'd think they'd only provide it with more data, wouldn't it?

I left a comment on the blog post pointing to this issue, and I also pinged Chris Messina to review this and give more detailed feedback.

Just heard back from Chris Messina, and gave him a bit more details about this GHOP contest.
He thought he was leading the code effort to actually implement it. :)

So I pointed him to mgcclx's write-up and asked him some feedback on the microformat end of things, which is more of his expertise rather than the best way that the Drupal community should implement them.

So I wrote back to Chris:

"Well, if you had to pick 5 microformats to go into Drupal first, would you choose these five?
XFN, hCard, XOXO, simple rel attributes & hCalendar

If not, then which ones would be better, more powerful, more useful, etc?

And take a look to see if he's described them accurately.

I'd say let him post it over at http://groups.drupal.org/microformats-in-drupal, and let that community hash out the best way to implement it."

The other microformat that Chris Messina was really interested in, which wasn't mentioned was hAtom.

I'll ask him here:
Chris:
Does hAtom require an atom feed?
Or can you mark up (X)HTML with the hAtom markup, and then create an RSS feed from static content page that may change later?
Couldn't glean that info from: http://microformats.org/wiki/hatom

Also please post here any other follow-up info about mgccl's post: http://mgccl.com/2007/12/1/microformats-use-in-drupal

So would you recommend focusing on hAtom over any of the other 5 suggested microformats?

That's great, Kent. Thanks for communicating with Chris!

But please bear in mind that these tasks are to be kept rather short (2-5 days), and we don't want to hold students in limbo while the community debates things. The question in terms of the GHOP task should be, "is the research done in the student's work good enough to give the community the information it needs in order to argue for 3 weeks and come up with a decision?" ;)

If so, then please mark this task "fixed" and we'll mark the student's task closed in the Google app so that they can take on another.

If not, please comment on what things are missing from the report, so the student can get them added.

Thanks!

thx for all the suggestions
I did some more changes...
if there is nothing else, can I post on http://groups.drupal.org/microformats-in-drupal ?

It looks like that you've included some extra examples of hCard and hCalendar that Crell was asking for.

And Mgccl did source the search engines getting confused as your own opinion, which isn't as good as a well-sourced link backing it up, but I agree with Crell that more metadata the better.

So I'd say go ahead and crosspost this to http://groups.drupal.org/microformats-in-drupal so that you can continue the discussion there regarding the actual implementation of it, and other details.

Let us know when you post it there, and I think this gives a pretty good overview at the specified high-level abstraction.

changing status in case Crell has any other thoughts.

Thanks!

Just noticed that all of the info is now posted here: http://groups.drupal.org/node/7557
I don't think the final approval should be held up by the Primary Contact of Chris Messina since he's off in his consulting business and fairly busy, and so I'd say let the microformat group sort out the implementation and further review and feedback.
I'd say that this task has been completed.

Well done!

I apologize for being MIA, I hope my feedback is still useful.

hAtom is like any other microformat in that the semantics of another well-known format (in this case, ATOM) is embedded in HTML itself.

In this case, any reverse-chronological content is a candidate for being marked up in hAtom -- so that means any blog-like themes!

Two popular themes for WordPress (K2 and Sandbox) both support hAtom out of the box. You might look to them for ideas:

http://getk2.com
http://sndbx.org

The purpose of using hAtom is to make any webpage subscribable (even if there are no RSS or ATOM feeds present). Additionally, hAtom is useful for theme designers since it creates standard class names for objects typically found in chronological content (i.e. author, entry-date, entry-title, etc).

Okay, now that I've read through mgccix's piece, I have more concrete feedback. I'll take it section by section.

1. XFN

* it's important to note that you can't simply use all XFN values at once; some are mutually exclusive.
* identity consolidation through the use of rel-me was not mentioned specifically and is one of the more important and useful XFN values, since it is a way of pointing to another site on the web from a Drupal user's profile and saying "this is another one of my web addresses". If that web address links back to that profile page using rel-me, you have an unverified claim that can be useful for spidering or discovering transitive relationships.
* Here is advice for implementing hcard and XFN friends lists.
* the second most important XFN values to add support for are 'contact' and 'friend'. Generally whenever you're linking two people together, you should use XFN values, but if you just start with a generic rel-contact for ALL links to friends from a profile page, you enable social network portability.

Note: I'm not sure what your commentary is really suggesting; I haven't seen bots get confused as you've described. Furthermore, rel links ONLY describe the relationship between the linking page and the destination page, it has nothing to do with domains. For example, rel-stylesheet doesn't indicate a stylesheet for an entire domain, only for a single page.

2. hcard

* An hcard is a representation of a person or organization (not an object) using attributes from the vcard standard.
* hcards can be contained in any proper tags, not only DIVs. It's just HTML after all.
* I'm not sure what it meant by "hCard as part of the site information"
* 'fn' represents the 'formatted name', not the 'full name'
* the usefulness of hcard to Drupal is that ANYTIME a person, place or organization is mentioned, it should be marked up using hcard. It's like using the IMG tag for images; when you're putting a person, place or organization into a page, you should use hcard.
* hcard should not be implemented as an extension; ALL profile pages should be turned into hcards. Only 'fn' is required as an attribute to have a valid hcard, which a user must have anyway. There's no good reason not to implement this.
* an extension could be used to add extra vcard attributes to a profile, this is true.
* the convention should be to use attribute names from the vcard spec whenever naming database objects or rows, and that forms should use the vcard attributes rather than a made-up set of attributes.

3. XOXO

* XOXO is pronounced "sho sho"
* XOXO is the easiest microformat to implement and is intended to provide a browser-friendly replacement for OPML.
* XOXO lists are demarked by the presence of class="xoxo", indicating a list of data, as opposed to, say, a list of navigation items. XOXO is simply a way of point out potentially exportable data in a webpage.

4. Simple rel attributes

* rel-nofollow isn't really a microformat; it was an invention by Google to fight spammers and didn't follow the research-intensive Microformats process. In fact, it has turned out to mostly be a failure.
* other rel-values to use include rel-next and rel-prev on pagination links as well as rel-me on those same links, to indicate the continuation of content; rel-home is useful for links to a homepage
* linking rel-license from the footer of every page is quite useful, as no matter what page you land on, you'll know what the license for the content on the page is! Flickr is a great example of this in practice as well.

5. hCalendar

* besides computers being able to read ISO times bette than "Oct 13th", it can be useful to use the date-time abbreviation when saying things like "yesterday", since you might have written "yesterday" a week ago. As well, ISO dates provide the year, another useful piece of information.
* hcalendar is useful for any time based information, like a lifestream or a birthday. It's not just about events, it's about indicating when something happened, no matter how significant. Hell, you could mark up the cron log to make it exportable to a better interface like simile's Timeline interface.

In terms of rel not needing to change the l() function, I'm not convinced. Especially when it comes to pagination linking, rel-next and rel-prev become *very* useful for spidering purposes.

hAtom should also be considered, and my notes are above.

Well, I guess I spoke too soon. :)

Thanks for all the detailed feedback factoryjoe.

The issue was closed in the sense that it was a GHOP research task, but the discussion could certainly go on either in this thread or over in this groups.drupal.org posting.

I'd suggest crossposting this over on the microformats groups research thread, and then they could discuss it a bit, and then create a more actionable wiki page -- like this one from your UI feedback -- that have smaller tasks in the appropriate project's issue queues.

Removing the GHOP part of this title to avoid confusion for those helping to coordinate and review GHOP tasks.
This task has been processed in Google's issue tracker already.
Carry on...

Moving issues from User experience project to Drupal core usability component.