Recently I've really got excited about Microformats and how they can be used to create content that can be aggregated around the internet.
Drupal really needs to support microformats, and I am currently planning and working on a module set that allows this. But I would like your input!
If you read the description of microformats, you can see they are set pieces of information based on existing formats such as vCard and iCal, but written in semantic XHTML, which can then be styled using CSS class selectors. You then have the choice to render them to the page, for example with an event. Or you can embed them in your site, such as linking to someone you have cited on your blog by using the rel tag i.e. XFN.
I suppose the input I would like is how people would like to see these microformats implemented? Here are some of my ideas below for what I would like to see:
- Allow each user profile to output to a hCard. This can then be embedded in any node that the user creates for hCard readers to index.
- Be able to create an event in Drupal that will output to a hCalendar-formated node, and also be able to create a hCalendar stream so people can subscribe using an event aggregator
- Allow users to tag an hCard to an hCalendar event so you can build up list of attendees
- Support hResume so someone can put up their CV online, and add their hCard to this as their contact details
- Add XFN to links and hCards to build up social networking structures
- Support hReview for so people can review an item, website, event, etc. Again, the reviewer can tag their hCard for contact, and other hCards and hCalendar events that tie in with the review
I'd also like to see a microformat parser (such as the one you are suggesting) so people can add external events to their drupal calendar. A JS "viewer" that shows/hides microformats as well, so for example if I linked to gusaus on my site, rather than it being a link to his website, instead a hCard pops up showing details of this person, plus a link to the website.
But really this list could be endless. The other question is how would people like to see them implemented? Would people like to see a CCK-like toolkit that allows you create microformats from set fields? For example, if you create your hCard you may want to add your name, URL and photo - but not include your email. Then you may decide to geotag yourself at a later date, so you can add in this field.
Feel free to bounce any ideas in this group.
Check out my Drupal and Microformats work at http://digitalspaghetti.me.uk/drupal5
Comments
Drupal module
Oh forgot to mention, the module project for Microformats is here: http://drupal.org/project/microformats
http://digitalspaghetti.me.uk
great to see
It's great to see progress on this. I recently created the microsummary module which I believe is a form of a microformat, but not an "official" one since it's just in Mozilla browsers at this point.
http://drupal.org/project/microsummary
--
Knaddison Family | mmm Beta Burritos
knaddison blog | Morris Animal Foundation
How would you guage the interest?
Kudos again for creating this group, a module, and trying to get some activity going. It's still a bit of mystery regarding the communities general support of microformats or how it relates to things like CCK. What's your (or anyones) experiences been like so far?
I'm thinking that we should be embracing these types of efforts...
http://microformats.org/wiki/music-examples
http://microformats.org/wiki/media-info-examples
Gus Austin
Nice one!
Really glad you started this group, Digital Spaghetti (or should we call you Digital? Mr. Spaghetti?)...Unlike myself, it looks like you know what your talking about AND know what you're doing. After checking out your site(s), it looks we're coming from a similar place. I'm looking at microformats, CCK, wikis, views, 3rd party APIs, cool work that's being done with audio/playlist/video modules, etc. all as ingredients or building blocks for various distributions. As we work towards building out some of these it'll (how all the modules work together, how structured formats can help tap into other web services, etc.) start to make sense.
Think we can do a lot of figuring out in this group - thanks for creating it!
Gus
Gus Austin
This group is already getting some nice attention
Chris Messina (aka FactoryJoe), gave a nice mention of this group in his blog. For those who don't know, Chris is one of the leading microformat evangelists, and somebody who has a bit of experience with Drupal. Hopefully we'll have Chris, and some other folks from the microformat community, joining the group and helping us figure out the best ways to integrate and support microformats.
Gus Austin
I know that Dries was thinking about this...
First off, I'm really glad to see a Microformats group spring up! I've thought about this a bit lately, realizing that CCK paired with Contemplate brings Microformat functionality within the reach of non-programmer types.
Secondly, I'd like to share this comment by Dries from the core issues form. I remember coming across this awhile back and thinking "wouldn't it be nice to have Microformats in core". Well, I guess Dries is thinking in the right direction concerning profile display. Maybe he just needs a bit more prodding :)
Rick
Microformats integration with other modules
We need to think about how a microformats module should integrate with other applications, and also how applying microformats for nodes differs from applying it to users. I see proposals for linking user profile info to microformats, but hcards aren't limited to users. For instance, you might have a CCK contact card node that should be represented as a hcard.
So I've been doing some playing around with creating a way to indicate a microformat for each CCK field and I see several ways to do this. However, as soon as I started doing that I realized that selecting microformats for the individual CCK fields isn't enough since you may want parts of the node other than CCK fields to have microformats, like the title or body, or the attached location fields, or taxonomy terms. On top of that, you might want a node to contain both hcard and hcalendar info, so some fields might need to be marked as both. Plus CCK fields could be hcalendar or hcard or almost any type of microformat field, and those same types might be used by other modules (like the location modules), so it seems to make more sense for some other module, like the microformats module, to define all the available types and the way they need to be displayed, rather than defining that in numerous places. So creating microformat info for nodes is a cross-field, cross-module task that probably needs to be controlled by a central module like the microformats module.
Here is my suggestion for microformats for nodes:
1) Using hook_form_alter(), insert an option into the content type settings form to select the microformats that should be enabled for that content type (hcalendar, hcard, etc). This could be done by the microformats module since it is done the same way for all content types irregardless of any other modules that might be installed.
2) Probably again using hook_form_alter(), insert an option into the content type settings form to link the node title and body fields to microformats. We need to let the user decide that, rather than make assumptions, so there needs to be a place where they can select that option (i.e that the title should be the summary field for hcalendar). This could be done by the microformats module since it is done the same way for all content types irregardless of any other modules that might be installed.
3) Each application that adds fields to the node needs to create a method for linking its own fields to microformats. That would include CCK, the location module, the event module, the image module, plus others. That work would need to be done by the application rather than in a central module, since it will need to implemented differently in each application, and the application needs to keep its own information and methods up to date.
So for this we need some kind of hook system to expose microformat info created by other modules back to the microformats module. I'm thinking of the way that Views works. Views provides a way (the views_tables() hook) for other modules to let Views know what fields are views-enabled. Then each module can provide a way that users can link their fields to microformats and then pass that info back to the microformats module. The modules also need to surpress the normal display of their info for those fields so the microformats module can handle it.
We also need the microformats module to expose to the applications the available microformat types for the current node type so the other modules have a list of available options for their fields to use.
4) The microformats module would then use the selected microformat type (hcalendar, hcard, etc), the user selections for handling the title and body fields plus info provided by other modules on other microformat fields, to insert microformat info into the view, rss feeds, and wherever else it is needed. In Drupal 5, this will be by wrapping each field item with the right microformat span or abbr tag. Not completely sure how best to do this in Drupal 4.7, it might even be so much easier to do this in Drupal 5.0 that it would make sense to implement this just as a Drupal 5+ feature.
I hope this makes some kind of sense. I can visualize how this could work, but I'm not sure I'm explaining it well...