Pigsonthewing (talk | contribs) m →View by Sandstein: ce3 |
→View by Sandstein: clearly this needs some qualifying |
||
Line 101: | Line 101: | ||
Users who endorse this summary: |
Users who endorse this summary: |
||
# As proposer. <small><span style="border:1px solid black;padding:1px;">[[User:Sandstein|<font style="color:white;background:blue;font-family:sans-serif;">''' Sandstein '''</font>]]</span></small> 21:46, 10 August 2010 (UTC) |
# As proposer. <small><span style="border:1px solid black;padding:1px;">[[User:Sandstein|<font style="color:white;background:blue;font-family:sans-serif;">''' Sandstein '''</font>]]</span></small> 21:46, 10 August 2010 (UTC) |
||
# Eminently reasonable. –[[user:xeno|<font face="verdana" color="black">'''xeno'''</font>]][[user talk:xeno|<font color="black"><sup>talk</sup></font>]] |
# 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. –[[user:xeno|<font face="verdana" color="black">'''xeno'''</font>]][[user talk:xeno|<font color="black"><sup>talk</sup></font>]] 22:18, 10 August 2010 (UTC) |
||
# 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". <span class="vcard"><span class="fn">[[User:Pigsonthewing|Andy Mabbett]]</span> (User:<span class="nickname">Pigsonthewing</span>); [[User talk:Pigsonthewing|Andy's talk]]; [[Special:Contributions/Pigsonthewing|Andy's edits]]</span> 22:13, 10 August 2010 (UTC) |
# 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". <span class="vcard"><span class="fn">[[User:Pigsonthewing|Andy Mabbett]]</span> (User:<span class="nickname">Pigsonthewing</span>); [[User talk:Pigsonthewing|Andy's talk]]; [[Special:Contributions/Pigsonthewing|Andy's edits]]</span> 22:13, 10 August 2010 (UTC) |
||
Revision as of 22:18, 10 August 2010
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.
Desired outcome
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.
Views
View by Xeno
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:
- As filer of RFC. –xenotalk 13:28, 10 August 2010 (UTC)
- -DJSasso (talk) 13:45, 10 August 2010 (UTC)
- - ♪ ♫ Wifione ♫ ♪ ―Œ ♣Łeave Ξ мessage♣ 13:53, 10 August 2010 (UTC)
- Resolute 14:01, 10 August 2010 (UTC)
- OrangeDog (τ • ε) 14:33, 10 August 2010 (UTC)
- — HELLKNOWZ ▎TALK 15:13, 10 August 2010 (UTC).
- —Krm500 (Communicate!) 15:18, 10 August 2010 (UTC)
- Der Wohltemperierte Fuchs(talk) 15:57, 10 August 2010 (UTC)
- Garion96 (talk) 16:11, 10 August 2010 (UTC)
- Atama頭 17:43, 10 August 2010 (UTC)
- Dodoïste (talk) 19:05, 10 August 2010 (UTC)
View by SarekOfVulcan
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:
- SarekOfVulcan (talk) 13:40, 10 August 2010 (UTC)
- 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)
- --Cybercobra (talk) 21:29, 10 August 2010 (UTC)
- But conversely also not to include them as a general rule. Sandstein 21:47, 10 August 2010 (UTC)
View by Wnt
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:
- Wnt (talk) 14:30, 10 August 2010 (UTC)
- I agree that the existing implementation of microformats is by-and-large confusing to the average editor. –xenotalk 15:03, 10 August 2010 (UTC)
- 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)
View by OrangeDog
While metadata is a good thing to have, there are a number of problems with the current practices on Wikipedia.
- 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)
- Clarification - I am referring to the fact that
- 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)
- Over-usage of metadata in all it's 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. - 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:
- OrangeDog (τ • ε) 14:33, 10 August 2010 (UTC)
- A well-stated encapsulation of my concerns. –xenotalk 14:36, 10 August 2010 (UTC)
- ♪ ♫ Wifione ♫ ♪ ―Œ ♣Łeave Ξ мessage♣ 14:52, 10 August 2010 (UTC)
- -DJSasso (talk) 14:59, 10 August 2010 (UTC)
- 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)
- 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)
- 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)
- Indeed. Especially point 4. Garion96 (talk) 16:12, 10 August 2010 (UTC)
- 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)
- I agree with 2 and 3 in particular. Dodoïste (talk) 19:07, 10 August 2010 (UTC)
- Hits the key issues right on the head. —fetch·comms 20:12, 10 August 2010 (UTC)
- 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)
View by Nihiltres
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:
- {{Nihiltres|talk|edits|⚡}} 20:49, 10 August 2010 (UTC)
- SarekOfVulcan (talk) 20:51, 10 August 2010 (UTC)
- --Cybercobra (talk) 21:32, 10 August 2010 (UTC)
- Sandstein 21:54, 10 August 2010 (UTC)
View by Sandstein
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:
- As proposer. Sandstein 21:46, 10 August 2010 (UTC)
- 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. –xenotalk 22:18, 10 August 2010 (UTC)
- 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)
View by ExampleUser
Users who endorse this summary:
Reminder to use the talk page for discussion
All signed comments and talk not related to an endorsement should be directed to this page's discussion page. Discussion should not be added below. Discussion should be posted on the talk page. Threaded replies to another user's vote, endorsement, evidence, response, or comment should be posted to the talk page.