A microformat (sometimes abbreviated μF), a web-based approach to semantic markup, seeks to re-use existing HTML/XHTML tags to convey metadata and other attributes in web pages and other contexts that support (X)HTML, such as RSS. This approach allows software to process information intended for end-users (such as contact information, geographic coordinates, calendar events, and the like) automatically.

Support for microformats is not yet provided natively by most web browsers. Several browser extensions, such as Operator for Firefox and Oomph for Internet Explorer, provide the ability to detect microformats within an HTML document. When hCard or hCalendar are involved, such browser extensions allow to export them into formats compatible with contact management and calendar utilities, such as Microsoft Outlook. When dealing with geographical coordinates, they allow to send the location to maps applications such as Google Maps. Yahoo! Query Language can be used to extract microformats from web pages. On 12 May 2009, Google announced that they would be parsing the hCard, hReview and hProduct microformats, and using them to populate search result pages.

Several microformat enthusiasts have been busy spreading microformat markup throughout Wikipedia's collection of templates. This can substantially increase the size and complexity of the template. However, there has never been a community-wide discussion where this technology was embraced. As such, there have been localized disputes at various templates and template talk pages and other locations (see User:Hans Adler/Microformats for a partial list of past discussions). A recent village pump discussion ended in a deadlock seemingly without consensus one way or the other.

Clear consensus as to whether microformats should be embraced by Wikipedia and provided via our templates.

If consensus if found supporting microformats, guidelines should be provided as to their appropriate use and deployment.

If consensus disfavours microformats, further discussion may be required regarding existing microformat implementations.

View by Xeno[edit]

My view is that microformats are an as-yet-unproven technology that provide little-to-no benefit to the average Wikipedia reader while unnecessarily complicating our templates and burdening editors with having to use things like {{duration}} for song lengths to provide metadata that few readers will ever access. According to a Yahoo employee, microformats are "yummy hack fodder", but I don't think that Wikipedia should be a test bed for hack fodder. In order for microformat support to be added to a template there should be a clear advantage and benefit to our reader, and this should be discussed and agreed-upon beforehand. Existing microformat implementations without demonstrable benefit to the reader should be stripped from templates for simplicity's sake.

Users who endorse this summary:

1. As filer of RFC. –xeno^talk 13:28, 10 August 2010 (UTC)[reply]
2. -DJSasso (talk) 13:45, 10 August 2010 (UTC)[reply]
3. - ♪ ♫ Wifione ♫ ♪ _―Œ ^{♣Łeave Ξ мessage♣} 13:53, 10 August 2010 (UTC)[reply]
4. Resolute 14:01, 10 August 2010 (UTC)[reply]
5. OrangeDog (τ • ε) 14:33, 10 August 2010 (UTC)[reply]
6. —  HELLKNOWZ  ▎TALK 15:13, 10 August 2010 (UTC).[reply]
7. —Krm500 ^{(Communicate!)} 15:18, 10 August 2010 (UTC)[reply]
8. Der Wohltemperierte Fuchs^(talk) 15:57, 10 August 2010 (UTC)[reply]
9. Garion96 (talk) 16:11, 10 August 2010 (UTC)[reply]
10. Atama頭 17:43, 10 August 2010 (UTC)[reply]
11. Dodoïste (talk) 19:05, 10 August 2010 (UTC)[reply]
12. Wikipedia's simplicity and accessability has always been one of its greatest strengths, and we should actively remove so-called features that get in the way of that. I imagine if Wikipedia had existed in 1996 people would have tried to foist VRML upon it too, but just because a thing can be done doesn't mean it should be done. Andrew Lenahan - Starblind 17:44, 11 August 2010 (UTC)[reply]
13. Deor (talk) 16:25, 14 August 2010 (UTC)[reply]
14. Davewild (talk) 19:41, 15 August 2010 (UTC)[reply]
15. A reluctant "concur" (I have admired Andy's work on this and helped him with it in the past) - except for the phrase "unproven technology" - I have no problems with the idea that Microfomats work, the question is:
    • Do they provide something useful currently and in the way they are implemented?

    Having seen some of the stuff emitted (with respect to human names), and other comments, documented elsewhere, I would answer no, for the following reasons

    1. Not enough consistency in the data emitted
    2. Not a sufficiently universal standard
    3. Not a good enough base of client apps
    4. Natural language processing can do most of this stuff pretty easily.

    Some of the above reasons may, however, change as technology changes, or not be considered applicable to, for example, coördinate data.

    Rich Farmbrough, 23:24, 25 August 2010 (UTC).[reply]

16. Having experience with a case where the use of microformats meant that the layout of an infobox worsened and info had to be removed from it, and seeing that the main proponent of the use of microformats here claims to have refuted this without having done anything such thing, I can not support the widespread use of them on Wikipedia for the moment. I have no problem with using them in cases where they have absolutely no negative impact on Wikipedia (editors and/or readers) and a positive outside use (as apparently is the case in "coord"), but those seem to be very limited. Fram (talk) 07:42, 1 September 2010 (UTC)[reply]
17. I fully agree with Xeno, and I think I have said enough about this elsewhere. Hans Adler 09:28, 1 September 2010 (UTC)[reply]

View by SarekOfVulcan[edit]

I don't see any reason to exclude microformats as a general rule -- they're useful. For example, see this map of Seattle, with links to Wikipedia articles overlaid on it.

Users who endorse this summary:

1. SarekOfVulcan (talk) 13:40, 10 August 2010 (UTC)[reply]
2. My understanding, admittedly limited, is that {{coord}} (see comments by OrangeDog below) which is undoubtedly useful, makes extensive use of microformats. I am prepared to be open-minded about other uses: the average reader might well not be assisted but is not hindered either. Occuli (talk) 16:09, 10 August 2010 (UTC)[reply]
3. --Cybercobra (talk) 21:29, 10 August 2010 (UTC)[reply]
4. But conversely also not to include them as a general rule.  Sandstein  21:47, 10 August 2010 (UTC)[reply]
5. They're damn useful. Gonna have to offer a view. Jack Merridew 23:52, 10 August 2010 (UTC)[reply]
6. Okay that Seattle map is cool (especially since I'm just outside of Seattle). I don't think they should be banned outright. -- Atama頭 00:20, 11 August 2010 (UTC)[reply]
7. Short but sweet. A better example might be this one, which reuses all the microformats from a single Wikipedia article, via one of the third-party tools for manipulating this supposed "as-yet-unproven technology", which statements above allege don't exist(!). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:12, 11 August 2010 (UTC)[reply]
8. Microformats are a good thing if it can be shown that they benefit the reader. I share the opinion that they will in the future, but here is an example of them doing so now. --WFC-- 04:36, 12 August 2010 (UTC)[reply]
9. -- Quiddity (talk) 23:02, 14 August 2010 (UTC)[reply]
10. Sadads (talk) 01:06, 16 August 2010 (UTC)[reply]
11. Per Andy. --The Evil IP address (talk) 14:38, 9 September 2010 (UTC)[reply]

View by Wnt[edit]

For the uninitiated, when you look into it to try to see how it works, a class tag looks like a dead end. For example, Template:UF-hcal-auto is described as "where class=dtstart is hardcoded".[1] I don't see this. I do see that it uses (simply for display) a class "horizontal". But how does the user know how this class works, what it can do? There's no link to follow. I recall seeing classes defined in various Mediawiki extensions, but to tell you the truth, the one case I managed to track down [2] was only because another editor gave me a link to the particular extension. I also don't know if any classes like "geo", "latitude", and "longitude" are being defined and supported in the browser extensions that are mentioned or if there's something in the Wikipedia code/extensions that defines them.

To me it looks like these microformats involve a hyperproliferation of classes, and that unless we set a strong standard for documentation, we're could end up at a spot where only a tiny fraction of the people who currently fool with templates will be able to fully understand the new system. I think that every class used in a Wikipedia template should be readily traceable to the source of the relevant extension that defines it. I think it might even be desirable to start a new namespace "Class:", where a reference (at minimum) and an easier-to-read manual (ideally) is provided for each class, and classes can be placed into categories, and Talk pages are available for each.

Users who endorse this summary:

1. Wnt (talk) 14:30, 10 August 2010 (UTC)[reply]
2. I agree that the existing implementation of microformats is by-and-large confusing to the average editor. –xeno^talk 15:03, 10 August 2010 (UTC)[reply]
3. This is my major objection to the way microformats are implemented in general: they silently reserve lots of class names. This makes them very overcomplicated. — Gavia immer (talk) 15:07, 10 August 2010 (UTC)[reply]

View by OrangeDog[edit]

While metadata is a good thing to have, there are a number of problems with the current practices on Wikipedia.

1. As detailed here, there are currently no user applications that make meaningful use of our microformats. The only useful use I have seen is with geo-coordinates, but this is redundant to our existing {{coord}} system.

   Clarification - I am referring to the fact that {{coord}} generates a link to a variety of different mapping services. 16:32, 10 August 2010 (UTC)

   Revision - Some of the coords functionality is due to microformats, but is still possible without it by using the http://toolserver.org/~geohack/ links. OrangeDog (τ • ε) 11:28, 17 August 2010 (UTC)[reply]

2. Many Wikipedia articles are nearing or past the usable levels of complexity, both in terms of template code and generated HTML (frequent threads appear at WP:VPT about Barak Obama, USA, etc.). If much of the metadata were removed, these pages would be far more usable, and templates more easy to maintain.

   Clarification - I attempt to refer here to the quantity of HTML, which increases download and display times. 16:32, 10 August 2010 (UTC)

3. Over-usage of metadata in all its forms (COinS, etc.) actually makes the data less useful. If we standardised on one type, user apps would be able to more easily deal with it. Also, I see many instances of {{Start date}}, for example, being used repeatedly on the same article, with no clear indication of what it means to be a "start" date, nor which start dates correspond to which end dates. This both increases the problems of #2, and renders all the metadata useless, as the semantics are no longer clear.
4. In some cases (e.g. {{Duration}}), existing style, flexibility and guidelines must be violated in order to correctly emit microformats. Sacrificing what everyone sees for the benefit of what almost no-one will ever see is a clear mis-placement of priorities.

In summary, limited, consensus-based, well-regulated use of appropriate metadata can be a good thing. The status quo is at best useless, at worst harmful.

Users who endorse this summary:

1. OrangeDog (τ • ε) 14:33, 10 August 2010 (UTC)[reply]
2. A well-stated encapsulation of my concerns. –xeno^talk 14:36, 10 August 2010 (UTC)[reply]
3. ♪ ♫ Wifione ♫ ♪ _―Œ ^{♣Łeave Ξ мessage♣} 14:52, 10 August 2010 (UTC)[reply]
4. -DJSasso (talk) 14:59, 10 August 2010 (UTC)[reply]
5. Agree with all of this, but point four especially. We must always prefer readable prose - that means the freedom to always write readable prose as the editor sees it - over restrictions imposed by technical substrates of the software. — Gavia immer (talk) 15:11, 10 August 2010 (UTC)[reply]
6. Agree to 1,3,4 in particular; 2 excluding HTML complexity, which I don't see as a deal-breaker. —  HELLKNOWZ  ▎TALK 15:21, 10 August 2010 (UTC)[reply]
7. I suggested something like microformats over five years ago in my first Semantic Wikipedia proposal. But what it requires to be useful is integration into the interface. Don't make me have to add arcane template tags to the article text; have a separate edit area with the entries, like "Place of birth" and a text entry box next to it, etc. Have a standardized set of entries for each type of article. Until there is a separation between content entry and metadata entry, it should not be used. --Golbez (talk) 15:50, 10 August 2010 (UTC)[reply]
8. Indeed. Especially point 4. Garion96 (talk) 16:12, 10 August 2010 (UTC)[reply]
9. A contrast between the first point and the fourth point is telling. Should we reduce the quality of an article (even in a small way, like mangling an infobox entry) to allow a little-used function to operate properly? That makes little sense to me. -- Atama頭 17:46, 10 August 2010 (UTC)[reply]
10. I agree with 2 and 3 in particular. Dodoïste (talk) 19:07, 10 August 2010 (UTC)[reply]
11. Hits the key issues right on the head. —fetch·comms 20:12, 10 August 2010 (UTC)[reply]
12. Only with respect to 4, as I don't consider 1 to be a problem (chicken and egg...) and know too little about the technical side of things to understand 3 or to see 2 as a serious problem.  Sandstein  21:53, 10 August 2010 (UTC)[reply]
13. Fully support this view. —TheDJ (talk • contribs) 13:39, 11 August 2010 (UTC)[reply]
14. —DoRD (talk) 21:46, 11 August 2010 (UTC)[reply]
15. Deor (talk) 16:25, 14 August 2010 (UTC)[reply]
16. Davewild (talk) 19:42, 15 August 2010 (UTC)[reply]
17. Sadads (talk) 01:05, 16 August 2010 (UTC)[reply]
18. Wrt. to 2 it's worth mentioning that page generation time is also a concern. Normally only Wikipedia editors are affected by this (not readers who are not logged in), but in some cases it takes a minute or longer for the server to generate the HTML for a page. This problem is very hard to pinpoint, but it would be surprising to me if microformats didn't contribute to it. But 4 is probably the most important point. There have been edit wars for including infoboxes just for the sake of microformats, and I believe there have also been edit wars for removing relevant information from infoboxes because, while perfectly clear to human readers, it was somehow wrong in a microformat context. That's not acceptable. We are writing an encyclopedia, not a database. Hans Adler 09:37, 1 September 2010 (UTC)[reply]
19. Particularly 1, 3, and 4. _EricLeb⁰¹ (Page | Talk) 14:46, 4 September 2010 (UTC)[reply]

View by Nihiltres[edit]

I don't particularly mind the inclusion or exclusion of microformats from Wikipedia, but I think that there are some broader principles that we can agree on before we consider specific cases:

Well-structured, semantically clean markup

We should only use microformats when they can and will be used in a way that uses a correct structure and one that is semantically "clean". For example, using a generic "start date" for a birth date on biographical articles is semantically unclear—is that the date the subject was active in their field, their birth date, or some other information? We should not be inventing our own ontology, or the purpose of standardization inherent in the microformat becomes pointless. Further, the structure ought to be itself clear and correct to the extent available; error-ridden formats are also useless.

Human-readable input/output

Wikipedia content is meant to be read by humans, not machines. The inclusion of a microformat should not compromise in any way the experience a human reader has, including special cases like the experience of blind users with JAWS. If a microformat is dictating an awkward format in articles, the use of that microformat should be rethought. Ideally, a human reader should not realize that the microformats are there, unless they're looking for them. This also applies, to a lesser degree, to input, where the template system can and should be made simpler where possible. In either case, this is more or less the same principle that the use of microformats ought not to interfere with other Wikipedia policies or guidelines.

Consistent format

Use of microformats should be consistent across articles. It would not make sense to have one microformat on, say, musician articles and another on painter articles unless one microformat is specific to a particular field (such as geo-coordinates, perhaps?)—in which case we would want to minimize conflict between microformats if applicable. If we choose one microformat over others, we should be looking for ones which are a) in real use outside Wikipedia, b) adaptable for our purposes, and c) not overly specific to particular entities, particularly non-free software. By (c) I mean the obvious case that were a company to approach Wikipedia asking for us to mark up product entries with their product codes, we would rightly reject that microformat as overly-specific. There is one exception that I find appealing, which is codes for reference media, à la Special:Booksources—but that special case would have to be carefully limited.

Metadata is desirable

When there are not good reasons to avoid using microformats and other metadata, it is in the interest of the project to provide them, even if it serves primarily as "yummy hack fodder". We should be mindful of the higher-order implications of providing this data—for example, if the "yummy hack fodder" were to become a vector for attracting volunteer developers to MediaWiki, it would certainly have not been useless, even if it does not see wider third-party use or things built from that "fodder".

Users who endorse this summary:

1. {{Nihiltres|talk|edits|⚡}} 20:49, 10 August 2010 (UTC)[reply]
2. SarekOfVulcan (talk) 20:51, 10 August 2010 (UTC)[reply]
3. --Cybercobra (talk) 21:32, 10 August 2010 (UTC)[reply]
4.  Sandstein  21:54, 10 August 2010 (UTC)[reply]
5. Mostly agree. nits: microformats are to aid levels of software that then aid users/readers. and consistency would be nice, but since when has that much emerged on a wiki. Jack Merridew 00:00, 11 August 2010 (UTC)[reply]
6. Nothing wrong with hack fodder, as long as it's yummy! ;) --Latebird (talk) 08:08, 11 August 2010 (UTC)[reply]
7. Good set of basic principles I think. —TheDJ (talk • contribs) 13:41, 11 August 2010 (UTC)[reply]
8. Per TheDJ; a foundation to their use here. —fetch·comms 16:02, 11 August 2010 (UTC)[reply]
9. On re-reading, I can support this - because the principles are already complied with, and all the concerns an caveats already addressed; or are straw-men. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:19, 11 August 2010 (UTC)[reply]
10. -- Quiddity (talk) 23:02, 14 August 2010 (UTC)[reply]
11. Agree — Oli Studholme (talk) 13:34, 22 August 2010 (UTC)[reply]
12. Agree that clarity, simplicity, and no additional confusion caused by mark-up are more important than emitting metadata. —  HELLKNOWZ  ▎TALK 19:23, 29 August 2010 (UTC)[reply]

View by Sandstein[edit]

Providing potentially useful metadata is a good thing in principle, even if that metadata is not yet widely used. That's because it allows and encourages the development of methods to use our compendium of human knowlege in new ways useful to the public, consistent with our mission. The number of ways in which third parties such as Google use our geodata is an example for this beneficial dynamic.

But our principal audience (by far!) are human readers and our primary resource are nonexpert volunteer writers, so metadata mechanisms should never get in the way of reading or writing Wikipedia and should not become mandatory. The balance between the cost and the benefit of using metadata mechanisms varies with each use case (depending on complexity, potential usefulness etc.) and changes over time.

A general discussion or policy about whether to use or not to use microformats as a matter of principle is therefore not very helpful. Rather, their merits should be discussed and consensus for their use should be sought on a case-by-case-basis when discussing templates and style guides, as with any other change to Wikipedia. Microformat advocates should temper their boldness with respect for our expectation that wide-ranging changes require consensus before implementation. And microformat opponents should approach each case individually with an open mind rather than letting this become a factional dispute.

Users who endorse this summary:

1. As proposer.  Sandstein  21:46, 10 August 2010 (UTC)[reply]
2. Eminently reasonable, though I don't agree that a general discussion or policy about whether to use microformats as a matter of principle is unhelpful. Microformat proponents have been claiming that consensus has already been established, without backing up their claims. –xeno^talk 21:52 expanded 22:18, 10 August 2010 (UTC)[reply]
3. I too agree that "a [further] general discussion or policy about whether to use or not to use microformats as a matter of principle is … not very helpful" and that "microformat opponents should approach each case individually with an open mind rather than letting this become a factional dispute" is an` "eminently reasonable" view. I trust that Xeno will now close this unhelpful and factional RfC accordingly. I further note that all edits relating to microformats always have been and remain subject to the usual checks an balances (consensus, BRD, etc.) for Wikipedia edits, "as with any other change to Wikipedia". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:13, 10 August 2010 (UTC)[reply]
   1. Note that Xeno has edited the above comment, since I wrote mine. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:23, 10 August 2010 (UTC)[reply]
4. So far there are no microformat opponents, just opponents to the current practice, of a very small group, of inserting them at every opportunity without consensus or against reasonable objection. OrangeDog (τ • ε) 22:18, 10 August 2010 (UTC)[reply]
5. --Cybercobra (talk) 23:44, 10 August 2010 (UTC)[reply]
6. Mostly agree here, too, although core stuff should be mandatory; details will be tucked away in templates, for the most part. Cheers, Jack Merridew 00:07, 11 August 2010 (UTC)[reply]
7. —fetch·comms 16:02, 11 August 2010 (UTC)[reply]
8. Unomi (talk) 16:44, 14 August 2010 (UTC)[reply]
9. -- Quiddity (talk) 23:02, 14 August 2010 (UTC)[reply]

View by Jack Merridew[edit]

I've not been much involved in discussions concerning this, but I've seen this evolving on-wiki for some years. This is core to how the web is evolving, it's about building for the future. It's not directly for the readers, it's for next generation user agents, for Googlebot, and for things we can't imagine, yet, thing that will aid readers indirectly. This project is a bunch of things, an encyclopaedia, a website, and a database. microformats are about adding meaning to content. This is good, we're not paper, we're better. This is a piece of that.

It is possible that these efforts have gone too far in certain areas, but that seems to be more about limitations of MediaWiki, which should simply be pushed forward to cope. Increase the template expansion limit. {{sofixit}}

Most of this will be in templates, which less knowledgeable editors should avoid, anyway. Remember when maps.google started offering the option of showing geo-tagged articles? This is that, but so much more.

Users who endorse this summary:

1. Jack Merridew 00:23, 11 August 2010 (UTC)[reply]
2. Sense at last; thank you - though rather than "going too far in certain areas", we haven't gone far enough, yet. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:03, 11 August 2010 (UTC)[reply]
3. Whole heartedly Acather96 (talk) 20:03, 11 August 2010 (UTC)[reply]
4. Build for the future; just don't make it too awkward. Let the templates work their magic! --Cybercobra (talk) 21:35, 11 August 2010 (UTC)[reply]
5. -- Quiddity (talk) 23:02, 14 August 2010 (UTC)[reply]
6. — Oli Studholme (talk) 13:37, 22 August 2010 (UTC)[reply]
7. --The Evil IP address (talk) 14:38, 9 September 2010 (UTC)[reply]

View by TheDJ[edit]

In principal I'm a proponent of semantic metadata in Wikipedia, but...

1. I'd like to see a good implementation. Microformats are currently used, but it's basically a hack. This hack is messing with the 'default' lack of semantic meaning of the html/css and this technology wise is a bad idea in my opinion. An html class attribute should not be abused for conveying semantic meaning (even if not strictly forbidden by HTML/CSS).
2. COinS, another semantic metadata format, is problematic in the gigantic overhead it creates for references, due to basically duplicating all the data. Despite this observation, I have found COinS to be rather useful if, for instance, you are in college and use something like Zotero.
3. The mixup of html/css semantics with semantic metadata of microformats is something that has crept into Wikipedia as well. Many infoboxes now use the |class options of {{infobox}} to pass along microformats. I think we should have separated this metadata syntax into separate parameters. That might make it easier to change things later on (I'm thinking about potential future integration with mediawiki software features)
4. I see some promise in microdata to solve the above problems, though I point out that switching to that won't be easy with our current implementations of microformats.
5. I'm not really in favor of these formats for anything but infoboxes and refs atm. There are 2 reasons for this. First, the infoboxes/refs are already 'complicated', but we should strive to make content LESS complicated, and making infoboxes and refs more efficient. Second, the more changes we make in content (as opposed to templates), the harder it will be to adapt later on. With unproven technology, the chances that we will have to adapt are real.
6. I'm not of the opinion that having semantic metadata all over the place is actually useful at this stage. Wikipedia is full of information, which in theory means that we can add hooks and stuff to all the content. That would create an unworkable system. Geodata, refs/books, infoboxes, perhaps an album listing, but for now, that's enough in my opinion. We should freeze and see where this is going. We are already emitting more semantic metadata than most other websites, we have done our part in pushing technology.
7. I'm very interested in the centralized data wiki ideas that have been floating around, I think such developments can be much more valuable in the long run.

All in all, I'm a fan, but I also think that we have given enough space for this largely still unproven technology to experiment in our encyclopedia. It's time to analyze, develop and adapt for the proponents of this technology. It is clear to me that this cannot be the definitive implementation. I'm happy to let what we have stay around, but I don't think we should expand it any further into the encyclopedia at this time.

Users who endorse this summary:

1. TheDJ presumably, lol thx for reminding Orangdog. —TheDJ (talk • contribs) 15:34, 11 August 2010 (UTC)[reply]
2. Although some of what we have already (e.g. hRecipe) are clearly out of project scope. OrangeDog (τ • ε) 14:42, 11 August 2010 (UTC)[reply]
3. Especially 4, 5, and 6. —fetch·comms 16:03, 11 August 2010 (UTC)[reply]
4. {{Nihiltres|talk|edits|⚡}} 02:54, 12 August 2010 (UTC)[reply]
5. Amalthea 21:31, 24 August 2010 (UTC)[reply]

View by FT2[edit]

Some examples would be good, many users won't know what "microformats" are in the context of a wiki article or how they are used externally.

The problem seems to be that microformats are in an ideal case, harmless and likely to be a significant future data source ancillary to many articles. (Even if microformats die, some kind of embedded data will probably be used and typical kinds of data for a song, town, or many other kinds of topic, are well enough defined to be worth adding now and updating how it's used as time passes). As such it makes very good sense to support them if it's not disruptive. If the status quo of microformat standards changes over time before settling down, an ideal set of templates and markup would be easy to update by bot or by central template edit.

This suggests that the problem isn't the actual existence of microformats in Wiki articles nearly as much as the cumbersome, complex, templated, and non-human readable way they seem to be done. If a microformat was literally as simple as a line of markup at the end of an article saying <data duration="93" height="17cm" geolocation="17.23461,55.438102" /> or <data title="We will rock you" group="Queen" year="19xx" ... />, or to mark individual snippets of data <data value="duration:3:25:17" display="3h 25m" /> that was transparent and non-disruptive to our end-users' experience, with the actual HTML generated from this being modified as standards stabilized, then I would imagine fewer would object.

Users who endorse this summary:

1. FT2 ^{(Talk | email)} 01:22, 14 August 2010 (UTC)[reply]

View by Andy Mabbett (aka Pigsonthewing)[edit]

Introduction[edit]

Just a few days before this RfC, I received an e-mail from Erik Möller, Deputy Director of the Wikimedia Foundation, thanking me for my work deploying microformats in Wikipedia, and asking if I would be prepared to cross the Atlantic to speak about microformats at a forthcoming Wikimedia event in the USA.

Prior to that, Erik had spoken, in an article called Wikipedia to Add Meaning to Its Pages, about "making some of the data on Wikipedia's 15 million (and counting) articles understandable to computers as well as humans". Note, in particular, the part about "allow[ing] software to know, for example, that the numbers shown in one of the columns in this table listing U.S. presidents are dates". That's exactly what microformats do.

[I've just done this for one row of that table; which is now "understandable to computers", because it now emits an hCalendar, or event, microformat for the presidency, with an hCard, or person, microformat for the president. Note that this is rough-and-ready mark up for illustrative purposes; a better solution would be to make each president's entry a table-row template in the manner of {{Episode list}} - I intend to work on that once this RfC is done.]

They do this simply by labelling, using HTML classes in the way in which they were intended to be used (as detailed in our own article on HTML), sequences of characters on a page, which we read as, say, a name or a date, so that machines can also understand that that is what they are.

There is no other way for us to impart meaning to content on our pages, than to add labels using either in-line HTML or Wikipedia templates (templates which are no more complicated than say, {{Convert}}, {{Birth date and age}} or {{Cite}}). Once meaning is imparted, then our data can be reused by anyone, either directly (by coding parsers) or indirectly (by using one of many browser plug-ins, third-party tools etc.) or, potentially, by using tools added to Wikipedia's own codebase, perhaps utilising one of the many free microformat-parsing code libraries available.

If a user codes a scraper for one of our templates, the scraper (a relatively crude method of reaping data from text by reverse-engineering its structure) only works on our site, and probably only on that one template, or a small group of templates; and if we change the template, the scraper is broken. By using microformats, they can use an existing parser (a relatively sophisticated method of extracting data from a logically marked-up document by following a clear schema or specification), which work on all templates using that microformat, and on any other site which uses it; if they do write their own parser, we won't break it by changing our template.

Our microformatted data can be downloaded as variously, KML, RDF (and thus our data becomes part of the Semantic web), FOAF, JSON, and more, including data-transfer formats such as vCard and iCal (the new vCard specification, vCard4, includes additional features based on what has been done with microformats on Wikipedia). It can be mapped, charted, aggregated and searched. Once some feature enhancements are made to MediaWiki, it will also be possible to extract our audio (spoken articles, etc.) as a podcast or playlist.

The tools which do this include, but are far from limited to:

• Any-2-triples
• Transformr
• Swignition
• X2V

There are plugins, bookmarkets and greasemoney scripts for using microformats in Firefox, IE, Opera and Chrome.

Take-up[edit]

Also just before this RfC, the microformats blog published a fifth anniversary post, "microformats.org at 5: Two Billion Pages With hCards, 94% of Rich Snippets", detailing the widespread use of microformats. Here are some key facts from that article:

• the number of pages published with one or more hCards recently crossed the 2 billion mark... according to Yahoo Search Monkey, making it the most popular format for people or organizations on the web
• in May of 2009 Google launched Rich Snippets with support for microformats and RDFa; 94% use

Among the very many organisations publishing microformats are:

• Google
• Yahoo
  • Upcoming
  • Flickr
• BBC
• Wordpress
  • Gravatar
• Telnec (for all .tel domain pages)
• Twitter
• Facebook
• MySpace
• Vimeo
• LinkedIn
• SlideShare
• Wikimedia Commons
• Wikiepdia in other languages - which have chosen to emulate what we have achieved.
• Associated Press (added to list 19 August)

Among organisations parsing (interpreting) our microformats are:

• Google
• Yahoo (provide a specific search category for Wikipedia)

Concerns[edit]

The concerns raised above are, variously, based on false assumptions or misleading statements; or already addressed:

[Microformats] can substantially increase the size and complexity of the template; unnecessarily complicating our templates

Unsubstantiated assertions. Templates exist specifically to contain (sometimes complex) markup and coding, so that our editors need not be exposed to them.

Microformats are an as-yet-unproven technology

Utterly false: See take up, above

...burdening editors with having to use things like {{duration}} for song lengths

False. Use of {{duration}} is optional, and editors can still enter plain text if they prefer - other editors or bots can make the substitution later, as already happens with, for example, {{Convert}} or {{Birthdate}}/ {{Birth date and age}}.

I don't think that Wikipedia should be a test bed for hack fodder

Wikipedia is not being used as a test bed. The microformats deployed are all already in use elsewhere, and parsed by more then one external tool. Microformats are not just "hack fodder".

In order for microformat support to be added to a template there should be a clear advantage and benefit to our reader,

The benefit may not be to the reader. It may be to a third party, or to a person who uses a third party tool or site which reuses our microformatted data. They give benefit to our readers, and the wider public.

Redundant to our existing {{coord}} system

coord works by emitting a microformat. That's was the reason for its creation.

A class tag looks like a dead end

There is no such thing, in HTML, as a "class tag". if what is meant is a "class attribute", then this is exactly how they were designed to be used, according to the HTML specification.

I do see that [{{UF-hcal-auto}}] uses (simply for display) a class "horizontal". But how does the user know how this class works, what it can do?

class="horizontal" is nothing to do with microformats.

Furthermore, {{UF-hcal-auto}} is a sub-template for documenting other templates; it does not emit a microformat.

Every class used in a Wikipedia template should be readily traceable to the source of the relevant extension that defines it; microformats silently reserve lots of class names

Classes are not "defined by an extension". However, see Wikipedia:WikiProject Microformats/classes and Wikipedia:Catalogue of CSS classes

The existing implementation of microformats is by-and-large confusing to the average editor

Unsubstantiated assertion. If you find things confusing, there is a project page where you can explain your confusion and seek help.

There are currently no user applications that make meaningful use of our microformats

False; see above.

Many Wikipedia articles are nearing or past the usable levels of complexity

Unsubstantiated opinion. Even if true, nothing to do with microformats.

...ditto, Barak Obama (the quantity of HTML increases download and display times.)

The full file size when I recently downloaded Barak Obama was 1814 KB; The microformat in it comprises just 110 characters of the emitted HTML code (~0.005% of the full download). That's not as many as in the preceding sentence. There is no microformat-specific HTML or Wikicode on the edit view; it's all handled by pre-existing templates (e.g. the infobox, and {{birth date and age}}

Over-usage of metadata in all it's [sic] forms (COinS, etc.) actually makes the data less useful

Unsubstantiated opinion.

In some cases (e.g. {{Duration}}), existing style, flexibility and guidelines must be violated in order to correctly emit microformats.

False; see talk page. {{Duration}} renders content in exactly the same visual style as the plain text which it replaces. One of the following durations uses the template; one plain text; without looking at the source, can you tell which is which? 4:32 - 4:32

The status quo is at best useless, at worst harmful.

False. The status quo is demonstrably useful. No harm has been demonstrated.

We must always prefer readable prose - that means the freedom to always write readable prose as the editor sees it

This is allowed by all of our microformat implementations (see above).

Until there is a separation between content entry and metadata entry, it should not be used.

Unfounded and mistaken assertion. The reverse is the case; consider the citation-entry interface, which came after the manual creation of citation templates. Editors should not have to enter material twice; as content then as metadata. They should enter it once, and it should then be emitted both as prose and as metadata. This is what our microformat implementations do.

using a generic "start date" for a birth date on biographical articles is semantically unclear.

That's just the name of a template. A redirect with a different name can be created, if desired; as can a parent template calling {{Start date}}. Examples of both already exist.

...renders all the metadata useless,

This has no effect on the dates in emitted microformats. (Evidence of an example to the contrary is invited)

...is that the date the subject was active in their field, their birth date, or some other information?

This is usually determined (in Wikipedia) by the template parameter name; and in the emitted microformat by the class name (bday for birthdate, or the creation date of organisations and places; dtstart for start date, published for audio recordings, etc.) and context. (There is as yet no microformat attribute for "active in their field"). No example of this issue having caused confusion or ambiguity is provided.

We should not be inventing our own ontology

Nor are we. Can we avoid straw men, please? That said, we should be devising sets of HTML class names as pseudo microformats, where no existing microformat is applicable, as part of our contribution the creation of future microformats. In practise, this simply means that, where we use classes, they should be semantically meaningful, and not presentational. This is good practice for all HTML authoring.

Wikipedia content is meant to be read by humans, not machines.

Wrong. Very wrong. Not the view of the Wikimedia Foundation, as evidenced above. And contradicted by the subsequent bullet point, "Metadata is desirable", as part of the same view (and endorsed by people jointly!). Wikipedia content is meant to be -and is - read by people and machines. Microformats enable this (otherwise, why does robots.txt not disallow all?)

Use of microformats should be consistent across articles.

Ours are; and accord with the relevant microformat specifications, so are consistent with those on other wsebsites, too.

We should be looking for [microformats] which are ... in real use outside Wikipedia

All the microformats we use are in real use outside Wikipedia.

we should be looking for [microformats] which are ... not overly specific to particular entities, particularly non-free software

There are no microformats "specific to particular entities" or " specific to ... non-free software"

Microformats are .. basically a hack. This hack is messing with the 'default' lack of semantic meaning of the html/css

No, microformats are using the semantic tool - class names - built into HTML in the way that was always intended. Read the HTML spec.

The mixup of html/css semantics with semantic metadata of microformats is something that has crept into Wikipedia as well

No; HTML class names are designed to be used semantically. "CSS semantics" is a non sequitur - CSS is for presentation, not meaning. It conveys no semantics. There is no "mixup".

An html class attribute should not be abused for conveying semantic meaning

There is no abuse, this is what class is for.

We are already emitting more semantic metadata than most other websites, we have done our part in pushing technology

We won't run out of metadata. We should publish as much as we can, not self-impose some arbitrary limit for the sake of it. Wikipedia is not paper.

The centralized data wiki ideas that have been floating around

...will store data. That data could be sourced by extracting it from microformatted content. When it's (re-)imported and displayed on our pages, it should still be wrapped in microformat mark-up.

Some of what we have already (e.g. hRecipe) are clearly out of project scope

We use hRecipe to label food stuffs as such, not to mark up cookery instructions. Emitting semantic metadata in this way is not "out of scope".

I see some promise in microdata to solve the above problems

Microdata (for good or bad) is explicitly specified to exclude use in generic data exchange such as that discussed here.

COinS, another semantic metadata format, is problematic in the gigantic overhead it creates for references, due to basically duplicating all the data.

Although COinS are outside the scope of this RfC, this comment highlights one of the advantages of microformats: they label the content on the page, there is no need to duplicate it, reducing volume and removing the possibility of disparity between data and metadata [item added 17 August]

Future development[edit]

None of this is to say that our use of microformats is perfect nor complete. This is a wiki; we constantly improve the way we do things. Anyone involved in or reading this debate is welcome to join and participate in the microformats project (few criticising microformats here seem to have done either), in order to find still better ways for us to make our data parsable and reusable, removing any remaining ambiguities, and increasing ease of use for editors - just as we do with the rest of our activities.

Conclusion[edit]

I urge people to disregard the partisan nature of the RfC wording; and the ad hominem attacks both on the talk page and in linked prior discussion, and to consider instead the veracity of the assertions made about the way microformats work and are used, and the evidence provided to support that, on both sides; in the light of the WikiMeadia Foundation's expressed desire to make our content machine readable. I'm happy to answer any further questions and trust that those who have already made endorsements, without reading both sides of the debate, will revise their views accordingly. Details of other microformat tools and implementations; and further refutations of the common misapprehensions addressed above, and others, plus specifications, examples, and more general information, is available on the microformat wiki.

Users who endorse this summary:

1. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:27, 14 August 2010 (UTC)[reply]
2. -- Quiddity (talk) 23:02, 14 August 2010 (UTC)[reply]
3. Martin McEvoy — MartinMcEvoy (talk • contribs) has made few or no other edits outside this topic.
4. Well-said. Erik (talk | contribs) 12:53, 15 August 2010 (UTC)[reply]
5. The conclusion is unnecessarily abrasive, but fortunately it stands separately from the points raised. This is a good rebuttal to the arguments in favour of the general curtailing of the use of microformats on Wikipedia. That said, I've got a couple of concerns; I'll post a separate opinion. Chris Cunningham (user:thumperward: not at work) - talk 08:15, 16 August 2010 (UTC)[reply]
6. Andy makes a compelling case for microformats. I have no concerns about the microformat-related edits Andy has been making in the last couple of years, which seem to be both considered and gradual (the one thumperward mentions below seems to me to be a trivial edit, which adds something at no expense). (Much of the opposition is indeed 'ad hominem' - I can't imagine a non-Mabbett would experience such difficulties with tiny edits.) Occuli (talk) 16:04, 21 August 2010 (UTC)[reply]
7. Agree with both the summary and Chris Cunningham’s summary of the summary :) Oli Studholme (talk) 14:01, 22 August 2010 (UTC)[reply]
8. There's nothing that can better explain this situation. --The Evil IP address (talk) 14:38, 9 September 2010 (UTC)[reply]

View by Quiddity[edit]

I believe much of this could be cleared up with a clearer FAQ, and set of examples, which is hopefully what this RFC will lead to.

Some of the repeated objections seem to ultimately stem from the titles of the microformats: hcalendar, hrecipe, etc. Again, this is hopefully resolvable just by running through a few examples. E.g. Caesar Salad currently emits metadata (via ADR and hRecipe microformats) that denote the origin of the dish (country and region) and a list of the primary ingredients. With this metadata in all our food-related articles, someone would be able to search for "all dishes that originate in Sicily and contain dill", for example.

Similarly with hCalendar, it's for generating things like timelines. We should be able to enter the url for List of ships attacked by Somali pirates into a site/program, and it will use our metadata to autogenerate a timeline of events, and in this case it could also generate something like a heatmap (as people are doing with the wikileaks info). E.g. a simple example via dbpedia, Aerosmith album timeline. I tried a few other sites, but I can't find many working examples; perhaps Andy can point towards some more?

I don't know much about microformats specifically, but I greatly look forward to the time when our Category:Graphical timelines is huge and useful, by being able to add/overlay/zoom/etc into all the available data, on any given topic (from cars, to species, to people, to wars, to food).

So: With real-estate, the mantra is "location, location, location". With metadata at Wikipedia, the requested mantra is "examples, examples, examples (and documentation)".

Or something like that. :)

Users who endorse this summary:

1. -- Quiddity (talk) 22:45, 14 August 2010 (UTC)[reply]
2. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:21, 14 August 2010 (UTC); while noting that each microformat we use is listed and documented on (or via) the project page; and that the DBPedia examples do not use microformats, and cater to a different audience. See further comments on related talk page section.[reply]
3. --Cybercobra (talk) 00:12, 15 August 2010 (UTC)[reply]
4. Martin McEvoy +1 — MartinMcEvoy (talk • contribs) has made few or no other edits outside this topic.
5. Support the idea of mechanism for searching/grouping well-emitted microformat data. —  HELLKNOWZ  ▎TALK 19:28, 29 August 2010 (UTC)[reply]
6. --The Evil IP address (talk) 14:38, 9 September 2010 (UTC)[reply]

View by Thumperward (Chris Cunningham)[edit]

In general I'm strongly in favour of using the templating system to transparently add semantic value to our markup, and I think Andy's rebuttal above is cogent. That said, I still have some concerns with the way we're currently deploying microformats support which warrant more discussion that a simple {{sofixit}}: namely, that our deployment of sometimes bleeding-edge standards can actually be harmful. For instance, one of the triggers for this RfC was the deployment of microformats to mark up stub templates, and I think it's odd that nobody has linked to that discussion yet: see template talk:asbox#Add 'bodyclass' parameter, redux and the associated archive page. In that case, there were apparently legitimate concerns that the proposed class addition wasn't productive. This is more than just "we should be cautious", as it was Andy himself who was strongly arguing for the support in question. I'd certainly hope that this RfC resulted in a broader discussion than a simple for/against call.

Users who endorse this summary:

1. Chris Cunningham (user:thumperward: not at work) - talk 08:25, 16 August 2010 (UTC)[reply]
2. -- Quiddity (talk) 17:33, 16 August 2010 (UTC)[reply]
3. —TheDJ (talk • contribs) 21:18, 30 August 2010 (UTC)[reply]

View by The Evil IP address[edit]

I really don't understand the need for drama because of such a pettiness. Nobody minds if you're not using the Microformat templates, but rather common text. And yes, they're pretty useless at first view for the average reader, but that's not what they're supposed to be there. They're made for machines, because they don't get the text otherwise. And the machines can then indirectly make such information useful for readers. So, yes, it is even useful to humen, even if not directly. Which definitely is a valid point are the technical aspects. But simply removing doesn't make it better. We need to find a technical way of easing the wiki and HTML source, rather than removing useful microformats. It may be that they're not yet widely used, but that's also no reason not to use them. Wikipedia has somewhat of an "idol function" in the WWW. If Wikipedia starts doing stuff, others will do it, too. It's not required for us that other sites take the first step, we can do that ourselves. So, let's work on improving the problems with it and not removing useful stuff.

Users who endorse this summary:

1. --The Evil IP address (talk) 14:31, 9 September 2010 (UTC)[reply]