Microformats Wiki - User contributions [en]

HCalendarFAQ

2008-11-28T12:28:52Z

Gazza: Remove double redirect

#REDIRECT [[hcalendar-FAQ]]

HCalendar

2008-11-28T12:28:13Z

Gazza: Remove double redirect

#REDIRECT [[hcalendar]]

browsers

2008-11-28T12:25:21Z

Gazza: /* built in */ Firefox 3 is now here

<h1>browsers</h1>

The following web browsers have either built-in support for microformats, or can be extended with plugins etc. for support:

== built in ==
* [[Flock]]
* [[Firefox]] 3

== with plugins ==
* [[Firefox]] 1.5-2.x
** [[Operator]]
** [[Tails]]
* [[Safari]] (coming soon)
* [[Internet Explorer]] 7+

== with favelets ==
See [[favelets]] to get the favelets themselves.
* [[Camino]]
* [[Internet Explorer]]
* [[Firefox]]
* [[Safari]]

== see also ==
* [[implementations]]
* [[user interfaces]]

User talk:Gazza

2008-11-28T12:23:30Z

Gazza:

I've made the following changes:
<div class="discussion">
* All links to users had the User: bit inserted.
* I checked to see if the User page already existed under a variation of the linked name.
** Please create redirects instead at the targets of the links to the appropriate User: pages. See updated [[how-to-play]]. Thanks much for your patience and understanding.
* By doing this, I could go along and put "..." on the User pages. This stops the names from appearing in red, but more importantly, removes that link from the Wanted pages, leaving a cleaner look at really what '''are''' the wanted pages.
** It is better that the links remain red. Users (or others) may never figure out that they need to or should replace the "...".
* The Wanted pages list went from ~120 down to ~50.
** It's ok to have a high "wanted pages list".
* The "..." might encourage those users to put something meaningful on their User page.
** I doubt it. If anything, the absence of red links to their names will make it *less obvious* that they should add something to their User page. [[User:Tantek|Tantek]] 17:45, 1 May 2007 (PDT) (for above nested comments also, please feel free to remove all my comments here and rewrite your user page accordingly.)
* If they do, then the links on the various discussion pages become more useful.

* Note that no links were removed from any pages (that's for someone else with more authority than me to do), just tweaked.
</div>
--[[User:Gazza|Gazza]] 06:10, 1 May 2007 (PDT)

xfn-brainstorming

2008-11-28T11:08:52Z

Gazza: /* ancestor descendant */ Adding syntax highlighting

<h1> XFN Brainstorming </h1>
{{TOC-right}}
This page is for brainstorming about various uses and details of [[XFN]], as well as collecting input for potential extensions.

== Required Reading ==
Before participating in any XFN brainstorming please read and understand the following:
* [http://gmpg.org/xfn/intro XFN intro]
* [http://gmpg.org/xfn/background XFN background]
* [[xfn-faq|XFN FAQ]]
* [http://gmpg.org/xfn/and XFN and other services]
* [[rel-faq]]

Note that all existing XFN values were based on research that showed real world sites that indicated such relationships explicitly via text and hyperlinks to other sites. Thus any new semantics or values will be more seriously considered if URLs demonstrating existing text labeling and hyperlinking behavior are provided.

== Contributors ==
* [http://tantek.com/ Tantek Çelik]
* [[User:CiaranMc |CiaranMc ]]
* [http://factoryjoe.com/ Chris Messina]
* [http://kevinmarks.com/ Kevin Marks]

== general ==
* [[xfn-wants]]

== Identity Consolidation ==
See [[rel-me]] and [[identity-consolidation]].  

=== Indicating non-identity ===
I think we need a way to indicate that another page should not be consolidated into your identity. - KevinMarks

==== common name disambiguation ====
If you have a common name, creating a disambiguation page or pages to indicate which ones aren't you is useful for indexers and people alike. In fact there are examples of people already creating such a page and linking to pages that are not them. Real world use cases that would benefit:
* Kevin Kelly (the former Wired editor) has put together a page to indicate [http://kevinkelly.name|other people also called "Kevin Kelly"].
* [http://vadim.com Vadim Akslerod] has created a page of [http://vadim.com/vadim/ Vadims on the Net] that link to other people called Vadim.

==== accidental or malicious rel-me links ====
If someone accidentally or maliciously links to one of my pages with rel="me" it would be good to be able to actually deny the connection, rather than just passively not link back. See [http://socialgraph-resources.googlecode.com/svn/trunk/samples/findyours.html?q=kevinmarks.com | the social graph API results for kevinmarks.com] for examples. - KevinMarks

This appears to be more of a theoretical use case (as compared to the common name disambiguation) because the real world use ''is'' to simply '''not''' link back, and I don't think we should encourage people to add links to things that are not them, nor are they likely to, especially if it is a spammer/stalker/griefer that is linking to them. - [[User:Tantek|Tantek]]

==== notme proposal ====
initial proposal: <code>rel="notme"</code>, though very open to better suggestions.

== Extending family relationships ==

=== grandparent ===
<cite>[http://www.gmpg.org/xfn/background The XFN: Background page]</cite> says:
<blockquote>
We considered adding "grandparent," but in the end dropped the term because it seemed unlikely to be used in the near future. It may appear in future versions of XFN.
</blockquote>

Presumably the assumption is that a grandparent won't have a website, but:

* I think it's important in some situations to capture the age difference in a relationship in a way that @rel="kin" doesn't seem to.
** ''follow-up'': XFN is the wrong place to represent age information (even relative). Instead, mark up each person's page with an hCard for them that has a <code>bday</code> property, with even just the year if you want - that could then be used to determine an approximate age difference, which is presumably all that is desired. Thus rel="kin" can be considered to be sufficient for now.
*** ''rel-kin'' with an age difference of, say, 45 years, might represent any of parent, grandparent, uncle, sibling, cousin or more.

To date, no real world examples have been documented, thus, per the microformats [[process]], we should not complicate a format for a theoretical need. However, anyone that cares to pursue this may find some real world examples to document in the following web searches: [http://www.google.co.uk/search?&q=%22my+grandpa%27s+website%22 "my grandpa's website"], [http://www.google.co.uk/search?&q=%22my+grandfather%27s+website%22 "my grandfather's website"], [http://www.google.co.uk/search?&q=%22my+grandma%27s+website%22 "my grandma's website"], [http://www.google.co.uk/search?&q=%22my+grandmother%27s+website%22 "my grandmother's website"]. See also [[genealogy-examples]].

=== ancestor descendant ===
Even if they don't maintain it themselves (or are deceased) there might be a URL that does a good job of representing a person.

Consider a site about one's family tree. It might have something like:
<source lang="html4strict">
I can trace my family back to <a href="http://en.wikipedia.org/wiki/William_I_of_England">William the conqueror.</a>
</source>
In these cases it would be useful to have @rel="ancestor", and perhaps a corresponding @rel="descendant".
-CiaranMc

See also: [[genealogy-brainstorming#Relationships]]

* follow-up: rel="kin" can be considered to be sufficient for now.

So far only a couple of (representative) real world examples (from just one site) have been provided, thus, per the microformats [[process]], we should not complicate a format for a need clearly outside of the 80/20. Examples from Wikipedia: [http://en.wikipedia.org/wiki/Winston_Churchill#Family_and_early_life Winston Churchill, with list if ancestors], [http://en.wikipedia.org/wiki/Elizabeth_II_of_the_United_Kingdom#Marriage Queen Elizabeth II]: refers to "Queen Victoria as [her] great-great-grandmother". See also [[genealogy-examples]].

== Simple Groups and Members ==
A very simple extension to XFN could enable decentralized group membership. E.g.
* rel="group". A person could link from their page to the page of a group that they belong to (e.g. their company, school, DJ collective etc.) and thus assert that they belong to that group.
* rel="member". The web pages of groups could link to who they consider members and thus assert that person's membership.

The relationships could be required bi-directional in order to confirm group membership, that is, both the individual must link to the group with rel="group" and the group must link to the individiual with rel="member" in order for the membership to be considered "true".

See also [[group-brainstorming]] for more on this including documentation of examples.

== fans and followers ==
It's becoming a common aspect of many social networks (see list below) that you have unreciprocated and non-friend-based connections to people. These connections are particularly noteworthy where you don't really ever expect to have your connections reciprocated, but instead are similar to the idea of "rel-muse".

=== fan follower examples ===
Sites that have the semantic / implied-schema of "fan" or "follower")
* http://crowdvine.com/ (has fans and mutual fans and want to meet)
* http://pownce.com/ (has fans vs friends)
* http://twitter.com/ (has followers vs friends)
* http://upcoming.org/ (has fans vs friends)
* http://www.sugarloot.com (has Fans vs Favorites)

=== possible inverse of fan terms ===
Brainstorm list of possible terms (for an inverse of fan/follower):
* source
** +1 I like this as a neutral term, <s>except that it would be better kept as a rel value for atom:source in [[hAtom]]</s> (on re-reading the Atom spec, atom:source should be a class on a containing element) [[User:Kevin Marks|Kevin Marks]]
* influence
* influencer
** +1 [[User:Tantek|Tantek]] - I like this one the best so far, as it seems to represent the implied semantics the best. If I follow someone, then they are an "influencer" to me.
** -1 Sounds like "influenza", and just because I follow someone, doesn't mean they influence me. [[User:Gazza|Gazza]]
** -1 - influence can be negative as well as positive: "The child only shoplifted because he was under the influence of older boys". [[User:AndyMabbett|Andy Mabbett]] 01:04, 26 Jan 2008 (PST)
** +1 This seems strong; the relationship is not meant to imply an endorsement; we have [[vote-links]] for that [[User:Kevin Marks|Kevin Marks]] 14:30, 24 Mar 2008 (PDT)
** -1 This value is assigned one of 2 ways; arbitrarily by app, or by the user. I don't trust an app to make a decision on what constitutes an ''influencer'' and I don't see a user choosing that in its current wording --[[User:Donohoe|Donohoe]] 19:55, 5 Aug 2008 (PDT)
* leader
* star
* hero
* favorite
* guider
* role-model
* idol
** -1 [[User:Tantek|Tantek]] These all seem too strong and sometimes imply more subordination than most people want.
* subscription
** +1 Tony Stubblebine
** +1 this one seems most neutral to me (a good thing) [[User:STHayden|STHayden]] 08:35, 3 Mar 2008 (PST)
** -1 this makes sense in a feed-reader context, but not necessarily in a blogroll one; it implies the content rather than the person [[User:Kevin Marks|Kevin Marks]] 14:30, 24 Mar 2008 (PDT)
** +1 Was neutral, now in favor --[[User:Donohoe|Donohoe]] 19:11, 6 Aug 2008 (PDT)
** -1 against for same reasons as Kevin Marks. And "subscription" doesn't sound like a term for a person. -- [[User:Tantek|Tantek]]
* of-interest
* interest
* followee
* focus
* following - as the singular of "followings". If someone is one of your "followings", then you are following that someone, as opposed to if someone is one of your "followers", then that someone is following you! It may sound a bit clumsy/awkward as a term at first, but I think that's actually a sign of novel usage, which has some appeal because then it means the term may be available for us to fill it with this meaning - or I should say, amplify this meaning as it [http://search.twitter.com/search?q=followings has been given by existing Twitter users].
** +1 [[User:Tantek|Tantek]] '''following''' is the best term I have seen for the inverse of fan/follower, and paired with '''follower''', provides a good enough complementary pair of relationships to express both directions.
** Note that Google has now [http://buzz.blogger.com/2008/08/show-off-your-followers.html adopted the "follow" terminology]. -- [http://factoryjoe.com/ Chris Messina]
** ...

=== rejected fan follower terms ===
==== rel-fan ====
<div class="discussion">
I would propose adding "rel-fan" or "rel-follower" to the collection of XFN values -- as being something like a "contact" or a "muse" but having a different purpose within the realm of social networking. Again, given that this is showing up in social networks like Pownce (fan), Twitter (follower), and that these words are becoming common, I wonder if it wouldn't make sense to even ditch rel-muse in favor of rel-follower and rel-fan (the former implying some kind of positive social stalking and the latter a kind of amiable appreciation for someone's work).

This fan/follower designation seems sorely lacking from Flickr where not everyone falls into either contact, friend or family... but in many cases, you just like someone's photos and want to be able to check in on them every now and again, similar to the way that people "follow" or "subscribe" to blog feeds... Someone who reads my blog feed could be considered a "follower" -- as in, "someone who follows my blog".

- Chris Messina

Chris, rel-fan or rel-follower would work for you to point to people who follow you, but the converse case is probably more useful, saying who you follow (eg blogroll case too). We need a good noun for that relationship that describes how you view them, that is less coloured than 'muse' currently is by being classified as romantic. rel-source or rel-influence maybe? Very hard to come up with a good noun.

[[User:Kevin Marks|Kevin Marks]] 12:57, 17 Aug 2007 (PDT)

* Hence the existence of the HTML "rev" attribute. [[User:TobyInk|TobyInk]] 00:12, 25 Feb 2008 (PST)
** The [[rel-faq#Should_rev_even_be_used|use of rev has been deprecated]] since authors nearly always get it wrong. [[User:Tantek|Tantek]] 10:32, 6 Aug 2008 (PDT)
*** I'm not suggesting that we create a new microformat using rev — I'm pointing out that if we define <code>rel=fan</code> (for linking to your fans) then <code>rev=fan</code> "automatically pops into meaning". (Besides which the usually quoted evidence of rev being "confusing" to authors (i.e. Google's analysis) is flaky at best.) [[User:TobyInk|TobyInk]] 15:26, 6 Aug 2008 (PDT)
**** Suggesting the use of <code>rev=fan</code> (as you just did) *is* creating a new microformat using rev, so yes, you are suggesting it. And Google's analysis backed up many years of my (and others') personal anecdotal experience with web developers where >90% did not understand the difference between rel and rev. [[User:Tantek|Tantek]] 17:53, 6 Aug 2008 (PDT)
***** My point is that as per the [http://www.w3.org/TR/REC-html40/struct/links.html#adef-rev HTML 4 definition of <code>rev</code>] any time anyone defines a new link type <code>rel=''X''</code>, the meaning of <code>rev=''X''</code> becomes defined too. This is unavoidable. We should define new link types in terms of <code>rel</code> rather than <code>rev</code> for clarity, but we can't prevent people from taking advantage of the facilities inherent in (X)HTML to mark up the inverse meaning. (e.g. [http://changelog.ca/log/2005/09/12/proposed-microformats-for-reputation-and-trust-metrics <code>rev=tag</code> mention], [http://singpolyma.net/2007/05/the-state-of-distributed-social-networking/ and again], [http://styrheim.weblogg.no/311005201154_revtags.html and again]) [[User:TobyInk|TobyInk]] 01:17, 7 Aug 2008 (PDT)
</div>

==== rel-reader ====
For blogrolls at least, what about rel-read / rel-reader? -- [[User:SteveIvy|Steve Ivy]]

Steve, "read" is still a verb (and [[rel-values]] need to be nouns), and "reader" would still imply that they are a "reader" of yours, rather than vice versa. -- [[User:Tantek|Tantek]]

==== rel-subscriber ====
What about ''subscriber'' instead - also very neutral and more akin to others in the list? --[[User:Donohoe|Donohoe]] 19:55, 5 Aug 2008 (PDT)

"subscriber" is no different from "reader" in this respect, and means the *opposite* of what we are looking for. I.e. a rel="subscriber" link to someone would mean that someone is a subscriber of my content/feed. -- [[User:Tantek|Tantek]]

== favorites ==
Another possibility is perhaps 'favorite', that is, people do link to favorite bands for example, which is similar to saying they are a fan of the band. Thus you could add <code>rel="favorite"</code> to such hyperlinks to indicate that that music band over there is a favorite of yours. [[User:Tantek|Tantek]] 17:57, 2 Oct 2007 (PDT) based on a question raised by DanBri.

== mentors and mentees ==
Though seemingly rare, I personally have found use for <code>rel="mentor"</code> and inverse <code>rel="mentee"</code> (see Wiktionary definitions: [http://en.wiktionary.org/wiki/mentor mentor], [http://en.wiktionary.org/wiki/mentee mentee]). I don't have sufficient evidence to even consider proposing adding these to XFN, but I wanted to capture them here as a brainstorm while I look into using them personally and research examples in the wild. I may just use them as [[POSH]] myself.

[[User:Tantek|Tantek]] 02:34, 8 Jul 2007 (PDT)

* +1 Erica OGrady

== advisor and advisee ==
Similarly, I have seen folks reference someone as an advisor, or note that they are advising someone. We could consider <code>rel="advisor"</code> and <code>rel="advisee"</code> to capture and represent these semantics.

Note that the relationship of advising a company or organization would be much better captured by noting "advisor" as a "role" property value in an hCard listing that organization, e.g.:
<pre><nowiki>

Tantek Çelik
Citizen Agency
advisor

</nowiki></pre>

Again, I think [[POSH]] usage of these terms would make a good experiment to see if there is sufficient use to formalize them.

[[User:Tantek|Tantek]] 07:45, 29 Dec 2007 (PST)

== Influence out and influenced in ==

Needing to provide more options to describe the flow of influence I've been considering the following relationship terms that fall into two predicate groups, influence out(applied) and influence in(received).

Influence out:
* 'follower'
* 'student'
* 'subscriber'
* 'listener'
* 'reader'
* 'viewer'
* 'supporter'
* 'collaborator'

Influence in:
* 'inspiration'
* 'favourite'
* 'teacher'
* 'mentor'
* 'adviser'
* 'influence'
* 'source'
* 'collaborator'

Inline with xfn convention the terms are all nouns and refer to the far side of the link they are used in.

[[User:James Tindall|James Tindall]] 14:23, 31 Aug 2008 (BST)

== scholarly ==
A possibility that might be added is scholarly definitions. For example <code>rel="mentor"</code>[Student's Teacher] (similar to above), <code>rel="student"</code>[Teacher's Student] (inverse of mentor), <code>rel="classmate"</code>[Student's classmate]. Possible uses in Social Networking sites that involve adding your school, grading your teachers, etc. Teacher <-> Teacher would be specified in with <code>rel="co-worker"</code> or <code>rel="colleague"</code>.

[[User:Navarr|Navarr]] 05:56, 13 Dec 2007 (CST)

== professional ==
* [[xpn]] / [[xpn-examples]] - proposal to extend (or replicate) XFN for business (or professional - hence X'''P'''N) relationships

== see also ==
{{xfn-related-pages}}
* [[hcard|hCard]]
* [[hcard-brainstorming|hCard brainstorming]]
* [[social-network-portability]]

xfn-brainstorming

2008-11-28T11:07:28Z

Gazza: /* rel-fan */ Adding discussion div

<h1> XFN Brainstorming </h1>
{{TOC-right}}
This page is for brainstorming about various uses and details of [[XFN]], as well as collecting input for potential extensions.

== Required Reading ==
Before participating in any XFN brainstorming please read and understand the following:
* [http://gmpg.org/xfn/intro XFN intro]
* [http://gmpg.org/xfn/background XFN background]
* [[xfn-faq|XFN FAQ]]
* [http://gmpg.org/xfn/and XFN and other services]
* [[rel-faq]]

Note that all existing XFN values were based on research that showed real world sites that indicated such relationships explicitly via text and hyperlinks to other sites. Thus any new semantics or values will be more seriously considered if URLs demonstrating existing text labeling and hyperlinking behavior are provided.

== Contributors ==
* [http://tantek.com/ Tantek Çelik]
* [[User:CiaranMc |CiaranMc ]]
* [http://factoryjoe.com/ Chris Messina]
* [http://kevinmarks.com/ Kevin Marks]

== general ==
* [[xfn-wants]]

== Identity Consolidation ==
See [[rel-me]] and [[identity-consolidation]].  

=== Indicating non-identity ===
I think we need a way to indicate that another page should not be consolidated into your identity. - KevinMarks

==== common name disambiguation ====
If you have a common name, creating a disambiguation page or pages to indicate which ones aren't you is useful for indexers and people alike. In fact there are examples of people already creating such a page and linking to pages that are not them. Real world use cases that would benefit:
* Kevin Kelly (the former Wired editor) has put together a page to indicate [http://kevinkelly.name|other people also called "Kevin Kelly"].
* [http://vadim.com Vadim Akslerod] has created a page of [http://vadim.com/vadim/ Vadims on the Net] that link to other people called Vadim.

==== accidental or malicious rel-me links ====
If someone accidentally or maliciously links to one of my pages with rel="me" it would be good to be able to actually deny the connection, rather than just passively not link back. See [http://socialgraph-resources.googlecode.com/svn/trunk/samples/findyours.html?q=kevinmarks.com | the social graph API results for kevinmarks.com] for examples. - KevinMarks

This appears to be more of a theoretical use case (as compared to the common name disambiguation) because the real world use ''is'' to simply '''not''' link back, and I don't think we should encourage people to add links to things that are not them, nor are they likely to, especially if it is a spammer/stalker/griefer that is linking to them. - [[User:Tantek|Tantek]]

==== notme proposal ====
initial proposal: <code>rel="notme"</code>, though very open to better suggestions.

== Extending family relationships ==

=== grandparent ===
<cite>[http://www.gmpg.org/xfn/background The XFN: Background page]</cite> says:
<blockquote>
We considered adding "grandparent," but in the end dropped the term because it seemed unlikely to be used in the near future. It may appear in future versions of XFN.
</blockquote>

Presumably the assumption is that a grandparent won't have a website, but:

* I think it's important in some situations to capture the age difference in a relationship in a way that @rel="kin" doesn't seem to.
** ''follow-up'': XFN is the wrong place to represent age information (even relative). Instead, mark up each person's page with an hCard for them that has a <code>bday</code> property, with even just the year if you want - that could then be used to determine an approximate age difference, which is presumably all that is desired. Thus rel="kin" can be considered to be sufficient for now.
*** ''rel-kin'' with an age difference of, say, 45 years, might represent any of parent, grandparent, uncle, sibling, cousin or more.

To date, no real world examples have been documented, thus, per the microformats [[process]], we should not complicate a format for a theoretical need. However, anyone that cares to pursue this may find some real world examples to document in the following web searches: [http://www.google.co.uk/search?&q=%22my+grandpa%27s+website%22 "my grandpa's website"], [http://www.google.co.uk/search?&q=%22my+grandfather%27s+website%22 "my grandfather's website"], [http://www.google.co.uk/search?&q=%22my+grandma%27s+website%22 "my grandma's website"], [http://www.google.co.uk/search?&q=%22my+grandmother%27s+website%22 "my grandmother's website"]. See also [[genealogy-examples]].

=== ancestor descendant ===
Even if they don't maintain it themselves (or are deceased) there might be a URL that does a good job of representing a person.

Consider a site about one's family tree. It might have something like:

I can trace my family back to
<a href="http://en.wikipedia.org/wiki/William_I_of_England">
William the conqueror.
</a>

In these cases it would be useful to have @rel="ancestor", and perhaps a corresponding @rel="descendant".
-CiaranMc

See also: [[genealogy-brainstorming#Relationships]]

* follow-up: rel="kin" can be considered to be sufficient for now.

So far only a couple of (representative) real world examples (from just one site) have been provided, thus, per the microformats [[process]], we should not complicate a format for a need clearly outside of the 80/20. Examples from Wikipedia: [http://en.wikipedia.org/wiki/Winston_Churchill#Family_and_early_life Winston Churchill, with list if ancestors], [http://en.wikipedia.org/wiki/Elizabeth_II_of_the_United_Kingdom#Marriage Queen Elizabeth II]: refers to "Queen Victoria as [her] great-great-grandmother". See also [[genealogy-examples]].

== Simple Groups and Members ==
A very simple extension to XFN could enable decentralized group membership. E.g.
* rel="group". A person could link from their page to the page of a group that they belong to (e.g. their company, school, DJ collective etc.) and thus assert that they belong to that group.
* rel="member". The web pages of groups could link to who they consider members and thus assert that person's membership.

The relationships could be required bi-directional in order to confirm group membership, that is, both the individual must link to the group with rel="group" and the group must link to the individiual with rel="member" in order for the membership to be considered "true".

See also [[group-brainstorming]] for more on this including documentation of examples.

== fans and followers ==
It's becoming a common aspect of many social networks (see list below) that you have unreciprocated and non-friend-based connections to people. These connections are particularly noteworthy where you don't really ever expect to have your connections reciprocated, but instead are similar to the idea of "rel-muse".

=== fan follower examples ===
Sites that have the semantic / implied-schema of "fan" or "follower")
* http://crowdvine.com/ (has fans and mutual fans and want to meet)
* http://pownce.com/ (has fans vs friends)
* http://twitter.com/ (has followers vs friends)
* http://upcoming.org/ (has fans vs friends)
* http://www.sugarloot.com (has Fans vs Favorites)

=== possible inverse of fan terms ===
Brainstorm list of possible terms (for an inverse of fan/follower):
* source
** +1 I like this as a neutral term, <s>except that it would be better kept as a rel value for atom:source in [[hAtom]]</s> (on re-reading the Atom spec, atom:source should be a class on a containing element) [[User:Kevin Marks|Kevin Marks]]
* influence
* influencer
** +1 [[User:Tantek|Tantek]] - I like this one the best so far, as it seems to represent the implied semantics the best. If I follow someone, then they are an "influencer" to me.
** -1 Sounds like "influenza", and just because I follow someone, doesn't mean they influence me. [[User:Gazza|Gazza]]
** -1 - influence can be negative as well as positive: "The child only shoplifted because he was under the influence of older boys". [[User:AndyMabbett|Andy Mabbett]] 01:04, 26 Jan 2008 (PST)
** +1 This seems strong; the relationship is not meant to imply an endorsement; we have [[vote-links]] for that [[User:Kevin Marks|Kevin Marks]] 14:30, 24 Mar 2008 (PDT)
** -1 This value is assigned one of 2 ways; arbitrarily by app, or by the user. I don't trust an app to make a decision on what constitutes an ''influencer'' and I don't see a user choosing that in its current wording --[[User:Donohoe|Donohoe]] 19:55, 5 Aug 2008 (PDT)
* leader
* star
* hero
* favorite
* guider
* role-model
* idol
** -1 [[User:Tantek|Tantek]] These all seem too strong and sometimes imply more subordination than most people want.
* subscription
** +1 Tony Stubblebine
** +1 this one seems most neutral to me (a good thing) [[User:STHayden|STHayden]] 08:35, 3 Mar 2008 (PST)
** -1 this makes sense in a feed-reader context, but not necessarily in a blogroll one; it implies the content rather than the person [[User:Kevin Marks|Kevin Marks]] 14:30, 24 Mar 2008 (PDT)
** +1 Was neutral, now in favor --[[User:Donohoe|Donohoe]] 19:11, 6 Aug 2008 (PDT)
** -1 against for same reasons as Kevin Marks. And "subscription" doesn't sound like a term for a person. -- [[User:Tantek|Tantek]]
* of-interest
* interest
* followee
* focus
* following - as the singular of "followings". If someone is one of your "followings", then you are following that someone, as opposed to if someone is one of your "followers", then that someone is following you! It may sound a bit clumsy/awkward as a term at first, but I think that's actually a sign of novel usage, which has some appeal because then it means the term may be available for us to fill it with this meaning - or I should say, amplify this meaning as it [http://search.twitter.com/search?q=followings has been given by existing Twitter users].
** +1 [[User:Tantek|Tantek]] '''following''' is the best term I have seen for the inverse of fan/follower, and paired with '''follower''', provides a good enough complementary pair of relationships to express both directions.
** Note that Google has now [http://buzz.blogger.com/2008/08/show-off-your-followers.html adopted the "follow" terminology]. -- [http://factoryjoe.com/ Chris Messina]
** ...

=== rejected fan follower terms ===
==== rel-fan ====
<div class="discussion">
I would propose adding "rel-fan" or "rel-follower" to the collection of XFN values -- as being something like a "contact" or a "muse" but having a different purpose within the realm of social networking. Again, given that this is showing up in social networks like Pownce (fan), Twitter (follower), and that these words are becoming common, I wonder if it wouldn't make sense to even ditch rel-muse in favor of rel-follower and rel-fan (the former implying some kind of positive social stalking and the latter a kind of amiable appreciation for someone's work).

This fan/follower designation seems sorely lacking from Flickr where not everyone falls into either contact, friend or family... but in many cases, you just like someone's photos and want to be able to check in on them every now and again, similar to the way that people "follow" or "subscribe" to blog feeds... Someone who reads my blog feed could be considered a "follower" -- as in, "someone who follows my blog".

- Chris Messina

Chris, rel-fan or rel-follower would work for you to point to people who follow you, but the converse case is probably more useful, saying who you follow (eg blogroll case too). We need a good noun for that relationship that describes how you view them, that is less coloured than 'muse' currently is by being classified as romantic. rel-source or rel-influence maybe? Very hard to come up with a good noun.

[[User:Kevin Marks|Kevin Marks]] 12:57, 17 Aug 2007 (PDT)

* Hence the existence of the HTML "rev" attribute. [[User:TobyInk|TobyInk]] 00:12, 25 Feb 2008 (PST)
** The [[rel-faq#Should_rev_even_be_used|use of rev has been deprecated]] since authors nearly always get it wrong. [[User:Tantek|Tantek]] 10:32, 6 Aug 2008 (PDT)
*** I'm not suggesting that we create a new microformat using rev — I'm pointing out that if we define <code>rel=fan</code> (for linking to your fans) then <code>rev=fan</code> "automatically pops into meaning". (Besides which the usually quoted evidence of rev being "confusing" to authors (i.e. Google's analysis) is flaky at best.) [[User:TobyInk|TobyInk]] 15:26, 6 Aug 2008 (PDT)
**** Suggesting the use of <code>rev=fan</code> (as you just did) *is* creating a new microformat using rev, so yes, you are suggesting it. And Google's analysis backed up many years of my (and others') personal anecdotal experience with web developers where >90% did not understand the difference between rel and rev. [[User:Tantek|Tantek]] 17:53, 6 Aug 2008 (PDT)
***** My point is that as per the [http://www.w3.org/TR/REC-html40/struct/links.html#adef-rev HTML 4 definition of <code>rev</code>] any time anyone defines a new link type <code>rel=''X''</code>, the meaning of <code>rev=''X''</code> becomes defined too. This is unavoidable. We should define new link types in terms of <code>rel</code> rather than <code>rev</code> for clarity, but we can't prevent people from taking advantage of the facilities inherent in (X)HTML to mark up the inverse meaning. (e.g. [http://changelog.ca/log/2005/09/12/proposed-microformats-for-reputation-and-trust-metrics <code>rev=tag</code> mention], [http://singpolyma.net/2007/05/the-state-of-distributed-social-networking/ and again], [http://styrheim.weblogg.no/311005201154_revtags.html and again]) [[User:TobyInk|TobyInk]] 01:17, 7 Aug 2008 (PDT)
</div>

==== rel-reader ====
For blogrolls at least, what about rel-read / rel-reader? -- [[User:SteveIvy|Steve Ivy]]

Steve, "read" is still a verb (and [[rel-values]] need to be nouns), and "reader" would still imply that they are a "reader" of yours, rather than vice versa. -- [[User:Tantek|Tantek]]

==== rel-subscriber ====
What about ''subscriber'' instead - also very neutral and more akin to others in the list? --[[User:Donohoe|Donohoe]] 19:55, 5 Aug 2008 (PDT)

"subscriber" is no different from "reader" in this respect, and means the *opposite* of what we are looking for. I.e. a rel="subscriber" link to someone would mean that someone is a subscriber of my content/feed. -- [[User:Tantek|Tantek]]

== favorites ==
Another possibility is perhaps 'favorite', that is, people do link to favorite bands for example, which is similar to saying they are a fan of the band. Thus you could add <code>rel="favorite"</code> to such hyperlinks to indicate that that music band over there is a favorite of yours. [[User:Tantek|Tantek]] 17:57, 2 Oct 2007 (PDT) based on a question raised by DanBri.

== mentors and mentees ==
Though seemingly rare, I personally have found use for <code>rel="mentor"</code> and inverse <code>rel="mentee"</code> (see Wiktionary definitions: [http://en.wiktionary.org/wiki/mentor mentor], [http://en.wiktionary.org/wiki/mentee mentee]). I don't have sufficient evidence to even consider proposing adding these to XFN, but I wanted to capture them here as a brainstorm while I look into using them personally and research examples in the wild. I may just use them as [[POSH]] myself.

[[User:Tantek|Tantek]] 02:34, 8 Jul 2007 (PDT)

* +1 Erica OGrady

== advisor and advisee ==
Similarly, I have seen folks reference someone as an advisor, or note that they are advising someone. We could consider <code>rel="advisor"</code> and <code>rel="advisee"</code> to capture and represent these semantics.

Note that the relationship of advising a company or organization would be much better captured by noting "advisor" as a "role" property value in an hCard listing that organization, e.g.:
<pre><nowiki>

Tantek Çelik
Citizen Agency
advisor

</nowiki></pre>

Again, I think [[POSH]] usage of these terms would make a good experiment to see if there is sufficient use to formalize them.

[[User:Tantek|Tantek]] 07:45, 29 Dec 2007 (PST)

== Influence out and influenced in ==

Needing to provide more options to describe the flow of influence I've been considering the following relationship terms that fall into two predicate groups, influence out(applied) and influence in(received).

Influence out:
* 'follower'
* 'student'
* 'subscriber'
* 'listener'
* 'reader'
* 'viewer'
* 'supporter'
* 'collaborator'

Influence in:
* 'inspiration'
* 'favourite'
* 'teacher'
* 'mentor'
* 'adviser'
* 'influence'
* 'source'
* 'collaborator'

Inline with xfn convention the terms are all nouns and refer to the far side of the link they are used in.

[[User:James Tindall|James Tindall]] 14:23, 31 Aug 2008 (BST)

== scholarly ==
A possibility that might be added is scholarly definitions. For example <code>rel="mentor"</code>[Student's Teacher] (similar to above), <code>rel="student"</code>[Teacher's Student] (inverse of mentor), <code>rel="classmate"</code>[Student's classmate]. Possible uses in Social Networking sites that involve adding your school, grading your teachers, etc. Teacher <-> Teacher would be specified in with <code>rel="co-worker"</code> or <code>rel="colleague"</code>.

[[User:Navarr|Navarr]] 05:56, 13 Dec 2007 (CST)

== professional ==
* [[xpn]] / [[xpn-examples]] - proposal to extend (or replicate) XFN for business (or professional - hence X'''P'''N) relationships

== see also ==
{{xfn-related-pages}}
* [[hcard|hCard]]
* [[hcard-brainstorming|hCard brainstorming]]
* [[social-network-portability]]

question-answer-brainstorming

2008-11-28T11:01:03Z

Gazza: /* Multi-page FAQs */ Adding Syntax highlighting

=Questions and Answers=

== Purpose ==

The "question-answer" microformat proposes to formalize the relationships between '''questions and answers''' (including "'''FAQs'''") published within a single HTML document (and possibly a set of documents). Such formalization should allow for reuse of questions and answers in new contexts, e.g. search engines, IM bots, etc.

==Multi-page FAQs==
Based on [http://www.nhs.uk/England/NoAppointmentNeeded/WalkInCentres/Default.aspx] (extraneous detail omitted)

Current mark-up:

<source lang=html4strict>
<a href="/england/noappointmentneeded/walkincentres/walkincentreservices.cmsx">What services does a Walk-in Centre
offer?</a>
</source>

Possible solution (tentative class-names):

<source lang=html4strict>
<a href="/england/noappointmentneeded/walkincentres/walkincentreservices.cmsx" class="question answer-at">What services
does a Walk-in Centre offer?</a>
</source>

More about this possible solution:

(FAQ-LIST)
<source lang=html4strict>
<ul class="faq-list">
<li><a class="question answer-at" href="faq1.htm">What are the microformats?</a></li>
<li><a class="question answer-at" href="faq2.htm">Who can use the microformats? </a></li>
<li><a class="question answer-at" href="faq3.htm">How can we use the microformats? </a></li>
</ul>
</source>

(FAQ-PAGE)
<source lang=html4strict>
<div class="faq">
<h1 class="question">What are the microformats?</h1>
Microformats are an implementation...
</div>
</source>

(FAQ-NAVIGATION-MENU)
<source lang="html4strict">
<ul class="faq-navigation">
<li><a href="faq1.htm" class="faq-previous question answer-at">What are the microformats?</a> (Previous in
faq-list)</li>
<li><a href="faq3.htm" class="faq-next question answer-at">How can we use the microformats?</a> (Next in
faq-list)</li>
</ul>
</source>

==Interview Questions and Answers==

A lively discussion on [http://www.quirksmode.org/blog/archives/2007/07/should_intervie_1.html Quirksmode] didn't resolve the issue, but the most convincing argument was made by Eric Myers at comment #7. The answer to a question is semantically a blockquote. The question itself is just text, assuming the author asked the question, so a paragraph is what's called for. Combine that with comment #13, which suggest the use of EM to provide a different voice for the question, and you're halfway there. What remains is to work in the names of the speakers. The CITE tag isn't ideal for identifying the speaker (it's not quite a reference to another source), but it's the only tag that makes sense with a blockquote. That just leaves a tag for the identity of the interviewer. But since the interviewer is also the author, the byline at the top of the page should do the trick. So to sum up, here's a proposed solution:

:<nowiki>What is your quest?</nowiki>
:<nowiki><blockquote><cite>Sir Launcelot:</cite> To seek the Holy Grail.</blockquote></nowiki>

:<nowiki>What is your favorite color?</nowiki>
:<nowiki><blockquote><cite><abbr title="Sir Launcelot">SL:</abbr></cite> Blue.</blockquote></nowiki>

If it is important that the format be portable across sites, then I would also propose adding class="question" in the P tag and class="answer" in the blockquote, although I tend to think the format is cleaner without those classes.

* The content model for <code><blockquote></code> is <code>(%block;|SCRIPT)+</code>. That is, it may only contain the <code><script></code> element (I wonder why?) and block level elements such as <code></code>. Inline elements like <code><cite></code>, and CDATA are not allowed directly within a <code><blockquote></code>. I've fixed the example to be a valid fragment. [[User:TobyInk|TobyInk]] 02:57, 28 Mar 2008 (PDT)

==hFeed==
FAQs could be marked up as, or using a variant of, [[hatom|hAtom]], with the question being the entry title and the answer the content. [[User:AndyMabbett|Andy Mabbett]]

hfeed (hAtom) is a good candidate, however, one thing is lacking...the key concept of a q/a. The value of a q/a format is for agregating questions and answers. If hAtom can indicate that it's contents are q/a it would be perfect.
[[User:TaylorCowan|Taylor Cowan]]

== See also ==

* [[question-answer-examples]]
* [[question-answer-formats]]

currency-brainstorming

2008-11-28T10:46:02Z

Gazza: /* Gary Jones */ Using Syntax highlighting

== Brainstorming ==

Brainstorming for the proposed [[currency]] microformat.

===Ken Griffith===

Ben B's system is the most extensible of the proposals here, though it might be problematic to insert it as an inline element in a paragraph that mentions a currency amount. It would be preferable to use only inline elements.

Regarding currency codes, it will be important to use an extensible code system. ISO 4217 is great for listing national currencies. However, we need to look at how people actually use currency for transactions on the web. There are a lot of businesses and people using systems like e-gold, Webmoney, etc - several billion dollars equivalent in annual transactions - a small but steadily growing percentage of web transactions. So there should be a currency code list somewhere that can be extended beyond ISO 4217 to include private issue currency units that people actually use on the web.

===Ben Buchanan===
Verbose but extensible and explicitly defines all values (without breaking DRY):

<pre><div class="currency">

code
symbol
12345

</div></pre>
"figure" is there to both explicitly associate the code, sign and amount but also allow the potential for more than one currency figure to be placed within the container. It does anticipate further development though and is the most easily dropped item at the early stage.

Without figure:
<pre><div class="currency">
code
symbol
12345
</div></pre>

Super shortened, relying on the parser to identify everything via implied order/structure:

<pre><div class="currency">ABC12345$</div></pre>

Although the simplest solution, it has a notable vulnerability: some currencies have/had three-letter abbreviations for their currency sign, instead of a symbol. This would make it very difficult for a parser to accurately identify such a currency.
In addition, it should be noted that the order alone cannot be used to identify which parts are code, sign and amount; since many currencies are denoted with the sign after the number.

Super shortened, but specifying a currency code as a class:

<pre><div class="currency ABC">12345$</div></pre>

It defines...

<ol type="a">
<li>we're talking about money - ISO standard implied,</li>
<li>we're talking about the USD variety,</li>
<li>we're talking fifty units of that money,</li>
<li>a parser could work out the numbers and the symbol.</li>
</ol>

The biggest limitation I can see for that shorthand is that the currency code is not displayed visibly to human readers. The currency code is useful information to viewers and ideally should be displayed.

Shortened (including dropping 'figure', but explicitly defining and displaying the currency code. This would allow a parser to treat any remaining numbers as the amount; and any remaining a-z or symbol as the sign:

<pre><div class="currency">
ABC12345$
</div></pre>

===Charles Iliya Krempeaux===
Maybe something like...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

Although something like the the following might be better...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though.

=== Ben Ward ===
Could pure HTML be sufficient?
<pre><html lang="en-gb">
My new T-Shirts cost £30, but it cost my friend in Canada $34
</html></pre>

===Arve Bersvendsen ===
<pre>Den kanadiske prisen på t-skjorten var 34 $.</pre>

=== Mike Stickel ===
<pre><abbr class="currency" title="CAD eng">$</abbr>5.00</pre>
In this format the wrapping would be "money" or something similar followed by either the actual "amount" or the "currency", depending on what rules your country/language follows in regards to the order.
Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the "currency" definition of the formating, eg., "CAD eng" or "CAD fr".
It could also give sites that list multiple languages a way to differentiate when they show multiple prices.

:Good idea, but shouldn't a Microformat use existing markup for language attributes, eg.

:<pre><abbr class="currency" title="CAD" lang="en">$</abbr>5.00</pre>

:Reference [http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1 w3.org: 8.1 Specifying the language of content: the lang attribute]
:[[User:Bob Jonkman|Bob Jonkman]] 22:26, 12 Oct 2006 (PDT)

=== Ciaran McNulty ===
The only microformat that I've noticed currency units in is [[hlisting-proposal|hListing]], and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats.

My own preference would be for something like:
<pre>This item costs
GBP
10.00
</pre>

Which with similar parsing rules to existing formats would also allow things like:
<pre>
It'll cost you
<abbr class="currency" title="50.00">fifty</abbr>
<abbr class="amount" title="GBP">quid</abbr>
, mate!
</pre>
Or, a more complex example with multiple languages:
<pre>
Price:

<abbr class="currency" title="GBP">£</abbr>
1,250.00


(Prix:
1600,00
<abbr class="currency" title="EUR">€</abbr>
)

</pre>

===Andy Mabbett===

====Straw man proposal====

'''Superseded; see [[#Straw_man]], below.'''

(this reflects Ciaran McNulty's proposals, above)

In order to use currency as a sub-class, the parent should be named 'money'

*money - class (required) '''[or "currency"?]'''
**currency - class (required; uses ISO 4217) '''[or "type"?]'''
**amount - class (required) '''[or "value"?]'''
**date - class (optional - for historic values only, in [[datetime-design-pattern]]. Consider inflation in Germany in 1930s!)
**symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent; it will also help user agents to ignore $ and other such symbols, when used for purposes other than to indicate a currency, or to remove them, when translating to a different currency.)
**unit - class (subdivison of currency; use as "symbol")
**<s>equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)</s>

All classes may occur only once, apart from ''symbol'' (to allow for "£14 6s 2d") and ''unit'' (to allow for "five pounds 23 pence").

=====Examples=====
Thus:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>
(note, in the above, that "unit" does not relate directly to the amount in the amount's title abttibute - it's 0.5 pounds, not 0.5 pence.)

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

(The above might be rendered as "... 1/ (worth £4.50 in modern terms" (or whatever the value would be).)

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

The following, simplified for clarity, from [http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

Is there anything sensible which ''can't'' be done with the above?

=====Assumptions=====

*Working out values in secondary currencies is a (real-time or daily) job for server-side scripting or user agents.

*If "£" is an abbreviation, then its title is "pounds sterling"; though note that "£5" is pronounced as "five pounds sterling" (commonly just "five pounds") and not: "pounds sterling five" in the same way that "$5" is pronounced as: "five dollars" and not "dollars five"

=====Issues=====

*There will be complications where the entire currency has disappeared, (such as the last example; French Francs into Euros).

* Where no symbol or unit is involved (chiefly in tables, where they will be in the header cell), should we allow:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money USD amount">42.67</td>
</tr>
</nowiki></pre>

====HTML Entities====

*The following currency entities exist:
**<code>¤</code> - <code>& curren;</code> - currency
**<code>¢</code> - <code>& cent;</code> - cent
**<code>£</code> - <code>& pound;</code> - pound
**<code>¥</code> - <code>& yen;</code> - yen
**<code>€</code> - <code>& euro;</code> - Euro

===Guillaume Lebleu ===

In the context of a hListing's price, without a unit:

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Rendered view:

<abbr class="currency" title="EUR">€</abbr>100

In the context of a hListing's price, with a unit:

<pre>
<abbr class="currency" title="USD">$</abbv>25 per
barrel
</pre>

<pre>
25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>
</pre>

Note: the class "amount" may not always be required, but it is useful when the amount is represented as text, or when the amount is mixed within text. See historical example below.

Rendered view:

<abbr class="currency" title="USD">$</abbr>25 per
barrel

25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>

Outside of the context of a hListing (not all currency amounts are prices, for instance sales numbers):

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Historical price (here currency rate):

<pre>
On <abbr class="datetime"
title="1998-03-12T08:30:00-05:00">August 1</abbr>, the US Dollar still
stood at 643 <abbr class="currency"
title="DEM">Marks</abbr> to the Dollar.
</pre>

In a table:

<pre>
<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>
</pre>

Rendered view:

<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>

=== Gary Jones ===

<source lang=html4strict>

<abbr class="type" title="CAD">$</abbr>
5.00

</source>

Renders as:

<abbr class="type" title="CAD">$</abbr>5.00

If the formatting of a currency is such that the type symbol comes after the value, then simply swap the order of the elements containing the type and value classes.

I do think that the use of "type" and "value" classes would be better than variations of "currency_symbol" and "amount". It follows the same principles as some other elemental formats ([http://microformats.org/wiki/hcard#Value_excerpting value excerpting]), meaning it's [http://microformats.org/wiki/naming-principles#Minimal_Vocabulary easier to remember] and implement, and even ISO4217 has codes for "currencies" that don't use symbols:

<source lang=html4strict>

23 ounces of
<abbr class="type" title="XAG">gold</abbr>

</source>

Renders as:

23 ounces of <abbr class="type" title="XAG">gold</abbr>

Following on from this, the use of a "money" class should not be used; currency does not ''have'' to be money, and having a "metal" class starts to make it convoluted. Currency is the parent of money, not the other way around.

===Mike Schinkel===
I'm taking Andy Mabbett's post and applying my thoughts to his.

Rather than:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

Why not just:

<pre><nowiki>
A widget costs $12.57
</nowiki></pre>

In the above, a number is assumed because their is not an "amount", and the number digit is the currency symbol. I guess what I'm saying is if there is a number in the HTML and it is the correct number (which I think will be the 80 percentile case, give or take, then why require additional markup for it?)

Rather than:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

Just:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="currency" title="USD">42.67</td>
</tr>
</nowiki></pre>

Or:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td>
42.67
</td>
</tr>
</nowiki></pre>

In this case, which is a little more complicated:

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

Why not use the following:

<pre><nowiki>
Can you spare

<abbr class="amount" title="10">ten</abbr>
dollars
?
</nowiki></pre>

Here:

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>

Why not?

<pre><nowiki>
It was worth

<abbr class="amount" title="0.5">50</abbr>
pence
?
</nowiki></pre>

I'm not going to try to mark up the following two since, thus far, [http://www.vizu.com/poll-vote.html?n=15067 no one has voted for dated money amounts or non-numerical representations] (those might be better expressed in their own microformat: ''hHistoricalCurrency''?):

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

I don't understand what this is trying to accomplish (it seems incomplete), so I can't mark it up.

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

Again, I'm not going to try to mark up given [http://www.vizu.com/poll-vote.html?n=15067 the lack of interest in dated money amounts]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

My efforts attempt to minimize the disruption in the HTML file and only use additional markup when absolutely required. I believe some high volume websites still try to minimize the markup they serve, and this is bloated as it it. They may decide just to serve up a few digits rather than 50 character per price, especially on pages with lots of prices.

*The claimed "lack of interest" in dated amounts ignores the [[currency-examples|evidence that such figures are widely published on the web]]. Most of your preceding "why not"s ignore the [[abbr-design-pattern]]. [[User:AndyMabbett|Andy Mabbett]] 07:30, 2 Jan 2007 (PST)

===Taylor Cowan===

Pretending to forget all that we've know up till now about microformats, what if we just wanted a way for web page designers to make their currency amounts unambiguous with respect to currency denomination and amount?

"one hundred bucks"

<pre><abbr class="currency" title="USD100">one hundred bucks</abbr></pre>

$100 (CAD)

<pre><abbr class="currency" title="CAD100">$100</abbr></pre>

10 cents

<pre><abbr class="currency" title="USD0.10">ten cents</abbr></pre>

compare:

<pre>10 <abbr class="unit" title="cent"><abbr
class="currency" title="USD">cents</abbr></abbr></pre>

man Yen

<pre><abbr class="currency" title="JPY10,000">man Yen</abbr></pre>

So within the title, we've got ISO###.##

Then later on we wanted to apply one of those amounts to the "price" of an hListing:

<pre><abbr class="currency price" title="USD100">one hundred bucks</abbr></pre>

==Straw man==

Based on Taylor Cowan's suggestion, above, and on [http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html subsequent mailing list discussion], the following "money" microformat straw man is proposed:

<pre><nowiki>

[value]


<abbr class="hmoney" title="[value]">
[text]
</abbr>
</nowiki></pre>

Where "value" is a number+ISO-code pair ("GBP5", "4 USD") using ISO curency codes and where parsers must accept the formats:

*[currency-code][number]
*[currency-code][space][number]
*[number][currency-code]
*[number]space[currency-code]

and where dated money amounts are included in an hCalendar:

<pre><nowiki>
<div class="vevent">


The last Monet painting to be auctioned

fetched
<abbr class="currency" title="USD95M">$95 million</abbr>
in
2005

</div>
</nowiki></pre>

Further comment is invited. A test page is available, at http://www.westmidlandbirdclub.com/test/money.htm

===Notes===
This works for sub-divisions of currencies:

<pre><nowiki>
<abbr class="currency" title="USD 0.05">
5c
</abbr>
</nowiki></pre>

archaic and non-decimal currencies:

<pre><nowiki>
<abbr class="currency" title="GBP 0.125">two shillings and sixpence</abbr>

<abbr class="currency" title="GBP1.05">a guinea</abbr>
</nowiki></pre>

and slang:

<pre><nowiki>
<abbr class="currency" title="USD 500">five-hundred buckaroos</abbr>

<abbr class="currency" title="USD200">a couple Franklins</abbr>
</nowiki></pre>

===Issues===
*Is hmoney the appropriate class-name?
** hcurrency would be better. [[User:MaxwellTerry|MaxwellTerry]] 19:59, 13 Jan 2008 (PST)
*Is money a separate microformat, or a [[measure]]ment, with the ISO currency code as the unit-code?
** Currency != money; Currency is a superset / parent of money. If we're using ISO codes, then we should be focusing on the currency (not money) it applies to. [[User:Gazza|Gazza]] 18:48, 7 Jan 2008 (PST)
*This is still susceptible to the [[accessibility-issues#abbr-design-pattern]].
*Using amount suffixes such as K, M, B, or T are not necessarily supported by any International Standard. Shouldn't we just say that the complete number should be used in the <nowiki><abbr></nowiki> element? [[User:ManuSporny|ManuSporny]] 12:31, 5 Oct 2007 (PDT)

===Suggested amendments===
*Use just the abbr pattern and format [number]space[currency-code]. We should narrow our focus to make progress. Simplify, simplify, simplify! [[User:ManuSporny|ManuSporny]] 07:16, 5 Oct 2007 (PDT)
**Is this approach too inflexible?
** "5 GBP" is not an abbreviation of "5 GBP". [[User:AndyMabbett|Andy Mabbett]] 09:46, 5 Oct 2007 (PDT)
*** This problem is easily fixed by using <pre>5 GBP</pre> [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)
** People publish amounts as, say, "5GBP" (with no space) in the wild. [[User:AndyMabbett|Andy Mabbett]] 09:49, 5 Oct 2007 (PDT)
*** Yes, they do, however we can still mark that up as <pre><abbr class="hcurrency" title="5 GBP">5GBP</abbr></pre>. You could argue that "5 GBP" is not an abbreviation of "5GBP", which is true - but I believe this is an acceptable compromise, afterall... we would be arguing over a single space character, which seems a bit pedantic. [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)

==References==
* [http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html The official list of ISO-4217 alphabetic and numeric codes]
* [http://en.wikipedia.org/wiki/ISO_4217 Wikipedia: ISO 4217]
*[http://en.wikipedia.org/wiki/List_of_circulating_currencies Wikipedia: List of circulating currencies]

==Related pages==
{{currency-related-pages}}

hcalendar-creator-issues

2008-04-04T06:34:40Z

Gazza: /* Bug Reports */

<h1>hCalendar creator feedback</h1>

This page is for collecting bugs, suggested fixes, and feature requests for the [[hcalendar|hCalendar]] [http://microformats.org/code/hcalendar/creator creator]

Please list your name, and indicate ''which'' version (even just a date and time helps) of the creator that you are providing feedback on. Thanks!

== Bug Reports ==
=== REGRESSIONS ===
Regressions are the worst kind of bug, and the top priority to fix. If you find problems in the creator that were not there in a previous version, please enter them here.
* dtstart fails to put human readable start time into element text ''reported by Tantek at 2006-07-20''
** clarification: "if you enter a start date and a start time , only the start date is put in the human visible text"
** appears to already by fixed in hg, but I can't be sure --[[User:RyanKing|RyanKing]] 14:52, 24 Jul 2006 (PDT)
* there should be a dash "-", not emdash "–" separator between dtstart and dtend [[User:Tantek|Tantek]] 22:57, 4 Jun 2007 (PDT)
** A range should be indicated via an endash, "–", not a dash. [[User:Gazza|Gazza]] 23:34, 3 Apr 2008 (PDT)
* The creator appears to not work in IE6
** reported by several people via email to [[RyanKing]]
** error report:
<pre><nowiki>
-- Browser/OS --
IE v6 - SP2, Windows XP

Nothing shows up in the "code" areas.
Press "Build It!"
JS error-
Line: 4266
Char: 1
Error: Object required
Code: 0
URL: http://microformats.org/code/hcalendar/creator
</nowiki></pre>
* reported not to work in Opera on WinXP
** reported to [[RyanKing]] via email

=== Bugs in new features ===
* the automatic 'id' attribute generation needs to strip "@" (e.g. I created an event for "@media") [[User:Tantek|Tantek]] 22:57, 4 Jun 2007 (PDT)
** BBEdit validator reports: <blockquote>Value of attribute “id” for element “<li>” must begin with one of {A-Z,a-z} followed by zero or more of {A-Z,a-z,0-9,-,_,:,.}.</blockquote>

== Suggested Tweaks and Fixes ==
* ...

== Feature Requests ==
* option to change root element to say <li>
* option to use mm/dd-mm/dd instead of MMM DD - MMM DD
* options to turn off most emdashes

== Related Pages ==
* [[hcalendar|hCalendar specification]]
* [[hcalendar-feedback|hCalendar feedback]]
* [[hcard-creator-feedback|hCard creator feedback]]
* [[hreview-creator-feedback|hReview creator feedback]]

xfn-brainstorming

2008-03-27T03:48:20Z

Gazza: /* possible inverse of fan terms */

icons

2008-03-27T03:30:07Z

Gazza: /* Geo */

<h1> Icons </h1>
These icons can be used to depict various microformats in webpages or on the desktop.

== Creators ==
* [http://factoryjoe.com/blog Chris Messina]
* [http://dmitry.baranovskiy.com Dmitry Baranovskiy]
* [http://bartleme.at Wolfgang Bartelme]

==Accessibility==
Publishers are advised to ensure that these icons are used in an accessible fashion, by including suitable "alt" attributes.

Icon designers are reminded that inability to distinguish between red and green is the commonest form of colour-blindness .

=== Copyright ===
Unless otherwise noted, these icons are licensed under the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5 license].

== Icons ==

=== Web ===

A [http://factorycity.net/projects/microformats-icons/ first effort] has been completed by Wolfgang Bartelme and Chris Messina to create a series of web-friendly icons and buttons for microformats.

==== General ====

* http://factorycity.net/projects/microformats%2Dicons/images/icon-hatom.png hAtom
* http://factorycity.net/projects/microformats%2Dicons/images/icon-hcalendar.png hCalendar
* http://factorycity.net/projects/microformats%2Dicons/images/icon-hcard-add.png hCard Add
* http://factorycity.net/projects/microformats%2Dicons/images/icon-hcard-download.png hCard Download
* http://factorycity.net/projects/microformats%2Dicons/images/icon-hresume.png hResume (button)
* http://factorycity.net/projects/microformats%2Dicons/images/icon-rel-tag.png rel-tag (button)
* http://factorycity.net/projects/microformats%2Dicons/images/icon-xfn.png XFN (button)

'''Based on the General Icon DevKit:'''
* http://farm1.static.flickr.com/247/515868619_ed9cda470a_o.png hCalendar Download
* http://farm1.static.flickr.com/217/515843744_57bd70fdf5_o.png hCalendar Add
* http://farm1.static.flickr.com/235/515843768_98956242a7_o.png hCard

'''Comments:'''

* Hober pointed out that bright green seems to be a common color for [eventful.com/images/skin/ical.gif ical chicklets]
* Tantek wonders if the rel-tag button is useful
* ChrisMessina suggest a need for a small 10x10 tag icon
** http://archgfx.net/aspnet_client/tag-ltblue.gif square tag
** [[User:SunBurntKamel|Adam]] suggests 10x10 is a little small, but square is nice
** [[User:Pfefferle|Pfefferle]] suggests the [http://www.famfamfam.com/lab/icons/silk/ FamFamFam] tag-icon: http://notizblog.org/wp-content/uploads/2007/05/tag_blue.png
* Tantek wonders whether we need an hCard Download icon -- since it focuses too much on the "pipes"
* Ron thinks it's ok to use icons, cause it's a nice way of promoting the "Microformat idea". Maybe it's a good idea to use a downward aimed arrow to indicate the possibility to "download" something (like an hCard or hResume).
* Adam wonders if a multiple-license, including GPL, might be helpful in increasing adoption among wordpress themes.
* [[User:Pfefferle|Pfefferle]] suggests to change the color of the XFN-button into blue, because it uses the rel-attribute like "rel-tag" http://farm1.static.flickr.com/195/515824030_3c0dd42493_o.png.

==== XFN ====

* http://factorycity.net/projects/microformats%2Dicons/images/xfn-me.png rel-me
* http://factorycity.net/projects/microformats%2Dicons/images/xfn-friend.png rel-friend
** http://factorycity.net/projects/microformats%2Dicons/images/xfn-friend-met.png met
* http://factorycity.net/projects/microformats%2Dicons/images/xfn-sweetheart.png rel-sweetheart
** http://factorycity.net/projects/microformats%2Dicons/images/xfn-sweetheart-met.png met
* http://factorycity.net/projects/microformats%2Dicons/images/xfn-colleague.png rel-colleague
** http://factorycity.net/projects/microformats%2Dicons/images/xfn-colleague-met.png met

'''Comments:'''

* Tantek: wonders if a rel-me icon is necessary or appropriate; perhaps something indicating "facets"?
* ChrisMesssina: rel-me is useful in blog posts where you link to other posts that you've written
* [[User:WizardIsHungry|Jon Williams]] 13:40, 5 Jan 2007 (PST): I thought "Flickr buddy" when I first saw these due to the color. Also the pink/blue may annoy people with some gender issues. Maybe we should use green for the sweetheart?

==== VoteLinks ====

[http://microformats.org/wiki/vote-links VoteLinks]

* http://deliciouslymeta.com/projects/vote-links/vote-for.gif vote-for
* http://deliciouslymeta.com/projects/vote-links/vote-against.gif vote-against
* http://factorycity.net/projects/microformats%2Dicons/images/vote-links.png (download the [http://factorycity.net/projects/microformats%2Dicons/files/vote-links.zip kit])

'''Comments:'''
* [[User:SteveIvy|Steve Ivy]]: I don't have a good icon for vote-abstain. Recommendations welcome. These are also a tad large to site next to links, perhaps?
** [[User:AndyMabbett|Andy Mabbett]]: Is +1/-1 a common way of representing voting? Would ticks and crosses be better, or thumbs up/ down (or horizontal for abstain)?
*** [[User:SteveIvy|Steve Ivy]]: I rather like the icons used by [http://digg.com digg] for voting on comments, but cannot use them for obvious reasons. I'm no iconographer to be honest, but if someone were to create thumbs-up/thumbs-down icons I'd use them instead of these.

==== Geo ====

Can be used in the ''background-image'' CSS property, next to a geo microformat. It could also indicate that a map opens in a new window:

* http://microformats.telemetry.gr/openmap.gif

* http://www.geotagicons.com/img/geotag-16px.png (taken from [http://www.geotagicons.com/ Geotag Icon Project])

----

=== Mac ===
[http://factoryjoe.com/blog/wp-content/uploads/2006/08/mf-icons.zip http://factoryjoe.com/blog/wp-content/uploads/2006/08/mf-icons-preview.png]

These [http://factoryjoe.com/blog/wp-content/uploads/2006/08/mf-icons.zip icons] can be used for folders or files on your Mac. You can use a tool like [http://iconfactory.com/software/pixadex Pixadex] for managing and applying them.

Created by [http://factoryjoe.com/blog Chris Messina]

----

=== PDF & SVG ===

[http://dmitry.baranovskiy.com/res/mf-logo.pdf http://dmitry.baranovskiy.com/i/pdffile.png] [http://dmitry.baranovskiy.com/res/mf-logo.svg http://dmitry.baranovskiy.com/i/svgfile.png]

This logo looks pretty much as first icon of Chris’ set. You could open it in any bitmap or vector editing tools, such as Adobe Photoshop or Adobe Illustrator.

Created by [http://dmitry.baranovskiy.com Dmitry Baranovskiy]

==See also==
{{branding-see-also}}

== Examples in the Wild ==

* [http://zeroseis.com.br ZeroSeis] uses hCard download icon.
* [http://www.bayofislands.net/ Bay of Islands] uses hCard geo icon eg. in [http://www.bayofislands.net/accommodation/mousetrap/ Moustrap Backpackers] page
* [http://www.nextbbs.com nextBBS] uses vote-links icons.
* [http://www.revolucao.etc.br Revolução Etc] uses hCard download icon and tag icon.
* There are various microformat logos on [http://www.westmidlandbirdclub.com/site/ the West Midland Bird Club's "about this site" page] and on its [http://www.westmidlandbirdclub.com/club/executive.htm contacts] and [http://www.westmidlandbirdclub.com/diary/2007/10.htm events] pages

Template:hatom-related-pages

2008-01-26T10:58:44Z

Gazza:

* [[hatom|hAtom]] - the draft proposal.
* [[hatom-cheatsheet|hAtom Cheatsheet]] - hAtom properties.
* [[hatom-examples-in-wild|hAtom Examples, in the Wild]]
* [[hatom-hints|hAtom Hints]] - help for implementors.
* [[hatom-issues|hAtom Issues]] - problems? complaints? ideas? Put them here.
* [[hatom-faq|hAtom FAQ]] - knowledge base.
* [[advocacy#hAtom|hAtom advocacy]] - encourage others to use hAtom.

xfn-brainstorming

2008-01-26T07:29:47Z

Gazza: /* fans and followers */

hcard-brainstorming

2008-01-09T01:03:17Z

Gazza: /* Other use cases */

<h1> hCard Brainstorming </h1>
{{TOC-right}}
This page is for brainstorming about various uses and details of [[hcard|hCard]]. This page contains proposals. For the current state please see [[hcard|hCard]].

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/ Tantek Çelik] (formerly of [http://technorati.com Technorati, Inc])

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* [[User:AndyMabbett|Andy Mabbett]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services
* [[social-network-portability]] through the use of [[hcard-supporting-user-profiles|hCard supporting user profiles]] and [[hcard-xfn-supporting-friends-lists|hCard+XFN supporting friends lists]]

== Named locations ==
Most hCards contain contact information for people or organizations. But locations that aren't organizations are also deserving of their own hCard (e.g. somebody's house/apartment). This situation can be represented by combining "fn" and "extended-address".

=== "fn" and "extended-address" combination ===

'''Proposal''': Similar to [[hcard#Organization_Contact_Info|organization contact info]], if the "fn" property and an "extended-address" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn extended-address"</code>), then

# The hCard represents contact information for a place and SHOULD be treated as such.
# The author also MUST NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "".
# Parsers SHOULD handle the missing "n" property by implying empty values for all the "n" sub-properties.

'''Further proposal''': Consider also an hCard for a City, "Birmingham, England": Birmingham may be the "fn" and the "locality", but it's not an "extended-address". Perhaps the rule should be that the hCard is for a place if the "fn" is on any address component (e.g "fn locality" or "fn street-address")?

=== Examples in the wild ===

* The named location "Picnic benches" in the address "Picnic benches, South Park, San Francisco, California" in [http://adactio.com/journal/1364/ a blog post on adactio.com].
<pre><nowiki>


Picnic benches
South Park
San Francisco
California


</nowiki></pre>

==== Potential examples in the wild ====

* The location "Phone Boxes by the Sealife Centre" [http://upcoming.yahoo.com/venue/5668/ on Upcoming] is currently marked up as "fn org":
<pre><nowiki>
<div class="vcard">
<div class="fn org">Phone Boxes by the Sealife Centre</div>
<div class="adr">
Marine Parade 
Brighton & Hove,
England
BN2 1TB 
United Kingdom 
01273 606674
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>
This could be marked up as:
<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="fn extended-address">Phone Boxes by the Sealife Centre</div>
Marine Parade 
Brighton & Hove,
England
BN2 1TB 
United Kingdom 
01273 606674
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>

===Concerns===
The above seems to be an elegant solution, but a wider variety of examples form published pages are needed, to be sure it meets all common scenarios. these should include cases where "adr" is not already used; note that in that case an extra level of nesting is required. The implications of this, for hCards already published, should be considered.

Also, what about hCards for published locations, which already include an extended address?

e.g.

<pre><nowiki>
<div class="vcard">
Powell's Pool

Sutton Park
Birmingham
England

</div>
</nowiki></pre>

[[User:AndyMabbett|Andy Mabbett]] 05:40, 15 Dec 2007 (PST)

=== named location formats ===
Previous named location format efforts:

==== Simple GeoRSS featurename ====
The [http://georss.org/simple Simple GeoRSS] vocabulary contains the following named location example in the "Additional Properties" section that references a <code>featurename</code> tag.

<blockquote><h3>Feature Type, Feature Name, and Relationship Tags</h3>The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.<pre><nowiki>
<georss:point>45.256 -110.45</georss:point>
<georss:featuretypetag>city</georss:featuretypetag>

<georss:relationshiptag>is-centered-at</georss:relationshiptag>

<georss:featurename>Podunk</georss:featurename>
</nowiki></pre></blockquote>

A [http://www.google.com/search?q=site%3Ageorss.org%20featurename search for featurename on georss.org] fails to find any other references however, including a definition.

An [http://lists.eogeo.org/pipermail/georss/2006-December/000895.html email on the georss list from Dec 2006] thread "featurename, other missing bits from the site" notes that "there is some updating to do" in response to a concern that "that descriptions of "featurename" are not present on GeoRSS Simple and the GeoRSS Model. GeoRSS GML makes no mention of the non-geometric properties at all."

== FN Nickname semantic ==
There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

== Implied FN from N ==
Since the "n" property is more detailed and structured than the "fn" property, and [[hcard-examples-in-wild]] have shown that very often what is specified for "n" sub-properties is also specified for the "fn" property, we could add the following implied "fn" optimization which would permit sites to only use "n" and its subproperties.

In addition, some sites don't have contiguous uninterrupted text that represents the desired "fn" value, and would much rather have the "fn" implied from "n" subproperties. E.g. "Citizen Space Citizens" on [[hcard-examples-in-wild]].

=== implied "fn" from "n" optimization ===
If an hCard has no "fn", yet has an "n" property with one or more subproperties, then the "fn" property value can be implied by concatenating the "n" subproperty values as follows, with a space between each subproperty value, and multiple subproperty instances.

* 'honorific-prefix'es (as found in document order)
* 'given-name'
* 'additional-name's (as found in document order)
* 'family-name'
* 'honorific-suffix'es (as found in document order)

== Implied N from its subproperties ==
Since the "n" subproperties are sufficiently uniquely named (that is, they are not used by any other hCard property), and "n" is one of the [[hcard-singular-properties]], it is possible to consider leaving out the "n" property itself fo the hCard, and simply directlly using the subproperties, as properties of the hCard.

=== implied "n" from its subproperties ===
If an hCard has no "fn" nor "n" properties, then the entire scope of the hCard is considered to be inside an implied "n" property.

E.g. this markup:
<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

would be treated from a parsing perspective as:

<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

Which, with the '''implied "fn" from "n" optimization''', would then be effectively treated as:

<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

* a related request from the mailing list: http://microformats.org/discuss/mail/microformats-discuss/2007-September/010791.html

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== Auto-Discovery ==

=== Representative hCard discovery ===

See [[representative-hcard]].

=== vCard link rel auto-discovery ===

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by

<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>

</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==
''See [[geo-brainstorming]]''

== Other use cases ==
Please add your suggestions!

hCard microformats could be used to:
*Calculate and display the subject's age "as of today".
*Calculate and display the subject's age at death (if a [[hcard-date-of-death|Date of Death]] is available)
*Generate a recurring iCal for a living subject's birthday
*Generate a recurring iCal for a dead subject's "anniversary of birth" (if a [[hcard-date-of-death|Date of Death]] is available)
*...

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
John
Q.
Public
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>



<a class="internet" href="mailto:jfriday@host.com">
<dfn>
Joe Friday
</dfn>
</a>

+1-919-555-7878
Area Administrator, Assistant


</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]
* If the answer to the above Q is "yes", why not use the following?
<pre><nowiki>
<dfn class="fn">Joe Friday</dfn>
</nowiki></pre>
or
<pre><nowiki>

<dfn class="vcard">

<a class="internet" href="mailto:jfriday@host.com">
Joe Friday
</a>

+1-919-555-7878
Area Administrator, Assistant
</dfn>

</nowiki></pre>
This would mark the entire hcard as the "defining instance".

[[User:Bob Jonkman|Bob Jonkman]] 10:07, 13 Jul 2007 (PDT)

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

''The URL reffered to in this section is no longer available. The thoughts on using icons are however still relevant.'' [[User:WilleRaab|WilleRaab]] 16:55, 23 Jul 2007 (PDT)

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

* [http://24ways.org/2006/styling-hcards-with-css Styling hCards with CSS] is a text on how to use CSS to make an improved presentation of an hCards contents.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

=== Additional Semantic HTML handling ===
==== <code>acronym</code> element handling ====
Choices:
* Explicitly treat <code>acronym</code> the same as <code>abbr</code>, per semantics of the '<code>title</code>' attribute on <code>acronym</code> in particular, as defined in HTML4.01.
* Explicitly treat <code>acronym</code> the same as <code>span</code>, and discourage use of <code>acronym</code>.

==== <code>input</code> element handling ====
In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the <code>img</code> element use the 'alt' attribute.

One element I forgot at the time was the <code>input</code> element, specifically, <code><nowiki><input type="text"></nowiki></code>. Another I forgot was the <code>textarea</code> element.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.
** consider other input types also (e.g. checkbox, radio, hidden) and specify how to parse them as well.
* <code><textarea></code>: use the text contents of the element. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.

[[User:Tantek|Tantek]]

==== forms auto-fill ====
If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Interactive useragents (e.g. [[operator]] on [[firefox]]) could detect such "insert hCard here" semantics in forms on pages, and let you "pre-fill" with *your* hCard info, and then all of a sudden we have a standard for forms auto-fill, rather than all the hacks that have gone into browsers since 1999 (starting with IE4.5/Mac which I'm pretty sure was the first to do forms auto-fill of an entire form with a single button press - not just auto-complete of each form field individually).

Obviously this would make sense to build into *existing* forms auto-fill features in [[Firefox]] and [[IE]], and any other browsers that support it.

For more on this, see the 2007 August blog post [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] by David Baron, a Mozilla employee.

This way new sites could simply conform to the standard, rather than depend on hacks which parse label values etc. and imply things and get them wrong sometimes.

'''[[i18n]]''' advantages: hCard annotated form inputs would also be more international, thus avoiding the need for each browser to guess what is the "name" and "telephone" field in every language, so they can do forms auto-fill on any site regardless of language, not just English.

[[User:Tantek|Tantek]] 16:24, 23 Jul 2007 (PDT)

==== Background discussion: ====

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html

The options discussed in a hypothetical hCard input system so far appear to be:

1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Proposed markup:

<pre><nowiki>
<form class="vcard-input" ...>
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" />
<input type="text" class="family-name" name="last_name" />
</fieldset>
...
</form>
</nowiki></pre>

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Proposed markup:

<pre><nowiki>
<form ...>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Rob" />
<input type="text" class="family-name" name="last_name" value="Manson" />
</fieldset>
...
</div>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Scott" />
<input type="text" class="family-name" name="last_name" value="Reynen" />
</fieldset>
...
</div>
</form>
</nowiki></pre>

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

==== Key Issues/discussion points ====
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
- ''Negative'' : this require adding a bit of special case to existing parsers to handle these elements
- ''Positive'' : this could help to enable uf based auto form filling
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
- ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. [[Operator]]) parse the loaded html not the dynamic DOM
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
- ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
- ''Examples''
- title select that lists mr/mrs/ms/dr/etc.
- checkboxes to choose which addresses to use
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
- Unworkable. Cannot require clientside javascript.
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields
- hypothetical comment assuming more complexity beyond.

[[User:RobManson|RobManson]]

=== multiple type parsing ===
* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]

=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

=== Ambiguous name components ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

==== implied single adr subproperty ====
I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

==== implied adr subproperties ====
It may be possible for parsers to parse out adr subproperties from a contiguous adr string. This would be an optimization for both [[adr]] and [[hcard|hCard]].

This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way.

Examples:

[http://www.ibm.com/contact/employees/us/ IBM's Employee Directory] search [http://www.ibm.com/contact/employees/servlets/lookup?country=us&language=en&search_country=all&lastname=Kaply&firstname=Michael returns hCards with the "adr" property] which contain the "locality" and "country-name" data but unfortunately without being marked up as such, e.g.:

<pre><nowiki>
<td class="adr">Austin, USA</td>
</nowiki></pre>

We could first define a canonical ordering of how to parse for comma (and perhaps in some cases space) separated adr subproperties within an adr string e.g.:

* 'post-office-box'
* 'street-address'
* 'extended-address'
* 'locality'
* 'region'
* 'postal-code'
* 'country-name'

Given a dictionary of country names and abbreviations, it may be feasible to parse for a country name at the end of the adr string, and then apply country/locale specific parsing rules to the rest of the adr string.

E.g.
* from a theoretical dictionary of country names:
** US|USA|United States|United States of America|Etats-Unis d'Amerique
* parse the remainder of the adr string backwards as follows:
** preceding that, look for a 5 or 9 digit (with optional dash '-' separator between digits 5 and 6) postal-code, and if found use it for the 'postal-code'
** preceding that, look for the name of a US state (e.g. California or any of the other states or territories available from a canonical list) or 2 letter state abbreviation (e.g. CA), and if found use it for the 'region' subproperty
** preceding that, look for the name of a US city (e.g. San Francisco, Los Angeles or any other US city available from a canonical list) or common city abbreviation (e.g. SF, LA), and if found use it for the 'locality'
** preceding that, look for common extended address details, such as: #|apt|apartment|suite|ste followed by a word consisting of letters and numbers, and if found use it for the 'extended-address'
** preceding that, look for a common street name bracketed by the street number (an integer with optional fraction and/or letter), and an optional street type (av|ave|avenue|blvd|boulevard|cir|circle|pl|place|st|street), and if found use it for the 'street-address'
** preceding that, look for a common post office box, with the pobox literal string: pob|pobox|PO Box followed by a word consisting of numbers and letters, and if found use it for the 'post-office-box'
* ... other countries

The above heuristic (not quite well specified enough to be an algorithm, yet) would allow parsing of the IBM Employee Directory result documented above.

There are a lot of existing geocoder APIs that turn unstructured addresses into structured ones - we should examine these for patterns and best practices. eg [http://www.google.com/apis/maps/documentation/#Geocoding_Structured Google's geocoder] [http://exogen.case.edu/projects/geopy/ geopy calls multiple ones]

==== adr without children FAQ ====
I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty)

Q: What should a parser do with an "adr" property lacking any subproperties?

A: A parser SHOULD do nothing with such an "adr" property. A parser MAY provide the text content of such an "adr" property in the results of its parsing as a freeform value of the "adr" property. Note that the vCard standard does not allow for any such freeform value of its "adr" property (in vCard the "adr" property MUST be structured) and thus that MAY suggestion to parsers only applies in situations (such as APIs, JSON return values) where it is possible to return a freeform value for the "adr" property.

[[User:Tantek|Tantek]] 09:20, 2 Aug 2007 (PDT)

== Birthday Reminders ==
*hCard consumers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, hCard consumers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when [[hcard-date-of-death|Date of Death]] is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)

== Post vCard additions ==

Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.

However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].

This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.

* '''altitude'''. From [[hcard-issues]].
**See [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).

* '''gender'''
** See [[vcard-suggestions#Gender]]

* '''date-of-death'''
** See [[hcard-date-of-death]]

Thus see (and add to): [[vcard-suggestions]]

Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]

Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.

Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1
representation of properties/values.

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.
* Clarify contradictory copyright statements, per http://microformats.org/discuss/mail/microformats-discuss/2007-July/010243.html

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
Hidden Data
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.
* [http://microid.org/ MicroID in hCard]

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Implied work tel ==

=== Problem ===

Some phone numbers are not always documented of type 'work'. The type 'work' is usually implied from context.

=== Examples in the wild ===

[[http://www.nvidia.com/page/contact_information.html NVidia contact information]]

Only 'Tel' is specified. The fact that it is of type 'work' can be assumed from the context: the name of an organization is present.

<pre>
NVIDIA CORPORATE OFFICE: 
2701 San Tomas Expressway 
Santa Clara, CA 95050 
Tel: 408-486-2000 

Fax: 408-486-2200 
...

</pre>

[[http://www.supermarketguru.com/page.cfm/369 Supermarketguru.com]]

<pre>


Phil Lempert: <a href="mailto:plempert@supermarketguru.com">plempert@supermarketguru.com</a> 

SupermarketGuru.com 
3015 Main Street, Suite 320 Santa Monica, California 90405 
Telephone: 323-860-3070


</pre>

Here only 'Telephone:' is specified, a FN is present ('Phil Lempert') but because an ORG is present ('SupermarketGuru.com'), it can be safely implied that '323-860-3070' is a tel or type work.

=== Proposal ===

If an ORG is present in a VCARD, a TEL with no TYPE has an implied TYPE 'work'

==== Comments ====
* Though it may be safe to make that assumption for the given example (and though it might have been wise to make this rule from the outset), we now can't know that it will alwyas be safe to do so, for all pre-existing hCards. Consider people whose organisation represents voluntary work, honorary roles and so forth. [[User:AndyMabbett|Andy Mabbett]] 00:33, 8 Jan 2008 (PST)

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>

...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...

</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

== References ==

=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]

=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

== Related Pages ==

{{hcard-related-pages}}

hcard-brainstorming

2008-01-09T01:03:00Z

Gazza: /* Auto-Discovery for XFN */

<h1> hCard Brainstorming </h1>
{{TOC-right}}
This page is for brainstorming about various uses and details of [[hcard|hCard]]. This page contains proposals. For the current state please see [[hcard|hCard]].

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/ Tantek Çelik] (formerly of [http://technorati.com Technorati, Inc])

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* [[User:AndyMabbett|Andy Mabbett]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services
* [[social-network-portability]] through the use of [[hcard-supporting-user-profiles|hCard supporting user profiles]] and [[hcard-xfn-supporting-friends-lists|hCard+XFN supporting friends lists]]

== Named locations ==
Most hCards contain contact information for people or organizations. But locations that aren't organizations are also deserving of their own hCard (e.g. somebody's house/apartment). This situation can be represented by combining "fn" and "extended-address".

=== "fn" and "extended-address" combination ===

'''Proposal''': Similar to [[hcard#Organization_Contact_Info|organization contact info]], if the "fn" property and an "extended-address" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn extended-address"</code>), then

# The hCard represents contact information for a place and SHOULD be treated as such.
# The author also MUST NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "".
# Parsers SHOULD handle the missing "n" property by implying empty values for all the "n" sub-properties.

'''Further proposal''': Consider also an hCard for a City, "Birmingham, England": Birmingham may be the "fn" and the "locality", but it's not an "extended-address". Perhaps the rule should be that the hCard is for a place if the "fn" is on any address component (e.g "fn locality" or "fn street-address")?

=== Examples in the wild ===

* The named location "Picnic benches" in the address "Picnic benches, South Park, San Francisco, California" in [http://adactio.com/journal/1364/ a blog post on adactio.com].
<pre><nowiki>


Picnic benches
South Park
San Francisco
California


</nowiki></pre>

==== Potential examples in the wild ====

* The location "Phone Boxes by the Sealife Centre" [http://upcoming.yahoo.com/venue/5668/ on Upcoming] is currently marked up as "fn org":
<pre><nowiki>
<div class="vcard">
<div class="fn org">Phone Boxes by the Sealife Centre</div>
<div class="adr">
Marine Parade 
Brighton & Hove,
England
BN2 1TB 
United Kingdom 
01273 606674
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>
This could be marked up as:
<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="fn extended-address">Phone Boxes by the Sealife Centre</div>
Marine Parade 
Brighton & Hove,
England
BN2 1TB 
United Kingdom 
01273 606674
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>

===Concerns===
The above seems to be an elegant solution, but a wider variety of examples form published pages are needed, to be sure it meets all common scenarios. these should include cases where "adr" is not already used; note that in that case an extra level of nesting is required. The implications of this, for hCards already published, should be considered.

Also, what about hCards for published locations, which already include an extended address?

e.g.

<pre><nowiki>
<div class="vcard">
Powell's Pool

Sutton Park
Birmingham
England

</div>
</nowiki></pre>

[[User:AndyMabbett|Andy Mabbett]] 05:40, 15 Dec 2007 (PST)

=== named location formats ===
Previous named location format efforts:

==== Simple GeoRSS featurename ====
The [http://georss.org/simple Simple GeoRSS] vocabulary contains the following named location example in the "Additional Properties" section that references a <code>featurename</code> tag.

<blockquote><h3>Feature Type, Feature Name, and Relationship Tags</h3>The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.<pre><nowiki>
<georss:point>45.256 -110.45</georss:point>
<georss:featuretypetag>city</georss:featuretypetag>

<georss:relationshiptag>is-centered-at</georss:relationshiptag>

<georss:featurename>Podunk</georss:featurename>
</nowiki></pre></blockquote>

A [http://www.google.com/search?q=site%3Ageorss.org%20featurename search for featurename on georss.org] fails to find any other references however, including a definition.

An [http://lists.eogeo.org/pipermail/georss/2006-December/000895.html email on the georss list from Dec 2006] thread "featurename, other missing bits from the site" notes that "there is some updating to do" in response to a concern that "that descriptions of "featurename" are not present on GeoRSS Simple and the GeoRSS Model. GeoRSS GML makes no mention of the non-geometric properties at all."

== FN Nickname semantic ==
There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

== Implied FN from N ==
Since the "n" property is more detailed and structured than the "fn" property, and [[hcard-examples-in-wild]] have shown that very often what is specified for "n" sub-properties is also specified for the "fn" property, we could add the following implied "fn" optimization which would permit sites to only use "n" and its subproperties.

In addition, some sites don't have contiguous uninterrupted text that represents the desired "fn" value, and would much rather have the "fn" implied from "n" subproperties. E.g. "Citizen Space Citizens" on [[hcard-examples-in-wild]].

=== implied "fn" from "n" optimization ===
If an hCard has no "fn", yet has an "n" property with one or more subproperties, then the "fn" property value can be implied by concatenating the "n" subproperty values as follows, with a space between each subproperty value, and multiple subproperty instances.

* 'honorific-prefix'es (as found in document order)
* 'given-name'
* 'additional-name's (as found in document order)
* 'family-name'
* 'honorific-suffix'es (as found in document order)

== Implied N from its subproperties ==
Since the "n" subproperties are sufficiently uniquely named (that is, they are not used by any other hCard property), and "n" is one of the [[hcard-singular-properties]], it is possible to consider leaving out the "n" property itself fo the hCard, and simply directlly using the subproperties, as properties of the hCard.

=== implied "n" from its subproperties ===
If an hCard has no "fn" nor "n" properties, then the entire scope of the hCard is considered to be inside an implied "n" property.

E.g. this markup:
<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

would be treated from a parsing perspective as:

<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

Which, with the '''implied "fn" from "n" optimization''', would then be effectively treated as:

<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

* a related request from the mailing list: http://microformats.org/discuss/mail/microformats-discuss/2007-September/010791.html

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== Auto-Discovery ==

=== Representative hCard discovery ===

See [[representative-hcard]].

=== vCard link rel auto-discovery ===

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by

<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>

</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically have their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==
''See [[geo-brainstorming]]''

== Other use cases ==
Please add your suggestions!

hCard microformats could be used to:
*Calculate and display the subject's age "as of today".
*Calculate and display the subject's age at death (if a [[hcard-date-of-death|Date of Death]] is available)
*Generate an recurring iCal for a living subject's birthday
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a [[hcard-date-of-death|Date of Death]] is available)
*...

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
John
Q.
Public
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>



<a class="internet" href="mailto:jfriday@host.com">
<dfn>
Joe Friday
</dfn>
</a>

+1-919-555-7878
Area Administrator, Assistant


</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]
* If the answer to the above Q is "yes", why not use the following?
<pre><nowiki>
<dfn class="fn">Joe Friday</dfn>
</nowiki></pre>
or
<pre><nowiki>

<dfn class="vcard">

<a class="internet" href="mailto:jfriday@host.com">
Joe Friday
</a>

+1-919-555-7878
Area Administrator, Assistant
</dfn>

</nowiki></pre>
This would mark the entire hcard as the "defining instance".

[[User:Bob Jonkman|Bob Jonkman]] 10:07, 13 Jul 2007 (PDT)

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

''The URL reffered to in this section is no longer available. The thoughts on using icons are however still relevant.'' [[User:WilleRaab|WilleRaab]] 16:55, 23 Jul 2007 (PDT)

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

* [http://24ways.org/2006/styling-hcards-with-css Styling hCards with CSS] is a text on how to use CSS to make an improved presentation of an hCards contents.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

=== Additional Semantic HTML handling ===
==== <code>acronym</code> element handling ====
Choices:
* Explicitly treat <code>acronym</code> the same as <code>abbr</code>, per semantics of the '<code>title</code>' attribute on <code>acronym</code> in particular, as defined in HTML4.01.
* Explicitly treat <code>acronym</code> the same as <code>span</code>, and discourage use of <code>acronym</code>.

==== <code>input</code> element handling ====
In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the <code>img</code> element use the 'alt' attribute.

One element I forgot at the time was the <code>input</code> element, specifically, <code><nowiki><input type="text"></nowiki></code>. Another I forgot was the <code>textarea</code> element.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.
** consider other input types also (e.g. checkbox, radio, hidden) and specify how to parse them as well.
* <code><textarea></code>: use the text contents of the element. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.

[[User:Tantek|Tantek]]

==== forms auto-fill ====
If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Interactive useragents (e.g. [[operator]] on [[firefox]]) could detect such "insert hCard here" semantics in forms on pages, and let you "pre-fill" with *your* hCard info, and then all of a sudden we have a standard for forms auto-fill, rather than all the hacks that have gone into browsers since 1999 (starting with IE4.5/Mac which I'm pretty sure was the first to do forms auto-fill of an entire form with a single button press - not just auto-complete of each form field individually).

Obviously this would make sense to build into *existing* forms auto-fill features in [[Firefox]] and [[IE]], and any other browsers that support it.

For more on this, see the 2007 August blog post [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] by David Baron, a Mozilla employee.

This way new sites could simply conform to the standard, rather than depend on hacks which parse label values etc. and imply things and get them wrong sometimes.

'''[[i18n]]''' advantages: hCard annotated form inputs would also be more international, thus avoiding the need for each browser to guess what is the "name" and "telephone" field in every language, so they can do forms auto-fill on any site regardless of language, not just English.

[[User:Tantek|Tantek]] 16:24, 23 Jul 2007 (PDT)

==== Background discussion: ====

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html

The options discussed in a hypothetical hCard input system so far appear to be:

1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Proposed markup:

<pre><nowiki>
<form class="vcard-input" ...>
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" />
<input type="text" class="family-name" name="last_name" />
</fieldset>
...
</form>
</nowiki></pre>

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Proposed markup:

<pre><nowiki>
<form ...>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Rob" />
<input type="text" class="family-name" name="last_name" value="Manson" />
</fieldset>
...
</div>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Scott" />
<input type="text" class="family-name" name="last_name" value="Reynen" />
</fieldset>
...
</div>
</form>
</nowiki></pre>

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

==== Key Issues/discussion points ====
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
- ''Negative'' : this require adding a bit of special case to existing parsers to handle these elements
- ''Positive'' : this could help to enable uf based auto form filling
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
- ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. [[Operator]]) parse the loaded html not the dynamic DOM
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
- ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
- ''Examples''
- title select that lists mr/mrs/ms/dr/etc.
- checkboxes to choose which addresses to use
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
- Unworkable. Cannot require clientside javascript.
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields
- hypothetical comment assuming more complexity beyond.

[[User:RobManson|RobManson]]

=== multiple type parsing ===
* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]

=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

=== Ambiguous name components ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

==== implied single adr subproperty ====
I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

==== implied adr subproperties ====
It may be possible for parsers to parse out adr subproperties from a contiguous adr string. This would be an optimization for both [[adr]] and [[hcard|hCard]].

This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way.

Examples:

[http://www.ibm.com/contact/employees/us/ IBM's Employee Directory] search [http://www.ibm.com/contact/employees/servlets/lookup?country=us&language=en&search_country=all&lastname=Kaply&firstname=Michael returns hCards with the "adr" property] which contain the "locality" and "country-name" data but unfortunately without being marked up as such, e.g.:

<pre><nowiki>
<td class="adr">Austin, USA</td>
</nowiki></pre>

We could first define a canonical ordering of how to parse for comma (and perhaps in some cases space) separated adr subproperties within an adr string e.g.:

* 'post-office-box'
* 'street-address'
* 'extended-address'
* 'locality'
* 'region'
* 'postal-code'
* 'country-name'

Given a dictionary of country names and abbreviations, it may be feasible to parse for a country name at the end of the adr string, and then apply country/locale specific parsing rules to the rest of the adr string.

E.g.
* from a theoretical dictionary of country names:
** US|USA|United States|United States of America|Etats-Unis d'Amerique
* parse the remainder of the adr string backwards as follows:
** preceding that, look for a 5 or 9 digit (with optional dash '-' separator between digits 5 and 6) postal-code, and if found use it for the 'postal-code'
** preceding that, look for the name of a US state (e.g. California or any of the other states or territories available from a canonical list) or 2 letter state abbreviation (e.g. CA), and if found use it for the 'region' subproperty
** preceding that, look for the name of a US city (e.g. San Francisco, Los Angeles or any other US city available from a canonical list) or common city abbreviation (e.g. SF, LA), and if found use it for the 'locality'
** preceding that, look for common extended address details, such as: #|apt|apartment|suite|ste followed by a word consisting of letters and numbers, and if found use it for the 'extended-address'
** preceding that, look for a common street name bracketed by the street number (an integer with optional fraction and/or letter), and an optional street type (av|ave|avenue|blvd|boulevard|cir|circle|pl|place|st|street), and if found use it for the 'street-address'
** preceding that, look for a common post office box, with the pobox literal string: pob|pobox|PO Box followed by a word consisting of numbers and letters, and if found use it for the 'post-office-box'
* ... other countries

The above heuristic (not quite well specified enough to be an algorithm, yet) would allow parsing of the IBM Employee Directory result documented above.

There are a lot of existing geocoder APIs that turn unstructured addresses into structured ones - we should examine these for patterns and best practices. eg [http://www.google.com/apis/maps/documentation/#Geocoding_Structured Google's geocoder] [http://exogen.case.edu/projects/geopy/ geopy calls multiple ones]

==== adr without children FAQ ====
I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty)

Q: What should a parser do with an "adr" property lacking any subproperties?

A: A parser SHOULD do nothing with such an "adr" property. A parser MAY provide the text content of such an "adr" property in the results of its parsing as a freeform value of the "adr" property. Note that the vCard standard does not allow for any such freeform value of its "adr" property (in vCard the "adr" property MUST be structured) and thus that MAY suggestion to parsers only applies in situations (such as APIs, JSON return values) where it is possible to return a freeform value for the "adr" property.

[[User:Tantek|Tantek]] 09:20, 2 Aug 2007 (PDT)

== Birthday Reminders ==
*hCard consumers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, hCard consumers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when [[hcard-date-of-death|Date of Death]] is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)

== Post vCard additions ==

Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.

However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].

This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.

* '''altitude'''. From [[hcard-issues]].
**See [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).

* '''gender'''
** See [[vcard-suggestions#Gender]]

* '''date-of-death'''
** See [[hcard-date-of-death]]

Thus see (and add to): [[vcard-suggestions]]

Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]

Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.

Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1
representation of properties/values.

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.
* Clarify contradictory copyright statements, per http://microformats.org/discuss/mail/microformats-discuss/2007-July/010243.html

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
Hidden Data
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.
* [http://microid.org/ MicroID in hCard]

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Implied work tel ==

=== Problem ===

Some phone numbers are not always documented of type 'work'. The type 'work' is usually implied from context.

=== Examples in the wild ===

[[http://www.nvidia.com/page/contact_information.html NVidia contact information]]

Only 'Tel' is specified. The fact that it is of type 'work' can be assumed from the context: the name of an organization is present.

<pre>
NVIDIA CORPORATE OFFICE: 
2701 San Tomas Expressway 
Santa Clara, CA 95050 
Tel: 408-486-2000 

Fax: 408-486-2200 
...

</pre>

[[http://www.supermarketguru.com/page.cfm/369 Supermarketguru.com]]

<pre>


Phil Lempert: <a href="mailto:plempert@supermarketguru.com">plempert@supermarketguru.com</a> 

SupermarketGuru.com 
3015 Main Street, Suite 320 Santa Monica, California 90405 
Telephone: 323-860-3070


</pre>

Here only 'Telephone:' is specified, a FN is present ('Phil Lempert') but because an ORG is present ('SupermarketGuru.com'), it can be safely implied that '323-860-3070' is a tel or type work.

=== Proposal ===

If an ORG is present in a VCARD, a TEL with no TYPE has an implied TYPE 'work'

==== Comments ====
* Though it may be safe to make that assumption for the given example (and though it might have been wise to make this rule from the outset), we now can't know that it will alwyas be safe to do so, for all pre-existing hCards. Consider people whose organisation represents voluntary work, honorary roles and so forth. [[User:AndyMabbett|Andy Mabbett]] 00:33, 8 Jan 2008 (PST)

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>

...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...

</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

== References ==

=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]

=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

== Related Pages ==

{{hcard-related-pages}}

hatom

2008-01-09T00:52:24Z

Gazza: /* Entry Content */

<h1> hAtom 0.1 </h1>

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the [http://www.atomenabled.org/ Atom] syndication format. hAtom will be one of several [[microformats]] open standards.

__TOC__
== Draft Specification ==

;Editor/Author
:[http://blogmatrix.blogmatrix.com/ David Janes] ([http://www.blogmatrix.com BlogMatrix, Inc.])

;Contributors
:[http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]
:[http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati, Inc.])

=== Copyright ===
{{MicroFormatCopyrightStatement2005}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

=== Patents ===
{{MicroFormatPatentStatement}}

== Introduction ==

hAtom is a [[microformat]] for identifying semantic information in weblog posts and practically any other place [http://www.atomenabled.org/ Atom] may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions.

{{rfc-2119-intro}}

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:

* Atom provides a lot more functionality than we need for a "blog post" microformat, so we've taken the minimal number of elements needed.
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "bridging the gap"

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, '<code>h</code>') on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]].

The hAtom schema consists of the following:

* hfeed ('''<code>hfeed</code>'''). optional.
** '''<code>feed category</code>'''. optional. keywords or phrases, using '''[[rel-tag]]'''.
** hentry ('''<code>hentry</code>''').
*** '''<code>entry-title</code>'''. required. text.
*** '''<code>entry-content</code>'''. optional (see field description). text. [*]
*** '''<code>entry-summary</code>'''. optional. text.
*** '''<code>updated</code>'''. required using [[datetime-design-pattern]]. [*]
*** '''<code>published</code>'''. optional using [[datetime-design-pattern]].
*** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''. [*]
*** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.
*** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.

[*] Some required elements have defaults if missing, see below.

=== Field and Element Details ===

===== Feed =====
* a Feed element is identified by the class name <code>hfeed</code>
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 Atom feed]
* the Feed element is optional and, if missing, is assumed to be the page
* hAtom documents {{may}} have multiple Feed elements

===== Feed Category =====
* a Feed Category element is identified by [[rel-tag]]
* a Feed {{may}} have a Feed Category
* a Feed Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside a [http://www.atomenabled.org/developers/syndication/#optionalFeedElements feed]
* Feed Category elements {{must}} appear inside a Feed element but not inside an Entry element
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry =====
* an Entry element is identified by class name <code>hentry</code>
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom entry]
* any microformat content inside a <code><blockquote></code> or <code><q></code> element within the Entry should not be considered part of the Entry.
: ''This allows quoting other microformated data without worry of corrupting the model''

===== Entry Category =====
* an Entry Category element is identified by [[rel-tag]]
* an Entry {{may}} have an Entry Category
* an Entry Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside an [http://www.atomenabled.org/developers/syndication/#optionalEntryElements entry]
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry Title =====
* an Entry Title element is identified by the class name <code>entry-title</code>
* an Entry {{should}} have an Entry Title
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 Atom entry title]
* if the Entry Title is missing, use
** the first <code><h#></code> element in the Entry, or
** the <code><title></code> of the page, if there is no enclosing Feed element, or
** assume it is the empty string

===== Entry Content =====
* an Entry Content element is identified by class name <code>entry-content</code>
* an Entry {{should}} have Entry Content
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]
* an Entry {{may}} have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
: ''Many web logs split content into multiple sections with a "Read More" link and JavaScript tricks. This is also needed in cases where Entry Titles are coded in-line and are considered part of the content.''
* if the Entry Content is missing, assume it is the empty string

===== Entry Summary =====
* an Entry Summary element is identified by class name <code>entry-summary</code>
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 Atom summary]
* an Entry {{may}} have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry

===== Entry Permalink =====
* an Entry Permalink element is identified by [[rel-bookmark]]
* an Entry {{should}} have an Entry Permalink
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 Atom link in an entry]
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries

===== Entry Updated =====
* an Entry Updated element is identified by class name <code>updated</code>
* an Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 Atom updated]
* an Entry {{should}} have an Entry Updated element
* use the [[datetime-design-pattern]] to encode the updated datetime
* if there is no Entry Updated element,
** use the Entry Published element, if present
** otherwise the page is invalid hAtom

===== Entry Published =====
* an Entry Published element is identified by the class name <code>published</code>
* an Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 Atom published]
* use the [[datetime-design-pattern]] to encode the published datetime

===== Entry Author =====
* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 Atom author]
* an Entry Author element {{must}} be encoded in an [[hcard|hCard]]
* an Entry Author element {{should}} be encoded in an <code><address></code> element
* an Entry {{should}} have at least one Entry Author element
* an Entry {{may}} have more than one Entry Author elements
* if the Entry Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the entry is invalid hAtom

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>
<dt>hfeed</dt>
<dd>
The concept of atom:feed from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>hentry</dt>
<dd>
The concept of atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-title</dt>
<dd>
The concept of atom:title inside of an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-content</dt>
<dd>
The concept of atom:content from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-summary</dt>
<dd>
The concept of atom:summary from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>bookmark</dt>
<dd>
The concept of atom:link (without any "rel") with an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>published</dt>
<dd>
The concept of atom:published from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>updated</dt>
<dd>
The concept of atom:updated from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>author</dt>
<dd>
The concept of atom:author from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
</dl>
</dd>
</dl>
</pre>

== Examples ==

See [[hatom-examples]].

=== Examples in the wild ===

See [[hatom-examples-in-wild]].

== Implementations ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse hAtom links. If you have an hAtom implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page.

* [http://spinn3r.com/opensource.php Spinn3r Open Source] - implemented in [http://spinn3r.com Spinn3r] and part of [http://code.tailrank.com/feedparser FeedParser] and our announcement of [http://blog.spinn3r.com/2008/01/announcing-spin.html hAtom in Spinn3r 2.1]
* [http://dichotomize.com/uf/hatom/creator.html hAtom Creator] modified from the other creators by BenWest.
** appears to have broken as of 14 Oct 2007. returns 404, as does each parent directory. site returns default Apache install home page.
* the [http://tools.blogmatrix.com/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://tools.blogmatrix.com/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://tools.blogmatrix.com/extract/ Almost Universal Microformat Parser]
* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)
* There is now an [http://www.lukearno.com/projects/hatom2atom/ hatom2atom proxy] that uses hAtom2Atom.xsl.
* [http://placenamehere.com/article/185/SubscribingTohAtomFeedsWithNetNewsWire Subscribe To hAtom] is a script that provides [http://ranchero.com/netnewswire/ NetNewsWire 2.x] users with the ability to subscribe to hAtom documents as they would any other feed. by [[User:ChrisCasciano|Chris Casciano]].
* [http://boxtheweb.mihopa.net/code/apis/#outlineclasses Outline Classes] - has GPL'ed PHP code for reading hAtom
* [http://boxtheweb.4x2.net/ BoxtheWeb] - supports subscribing to hAtom as a feed format


== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc4287 RFC4287: The Atom Syndication Format]
* [[hcard-parsing]]
* [[rfc-2119|RFC 2119]]
* [[iso-8601|ISO8601]]

=== Informative References ===
* [http://www.atomenabled.org/ atomenabled.org]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:

* [[blog-post-brainstorming|blog-post Brainstorming]]

=== Version 0.1 ===

Version 0.1 was released 28 February 2006.

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.

==See Also==
{{hatom-related-pages}}
* [[rel-enclosure]] - how to semantically reference enclosures (e.g. podcasts) in hAtom
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)

hatom

2008-01-09T00:50:43Z

Gazza: /* Draft Specification */ As only a draft, surely "will be" open standard in the future?

<h1> hAtom 0.1 </h1>

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the [http://www.atomenabled.org/ Atom] syndication format. hAtom will be one of several [[microformats]] open standards.

__TOC__
== Draft Specification ==

;Editor/Author
:[http://blogmatrix.blogmatrix.com/ David Janes] ([http://www.blogmatrix.com BlogMatrix, Inc.])

;Contributors
:[http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]
:[http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati, Inc.])

=== Copyright ===
{{MicroFormatCopyrightStatement2005}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

=== Patents ===
{{MicroFormatPatentStatement}}

== Introduction ==

hAtom is a [[microformat]] for identifying semantic information in weblog posts and practically any other place [http://www.atomenabled.org/ Atom] may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions.

{{rfc-2119-intro}}

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:

* Atom provides a lot more functionality than we need for a "blog post" microformat, so we've taken the minimal number of elements needed.
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "bridging the gap"

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, '<code>h</code>') on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]].

The hAtom schema consists of the following:

* hfeed ('''<code>hfeed</code>'''). optional.
** '''<code>feed category</code>'''. optional. keywords or phrases, using '''[[rel-tag]]'''.
** hentry ('''<code>hentry</code>''').
*** '''<code>entry-title</code>'''. required. text.
*** '''<code>entry-content</code>'''. optional (see field description). text. [*]
*** '''<code>entry-summary</code>'''. optional. text.
*** '''<code>updated</code>'''. required using [[datetime-design-pattern]]. [*]
*** '''<code>published</code>'''. optional using [[datetime-design-pattern]].
*** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''. [*]
*** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.
*** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.

[*] Some required elements have defaults if missing, see below.

=== Field and Element Details ===

===== Feed =====
* a Feed element is identified by the class name <code>hfeed</code>
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 Atom feed]
* the Feed element is optional and, if missing, is assumed to be the page
* hAtom documents {{may}} have multiple Feed elements

===== Feed Category =====
* a Feed Category element is identified by [[rel-tag]]
* a Feed {{may}} have a Feed Category
* a Feed Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside a [http://www.atomenabled.org/developers/syndication/#optionalFeedElements feed]
* Feed Category elements {{must}} appear inside a Feed element but not inside an Entry element
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry =====
* an Entry element is identified by class name <code>hentry</code>
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom entry]
* any microformat content inside a <code><blockquote></code> or <code><q></code> element within the Entry should not be considered part of the Entry.
: ''This allows quoting other microformated data without worry of corrupting the model''

===== Entry Category =====
* an Entry Category element is identified by [[rel-tag]]
* an Entry {{may}} have an Entry Category
* an Entry Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside an [http://www.atomenabled.org/developers/syndication/#optionalEntryElements entry]
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry Title =====
* an Entry Title element is identified by the class name <code>entry-title</code>
* an Entry {{should}} have an Entry Title
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 Atom entry title]
* if the Entry Title is missing, use
** the first <code><h#></code> element in the Entry, or
** the <code><title></code> of the page, if there is no enclosing Feed element, or
** assume it is the empty string

===== Entry Content =====
* an Entry Content element is identified by class name <code>entry-content</code>
* an Entry {{should}} have Entry Content
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]
* an Entry {{may}} have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
: ''Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.''
* if the Entry Content is missing, assume it is the empty string

===== Entry Summary =====
* an Entry Summary element is identified by class name <code>entry-summary</code>
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 Atom summary]
* an Entry {{may}} have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry

===== Entry Permalink =====
* an Entry Permalink element is identified by [[rel-bookmark]]
* an Entry {{should}} have an Entry Permalink
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 Atom link in an entry]
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries

===== Entry Updated =====
* an Entry Updated element is identified by class name <code>updated</code>
* an Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 Atom updated]
* an Entry {{should}} have an Entry Updated element
* use the [[datetime-design-pattern]] to encode the updated datetime
* if there is no Entry Updated element,
** use the Entry Published element, if present
** otherwise the page is invalid hAtom

===== Entry Published =====
* an Entry Published element is identified by the class name <code>published</code>
* an Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 Atom published]
* use the [[datetime-design-pattern]] to encode the published datetime

===== Entry Author =====
* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 Atom author]
* an Entry Author element {{must}} be encoded in an [[hcard|hCard]]
* an Entry Author element {{should}} be encoded in an <code><address></code> element
* an Entry {{should}} have at least one Entry Author element
* an Entry {{may}} have more than one Entry Author elements
* if the Entry Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the entry is invalid hAtom

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>
<dt>hfeed</dt>
<dd>
The concept of atom:feed from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>hentry</dt>
<dd>
The concept of atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-title</dt>
<dd>
The concept of atom:title inside of an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-content</dt>
<dd>
The concept of atom:content from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-summary</dt>
<dd>
The concept of atom:summary from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>bookmark</dt>
<dd>
The concept of atom:link (without any "rel") with an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>published</dt>
<dd>
The concept of atom:published from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>updated</dt>
<dd>
The concept of atom:updated from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>author</dt>
<dd>
The concept of atom:author from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
</dl>
</dd>
</dl>
</pre>

== Examples ==

See [[hatom-examples]].

=== Examples in the wild ===

See [[hatom-examples-in-wild]].

== Implementations ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse hAtom links. If you have an hAtom implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page.

* [http://spinn3r.com/opensource.php Spinn3r Open Source] - implemented in [http://spinn3r.com Spinn3r] and part of [http://code.tailrank.com/feedparser FeedParser] and our announcement of [http://blog.spinn3r.com/2008/01/announcing-spin.html hAtom in Spinn3r 2.1]
* [http://dichotomize.com/uf/hatom/creator.html hAtom Creator] modified from the other creators by BenWest.
** appears to have broken as of 14 Oct 2007. returns 404, as does each parent directory. site returns default Apache install home page.
* the [http://tools.blogmatrix.com/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://tools.blogmatrix.com/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://tools.blogmatrix.com/extract/ Almost Universal Microformat Parser]
* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)
* There is now an [http://www.lukearno.com/projects/hatom2atom/ hatom2atom proxy] that uses hAtom2Atom.xsl.
* [http://placenamehere.com/article/185/SubscribingTohAtomFeedsWithNetNewsWire Subscribe To hAtom] is a script that provides [http://ranchero.com/netnewswire/ NetNewsWire 2.x] users with the ability to subscribe to hAtom documents as they would any other feed. by [[User:ChrisCasciano|Chris Casciano]].
* [http://boxtheweb.mihopa.net/code/apis/#outlineclasses Outline Classes] - has GPL'ed PHP code for reading hAtom
* [http://boxtheweb.4x2.net/ BoxtheWeb] - supports subscribing to hAtom as a feed format


== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc4287 RFC4287: The Atom Syndication Format]
* [[hcard-parsing]]
* [[rfc-2119|RFC 2119]]
* [[iso-8601|ISO8601]]

=== Informative References ===
* [http://www.atomenabled.org/ atomenabled.org]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:

* [[blog-post-brainstorming|blog-post Brainstorming]]

=== Version 0.1 ===

Version 0.1 was released 28 February 2006.

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.

==See Also==
{{hatom-related-pages}}
* [[rel-enclosure]] - how to semantically reference enclosures (e.g. podcasts) in hAtom
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)

implementations

2008-01-09T00:45:26Z

Gazza: /* WP Themes */ Add Barthelme - hAtom + hCard supporting theme

<h1>Microformats Implementations</h1>
{{TOC-right}}
This page lists the applications, plugins, sample code, services, tools that produce or consume microformats. This is only a partial list. If you know other services or tools for or supporting microformats, please add them, link to their [[implementors]], and list what specific microformats they support.

== Implementations vs. Examples in the Wild ==
This page is ''only'' for implementations of tools that publish or consume microformats. Companies simply ''using'' microformats on their pages/sites belong in the "Examples in the wild" sections of those respective microformats, e.g.:
* [[hcard-examples-in-wild|hCard Examples in the wild]]
* [[hcalendar-examples-in-wild|hCalendar Examples in the wild]]
* etc.

== Editing This Page ==
When you find an implementation, first make sure that it is ''actually'' an implementation as opposed to ''just'' an [[hcard-examples-in-wild|example in the wild]] of publishing microformats (see above).

Second, note the name of the ''tool or service'' separately from the name of the ''developer(s)'' who wrote the tool/service.

Add a third level heading with the name of the tool/service ( <code>=== Name of Tool ===</code> ) to the Applications / Plugins / Services / Tools section, sorted alphabetically by name of tool/service. Add a top level list item (*) just below the heading with an external link to the tool/service, along with a link to evidence of their support for microformats, and mention (and locally link) each microformat that is supported.

Add a nested list item <code>* by Name of Developer</code> and local to wiki hyperlink the Name of Developer to a fragment identifier in the [[implementors]] page, e.g. Apple Computer would be linked like this: <code><nowiki>[[implementors#Apple_Computer|Apple Computer]]</nowiki></code>

Check to see if there is an entry for the developer in the [[implementors|list of implementors]], if not add them there. Add a link to the developer's home page followed by "has implemented microformats in:".

In the entry for the developer, add a list item <code>* Name of Tool</code> and local to wiki hyperlink the Name of Tool to a fragment identifier in this page, e.g. X2V would be linked like this: <code><nowiki>[[implementations#X2V|X2V]]</nowiki></code>

Save the page and make sure that each fragment ID local hyperlink when clicked scrolls you to the right spot (for the developer, and for the tool). Make any fix-up edits as necessary. That's it!

== Reporting Bugs ==
In short, [[put-it-on-the-wiki]]. In particular, add bug reports, with URL(s) to a valid demonstrative test case(s) of course, to the listing of an implementation on this page, OR on the specific implementations wiki page (e.g. [[hcard-implementations]]). Please describe why you think it is a bug (user interface, cosmetic, violates a spec page, e.g. for problems parsing hCards, reference which part of [[hcard-parsing]] the implementation appears to not be following).

If you have a sense of urgency for getting that particular bug fixed in that implementation, you may email [http://microformats.org/discuss/ microformats-dev] with the URL of that implementation on the wiki page, and *summarize* the bug (the full description being on the wiki page instead).

== Formats ==
Most microformat specifications have an "implementations" section, e.g.:
*[[rel-tag#Implementations|rel-tag implementations]]
*[[vote-links#Implementations|vote-link implementations]]
*[[xoxo#Implementations|XOXO implementations]]

In addition, some microformat specifications have separate implementation pages:
*[[hcalendar-implementations|hCalendar implementations]]
*[[hcard-implementations|hCard Implementations]]
*[[xfn-implementations|XFN implementations]]

== Applications / Plugins / Services / Tools ==
This is an alphabetical listing of all applications, plugins (grouped with their app/tool), services and tools that implement microformats, along with the list of microformats that are supported, and the company and/or developers responsible for it.

As a user, the implementations listed below will automatically help you use microformats and help your data portability and interoperability with other apps and services.

Please help complete this list! If you know of additional apps/plugins/services/tools that support microformats, please add them!

Note: this section is only for listing specific ''implementations''. The list of ''implementors'' is in the [[implementors#Companies / Developers / Organizations|Companies / Developers / Organizations]] section on the [[implementors]] page.

Alphabetically:

=== .Mac Webmail ===
* The [http://www.mac.com/webmail .Mac Webmail] ''service'' now [http://factoryjoe.com/blog/2006/10/28/apple-embraces-microformats-in-new-mac-webmail/ supports hcard].
** by [[implementors#Apple_Computer|Apple Computer]]

=== AlchemyPoint ===
* [http://www.orch8.net/ AlchemyPoint] is a structured web / mashup platform that supports parsing hCard, rel-tag and other microformats.
** by [[implementors#Orchestr8|Orchestr8]]

=== Backnetwork ===
* [http://backnetwork.com/ Backnetwork] is a community networking tool for events that supports [[hCard]], [[hCalendar]], and [[XFN]].
** by [[implementors#Glenn_Jones|Glenn Jones]] of [[implementors#Madgex|Madgex]].

=== Blinksale ===
* [http://blinksale.com Blinksale] uses [[hcard|hCard]] standard throughout for people and companies.

=== BlogMatrix ===
* [http://www.blogmatrix.com BlogMatrix] - user information marked as [[hcard|hCard]], tag directories in [[xfolk]]/[[rel-tag]], enclosures are marked as [[rel-enclosure]].
** by [[implementors#David_Janes|David Janes]]

=== Blogmarks.net ===
* [http://www.blogmarks.net Blogmarks.net] publish user bookmarks in [[xfolk]]/[[rel-tag]].

=== Bugzilla ===

* [http://www.bugzilla.org/ Bugzilla] [http://www.bugzilla.org/status/2007-08-23.html 3.1.1] includes some microformats on show_bug.cgi and a few other places.

=== cmSiteNavigation ===
* [http://www.christophm.de/software/firefox/cmSiteNavigation/ cmSiteNavigation] extension for Firefox make use of links marked with a [[existing-rel-values|"rel" value]], and parses additional link types also.

=== Community Server ===
* [http://communityserver.org Community Server] supports tagging posts with [[rel-tag]], implements [[rel-nofollow]] on links in comments, and allows users to create link lists using [http://gmpg.org/xfn/ XFN].

=== Conferenceer ===
* Built for SXSW 2007, [http://sxsw07.conferenceer.com/ Conferenceer] supports hcalendar and hcard.

=== Citycita===
* [http://www.citycita.org Citycita] supports [[hCal|hCal]] in all event pages for local social groups.
** by [[implementors#Rubio_Jamin|Rubio Jamin]]

=== Cork'd ===
* [http://corkd.com Cork'd] supports [[hcard|hCard]] for user profiles, [[hreview|hReview]] for wine reviews, along with [[rel-tag]] for tagging wines as announced in [http://www.simplebits.com/notebook/2006/06/10/wineformats.html Pairing Wine and Microformats]
** by [[implementors#Dan_Cederhold|Dan Cederholm]]

=== Delicious Generation ===
* [http://deliciousgeneration.com/ Delicious Generation] supports [[hCal|hCal]] for the event and [[hcard|hCard]] for sponsors and people.
** by [[implementors#Chris_Messina|Chris Messina]]

=== Digg ===
* [http://digg.com/ Digg] supports [[hcard|hCards]] for profiles and rel-me for identity consolidation (though they currently mix rel-nofollow with rel-me, negating these links).

=== Dreamweaver ===
==== Microformats Extensions ====
* [http://www.webstandards.org/action/dwtf/microformats Dreamweaver Microformats Extensions] ([http://allinthehead.com/beta/microformats.mxp.zip download]) support authoring [[hcard|hCard]], [[hcalendar|hCalendar]], [http://gmpg.org/xfn XFN], [[rel-tag]], [[rel-license]] as [http://allinthehead.com/retro/282/microformats-in-dreamweaver announced by Drew]
** by [[implementors#Drew_Mclellan|Drew McLellan]]

=== Drupal ===
==== Upcoming module for Drupal ====
* [http://hybernaut.com/upcoming-module Drupal Upcoming.org syndication module] emits [[hcalendar|hCalendar]]
** by [[implementors#Brian_Del_Vecchio|Brian Del Vecchio]]

=== Etnies ===
* [http://etnies.com/extra/calendar/ Etnies Calendar] supports hcalendar. Maybe the [http://thecolab.com/blog/2007/01/22/etniescom-relaunch/ first skate-shop to support microformats].

=== Eventful ===
* [http://eventful.com Eventful] supports [[hcalendar|hCalendar]] for over 1,000,000 event listings and [[hcard|hCard]] for venues.

=== Facebook ===
* [http://facebook.com/ Facebook] supports [[hcard|hCard]] for some public profiles '''(example needed)'''.
* There is also an [http://www.facebook.com/apps/application.php?id=2400943827&ref=s hCard application] (a plug-in) for Facebook users.
* Note also the [http://www.facebook.com/group.php?gid=2374732285 microformats group], which Facebook users who support microformats can join.

=== Ficlets ===
* [http://ficlets.com Ficlets] supports [[hcard]] for author data and [[hatom]] for stories and lists of stories.
** [http://sixtwothree.org Jason Garber] and [http://lawver.net Kevin Lawver] for [http://aol.com AOL]

=== Finetoothcog ===
* [http://finetoothcog.com/site/stolen_bikes Stolen Bikes] now supports [[hcalendar|hCalendar]] for reported stolen bikes. Also provides iCal subscription.

=== Firefox ===
* See [[firefox-extensions]]

=== FunAdvice ===
* [http://funadvice.com FunAdvice] supports using the rel-nofollow tag to prevent users posting content simply for the search engine benefit, to improve teh quality of the advice giving community.

=== Gravatar Commenters as hCards ===
* [http://thedredge.org Andy Hume] added code to his blogging software to automatically mark-up the names and URLs of commenters on his blog with [[hcard|hCard]].
** by [[implementors#Andy_Hume|Andy Hume]]
** Andy - any chance of open sourcing your code to turn Gravatars into hCards?

=== Flickr People ===
* [http://flickr.com/ Flickr]'s profiles on its people pages supports both [[hcard|hCard]] and [http://gmpg.org/xfn XFN].
** by [[implementors#Cal_Henderson|Cal Henderson]]
**[http://flickr.com/people/tantek example]

=== Flickr Photos ===
* [http://flickr.com/map/ Flickr's geo tagged photos] are marked up with the [[geo]] microformat.

=== Flock Web Browser ===
* The [http://flock.com Flock web browser] supports the [[rel-tag]] microformat.
** by [[implementors#Flock|Flock]]

=== Google Search ===
* [http://google.com/ Google Search] - supports [[rel-nofollow]]
** by [[implementors#Google|Google]]

=== Google Blogger ===
* [http://blogger.com/ Blogger] supports [[hatom|hAtom]] (citation to blog post needed - 2007)
** by [[implementors#Google|Google]]

=== Google Creative Commons Search ===
* [http://www.google.com/webhp?as_rights=(cc_publicdomain%7Ccc_attribute%7Ccc_sharealike%7Ccc_noncommercial%7Ccc_nonderived) Google Creative Commons Search] - supports [[rel-license]]
** by [[implementors#Google|Google]]

=== Google Maps ===
* [http://maps.google.com/ Google Maps] supports [[hcard|hCard]] (see [http://googlemapsapi.blogspot.com/2007/06/microformats-in-google-maps.html 2007-06-31 announcement by Google])
* Google maps also allows reviewers and map creators to [http://maps.google.com/maps/me attach a public profile], which includes hCard and rel="me' XFN markup. See [http://google-latlong.blogspot.com/2007/10/put-yourself-on-map.html 2007-10-17 announcement]. Sample profile: [http://maps.google.com/maps/user?uid=109581870574956225297 Kevin Marks].
** by [[implementors#Google|Google]]
**Unfortunately, [http://microformats.org/discuss/mail/microformats-discuss/2007-July/010311.html Google Map's implementation is broken]. [http://microformats.org/discuss/mail/microformats-discuss/2007-August/010457.html Google are aware; a fix is awaited].
** Also, there is no hCard nor any XFN rel values on the [http://maps.google.com/maps/user?uid=109581870574956225297 sample profile] itself, it appears to include a [http://maps.google.com/maps/c/widgets/ProfileViewer?js=RAW&maximize=true&hide=false&width=40&noTitle=true&theme=theme_2&service=local&uid=109581870574956225297&height=0&background=transparent&serverbased=true&border=NONE&eventCallback=ParentStub1192999211538&zx=dc574o15j0wrv frame] which then has an hCard and rel="me" to the user's blog.

=== Greasemonkey ===
* [http://greasemonkey.makedatamakesense.com/google_hcalendar/ Google hCalendar] - Adds hCalendar data to Google Calendar.
* [http://www.nickpeters.net/?p=35 Social xFolk] - Adds xFolk links to social bookmarking sites del.icio.us and ma.gnolia.

=== hCalendar creator ===
* [http://microformats.org/code/hcalendar/creator hCalendar creator] (originally [http://theryanking.com/microformats/hcalendar-creator.html published by Ryan King]) is a javascript form for creating [[hcalendar|hCalendar]] events.
** by [[implementors#Ryan_King|Ryan King]]

=== hCard to Gmail Service ===
* [http://jkg3.com/Journal/81/bookmarklet hCard to gmail] is a bookmarklet / service which will convert hCard formatted data to the .CSV file for importing to gmail.
** by [[implementors#Jamie_Knight|Jamie Knight]]

=== hCard creator ===
* The open source [http://microformats.org/code/hcard/creator hCard creator] (originally [http://tantek.com/microformats/hcard-creator.html published by Tantek]) is a very simple, yet illustrative, open source user interface / form / script which creates an [[hcard|hCard]] in real-time as you type in a set of contact information.
** by [[implementors#Tantek_Çelik|Tantek Çelik]]

=== hKit Microformats Toolkit for PHP5 ===
* [http://hkit.googlecode.com/ hKit Microformats Toolkit for PHP5] as [http://allinthehead.com/retro/291/hkit-microformats-toolkit-for-php announced by Drew McLellan]. See also [[hkit|hKit on this wiki]].

=== hReview creator ===
* [http://microformats.org/code/hcalendar/creator hReview creator] (originally [http://theryanking.com/microformats/hreview-creator.html published by Ryan King]) is a javascript form for creating [[hreview|hReviews]].
** by [[implementors#Ryan_King|Ryan King]]

=== Ice Rocket ===
* [http://icerocket.com] - [http://blogs.icerocket.com/tag/ supports] [[rel-tag]]

=== iChat buddy list to hCards ===
* [http://tantek.com/microformats/buddylist2hcards.html iChat buddy list to hCards] - open source AppleScript to automatically convert one's buddy list in the MacOSX iChat AIM client into a valid XHTML 1.0 Strict list of hCards.
** by [[implementors#Tantek_Çelik|Tantek Çelik]]

=== Internet Explorer ===
* See [[internet-explorer-extensions]]

=== JobiJoba ===
* [http://www.jobijoba.com JobiJoba : moteur de recherche emploi] parses and supports [[hCard|hCard]] and [[rel-tag|rel-tag]] for over 40,000 job listings.

=== JSCalendar ===
* [http://web.mit.edu/glasser/www/JSCalendar/ JSCalendar] parses [[hcalendar|hCalendar]] and produces a displayable HTML table/CSS-based calendar.

=== Konqueror ===
* [http://www.konqueror.org/ Konqueror] - [http://flickr.com/photos/factoryjoe/68755089/ supports] [[hcard|hCard]]

=== Last.fm ===
* [http://last.fm Last.fm] - [http://factoryjoe.com/blog/2006/10/31/lastfm-adds-support-for-hcalendar/ Last.fm supports] [[hcalendar|hCalendar]]

=== LouderVoice ===
* [http://www.loudervoice.com Publishes and aggregates hreview content] - The LouderVoice site provides a variety of tools to publish hreview to blogs and it also aggregates hreview content from any registered RSS Feed so that users can search/rate/collect distributed reviews.

=== Laughing Squid Calendar ===
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events listings support [[hcalendar|hCalendar]].
** by [http://laughingsquid.com/ Laughing Squid]

=== LinkedIn ===
* [http://www.linkedin.com LinkedIn] - LinkedIn includes [[hcard|hCard]] and [[xfn|XFN]] on contacts, [[hresume|hResume]] for public profiles and [[hreview|hReview]] on service provider recommendations

=== Live Clipboard ===
* [http://spaces.live.com/editorial/rayozzie/demo/liveclip/liveclipsample/techPreview.html Live Clipboard Technical Introduction]
* [http://spaces.live.com/editorial/rayozzie/demo/liveclip/liveclipsample/clipboardexample.html Live Clipboard Example]

=== LiveJournal ===
* [http://www.livejournal.com LiveJournal]
** supports tagging posts with [[rel-tag]]
** supports [[hcard-supporting-user-profiles|hCard user profiles]] and [[XFN]] ([http://community.livejournal.com/lj_releases/24768.html 2007-09-27 release #15]).

=== LJFind ===
* [http://www.ljfind.com LJ-Find] - LJFind supports tagging posts with [[rel-tag]].

=== Ma.gnolia ===

* [http://ma.gnolia.com Ma.gnolia] has wide [http://wiki.ma.gnolia.com/Ma.gnolia_Feeds_Guide#Microformats support for a variety of microformats] including [[rel-tag]], [[xfolk]], [[hreview]], [[xfn]] and [[hcard]].

=== Maxthon ===
[http://maxthon.com Maxthon] is a browser for Microsoft Windows that uses the Trident rendering engine and provides additional user interface. Maxthon has built and published a plugin for their browser that recognizes microformats in web pages and allows users to take action with them, similar to Operator for [[Firefox]].
* [http://forum.maxthon.com/index.php?showtopic=65408 Microformats Button Version 1.0.0 Release Candidate 1]
** Description: "Microformats Button extracts Microformats from websites and allows you to export the data to vCard, vCalendar, Google Maps, Yahoo Maps and other sites."

=== Microformat Base ===
* [http://randomchaos.com/microformats/base/ Microformat Base]
** by [[implementors#Scott Reynen|Scott Reynen]]

=== Microformat Bookmarklet Overlay ===
* [http://leftlogic.com/info/articles/microformats_bookmarklet Microformats Bookmarklet] for Safari, Firefox and Camino, supports [[hcard|hCard]] and [[hcalendar|hCalendar]] and allows the user to import individual microformats on the fly.
** by [[implementors#Remy_Sharp|Remy Sharp]]

=== Microformat Parser for Ruby ===
* [http://blog.labnotes.org/2005/11/20/microformat-parser-for-ruby/ Microformat Parser for Ruby]
** by [[implementors#Assaf Arkin|Assaf Arkin]]

=== MyMap.yam.com ===
* support [[geo]] microformat in the POI page. example: [http://mymap.yam.com/place/point/charleschuang/6695/ a book store in Tamsui].

=== National eXtension Initiative ===
* [http://www.extension.org/ eXtension Home] - content marked-up with [[hatom|hAtom]] and events marked-up as [[hcalendar|hCalendar]] entries.
** by [[implementors#James E. Robinson, III|James E. Robinson, III]]

=== Nature Network Boston ===
* [http://network.nature.com/boston/ Nature Network Boston], a social networking community for scientists, supports [[reltag|rel-tag]], [[hcard|hCard]] for user profiles and [[hcalendar|hCalendar]] for marking up events across the site.
** by [[implementors#Nature Publishing Group|Nature Publishing Group]]

=== Nature Protocols ===
* [http://www.nature.com/nprot/ Nature Protocols], a forum for scientists to upload and comment on protocols, supports [[hcard|hCard]] and [[XOXO]].
** by [[implementors#Nature Publishing Group|Nature Publishing Group]]

=== NetNewsWire ===
*[http://www.newsgator.com/Individuals/NetNewsWire/ NetNewsWire] is an easy-to-use RSS and Atom reader for your Mac. NetNewsWire 3.0 detects, extracts and converts hcard and hcalendar data from feed entries.
** by [[implementors#NewsGator|NewsGator]]

=== Netscape Navigator ===
* Version 9.0+ supports [[Firefox extensions]], e.g. [[Operator]]:
** [http://notizblog.org/2007/10/21/operator-unter-navigator-90/ Operator unter Navigator 9.0]

=== Nutch ===
* [http://www.mail-archive.com/nutch-dev@lucene.apache.org/msg01295.html rel-nofollow support added]
* [http://www.mail-archive.com/nutch-commits@lucene.apache.org/msg01014.html rel-tag support checked in]

=== ODEO ===
* [http://odeo.com/ ODEO] [http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html noted] that they support microformats: [[rel-tag]], [[rel-enclosure]], [http://gmpg.org/xfn XFN].

=== Optimus ===
*[http://microformatique.com/optimus/ Optimus]. Output formats: XML, JSON, JSON-P.

=== phpMicroformats ===
* [http://enarion.net/phpmicroformats/ phpMicroformats] is a PHP class library that generates microformat entries for [[hcalendar|hCalendar]] and [[hcard|hCard]]. It is released under GPL.

=== Portable Social Network Profile Parser ===
* [http://lab.backnetwork.com/ufXtract-psn/ Portable Social Network Profile Parser] implements parsing of [[hCard]], [[XFN]], and in particular [[rel-me]] for [[identity-consolidation]] for [[social-network-portability]].
** by [[implementors#Glenn_Jones|Glenn Jones]] of [[implementors#Madgex|Madgex]].

=== PostNuke ===
''[http://www.postnuke.com PostNuke] is an Application Framework/Content Management Systeme''
* [http://www.pagesetter.net/index.php?module=pagesetter&func=viewpub&tid=4&pid=96 hCards4Pagesetter] - hCards Publication Type for the PostNuke module "Pagesetter"
* [http://www.pagesetter.net/index.php?module=pagesetter&func=viewpub&tid=4&pid=97 hCalendar4Pagesetter] - hCalendar Publication Type for the PostNuke module "Pagesetter"
* [http://www.pagesetter.net/index.php?module=pagesetter&func=viewpub&tid=4&pid=98 hReview4Pagesetter] - hReview Publication Type for the PostNuke module "Pagesetter"
* [http://noc.postnuke.com/frs/?group_id=256&release_id=477 Blogroll] - XFN Block/Modul
* [http://noc.postnuke.com/frs/?group_id=256&release_id=628 nofollow] - nofollow Hook

=== Pownce ===
*[http://pownce/ Optimus]. Output formats: XML, JSON, JSON-P.

=== Profiler ===
* [http://microformat.makedatamakesense.com/profiler/ Profiler] works as a proxy service adding microformat profiles to documents that appear to contain microformats.

=== RFC2629.xslt ===
* [http://greenbytes.de/tech/webdav/rfc2629.xslt rfc2629.xslt] now attempts to generate [[hcard|hCard]] information ([http://ietf.org/rfc/rfc2629 RFC2629] in an XML format for authoring RFCs and Internet Drafts, see [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html example document])

=== Salesforce ===
* [http://salesforce.com Salesforce] [http://flickr.com/photos/kingsleyj/175689109/ supports] [[hcard|hCard]]
** by [http://flickr.com/people/kingsleyj/ Kingsley Joseph]
==== Spanning Salesforce ====
* [http://spanningsalesforce.com/ Spanning Salesforce] supports [[hcalendar|hCalendar]].

=== Sivitools ===
<blockquote>
Sivitols is a Java library for microformats. Currently only the xFolk RC1 standard is implemented, but additional microformat support is planned. This library is being written and maintained for a tag sharing project undertaken by Video Vertigo.
</blockquote>
[http://blog.blip.tv/blog/microformats/ Annoucement], [http://pokkari.com/microformat/javadoc/ Docs]

=== SPRACI ===
* [http://www.spraci.com SPRACI] - nightlife/events - [[hcalendar|hCalendar]] published in events listings, aggregator can read hCalendar

=== stuckUnstuck ===
* [http://stuckunstuck.com stuckUnstuck] supports [[hcard|hCard]] and [[hatom|hatom]].

=== Sunnyvale House Concerts ===
* [http://concerts.shrub.ca/shows Sunnyvale House Concerts] supports [[hcard|hCard]] and [[hcalendar|hCalendar]].

=== Technorati Contacts Feed Service ===
* [http://feeds.technorati.com/contacts/ Technorati Contacts Feed Service] is a deployment of [[implementations#X2V|X2V]] to convert [[hcard|hCards]] to vCard (.vcf) format.
** by [[implementors#Technorati|Technorati]]

=== Technorati Events Feed Service ===
* [http://feeds.technorati.com/events/ Technorati Events Feed Service] is a deployment of [[implementations#X2V|X2V]] to convert [[hcalendar|hCalendar]] events to iCalendar (.ics) format.
** by [[implementors#Technorati|Technorati]]

=== Technorati Microformats Search ===
* Technorati [http://kitchen.technorati.com/search/ Microformats Search]. Search for contacts ([[hcard|hCard]]), events ([[hcalendar|hCalendar]]), or reviews ([[hreview|hReview]]) published on blogs and other web sites.
** by [[implementors#Ryan_King|Ryan King]]
** first version (2006 May) by [[implementors#Tantek_Çelik|Tantek Çelik]], [[implementors#Ryan_King|Ryan King]], [[implementors#Kevin_Marks|Kevin Marks]], [[implementors#Josh_Smith|Josh Smith]]

=== Technorati Search ===
* [http://technorati.com/ Technorati] [http://technorati.com/search Search] supports and handles both [[vote-links]] and [[rel-nofollow]] for indicating whether a link should have any/positive/negative weighting towards the destination.
** by [http://technorati.com/about/staff.html Technorati Staff]

=== Technorati Tags ===
* [http://technorati.com/tags/ Technorati Tags] pages aggregate blog posts tagged with the [[rel-tag]] open tagging standard, in addition to recent tagged photos and links.

=== Textpattern ===
==== Microformats Plugin ====
* [http://placenamehere.com/TXP/pnh_mf/ Textpattern Microformats Plugin] supports authoring [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [http://gmpg.org/xfn XFN], [[rel-tag]], [[rel-license]] in the [http://www.textpattern.com/ Textpattern] CMS/blogging tool
** by [http://placenamehere.com/ Chris Casciano]

=== Tomota ===
* The [http://www.tomota.de Tomota] allows import, export and conversion from and to hcards.
** by [[implementors#RalfEngels|Ralf Engels]]

=== TYPO3 ===
* [http://www.typo3.com TYPO3], [http://typo3.org TYPO3 Developer Ressource]
==== tt_address extension====
* [http://typo3.org/extensions/repository/view/tt_address/2.0.1/ tt_address] - hCard support with the tt_address extension version 2.0.0
** by [[implementors#Ingo_Renner|Ingo Renner]]
==== TIMTAB extension====
* [http://typo3.org/extensions/repository/view/timtab/0.5.11/ TIMTAB] - XFN support for blogrolls with the TIMTAB weblog extension for TYPO3
** by [[implementors#Ingo_Renner|Ingo Renner]]

=== Tweeterboard ===
* Tweeterboard supports [hcard|hCard]], and [http://gmpg.org/xfn XFN] on profile pages ([http://tweeterboard.com/user/missrogue example]).

=== Twitter ===

* [http://twitter.com Twitter] [http://twitter.com/al3x/statuses/53982402 supports] [[hatom|hAtom]], [[hcard|hCard]], and [http://gmpg.org/xfn XFN].
** hCards for groups are marked up with "fn" not "fn org". See, for example, [http://twitter.com/microformats microformats on Twitter]
** Improper address mark-up (no child properties; though this may be all that can be achieved, if the user enters a value like "Birmingham, England")
** Uses <code>class="label"</code> for non-hCard purpose.

=== ufXtract ===
* [http://lab.backnetwork.com/ufXtract/ ufXtract] implements [[parsing]] of microformats such as [[hCard]] and [[XFN]].
** by [[implementors#Glenn_Jones|Glenn Jones]] of [[implementors#Madgex|Madgex]]. See [http://www.glennjones.net/Post/831/ufXtractmicroformatsparser.htm blog post announcement].

=== Upcoming.org ===
* [http://upcoming.org Upcoming.org] - hCalendar support in events listings and individual events.
** by [[implementors#Andy_Baio|Andy Baio]], [[implementors#Leonard_Lin|Leonard Lin]], [[implementors#Gordon_Luk|Gordon Luk]]

=== vCardExplorer ===
* [http://vcardexplorer.corefault.de/ vCardExplorer for MacOSX] - browses local vcards and converts hcards from URLs.

=== WindowsLiveWriter ===
* [[implementors#Microsoft|Microsoft's]] WindowsLiveWriter (WLW) [http://gallery.live.com/liveItemDetail.aspx?li=9751e563-1408-4fc3-8028-bd4351edb1fb&l=8 event plugin] supports [[hcalendar|hCalendar]].

=== WordPress ===
* [http://wordpress.org WordPress] supports [http://gmpg.org/xfn/ XFN] blogrolls through a very nice built-in user interface. (cf. [[xfn-implementations]])
** by [[implementors#Matt_Mullenweg|Matt Mullenweg]] and friends

==== WP Microformatted Blogroll ====
* The [http://factorycity.net/projects/wp-microformatted-blogroll/ WP Microformatted Blogroll 0.2] Wordpress plugin by [[implementors#Chris_Messina|Chris Messina]] supports [[hcard|hCard]] and [http://gmpg.org/xfn/ XFN].

==== hCard About Box ====
* The [http://redmonk.net/projects/widget_hcard_about/ hCard About Box] widget by [[implementors#Steve_Ivy|Steve Ivy]] supports [[hcard|hCard]].

====GigPress====
* [http://gigpress.com/ GigPress] is a WordPress plugin that manages and displays concerts and tours for bands or other touring acts, and outputs them with [[hcalendar|hCalendar]] markup. By [[implementors#Derek_Hogue|Derek Hogue]].

==== VoteBack Plugin ====
* The [http://redmonk.net/archives/2006/12/21/voteback/ VoteBack plugin for Wordpress] by [[implementors#Steve_Ivy|Steve Ivy]] checks incoming pingbacks and trackbacks for [[votelinks]].

==== Save Microformats Plugin ====
* [http://notizblog.org/projects/save-microformats/ Save Microformats plugin for Wordpress] - a plugin to save posted Microformats using technorati feeds.

==== WP Themes ====
* [http://www.plaintxt.org/themes/barthelme/ Barthelme] is a theme for Wordpress that uses [[hatom|hAtom]] and [[hcard|hCard]].
* [http://www.plaintxt.org/themes/sandbox/ Sandbox] is a theme for Wordpress that uses [[hatom|hAtom]].
** The theme is also available to accounts on the <username>.wordpress.com hosting service.
* [http://www.jesuscarrera.info/proyectos/startpoint/ StartPoint] A theme for theme developers. A good start point to make your own templates. It supports multiple languages, widgets, contains semantic hAtom microformats, and more.
* [http://www.whump.com/dropbox/Strangelove.zip Strangelove] is a modification of the default Wordpress theme (Kubrick) with [[hatom|hAtom]] support.
** It points to the hAtom2Atom proxy service as the link for syndication feeds.

=== X2V ===
* Brian Suda has created several XSLT files to extract microformats from HTML. From that the [http://suda.co.uk/projects/X2V/ X2V] webservice/favelet emerged. The XSLT and favelet extracts [[hcard|hCard]] and to produces .vcf (vCard) files and [[hcalendar|hCalendar]] to produce .ics (iCal) files. Also in the labs is a universal XMDP validator and a site-wide search spider that recognizes 'no-follow', 'license' and other microformats so they can be used in a more semantic way when displaying search results.
** by [[implementors#Brian_Suda|Brian Suda]]

=== XWiki ===
* [http://xwiki.org XWiki] (as of [http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWiki10Beta5 version 10Beta5]) publishes the user profiles using [[hcard | hCard]], the events in the calendar application using [[hCalendar | hCalendar]], the blog entries using [[hAtom | hAtom]] and homepage links using [[rel-home | rel-home]].

=== Yahoo Creative Commons Search ===
* [http://search.yahoo.com/cc/ Yahoo Creative Commons Search] - supports [[rel-license]] specifically to search for Creative Commons licensed content.

=== Yahoo Local ===
* [http://local.yahoo.com Yahoo local] supports [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]].

=== Yahoo Tech ===
* [http://tech.yahoo.com Yahoo! Tech] supports [[hreview|hReview]].

=== Yahoo UK Movies ===
* [http://movies.yahoo.co.uk Yahoo! UK Movies] supports [[hreview|hReview]].
** by Mark Norman Francis

=== Yedda ===
* [http://yedda.com Yedda] supports [[hcard|hCard]] for exposing users information, [[hatom|hAtom]] for exposing data that is already exposed via feeds (like list of questions and answers) and [[rel-tag|rel-tag]] for every tag used to tag questions and users.

== Validators ==
This is an alphabetical listing of tools that have been created to validate implementations, and which formats they support.

Please add to this section if you have a validator/checker, no matter which or how many microformats you test for.

=== rel-lint ===
* [http://tools.microformatic.com/help/xhtml/rel-lint/ rel-lint] supports validation of [[rel-tag|rel-tag]] and [[xfn|XFN]]
* by [[implementors#Drew_McLellan|Drew McLellan]]

== Companies / Developers / Organizations ==

See [[implementors]]

The following have been moved from the sections above due to problems, stated below:

=== Web Essentials ===
* [http://we05.com/ Web Essentials] - supports [[hcard|hCard]] and [[hcalendar|hCalendar]], e.g. in their [http://we05.com/presenters.cfm list of presenters] and [http://we05.com/program.cfm program schedule].
** John McKerrell tried to look at the site on 24th October 2006 but could not access the site, server didn't seem to be up.

== Other ==
Some notes on initial thoughts around [[implementation-guidelines|Guidelines and Strategies for Implementing Microformats]]

vcard-suggestions

2008-01-09T00:35:33Z

Gazza: /* 3.3.2 EMAIL Type Definition */ Typo

<h1> vCard suggestions </h1>

As a result of experience using [[hcard|hCard]] to markup people, organizations, and contact information in general on [[hcard-examples-in-wild|real world websites]], we have discovered a few aspects of {{RFC2426}} vCard that could be improved. Thus we are documenting suggestions for improving vCard here as we find them, organized by {{RFC2426}} section number for improvements to current properties, and a "new" section for new properties.

; Authors
:[[User:Tantek|Tantek Çelik]]
:[[User:AndyMabbett|Andy Mabbett]]

;Shortcut
:This page may be referenced as '''<nowiki>http://microformats.org/wiki/vs</nowiki>'''

== Suggestions for Existing Properties ==

Suggestions for improvement could include new features and other such more major changes to the specification, organized under headings that reflect RFC 2426 vCard section numbers and heading. For documentation of errors, corrections, errata for vCard, please see [[vcard-errata]].

=== 3.3.1 TEL Type Definition ===

* The "type" for "TEL" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. It may be good to consider adding a "textphone" value to the "type" for "TEL".
** +0 Tantek: I think a rethinking of the taxonomy of TEL types is merited, but I am uncertain whether it is worth growing the existing limited taxonomy or instead permitting user defined TEL types and thus allowing for natural evolution of a folksonomy of TEL types.
** +1 [[User:AndyMabbett|Andy Mabbett]]: There are a limited number of types. Note also the cell vs. mobile issue.
* The "type" for "TEL" lacks a "freephone" option. It may be good to consider adding a "freephone" value to the "type" for "TEL". Usually freephone numbers are not accessible from outside the country so it could help parsers with something?
* The "type" for "TEL" lacks an "SMS short code" option. (Raised in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011292.html e-mail, 2008-01-08 by Michael Smethurst])
** Seems like 'sms' TEL TYPE is a viable implementation option --[[User:Guillaume Lebleu|Guillaume]] 12:17, 8 Jan 2008 (PST).
* FYI. Some existing Personal Information Manager software practices:
** Mac OS X address book allows custom labels for TEL but not custom TEL TYPE per se, although for the user a custom TEL label just looks like a TEL TYPE
** Microsoft Outlook does not allow custom TEL TYPE values. Also, Microsoft Outlook has a "Company" telephone type, but unfortunately it isn't mapped to anything in vCard i.e. if you export a contact with a company tel, it is lost.
** Windows Mobile 6 displays SMS as a service that is only available if the telephone type is 'mobile'.
** Thunderbird 2 (Mac) does not allow custom TEL TYPE values.

Note: it might be a good idea to look at the [http://tools.ietf.org/html/draft-ietf-iptel-tel-reg-04 proposed registry for "tel:" URI parameters]; especially the [http://tools.ietf.org/html/rfc3966 "phone-context" URI parameter], since it tries to solve a similar problem. (per [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011295.html e-mail, 2008-01-08]).

=== 3.3.2 EMAIL Type Definition ===

* The "type" for "EMAIL" lacks distinction for various types of email, e.g. '''work''' or '''home'''.
* The "type" for "EMAIL" lacks distinction for give an alternative to the e-mail like a contact form.

=== 3.3.3 Suggestion for Types Definition ===

We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is :
<nowiki><div class="tel">
Travail :
0321596224
</div></nowiki>

How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better :
<nowiki>Travail : 0321596224</nowiki>

Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !

== Suggestions for New Properties ==
===Gender===
*There is no Card property for gender. A workaround: add the tag/category "male", "female", etc. See also [[hcard-faq#How_is_gender_represented|earlier discussion]] and [[genealogy-brainstorming#Gender]].
** -1 Tantek: I think tags/categories are good enough for now.
** +1 [[User:AndyMabbett|Andy Mabbett]]:Tags are often not appropriate, as per the cited discussion.

====Gender evidence====
See [[gender-examples]].

* Social network sites (see [[profile-examples]]) typically publish the gender of the individual. Please add such sites with specific URLs to the site, their editing UI, and their list of gender values to [[gender-examples#sites_and_services]].

* Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. Please add such pages with specific URLs and quotes of the explicit information, and the implied genders to the [[gender-examples#examples|gender examples]] page.

See also [[genealogy-brainstorming]].

===Deceased===

*See [[hcard-date-of-death]]

====Date of Death evidence====

*See [[hcard-date-of-death]]

===Instant Messaging===
*See [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].

===Subject differentiator===
*The use of "fn" and "fn org" differentiate between hCards for people and for other entities, but we perhaps need some further differentiator, between, say, organisations and venues (including buildings, governmental divisions, waypoints, etc.) at a level of granularity to be determined. [[User:AndyMabbett|Andy Mabbett]] 14:30, 11 Jul 2007 (PDT)
** This may no longer be necessary; as the [[hcard-brainstorming#Named_locations|use of "fn [child-of-adr]"]], for venues and other places, has been proposed and is being debated (see [http://microformats.org/discuss/mail/microformats-discuss/2007-December/011169.html email of 2007-12-30]. [[User:AndyMabbett|Andy Mabbett]] 14:04, 8 Jan 2008 (PST)

===Elevation===
Additional "geo" sub-property; aka "altitude"
*See [[geo-extension-elevation]]

===Vessel===
Additional "adr" sub-property; for people on, say, ships, oil rigs, and even space vehicles (e.g. the ISS)

===Body===
Additional "adr" sub-property; for people off-planet (e.g. proposed moon base, Mars expedition)
* See also [[geo-extension-nonWGS84]]

===Schema===
Additional "geo" sub-property; for coordinates using non-WGS84 schema (terrestrial and for other bodies)
* See also [[geo-extension-nonWGS84]]

===Global Location Number===
Global Location Number (GLN) - generally used in electronic commerce transactions [http://en.wikipedia.org/wiki/Global_Location_Number]. [[User:AndyMabbett|Andy Mabbett]] 06:43, 31 Aug 2007 (PDT)

===Initials===
For people, whose given-name is not stated (e.g. "A. N. Other"); to allow mark-up like:

<pre><nowiki>


A. N.
Other


</nowiki></pre>

===Alternative dates===

For historic figures, where no birth and/ or death dates are known a "'''flourished'''" date, or "'''flourished from'''"+"'''flourished to'''" pair, would be useful.

In genealogy, some people have no recorded birth date, but their "'''baptised'''" date is known.

===Continent===
<code>adr</code> should have an optional <code>continent</code> child-property.

== Suggestions for handling encodings ==
The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.

Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

==Suggestions made elsewhere==

===WebDAV===

[http://www.ietf.org/internet-drafts/draft-daboo-carddav-02.txt vCard Extensions to WebDAV (CardDAV)]
<blockquote>defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. This document defines the "addressbook-access" feature of CardDAV.</blockquote>

===XEP-0154: User Profile===

[http://www.xmpp.org/extensions/xep-0154.html XEP-0154: User Profile] specifies how to represent and manage profile data about IM users and other [http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol Extensible Messaging and Presence Protocol] (XMPP) entities using the XMPP Data Forms extension. It has a far greater number of properties than vCard (possibly more than vCard will ever need), and reinvents and re-names some of the latter's properties, but may have some attributes worth considering for vCard.

==Note==
On 2006-11-24, Paul Hoffman of the [http://www.imc.org/ Internet Mail Consortium], responsible for the development and promotion the vCard standard, wrote in response to an e-mail from [[User:AndyMabbett|Andy Mabbett]] informing him of this web page:
<blockquote>There has been almost no interest in revising the vCard standard. This is due to lack of momentum, not the lack of good suggestions.</blockquote>

However, see [[events/2007-09-18-calconnect-vcard-workshop]] for an event with vCard modification on the agenda.

== See Also ==

* [[vcard-errata|vCard errata]]
* [[vcard-implementations]]
* [[hcard|hCard]]
* [[hcard-brainstorming#Post_vCard_additions]]
* [http://www.imc.org/imc-vcard/ vCard mailing list] - a place to raise these issues, and where similar issues can be found.
* [[events/2007-09-18-calconnect-vcard-workshop]]

anti-patterns

2008-01-08T03:33:23Z

Gazza: /* empty hyperlinks */ Google is a proper noun in this context

<h1>anti-patterns</h1>
{{TOC-right}}
This is an index page for pointing to various known anti-patterns, in particular those that have been encountered by the microformats community during the development of [[POSH]] patterns or microformats within

New anti-patterns may be documented here at first and then moved to their own page(s).

== known anti-patterns ==
* [[presentational-html]]
* [[namespaces]]
* [[social-network-anti-patterns]]

== recent anti-patterns ==
These anti-patterns have been recently noted:

=== removing data from its context ===

HTML4 contains numerous mechanisms for storing machine data in a document in the <nowiki><head></nowiki> such as a list of <nowiki><link> or <meta></nowiki> elements.

This is an anti-pattern.

Disconnecting data (or meta-data, whatever you prefer to call it) from its context inevitably leads to corruption, and loss of fidelity. Meta keywords rotted for example. One person writes the template with the head and link and meta, and another puts the content in the page, etc.

Removing data from its context is an anti-pattern.

=== empty hyperlinks ===

More than once it has been proposed to use empty hyperlinks to store machine readable information at least ''near'' the context of the related human readable information.

Empty hyperlinks are still problematic for several reasons however:

<blockquote>
any SEO worth his salt will know anchor text links that go nowhere, will
* A, reduce the quality of out going links from your site so reducing PR (Page Rank) and
* B, more than likely get you banned from Google because it will think you are trying to spam it...
</blockquote>

=== invisible metadata ===
In the early days of HTML, authors used to place keywords for their pages in an invisible <code><nowiki><meta></nowiki></code> tag and search engines used this information, because the specifications said to do so. However, before long, in the realm of the Wild Wild Web, these meta keywords fell out of sync with the content on pages, were polluted, spammed, and otherwise abused until there was so much noise, any semblance of signal was lost. The invisible metadata of meta keywords, which, lacking any positive feedback loop, through the combination of gaming incentives and natural entropy, historically has deteriorated into useless noise.

This is in stark contrast to visible data, even semi-visible data like hyperlink destinations, or title attributes commonly displayed as tool-tips. This is part of the basis for the microformats [[principle]] of humans first, machines second.

Excerpted/rephrased from: <cite>[http://tantek.com/log/2005/06.html#d03t2359 Principles of visibility and human friendliness].</cite>

==== data in class attributes ====
Storing data in class attributes has been proposed a number of times. Unfortunately storing data in a class attribute is simply another form of invisible metadata and thus an anti-pattern that should be discouraged.

==See also==
*[[anti-design-patterns]]
*[[social-network-anti-patterns]]

currency-brainstorming

2008-01-08T02:48:56Z

Gazza: /* Issues */ Contribution

== Brainstorming ==

Brainstorming for the proposed [[currency]] microformat.

===Ben Buchanan===
Verbose but extensible and explicitly defines all values (without breaking DRY):

<pre><div class="currency">

code
symbol
12345

</div></pre>
"figure" is there to both explicitly associate the code, sign and amount but also allow the potential for more than one currency figure to be placed within the container. It does anticipate further development though and is the most easily dropped item at the early stage.

Without figure:
<pre><div class="currency">
code
symbol
12345
</div></pre>

Super shortened, relying on the parser to identify everything via implied order/structure:

<pre><div class="currency">ABC12345$</div></pre>

Although the simplest solution, it has a notable vulnerability: some currencies have/had three-letter abbreviations for their currency sign, instead of a symbol. This would make it very difficult for a parser to accurately identify such a currency.
In addition, it should be noted that the order alone cannot be used to identify which parts are code, sign and amount; since many currencies are denoted with the sign after the number.

Super shortened, but specifying a currency code as a class:

<pre><div class="currency ABC">12345$</div></pre>

It defines...

<ol type="a">
<li>we're talking about money - ISO standard implied,</li>
<li>we're talking about the USD variety,</li>
<li>we're talking fifty units of that money,</li>
<li>a parser could work out the numbers and the symbol.</li>
</ol>

The biggest limitation I can see for that shorthand is that the currency code is not displayed visibly to human readers. The currency code is useful information to viewers and ideally should be displayed.

Shortened (including dropping 'figure', but explicitly defining and displaying the currency code. This would allow a parser to treat any remaining numbers as the amount; and any remaining a-z or symbol as the sign:

<pre><div class="currency">
ABC12345$
</div></pre>

===Charles Iliya Krempeaux===
Maybe something like...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

Although something like the the following might be better...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though.

=== Ben Ward ===
Could pure HTML be sufficient?
<pre><html lang="en-gb">
My new T-Shirts cost £30, but it cost my friend in Canada $34
</html></pre>

===Arve Bersvendsen ===
<pre>Den kanadiske prisen på t-skjorten var 34 $.</pre>

=== Mike Stickel ===
<pre><abbr class="currency" title="CAD eng">$</abbr>5.00</pre>
In this format the wrapping would be "money" or something similar followed by either the actual "amount" or the "currency", depending on what rules your country/language follows in regards to the order.
Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the "currency" definition of the formating, eg., "CAD eng" or "CAD fr".
It could also give sites that list multiple languages a way to differentiate when they show multiple prices.

:Good idea, but shouldn't a Microformat use existing markup for language attributes, eg.

:<pre><abbr class="currency" title="CAD" lang="en">$</abbr>5.00</pre>

:Reference [http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1 w3.org: 8.1 Specifying the language of content: the lang attribute]
:[[User:Bob Jonkman|Bob Jonkman]] 22:26, 12 Oct 2006 (PDT)

=== Ciaran McNulty ===
The only microformat that I've noticed currency units in is [[hlisting-proposal|hListing]], and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats.

My own preference would be for something like:
<pre>This item costs
GBP
10.00
</pre>

Which with similar parsing rules to existing formats would also allow things like:
<pre>
It'll cost you
<abbr class="currency" title="50.00">fifty</abbr>
<abbr class="amount" title="GBP">quid</abbr>
, mate!
</pre>
Or, a more complex example with multiple languages:
<pre>
Price:

<abbr class="currency" title="GBP">£</abbr>
1,250.00


(Prix:
1600,00
<abbr class="currency" title="EUR">€</abbr>
)

</pre>

===Andy Mabbett===

====Straw man proposal====

'''Superseded; see [[#Straw_man]], below.'''

(this reflects Ciaran McNulty's proposals, above)

In order to use currency as a sub-class, the parent should be named 'money'

*money - class (required) '''[or "currency"?]'''
**currency - class (required; uses ISO 4217) '''[or "type"?]'''
**amount - class (required) '''[or "value"?]'''
**date - class (optional - for historic values only, in [[datetime-design-pattern]]. Consider inflation in Germany in 1930s!)
**symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent; it will also help user agents to ignore $ and other such symbols, when used for purposes other than to indicate a currency, or to remove them, when translating to a different currency.)
**unit - class (subdivison of currency; use as "symbol")
**<s>equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)</s>

All classes may occur only once, apart from ''symbol'' (to allow for "£14 6s 2d") and ''unit'' (to allow for "five pounds 23 pence").

=====Examples=====
Thus:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>
(note, in the above, that "unit" does not relate directly to the amount in the amount's title abttibute - it's 0.5 pounds, not 0.5 pence.)

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

(The above might be rendered as "... 1/ (worth £4.50 in modern terms" (or whatever the value would be).)

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

The following, simplified for clarity, from [http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

Is there anything sensible which ''can't'' be done with the above?

=====Assumptions=====

*Working out values in secondary currencies is a (real-time or daily) job for server-side scripting or user agents.

*If "£" is an abbreviation, then its title is "pounds sterling"; though note that "£5" is pronounced as "five pounds sterling" (commonly just "five pounds") and not: "pounds sterling five" in the same way that "$5" is pronounced as: "five dollars" and not "dollars five"

=====Issues=====

*There will be complications where the entire currency has disappeared, (such as the last example; French Francs into Euros).

* Where no symbol or unit is involved (chiefly in tables, where they will be in the header cell), should we allow:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money USD amount">42.67</td>
</tr>
</nowiki></pre>

====HTML Entities====

*The following currency entities exist:
**<code>¤</code> - <code>& curren;</code> - currency
**<code>¢</code> - <code>& cent;</code> - cent
**<code>£</code> - <code>& pound;</code> - pound
**<code>¥</code> - <code>& yen;</code> - yen
**<code>€</code> - <code>& euro;</code> - Euro

===Guillaume Lebleu ===

In the context of a hListing's price, without a unit:

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Rendered view:

<abbr class="currency" title="EUR">€</abbr>100

In the context of a hListing's price, with a unit:

<pre>
<abbr class="currency" title="USD">$</abbv>25 per
barrel
</pre>

<pre>
25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>
</pre>

Note: the class "amount" may not always be required, but it is useful when the amount is represented as text, or when the amount is mixed within text. See historical example below.

Rendered view:

<abbr class="currency" title="USD">$</abbr>25 per
barrel

25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>

Outside of the context of a hListing (not all currency amounts are prices, for instance sales numbers):

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Historical price (here currency rate):

<pre>
On <abbr class="datetime"
title="1998-03-12T08:30:00-05:00">August 1</abbr>, the US Dollar still
stood at 643 <abbr class="currency"
title="DEM">Marks</abbr> to the Dollar.
</pre>

In a table:

<pre>
<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>
</pre>

Rendered view:

<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>

=== Gary Jones ===

<pre><nowiki>

<abbr class="type" title="CAD">$</abbr>
5.00

</nowiki></pre>

Renders as:

<abbr class="type" title="CAD">$</abbr>5.00

If the formatting of a currency is such that the type symbol comes after the value, then simply swap the order of the elements containing the type and value classes.

I do think that the use of "type" and "value" classes would be better than variations of "currency_symbol" and "amount". It follows the same principles as some other elemental formats ([http://microformats.org/wiki/hcard#Value_excerpting value excerpting]), meaning it's [http://microformats.org/wiki/naming-principles#Minimal_Vocabulary easier to remember] and implement, and even ISO4217 has codes for "currencies" that don't use symbols:

<pre><nowiki>

23 ounces of
<abbr class="type" title="XAG">gold</abbr>

</nowiki></pre>

Renders as:

23 ounces of <abbr class="type" title="XAG">gold</abbr>

Following on from this, the use of a "money" class should not be used; currency does not ''have'' to be money, and having a "metal" class starts to make it convoluted. Currency is the parent of money, not the other way around.

===Mike Schinkel===
I'm taking Andy Mabbett's post and applying my thoughts to his.

Rather than:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

Why not just:

<pre><nowiki>
A widget costs $12.57
</nowiki></pre>

In the above, a number is assumed because their is not an "amount", and the number digit is the currency symbol. I guess what I'm saying is if there is a number in the HTML and it is the correct number (which I think will be the 80 percentile case, give or take, then why require additional markup for it?)

Rather than:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

Just:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="currency" title="USD">42.67</td>
</tr>
</nowiki></pre>

Or:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td>
42.67
</td>
</tr>
</nowiki></pre>

In this case, which is a little more complicated:

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

Why not use the following:

<pre><nowiki>
Can you spare

<abbr class="amount" title="10">ten</abbr>
dollars
?
</nowiki></pre>

Here:

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>

Why not?

<pre><nowiki>
It was worth

<abbr class="amount" title="0.5">50</abbr>
pence
?
</nowiki></pre>

I'm not going to try to mark up the following two since, thus far, [http://www.vizu.com/poll-vote.html?n=15067 no one has voted for dated money amounts or non-numerical representations] (those might be better expressed in their own microformat: ''hHistoricalCurrency''?):

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

I don't understand what this is trying to accomplish (it seems incomplete), so I can't mark it up.

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

Again, I'm not going to try to mark up given [http://www.vizu.com/poll-vote.html?n=15067 the lack of interest in dated money amounts]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

My efforts attempt to minimize the disruption in the HTML file and only use additional markup when absolutely required. I believe some high volume websites still try to minimize the markup they serve, and this is bloated as it it. They may decide just to serve up a few digits rather than 50 character per price, especially on pages with lots of prices.

*The claimed "lack of interest" in dated amounts ignores the [[currency-examples|evidence that such figures are widely published on the web]]. Most of your preceding "why not"s ignore the [[abbr-design-pattern]]. [[User:AndyMabbett|Andy Mabbett]] 07:30, 2 Jan 2007 (PST)

===Taylor Cowan===

Pretending to forget all that we've know up till now about microformats, what if we just wanted a way for web page designers to make their currency amounts unambiguous with respect to currency denomination and amount?

"one hundred bucks"

<pre><abbr class="currency" title="USD100">one hundred bucks</abbr></pre>

$100 (CAD)

<pre><abbr class="currency" title="CAD100">$100</abbr></pre>

10 cents

<pre><abbr class="currency" title="USD0.10">ten cents</abbr></pre>

compare:

<pre>10 <abbr class="unit" title="cent"><abbr
class="currency" title="USD">cents</abbr></abbr></pre>

man Yen

<pre><abbr class="currency" title="JPY10,000">man Yen</abbr></pre>

So within the title, we've got ISO###.##

Then later on we wanted to apply one of those amounts to the "price" of an hListing:

<pre><abbr class="currency price" title="USD100">one hundred bucks</abbr></pre>

==Straw man==

Based on Taylor Cowan's suggestion, above, and on [http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html subsequent mailing list discussion], the following "money" microformat straw man is proposed:

<pre><nowiki>

[value]


<abbr class="hmoney" title="[value]">
[text]
</abbr>
</nowiki></pre>

Where "value" is a number+ISO-code pair ("GBP5", "4 USD") using ISO curency codes and where parsers must accept the formats:

*[currency-code][number]
*[currency-code][space][number]
*[number][currency-code]
*[number]space[currency-code]

and where dated money amounts are included in an hCalendar:

<pre><nowiki>
<div class="vevent">


The last Monet painting to be auctioned

fetched
<abbr class="currency" title="USD95M">$95 million</abbr>
in
2005

</div>
</nowiki></pre>

Further comment is invited. A test page is available, at http://www.westmidlandbirdclub.com/test/money.htm

===Notes===
This works for sub-divisions of currencies:

<pre><nowiki>
<abbr class="hmoney" title="USD 0.05">
5c
</abbr>
</nowiki></pre>

and for archaic and non-decimal currencies:

<pre><nowiki>
<abbr class="currency title="GBP 0.125">
two shillings and sixpence
</abbr>

<abbr class="currency title="GBP1.05">One guinea</abbr>
</nowiki></pre>

===Issues===
*Is hmoney the appropriate class-name?
*Is money a separate microformat, or a [[measure]]ment, with the ISO currency code as the unit-code?
** Currency != money; Currency is a superset / parent of money. If we're using ISO codes, then we should be focusing on the currency (not money) it applies to. [[User:Gazza|Gazza]] 18:48, 7 Jan 2008 (PST)
*This is still susceptible to the [[accessibility-issues#abbr-design-pattern]].
*Using amount suffixes such as K, M, B, or T are not necessarily supported by any International Standard. Shouldn't we just say that the complete number should be used in the <nowiki><abbr></nowiki> element? [[User:ManuSporny|ManuSporny]] 12:31, 5 Oct 2007 (PDT)

===Suggested amendments===
*Use just the abbr pattern and format [number]space[currency-code]. We should narrow our focus to make progress. Simplify, simplify, simplify! [[User:ManuSporny|ManuSporny]] 07:16, 5 Oct 2007 (PDT)
**Is this approach too inflexible?
** "5 GBP" is not an abbreviation of "5 GBP". [[User:AndyMabbett|Andy Mabbett]] 09:46, 5 Oct 2007 (PDT)
*** This problem is easily fixed by using <pre>5 GBP</pre> [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)
** People publish amounts as, say, "5GBP" (with no space) in the wild. [[User:AndyMabbett|Andy Mabbett]] 09:49, 5 Oct 2007 (PDT)
*** Yes, they do, however we can still mark that up as <pre><abbr class="hcurrency" title="5 GBP">5GBP</abbr></pre>. You could argue that "5 GBP" is not an abbreviation of "5GBP", which is true - but I believe this is an acceptable compromise, afterall... we would be arguing over a single space character, which seems a bit pedantic. [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)

==References==
* [http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html The official list of ISO-4217 alphabetic and numeric codes]
* [http://en.wikipedia.org/wiki/ISO_4217 Wikipedia: ISO 4217]
*[http://en.wikipedia.org/wiki/List_of_circulating_currencies Wikipedia: List of circulating currencies]

==Related pages==
{{currency-related-pages}}

currency-brainstorming

2008-01-08T02:45:30Z

Gazza: /* Issues */ Contribution

== Brainstorming ==

Brainstorming for the proposed [[currency]] microformat.

===Ben Buchanan===
Verbose but extensible and explicitly defines all values (without breaking DRY):

<pre><div class="currency">

code
symbol
12345

</div></pre>
"figure" is there to both explicitly associate the code, sign and amount but also allow the potential for more than one currency figure to be placed within the container. It does anticipate further development though and is the most easily dropped item at the early stage.

Without figure:
<pre><div class="currency">
code
symbol
12345
</div></pre>

Super shortened, relying on the parser to identify everything via implied order/structure:

<pre><div class="currency">ABC12345$</div></pre>

Although the simplest solution, it has a notable vulnerability: some currencies have/had three-letter abbreviations for their currency sign, instead of a symbol. This would make it very difficult for a parser to accurately identify such a currency.
In addition, it should be noted that the order alone cannot be used to identify which parts are code, sign and amount; since many currencies are denoted with the sign after the number.

Super shortened, but specifying a currency code as a class:

<pre><div class="currency ABC">12345$</div></pre>

It defines...

<ol type="a">
<li>we're talking about money - ISO standard implied,</li>
<li>we're talking about the USD variety,</li>
<li>we're talking fifty units of that money,</li>
<li>a parser could work out the numbers and the symbol.</li>
</ol>

The biggest limitation I can see for that shorthand is that the currency code is not displayed visibly to human readers. The currency code is useful information to viewers and ideally should be displayed.

Shortened (including dropping 'figure', but explicitly defining and displaying the currency code. This would allow a parser to treat any remaining numbers as the amount; and any remaining a-z or symbol as the sign:

<pre><div class="currency">
ABC12345$
</div></pre>

===Charles Iliya Krempeaux===
Maybe something like...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

Although something like the the following might be better...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though.

=== Ben Ward ===
Could pure HTML be sufficient?
<pre><html lang="en-gb">
My new T-Shirts cost £30, but it cost my friend in Canada $34
</html></pre>

===Arve Bersvendsen ===
<pre>Den kanadiske prisen på t-skjorten var 34 $.</pre>

=== Mike Stickel ===
<pre><abbr class="currency" title="CAD eng">$</abbr>5.00</pre>
In this format the wrapping would be "money" or something similar followed by either the actual "amount" or the "currency", depending on what rules your country/language follows in regards to the order.
Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the "currency" definition of the formating, eg., "CAD eng" or "CAD fr".
It could also give sites that list multiple languages a way to differentiate when they show multiple prices.

:Good idea, but shouldn't a Microformat use existing markup for language attributes, eg.

:<pre><abbr class="currency" title="CAD" lang="en">$</abbr>5.00</pre>

:Reference [http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1 w3.org: 8.1 Specifying the language of content: the lang attribute]
:[[User:Bob Jonkman|Bob Jonkman]] 22:26, 12 Oct 2006 (PDT)

=== Ciaran McNulty ===
The only microformat that I've noticed currency units in is [[hlisting-proposal|hListing]], and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats.

My own preference would be for something like:
<pre>This item costs
GBP
10.00
</pre>

Which with similar parsing rules to existing formats would also allow things like:
<pre>
It'll cost you
<abbr class="currency" title="50.00">fifty</abbr>
<abbr class="amount" title="GBP">quid</abbr>
, mate!
</pre>
Or, a more complex example with multiple languages:
<pre>
Price:

<abbr class="currency" title="GBP">£</abbr>
1,250.00


(Prix:
1600,00
<abbr class="currency" title="EUR">€</abbr>
)

</pre>

===Andy Mabbett===

====Straw man proposal====

'''Superseded; see [[#Straw_man]], below.'''

(this reflects Ciaran McNulty's proposals, above)

In order to use currency as a sub-class, the parent should be named 'money'

*money - class (required) '''[or "currency"?]'''
**currency - class (required; uses ISO 4217) '''[or "type"?]'''
**amount - class (required) '''[or "value"?]'''
**date - class (optional - for historic values only, in [[datetime-design-pattern]]. Consider inflation in Germany in 1930s!)
**symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent; it will also help user agents to ignore $ and other such symbols, when used for purposes other than to indicate a currency, or to remove them, when translating to a different currency.)
**unit - class (subdivison of currency; use as "symbol")
**<s>equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)</s>

All classes may occur only once, apart from ''symbol'' (to allow for "£14 6s 2d") and ''unit'' (to allow for "five pounds 23 pence").

=====Examples=====
Thus:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>
(note, in the above, that "unit" does not relate directly to the amount in the amount's title abttibute - it's 0.5 pounds, not 0.5 pence.)

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

(The above might be rendered as "... 1/ (worth £4.50 in modern terms" (or whatever the value would be).)

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

The following, simplified for clarity, from [http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

Is there anything sensible which ''can't'' be done with the above?

=====Assumptions=====

*Working out values in secondary currencies is a (real-time or daily) job for server-side scripting or user agents.

*If "£" is an abbreviation, then its title is "pounds sterling"; though note that "£5" is pronounced as "five pounds sterling" (commonly just "five pounds") and not: "pounds sterling five" in the same way that "$5" is pronounced as: "five dollars" and not "dollars five"

=====Issues=====

*There will be complications where the entire currency has disappeared, (such as the last example; French Francs into Euros).

* Where no symbol or unit is involved (chiefly in tables, where they will be in the header cell), should we allow:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money USD amount">42.67</td>
</tr>
</nowiki></pre>

====HTML Entities====

*The following currency entities exist:
**<code>¤</code> - <code>& curren;</code> - currency
**<code>¢</code> - <code>& cent;</code> - cent
**<code>£</code> - <code>& pound;</code> - pound
**<code>¥</code> - <code>& yen;</code> - yen
**<code>€</code> - <code>& euro;</code> - Euro

===Guillaume Lebleu ===

In the context of a hListing's price, without a unit:

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Rendered view:

<abbr class="currency" title="EUR">€</abbr>100

In the context of a hListing's price, with a unit:

<pre>
<abbr class="currency" title="USD">$</abbv>25 per
barrel
</pre>

<pre>
25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>
</pre>

Note: the class "amount" may not always be required, but it is useful when the amount is represented as text, or when the amount is mixed within text. See historical example below.

Rendered view:

<abbr class="currency" title="USD">$</abbr>25 per
barrel

25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>

Outside of the context of a hListing (not all currency amounts are prices, for instance sales numbers):

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Historical price (here currency rate):

<pre>
On <abbr class="datetime"
title="1998-03-12T08:30:00-05:00">August 1</abbr>, the US Dollar still
stood at 643 <abbr class="currency"
title="DEM">Marks</abbr> to the Dollar.
</pre>

In a table:

<pre>
<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>
</pre>

Rendered view:

<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>

=== Gary Jones ===

<pre><nowiki>

<abbr class="type" title="CAD">$</abbr>
5.00

</nowiki></pre>

Renders as:

<abbr class="type" title="CAD">$</abbr>5.00

If the formatting of a currency is such that the type symbol comes after the value, then simply swap the order of the elements containing the type and value classes.

I do think that the use of "type" and "value" classes would be better than variations of "currency_symbol" and "amount". It follows the same principles as some other elemental formats ([http://microformats.org/wiki/hcard#Value_excerpting value excerpting]), meaning it's [http://microformats.org/wiki/naming-principles#Minimal_Vocabulary easier to remember] and implement, and even ISO4217 has codes for "currencies" that don't use symbols:

<pre><nowiki>

23 ounces of
<abbr class="type" title="XAG">gold</abbr>

</nowiki></pre>

Renders as:

23 ounces of <abbr class="type" title="XAG">gold</abbr>

Following on from this, the use of a "money" class should not be used; currency does not ''have'' to be money, and having a "metal" class starts to make it convoluted. Currency is the parent of money, not the other way around.

===Mike Schinkel===
I'm taking Andy Mabbett's post and applying my thoughts to his.

Rather than:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

Why not just:

<pre><nowiki>
A widget costs $12.57
</nowiki></pre>

In the above, a number is assumed because their is not an "amount", and the number digit is the currency symbol. I guess what I'm saying is if there is a number in the HTML and it is the correct number (which I think will be the 80 percentile case, give or take, then why require additional markup for it?)

Rather than:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

Just:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="currency" title="USD">42.67</td>
</tr>
</nowiki></pre>

Or:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td>
42.67
</td>
</tr>
</nowiki></pre>

In this case, which is a little more complicated:

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

Why not use the following:

<pre><nowiki>
Can you spare

<abbr class="amount" title="10">ten</abbr>
dollars
?
</nowiki></pre>

Here:

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>

Why not?

<pre><nowiki>
It was worth

<abbr class="amount" title="0.5">50</abbr>
pence
?
</nowiki></pre>

I'm not going to try to mark up the following two since, thus far, [http://www.vizu.com/poll-vote.html?n=15067 no one has voted for dated money amounts or non-numerical representations] (those might be better expressed in their own microformat: ''hHistoricalCurrency''?):

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

I don't understand what this is trying to accomplish (it seems incomplete), so I can't mark it up.

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

Again, I'm not going to try to mark up given [http://www.vizu.com/poll-vote.html?n=15067 the lack of interest in dated money amounts]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

My efforts attempt to minimize the disruption in the HTML file and only use additional markup when absolutely required. I believe some high volume websites still try to minimize the markup they serve, and this is bloated as it it. They may decide just to serve up a few digits rather than 50 character per price, especially on pages with lots of prices.

*The claimed "lack of interest" in dated amounts ignores the [[currency-examples|evidence that such figures are widely published on the web]]. Most of your preceding "why not"s ignore the [[abbr-design-pattern]]. [[User:AndyMabbett|Andy Mabbett]] 07:30, 2 Jan 2007 (PST)

===Taylor Cowan===

Pretending to forget all that we've know up till now about microformats, what if we just wanted a way for web page designers to make their currency amounts unambiguous with respect to currency denomination and amount?

"one hundred bucks"

<pre><abbr class="currency" title="USD100">one hundred bucks</abbr></pre>

$100 (CAD)

<pre><abbr class="currency" title="CAD100">$100</abbr></pre>

10 cents

<pre><abbr class="currency" title="USD0.10">ten cents</abbr></pre>

compare:

<pre>10 <abbr class="unit" title="cent"><abbr
class="currency" title="USD">cents</abbr></abbr></pre>

man Yen

<pre><abbr class="currency" title="JPY10,000">man Yen</abbr></pre>

So within the title, we've got ISO###.##

Then later on we wanted to apply one of those amounts to the "price" of an hListing:

<pre><abbr class="currency price" title="USD100">one hundred bucks</abbr></pre>

==Straw man==

Based on Taylor Cowan's suggestion, above, and on [http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html subsequent mailing list discussion], the following "money" microformat straw man is proposed:

<pre><nowiki>

[value]


<abbr class="hmoney" title="[value]">
[text]
</abbr>
</nowiki></pre>

Where "value" is a number+ISO-code pair ("GBP5", "4 USD") using ISO curency codes and where parsers must accept the formats:

*[currency-code][number]
*[currency-code][space][number]
*[number][currency-code]
*[number]space[currency-code]

and where dated money amounts are included in an hCalendar:

<pre><nowiki>
<div class="vevent">


The last Monet painting to be auctioned

fetched
<abbr class="currency" title="USD95M">$95 million</abbr>
in
2005

</div>
</nowiki></pre>

Further comment is invited. A test page is available, at http://www.westmidlandbirdclub.com/test/money.htm

===Notes===
This works for sub-divisions of currencies:

<pre><nowiki>
<abbr class="hmoney" title="USD 0.05">
5c
</abbr>
</nowiki></pre>

and for archaic and non-decimal currencies:

<pre><nowiki>
<abbr class="currency title="GBP 0.125">
two shillings and sixpence
</abbr>

<abbr class="currency title="GBP1.05">One guinea</abbr>
</nowiki></pre>

===Issues===
*Is hmoney the appropriate class-name?
*Is money a separate microformat, or a [[measure]]ment, with the ISO currency code as the unit-code?
** Currency != money; Currency is a superset / parent of money. If we're using ISO codes, then we should be focusing on the currency (not money) it applies to. [[User:Gazza|Gazza]] 18:45, 7 Jan 2008 (PST)
*This is still susceptible to the [[accessibility-issues#abbr-design-pattern]].
*Using amount suffixes such as K, M, B, or T are not necessarily supported by any International Standard. Shouldn't we just say that the complete number should be used in the <nowiki><abbr></nowiki> element? [[User:ManuSporny|ManuSporny]] 12:31, 5 Oct 2007 (PDT)

===Suggested amendments===
*Use just the abbr pattern and format [number]space[currency-code]. We should narrow our focus to make progress. Simplify, simplify, simplify! [[User:ManuSporny|ManuSporny]] 07:16, 5 Oct 2007 (PDT)
**Is this approach too inflexible?
** "5 GBP" is not an abbreviation of "5 GBP". [[User:AndyMabbett|Andy Mabbett]] 09:46, 5 Oct 2007 (PDT)
*** This problem is easily fixed by using <pre>5 GBP</pre> [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)
** People publish amounts as, say, "5GBP" (with no space) in the wild. [[User:AndyMabbett|Andy Mabbett]] 09:49, 5 Oct 2007 (PDT)
*** Yes, they do, however we can still mark that up as <pre><abbr class="hcurrency" title="5 GBP">5GBP</abbr></pre>. You could argue that "5 GBP" is not an abbreviation of "5GBP", which is true - but I believe this is an acceptable compromise, afterall... we would be arguing over a single space character, which seems a bit pedantic. [[User:ManuSporny|ManuSporny]] 11:52, 5 Oct 2007 (PDT)

==References==
* [http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html The official list of ISO-4217 alphabetic and numeric codes]
* [http://en.wikipedia.org/wiki/ISO_4217 Wikipedia: ISO 4217]
*[http://en.wikipedia.org/wiki/List_of_circulating_currencies Wikipedia: List of circulating currencies]

==Related pages==
{{currency-related-pages}}

User:Gazza

2008-01-08T02:26:34Z

Gazza:

My experience with Microformats is fairly limited, and have only tried to implement them on my most recent client site [http://inga-art.co.uk Inga-Art.co.uk].

In time, I will be adding the most common ones onto my other sites.

{{cc-public-domain-release}}

--[[User:Gazza|Gazza]] 18:26, 7 Jan 2008 (PST)

hresume

2007-10-28T10:30:53Z

Gazza: /* Acknowledgements */

<h1> hResume </h1>

hResume is a microformat for publishing resumes and CVs. hResume is one of several open microformat standards suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML.

Want to get started with writing an hResume? Use the [http://hresume.weblogswork.com/hresumecreator/ hResume Creator] to create your hResume and publish it, or follow the hResume authoring tips to add hResume markup to your web page or blog.

<h2> Microformats Draft Specification </h2>

; Editor/Author: [http://theryanking.com Ryan King]
; Acknowledgments: See [http://microformats.org/wiki/hresume#Acknowledgements acknowledgments].

Microformats [http://microformats.org/wiki/hresume#Copyright copyright] and [http://microformats.org/wiki/hresume#Patents patents] statements apply.

{{rfc-2119-intro}}

__TOC__

== Status ==
Draft, version 0.1.

== Introduction ==
=== Semantic XHTML Design Principles ===
{{SemanticXHTMLDesignPrinciples}}

== Format ==
=== In General ===
The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.

=== Schema ===
The hResume schema consists of the following:

* hResume
** summary. optional. text.
** contact info. required. {{must}} use [[hcard|hCard]]; {{should}} use <code class="element"><address></code> + [[hcard|hCard]].
** experience. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** education. optional One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization
** publications. optional. One or more citations. Use cite tag.

=== Field details ===
The fields of the hResume schema represent the following:

* '''<code class="class-name">hresume</code>''':: root class name
* '''<code class="class-name">summary</code>''':: The class name <code class="class-name">summary</code> is used to mark up an overview of qualifications and objectives.
* '''contact''':: Current contact info in an [[hCard]]; {{should}} use <code class="element"><address></code> with [[hCard]] when possible.
* '''<code class="class-name">education</code>''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.
* '''<code class="class-name">experience</code>''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''<code class="class-name">skill</code>''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.
* '''<code class="class-name">affiliation</code>''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization
* '''<code class="class-name">publications</code>''':: just use <code class="element"><cite></code>. When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.

=== XMDP Profile ===
* [[hresume-profile]] (@TODO)

=== Notes ===
This section is informative.

*...

== Examples ==
=== Summary ===
An example summary:

<pre><nowiki>

I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996,
designing with pastels while others will still using tiled background images and frames...

</nowiki></pre>

=== Contact ===
<pre><nowiki>
<address class="vcard">
Pedro Sanchez

123 Fake St.
Preston, Idaho 83263

Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a>
Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a>
Phone: +01.208.555.4567
</address>
</nowiki></pre>

=== Education ===
<pre><nowiki>
<ol class="vcalendar">
<li class="education vevent">
<a class="url summary" href="http://example.edu/">Preston High School</a>
(<abbr class="dtstart" title="2001-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
</li>
...
</nowiki></pre>

=== Experience ===
==== Basic ====
A basic experience event:

<pre><nowiki>
<ol class="vcalendar">
<li class="experience vevent">
President,
Preston High School,
<abbr class="dtstart" title="2004-09-01">May 2004</abbr> - <abbr title="2005-05-25">present</abbr>
</li>
...
</nowiki></pre>

==== Job Titles ====
To express one or more job titles/positions in the same experience event you should use one or more [[hcard|hCard]]s. hCard requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't customary to repeat your name for every job title you mark up in [[hResume|hresume]]. So, you may use an <code class="element"><object></code> and the class name '<code class="class-name">include</code>' with a reference to the <code class="class-name">fn</code> somewhere else on the page.

For example, this hCard refers to another hCard:

<pre>

<object data="#j" class="include"></object>
Preston High School
Class President

</pre>

Where "<code class="attr-value">j</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact hCard at the top of the page, e.g. (shown here as a verbose hCard for purposes of illustration that the reference may be to a subtree, not just a text node):

<pre><nowiki>
<address class="vcard">

Pedro
Sanchez

</address>
</nowiki></pre>

This method of hCard property indirection via an object element [[include-pattern|has been generalized]] to apply to any/all string/text properties in hCard.

Note: the object data attribute {{must}} be a local ID reference. External references (which would require a consuming application to load an external resource) are not supported by this method.

=== Skills ===
Some sample skills tags:
<pre><nowiki>
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a>
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.
</nowiki></pre>

=== Affiliations ===
<pre><nowiki>
National Honor Society
</nowiki></pre>

=== Publications ===
<pre><nowiki>
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
</nowiki></pre>

== Examples in the wild ==
See [[hresume-examples-in-wild]]

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse hResumes. If you have an hResume implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* [http://linkedin.com LinkedIn] generates hResume for all Public Profiles. [http://www.linkedin.com/in/steveganz LinkedIn Public Profile Example].

* [http://www.antix.co.uk Anthony Johnston] has implemented hResume (Creation and Import) in the [http://cv.antix.co.uk Antix CV Builder], an example resume using this site can be found [http://cv.antix.co.uk/ant here]
** The example resume is ''invalid''; job titles are marked with an hCard that is missing a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:23, 1 May 2007 (PDT)

* The [http://spurinc.com Spur] team has created an hResume WordPress plugin located at [http://hresume.weblogswork.com/?page_id=3 hResume Plugin]. See an example of the hResume markup [http://hresume.weblogswork.com/?page_id=6 here]. Neat feature of the hResume plugin is that it automatically creates a new page for the resume - no cutting and pasting...

* The [http://www.ssdesigninteractive.com/ssdesign Sajid Saiyed] has created an hResume WordPress plugin located at [http://www.ssdesigninteractive.com/ssdesign/?p=96 Microformat Resume Plugin]. See an example of the hResume markup [http://www.ssdesigninteractive.com/ssdesign/?page_id=95 here].

* Spur also created a standalone hResume Creator located at [http://hresume.weblogswork.com/hresumecreator/ hResume Creator]. The creator will generate hResume markup ready to cut and paste into your webpage.

== Copyright ==
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
* [[RyanKing]]: I release all of my contributions to the public domain.

Per the above, and the public domain release on the author, [[User:RyanKing|RyanKing]]'s, user page this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[include-pattern|include pattern]]
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag| Rel-Tag]]
* [[rfc-2119]]
* @TODO

=== Informative References ===
* @TODO

== Acknowledgements ==
=== Concept ===
* [http://theryanking.com/ Ryan King] ([http://technorati.com Technorati])
* [http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati])
* James Levine ([http://simplyhired.com Simply Hired])
* [http://epeus.blogspot.com/ Kevin Marks] ([http://technorati.com Technorati])

== Related Pages ==
{{hresume-related-pages}}

== Further Reading ==
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

hresume-examples-in-wild

2007-10-28T10:23:36Z

Gazza: CV for Inga Scholes has been removed

<h1>hResume examples in the wild</h1>

This page is '''informative'''.

The following sites have published '''hResumes''', and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing, etc.

__TOC__

== New Examples ==
If you have an hResume on your own page, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hresume|hResume]] markup. Examples added without a URL to a page with hResume markup may be removed.
* [[User:ChristopheDucamp|Christophe Ducamp]] has marked up his [http://www.elanceur.org/CV_ChristopheDucampFr.html C.V.] with hResume
* [[User:RichardDavies|Richard Davies]] has marked up his [http://www.richarddavies.us/resume/ resume] as an hResume.
* [[User:JeffMcNeill|jeffmcneill]] has marked up [http://jeffmcneill.com/microformats/hresume-jeffmcneill.html his resume] with hResume
* Actor [[User:DavidSwain|David Swain]] has marked up his [http://davidswain.co.uk/cv cv] as an hResume.
* [[User:CiaranMc|Ciaran McNulty]] has marked up his [http://ciaranmcnulty.com/assets/files/Ciaran_McNulty_CV.html resume] as an hResume.
* [[User:RobCrowther|Rob Crowther]] has marked up his [http://www.dotrob.com/cv.html resume] as an hResume.
* [[User:Ajaswa|Andrew Jaswa]] has marked up his [http://www.gotkicked.net/hresume resume] as an hResume.
* [[User:ScottWallick|Scott Allan Wallick]] has [http://scottwallick.com/about/resume/ his resume] as an hResume.
* Ed Lau has [http://www.edlabs.net/ his resume] marked up with hResume.
* [[User:AndySmith|Andy Smith]] has marked up [http://ymkm.com/AndySmith.html his CV] with hResume.
* [[User:BenDodson|Ben Dodson]] has marked up [http://www.bendodson.com/developer/cv/html/ his CV] with hResume.
* [[User:BruceDailey|Bruce Dailey]] has marked up his [http://www.jciti.com/cv/cv.php resume] as an hResume.
* [[User:JesseNewland|Jesse Newland]] has marked up his [http://resume.jnewland.com resume] as an hResume.
* [[User:Harriyott|Simon Harriyott]] has his [http://harriyott.com/cv.aspx curriculum vitae] as an hResume.
* [[User:BradT|Brad Touesnard]] has scraped together [http://brad.touesnard.com/documents/resume/ his resume] with the [http://brad.touesnard.com/projects/wordpress/linkedin-hresume/ LinkedIn hResume for Wordpress] plugin.
* [[User:ChadL|Chad Lindstrom]] has extended his [http://chadlindstrom.ca/resume/ resume] with hResume.
* Dawn Waswick has marked up [http://www.miniminx.com/portfolio/resume.cfm her CV] with hResume.
* [[User:Rolandinsh|Rolands Umbrovskis]] has [http://www.rolandinsh.lv/?ro=hResume marked up his CV] with hResume.
* [http://linkedin.com/ LinkedIn] has ~9 million Public Profiles marked up in hResume, e.g. [http://www.linkedin.com/in/steveganz Steve Ganz's Public Profile].
* [http://steinhardt.nyu.edu/ NYU Steinhardt] has [http://steinhardt.nyu.edu/faculty_bios/list/Faculty 240+ faculty bios marked up], e.g. [http://steinhardt.nyu.edu/faculty_bios/view/Susan_Murray]. ([[User:WizardIsHungry|Jon Williams]])
* [[User:ClintAndrewHall|Clint Hall]] has marked up his [http://www.clintandrewhall.com/resume.html resume] as an hResume.
* [[User:Csarven|Sarven Capadisli]] has marked up his [http://www.csarven.ca/cv Curriculum Vitae] as an hResume.
* [[User:Jax|Xavier Roy]] has marked his [http://xavierroy.com/resume/ resume] with hResume
* [[User:SanchTheFat|Robert O'Rourke]] has marked up his [http://robert.o-rourke.org/ CV] with hResume.
* [[User:Keri Henare|Keri Henare]] has marked up [http://www.kerihenare.com/cv/ his Curriculum Vitae] using hResume.
* [[User:Kwilson|Kenn Wilson]] has marked up [http://www.six23.net/resume/kenn-wilson.html his resume] using hResume, following [[User:Ralph Brandi|Ralph Brandi]]'s method of using object.include.
* [[User:Ralph Brandi|Ralph Brandi]] has [http://www.brandi.org/ralph/resume/ marked up his resume] with hResume, additionally using the object.include method to associate one description with three hCalendar experiences.
* [[User:Pat Ramsey|Pat Ramsey]] has his [http://www.patramsey.net/resume.html resume] marked up as an hResume.
* [[User:Wim Le Page|Wim Le Page]] has also marked up [http://adrem.ua.ac.be/~wlepage/curriculum-vitae/ his curriculum vitae] as an hResume.
* [[user:Jonathan Arkell|Jonathan Arkell]] has posted an [http://portfolio.jonnay.net/cv/ hResume] on his portfolio website.
* [http://steve.ganz.name/hresume/ Steve Ganz - hResume 0.1]
* [[User:Dave Cardwell|Dave Cardwell]] has marked up [http://davecardwell.co.uk/cv/ his curriculum vitae] as an hResume.
* [[User:EdwardOConnor|Edward O'Connor]]'s [http://edward.oconnor.cx/resume/ resume] is in hResume, and has some experimental JavaScript in it to extract a skill summary from the resume.
* [[User:Lindsey Simon|Lindsey Simon]] has his [http://www.commoner.com/~lsimon/lindsey_simon_resume.html resume] marked up as an hResume - with lots of thanks to Pat Ramsey.
* [[User:Ben Ward|Ben Ward]] has published [http://ben-ward.co.uk/cv his CV] with hResume.
* [http://www.kelleychambers.com Kelley Chambers] has published her [http://www.kelleychambers.com/resume resume] via [http://www.ssdesigninteractive.com/ssdesign/?p=96 Sajid Saiyed's Microformat hResume Plugin for Wordpress].
* [[User:Fishy5|Brennan Falkner]] used hResume to markup his [http://my.usf.edu/bbcswebdav/users/bfalker/resume.html resume].
* [http://www.zachary.com/creemer/resume.html David Creemer's resume] uses hResume, with thanks to Pat Ramsey for the CSS.
* [[User:ChristophBurgdorfer|Christoph Burgdorfer]] has integrated his hResume into a [http://emcons.net/index.php mashup].

== Examples with some problems ==

If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hresume|hResume spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hresume-faq|hResume FAQ]], or raise any queries on [[hresume-issues|hResume Issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you. 

* [[User:RudyDesjardins|Rudy Desjardins]] has marked up his [http://rudy.theendless.org/resume/index.html resume] as an hResume.
** '''Invalid''' : hCard seems invalid
* [[User:MattBosworth|Matt Bosworth]] has marked up his chronological [http://www.codetastic.com/resume-chrono.html resume] and his functional [http://www.codetastic.com/resume-functional.html resume] with hResume.
** '''Invalid''' -- hCalendar's summaries to be specified
* [[User:AndrewPendrick|Andrew Pendrick]] has marked up his [http://www.andrewpendrick.co.uk/cv.html resume] as an hResume.
**'''Invalid''' - hCalendars's summaries to be specified (per Operator).[[User:ChristopheDucamp|xtof]]
* [[User:WebOrganics|Martin McEvoy]] has cobbled together his [http://weborganics.co.uk/hResume/ resume] as a hResume.
**'''Invalid''' - Three hCalendars have empty summary; several tags are invalid (per Operator). [[User:AndyMabbett|Andy Mabbett]] 22:48, 1 Sep 2007 (PDT)
* [[User:DmytroShteflyuk|Dmytro Shteflyuk]] has marked up [http://kpumuk.info/curriculum-vitae/ his resume] as an hResume.
** Invalid; job titles contain hCards without a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:27, 1 May 2007 (PDT)
* [[user:Izo|Mathieu Drouet]] has posted an [http://izo.aucuneid.com/hresume.html hResume].
** ''Incorrect root class name hResume? -- [[DavidJanes]]''
* [[User:Stauciuc|Sergiu Sebastian Tauciuc]] has his [http://www.sergiutauciuc.ro/en/cv.html curriculum vitae] as an hResume.
** Invalid - no contact vCard specified. [[User:AndyMabbett|Andy Mabbett]] 04:05, 10 Mar 2007 (PST)

== Reviewed Examples ==

If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

== Related Pages ==
{{hresume-related-pages}}

currency-examples

2007-06-09T13:32:21Z

Gazza: /* Historic prices */ Fix typo

= Currency Examples =
The following are real-world examples and brainstorming for marking up '''[[currency]]'''.

==The Problem==

The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.

*The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even [http://en.wikipedia.org/wiki/Currency_sign#Examples other units like pesos].
*The language of the page is not sufficient to define the currency of prices in the page:
**More than one currency may be used by people who speak the same language.
**The page may be written in one language and still quote prices/figures in a different country's currency.
**Even if a country can be identified, more than one currency may be used in that country.

Converting currency figures is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]]. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also [http://en.wikipedia.org/wiki/Lira sometimes used to denote Lira]).

=== Currency Changes ===
I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania
* ROL - Romanian Lei [being phased out]
* RON - Romanian New Lei
* after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)

Although the three letter code is different in this case, the currency is often given as ''Lei''. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency.
[[discoleo]]

===Related problems===
"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

[[recipe-examples]]

Though we haven't reached this problem yet in the research, I can see it
coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.

===Use of currency amounts in tables===

Representing currency amounts in a table format is very common. For instance, see [http://investor.google.com/fin_data.html Google Financials].

In this table representation, it does not make sense to provide the currency information for each cell. Instead, it should be provided once at the table, thead, tr, or th, level, and then a td may override the default value. This is very similar to the common practice of indicating the currency and formatting in plain english: "Numbers in thousands of dollars" in the table title/subtitle or legend.

The microformat for currency amounts should provide a way to represent a default currency for all children of a table, thead, tr, or th nodes.
The currency symbol/abbreviation should be optional in for elements defined as containing currency values/amounts, if a default currency has been defined in one of the ancestor elements.

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (proponent)
* Arve Bersvendsen
* [http://tantek.com/log/ Tantek Çelik]
* [http://steve.ganz.name/ Steve Ganz]
* Charles Iliya Krempeaux
*[[User:AndyMabbett|Andy Mabbett]] (2nd proponent)
* Ciaran McNulty
* Mike Stickel
* Ben Ward
* Guillaume Lebleu

== Real-World Examples ==
''Links to public web pages, either popular or insightful''

=== [http://www.govtalk.gov.uk/gdsc/html/frames/AmountSterling-1-0-Release.htm UK Government Data Standards Catalogue] ===

The [http://www.govtalk.gov.uk/gdsc/schemaHtml/FinancialTypes-v1-1-xsd-AmountSterlingStructure.htm associated XML Schema] seems to suggest an ''Amount'' element, followed by a fixed ''Currency'' element of "GBP".

=== [http://www.skype.com/products/skypeout/ SkypeOut Pricing] ===

<pre>2.1 US cents/2.4 CAN cents per minute</pre> (on the Web page)

<pre>¢2.1 USD (or ¢2.4 CAD) per minute.</pre> (in the announcement email)

See also [[measure]]

=== [http://enterpriseforum.mit.edu/mindshare/startingup/dilution.html MIT Enterprise Forum ] ===

<pre>$1 million in equity</pre>

<pre>$2.50 a share</pre>

See also [[measure]]

=== [http://tonto.eia.doe.gov/oog/info/ngw/historical/2004/06_24/ngupdate.asp Energy Information Administration] ===

<pre>23 cents per barrel</pre>

Also in this [http://www.eia.doe.gov/emeu/international/oilprice.html page]:

<pre>(U.S. Cents per Gallon)</pre>

<pre>(Euros per Thousand Liters)</pre>

<pre>(U.S. Dollars per Gallon)</pre>

See also [[measure]]

=== [http://www.cbc.ca/money/story/2005/08/08/oil-050808.html CBCNews] ===

<pre>$63.94 US per barrel, up $1.63 US</pre>

=== [http://finance.google.com/finance?q=google&hl=en Google Finance] ===

The current price of a stock:

<pre>401.90</pre>

=== [http://www.ebay.com eBay] ===

eBay marks prices as "ebcPr". eBay c? Price.

<pre>
<td class="ebcPr">$11.70 $12.95 </td>
</pre>

=== [http://code.google.com/webstats/2005-12/classes.html Google] ===

The Google Web Authoring Statistics mentions that "price" is the 40th most used class name.

Something like:

<pre>
$39.99
</pre>

=== [http://us.mcafee.com/root/package.asp?pkgid=100 McAfee] ===
<pre>
$39.99 (USD)
</pre>

=== [http://www.amazon.com/gp/product/0764597582/sr=8-9/qid=1153301402/ref=sr_1_9/002-9103678-0608852?ie=UTF8 Amazon] ===

<pre><td class="price">$34.85</td></pre>

=== [https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Bell Canada in French Canadian] ===

<pre>Niveau de service Premium - 125 $*</pre>

Note the placement of the dollar sign AFTER the number.

=== [https://secure.vmp.com/signup/adv_signup.php?locale=en_US Bell Canada in US English] ===

<pre>Premium Service Level - $125*</pre>

===Historic prices===
*West Midland Bird Club:
**[http://www.westmidlandbirdclub.com/biblio/worcs.htm#MalvernHand West Midland Bird Club Bibliography] (Published prices of old books)
**[http://www.westmidlandbirdclub.com/reviews/rarer.htm West Midland Bird Club CD-ROM review] (price at time of review; since reduced)
**[http://www.westmidlandbirdclub.com/archive/jubilee-54.htm Silver Jubilee] (1954) - prices in text ("'''five shilling subscriptions'''", "'''10/-'''") shown in footnotes as "'''1 shilling = 5p'''" and "'''10/- = 10 shillings (50p)'''" respectively.
*[http://en.wikipedia.org/wiki/Bleak_House#Original_publication Wikipedia: Bleak House]
**"Like most Dickens novels, Bleak House was published in 19 monthly instalments, each containing 32 pages of text and two illustrations by Phiz. Each cost one shilling, except for the last, which was a double issue and cost two." Dates in the subsequent table range monthly from March 1852 - September 1853
*[http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions Wikpedia: 1922 in Germany]
**"Despite the ending of cash payments for the rest of 1922, the main cause of Germany's inability to pay, the steady depreciation of the mark, was ongoing. Towards the end of the year it assumed a disastrous rapidity. On August 1, the US Dollar still stood at 643 Marks to the Dollar and the British Pound at 2,850 Marks to the Pound. But on September 5 the dollar had already risen to 1,440 Marks and the pound to 6,525 Marks, and in December the pound was worth between 30,000 and 40,000 marks and the dollar between 7,000 and 9,000."
*[http://news.bbc.co.uk/1/hi/business/1096916.stm BBC News story dated 2 January, 2001]
**"A barrel of Brent crude for February delivery came within range of $25 a barrel on Tuesday before slipping to $24.35, a closing price 48 cents above Friday's closing price of $23.87. In New York, the price of Nymex (New York Merchantile Exchange) crude reached $27.40 a barrel before settling at $27.40, a gain of 41 cents or 1.5% on the day. Nymex oil prices in 2000 averaged $30.20 a barrel, the highest level since 1983, and well above the 1999 average of $19.25. Traders also saw support for the oil price from the Opec basket of seven crude oils which stood at $21.75 a barrell on 29 December 2000. That was the seventh day the price stayed below a preferred range of $22-$28 a barrell. Under an Opec price stability measure, output will be cut by 500,000 barrels a day if the basket price stay below $22 for more than 10 days."
*[http://news.bbc.co.uk/1/hi/uk/911569.stm BBC News story dated 5 September, 2000]
**"The Millennium Commission's decision to grant an extra £47m to the Dome has been widely condemned by MPs on various political hues."
*[http://www.jamaica-gleaner.com/pages/history/story0014.html Jamaica and the Great War]
**"in 1917 [...] unemployment was high and wages were low - men received 9 pence a day to cut cane."
*[http://www.wilkiecollins.demon.co.uk/coinage/coins.htm Money and Coinage in Victorian Britain]
*[http://www.margaretmorgan.com/wesley/state.html Macaulay on the State of England in 1685]
**"In 1661 the justices at Chelmsford had fixed the wages of the Essex labourer, who was not boarded, at six shillings in winter and seven in summer."
*[http://www.bbc.co.uk/ww2peopleswar/stories/74/a4095074.shtml BBC - WW2 People's War]
**"I left [school] at Easter 1938. As soon as I had left school, my Father insisted that I went to work for my Uncle. My wages were 5 shillings per week plus board & lodgings"
*[http://privatewww.essex.ac.uk/~alan/family/N-Money.html Relative Value of Sums of Money]
*[http://eh.net/hmit/ How Much Is That?] (set of calculators)

== Existing Practices ==

===Firefox Extension===
[http://viewmycurrency.wordpress.com/about/ Firefox Currency Converter - ViewMyCurrency]

Note: the [http://viewmycurrency.backpackit.com/pub/403081 current bug list] illustrates some problems of identifying currencies based on page content alone:
<blockquote>
<ul>
<li>All $ symbols are treated as USD Very annoying if you are Australian, Canadian etc. (Needs a new feature)</li>
<li>‘Euro 2006 Championship’ should not be converted.</li>
<li>...</li>
<li>Don’t convert CVS keywords . $Revision: 1.3 $ should not be treated as dollars.</li>
</ul>
</blockquote>

===Greasemonkey Scripts ===
[http://nybblelabs.org.uk/projects/exchequer Exchequer]

[http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Yahoo! Finance Currency Converter]

===Relevant Standards ===
[http://www.xe.com/iso4217.htm ISO 4217 Codes]

==See also==
*[http://code.google.com/webstats/2005-12/classes.html Google code - classes] - discussion of <code>class="price"</code> (the 40th most used class on the web) and the case for attributes for unambiguous specification of currency (see final paragraph).
*[http://fx.sauder.ubc.ca/plot.html PACIFIC Exchange Rate Service] - dynamic tables of historic currency conversion rates

==Related pages==
{{currency-related-pages}}
* [[abbr-design-pattern]]

currency-examples

2007-05-19T11:48:00Z

Gazza: Added Real World Example

= Currency Examples =
The following are real-world examples and brainstorming for marking up '''[[currency]]'''.

==The Problem==

The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.

*The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even [http://en.wikipedia.org/wiki/Currency_sign#Examples other units like pesos].
*The language of the page is not sufficient to define the currency of prices in the page:
**More than one currency may be used by people who speak the same language.
**The page may be written in one language and still quote prices/figures in a different country's currency.
**Even if a country can be identified, more than one currency may be used in that country.

Converting currency figures is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]]. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also [http://en.wikipedia.org/wiki/Lira sometimes used to denote Lira]).

=== Currency Changes ===
I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania
* ROL - Romanian Lei [being phased out]
* RON - Romanian New Lei
* after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)

Although the three letter code is different in this case, the currency is often given as ''Lei''. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency.
[[discoleo]]

===Related problems===
"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

[[recipe-examples]]

Though we haven't reached this problem yet in the research, I can see it
coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.

===Use of currency amounts in tables===

Representing currency amounts in a table format is very common. For instance, see [http://investor.google.com/fin_data.html Google Financials].

In this table representation, it does not make sense to provide the currency information for each cell. Instead, it should be provided once at the table, thead, tr, or th, level, and then a td may override the default value. This is very similar to the common practice of indicating the currency and formatting in plain english: "Numbers in thousands of dollars" in the table title/subtitle or legend.

The microformat for currency amounts should provide a way to represent a default currency for all children of a table, thead, tr, or th nodes.
The currency symbol/abbreviation should be optional in for elements defined as containing currency values/amounts, if a default currency has been defined in one of the ancestor elements.

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (proponent)
* Arve Bersvendsen
* [http://tantek.com/log/ Tantek Çelik]
* [http://steve.ganz.name/ Steve Ganz]
* Charles Iliya Krempeaux
*[[User:AndyMabbett|Andy Mabbett]] (2nd proponent)
* Ciaran McNulty
* Mike Stickel
* Ben Ward
* Guillaume Lebleu

== Real-World Examples ==
''Links to public web pages, either popular or insightful''

=== [http://www.govtalk.gov.uk/gdsc/html/frames/AmountSterling-1-0-Release.htm UK Government Data Standards Catalogue] ===

The [http://www.govtalk.gov.uk/gdsc/schemaHtml/FinancialTypes-v1-1-xsd-AmountSterlingStructure.htm associated XML Schema] seems to suggest an ''Amount'' element, followed by a fixed ''Currency'' element of "GBP".

=== [http://www.skype.com/products/skypeout/ SkypeOut Pricing] ===

<pre>2.1 US cents/2.4 CAN cents per minute</pre> (on the Web page)

<pre>¢2.1 USD (or ¢2.4 CAD) per minute.</pre> (in the announcement email)

See also [[measure]]

=== [http://enterpriseforum.mit.edu/mindshare/startingup/dilution.html MIT Enterprise Forum ] ===

<pre>$1 million in equity</pre>

<pre>$2.50 a share</pre>

See also [[measure]]

=== [http://tonto.eia.doe.gov/oog/info/ngw/historical/2004/06_24/ngupdate.asp Energy Information Administration] ===

<pre>23 cents per barrel</pre>

Also in this [http://www.eia.doe.gov/emeu/international/oilprice.html page]:

<pre>(U.S. Cents per Gallon)</pre>

<pre>(Euros per Thousand Liters)</pre>

<pre>(U.S. Dollars per Gallon)</pre>

See also [[measure]]

=== [http://www.cbc.ca/money/story/2005/08/08/oil-050808.html CBCNews] ===

<pre>$63.94 US per barrel, up $1.63 US</pre>

=== [http://finance.google.com/finance?q=google&hl=en Google Finance] ===

The current price of a stock:

<pre>401.90</pre>

=== [http://www.ebay.com eBay] ===

eBay marks prices as "ebcPr". eBay c? Price.

<pre>
<td class="ebcPr">$11.70 $12.95 </td>
</pre>

=== [http://code.google.com/webstats/2005-12/classes.html Google] ===

The Google Web Authoring Statistics mentions that "price" is the 40th most used class name.

Something like:

<pre>
$39.99
</pre>

=== [http://us.mcafee.com/root/package.asp?pkgid=100 McAfee] ===
<pre>
$39.99 (USD)
</pre>

=== [http://www.amazon.com/gp/product/0764597582/sr=8-9/qid=1153301402/ref=sr_1_9/002-9103678-0608852?ie=UTF8 Amazon] ===

<pre><td class="price">$34.85</td></pre>

=== [https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Bell Canada in French Canadian] ===

<pre>Niveau de service Premium - 125 $*</pre>

Note the placement of the dollar sign AFTER the number.

=== [https://secure.vmp.com/signup/adv_signup.php?locale=en_US Bell Canada in US English] ===

<pre>Premium Service Level - $125*</pre>

===Historic prices===
*West Midland Bird Club:
**[http://www.westmidlandbirdclub.com/biblio/worcs.htm#MalvernHand West Midland Bird Club Bibliography] (Published prices of old books)
**[http://www.westmidlandbirdclub.com/reviews/rarer.htm West Midland Bird Club CD-ROM review] (price at time of review; since reduced)
**[http://www.westmidlandbirdclub.com/archive/jubilee-54.htm Silver Jubilee] (1954) - prices in text ("'''five shilling subscriptions'''", "'''10/-'''") shown in footnotes as "'''1 shilling = 5p'''" and "'''10/- = 10 shillings (50p)'''" respectively.
*[http://en.wikipedia.org/wiki/Bleak_House#Original_publication Wikipedia: Bleak House]
**"Like most Dickens novels, Bleak House was published in 19 monthly instalments, each containing 32 pages of text and two illustrations by Phiz. Each cost one shilling, except for the last, which was a double issue and cost two." Dates in the subsequent table range monthly from March 1852 - September 1853
*[http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions Wikpedia: 1922 in Germany]
**"Despite the ending of cash payments for the rest of 1922, the main cause of Germany's inability to pay, the steady depreciation of the mark, was ongoing. Towards the end of the year it assumed a disastrous rapidity. On August 1, the US Dollar still stood at 643 Marks to the Dollar and the British Pound at 2,850 Marks to the Pound. But on September 5 the dollar had already risen to 1,440 Marks and the pound to 6,525 Marks, and in December the pound was worth between 30,000 and 40,000 marks and the dollar between 7,000 and 9,000."
*[http://news.bbc.co.uk/1/hi/business/1096916.stm BBC News story dated 2 January, 2001]
**"A barrel of Brent crude for February delivery came within range of $25 a barrel on Tuesday before slipping to $24.35, a closing price 48 cents above Friday's closing price of $23.87. In New York, the price of Nymex (New York Merchantile Exchange) crude reached $27.40 a barrel before settling at $27.40, a gain of 41 cents or 1.5% on the day. Nymex oil prices in 2000 averaged $30.20 a barrel, the highest level since 1983, and well above the 1999 average of $19.25. Traders also saw support for the oil price from the Opec basket of seven crude oils which stood at $21.75 a barrell on 29 December 2000. That was the seventh day the price stayed below a preferred range of $22-$28 a barrell. Under an Opec price stability measure, output will be cut by 500,000 barrels a day if the basket price stay below $22 for more than 10 days."
*[http://news.bbc.co.uk/1/hi/uk/911569.stm BBC News story dated 5 September, 2000]
**"The Millennium Commission's decision to grant an extra £47m to the Dome has been widely condemned by MPs on various political hues."
*[http://www.jamaica-gleaner.com/pages/history/story0014.html Jamaica and the Great War]
**"in 1917 [...] unemployment was high and wages were low - men received 9 pence a day to cut cane."
*[http://www.wilkiecollins.demon.co.uk/coinage/coins.htm Money and Coinage in Victorian Britain]
*[http://www.margaretmorgan.com/wesley/state.html Macaulay on the State of England in 1685]
**"In 1661 the justices at Chelmsford had fixed the wages of the Essex labourer, who was not boarded, at six shillings in winter and seven in summer."
*[http://www.bbc.co.uk/ww2peopleswar/stories/74/a4095074.shtml BBC - WW2 People's War]
**"I left [school] at Easter 1938. As soon as I had left school, my Father insisted that I went to work for my Uncle. My wages were 5 shillings per week plus board & lodgings"
*[http://privatewww.essex.ac.uk/~alan/family/N-Money.html Relative Value of Sums of Money]

== Existing Practices ==

===Firefox Extension===
[http://viewmycurrency.wordpress.com/about/ Firefox Currency Converter - ViewMyCurrency]

Note: the [http://viewmycurrency.backpackit.com/pub/403081 current bug list] illustrates some problems of identifying currencies based on page content alone:
<blockquote>
<ul>
<li>All $ symbols are treated as USD Very annoying if you are Australian, Canadian etc. (Needs a new feature)</li>
<li>‘Euro 2006 Championship’ should not be converted.</li>
<li>...</li>
<li>Don’t convert CVS keywords . $Revision: 1.3 $ should not be treated as dollars.</li>
</ul>
</blockquote>

===Greasemonkey Scripts ===
[http://nybblelabs.org.uk/projects/exchequer Exchequer]

[http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Yahoo! Finance Currency Converter]

===Relevant Standards ===
[http://www.xe.com/iso4217.htm ISO 4217 Codes]

==See also==
*[http://code.google.com/webstats/2005-12/classes.html Google code - classes] - discussion of <code>class="price"</code> (the 40th most used class on the web) and the case for attributes for unambiguous specification of currency (see final paragraph).
*[http://fx.sauder.ubc.ca/plot.html PACIFIC Exchange Rate Service] - dynamic tables of historic currency conversion rates

==Related pages==
{{currency-related-pages}}
* [[abbr-design-pattern]]

datetime-design-pattern

2007-05-19T11:43:46Z

Gazza: /* Accessibility issues */ Typos

'''This page is a draft.'''

= Datetime Design Pattern =
This is a page for exploring a datetime design pattern.

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable ISO8601 datetime or date as the value

==Current uses==

'''note using these formats will mean your content will likely fail WCAG2.0 accessibility'''

The pattern, which is now available as part of [[hcalendar|hCalendar]], [[hcard|hCard]] and [[hreview|hReview]], is:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

== Profile of ISO8601 ==

We recommend that any [[microformat]] using the date-time-design pattern use a profile of ISO8601. There are currently two widely used profiles which SHOULD be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

==Accessibility issues==

Ironically, this pattern while machine readable for browsers compatible with microformats is not accessible for screenreaders when referring to a date. Therefore:

<pre>
we have a party in
<abbr class="dtstart" title="20070312T1700-06">
March 12, 2007 at 5 PM
</abbr>
</pre>

would be read by Jaws as

<pre>
we have a party at Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six.
</pre>

The [http://www.webstandards.org/2007/04/27/haccessibility/ accessibility task force] from webstandards.org recommends:

<pre>

March 12, 2007 at 5 PM, Central Standard Time

</pre>

or

<pre>

March 12, 2007 at 5 PM, Central Standard Time


</pre>

see more at [[abbr-design-pattern-issues]] and [http://www.webstandards.org/2007/04/27/haccessibility/]

== Discussion ==

This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

---

A few questions:

1) Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page?

2) Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 [http://www.w3.org/TR/WCAG20-TECHS/#H28 H28: Providing definitions for abbreviations by using the abbr and acronym elements], although that is a supporting document and does not have the force of a guideline.

3) In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag?

4) For that matter, wouldn't you want to style such an abbr tag with text-decoration:none to hide that an abbr tag was used? Otherwise, visitors might cursor over the time, see the machine time, and be annoyed that their time was wasted or else be confused. And I don't think you can suppress the title from coming up if the human-readable time was inadvertently hovered.

[[User:CharlesBelov|CharlesBelov]] 16:57, 24 Apr 2007 (PDT)

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

abbr-design-pattern

2007-05-19T11:42:38Z

Gazza: /* Accessibility issues */ Typos

<h1> Abbr design pattern </h1>

__TOC__

== Purpose ==
* Use the [[abbr-design-pattern]] to make text that is human readable also formally machine readable
* Avoiding using the [[abbr-design-pattern]] to re-encode human text or to hide data

== How to use it ==
* enclose the human-friendly text that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable data as the value

== Example ==
The [[datetime-design-pattern]] formally encodes (the notoriously unparsable) datetimes into an <code>abbr</code> element.

Before:

<pre>
The party is at 10 o'clock on the 10th.
</pre>

After:

<pre>
The party is at
<abbr class="dtstart" title="20051010T10:10:10-0100">10 o'clock on the 10th</abbr>.
</pre>

==Alternative presentations==
Note that the following are all equivalent, to a microformat parser:

<pre>
20070501

2007-05-01

<abbr class="dtstart" title="20070501">1 May 2007</abbr>

<abbr class="dtstart" title="2007-05-01">1 May 2007</abbr>

<abbr class="dtstart" title="20070501">1st May 2007</abbr>.

<abbr class="dtstart" title="20070501">May 1st 2007</abbr>.

<abbr class="dtstart" title="20070501">The first of May, 2007</abbr>.

<abbr class="dtstart" title="20070501">2007-05-01</abbr>.

<abbr class="dtstart" title="20070501">Tuesday, 1 May 2007</abbr>

<abbr class="dtstart" title="20070501">2007, day 121</abbr>

<abbr class="dtstart" title="20070501">May Day, 2007</abbr>

<abbr class="dtstart" title="20070501" lang="FR">1er mai, 2007</abbr>

<abbr class="dtstart" title="20070501" lang="ES">1 de mayo, 2007</abbr>
</pre>

and the following may be used in, say, a list, table, or page, headed "2007":

<pre>
<abbr class="dtstart" title="20070501">1 May</abbr>
</pre>

== Discussion ==
''This discussion is culled from [http://microformats.org/discuss/mail/microformats-discuss/2005-October/001277.html here]''. Consider two possible uses for the [[abbr-design-pattern]]:

<ol>
<li>
using ABBR to encode machine readable data around human readable data

<pre>
<abbr class="dtstart" title="20051010T10:10:10-0100">10 o'clock on the 10th</abbr>
</pre>
</li>
<li>
using ABBR to encode more formal human data around something less formal

<pre>
<abbr class="author" title="Danny Ayers">Danny</abbr>
</pre>
</li>
</ol>

Use #1 is encouraged if there's a reasonable need for it. Use #2 is discouraged under the [http://c2.com/cgi-bin/wiki?DontRepeatYourself Don't Repeat Yourself principle], as: "#2 is a case of *more* information being invisibly present, namely, the
last name in this case. If someone is not willing to make some information visible, then we
shouldn't be encouraging them to store that information invisibly, for all
the same reasons that invisible metadata is bad/futile in the first place."

''I'd like to delete this below, as the points are covered above''

* Theoretically, this could be done with almost any HTML element. But is it a good idea? If it's not, is abbr the only one? [[DavidJanes]]
* abbr-design-pattern should be avoided, if possible. [[User:RobertBachmann|RobertBachmann]]
** why, or under what circumstances? For example, it is quite useful with datetimes. Should there not be other potentially analogous situations? [[DavidJanes]]
** Under circumstances where the text in the title would be gobbledegook if read by a screenreader. JAWS and other screenreaders use title attributes from abbr, when used properly (as in this example from the WCAG group), to pronounce words which would otherwise be unreadable or confusing. Using machine data such as datetime as a title is an bending of the dictionary definition of abbreviation (contraction by ommision or initialisation, applied at the word and not semantic level), this may not be a great issue in itself, but if screen readers are unable to turn title content into something comprehensible, this will lead to accessibility failures.

<pre>
Sugar is commonly sold in 5 <abbr title="pound">lb.<abbr> bags.
Welcome to the <abbr title="World Wide Web">WWW</abbr>!
</pre>

==Accessibility issues==

Ironically, this pattern while machine readable for browsers compatible with microformats is not accessible for screenreaders when referring to a date. Therefore:

<pre>
we have a party in
<abbr class="dtstart" title="20070312T1700-06">
March 12, 2007 at 5 PM
</abbr>
</pre>

would be read by Jaws as

<pre>
we have a party at Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six.
</pre>

The [http://www.webstandards.org/2007/04/27/haccessibility/ accessibility task force] from webstandards.org recommends:

<pre>

March 12, 2007 at 5 PM, Central Standard Time

</pre>

or

<pre>

March 12, 2007 at 5 PM, Central Standard Time


</pre>

see more at [[abbr-design-pattern-issues]] and [http://www.webstandards.org/2007/04/27/haccessibility/]

== See Also ==
* [[abbr-design-pattern-issues]]
* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [http://microformats.org/discuss/mail/microformats-discuss/2005-October/001277.html discussion in microformats-discuss]
* [[datetime-design-pattern]] uses [[abbr-design-pattern]]
* [http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR HTML 4.01 definition]

User talk:Gazza

2007-05-01T13:58:44Z

Gazza: Clarification

I've made the following changes:
* All links to users had the User: bit inserted.
* I checked to see if the User page already existed under a variation of the linked name.
* By doing this, I could go along and put "..." on the User pages. This stops the names from appearing in red, but more importantly, removes that link from the Wanted pages, leaving a cleaner look at really what '''are''' the wanted pages.
* The Wanted pages list went from ~120 down to ~50.
* The "..." might encourage those users to put something meaningful on their User page.
* If they do, then the links on the various discussion pages become more useful.

* Note that no links were removed from any pages (that's for someone else with more authority than me to do), just tweaked.

--[[User:Gazza|Gazza]] 06:10, 1 May 2007 (PDT)

Category:Species

2007-05-01T13:55:06Z

Gazza:

Lists the pages related to the proposed ''species'' microformat.

species

2007-05-01T13:53:55Z

Gazza: Added Category

=Species=

:'''For the latest ideas, and to make comments, please see [[species-brainstorming]].'''

:'''Note: the original name of the proposed microformat, "species", is likely to change, probably to "biota" or "taxon". The former has been retained here, to avoid having to make many repetitive and perhaps redundant edits'''

:'''{{UpdateMarker}} The new [http://www.kaply.com/weblog/2007/02/16/operator-07a-is-available/ beta of Operator] detects ''Species''. [http://www.westmidlandbirdclub.com/records/lists-2004uf.htm A test page is available]. Work on both continues!'''

==Introduction==

People use the vernacular AND taxonomic names of species in everyday speech and writing - just read or watch any populist gardening magazine or television programme.

*Consider this list: "'''Blackbird'''", "'''poodle'''", "'''T Rex'''", "'''potato'''", "'''French Marigold'''", "'''Wisteria'''", "'''E. Coli'''", "'''HIV'''", "'''Rubella'''" and "'''human being'''".

:"'''T Rex'''" is "''Tyrannosaurus rex''"; "'''E. Coli'''" is "''Escherichia coli''"; "'''HIV'''" is "''Human immunodeficiency virus''" and "'''Rubella'''" is "''Rubella virus''". All are the taxonomic (or scientific) names of unique species.

:"'''''Wisteria'''''" is a taxonomic genus.

:"'''Blackbird'''"; "'''poodle'''"; "'''potato'''"; "'''French Marigold'''" and "'''human being'''" (arguments about Neanderthals not withstanding) are vernacular (or common) names, but still refer to individual species.

*The scientific naming of organisms is a part of [http://www.calacademy.org/research/informatics/sblum/pub/biodiv_informatics.html biodiversity informatics] - "the application of information technology to the domain of biodiversity".

*The proposal aligns with [http://www.ted.com/tedprize/2007/wilson.cfm E.O Wilson's wish]:

<blockquote>...that we will work together to help create the key tool that we need to inspire preservation of Earth's biodiversity: the Encyclopedia of Life [...] an encyclopedia that lives on the Internet, with an ever-evolving page for every species [and which]
does not duplicate existing efforts, but instead incorporates them through linking [with a] search technology that can aggregate existing biological information and make it easily accessible.</blockquote>

*As long ago as April 1998 on [http://www.w3.org/MarkUp/future/papers/rothenburg-19980412.html Robert Rothenburg's paper on Dictionaries] (''Note 4'') said:

<blockquote>What is missing [from HTML] is an element for marking up "proper names" (names of people, geographic locations, institutions, or even '''scientific names such as genus/species''').</blockquote>

:It's interesting that microformats have given us the first three missing items - and we're now debating the fourth!

==Proposal==
Imagine viewing a web page with a reference to a species - and being able to use an add-on to you browser to be taken directly to information about that species, on, say, Wikipedia, or Wikispecies, or Google Images, or another site, such as in an academic database, of your choosing.

Your software would automatically know to search site A if the scientific name referred to a moth, site B for a bird, and site C for a plant - and you could set your preferences as to which sites those were to be, and in which order two or more were to be searched (e.g. for moths, try [http://ukmoths.org.uk/ UK Moths] first, if not found try [http://www.nhm.ac.uk/research-curation/projects/lepindex/index.html The Global Lepidoptera Names Index]).

Or supposing someone writes a long, chronologically-ordered web page about all the birds, insects, mammals and plants they saw on a wildlife safari, with lots of prose description about the paces where they saw them and the people they were with, but you want to extract a list of species, sorted into alphabetical order within taxonomic class (birds first, then insects then...) or in taxonomic order.

Those are just two of the things a "species" microformat might do for you.

Your software, or a search engine, would be able to differentiate between a pages discussing HMS Beagle, the ship, and a Beagle dog; or birds that fly as opposed to a slang term for women.

Another benefit would be that user-agents could be instructed to treat text marked up in this way as not being in the base language of the document or element in which they occur - pronunciation should be as for Latin, they should not be translated (e.g. where a component word happens also to be a valid word in that language, such as the genus '''''Colon''''', '''''Circus''' cyaneus'', ''Hesperia '''comma''''', or anything with ''major'' or ''minor'' on an English-language page) and should not be spell-checked, or be spell-checked with a specialised dictionary (a need identified in this [http://www.alvestrand.no/pipermail/ietf-languages/2003-February/000590.html 2003 ietf-languages discussion of language values for taxonomic names]).

A further benefit the species microformat would bring is in the enriching and enhancement of species checklists, which are commonly found on the web. Broadly speaking, a species checklist is a list of taxa, usually for a particular group of similar organisms such as birds or vascular plants, found within a particular geographical region (a country, [http://www.westmidlandbirdclub.com/records/lists.htm a region], a county, or a specific site, large or small). A typical example of a species checklist is the [http://www.coleopterist.org.uk/checklist.htm Checklist of Beetles of the British Isles] which, as the name suggests, lists beetles known to be found within the British Isles. A [http://www.google.com/search?q=species+checklist Google Search for "species checklist"] will reveal many other such examples. Species checklists are presented in a broadly consistent manner but are usually unable to be parsed and utilised by computers due to the lack of a common standard for marking them up in HTML. The species microformat would provide that common standard. A fully microformat enabled checklist would be parsable by computers and thus would provide developers with a means by which to aggregate and otherwise make use of this invaluable content beyond the current, rather limited, use of simple online viewing.

A specific example of checklist use might be in enabling [http://www.aditsite.co.uk/html/choosing_recording_software.html biological recording software] to parse and aggregate checklists in order to include them in their own species dictionaries. Typically there are waits of many months or even years while humans collate checklist changes manually for inclusion in recording software; automated checklist parsing and aggregation would greatly expedite and increase the efficiencies of this process.

==Existing taxonomies==
The proposal respects all existing biological taxonomies, and is not intended to change or supplant any of them - it is intended merely to provide webmasters (from personal hobby sites to major academic databases; from news outlets to retail organisations) with a method of either:

# marking-up a taxonomical name (or taxon-common name pair) in such a way that its components can be recognised by computers '''or'''
# marking up a common name, so as to associate with it a taxonomical name, in such a way that the latter's components can be recognised by computers.

==Embedding within other microformats==
The proposed [[plant]] microformat (with care regime, supplier, etc.), [[hlisting]], [[recipe]] or [[hReview]] (and possibly others) could contain a scientific name microformat, in the same way that an [[hCalendar]] can contain an [[hCard]].

See also: [[species-brainstorming#Future development]]

==References==
*[http://en.wikipedia.org/wiki/Scientific_classification Wikipedia: Scientific classification]
**[http://en.wikipedia.org/wiki/Binomial_nomenclature Wikipedia: Binomial nomenclature]
**[http://en.wikipedia.org/wiki/Trinomial_nomenclature Wikipedia: Trinomial nomenclature]
**[http://en.wikipedia.org/wiki/Taxon Wikipedia: Taxon]
**[http://en.wikipedia.org/wiki/Cultivar Wikipedia: Cultivars]
**[http://en.wikipedia.org/wiki/Variety_%28biology%29 Wikipedia: Varieties]
**[http://en.wikipedia.org/wiki/Subvariety Wikipedia: Sub-varieties]
**[http://en.wikipedia.org/wiki/Form_%28botany%29 Wikipedia: forms]
**[http://en.wikipedia.org/wiki/Synonym_%28taxonomy%29 Wikipedia: Synonyms]
**[http://en.wikipedia.org/wiki/Wikipedia:How_to_read_a_taxobox How to read a taxobox]
*[http://www.iczn.org/ http://www.iczn.org/ International Commission on Zoological Nomenclature]
**[http://en.wikipedia.org/wiki/Binomial_nomenclature Wikipedia: International Commission on Zoological Nomenclature]
*[http://www.iczn.org/ International Code of Botanical Nomenclature]
*[http://www.rhs.org.uk/rhsplantfinder/plantnaming.asp RHS Plant Finder: The naming of plants]
*[http://www.ishs.org/sci/icracpco.htm International Code of Nomenclature for Cultivated Plants]
*[http://www.tdwg.org/index.html Taxonomic Databases Working Group]
*[http://www.hortax.org.uk/ Hortax] - The Names of Garden Plants
*[http://www.bgbm.fu-berlin.de/iapt/nomenclature/code/SaintLouis/0000St.Luistitle.htm www.bgbm.fu-berlin.de/iapt/nomenclature/code/SaintLouis/0000St.Luistitle.htm]
*[http://species.wikimedia.org/wiki/Main_Page WikiSpecies]
*[http://en.wiktionary.org/wiki/taxonomy Wiktionary: Taxonomy]
*[http://jbi.nhm.ku.edu/index.php/jbi/article/view/25 Biodiversity Informatics: Taxonomic names, metadata, and the Semantic Web]

==Contributors & Supporters==
*[[User:AndyMabbett|Andy Mabbett]] (proponent)
*[[User:RogerHyam|Roger Hyam]] (interested party?)
*[[User:SXBRC|Charles Roper]], [http://www.sxbrc.org.uk/ Sussex Biodiversity Record Centre] (proponent)
*[[User:SteveMcBill|Steve McWilliam]], [http://www.rECOrd-LRC.co.uk/ rECOrd - The Biodiversity Information System for the Cheshire region] (supporter)
*[[User:KierenPitts|Kieren Pitts]], [http://www.ilrt.bris.ac.uk/ ILRT - Institute for Learning and Research Technology] and the [http://www.amentsoc.org/ Amateur Entomologists' Society] (supporter)
*[[User:CyndyParr|Cyndy Parr]], [http://spire.umbc.edu Spire project] (interested party)
*[[User:AnimalDiversity|Animal Diversity Web]], [http://animaldiversity.org] (interested party)
*[[User:Christoph|Christoph Champ]], [http://www.christophchamp.com/] (supporter with a background in biochemistry, biophysics, and bioinformatics)

==See also==
Here's some work-in-progress:
{{species}}
*[https://addons.mozilla.org/firefox/169/ Biobar] - A customisable Firefox Extension providing a toolbar and content menu options for browsing biological data and databases, which shows what a user-agent could do, with data extracted from a species microformat

==Implementations (pending)==
*[http://www.spacefornature.co.uk/biorec/taxoncheck.htm Taxon Checker] - a software tool which, given a common name, searches for the relevant taxonomic data and outputs the selected species' details as (among other options) an HTML fragment. It is intended to provide templates for outputting such fragments with "species" microformat markup, once this proposal is implemented.
*[http://en.wikipedia.org/wiki/User:Beastie_Bot Wikpedia's Beastie Bot] can be used to update the "taxoboxes" of articles about living things/

[[Category:Species]]

species-brainstorming

2007-05-01T13:52:48Z

Gazza: Added Category

=Species Brainstorming=

:'''Note: the original name of the proposed microformat, "species", is likely to change, probably to "biota" or "taxon". The former has been retained here, to avoid having to make many repetitive and perhaps redundant edits'''

:'''{{UpdateMarker}} The new [http://www.kaply.com/weblog/2007/02/16/operator-07a-is-available/ beta of Operator] detects ''Species''. [http://www.westmidlandbirdclub.com/records/lists-2004uf.htm A test page is available]. Work on both continues!'''

==Andy Mabbett==
===Proposal===

There should, I believe, be a "'''[[species]]'''" microformat for the markup of plant and animal names, to include their scientific names. Consider:

:<pre><nowiki><abbr class="species" title="Anas platyrhynchos">Mallard</abbr></nowiki></pre>
or
:<pre><nowiki>Anas platyrhynchos</nowiki></pre>

The microformat would allow user agents to be configured to perform look-ups on on-line databases of species, according to user preferences. Specification of the taxonomic class would help user agents to know which such databases were applicable (i.e., use database A for plants, but database B for mammals and database C for insects.)

It would also allow for more specific searching (do I mean "crow" or do I mean "Corvus corone"?).

The specification should encourage, but not mandate, the correct capitalisation of scientific names, so "''Anas platyrhynchos'''" not "''anas platyrhynchos''" nor (except historically) "''Anas Platyrhynchos''". A reminder that such names should be styled with italics will also be included.

===Straw man proposal===

I'm tending towards this model, nested according to components of the microformat, not taxonomically:

[Note: in taxonomy, levels such as "subphylum", "class" or "order" are known as a "rank"].

[Note: It is intended that all these (X)HTML classes be '''''optionally'''' available to publishers, but they need use '''''only''''' those which apply to their particular needs. Compare, for instance, with all the classes and types available in [[hcard|hCard]].]

*species (scientific name; aka botanical name) (better: '''taxon'''; or '''biota''')
**domain (alternatively: "superregnum")
**kingdom (alt: "regnum")
**subkingdom (alt: "subregnum")
**superphylum
**phylum
**subphylum
**taxoclass (alt: "taxo-class ", "taxonclass", "taxon-class", "classis")
**subclass (alt: "subclassis")
**infraclass (alt: "infraclassis")
**superorder (alt: "superordo")
**order (alt: "ordo")
**suborder (alt: "subordo")
**infraorder (alt: "infraordo")
**parvorder
**superfamily (alt: "superfamilia")
**family (alt: "familia")
**subfamily (alt: "subfamilia")
**rank (alt: "taxorank", "taxon-rank", et al) - "unranked". See [http://names.ubio.org/browser/classifications.php?conceptID=2463046]; might also be used where the level of a rank is disputed, or the author simply has no ability or wish to declare the rank more explicitly.
**binominal ("binominal name" alt: "binomial")
***genus
***specific (="''specific epithet''")
**subsp ("subspecies")
**variety
**subvar ("subvariety")
**form
**subform
**cultivar
**cultgp ("cultivar group")
**cross (e.g. "F1")
**strain
**? morph (or phase) (e.g "Gyrfalcons, for example, have a grey morph and a white morph" [http://www.peregrine-foundation.ca/info/dictionary.html]; "the Lesser Snow Goose (C. c. caerulescens), commonly occurs in two plumage variants. White-phase birds are white except for black wing tips, but blue-phase geese have bluish-grey plumage replacing most of the white except on the head, neck and tail tip." [http://en.wikipedia.org/wiki/Snow_goose])
**trade ("trade name")
**breed (e.g. Bull Terrier)
**sense (botanical - see [[species-examples#Sense (plant)|examples]])
**authority
***year (...of authority)
**cname ("common name" - should this be "common" or "vernacular"?)
**guid
**vgroup ("vernacular group" (alt: "vernacular-group") - there is possibly a better term for this. Often, a genus or family doesn't encapsulate a particular group of species in a practical or useful fashion. For example, it is difficult to seperate fungi species and lichen species as they are taxonomically intermingled. Thus, within taxonomic databases, a vernacular group of "fungi" and "lichen" is often applied to species falling into either of these groups. A vernacular group could be considered similar to a common name, but for groups of species. See the [http://www.searchnbn.net/directory/browseTGLevel1.jsp NBN Gateway] for an example of vernacular groups in use; these group names are also used in the [http://www.recordersoftware.org/ Recorder] biological recording software.
**? gender (useful for species exhibiting sexual dimorphism - "find me a picture of a male Pintail"; "I want to buy a female Holly bush" - a binary value, '''m'''ale or '''f'''emale; or including '''n'''ueter, '''h'''ermaphoradite, '''u'''nspecified and/ or '''m'''ixed?)- see [[#Future development|Future development]]
**? age bracket (adult/ juvenile/ seed/ egg/ nymph/ nestling/ pup/ cub/ instar1/ instar2 etc. - '''needs more work''') - see [[#Future development|Future development]]
**? count (a number, or represenattion of some other value - none, unspecified, "present", etc) - see [[#Future development|Future development]]
** [name to be suggested ("type", "role"?)] an indicator of type, e.g. for bees, "queen" or "worker" [Q: Is there a proper name, in the scientific cmmnuity, for thes edistinctions?]

where are optional, and it is possible to infer from simply:
:<pre><nowiki><abbr class="binominal" title="Anas platyrhynchos">Mallard</abbr></nowiki></pre>
or
:<pre><nowiki>Anas platyrhynchos</nowiki></pre>
that the genus is ''Anas'' and the species is ''platyrhynchos'' (and, thus, "binominal" is to "sci"; as "[[adr]]" is to "[[hCard]]")

A species (Citrine Wagtail, a bird):

<pre><nowiki>

Motacilla citreola

</nowiki></pre>

Sub-species (animal):
<pre><nowiki>

Larus glaucoides
kumlieni

</nowiki></pre>

Variety (plant):
<pre><nowiki>

Pisum sativum
var. macrocarpon

</nowiki></pre>

Species (animal, common name displayed):
<pre><nowiki>

<abbr class="binominal" title="Larus thayeri">
Thayer's Gull
</abbr>

</nowiki></pre>

Species (animal, scientific name displayed):
<pre><nowiki>

<abbr class="common" title="Thayer's Gull">

</abbr>

</nowiki></pre>

Fungus, kingdom included:
<pre><nowiki>

<abbr class="kingdom" title="Fungi">
Amanita muscaria
</abbr>

</nowiki></pre>

Same name for different Genera:

<pre><nowiki>

An unidentified
<abbr class="taxoclass" title="Aves">
<abbr class="genus" title="Oenanthe">

Wheatear

</abbr>
</abbr>

</nowiki></pre>

and :

<pre><nowiki>

An unidentified
<abbr class="taxoclass" title="Magnoliopsida">
<abbr class="genus" title="Oenanthe">

Water Dropwort

</abbr>
</abbr>
sp.
</nowiki></pre>

Species (animal, with authority and year):
<pre><nowiki>

Pica pica
Linnaeus,
(1758)

</nowiki></pre>

Re-classified species (animal):
<pre><nowiki>
The species was classified as

<abbr class="binominal" title="Bartramia longicauda">Tringa longicauda</abbr>
by Johann Bechstein in 1812.

</nowiki></pre>

A more extreme example, where there is a need to describe the full taxonomic hierarchy:

<pre><nowiki>

Eukarya
Animalia
Eumetazoa
Deuterostomia
Chordata
Vertebrata
Aves
Neognathae
Passeriformes
Passeri
Passerida
Passeroidea
Motacillidae

Motacilla
alba
yarrellii

Pied Wagtail
Linnaeus
1758

</nowiki></pre>

=====Expressing a species with a GUID=====
Work is currently underway, through [http://www.nhm.ac.uk/hosted_sites/tdwg/ TDWG] to develop a [http://wiki.gbif.org/guidwiki/wikka.php?wakka=HomePage truly global GUID system] based on [http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSID LSID]s. [http://xml.coverpages.org/lsid.html More on LSIDs].

In the following example case an NBN GUID is provided. This GUID would be usable on the [http://www.searchnbn.net/speciesInfo/taxonomy.jsp?searchTerm=lutra%20lutra&spKey=NBNSYS0000005133 NBN Gateway], [http://nbn.nhm.ac.uk/nhm/bin/nbntaxa.dll/taxon_details?taxon_key=NBNSYS0000005133 The NHM Species Dictionary], in Recorder 2002 and Recorder 6, and in the forthcoming OpenRecorder online recording toolkit. As there are different GUIDs for different databases, the type of GUID can be indicated with a code followed by a hyphen followed by the GUID (e.g. nbn-NBNSYS0000005133).
<pre><nowiki>

Lutra lutra

</nowiki>
</pre>
Alternatively, the GUID could be expressed as an element in its own right, with the GUID type being expressed as a secondary class name:
<pre><nowiki>

Lutra lutra
NBNSYS0000005133

</nowiki>
</pre>
As a further alternative, the [[abbr-design-pattern]] could potentially be used, although this is semantically questionable:
<pre><nowiki>

<abbr class="binominal" title="NBNSYS0000005133">Lutra lutra</abbr>

</nowiki>
</pre>
Yet another alternative, using a [http://www.ubio.org/index.php?pagename=home uBio] LSID as the GUID:
<pre><nowiki>

Green Sandpiper
Tringa ochropus

</nowiki>
</pre>
uBio has a publicly available [http://www.ubio.org/index.php?pagename=soap_tools SOAP web services interface] which makes mining for taxonomic intelligence relatively easy.

====Questions====

* Is "sci" the best attribute name for the top-level?
** No - Scott Reynen
*** What do you think would be better? - Andy Mabbett
**** Assuming "sci" is short for "scientific name", I propose "scientific-name".
***** It is. That's 12 extra characters! - Andy Mabbett
** '''Taxon''' is a far better solution [http://en.wiktionary.org/wiki/taxon]. It's short, meaningful and in keeping with the other class types. - Andy Mabbett
*** I think "taxonname" or "taxon-name" would be a better value for the class attribute. It is more descriptive of the data your trying to specify the format of. Taxon refers more to the classification grouping I thought. The class attribute is used frequently for the application of CSS styling so the top level class at least needs to be fairly distinctive I would have thought to avoid clashes with other class attribute values in the page and CSS files. - Tony Prichard
**** The OED defines ''taxon'' as "A taxonomic group". See also the URL cited, [http://en.wiktionary.org/wiki/taxon]. - Andy Mabbett
***** I agree that '''taxon''' would be the most suitable name. It could be considered as a shortening of '''TaxonConcept''' (or '''TaxonName'''), which is the term used by the [http://tdwg.napier.ac.uk/index.php?pagename=VotingDraftIntroduction TCS] - Charles Roper
** or '''Biota''' - Andy Mabbett
*'''Species''' is used in the above, for the sake of having one name to use, but "biota" or "taxon" are likely to be used in the final version. [[User:AndyMabbett|AndyMabbett]] 09:15, 22 Oct 2006 (PDT)

* Should "bin", var", "cult", etc., be written in full? (I think not, to save bloating file sizes)
** Yes - Scott Reynen
***'''Conceded''', and applied to the above. What about "subsp", etc? [[User:AndyMabbett|AndyMabbett]] 09:15, 22 Oct 2006 (PDT)

* Should other attribute names be abbreviated for brevity?
** No, brevity is not one of the [[naming-principles|naming principles]]. "bin", "var", and "cult" all leave ambiguous meaning, which is a problem. We should "Use class names based on names from the original schema," e.g. full words or phrases where they aren't especially long. - Scott Reynen
*** Fair enough, though I worry about some of my pages, with tens or hundreds of species listed! Also, note that "var" "sub" and suchlike are the ''proper'' abbreviations to use, in botanical nomenclature (see the posted examples). - Andy Mabbett
*** I think a balance will need to be achieved between brevity in the interests of avoiding bloated html in a page with many species names and giving a meaningful name - Tony Prichard
**** Would bloating really be an issue? Many, if not most, servers (including this one) now gzip,deflate content and thus transfer time aren't so much of an issue. The front page of the microformats site states "Designed for humans first and machines second[...]", so unabbreviated terms would be more consistent with this aim. - Charles Roper
*****[http://www.westmidlandbirdclub.com/records/lists.htm 341 species, 58Kb]. 'Nuff said? [[User:AndyMabbett|AndyMabbett]] 11:53, 26 Sep 2006 (PDT)
******Your bird list page can be [http://snipurl.com/zfmj compressed by 79%], i.e. it would go down from 58KB to 12KB by enabling output compression on your server. It would also make the page load faster and save you bandwidth. No doubt compression technologies will improve over time, as will connection speeds and server speeds, so the technical solution to reducing page size would seem to me to be preferable over the "manual compression" method, i.e. using abbreviated, less clear, less readable class names. While it is easy to improve the compression technology (or switch it on, even), it's much harder to change an established microformat standard. - [[User:CharlesRoper| Charles Roper]]

* Is "class" a potentially confusing attribute name, and what should replace it ("taxoclass", perhaps? or "classis"?)
** Yes I would avoid class as it a frequent keyword in software languages - Tony Prichard
*** "bin" and "var" are also extremely common terms using in programming languages - Charles Roper
***'''Conceded''', and "taxoclass" applied to the above. "classis" would be an alternative. [[User:AndyMabbett|AndyMabbett]] 09:15, 22 Oct 2006 (PDT)

* What other attribute names are needed, if any (we could do with help from a taxonomist!)

* How to deal with: "Podiceps sp." (a grebe of unknown species)
** How about the following, where we can infer an unknown species by the absence of that attribute?:
:<pre><nowiki>Podiceps</nowiki></pre>
** There are also species aggregates and groups to be considered Grey/Dark Dagger sp., where it is one of two species but where the genus Acronicta cannot be used as there are more than the two species in the genus - Tony Prichard
*** Any suggestions? Or other examples? - [[User:AndyMabbett|AndyMabbett]]
**** This kind of aggregates are often used by birdwatchers (in Finland). How about separating the names with a slash (or some other sign)?: - [[User:MikkoBiomi|MikkoBiomi]]
:<pre><nowiki>Phylloscopus trochilus/Phylloscopus collybita</nowiki></pre>
:<pre><nowiki>Anser/Branta</nowiki></pre>

* Should we allow divisions of "binominal" with no parent "species", such as:
:<pre><nowiki>Larus glaucoides kumlieni</nowiki></pre>

* Is the "fungus" example OK, given that '''Amanita muscaria''' is not an abbreviation of "funghi"?
** I do not like the use of the abbr tag at all in the examples given. The abbr tag is for abbreviations with the suggestion that the title is used for the full name. The implication in the Mallard example is that Mallard is an abbreviation for the scientific name, it is not it is a different type of name - Tony Prichard

* Do the "authority" and "date" pair need a joint wrapper?

* Is "bin" (short for binominal) the most appropriate term for a taxon name? When subspecies, var, subvar, etc. are nested, then surely it becomes [http://en.wikipedia.org/wiki/Trinomial_nomenclature trinomial]? Would simply '''name''' or '''TaxonName''' not be more flexible? - Charles Roper

====To add====
* Animal hybrids
* GUID (Globally Unique Identifier). When referencing to a taxon name, there is also often the need to provide a GUID which relates to a taxonomic concept database (such as the [http://nbn.nhm.ac.uk/nhm/ NHM Species Dictionary]). By providing a GUID, ambiguity is removed. - Charles Roper
** Thank you. [[User:AndyMabbett|AndyMabbett]] 11:55, 26 Sep 2006 (PDT)

====Future development====
Instead of including gender, age-bracket and count, we could allow for a furture microformat, called, perhpas, "sighting", which might have the components:

*sighting
**species (a "species" microformat)
***set (one or more)
****count
****age-bracket
****gender
**location (hCard or geo)
**date-time

See [http://www.westmidlandbirdclub.com/ladywalk/latest.htm West Midland Bird Club's Latest news from Ladywalk] and [http://www.birdforum.net/showthread.php?t=48505 In and around South Staffordshire 2006 (blog)] for simple examples.

==Bill Hull==
[http://www.mangoverde.com/ My website] has 17000+ photos of 4700+ bird species. There are also a handful of butterflies (organized very poorly as I am unaware of any published butterfly world taxonomies) and shortly will have a number of dragon/damselflies. The site is made up of static pages but is built from a database so it is easy for me to add it new HTML tags to the pages. If you are interested in some prototyping at some point I can probably build stuff into the pages. - Bill Hull

==Roger Hyam==
===Taxonomic Databases Working Group===

[http://www.tdwg.org/index.html TDWG] is the organisation for standardisation in exchange of biodiversity data. The organisation is currently undergoing a degree of re-organisation and is developing an architecture to integrate the different standards it produces with each other and with those in use in the semantic web and geospatial communities. Part of this architecture will be a central ontology for things like scientific biological names.

Because of its role in bridging technologies the application that manages the ontology will need to be able to express the same basic semantics in multiple formats (e.g. RDFS, OWL, Geography Mark Up, OBO etc). It seems logical that this application should also generate basic microformat definitions for each of the classes it contains. If we have an ontology defining 'Taxon Name' and 'specific epithet' for example the same notion should be mapped to as many technologies as possible.

TDWG is also supporting a system for Globally Unique Identifiers based on Life Science Identifiers for biodiveristy objects such as taxon names, specimens, herbaria etc which it would be cool to integrate into any microformat.

There is a meeting in [http://tdwg2006.tdwg.org/ St Louis, USA, October 2006] where the way forward for the ontology will be discussed. Decisions made at the meeting will govern what is possible. It is difficult to take this further without concensus from that meeting.

If it is after October 2006 and you are interested in learning more please contact me ([[User:RogerHyam|Roger Hyam]]).

*Thanks, Roger - it's good to have the involvement of such an august body, especially just before such a fortuitously-scheduled event. Is there any chance (and I realise that this is rather late in the day) that this proposal could be on the agenda in St Louis (even if only through a note in the papers/ programme); or that someone from the microformat community could attend/ speak there? Or that the TDWG and/or conference websites could link to '''http://microformats.org/wiki/species'''? - Andy Mabbett

==Malcolm Storey==
(extracted from e-mails to Andy Mabbett, by kind permission)

* "Hopefully I'll have more time for things like this in the New Year, but expect it all be done and dusted by then!!" - Malcolm Storey, [http://www.bioimages.org.uk/ BioImages]

===ICZN, ICBN et al===
You don't cover the full set of levels of taxonomic hierarchy defined by the relevant body ICZN or ICBN (plus the others - one each for garden plant varieties, bacteria, viruses. Don't know about mycoplasmas, diseases, BSE factors etc.

ICBN Ranks listed [http://www.bgbm.org/iapt/nomenclature/code/SaintLouis/0007Ch1Art003.htm], [http://www.bgbm.org/iapt/nomenclature/code/SaintLouis/0008Ch1Art004.htm]

AIUI ICBN only goes down to species.

ICZN isn't so easy: [http://www.nhm.ac.uk/hosted_sites/iczn/]

:1.2.2. The Code regulates the names of taxa in the family group, genus group, and species group. Articles 1-4, 7-10, 11.1-11.3, 14, 27, 28 and 32.5.2.5 also regulate names of taxa at ranks above the family group. (But none of the above articles list the taxonomic ranks.)

ICZN Only goes down to subspecies (art 1.3.4)

Note also:

:1.4. Independence. Zoological nomenclature is independent of other systems of nomenclature in that the name of an animal taxon is not to be rejected merely because it is identical with the name of a taxon that is not animal (see Article 1.1.1)

(eg Trichia, Oenanthe, Melanotus)

Myxomycetes are the exception - they're in kingdom protozoa which falls under ICZN but they fall under the ICBN name space. (Hence "Trichia").

===DNA===
You may want to consider refs to DNA sequences. They're not part of taxonomy, but they can be considered the bottom rung of the taxonomic hierarchy and they will be of increasing significance.

===Typography===
what about ''Adalia 2-punctata'', and ''Adalia bipunctata'' (not to mention those with hyphens [or apostrophes] which may get left out. And what about accented characters)?

:''Adalia 2-punctata'' is an abbreviation of ''Adalia bipunctata'', so:

:<pre><nowiki><abbr class="binominal" title="Adalia bipunctata">Adalia 2-punctata</abbr></nowiki></pre>
[[User:AndyMabbett|AndyMabbett]] 09:55, 21 Oct 2006 (PDT)

===Gaps===
The hierarchy is not always fully populated. Not every species belongs to a class. Maybe this was where fungi are different. In Paul Kirk's databases (which are the official ones used to drive the checklists and NBN) he has fixed fields for the higher level taxa which means that only certain ranks can be used. The blanks he fills in (mostly!!) with "insertae sedis" (think it's Latin for "unknown seat"). In my database I use a self-join which gives much more flexibility. Anyway there are lots of "insertae sedis" in Paul's database!

===Homonyms===
''Apion carduorum'' sensu Morris 1990 is ''Apion gibbirostre'' (Gyllenhal, 1813). ''Apion carduorum'' Kirby, 1808 is a different species.

:You'd mark the former up as something like
:<pre><nowiki><abbr class="binominal" title="Apion gibbirostre">''Apion carduorum'' sensu Morris 1990</abbr></nowiki></pre>

:[[User:AndyMabbett|AndyMabbett]] 12:21, 5 Oct 2006 (PDT)

===Citations for authorites===
If people are citing the authority in full they would include the literature reference, not just the date e.g.
:''Cuphophyllus niveus'' (Scop.) Bon, ''Doc. Mycol.'' 14(56): 11 (1985)[1984]

::Perhaps we should allow for the inclusion of an [[hcitation|hCitation]]? [[User:AndyMabbett|Andy Mabbett]] 15:08, 28 Feb 2007 (PST)

==Hyppo==
===Nomenclatural challenge===
You asked for comments. One challenge I see is the difference in Nomenclature for Animalia and Plantae (coming from the old 2 kingdom system). For Plantae the International Code of Botanical Nomenclature[http://www.bgbm.org/iapt/nomenclature/code/SaintLouis/0000St.Luistitle.htm] is used and for Animalia the code from [http://www.iczn.org/ http://www.iczn.org/]. Animalia code is not officially accepted but ICZN tries to be authoritive starting from 2008.

The two different nomenclatural systems differ in a few areas, and they affect markup.

*Subgenus (Plantae): ''Dendroceros'' subg. ''Apoceros''
*Subgenus (Animalia): ''Sula (Morus)''

*Subspecies (Plantae): ''Begonia grandis'' ssp. ''evansiana''
*Subspecies (Animalia): ''Gorilla beringei graueri''
:--[[User:Hyppo|Hyppo]] 14:23, 9 Oct 2006 (PDT)

:I would mark those up as:

:<pre><nowiki>Dendroceros subg. Apoceros</nowiki></pre>

:<pre><nowiki>Sula Morus</nowiki></pre>

:<pre><nowiki>Begonia grandis ssp. evansiana''</nowiki></pre>

:<pre><nowiki>Gorilla beringei graueri</nowiki></pre>

:With wrapping class="biota" and possibly kingdom, attributes.

:[[User:AndyMabbett|AndyMabbett]] 11:37, 10 Oct 2006 (PDT)

==Cyndy Parr==

The ideas expressed here are promising. Below are my comments on all the preceding -- as I have time I'll organize, elaborate, and try to move parts into the right discussion threads above.

In the [http://spire.umbc.edu Spire project] we have been developing ontologies in OWL for taxonomic names and hierarchies. Ideally, we'd like to have a microformat where people can tag a scientific name and an application can then check an ontology of their choice for more information (richer semantics).

We would discourage full expression of the Linnaean hierarchy except for those who are maintaining such classifications (such as uBio). The rest of the hierarchy can be retrieved ontologically as necessary.

Better to tie the scientific name (taxon name) to the authority or ontology from which it came. I.e. for those who are able to provide information on taxonomic concepts, support for TCS (Taxonomic Concept Schema) fields would be important.

I prefer "taxon" or "taxon-name" or TaxonName over biota (which is plural, and too close to biotic which has a far larger scope than taxa). Would prefer "binomial" to "binominal"
*I also favour "taxon" over "biota" simply because it the more commonly used term. I also prefer "binomial". I did a quick straw poll of various experts and all favoured binomial. Neither is technically incorrect, but binomial is more commonly used. Indeed, a Google search for binomial returns 6,580,000 results while binominal returns 342,000 and a "did you mean: binomial" prompt. --[[User:CharlesRoper|Charles Roper]] 04:12, 9 Jan 2007 (PST)
**This [http://www.googlebattle.com/index.php?domain=%22binomial+name%22+-equation&domain2=%22binominal+name%22+-equation&submit=Go%21 binomial vs. binominal Google battle] seems even more conclusive. [[User:AndyMabbett|Andy Mabbett]] 06:17, 9 Jan 2007 (PST)
"class" is difficult not only because of the confusion with the programming concept of classes, but because it is a taxonomic rank. However, most of us have figured out the difference by now so this is not critical.

"cname" should be "comname" or "common-name" or "vernacular" to make it more obvious what the information is. A sub-component would be the language for which that common name is used ( something like an HTML attribute lang="en")
*I also favour "common-name" or "vernacular" --[[User:CharlesRoper|Charles Roper]] 04:12, 9 Jan 2007 (PST)

There are known conflicts between names across kingdoms (as current codes of nomenclature allow these). Thus specification of kingdom may be encouraged. Disambiguation could be handled by applications outside the microformats (this could be difficult), or they could be dealt with in the core microformat: e.g. plant-taxon or fungal-taxon or animal-taxon.

A sightings microformat is a good idea and I would be interested in being involved in that. We've been toying with this in OWL and also using structured blogging over at http://fieldmarking.reger.com

Your terms such as gender (better: sex), age bracket (better: life stage), count, type (better: depending on the meaning, caste or morph) all belong in a specimen or sighting microformat and used in combination with the taxon microformat, not be part of it.

===Response by Andy Mabbett===
Thank you very much for your detailed contribution. I have a few responses:

*We would discourage full expression of the Linnaean hierarchy except for those who are maintaining such classifications (such as uBio).
** Why? Also, I'm not aware of any microformat which is restricted to a subset of users, nor how this would be done. How would you suggest that someone mark up this: "Not all of the Passeriformes sing"?
*** I would prefer express this something like so:
<pre><nowiki>

Passeriformes

</nowiki></pre>
Or, to simplify further:
<pre><nowiki>
Passeriformes
</nowiki></pre>
Or, at the simplest level:
<pre><nowiki>
Passeriformes
</nowiki></pre>
Simply marking up the word as a taxon would lighten the load of any parser, making its job much simpler. --[[User:CharlesRoper|Charles Roper]] 10:50, 8 Jan 2007 (PST)
***Your first example requires the author of that page to find LSID, even assuming that they know such a thing exists. How is that "paving the cowpaths"? Your latter example removes semantic detail which is included in the straw-man proposal. It is akin to removing all the children of "adr" in hCard. I think your parser-load issue is a red herring. [[User:AndyMabbett|Andy Mabbett]] 11:07, 8 Jan 2007 (PST)
**** I would argue that finding and using an LSID would not be a difficult task for any author who is using a microformat. I don't see how it is any more difficult - in fact I see it as being easier - than manually marking up ranks. Why is parser-load a red herring? --[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
***Nice example (having done my doctoral work on a Passerine that may or may not be singing...). Absolutely I'd recommending marking up "Passeriformes" but no need to go on to specify "Aves." I'm still grokking microformats so I don't think we've got a conflict. [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
****''Aves'' is available for use, but not required, so indeed, we don't have conflict ;-) [[User:AndyMabbett|Andy Mabbett]] 10:42, 10 Jan 2007 (PST)
*The rest of the hierarchy can be retrieved ontologically as necessary.
**That's a use-case once the uF is published, certainly. the proposal doesn't require that the hierarchy be marked-up, it merely allows for it, in cases where it is '''already published'''.
***I've yet to see any consistent examples of a hierarchy being marked-up using class names resembling those found in the proposal. A microformat is supposed take (and perhaps tweak, or clean up) mark-up practises that are '''already in use''', not invent new ones. In other words, microformats should pave the cowpaths. While allowing for the marking-up of the hierarchy is fair enough (I understand the reasons for wanting that option), I believe the vast majority of authors do not need that facility, or (from my own experience) do not have time or energy to make use of anything more complex than simply marking-up a piece of text as a taxonomic name. In its current state, I don't believe the current species microformat proposal fulfils any of the "philosophy of microformats" points raised in [http://ifindkarma.typepad.com/relax/2004/12/microformats.html this article]. I believe the added complexity acts as a disincentive potential users and is also clearly confusing. With taxonomic intelligence (hierarchies, synonymy, etc) being available from elsewhere (e.g. uBio), why have it embedded in the microformat? What examples of this kind of usage are there and what leads you to believe authors '''will''' use it, if it's available? [[rel-license]] is an example of a microformat that is simple and holds intelligence elsewhere. I believe simplicity is the key to a successful species microformat. --[[User:CharlesRoper|Charles Roper]] 10:50, 8 Jan 2007 (PST)
****''I've yet to see any consistent examples of a hierarchy being marked-up using class names resembling those found in the proposal.'' Perhaps not but, unlike other uFs, in taxonomy there exist clearly defined standards for the names of the components of taxonomic names. This is akin to the pre-existing class names from vCard, as used in hCard.
*****Not so: vCard is widely used standard already and thus it was a natural progression to develop hCard. There is no software based vCard equivalent of the taxonomic hierarchy in common use that I am aware of.
****''A microformat is supposed take (and perhaps tweak, or clean up) mark-up practises that are '''already in use''''' Taxonomic classes ''''are '''' already in use.[[User:AndyMabbett|Andy Mabbett]]
*****My concern still stands that there is no consistent mark-up usage that I can find.
***Fair enough [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
****''I believe the vast majority of authors [...] do not have time or energy to make use of anything more complex than simply marking-up a piece of text as a taxonomic name''' and - as has been pointed out previously, they will be able to do the latter, and nobody will force them to do the former. Why should they not, though, be able to do the latter should they wish?
*****As I say, I find the concept of allowing the full suite of ranks to be fair - I understand your desire to have them in there. I just feel that the complexity they add to the specification will put off authors and confuse them. I also maintain that very few authors will make use of this extra complexity. Should we have some sort of poll to try and determine how many people would be able to make use of the full proposal? I'm not totally against having all of the ranks in the Species microformat, I've just yet to be convinced they are necessary or conducive to adoption of the standard. --[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
****''What examples of this kind of usage are there'' Those on [[species-examples]], e.g. Wikipedia.
*****I've yet to find any consistent mark-up usage.--[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
****''[[rel-license]] is an example of a microformat that is simple and holds intelligence elsewhere'''' It holds no intelligence elsewhere, which was not already on the pre-microformatting page.[[User:AndyMabbett|Andy Mabbett]] 11:07, 8 Jan 2007 (PST)
*****The license on the end of the rel-license link is the intelligence. To look at it from a different angle, why not embed the license information within class attributes? Why not have a full license microformat, just in case some author needs it? Rel-license as it stands serves the needs of most authors most of the time, which is a fundamental philosophy of microformats.
*Better to tie the scientific name (taxon name) to the authority or ontology from which it came.
**That would require the publisher to add extra data, which they might not wish to publish, nor, indeed, have to hand. Microformats are about recognising what data is '''already''' published and then enabling people to add semantics which identify the type of data on their pages.
***I'm just suggesting support for such authority or ontology for those of us who think it important [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
****Again, the option to do so is in the current proposal. [[User:AndyMabbett|Andy Mabbett]] 10:42, 10 Jan 2007 (PST)
*[common names] A sub-component would be the language for which that common name is used (something like an HTML attribute lang="en")
**Indeed, but that's already available, and (on properly constructed pages) should already be on the parent container. [[User:AndyMabbett|Andy Mabbett]]
***Fair enough [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
*conflicts between names across kingdoms (as current codes of nomenclature allow these). Thus specification of kingdom may be encouraged.
**already in the proposal! [[User:AndyMabbett|Andy Mabbett]]
***but perhaps the proposal could be more explicit about the importance of kingdom given its important role in disambiguating species names (using a name of any other rank is less desirable given instability and required application overhead). I realize that I'm going beyond the microformat itself to "best practices" but please forgive me; I've been wrangling with taxonomic databases for a long time. [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
*Disambiguation could be handled by applications outside the microformats
**Not sure what you mean here, since all parsing is done "outside microformats". [[User:AndyMabbett|Andy Mabbett]]
***Thanks for the clarification [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)
***Another reason to make use of nameservers, rather than embedding the information within the microformat. --[[User:CharlesRoper|Charles Roper]] 10:50, 8 Jan 2007 (PST)
**** And how is enforcing the use of nameservers "paving the cowpaths"? [[User:AndyMabbett|Andy Mabbett]] 11:07, 8 Jan 2007 (PST)
*****The use of nameservers isn't enforced; it's optional (if disambiguation or further taxonomic intelligence is required). --[[User:CharlesRoper|Charles Roper]] 12:26, 8 Jan 2007 (PST)
******Agreed [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)

(I'm either in agreement with your other points, or ambivalent.)

Thank you again - do stick around. Are you on the [[mailing-lists#microformats-discuss|mailing list]]?

[[User:AndyMabbett|Andy Mabbett]] 11:06, 5 Jan 2007 (PST)

*I am now! [[User:CyndyParr|CyndyParr]] 10:20, 10 Jan 2007 (PST)

==Pengo==

Unfortunately scientific names seem to change as often as common names. I have some examples and use cases this microformat needs to address, around the problems of ambiguity:

Ambiguity 1. Ambiguous scientific names.. ''[http://en.wikipedia.org/wiki/Sousa_chinensis Sousa chinensis]'' may either refer to '''Chinese White Dolphin''' (also known as ''Sousa chinensis chinensis'') or Humpback dolphin, also known as '''''Sousa''''' (genus) which includes up to five species or subspecies of dolphin including the Chinese White Dolphin. I don't care whether the Chinese White Dolphin is a species or subspecies, but the microformat needs to allow the user to be specific about which system is being addressed.

Ambiguity 2. Another example is the [http://en.wikipedia.org/wiki/Orangutan Orangutan]... or Orangutans. Organutans were once believed to be a single species, but are now considered two separate species. The problem is that the new scientific name for just the Bornean species (''Pongo pygmaeus'') is the same as the old scientific name which encompassed both species (''Pongo pygmaeus''). Meanwhile the new scientific name for the Sumatran Orangutan (''Pongo abelii'') is always unambiguous.

Ambiguity 3. ''[http://en.wikipedia.org/wiki/Doronomyrmex_pocahontas Doronomyrmex pocahontas]'' is an ant species that probably doesn't belong in the genus ''Doronomyrmex'', but rather ''Leptothorax''. But, until a full taxonomic study of the known species of ''Doronomyrmex'' and ''Leptothorax'' is carried out, it will stay there. Meanwhile the the term "''Leptothorax'' ([http://en.wiktionary.org/wiki/sensu_stricto sensu stricto])" is used to mean "in the sense of the original author".

Use cases:
So how do we:
# tag species in new documents, where we are using the most current nomenclature in the tags, to indicate that we don't mean the old nomenclature
# tag species allowing for new nomenclature to arise which may obsolete what we're using
# tag species in old documents, where we have updated the nomenclature in the tag, but the taxt may be referring to the old nomenclature, and we want to indicate that the updated nomenclature is being used.
# tag species in [others'] documents that are tagged automatically and where the specific nomenclature being used is unknown or ambiguous
# address issues where competing nomenclatures exist side-by-side, or transition periods
# tag species that have some clues as to which nomenclature is being used, e.g. the date of publication, and the author.
# tag a taxon which is now considered paraphyletic
# decide what's out of the scope of this microformat

Brainstorm solutions:
* Allow an "old-synonym" field, which strictly lists the previous name of the species (and never a newer name). So, e.g.
<pre><nowiki>Bornean Orangutan</nowiki></pre>
* Allow the English common name to be included, when it clears ambiguity. E.g. the "Chinese White Dolphin" has always been called that, regardless of whether it was considered a species or subspecies.
* Allow a taxonomy-year field for what year the taxonomy used in the tag comes from.
* Use a UID as described by others above.
* Have an ad-hoc "disambiguation" field which could include anything to disambiguate, such as years, synonyms, "sensu stricto", common names, authors (i.e. "in the sense of this author") etc. What goes in it for a particular taxon will develop from usage.
* Have a taxonomy-uncertain="true" field to indicate it has been (for example) automatically tagged and may not be accurate, so that other suggestions can be given by 3rd party software.

Basically I don't synonyms are necessary unless they are to show that the species was previously called something else, which may help to give a more exact meaning.

Comments? Are there already existing solutions to this problem in the real world?
[[User:PeNGo|Pengo]] 19:49, 28 Jan 2007 (PST)

===Response to Pengo by Andy Mabbett===
Thank you for your expert contribution. Of your proposed solutions, the common (or vernacular) name, UID and author/ year are already in the current proposal. It may be sensible to have a "synonym" property (as used on http://en.wikipedia.org/wiki/Doronomyrmex_pocahontas), but I don't think "old-synonym" is particularly well named. Perhaps, if it's needed at all, "formerly" would be better? It is worth remembering, though, that the microformat is meant for labelling what people '''''already''''' publish and, for instance, http://en.wikipedia.org/wiki/Bornean_Orangutan refers to ''Pongo pygmaeus'', not any previous name. [[User:AndyMabbett|Andy Mabbett]] 02:20, 30 Jan 2007 (PST)
* Then most effective way to disambiguate is to use a UID. I feel other solutions would over-complicate the specification. I think we need to put some effort into populating the examples regrouped page with specific examples of publishing styles, e.g., plain binomials, plain common names, scientific names with common names, scientific names with synonyms, binomial with subspecies, etc. [[User:CharlesRoper|Charles Roper]] 05:25, 2 Feb 2007 (PST)
**There are very few exmples of UIDs being published in-the-wild. [[User:AndyMabbett|Andy Mabbett]] 06:00, 2 Feb 2007 (PST)
***I found a good source of synonym usage; see the Coleopterist's Checklist of Beetles of the British Isles: http://www.coleopterist.org.uk/checklist.htm. Look for the indented specific epithet names, e.g. in the family [http://www.coleopterist.org.uk/haliplidae-list.htm HALIPLIDAE], ''pallens'' Fowler, 1887 and ''halberti'' Bullock, 1928 are examples of synonyms, with the favoured specific epithet being ''confinis'' Stephens, 1828. On a more general note, checklists such as this are ripe for microformatting and are an excellent example of common markup practice. The species microformat could be used to great effect with content such as this, creating minable dictionaries of species names which are, in turn, essential tools in for use in biodiversity informatics. [[User:CharlesRoper|Charles Roper]] 14:43, 24 Feb 2007 (PST)
***Re. UIDs: yes, we have an interesting chicken & egg situation here. Without a reliable way to publish a UID (other than making them human readable text, which is undesirable) how are we supposed to be able to make use of them? A microformat would be a good means with which to deploy UIDs, but it is frowned upon to implement a pattern that isn't already being practised. Judging by the messages here, on the discussion list and elsewhere, there is clearly a desire for linking taxon names with UIDs, particularly LSIDs, which look set to become the standard UID for taxonomic naming. [[User:CharlesRoper|Charles Roper]] 10:41, 2 Feb 2007 (PST)
****Well, the proposal allows for the inclusion of UIDs (as with all the suggested attributes, some work on the exact format might need to be done), should people to chose to publish them; whether or not they do is not something for uFs to push for. [[User:AndyMabbett|Andy Mabbett]] 13:13, 2 Feb 2007 (PST)

==Charles Roper==
===Synonyms===
I found an interesting [http://collections2.eeb.uconn.edu/collections/insects/CTBnew/duodecimguttata.html example of synonym usage] in the [http://collections2.eeb.uconn.edu/collections/insects/CTBnew/checklist.htm Tiger Beetles of Connecticut checklist]. In the particular example cited, the synonyms refer to, or are associated with, the species name - ''Cicindela duodecimguttata'' Dejean 1825. Synonyms are often mentioned alongside or near preferred scientific names; how should we tie them together, especially when, as in this case, the name and the synonym are not positioned close to one another, but are still clearly associated? As a segue to this question, how should multiple synonymous common names be represented? How about common names in different languages? For example, the [http://names.ubio.org/browser/details.php?names=on&authors=on&sci=on&vern=on&namebankID=2478269 Otter has many different common names].

:I take it you refer to the text which may be paraphrased (by omitting some prose) as:

::'''''Cicindela duodecimguttata'' is known from 23 localities. ''Cicindela duodecimguttata'', once classified as a subspecies of ''C. repanda'', shares many traits with ''C. repanda''. Where ''C. duodecimguttata'' occurs, the more common ''C. repanda'' is usually found.'''

::'''Synonomies: ''Cicindela proteus'' Kirby 1837:9. ''Cicindela bucolica'' Casey 1913:28. ''Cicindela hudsonica'' Casey 1916:29. ''Cicindela edmontonensis'' Carr 1920:21'''

:The problem would seem to be that ''C. repanda'' is referred to both as a species in its own right, and as a past synonym of ''C. duodecimguttata''. If the whole thing is wrapped in one <code>div class="biota"</code>, allowing the other listed synonyms to be included, then how is ''C. repanda'' to be marked up as a species in its own right?

:I would mark up the first occurrence of each, then use the include-pattern to "attach" the other listed synonyms with the former (I've only included one synonym in the following, for clarity):

:<pre><nowiki>

Cicindela duodecimguttata
<object class="include" data="#C-proteus"></object>


is known from 23 localities. Cicindela duodecimguttata, once classified as a subspecies of


C. repanda


, shares many traits with C. repanda. Where C. duodecimguttata occurs, the more common C. repanda is usually found.

Synonomies:

Cicindela proteus [or maybe "synonym-binominal" ?]
Kirby
1837:9.
Cicindela bucolica Casey 1913:28. Cicindela hudsonica Casey 1916:29. Cicindela edmontonensis Carr 1920:21
</nowiki></pre>

:I might then use the its entry on the "shares many traits" line to mark up ''C. repanda'' as an synonym, and include it in the same way.

:Multiple and foreign-language common names would be catered for by allowing the common name attribute to be "0 or many" (the first such occurrence having precedence), and using a <code>lang</code> attribte where appropraite.

:[[User:AndyMabbett|Andy Mabbett]] 14:42, 28 Feb 2007 (PST)

==See also==
{{species}}

[[Category:Species]]

species-examples

2007-05-01T13:52:02Z

Gazza: Added Category

=Species Examples=

Examples of common and scientific names of living things, which could be marked up with a "'''[[species]]'''" (or similar) microformat. Note use of matching pairs of examples, where possible.

:'''Note: the original name of the proposed microformat, "species", is likely to change, probably to "biota" or "taxon". The former has been retained here, to avoid having to make many repetitive and perhaps redundant edits'''

'''If you find a link which is not working, please replace it with a suitable alternative, rather than simply deleting it. Thank you.'''

__TOC__

==Types of publishers==

There are, perhaps, three types of publisher of taxonomic information (with all the usual overlaps and exceptions one finds when generalising so much!):

#Those which publish a full or partial hierarchy, like [http://names.ubio.org/browser/classifications.php?conceptID=2463046 UBIO].
#Those which publish a binominal, or a binominal with a qualifier, like a subspecies, variety, breed, hybridisation - but still referring to a single type of living thing, with no higher- level taxonomy. e.g [http://www.westmidlandbirdclub.com/records/lists.htm the West Midland Bird Club's county lists]
#These which publish common (or "vernacular") names, but who would be interested in "aliasing" those to the scientific equivalent. e.g [http://www.westmidlandbirdclub.com/ladywalk/latest.htm the West Midland Bird Club's news from Ladywalk]

Interestingly, some sites (Wikipedia, for example) have pages which fall into each of the three categories!
#[http://en.wikipedia.org/wiki/Bar-tailed_Godwit Bar tailed Godwit]
#[http://en.wikipedia.org/wiki/Genetics_of_humans Genetics of humans]
#[http://en.wikipedia.org/wiki/Ladywalk Ladywalk]

[[User:AndyMabbett|AndyMabbett]] 12:05, 23 Oct 2006 (PDT)

==Binominals==

===Birds===

'''Black-tailed Godwit''' on [http://www.westmidlandbirdclub.com/ladywalk/latest.htm West Midland Bird Club's Ladywalk reserve latest news page]

<pre><nowiki>Black-tailed Godwit</nowiki></pre>

'''''Limosa limosa'''''
[http://www.westmidlandbirdclub.com/records/lists.htm West Midland Bird Club county lists]

<pre><nowiki>
<th scope="col">Common Name</th><th scope="col">Scientific Name</th>
[...]
<th scope="row" class="bird">Black-tailed Godwit</th><td class="sci">Limosa limosa</td>
</nowiki></pre>

'''''Eurasian Bittern'''''
[http://www.westmidlandbirdclub.com/ladywalk/BITTE.htm Bitterns at LAdywalk]

<pre><nowiki>
Eurasian Bitterns, (Botaurus stellaris)
</nowiki></pre>

===Mammal===
'''Wolf''' on [http://www.wolf.org/wolves/index.asp International Wolf Center]

'''''Canis_lupus''''' on [http://animaldiversity.ummz.umich.edu/site/accounts/information/Canis_lupus.html Animal Diversity Web]

===Fish===
'''Northern pike''' on [http://www.dnr.state.mn.us/fish/northern/index.html Minnesota Department of Natural Resources]

'''''Esox lucius''''' on [http://www.pikezander.co.uk/pike.htm Pike & Zander]

===Insect===
'''Death’s Head Hawkmoth''' on [http://funkman.org/animal/insect/deathheadmoth.html Animal Teachers]

'''''Acherontia atropos''''' on [http://ukmoths.org.uk/show.php?id=2540 UK Moths]

'''Migrant Hawker''' (''Aeshna mixta'') on [http://www.sxbrc.org.uk/news/friston-forest-recording-day Sussex Biodiversity Record Centre]

===Arachnid===
'''Rose Trantula''' on [http://www.practical-pet-care.com/spider_question.php?ID=1.2006100416232172 Pet Care Forum]

'''''Araneus angulatus''''' on [http://www.sxbrc.org.uk/news/friston-forest-recording-day Sussex Biodiversity Record Centre] (this is a duplicate. [[User:BenWest|BenWest]] 21:56, 21 Oct 2006 (PDT))

===Plant===
'''Bog Pimpernel''' on [http://www.map-reading.co.uk/wildflowers/HTML%20files/f0219.htm Map Reading's Wildflower Images]

'''''Anagallis tenella''''' on [http://www.bioimages.org.uk/HTML/T47624.HTM BioImages]

'''''Persicaria campanulatum''''' on [http://www.record-lrc.co.uk/?Mod=Forum&Do=ViewThread&ForumID=6&ThreadID=75 rECOrd - The Biodiversity Information Centre for the Cheshire region]

'''''Galeopsis tetrahit s.s.'''''
[http://www.westmidlandbirdclub.com/blithfield/plants20060815.htm West Midland Bird Club]
<pre><nowiki>
Galeopsis tetrahit 
<abbr lang="la" title="sensu stricto">s.s.</abbr>

(Common Hemp-nettle)
</nowiki></pre>

===Fungi===

'''''Amanita muscaria''''' on [http://www.mykoweb.com/CAF/species/Amanita_muscaria.html California Fungi]
* as '''''Amanita muscaria'' (L. per Fr.) Hooker'''
* as '''''Amanita muscaria var. flavivolvata'''''

'''Fly Agaric''' on [http://www.treesforlife.org.uk/forest/mythfolk/flyagaric.html Trees for Life]

'''''Rhodocollybia maculata'' (Albertini & Schweinitz: Fries) Singer''' on [http://www.ilmyco.gen.chicago.il.us/Taxa/Rhodomacul540.html]
*also written as '''''Rhodocollybia maculata'' (Albertini & Schweinitz ex Fries) Singer'''
*(This is where a post-Linnean author is given special rights (because his descriptions were comparatively complete - i.e. recognisable) so his interpretation of earlier names is taken as the sense meant by the original author. Think these used to be "apud" and are now "ex" although a colon has also been used. There are only a few sanctioning authors, the main one being Elias Fries.(Fr.) )

==More than binominals==

===Authority===
'''''Pica pica'' Linnaeus, (1758)''' on [http://en.wikipedia.org/wiki/European_Magpie Wikipedia: European Magpie]
:(i.e. named by Linnaeus in 1758)

'''''Anarhynchus frontalis'' Quoy and Gaimard, 1830''' on [http://en.wikipedia.org/wiki/Wrybill Wikipedia: Wrybill]
:note two-person authority

===Unspecified species===
'''''Podiceps sp.''''' on [http://www.birdlife.org/datazone/species/index.html?action=SpcHTMDetails.asp&sid=3644&m=0 Bird Life] <pre><nowiki>Podiceps sp.</nowiki></pre>

'''Psyllid plant hopper''' [http://ramblingsofanaturalist.blogspot.com/2006/07/bay-sucker-gall-trioza-alacris.html on Ramblings of a Naturalist blog]

===Sub-species===

====Animal====
'''''Larus glaucoides kumlieni''' on [http://www.birdguides.com/html/vidlib/species/Larus_glaucoides_kumlieni.htm BirdGuides]

'''Kumlien's Gull''' on [http://www.birdsireland.com/pages/rare_bird_news/2005/january_photos.html Birds Ireland]

====Plant====
'''''Pisum sativum L. subsp. sativum''''' on [http://www.plantnames.unimelb.edu.au/Sorting/Pisum.html] (also has other examples; note lack of required italics)
<pre><nowiki>Pisum sativum L. subsp. sativum</nowiki></pre>

===Cultivars (plant)===
'''''Chamaecyparis lawsoniana 'Aureomarginata'''''' on [http://en.wikipedia.org/wiki/Cultivar Wikipedia: Cultivar]

<pre><nowiki><dd>Chamaecyparis lawsoniana 'Aureomarginata'</dd></nowiki></pre>

'''''Chamaecyparis lawsoniana'' 'Golden Wonder'''' on [http://www.plantago.nl/plantindex/c/Chamaecyparis/Chamaecyparis_4.htm plantago.nl]

====Cultivar groups (plant)====
'''''Brassica oleracea'' Botrytis Group''' on [http://en.wikipedia.org/wiki/Cultivar Wikipedia: Cultivar]

===Trade names (plant)===

'''''Rosa'' Peace''' on [http://en.wikipedia.org/wiki/Cultivar Wikipedia: Cultivar]
:("Peace" is a trade designation or "selling name" for the cultivar R. 'Madame A. Meilland' and should therefore be printed in a different typeface from the rest of the name, without any quote marks)

'''Sunflower 'Giant Single'''' on [http://cgi.www.johnsons-seeds.com/cgi-bin/www.johnsons-seeds.com/detail/azlist/S-1 Johnsons Seeds]

'''Sunflower 'Infrared' F1''' on [http://cgi.www.johnsons-seeds.com/cgi-bin/www.johnsons-seeds.com/detail/azlist/S-1 Johnsons Seeds]
:(Note "F1" cross designation)

===Variety (plant)===
'''''Pisum sativum var. macrocarpon''''' on [http://davesgarden.com/pf/go/8/index.html Dave's Garden]

====Sub-variety (plant)====

'''''Betula ermani var. genuina subvar. brevidentata''''' on [http://www.nccpg.com/gloucestershire/wilson1.html National Council for the Conservation of Plants and Gardens, Gloucestershire Group] (plus many other examples)

===Form (plant)===

'''''Acanthocalycium spiniflorum f. klimpelianum''''' on [http://en.wikipedia.org/wiki/Form_%28botany%29 Wikipedia: form (botany)]
*aka '''''Acanthocalycium spiniflorum forma klimpelianum'''''

===Sense (plant)===
'''''Ranunculus aquatilis s.l.''''' and '''''R. aquatilis s.s'''''; on [http://www.westmidlandbirdclub.com/blithfield/plants20060815.htm Blithfield Reservoir: Survey of Flowering Plants...] (see also footnotes on that page)

===Cross (plant)===
'''''Digitalis x mertonensis''''' on [http://www.hortax.org.uk/gardenplantsnames.html Hortax]
:The hybrid name for all plants derived from the cross between '''D. purpurea''' and '''D. grandiflora'''. The "x" indicates the hybrid status.

'''''× Fatshedera lizei''''' on [http://oregonstate.edu/dept/ldplants/sci-names.htm Scientific Plant Names, Oregon State Univ., Landscape Plants]

===Strain (bacteria)===
'''''Escherichia coli O157:H7''''' on [http://www.cfsan.fda.gov/~mow/chap15.html FDA.gov]

'''''E.Coli''''' on [http://news.bbc.co.uk/1/hi/england/southern_counties/5346842.stm BBC news]

===Synonyms===
[http://en.wikipedia.org/wiki/Tarpan The Tarpan], '''''Equus ferus ferus''''':
<blockquote>The Tarpan was first described by Johann Friedrich Gmelin in 1774; he had seen the animals in 1769 in the region of Bobrovsk, near Voronezh. In 1784 Pieter Boddaert named the species '''''Equus ferus''''', referring to Gmelin's description. Unaware of Boddaert's name, Otto Antonius published the name '''''Equus gmelini''''' in 1912, again referring to Gmelin's description. Since Antonius' name refers to the same description as Boddaert's it is a junior objective synonym.</blockquote>

on http://www.westmidlandbirdclub.com/biblio/bb/71-338.htm:
<blockquote>some authors still refer to Scandinavian Herring Gulls as '''''L. a. omissus'''''; others regard '''''omissus''''' as no longer valid (a synonym of '''''argentatus''''')</blockquote>

On http://en.wikipedia.org/wiki/Devario_chrysotaeniatus:

:'''''Devario chrysotaeniatus''''' [...] former Names and Synonyms
::* '''''Danio chrysotaeniatus'''''

On http://en.wikipedia.org/wiki/Tetracanthus:

:'''''Echinocactus tetracanthus''''' synonym of '''''Parodia erinacea''''' - cactus

On http://en.wikipedia.org/wiki/Jostia_teaguei (using a "taxobox")

:Binomial name
:'''''Jostia teaguei'''''
:(Luer) Luer
:Synonyms
:'''''Masdevallia teaguei''''' Luer, 1978

On http://www.coleopterist.org.uk/haliplidae-list.htm

:'''HALIPLUS''' Latreille, 1802
:Subgenus HALIPLUS Latreille, 1802
:''confinis'' Stephens, 1828
::''pallens'' Fowler, 1887
::''halberti'' Bullock, 1928

i.e. ''Haliplus pallens'' and ''H. halberti'' are synonyms of ''H. confinis''.

See also [http://en.wikipedia.org/wiki/Special:Search?search=species+synonym&fulltext=Search Wkipedia search for "species synonym"]

==Misc==
===Superseded names===
'''''Tringa bartramia''''' superseded by '''''Bartramia longicauda''''' on [http://www.westmidlandbirdclub.com/firsts/UPLSA.htm West Midland Bird Club's Upland Sandpiper article]

===GUID===
'''NBN Taxon Key''' for European Otter, ''Lutra lutra'', on [http://nbn.nhm.ac.uk/nhm/bin/nbntaxa.dll/taxon_details?taxon_key=NBNSYS0000005133 NBN Species Dictionary]: '''NBNSYS0000005133'''

'''LSID ([http://lsid.sourceforge.net/#whatislsid Life Science Indicator])''' for ''Popillia japonica'' on [http://names.ubio.org/browser/details2.php?names=on&authors=on&sci=on&vern=on&conceptID=&expand=&namebankID=3377001 uBio]: '''urn:lsid:ubio.org:namebank:3377001'''

===Wikipedia===
'''Black-tailed Godwit''' on [http://en.wikipedia.org/wiki/Black-tailed_Godwit Wikipedia: Black-tailed Godwit]

Wikipedia uses several sets of markup, e.g. (in-line styles and links, plus some other markup, removed, for clarity):

<pre><nowiki>The Black-tailed Godwit, Limosa limosa</nowiki></pre>

====Linking====
Wikipedia uses the standard convention of having species italicised. Internal links to species may be to the common name or scientific name depending on which is used as the article's title (usually common for animals, scientific for plants, although there are exceptions). Links to scientific names work regardless:

<pre><nowiki>''[[Limosa limosa]]''</nowiki></pre>

Link to common name:

<pre><nowiki>[[Black-tailed Godwit]]</nowiki></pre>

Link to common name, but displaying scientific name:

<pre><nowiki>''[[Black-tailed Godwit|Limosa limosa]]''</nowiki></pre>

These types of links are not used in the Black-tailed Godwit article itself, but in others related to it. e.g. [http://en.wikipedia.org/wiki/British_avifauna British avifauna]

====Taxobox====

Wiki markup for the taxobox (taxonomy infobox) on the English Wikipedia, as used on the Black-tailed Godwit article, with irrelevant fields removed:

<pre><nowiki>
{{Taxobox
| name = Black-tailed Godwit
| regnum = [[Animal]]ia
| phylum = [[Chordate|Chordata]]
| classis = [[bird|Aves]]
| ordo = [[Charadriiformes]]
| familia = [[Scolopacidae]]
| genus = ''[[Godwit|Limosa]]''
| species = '''''L. limosa'''''
| binomial = ''Limosa limosa''
| binomial_authority = ([[Carolus Linnaeus|Linnaeus]], 1758)
}}
</nowiki></pre>

Above is vaguely displayed in an HTML table as (with formatting and links removed):

<pre><nowiki>
<tr>
<td>Kingdom:</td>
<td>Animalia</td>
</tr>
<tr>
<td>Phylum:</td>
<td>Chordata</td>
</tr>
<tr>
<td>Class:</td>
<td>Aves</td>
</tr>
<tr>
<td>Order:</td>
<td>Charadriiformes</td>
</tr>
<tr>
<td>Family:</td>
<td>Scolopacidae</td>
</tr>
<tr>
<td>Genus:</td>
<td>Limosa</td>
</tr>
<tr>
<td>Species:</td>
<td>L. limosa</td>
</tr>

<tr>
<th>binominal name</th>
</tr>
<tr>
<td>Limosa limosa
<td>(Linnaeus, 1758)</td>
</tr>
</nowiki></pre>

Also allows for other levels of taxonomy (e.g. genus or subspecies), and synonyms.

==Quantitative evidence==

For evidence of quantitative, rather than qualitative, use of species' and other taxonomic names, see [[species-examples-quantitative]]

==Notable websites==
These high-profile websites use species names

*Amazon
**[http://www.amazon.co.uk/s/?url=search-alias%3Daps&field-keywords=%22house+sparrow%22 search for "House Sparrow"]

*BBC News
**[http://news.bbc.co.uk/1/hi/uk/4835208.stm Fewer birds spotted in UK gardens]
**[http://news.bbc.co.uk/1/hi/england/london/4743250.stm Study to solve sparrow's decline riddle]

*Encyclopaedia Britannica - all species, e.g.
**[http://concise.britannica.com/ebc/article-9379473/starling Starling]

*Flickr
**[http://www.flickr.com/photos/tags/citheronia/ Tag for moth genera 'citheronia']
***[http://www.flickr.com/photos/30268343@N00/152101772/ Sample result from that search]
**[http://www.flickr.com/groups/birdguide/ Field Guide: Birds of the World] 23,073 tagged photos, as at 2006-10-21

*CNN
**[http://archives.cnn.com/2001/NATURE/01/24/dying.eagles/ Disease threatens bald eagle population]

*eBay
**[http://search.ebay.com/house-sparrow search for "House Sparrow"]

*The Guardian
**[http://environment.guardian.co.uk/conservation/story/0,,1878956,00.html The call of the wildlife]
**[http://education.guardian.co.uk/higher/news/story/0,,1665396,00.html Sparrow joins 'raped' duck in Dutch museum] (note improper capitalisation "''passer domesticus''")

*The Internet Movie Database
**[http://www.imdb.com/title/tt0029443/ Private Life of the Gannets]
***[http://www.imdb.com/title/tt0029443/trivia Private Life of the Gannets trivia page with binominal]
**[http://www.imdb.com/title/tt0133318/ The Trials of Life]
**[http://www.imdb.com/title/tt0227812/ Whooping Crane]
***[http://www.imdb.com/title/tt0227812/trivia Whooping Crane trivia page with binominal]
**[http://www.imdb.com/title/tt0301727/ Winged Migration]

*London Zoo
**[http://www.zsl.org/london-zoo/animals/birds/tawny-frogmouth,99,AN.html Tawny frogmouth]

*Microsoft
**[http://www.microsoft.com/games/zootycoon/zoo2/zoo2_ymi_animals1.asp Zoo Tycoon]

*MSN-Encarta - all species, e.g.
**[http://encarta.msn.com/encnet/refpages/search.aspx?q=vulgaris&Submit2=Go Search for "vulgaris"]

*MySpace
**[http://blog.myspace.com/index.cfm?fuseaction=blog.view&friendID=47134278&blogID=79591637]

*Nature
**[http://www.nature.com/nature/focus/avianflu/index.html Avian flu web focus]

*Nature Network, Boston
**[http://network.nature.com/boston/news/archive/2006/06/13/the-student-and-the-squid The student and the squid] '''N.B.''' site already supports rel-tag, hCard for user profiles and hCalendar for marking up events across the site.

*NASA
**[http://history.nasa.gov/SP-401/ch3.htm SP-401 Skylab, Classroom in Space. Part II - Student Experiments] ("The common Cross spider (Araneus diadematus)")

*New York Times
**[http://query.nytimes.com/gst/fullpage.html?sec=travel&res=9D04E4DE1131F93BA25751C0A9669C8B63 Where the Eagles Fly: Seeing the National Symbol]

*Sky News
**[http://news.sky.com/skynews/article/0,,15410-1249430,00.html Homo floresiensis]
**[http://news.sky.com/skynews/article/0,,30200-13546024,00.html Atlapetes latinuchus yariguierum]
**[http://news.sky.com/skynews/picture_gallery/picture_gallery/0,,15410-1244699,00.html Polypedates chlorophthalmus]
**[http://search.sky.com/search/skynews/results/1,,,00.html?CID=30000&QUERY=species&SITEREF=skynews&SECTION=&TYPE_REF=&radiodate=&dayFrom=dd&monthFrom=mm&yearFrom=yyyy&dayTo=dd&monthTo=mm&yearTo=yyyy&Submit.x=0&Submit.y=0 Sky News search for "species"]

*Snopes (Urban Legends Reference Pages)
**[http://www.snopes.com/photos/animals/fishfly.asp Fish Fly]

*United Kingdom Government
**[http://www.defra.gov.uk/wildlife-countryside/vertebrates/gen-licence.htm DEFRA: General licences under the Wildlife & Countryside Act 1981]

*United Nations
** [http://www.oceansatlas.org/ Atlas of the Oceans] e.g. [http://www.oceansatlas.org/world_fisheries_and_aquaculture/html/resources/capture/mainspec/species/sp2605.htm Chilean nylon shrimp ''Heterocarpus reedi'']

*United States of America Government
**ITIS, e.g. [http://www.itis.usda.gov/servlet/SingleRpt/SingleRpt?search_topic=TSN&search_value=179628 Passer Domesticus] - "authoritative taxonomic information on plants, animals, fungi, and microbes of North America and the world"

*W3C
**[http://dev.w3.org/cvsweb/2000/10/swap/test/ferrell/biology.n3?rev=1.4 An Ontology of Biology]
**[http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/Reagents/Status_Reports/2006-05-04 BioRDF Sub-group Status Report, 4 May 2006]

*Yahoo Groups
**[http://tech.groups.yahoo.com/group/passerdomesticus/ passerdomesticus] species as group name!

*YouTube
**[http://www.youtube.com/results?search_query=starling&search=Search YouTube search for 'starling']]

==Breaking news==
In under two weeks, the BBC News website carried the following stories, all including the scientific names of species:
*[http://news.bbc.co.uk/1/shared/spl/hi/pop_ups/06/sci_nat_orchid_spectacular/html/1.stm BBC News: Stunning new orchids from Asia's rainforest] - 2006-10-16
*[http://news.bbc.co.uk/1/hi/sci/tech/6045802.stm BBC News: Winter home find cheers twitchers] (winter home of the northern bald ibis found) - 2006-10-13
*[http://news.bbc.co.uk/1/hi/sci/tech/6043648.stm BBC News: New mouse find is 'living fossil'] - 2006-10-12
*[http://news.bbc.co.uk/1/hi/sci/tech/6035113.stm BBC News: Giant camel fossil found in Syria] - 2006-10-10
*[http://news.bbc.co.uk/1/hi/sci/tech/5414410.stm BBC News: Sharks swim into political waters] - 2006-10-06
*[http://news.bbc.co.uk/1/hi/sci/tech/5403570.stm BBC News: 'Monster' fossil find in Arctic] - 2006-10-05

==Use in blogs==
*[http://technorati.com/search/%22passer%20domesticus%22 Technorati search for "Passer domesticus"] (367 found, as at 2006-09-25)
*[http://technorati.com/search/%22acer%20palmatum%22 Technorati search for "Acer palmatum"] (682 found, as at 2006-09-25)
*[http://technorati.com/search/%22Homo%20sapiens%22 Technorati search for "Homo sapiens"] (40,932 found, as at 2006-09-25)
*[http://technorati.com/search/birding Technorati search for "birding"] (26,472 found, as at 2006-09-25)
*[http://ramblingsofanaturalist.blogspot.com/ Ramblings of a Naturalist]
*[http://squaremetre1.blogspot.com/ The Square Metre]
*[http://windowboxwildlife.blogspot.com/index.html Windowbox Wildlife]
*[http://www.rxwildlife.org.uk/ RXWildlife]
*[http://newsbou.blogspot.com/ British Ornithologists' Union news]
*[http://fieldmarking.reger.com/ FieldMarking] - An experiment to see how people can collaborate to record wildlife observations in blogs.

==And finally...==
Gary Larson, in his book ''The Far Side Gallery'' (Warner Books, 1980, ISBN 0751502367) has a cartoon, showing two entomologists sitting down to eat dinner in a jungle. One says to the other "Hey! What's this ''Drosophila melanogaster'' doing in my soup?"

==Contributors==
*[[User:AndyMabbett|Andy Mabbett]] (proponent)
*Malcolm Storey (per e-mail)
*[[User:SXBRC|Charles Roper]], [http://www.sxbrc.org.uk/ Sussex Biodiversity Record Centre] (proponent)
*[[User:SteveMcBill|Steve McWilliam]], [http://www.rECOrd-LRC.co.uk/ rECOrd - The Biodiversity Information System for the Cheshire region] (proponent)
*[[User:PeNGo|Peter Halasz]], Wikipedia Admin.

==See also==
{{species}}

[[Category:Species]]

species-examples-regrouped

2007-05-01T13:51:14Z

Gazza: a

This is a re-grouping of the examples on [[species-examples]]

:'''Note: the original name of the proposed microformat, "species", is likely to change, probably to "biota" or "taxon". The former has been retained here, to avoid having to make many repetitive and perhaps redundant edits'''

== Grouped By Publisher ==

=== West Midland Bird Club ===
* [http://www.westmidlandbirdclub.com/ladywalk/latest.htm Black-tailed Godwit]
<pre><nowiki>Black-tailed Godwit</nowiki></pre>

* [http://www.westmidlandbirdclub.com/records/lists.htm Limosa limosa ]
<pre><nowiki>
<th scope="col">Common Name</th><th scope="col">Scientific Name</th>
[...]
<th scope="row" class="bird">Black-tailed Godwit</th><td class="sci">Limosa limosa</td>
</nowiki></pre>

* [http://www.westmidlandbirdclub.com/ladywalk/BITTE.htm Eurasian Bittern]
<pre><nowiki>
Eurasian Bitterns, (Botaurus stellaris)
</nowiki></pre>

* [http://www.westmidlandbirdclub.com/blithfield/plants20060815.htm Galeopsis tetrahit s.s.]
<pre><nowiki>
Galeopsis tetrahit <abbr lang="la" title="sensu stricto">s.s.</abbr> (Common Hemp-nettle)
</nowiki></pre>

* [http://www.westmidlandbirdclub.com/ladywalk/index.htm Ladywalk]
<pre><nowiki>
The shallow scrapes are now home to many dragonflies and damselflies
</nowiki></pre>

* Comments
** Occurrences of common bird names are consistently bolded and given a class of "bird". Occurrences of scientific names are consistently italisized and given a class name of "sci". Common plant names are bolded and given a class name of "plant". In the last example, common insect names (in this case at the order rank) are tagged with . - [[User:CharlesRoper|Charles Roper]]

=== species.mediawiki.org ===
[http://species.wikimedia.org/wiki/Charadrius_dubius species.mediawiki.org media bird ] .
<pre><nowiki>
<dd>Regnum: <a href="/wiki/Animalia" title="Animalia">Animalia</a> (Metazoa)
<dl>
<dd>Subregnum: <a href="/wiki/Eumetazoa" title="Eumetazoa">Eumetazoa</a>
<dl>
<dd>Superphylum: Bilateria: <a href="/wiki/Deuterostomia" title="Deuterostomia">Deuterostomia</a>
<dl>
<dd>Phylum: <a href="/wiki/Chordata" title="Chordata">Chordata</a>
<dl>

<dd>Subphylum: <a href="/wiki/Vertebrata" title="Vertebrata">Vertebrata</a>
<dl>
<dd>Classis: <a href="/wiki/Aves" title="Aves">Aves</a>
<dl>
<dd>Subclassis: <a href="/wiki/Neognathae" title="Neognathae">Neognathae</a>
<dl>
<dd>Ordo: <a href="/wiki/Charadriiformes" title="Charadriiformes">Charadriiformes</a>
<dl>
<dd>Subordo: <a href="/wiki/Charadrii" title="Charadrii">Charadrii</a>

<dl>
<dd>Familia: <a href="/wiki/Charadriidae" title="Charadriidae">Charadriidae</a>
<dl>
<dd>Subfamily: <a href="/wiki/Charadriinae" title="Charadriinae">Charadriinae</a>
<dl>
<dd>Genus: <a href="/wiki/Charadrius" title="Charadrius">Charadrius</a>
<dl>
<dd>Species: Charadrius dubius
<dl>

<dd>Subspecies: <a href="/w/index.php?title=Charadrius_dubius_curonicus&action=edit" class="new" title="Charadrius dubius curonicus">C. d. curonicus</a> - <a href="/w/index.php?title=Charadrius_dubius_dubius&action=edit" class="new" title="Charadrius dubius dubius">C. d. dubius</a> - <a href="/w/index.php?title=Charadrius_dubius_jerdoni&action=edit" class="new" title="Charadrius dubius jerdoni">C. d. jerdoni</a> - <a href="/w/index.php?title=Charadrius_dubius_papuanus&action=edit" class="new" title="Charadrius dubius papuanus">C. d. papuanus</a></dd>

...
</nowiki>
</pre>

* Comments
** This feels similar to tagging to me. This particular example has a resolves the whole heirarchy, correct? [[User:BenWest|BenWest]] 17:57, 21 Oct 2006 (PDT)
*** In what way is it similar to tagging? Your question cannot be parsed. [[User:AndyMabbett|AndyMabbett]] 04:10, 22 Oct 2006 (PDT)

=== International Wolf Center ===

[http://www.wolf.org/wolves/index.asp Wolf Example]
* Comments
** The word "wolf" appears all over, a brief look only revealed "delist
wolves" as more resolution in some free text. Is this a good example of how
species data is marked up on the web? [[User:BenWest|BenWest]] 22:20, 21 Oct 2006 (PDT)

=== Minnesota Department of Natural Resources ===
[http://www.dnr.state.mn.us/fish/northern/index.html Northern Pike Example]

<pre><nowiki>
<h1 class="last">Northern pike</h1>
</nowiki></pre>

=== Pike & Zander ===

[http://www.pikezander.co.uk/pike.htm Pike & Zander]
<pre><nowiki>
The Pike is known worldwide, a species of the family Esocidae...
</nowiki>
</pre>
<pre><nowiki>
In Europe and Asia, Esox lucius had to...
</nowiki></pre>
* Comments
** Free text, in paragraph elements.

=== funkman.org ===
[http://funkman.org/animal/insect/deathheadmoth.html Death's Head Hawkmoth Example]
Free text in paragraph elements.

=== UK Moths ===
[http://ukmoths.org.uk/show.php?id=2540 Acherontia atropos]
<pre><nowiki>
Acherontia atropos
</nowiki></pre>
<pre><nowiki>
<div id="title">Sphingidae: Sphinginae</div>
</nowiki></pre>
<pre><nowiki>
(Solanum tuberosum)
</nowiki></pre>

[http://ukmoths.org.uk/cirsiumkey.php Cirsium arvense Key]
<pre><nowiki>
Key to leaf-feeding micro-moth larvae on creeping thistle (Cirsium arvense)
</nowiki></pre>

<pre><nowiki>
1076 <a href="show.php?bf=1076">Celypha lacunana</a>. A very common polyphage, but too many varieties to include.
</nowiki></pre>
<pre><nowiki>
1380 <a href="show.php?bf=1380">Phlyctaenia perlucidalis</a>. No larval description or photographs available Feb. 2004. 
</nowiki></pre>
<pre><nowiki>
814a Scrobipalpa pauperella. No larval description or photographs available Feb. 2004.
</nowiki></pre>

* Comments
** Use of to italicize. Use of scientific names and latin. [[User:BenWest|BenWest]] 22:20, 21 Oct 2006 (PDT)
** Again, two next to last examples look like tagging. [[User:BenWest|BenWest]] 22:20, 21 Oct 2006 (PDT)

=== Sussex Biodiversity Record Centre ===

[http://www.sxbrc.org.uk/news/friston-forest-recording-day Migrant Hawker (''Aeshna mixta'')]
<pre><nowiki>
include a White Admiral (Limenitis camilla), an <a href="http://www.britishspiders.org.uk/html/nbn.php?spn=375">Araneus angulatus</a>,
</nowiki></pre>

All common names are in strong elements, the species is in an italic element,
with resolution as link text, which turns out to be a fairly consistent
convention on this particular site.

* Comments
** Again, some part of the resolution is the link text to a resource presumably considered authoritative. Resembles tagging. This particular site also puts common names in a strong tag, with the species in an italic tag.
*** No, it's not necessarily an authoritative resource; it's just a link to a site I consider ''useful'' for those seeking further information on this species. - [[User:CharlesRoper|Charles Roper]]
** The use of an italicized scientific name is a very common convention, particularly in printed media but also online. The use of strong names is also a common convention, particularly online, as it helps readers scan a page quickly for species they are interested in. Further examples of this convention can be found here:
*** [http://www.sos.org.uk/ Sussex Ornithological Society]
*** [http://www.rxwildlife.org.uk/ RXWildlife weblog]
*** [http://ramblingsofanaturalist.blogspot.com/ Ramblings of a Naturalist weblog]. This site also has examples of italicizing scientific names.
[[User:CharlesRoper|Charles Roper]]

=== WildRye.info ===
[http://www.wildrye.info/recent-sightings/september-2006 Temmick's Stint]
<pre><nowiki>Bird highlight during September was a Temminck’s Stint (below)</nowiki></pre>

[http://www.wildrye.info/reserve/wildlife/moths.php Pinion-streaked Snout Schrankia costaestrigalis]
<pre><nowiki>Pinion-streaked Snout Schrankia costaestrigalis</nowiki></pre>

[http://www.wildrye.info/reserve/wildlife/moths.php Festoon A. limacodes]
<pre><nowiki>Festoon A. limacodes</nowiki></pre>

* Comments
** This site uses the common bold common name/italisized scientific name pattern. Of note is the last example which uses an abbreviated genus (A.) --[[User:CharlesRoper|Charles Roper]] 01:23, 24 Oct 2006 (PDT)
** "<nowiki></nowiki>" and "<nowiki></nowiki>" should not be used (according to a lengthy debate on a web authoring forum some time ago), because text thus marked will be emphasised/ "shouted" verbally in an aural browser or text reader. Either <nowiki></nowiki>/ <nowiki></nowiki> should be used, or a style with italicised/ heavier-font-weight text, or both (the later happens on the West Midland Bird Club website). [[User:AndyMabbett|Andy Mabbett]] 01:30, 24 Oct 2006 (PDT)
*** I agree regarding the use of over as the italisizing of a scientific name is not necessarily an emphasis. However, I believe the use of is valid as the intent is to emphasise the content, drawing the reader's eye. I see no problem with strong content being emphasised aurally. I am comfortable with the use of tags for scientific names as they are often referred to a Latin names (even though they are not necessarily Latin) and could be considered a form of ''[http://en.wikipedia.org/wiki/Italic_languages Italic language]'' --[[User:CharlesRoper|Charles Roper]] 09:49, 24 Oct 2006 (PDT)
****There is no "reader's eye" in an aural browser or text reader! Try reading a page with such names emboldened and speaking "strongly" (i.e. raising your voice slightly) each time you say one. Preferably in a busy office ;-) [[User:AndyMabbett|Andy Mabbett]] 10:58, 24 Oct 2006 (PDT)
*****True, there is no reader's eye, but aural properties can be [http://www.w3.org/TR/CSS-access#ACSS styled with CSS]. Better to use stylesheets to change the style of the content rather than demand a change in markup. Remember, microformats are supposed to be based on existing markup practices where possible. --[[User:CharlesRoper|Charles Roper]] 03:28, 31 Oct 2006 (PST)
******How widely supported is aural styling? And yes, you're right about existing mark-up practices; but I was explaining why those practices are wrong, not that uFs should change them. [[User:AndyMabbett|AndyMabbett]] 06:25, 31 Oct 2006 (PST)

===To do===
TODO: remove, or at least
coalesce free text examples. create a commonalities section. [[User:BenWest|BenWest]] 22:20, 21 Oct 2006 (PDT)
TODO:
I've been working down the examples list, item by item to
reorganize by publisher, like the other *-examples pages have done. So far,
I've gone from the top of binominals to the top of the Plant section. It's a
Saturday night and time to have some fun so.... If someone continues this work
before I get a chance to continue, please note where you left off. [[User:BenWest|BenWest]] 22:20, 21 Oct 2006 (PDT)

== Alternative Grouping By Strategy ==
I'd like to regroup these examples... perhaps by publishing strategy instead of a list of what is being published. Should this be available as an alternate grouping section? In the mean time, a grouping by publisher would help analysis go smoother. [[User:BenWest|BenWest]] 17:57, 21 Oct 2006 (PDT)

I looked at several examples. Several of them feel like tagging to me. Should we attempt to note what level or resolution is available in each example?

=== Tagging ===
The [[http://species.wikimedia.org/wiki/Charadrius_dubius wiki media bird example]] is particularly interesting.
<pre><nowiki>
<dd>Regnum: <a href="/wiki/Animalia" title="Animalia">Animalia</a> (Metazoa)
<dl>
<dd>Subregnum: <a href="/wiki/Eumetazoa" title="Eumetazoa">Eumetazoa</a>
<dl>
<dd>Superphylum: Bilateria: <a href="/wiki/Deuterostomia" title="Deuterostomia">Deuterostomia</a>
<dl>
<dd>Phylum: <a href="/wiki/Chordata" title="Chordata">Chordata</a>
<dl>

<dd>Subphylum: <a href="/wiki/Vertebrata" title="Vertebrata">Vertebrata</a>
<dl>
<dd>Classis: <a href="/wiki/Aves" title="Aves">Aves</a>
<dl>
<dd>Subclassis: <a href="/wiki/Neognathae" title="Neognathae">Neognathae</a>
<dl>
<dd>Ordo: <a href="/wiki/Charadriiformes" title="Charadriiformes">Charadriiformes</a>
<dl>
<dd>Subordo: <a href="/wiki/Charadrii" title="Charadrii">Charadrii</a>

<dl>
<dd>Familia: <a href="/wiki/Charadriidae" title="Charadriidae">Charadriidae</a>
<dl>
<dd>Subfamily: <a href="/wiki/Charadriinae" title="Charadriinae">Charadriinae</a>
<dl>
<dd>Genus: <a href="/wiki/Charadrius" title="Charadrius">Charadrius</a>
<dl>
<dd>Species: Charadrius dubius
<dl>

<dd>Subspecies: <a href="/w/index.php?title=Charadrius_dubius_curonicus&action=edit" class="new" title="Charadrius dubius curonicus">C. d. curonicus</a> - <a href="/w/index.php?title=Charadrius_dubius_dubius&action=edit" class="new" title="Charadrius dubius dubius">C. d. dubius</a> - <a href="/w/index.php?title=Charadrius_dubius_jerdoni&action=edit" class="new" title="Charadrius dubius jerdoni">C. d. jerdoni</a> - <a href="/w/index.php?title=Charadrius_dubius_papuanus&action=edit" class="new" title="Charadrius dubius papuanus">C. d. papuanus</a></dd>

...
</nowiki>
</pre>
This feels similar to tagging to me. This particular example has a resolves the whole heirarchy, correct? [[User:BenWest|BenWest]] 17:57, 21 Oct 2006 (PDT)

==See also==
{{species}}

[[Category:Species]]

species-examples-quantitative

2007-05-01T13:50:53Z

Gazza: Added Category

=Species Examples (Quantitative )=

Quantitative examples of common and scientific names of living things, which could be marked up with a "'''[[species]]'''" (or similar) microformat.

:'''Note: the original name of the proposed microformat, "species", is likely to change, probably to "biota" or "taxon". The former has been retained here, to avoid having to make many repetitive and perhaps redundant edits'''

'''If you find a link which is no longer working, please replace it with a suitable alternative, rather than simply deleting it. Thank you.'''

__TOC__

==Evidence==

For earlier evidence of quantitative use of species' and other taxonomic names, see
[http://microformats.org/discuss/mail/microformats-discuss/2006-September/005790.html] and [http://microformats.org/discuss/mail/microformats-discuss/2006-September/005791.html]. Furthermore:

*Wikipedia:
** '''All''' species articles, e.g. [http://en.wikipedia.org/wiki/Little_Ringed_Plover Little Ringed Plover] (see [[species-examples#Wikipedia|above]])
** '''All''' genera articles, e.g. [http://en.wikipedia.org/wiki/Plover Charadrius (Plover)] (e.g [http://en.wikipedia.org/wiki/Category:Genera_of_birds '''200''' pages, for birds] alone)
** '''All''' higher classes, e.g. [http://en.wikipedia.org/wiki/Charadriidae Charadriidae]
** '''All''' regional lists, e.g. [http://en.wikipedia.org/wiki/List_of_British_birds:_non-passerines List of British birds]
** '''All''' dedicatees, e.g. [http://en.wikipedia.org/wiki/Alexander_Wilson Alexander Wilson]
** '''All''' authorities, e.g. [http://en.wikipedia.org/wiki/Giovanni_Antonio_Scopoli Giovanni Antonio Scopoli]
** '''All''' images of living things, e.g. [http://en.wikipedia.org/wiki/Image:Charadrius_dubius_4_%28Marek_Szczepanek%29.jpg Charadrius dubius 4 (Marek Szczepanek).jpg]
** Many reserves, lakes, and other places of interest, e.g. [http://en.wikipedia.org/wiki/Belvide Belvide]
** Many biological authors and illustrators, e.g. [http://en.wikipedia.org/wiki/John_Audubon John Audubon]; [http://en.wikipedia.org/wiki/Gilbert_White Gilbert White]
** Random articles on other topics, e.g. [http://en.wikipedia.org/wiki/Balancing_lake Balancing lake}]
** Wines. E/g/ [http://en.wikipedia.org/wiki/Cabernet_Sauvignon Cabernet Sauvignon]
** '''All the above, again''', for each alternative language e.g. [http://cy.wikipedia.org/wiki/Cwtiad_Torchog_Bach Welsh]; [http://fr.wikipedia.org/wiki/Petit_gravelot French]; [http://zh.wikipedia.org/wiki/%E9%87%91%E7%9C%B6%E9%B8%BB Chinese]

*Wikimedia Commons
** '''All''' species indexes, e.g. [http://commons.wikimedia.org/wiki/Charadrius_dubius Charadrius dubius]
** '''Each individual''' image, e.g. [http://commons.wikimedia.org/wiki/Image:Charadrius_dubius_1_%28Marek_Szczepanek%29.jpg Charadrius dubius 1 (Marek Szczepanek).jpg]
** '''Each family''' list [http://commons.wikimedia.org/wiki/Charadriidae Charadriidae]

*Wiktionary
** '''All''' species articles, e.g. [http://en.wiktionary.org/wiki/american_golden_plover American Golden Plover]
** '''All''' family articles, e.g. [http://en.wiktionary.org/wiki/plover Plover]
** '''Many of the above, in other langauges''' e.g. [http://en.wiktionary.org/wiki/aquila_reale Italian]; [http://en.wiktionary.org/wiki/%D0%B1%D0%B5%D1%80%D0%BA%D1%83%D1%82 Russian]

*Wikispecies
** '''Every''' speices, e.g. [http://species.wikimedia.org/wiki/Charadrius_dubius Charadrius dubius]
** '''Every''' genus, e.g. [http://species.wikimedia.org/wiki/Charadrius Charadrius]
** '''Every''' sub-family, e.g. [http://species.wikimedia.org/wiki/Charadriinae Charadriinae]
** '''Every''' family, e.g. [http://species.wikimedia.org/wiki/Charadriidae Charadriidae]
** and so on, for '''every other rank'''
** '''Every''' image (e.g. [http://species.wikimedia.org/wiki/Image:Charadrius_hiaticula_He.jpg Charadrius hiaticula He.jpg]

*Wikibooks
** [http://en.wikibooks.org/wiki/Dichotomous_Key Dichotomous Key]

*WikiFlora
** All flowering plants of North-western Europe, (e.g [http://www.floralimages.co.uk/pvincaminor.htm ''Vinca minor'']), genus ([http://www.floralwiki.co.uk/wiki/index.php?title=Vinca Vinca])families ([http://www.floralwiki.co.uk/wiki/index.php?title=Apocynaceae Apocynaceae]), etc.

*Google
**[http://www.google.co.uk/search?hl=en&hs=dBU&client=firefox-a&rls=org.mozilla:en-US:official&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=%22E+coli%22&spell=1 Google finds about '''37,600,000''' for "E coli"].
***[http://www.google.co.uk/search?hs=Apo&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=%22Escherichia+coli%22&btnG=Search&meta= Google finds about '''19,500,000''' for "Escherichia coli"]
***[http://www.google.co.uk/search?hs=zqo&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=%22Ecoli%22&btnG=Search&meta= Google finds about '''722,000''' for "Ecoli"].
**[http://www.google.co.uk/search?hs=vWC&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=%22Homo+sapiens%22&btnG=Search&meta= Google finds about '''14,200,000''' for "Homo sapiens"]
***[http://www.google.co.uk/search?hs=vWC&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&q=%22Homo+sapien%22+-sapiens&btnG=Search&meta= Google finds about '''273,000''' for the mis-spelling "Homo sapien" -sapiens.]
**[http://www.google.co.uk/search?q=%22%22Homo+erectus%22%22&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official Google finds about '''1,260,000''' for ""Homo erectus"]
**[http://www.google.com/search?svnum=10&as_scoring=r&hl=en&edition=us&as_drrb=q&as_qdr=&as_mind=1&as_minm=9&as_maxd=1&as_maxm=10&q=%22Clostridium+difficile%22&ie=UTF-8&sa=N&tab=nw Google finds about '''1,380,000''' for "Clostridium difficile"].
**[http://www.google.com/search?hl=en&lr=&edition=us&q=%22Passer+domesticus%22&btnG=Search Google finds about '''841,000''' for "Passer domesticus"].
***[http://images.google.com/images?hl=en&lr=&edition=us&q=%22Passer%20domesticus%22&btnG=Search&sa=N&tab=wi Google images finds about '''3,140''' for "Passer domesticus"].
**[http://www.google.co.uk/search?hl=en&hs=oEU&client=firefox-a&rls=org.mozilla:en-US:official&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=%22Acer+palmatum%22&spell=1 Google finds about '''602,000''' for "Acer palmatum"]
** At the time of writing, '''every single one''' of the first 20 [http://www.google.com/search?q=%22Noctule+bat%22 Google results for "Noctule Bat"] also includes the scientific name ''Nyctalus noctula''.
*A [http://www.google.com/search?q=checklist+NEAR+species Google search for "checklist NEAR species"] finds about '''1,090,000''' - each checklist includes many species e.g. [http://www.earthlife.net/insects/mantchek.html], [http://www.kingsnake.com/dfw/checklist/species_checklist.htm], [http://www.taylor.edu/academics/acadDepts/ees/sedges/checklist.html]

*A [http://www.google.com/search?q=checklist+NEAR+species Google search for "species identification sheet"] finds about ''' 13,400''' - e.g. [http://www.oceansatlas.org/world_fisheries_and_aquaculture/html/resources/capture/mainspec/species/sp2605.htm]

*[http://www.arkive.org/ ARKive] - '''2000''' species ("It is ARKive's current aim to compile audio-visual records, where such media exists, for the 15,000-plus species currently threatened with extinction, according to the World Conservation Union's (IUCN) Red List of Threatened Species.")

* [http://zipcodezoo.com/ Zip Code Zoo] '''875,712''' plants and '''932,168''' animals ... '''79,438''' '''1,537''' sound recordings, '''23,704,023''' field observations (from 28,236 data sets and 1,326 data providers which show latitude and longitude, from which they have generated 218,283 State Maps, 715,397 Country Maps, 156,248 Google maps showing up to 200 sightings each, and 18,177 Google Earth maps showing all sightings). Uses full taxonomies e.g. [http://zipcodezoo.com/animals/s/sciurus_carolinensis.asp Eastern Gray Squirrel, ''Sciurus carolinensis'']

* [http://www.gbif.org/ Global Biodiversity Information Facility] '''983,000''' scientific names and '''253,000''' common names [http://www.europe.gbif.net/portal/index.jsp]. Uses full taxonomies, e.g [http://www.secretariat.gbif.net/portal/ecat_browser.jsp?taxonKey=1579222&countryKey=0&resourceKey=0&showIncertae=false&nextTask=ecat_browser.jsp ''Pterothrissus cristatus'']. Has '''118,932,333''' individual records, e.g. [http://www.secretariat.gbif.net/portal/digit_detail.jsp?scientificName=Pterothrissus+cristatus&headingTaxonKey=1579222&serviceKey=310&resourceKey=971&recordKey=0&nextTask=digit_viewer.jsp Pterothrissus cristatus at Lee-on-the-Solent on 2004-07-22]

*[http://www.rhs.org.uk/rhsplantfinder/plantfinder.asp Royal Horticultural Society - RHS Plant Finder] - '''70,000''' plants

*[http://www.bacterio.net List of Prokaryotic Names (formerly List of Bacterial Names)] - 2,032 *files*; '''10,268''' published names (to 2006-09-07)

*[http://nbn.nhm.ac.uk/nhm/ UK National Biodiversity Network's Species Dictionary]

*[http://www.searchnbn.net/ UK National Biodiversity Network Gateway] - '''20 million+''' species records

*[http://www.sp2000.org/ Species 2000] - '''450,000 species'''

*[http://www.bioimages.org.uk/index.html BioImages - Virtual Fieldguide] - '''53,000''' images depicting 4,600 species (see [[species-brainstorming#Malcolm_Storey|Wiki comments from site owner]])

*[http://animaldiversity.ummz.umich.edu/ Animal Diversity Web] - "'''Thousands''' of species accounts ['''plus'''] descriptions of levels of organization above the species level, especially phyla, classes, and in some cases, orders and families. Hundreds of hyperlinked pages and images illustrate the traits and general biology of these groups"

* [http://www.ubio.org/index.php?pagename=home uBio]
**NameBank is a repository of '''millions''' of recorded biological names and facts that link those names together.
**ClassificationBank stores multiple classifications and taxonomic concepts that are the result of expert opinions. It extends the functionality of NameBank.
**Over '''500,000''' common names are catalogued.

*[http://www.birdlife.org/datazone/species/ BirdLife International] - all birds of the world (~'''10,000''')

*[http://bugguide.net/ Bug Guide] - all insects, spiders, and allies, of the USA and Canada (most with more than one page).
** e.g. [http://bugguide.net/node/view/70875 Arge pectoralis - Birch Sawfly]

*[http://www.birdforum.net/bird_index.php BirdForum Birds Database] - currently >'''5,000''', working towards all 10,000+, species.
**[http://www.birdforum.net/bird_view.php?bid=5780 Painted Firetail]

*[http://www.bto.org/birdtrack/ BirdTrack]
**[http://blx1.bto.org/bt-dailyresults/results/s171-20-06.html Lapwing]

*[http://www.discoverlife.org/ Discover Life] - "contains '''306,553''' species. The Polistes Foundation and its scientific partners plan to add high-quality identification guides, maps, images, and text for '''a million species''' by 2012. [...] Each month Discover Life serves approximately 3 million pages and images to 70,000 IP addresses"

*[http://www.record-lrc.co.uk/ rECOrd] (the Local Biological Records Centre serving the Cheshire region of England) - '''1.6 million''' species records available online for the public to search and map

*[http://www.dnabarcoding.ca/ Canadian Centre for DNA Barcoding ] multiple sites, covering over '''11,000''' species ('''134,990''' records; target 55,000+ species.
**[http://www.barcodinglife.org/ Barcode of Life Data Systems] "BOLD-ECS provides web developers and bioinformaticians the ability to build tools and workflows that can be integrated with the BOLD framework. We welcome the addition of new analytical modules."

* [http://hbs.bishopmuseum.org/fiji/checklists.html Fiji Arthropod Survey] - (insects, arachnids, crustaceans, and others) > '''7,000''' Families, Genera and Species

*[http://simile.mit.edu/timeline/examples/dinosaurs/dinosaurs2.html Simile Dinosaur Timeline] '''all''' dinosaurs genus - potential hCalendar mash-up.

* [http://www.fishBase.org/search.php Fishbase] '''29,600''' species, '''222,400''' common names, e.g. [http://www.fishbase.org/comnames/CommonNameSummary.cfm?autoctr=14995 Chinese barb], '' [http://www.fishbase.org/Summary/SpeciesSummary.php?id=4677&CFID=1552828&CFTOKEN=13861129 Puntius semifasciolatus]'' and [[http://www.fishbase.org/comnames/CommonNamesList.cfm?ID=4677&GenusName=Puntius&SpeciesName=semifasciolatus&StockCode=4895 all its other common names]].

* [http://nmnhgoph.si.edu/msw/ Mammal Species of the World] - ~'''8,000''' species (e.g. [http://nmnhgoph.si.edu/cgi-bin/wdb/msw/names/query/12216 Eurasian Badger, ''Meles meles''], plus higher-level ranks (e.g. [http://nmnhgoph.si.edu/cgi-bin/wdb/msw/names/query/5001 Order ''Insectivora''], [http://nmnhgoph.si.edu/cgi-bin/wdb/msw/names/query/5071 Family ''Erinaceidae''], etc.).

* [http://research.amnh.org/herpetology/amphibia/index.php Amphibian Species of the World] - >'''6,000''' species (e.g. [http://research.amnh.org/herpetology/amphibia/references.php?id=6984 ''Cochranella daidalea '']), plus higher-level ranks (e.g. [http://research.amnh.org/herpetology/amphibia/references.php?id=6815 Family ''Centrolenidae''], etc.).

* [http://www.bacterio.cict.fr/index.html List of Prokaryotic (Bacterial) names with Standing in Nomenclature] - '''2,212''' names of genera, species or subspecies (e.g. [http://www.bacterio.cict.fr/allnamesac.html A-C]), and '''124''' names of higher taxa ([http://www.bacterio.cict.fr/validsupragenerinames.html]]) (number cited seems on low side; note [http://www.bacterio.cict.fr/twothousand/twothousandsix.html 856 additions in 2006]).

*PhotoPic
**[http://community.fotopic.net/search/simple.php?txt=bird&action.x=0&action.y=0&action=Go galleries for "bird"] = '''929'''
*** e.g. [http://parentphoto.fotopic.net/c1119884.html Ryan Parent's pictures]
**[http://community.fotopic.net/search/simple.php?txt=insect&action.x=0&action.y=0&action=Go galleries for "insect"] = '''194'''
***e.g. [http://foto-fountain.fotopic.net/ Foto Fountain]
**[http://community.fotopic.net/search/simple.php?txt=wildlife&action.x=0&action.y=0&action=Go galleries for "wildlife"] = '''458'''
***e.g. [http://johnmartin.photos.gb.com/c1113758.html Martin's Photo Images]
**etc.

===Planned sites===
*[http://herbariaunited.org/atHome/ Herbaria United] (part of The website of the Botanical Collection Managers Group (BCMG), a specialist group of the Linnean Society of London) - "The UK has the world's largest and oldest collections of herbarium specimens held in trust by museums and universities. A new project is just getting underway to put all this online."
**Update (2007-02-28) - work has started, and the first pages are available to view.

===Misc===
*[http://darwin.zoology.gla.ac.uk/~rpage/ispecies/ iSpecies] - a species search engine (e.g. [http://darwin.zoology.gla.ac.uk/~rpage/ispecies/?q=bullfinch&submit=Go search for "Bullfinch"], [http://darwin.zoology.gla.ac.uk/~rpage/ispecies/?q=Charadrius+dubius&submit=Go search for "''Charadrius dubius''"]

==Contributors==
*[[User:AndyMabbett|Andy Mabbett]] (proponent)
*Malcolm Storey (per e-mail)
*[[User:SXBRC|Charles Roper]], [http://www.sxbrc.org.uk/ Sussex Biodiversity Record Centre] (proponent)

==See also==
{{species}}

[[Category:Species]]

Category:htodo

2007-05-01T13:46:57Z

Gazza:

Lists all pages related to hToDo.

to-do-examples

2007-05-01T13:45:19Z

Gazza: Added Category

I took at look at Basecamp. They embed todo items in a UL, a little bit like XOXO (with a lot of extra schmutz). If you assign something to someone then you get something like this:

Smack Man: wonder why it looks like this

so what's missing here is an identifier for the person, and their role. We'd imaging something like,


Smack Man
wonder why it looks like this


(the assignment looks a bit verbose.... plus "attendee" is not exactly the right idea, but it's coming from VTODO, we we defer.)

[[Category:htodo]]

htodo

2007-05-01T13:44:54Z

Gazza: Added Category

<h1>hToDo</h1>

''This is just an initial draft''

[http://en.wikipedia.org/wiki/ICalendar#To-do_.28VTODO.29 VTODO] is part of the [http://www.ietf.org/rfc/rfc2445.txt RFC2445 iCalendar spec] used for describing todo items.

VTODO is fairly straight-forward, as it doesn't contain any nested entities, and has a fairly small list of properties. Most of these it shares with VEVENT, suggesting htodo be modeled on hevent in [[hcalendar]], and the ground assumption is that htodo should work just like hevent with respect to these properties. The shared properties are:

''class, created, description, dtstamp, dtstart, geo, last-mod, location, organizer, priority, recurid, seq, statusm summary, uid, url, duration, attach, attendee, categories, comment, contact, exdate, exrule, rstatus, related, resources, rdate, rrule, x-prop''

The unique properties to VTODO are:

* '''completed''' The date/time the todo was completed
* '''due''' The date/time this todo is due
* '''percent''' Integer from 0-100, completion status

As the data types for '''completed''' and '''due''' are the same as, e.g., '''dtstart''', then the usage should be the same. For example,

<abbr class="due" title="2007-01-01T13:10:05.0Z">January 1, 2007</abbr>

As for percent, the contents of span with class "percent" will do, I think. If there is a "%" in the body, it can be ignored. The numerical part is assumed to be from 0-100. For example,

50%

and

50 percent

are equivalent.

Here is a full example,

<div class="vtodo">
Create a spec for hToDo
first draft
Initiated <abbr class="dtstart" title="2006-05-12">May 12, 2006</abbr>
</div>

[[Category:htodo]]

hReview-feedback

2007-05-01T13:32:45Z

Gazza: Empty, now Hixie's comment is on the right page

#REDIRECT [[hreview-feedback]]

hreview-feedback

2007-05-01T13:32:03Z

Gazza: /* General Comments */ Moved Hixie's comment from Orphaned page

= hReview Feedback =

This document is for keeping track of feedback about [[hreview|hReview]], one of several MicroFormats.

== Feedback ==
=== General Questions ===
See the [[hreview-faq|hReview FAQ]].

=== General Comments ===

April 30, 2005:

Nice work :-) Some questions:

For the most part, the concept of the format's "fields" translates, in any particular case, to the field name appearing in the class attribute of an element, and the field value appearing in the text of the element. Right?

Can it be generally stated that it doesn't matter which elements these class/fields are attached to? If not, what are the specific constraints?

It'd be useful to outline any cases where:

* fields or values appear in other attributes (e.g., class="type" title="business")

* an element indicated as a field can contain more than text, or a mix of text and other elements (e.g., some of the 1 of 5 type rating span examples)

Also, what is the constraint about class attributes containing multiple values where one is a field name (i.e., I assume you're not supposed to put two field names in the same class--but, what is the extent of the constraint? Can multiple class values be used as long as they don't look like two field names?)

'''See [[hcard-parsing]] which answers these questions. -[http://tantek.com/log/ Tantek]'''

Also ([[rel-tag]] question), does rel-tag support this kind of eleaborate label (where the tag indicated element has more than just a text value that exactly matches the last part of the uri?):

<pre><nowiki>
<li><a href="http://flickr.com/photos/tags/Price" rel="tag">
Price: <abbr class="rating" title="2">$$</abbr>...</a></li>
</nowiki></pre>

Doesn't RelTag significantly constrain what appears enclosed within the A element? i.e., (from Technorati's tag description:)
<pre><nowiki>
<a href="http://technorati.com/tag/[tagname]" rel="tag">[tagname]</a>
</nowiki></pre>
-[http://icite.net/blog/ Jay Fienberg]
</pre></nowiki>

'''See the [[rel-tag]] spec. The last segment of the URL is the tagname, not the contents of the element. The Technorati help page is only providing suggested markup. See the spec for normative details. -[http://tantek.com/log/ Tantek]'''

----

I don't know how widespread it is to have summaries of a review in one place and then point to them in another, but that's something I do on one of my sites, where reviews are accepted by trackback (eg. [http://grwifi.net/location/Common+Ground+Coffee+Shop | this page]). I've blogged a possible markup for that [http://jystewart.net/process/archives/2005/04/initial-thoughts-on-hreview/ | here]

- JamesStewart

'''Thus the "description" is optional, and you can provide a URL permalink back to the original. -[http://tantek.com/log/ Tantek]'''

----

I've added some items to the FAQ page ([[hreview-faq|hReview FAQ]]) Please take a look at them and feel free to clarify or modify.

-RyanKing

----

I've been following the evolution of microformats on Technorati with great interest and hReview seems to really break new ground. Reviews represent something big enough that they have their own identity, they can be 'referenced'. In contrast hCard and hCalendar seem to be more of a 'pass-by-value' proposition (I've ammended my SmartTag + AutoLink = SmartLink [http://adriancuthbert.blogspot.com/2005/04/smartlink.html experiment] to support [[hcalendar|hCalendar]]). To that end I was surprised at the specification. I've explained things more fully [http://adriancuthbert.blogspot.com/2005/05/review-of-hreview.html here]

-[http://www.technorati.com/profile/acuth Adrian Cuthbert]

----

Has anyone considered list context? I have adapted my Developer's Resource Index, which is in essence a list of reviews, to use the hReview spec. However, is it appropriate to set the entire list as <code>&lt:dl class="hreview"></code>, or each individual item by wrapping the <code><dt></code>/<code><dd></code> pairs in a <div> (which is the approach I took)?

'''Follow-up''': scratch that last comment: Since I'm using XHTML 1.1, <div> is not allowed in this context. Which of course brings me back to the original question. Hmm...

Have a look at an example of the code if you'd like: [http://loadaveragezero.com/app/drx/Data_Formats/Markup_Languages Markup Languages]. I will post this URI to del.icio.us tagged as hreview as well.

[http://loadaveragezero.com/hnav/contact.php Douglas Clifton]

----

Shouldn't it be mentioned somewhere in which language the review is written in? Is it just a slip of the mind, or a very US-centric attitude, dude? I don’t think adding language info would be out of scope, as it would help filter out unwanted languages from search queries; plus, Ce n’est pas parce que mon blog est en anglais, 꼭 英語만 쓰는 것이 아니다… What if I wanted to post the same review in different languages, or quote something in another language..?

[http://sungnyemun.org/wordpress/ dda]

'''Thanks for your input. This was made explicit and resolved by hReview 0.2, specifically: [http://microformats.org/wiki/hreview#Language hReviews and language] -[http://tantek.com/log/ Tantek]'''

----
A sample xhtml fragment of "Multidimensional Restaurant Review" is not valid XML format.

original:
This <abbr class="type" title="business">
<a href="http://en.wikipedia.org/wiki/cafe" rel="tag">cafe</abbr></a>

correct:
This <abbr class="type" title="business">
<a href="http://en.wikipedia.org/wiki/cafe" rel="tag">cafe</a></abbr>

[http://yohei-y.blogspot.com YAMAMOTO Yohei]

'''Thanks for the feedback Yamamoto, that was my typo and the example has been corrected. - [http://tantek.com/ Tantek]'''

----
* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hReviews must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?

----
Should the 'type' field be expanded? What is the proper type for reviewing a movie seen in a cinema? Of the existing values, 'event' would seem to apply best, but it's not completely intuitively obvious, especially since 'product' could also apply.

Compare to reviewing a movie on DVD. One might be tempted to use the 'product' type. But what is really the product here -- the film being viewed, or its packaging? Again, 'product' doesn't seem intuitively obvious, as it would seem to apply to more utilitarian objects, rather than to ephemera like movies or music.

I suggest the following:

'event' should specifically be defined to mean an occurence in a particular time/location frame, experienced in person (live concerts, trade shows, sporting events, etc).

'product' should similarly be narrowed down in some fashion. In some cases, it might be difficult to decide whether one is reviewing a 'business', or their 'product'. And where does the concept of a 'service' fall? These ideas are sometimes closely related, and other times quite separate.

'media' should be added to cover reviews of artistic creations (music, films, literature, art) which may appear in non-unique formats (viewed in person, DVD, CD, TV, radio, magazines, art galleries, etc).

[[User:Dougal Campbell|Dougal Campbell]] 10:28, 26 Jul 2005 (PDT)

'''Dougal, this was already answered in the [[hreview-faq|FAQ]] a while ago as the first question! -[http://tantek.com/log/ Tantek]'''

----

The rating field, at the moment, is mandated to be an integer. Is there a particular reason for this (which seems like an unnecessary restriction)?

- AlfEaton.

'''First, the rating field is based on current actual review/rating data published on the web, which for the most part is integer. There have been several requests for allowing one decimal digit of precision, since that broader definition would include many more (90%+ at least) reviews on the web, it is being considered for hReview 0.3.'''

'''Second, "unnecessary restriction" is looking at it from the complete wrong perspective. "unnecessary axis of freedom or extensibility" is the thing to avoid, because that is the antithesis of simplicity, and causes more work for everyone involved, testing, developing etc. Premature generality is a common mistake made by engineers, and microformats explicitly seeks to avoid it.'''

'''- [http://tantek.com/log/ Tantek]'''

----

Consider for hReview 0.3:

* make it explicit that a review of an event (see item types list) SHOULD use [[hcalendar|hCalendar]] to represent the item, just as a review of a company or person SHOULD use [[hcard|hCard]]. - [http://tantek.com/log/ Tantek]
* now that [[hcard|hCard]], [[hcard-parsing]], and [[hcard-profile]] are solid, change SHOULD to MUST for
** item description of a business MUST use an hCard
** reviewer information MUST be represented by an hCard

2005-10-06 Tantek Çelik and Ian McAllister discussed the above changes for hReview 0.3 and agreed that they should be in hReview 0.3.

* add one decimal digit of precision to ratings per discussion above. Matt Mullenweg has also asked for this based on his experience at CNET and their reviews.

2005-11-29 Tantek Çelik and John Panzer discussed the above changes for hReview 0.3 and agreed that they should be in hReview 0.3.

2005-12-07 As pointed out by David Janes, there needs to be a more explicit way to markup the best/worst of a rating, and an example provided that does so, e.g.:

I think to convey the scale of an overall rating, we may need to borrow [http://microformats.org/wiki/hcard#Value_excerpting the "value" construct from hCard] (as it is used in "tel" properties for example). E.g.

<pre><nowiki>

On Fred's 4</a> ICBM scale, I give this a 2</a>.

</nowiki></pre>

- Tantek Çelik

2005-12-07 I've made the following assumption from 0.2, which works pretty good and you may consider making more formal: "best"/"worst"/"rating" apply to the entire hReview object, unless they appear inside a rel-tag object, in which case they only appy to that. Since hReview seems designed to apply to one "item" at a time, this seems sufficient. -- [[User:DavidJanes|David Janes]]

----

Some comments:

* ''There is no mention of any sort of credibility attached to a review in this specification. Most review sites today indicate how many users found the review helpful, etc, which I consider critical information to attach any credibility to the review. This can also be considered a review of a review, and allow for embedded hReviews.''
** Response: The URL from which the hReview is obtained can be used to lookup a credibility of that URL/domain/blog as a source in general. It's not clear this should be in the review itself.
* ''I don't understand why the 'item type' field is restricted. What if I want to write reviews for job desriptions? Is my only option the URL type? ''
** Please see the [[hreview-faq|hReview FAQ]] about using tags for more specific items.
* ''Shouldn't we have the 'origin' field as mandatory? If not specified, this may lead to duplicate reviews on a site that crawls multiple sites which in turn crawl eachother.''
** The permalink field solves this problem.
*''-Sapna''
** - Tantek Çelik

----

2005-10-20 David Sifry suggested adding a license feature so that companies could explicitly state the license/copyright of the review (e.g. CC license, or All Rights Reserved etc.).

* The question is, is such a license feature something that all microformats need? And thus perhaps we need to figure out how to extend / update [[rel-license]] to apply to any microformatted chunk of data - Tantek Çelik

----

2005-11-30 RyanKing wonders whether requiring reviewer might be too much in some cases. For example, he wrote [http://theryanking.com/blog/archives/2005/11/17/spoon-the-warfield/ a review], on his own blog, but had to include his name in the post text.

* Tantek reminds Ryan about the hResume discussion where we figured out how multiple hCards on a page could share a common "fn" at the top of the page by reference. Note: Tantek needs to add "write hResume draft" to his section on the [[to-do]] page.

----

2006-01-26

[http://microformats.org/discuss/mail/microformats-discuss/2005-July/000409.html Eran Globen noted in July of 2005] that it may be good to allow for rated tags to be specified with the tag inside the rating. Combined with the "value" technique in hCard, this is quite doable. The example that Eran gave, modified just a bit to use the "value" technique:

<pre><nowiki>
<ul>
<li>
<a href="http://en.wikipedia.org/wiki/Food" rel="tag">Food:
18/30</a>;
</li>
...
</ul>
</nowiki></pre>

Changes to:

<pre><nowiki>
<ul>
<li class="rating">
<a href="http://en.wikipedia.org/wiki/Food" rel="tag">Food</a>:
18/30;
</li>
...
</ul>
</nowiki></pre>

------

2006-01-27

In some contexts, it'd be somewhat useful for the author information to be able to be "inherited" from the review's context, e.g. perhaps a series of many, perhaps dozens, of reviews all by the same reviewier, provided together on a list, perhaps on a blog. This might be good for 0.3.

We thought of something similar for [[hresume|hResume]], to enable [[hcard|hCards]] for each job to share a common "fn" value, derived from the individual's name at the top of the resume.

We could also use such a "sharing of data" concept for [[hatom|hAtom]], so that the authors for entries are by default the authors for the blog, unless otherwise specified. - Tantek

* We have now done this for hReview 0.3 via the object [[include-pattern]] Thanks. Tantek

------

2006-02-07

In the extended Crepes on Cole example, the reviewer name is anonymous, but is not so indicated by adding fn to the list of classes on the enclosing element. Is this correct? I don't think so. - Rohit

* This has been corrected in hReview 0.3. Thanks. Tantek
------

2006-02-23

What's the rationale for making dtreviewed required? I think (as pointed out earlier) there are vaild cases where it's omitted from the page markup (either because it's inferred from the HTTP Last-Modified date, or because a review date isn't relevant or available).

* This was an unintentional omission from hReview 0.3, and has been corrected. Please take another look. Thanks. Tantek

----

2006-03-06

At [http://postgenomic.com/about_reviews.php postgenomic.com] (an aggregator/analysis engine for life science weblogs), an attempt to get people to add markup to their posts to identify reviews of papers currently recommends using either a) rev="review" on the outgoing link, or b) to enclose the review in <div class="hreview"> and add class="url" to the outgoing link.

Because of the way the reviews can be structured (generally just free text, without extra citation metadata), the separation between 'item' and 'description' doesn't really fit. Could it be acceptable to just use class="url" on the outgoing link to imply that as the subject of the review, without using either 'item' or 'description'? -- AlfEaton

----

2006-09-20
What about marking up prices, using the [[currency]] proposal? - Andy Mabbett

==Related pages==
{{hreview-related-pages}}

microformats-jp

2007-05-01T13:26:41Z

Gazza: Redirect

#REDIRECT [[microformats-ja]]

rel-tag-faq

2007-05-01T13:20:52Z

Gazza: Changed headings to follow How To Play Guideline 9

= rel-tag frequently asked questions =

This document serves to answer and discuss frequently asked questions specifically about the [[rel-tag]] microformat. You may want to read the [[rel-faq]] first as it answers many common questions about the HTML4 "rel" and "rev" attributes, and their linktype values. If you have a new question to ask, first consider asking on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss list].

== Q&A ==

# ''Where does a tagging link belong? Does the tagging link only need to appear in my Web feed (RSS / Atom)? Does the tagging link need to appear on the page where my specific blog entry lies? Does the tagging link need to appear everywhere that I can possibly imagine?''
#* In short, tagging links belong in all the places and formats in which you published tagged content. The Web page is the primary location where users read content and where search engines index. Thus the Web page is a place where you should absolutely include your [[rel-tag]] links. To tag your blog posts, put the [[rel-tag]] links inside them, visibly. The Web feeds are simply alternate ways of publishing your blog posts, and thus should include the full content of your blog posts, [[rel-tag]] links intact.
# ''Where shouldn't I use rel-tag?''
#* rel-tag expresses a particular relationship (a) between the page you are on and (b) the target of a link. If you're not asserting this relationship, don't use rel-tag. In particular:
#** don't use rel-tag in [http://en.wikipedia.org/wiki/Tag_cloud Tag Clouds]
#** don't use rel-tag to refer to the pages http://www.technorati.com/tag/xyz, http://del.icio.us/tag/xyz, http://www.flickr.com/photos/tags/xyz/ (and so forth) if you're not asserting "this page is tagged 'xyz'"
# ''The format specifies that the tag must "come after the last / in the path". Will something like <code><nowiki>http://example.com/index.php/TAG</nowiki></code> work? Or does it have to be a "real" directory or [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite]? -- [[User:Singpolyma|singpolyma]] 23:51, 24 Jan 2006 (PST)''
#* The key is the URL. Whether that URL is generated from a database or a directory does not matter. The URL matters.
#** My question, however, was about whether that URL form ( <code><nowiki>http://example.com/index.php/TAG</nowiki></code> ) would be valid, since there is the dot in "index.php".
#*** Yes, the URL in the example is valid (or legal or conformant or whatever you want to call it to minimize confusion). The dot (period, full stop, U+002E) is free to appear in most places in a URL, even in the middle of a path-segment that is not the last path-segment. (The latest specification for URLs, "[http://gbiv.com/protocols/uri/rfc/rfc3986.html Uniform Resource Identifier (URI): Generic Syntax]", is RFC 3986.)
# ''I'm developing a web application which uses tagging, and so of course I want to use [[rel-tag]]. For this application, I want nice, clean URLs. I was planning to use [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map a clean URL onto my underlying scripts. How do I use Apache's [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map <code><nowiki>http://example.org/~user/app/tag/car</nowiki></code> to <code><nowiki>http://example.org/~user/app/script.php?tag=car</nowiki></code> ?''
#* One solution involves changing the script to inspect the path for the tag (via the variable "PATH_INFO"), rather than inspecting the query:
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/([^/]+)$ script.php/$1 [last]
</Directory></nowiki></pre>
#* For people who can edit the server's main configuration file, the following untested configuration code may work. Corrections are welcome.
<pre><nowiki>RewriteEngine On
RewriteMap tag int:escape
RewriteRule ^/~user/app/tag/([^/]+)$ /~user/app/script.php?tag=${tag:$1} [last]</nowiki></pre>
#* The following configuration code, left over from a previous contribution to this document, does a poor job according to tests. The following code fails to enforce the [[rel-tag]] rules about the tag corresponding to the last non-empty path-segment. The following code fails to transcode the tag for safe use in the URL query. Consider that a request on <code><nowiki>http://example.org/~user/app/tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/not-a-tag/the-tag</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=not-a-tag/the-tag</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/the-tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=the-tag/</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/attack&intent=destroy</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=attack&intent=destroy</nowiki></code> .
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/(.*)$ script.php?tag=$1
</Directory></nowiki></pre>
<ol start="4">
<li>''Does a rel tag still have meaning if the link redirects? If the HTTP server returns a 302 status code, does the rel-tag have meaning? Is there a formal rule that indexers should follow the link to the final, resolved destination? Or is there a formal rule that a rel tag should be ignored if URL of its link does not return a status code of 200?''
* ..next answer
</li>
</ol>

===CSS selector===
*How do you write a CSS selector for rel-tag?
** <code>a[rel~="tag"] { color: green }</code>

===Are tags case sensitive===
*Are tags case sensitive. Is "Dog" the same tag as "dog" and "DOG"?
**{{AwaitingAnswer}}

===Multi-word tags===
*How should a multi-word tag be made? For instance, if using Wikipedia as a name space, a page about a Black Redstart (a bird) would be tagged '''Black_Redstart''', with an underscore [http://en.wikipedia.org/wiki/Black_Redstart]. Is there any way of aliasing alternatives ("BlackRedstart", "Black-Redstart", etc.)? Is any particular format preferable?
** Existing bevavior
*** delicious supports combined tags
*** flickr supports multi-word tags with spaces but collapses spaces when searching
*** ma.gnolia supports multi-word tags with spaces
*** technorati supports multi-word tags with spaces
**{{AwaitingAnswer}}

===Tags with file extensions===
*Is <code><a rel="tag" href="<nowiki>http://example.com/cheese.htm</nowiki>">cheese</a></code> a valid tag for "cheese"? Ditto ".asp" or ".php" variants? If not, why not?

Any file-name extension in the last path segment is part of the tag value:

*<nowiki>http://example.com/cheese.htm</nowiki> ⇒ cheese.htm
*<nowiki>http://example.com/cheese.asp</nowiki> ⇒ cheese.asp
*<nowiki>http://example.com/cheese.php</nowiki> ⇒ cheese.php

The [[rel-tag|rel-tag specification]] is clear on how to extract a tag from a URL. Special treatment for file-name extensions is not part of the extraction. Brian Suda gave an [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008538.html explanation on the microformats-discuss list]. Consider the following URLs, the tags that the following URLs give under the current specification, and the effect of requiring special treatment for file-name extensions on the tags that the following URLs give.

*http://en.wikipedia.org/wiki/.htaccess
*http://en.wikipedia.org/wiki/.Net
*http://en.wikipedia.org/wiki/India.Arie
*http://en.wikipedia.org/wiki/ASN.1
*[http://en.wikipedia.org/wiki/L.I.E. http://en.wikipedia.org/wiki/L.I.E.]

===What about Scope===
Since rel-tag is a feature used in many other microformats, the question often arises: "What is the scope of the tag?" For instance, a rel-tag may appear inside of an [[xfolk xFolk]] entry and on first glance it may appear that the tag should only apply to that entry. However, current publishing practice seems to indicate anything appearing on a page is likely related to the content of the page. Therefore, the interpretation is that not only does the rel-tag apply its direct container but to all containers and to the document as a whole; it contains the xFolk entry. This is a departure from strict knowledge theory in favor of real-world usage.

As another example, you may link to your friend Joe with XFN and hCard, indicating in his categories that Joe is interested in swimming, which you loathe. Since the article is primarily about you and not about Joe's hobbies and because the rel-tag is inside an hCard, you may expect that the rel-tag does not apply to the document; however, the document does contain information about swimming, albeit tiny, namely that your friend likes it. In this way, rel-tag is binary: it indicates direction (yes or no) but not magnitude. This equivalent to a free-text search sans [[http://en.wikipedia.org/wiki/tf-idf tf-idf]]; i.e. without a notion of term relevance.

The upshot of this is that rel-tags can have downward scope but not upward scope.

==Related pages==
{{rel-tag-related-pages}}
**{{AwaitingAnswer}}

rel-faq

2007-05-01T13:19:26Z

Gazza: Changed headings to follow How To Play Guideline 9

<h1> "rel" attribute frequently asked questions </h1>

This document serves to answer and discuss frequently asked questions about the HTML4 "rel" and "rev" attributes, and their linktype values. Specifically this document explores a number of issues common to and exposed by the various [[microformats]] which extend the HTML4 rel attribute.

__TOC__

== Authors ==
* John Allsopp, [http://westciv.com Western Civilisation]
* [http://tantek.com Tantek Çelik], [http://technorati.com Technorati, Inc]
* [[User:AndyMabbett|Andy Mabbett]]

== FAQ ==

===What microformats use rel ===
*[[rel-directory]]
*[[rel-license]]
*[[rel-nofollow]]
*[[rel-tag]]
*[[rel-payment]]
*[[vote-links]]
*[http://gmpg.org/xfn/ XFN]

=== What is the proper use of the rel attribute ===

First, you can use the [http://www.w3.org/TR/html4/types.html#type-links linktype] as specified in [http://www.w3.org/TR/html4/ HTML 4]. A well known example of this is rel="stylesheet". Second, you "can extend the rel attribute using a [http://www.w3.org/TR/html4/types.html#type-links profile"], but "[http://www.w3.org/TR/html4/types.html#idx-link_type-2 HTML doesn't specify/recommend a profile format]". XMDP can be used to formally define new rel values.

=== What does a rel value really mean ===

The rel values in HTML follow a consistent pattern which at a minimum ''implies'' a deliberate design. rel describes the relationship of a hyperlink in terms of what the destination (href) is, to the source, or from the source's perspective. rel="stylesheet" is perhaps the easiest example to understand in this manner, because it is saying that this resource over there (indicated with the href) ''is'' a "stylesheet" for the current document. Similarly, rel="help" link states that the resource indicated by the href is "help" (e.g. a help file or FAQ) for the current document. All the rest of the values defined in HTML4 also follow this pattern of being a ''noun'' which labels the resource indicated by the href, from the perspective of the current document.

=== Then what does rev mean ===

"rev" is the precise opposite (or "reverse") of the "rel" attribute. E.g. a rev="help" link indicates that ''the current document'' is "help" for the resource indicated by the href.

=== Is rel single or bi directional ===

Though the HTML4 specification is not specific on this point, all the rel values in the HTML4 specification follow a very consistent pattern that indicate a specific directionality to the value of the rel attribute. The ''only'' exception to this is the value "alternate", which, is actually inherently symmetric, so rel="alternate" means pretty much the same thing as rev="alternate". I say pretty much because in theory (and in practice) one of a pair of alternates is likely to be more definitive, and thus one is more a primary resource, with the other being an alternative. In theory you could extend rel with a new value, e.g. "original" which could be used to point back the original version of a document. This could be used for example with translations, where translations of a document would point back to the original with rel="original".

=== Are rel attributes and linktypes in general just document to document ===

The vast majority of the rel values defined in HTML4 are from a document to a document. rel="stylesheet" is a bit of an exception, as it from an HTML document to a style sheet, which is more like a set of styling rules and instructions than a "document" in the classical sense. Two notable exceptions are rel="copyright" and rel="bookmark" which describe the relationship from the current document to (potentially) only part of a document. The 'rev' attribute adds an interesting perspective on this question. Specifically, [http://www.w3.org/TR/html4/struct/links.html#rev-link 12.3.1 of HTML4] shows an example of two links one using rel and the other using rev which mean the same thing. Thus linktypes in general may be either from a whole document or part of a document to a whole document or a part of a document. For example, the RelTag specification introduces the rel="tag" value, and notes that it indicates a relation from a document or major portion thereof to a document. Finally, XFN probably stretches rel the farthest, as it uses rel to indicate a person to person relationship. This person to person scope was not introduced by XFN, but merely adopted. It was introduced by bloggers who have taken to linking to other bloggers by name and thus using people's blog URLs as proxies for people themselves.

=== Is VoteLinks a proper use of rel ===

No. The problem with using rel for VoteLinks is made apparent with the following example:

<pre><nowiki>
<a href="http://www2005.org" rel="vote-for">WWW2005 is a great conference</a>
</nowiki></pre>

Following the reasoning in the earlier answer to the question of what a rel value means, this link would mean:

The resource indicated by http://www2005.org is a "vote-for" the current document.

That clearly doesn't make any sense, and was certainly not the intent of VoteLinks. Ironically, the reverse makes a lot more sense:

The current document is a "vote-for" the resource indicated by http://www2005.org.

And generalizing to the same cultural usage links as XFN:

The current document, as a proxy for the person who wrote it (e.g. the blogger whose blog it is),
is a vote-for the resource indicated by http://www2005.org.

Fortunately the "rev" attribute captures this "reverse" relationship semantic, and thus the above example should be written like this:

<pre><nowiki>
<a href="http://www2005.org" rev="vote-for">WWW2005 is a great conference</a>
</nowiki></pre>

And thus VoteLinks has been changed to use "rev" instead of "rel", in order to keep the well known and easily understandable "vote-for", "vote-abstain", and "vote-against" values.

=== Should rev even be used ===

Given that the 'rev' attribute has been more often misused by authors than properly used ([http://code.google.com/webstats/2005-12/linkrels.html Google Code: Web Authoring Statistics: Link Relationships]) is it even a good idea to use rev at all?

The short answer is unfortunately "no". Use of "rev" SHOULD be avoided.

However, VoteLinks, is being grandfathered since it was such an early use. No future microformats should be developed that use 'rev'.

=== When a rel value refers to a relationship to or from a page or document is it referring to just the page or the contents of the page or both ===

The consensus (and convention) is that such rel values are referring to the page itself including its immediate contents, but not for example to embedded contents of like images, objects, frames etc.

== See Also ==

* [[rel-directory]]
* [[rel-examples]]
* [[rel-license]]
* [[rel-payment]]
* [[rel-tag]], [[rel-tag-faq]]
* [[rel-design-pattern]]
* [[vote-links]]
* [http://gmpg.org/xfn/ XFN], [http://gmpg.org/xfn/faq XFN FAQ]

User talk:Gazza

2007-05-01T13:10:28Z

Gazza: Explains why I made so many changes

hresume-issues

2007-05-01T13:02:38Z

Gazza: /* Issues */ Fixed broken link

<h1> hResume issues </h1>

These are externally raised issues about [[hresume|hResume]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]

See related [[hcalendar-issues]].
See related [[hcard-issues]].

__TOC__

== Issues ==

* {{OpenIssue}} 2007-01-04 raised by [[User:NTollervey|ntoll]].
*# ''With regard to the "skill" attributes in a resume: often skills have an indication of the level of attainment - be it as a descriptive "tag" or a duration denoting the length of experience of the referenced skill. In fact, abstracting out a "skill" microformat might be useful for re-use in the job-listing (Vacancy?) microformat. That way, job requirements can be married to CVs. Although not a job-site, I like Sourceforge.net's skill inventory feature (that captures both a level and length of experience) although I think its implementation is horrendous.''

* {{OpenIssue}} 2006-10-19 raised by [[RyanKing]].
*# ''There's currently no way to say 'present' in hCalendar''
*#* Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html correctly pointed out] that a blank DTEND does not indicate that the event is still ongoing. We need to find an easy way to make this work in hResume.

* {{OpenIssue}} 2006-10-19 raised by [[User:Steve Ganz|Steve Ganz]].
*# ''There's currently no way to distinguish different hCard types in hResume''
*#* In Draft, version 0.1 it is specified that a parent element of <code>address</code> should be used to the distinguish an hCard as the subject's contact info. This proves problematic to implement because <code>address</code> cannot contain block level elements. To avoid sacrificing semantic value by restricting the child elements of an hCard to inline elements, we need to settle on an alternate method to classify a subject's hCard as thier contact info.
*#* In any given experience there may be one or more hCards. One which would be the subject's hCard for that experience and the other for a supervisor or manager, etc. We need a way to distinguish different hCards in a given experience.

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Related Pages ==
{{hresume-related-pages}}

hresume-issues-fr

2007-05-01T13:01:15Z

Gazza: /* Problématique */ Fixed broken link

<h1> Problématiques hResume </h1>

Ce sont des problématiques soulevées à l'extérieur à propos de [[hresume-fr|hResume]] avec différents degrés de mérites. Par conséquent, certaines problématiques sont REJETEES pour un certain nombre de raisons évidentes (mais encore documentées ici au cas où elles réapparaissent à nouveau), et d'autres qui contiennent de plus longues discussions. Quelques problématiques peuvent être ACCEPTEES et peut-être amener à des modifications ou explications améliorées dans la spécification. Les problématiques proposées peuvent et seront (probablement) éditées et récrites pour une meilleure concision, clarté, rationnalité et si possible avec un point de vue aussi neutre que possible. Ecrivez bien vos problématiques. — [http://tantek.com/log/ Tantek]

Voir les [[hcalendar-issues-fr|problématiques hcalendar]] apparentées.
Voir les [[hcard-issues-fr|problématiques hcard]] apparentées.

__TOC__

== Problématique ==

* {{OpenIssue-fr}} 2007-01-04 soulevée par [[User:NTollervey|ntoll]].
*# ''Eu égard aux attributs "skills" dans un résumé : souvent les compétences sont une indication du niveau d'accomplissement - que ce soit un "tag" descriptif ou une durée indiquant la longueur de l'expérience de la compétence référencée. En fait, le fait d'extraire un résumé d'un microformat "skill" pourrait être utile pour une réutilisation dans le microformat de liste d'annonce (disponibilité "vacancy" ?). De ce fait, les exigences de job pourraient être mariées vers les CVs. Même si ce n'est pas un site d'emploi, j'aime la fonctionnalité skill de Sourceforge.net (qui saisit à la fois un niveau et une longueur d'expérience) même si je pense que son implémentation est épouvantable.''

* {{OpenIssue-fr}} 2006-10-19 soulevée par [[RyanKing]].
*# ''Il n'y a actuellement pas moyen de dire 'present' dans hCalendar''
*#* Beaucoup de listes d'expériences de jobs inclueront le fait que la personne est en train de travailler actuellement. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html a souligné avec pertinence] qu'un DTEND blanc n'indique pas que l'événement est encore en cours. Nous aons besoin de trouver un moyen facile de faire fonctionner cela dans le hResume.

* {{OpenIssue-fr}} soulevée le 2006-10-19 par [[User:Steve Ganz|Steve Ganz]].
*# ''Il n'y a actuellement pas moyen de distinguer différents types de hCard dans hResume''
*#* Dans la version 0.1 draft il est spécifié qu'un élément parent de <code>address</code> devrait être utilisé pour distinguer une hCard comme l'info contact du sujet. Ce s'avère problématique à mettre en oeuvre du fait que <code>address</code> ne pas contenir des éléments de niveau bloc. Pour éviter de sacrifier la valeur sémantique en restreignant les éléments enfants d'une hCard à des éléments dans la ligne, nous avons besoin d'installer une méthode alternative pour classifier un hCard d'un sujet comme son info de contact.
*#* Dans toute expérience donnée il peut y avoir une ou plusieurs hCards. Une qui devrait être la hCard du sujet pour cette expérience et l'autre pour un superviseur ou manager, etc. Nous avons besoin d'un moyen de distinguer différentes hCards dans une expérience donnée.

== Gabarit ==

SVP utilisez ce format (copiez et collez cela à la fin de la liste pour ajouter vos problématiques) :
* {{OpenIssue-fr}} AAAA-MM-JJ soulevé par [http://yourhomepage.exemple.com VOTRENOM].
*# ''Problématique 1 : Voici le premier problème que j'ai.''
*# ''Problématique 2 : Voici le second problème que j'ai.''

== Pages en rapport ==
{{hresume-related-pages-fr}}

hatom-issues

2007-05-01T12:58:39Z

Gazza: Fixed broken links

__TOC__

= Cited example issue =

= Cited example issue =

Andy Mabbett moved the Joomla! Melbourne User Group link to the "Examples with some problems" area of [[hatom]] and I was wondering what the problem is with it... as Operator and Tails have no problems identifying the hAtomised content. which is why I'm confused by Andy's comments about no cited examples. Can someone please offer some assistance?
:I didn't find any hAtom content on that page. I can see it now, so have moved it back. Apologies if I was mistaken. [[User:AndyMabbett|Andy Mabbett]] 01:29, 25 Feb 2007 (PST)

= hAtom 0.2 =

This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.

==Geo==
*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom|hAtom]] to represent GeoRSS element

== Relationship of rel-bookmark to url+uid ==
The concept of permalink is available in [[hcard|hCard]] and [[hcalendar|hCalendar]] as the classes ''url'' and ''uid''. This combination matches the permalink semantics by indicating that the URL should be dereferenced to find a more dynamic or up-to-date version of the content, and that that URL is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the hCard and hCalendar permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconciliation's include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

== Feed XXX (atom:xxx) ==

Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

== Datetime format (atom:updated and atom:published) ==
2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]

Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.

== Feed id (atom:id) ==
2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]

atom:id is required for atom:feed. Thus it should be available in hAtom to.
The Feed permalink should be used as the feed ID.

== Feed permalink (atom:permalink) ==
2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]

I'm proposing the following rules:

* a Feed Permalink element is identified by [[rel-bookmark]] at the feed level*
* a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
* a Feed Permalink element represents the concept of an Atom link in a feed.
* if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.

: 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
: 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
: "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
: IMO this would be good enough for at least 80% of the cases.

* 2006-04-12 [[User:DavidJanes|DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.

* [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

== Feed updated (atom:updated) ==
2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]

atom:updated is required for atom:feed. Thus it should be available in hAtom to.
I'm proposing the following rules:

* The Feed Updated element is identified by the class name <code>updated</code> at the feed level*
* If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.

Algorithm:

<pre>
$a = array();
for each $entry in $feed {
if ($entry.updated)
$a.add(pad_datetime($entry.updated))
else
$a.add(pad_datetime($entry.published))
}
$a.sort_by( datetime_to_utc($element) )
$feed_updated = $a[0];
</pre>

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* 2006-04-12 [[User:DavidJanes|DavidJanes]] I like this. And the definition of "feed level"

== Feed title (atom:title) ==
2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]

atom:title is required for atom:feed. Thus it should be available in hAtom to.

I'm proposing the following rules:

* a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
* a Feed SHOULD have an Feed Title
* a Feed Title element represents the concept of an Atom feed title
* if the Feed Title is missing, use
** <del>the first <code><h#></code> element in the Feed, or</del>
** the <code><title></code> of the page, or
** assume it is the empty string

* 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.

:: 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
:: 2006-04-12 [[User:DavidJanes|DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings

* 2006-04-12 [[User:DavidJanes|DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?

: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.

* 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

== Feed author and Entry author (atom:author) ==
2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]

I'm proposing the following rules for Feed author:

* a Feed Author element is represented by class name <code>author</code> at the feed level*
* a Feed Author element represents the concept of a Atom author
* a Feed Author element MUST be encoded in a [[hcard|hCard]]
* a Feed Author element SHOULD be encoded in a <code><address></code> element
* a Feed MAY have more than one Feed Author elements
* if the Feed Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>

I'm proposing the following rules for entry author:

* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an Atom author
* an Entry Author element MUST be encoded in an [[hcard|hCard]]
* an Entry Author element SHOULD be encoded in an <code><address></code> element
*<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
* <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the Entry is invalid hAtom
</ins>
* an Entry MAY have more than one Entry Author elements
<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
: 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

== Entry XXX (atom:xxx) ==

Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

== Entry id (atom:id) ==
2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]

atom:id is required for atom:entry. Thus it should be available in hAtom to.

The Entry permalink should be used as the entry id.

* --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.

2006-12-31 response by [[User:ComputerKid|Emanla Eraton]]

No, it shouldn't be a permalink. It should be a "tag:" id for entries.

== Author ==

=== author as an hcard is too much to require ===

The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[User:Tantek|Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[User:pnhChris|pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[User:Tantek|Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[User:Tantek|Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

== Other Questions and Issues ==

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Required? -- Blogger Issue ===
The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? -- [[User:Singpolyma|singpolyma]] 05:45, 28 Mar 2006 (PST)

* [[User:DavidJanes|DavidJanes]]: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example <code>title="day month-name year, hour12:minute ampm tz"</code>) but I think this is asking too much from creators and parsers.

** [[User:Singpolyma|singpolyma]] 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats. My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs ''cannot'' be parsed by other's hAtom parers as hAtom is now unless they too are so leniant.

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
The [[hatom|hAtom]] 0.1 spec states the follwing two items about the Feed element:

# the Feed element is optional and, if missing, is assumed to be the page
# hAtom documents MAY have multiple Feed elements

I'm concerned about the implementation details of multiple feeds and that the current 0.1 spec isn't sufficient to define multiple distinct feeds in a single html document and that even if some of those areas were modified if there are real mechanisms out there to support a document with multiple feeds.

To provide examples of how multiple feeds might reside in a document under hAtom 0.1 I've created this collection of [http://placenamehere.com/mf/hatom_tests/ hAtom multiple feed tests]

Some of the questions that need to be answered (more details and some conclusions at a later time):

# Can a unique reference be made to each feed? Are there ambiguous references?
# Can a unique label or feed name be generated from each feed for the purpose of selection by the subscriber?
#* Using the feed title seems to be an option. It is likely (thought not guaranteed) that it is unique.
# What changes need to be made to the spec to make the publishing of multiple feeds in a document less ambiguous?
#* [[User:RobertBachmann|Robert Bachmann]] (2006-05-23): IMO the simplest soultion would be to require that each feed element MUST have an XHTML id attribute.
# What rules are needed for the detection, selection and consumption of feed documents so that people can select and maintain a subscription to the proper feed?
# How should a consuming application deal with potential changes to feeds found in a document over time (either id changes, additional feeds added, removal of feed, etc)? (this issue could be generalized to single feed documents as well)
# [[User:ChrisCasciano|Chris Casciano]] (2006-07-24): A good chat session on this issue can be found [http://rbach.priv.at/Microformats-IRC/2006-05-25#T224929 here]

==== Draft Rules for multiple feeds ====
(2006-07-24): Written by [[User:ChrisCasciano|Chris Casciano]]

* If there is only one feed on a page spec+parsing rules from 0.1 apply
* If there are multiple feeds, each feed should explicitly define the root hfeed element with both class="hfeed" and a fragment identifier (id).
* Specific feeds can be addressed via their fragment id.
* If no fragment id is specified for a page with multiple hatom feeds then their content is merged via atom's SOURCE semantics

===== Discussion of Draft Rules =====
* Issue: what is the result of trying to address a feed at a non-existing fragment identifier? Same as no fragment id specified, or a not found error?
* Issue: for authors, is there any way we can control a redirect for a feed addressed via fragment id?
* Issue: are there any other long term management issues or other authoring considerations we need to think about for 0.2?
* Issue: is the reliance on class + id too strict? we may be losing other non-ambiguous constructs for sake of simplicity (e.g. roots are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)

= hAtom 0.1 =

'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).

__TOC__

== Contributors ==
* Danny Ayers
* Robert Bachmann
* Paul Bryson
* Benjamin Carlyle
* Chris Casciano
* Tantek Çelik
* David Janes
* Ryan King
* Kevin Marks
* Scott Reynen
* Brian

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])'''

=== Initial proposal ===

<code>atomfeed</code> (or rather, "atom-entry")

* [[User:DannyAyers|DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
* [[User:DavidJanes|DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
* [[User:DavidJanes|DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[User:DavidJanes|DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[User:Tantek|Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[User:DannyAyers|DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --
* [[User:Tantek|Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
* [[User:Tantek|Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** hfeed

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

* <code>feed</code> (Atom consistency)
* <code>atom-feed</code> (Atom consistency with prefix)
* <code>hfeed</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 MarkRickerby
** +1 DannyAyers

==== Discussion ====

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[User:Tantek|Tantek]]

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Initial Proposal ===

<code>atomentry</code> (or rather, "atom-entry")

* [[User:DannyAyers|DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[User:DannyAyers|DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** [[User:Tantek|Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[User:MarkRickerby|MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[User:DavidJanes|DavidJanes]]
** +1 [[User:Tantek|Tantek]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[User:MarkRickerby|MarkRickerby]]
** +1 [[User:DannyAyers|DannyAyers]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[User:Tantek|Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.

== Entry Title (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''

=== proposals ===

The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[User:Tantek|Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[User:Kevin Marks|Kevin Marks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[User:Tantek|Tantek]]
** +1 [[User:Kevin Marks|Kevin Marks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]], atom:entry/title only
** +½ [[User:DavidJanes|DavidJanes]], atom:entry/title only
** +½ [[User:PaulBryson|PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[User:Tantek|Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[User:PaulBryson|PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[User:DavidJanes|DavidJanes]] see my note below
** -1 [[User:Tantek|Tantek]] (does not mean the "name" of the post/entry)
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[User:DavidJanes|DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[User:Tantek|Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name. Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.
* [[User:DavidJanes|DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[User:DavidJanes|DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.
* [[User:DavidJanes|DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[User:PaulBryson|PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==

'''STATUS - RESOLVED going with entry-content'''

* <code>content</code> (Atom consistency)
** -1 [[User:Tantek|Tantek]]
** +1 [[User:DavidJanes|DavidJanes]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[User:ChrisCasciano|ChrisCasciano]]
** -1 Kevin Marks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 Kevin Marks
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[User:Tantek|Tantek]]
** +1 Kevin Marks
** +1 [[User:ChrisCasciano|ChrisCasciano]]
* <code>atom-content</code>
** +0.5 [[User:Tantek|Tantek]]
* <code>hcontent</code>
** -1 [[User:Tantek|Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.

=== Discussion ===
* [[User:Tantek|Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
* [[User:ChrisCasciano|ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
* [[User:Tantek|Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".
* [[User:Tantek|Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.
* [[User:ChrisCasciano|ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
* [[User:Kevin Marks|Kevin Marks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.
* [[User:ChrisCasciano|ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')

== Entry Summary (atom:summary) ==

'''STATUS - RESOLVED - going with 'entry-summary''''

The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[User:Tantek|Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 Kevin Marks
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs

=== Discussion ===
* [[User:Tantek|Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think Tantek is simply suggesting that the 80% win in this case.
* [[User:Tantek|Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. In addition:
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.
* [[User:ScottReynon|ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.
* [[User:ChrisCasciano|ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

* <code>rel="bookmark"</code> (HTML consitency)
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 Kevin Marks

=== Discussion ===
* [[User:Kevin Marks|Kevin Marks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[User:DavidJanes|DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[User:DavidJanes|DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[User:Tantek|Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
** +0.5 [[User:Tantek|Tantek]]
** +1 [[User:DavidJanes|DavidJanes]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +0.5 [[User:Tantek|Tantek]] (want to consider it, while we can)
* <code>VJOURNAL CREATED</code>

=== Discussion ===
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[User:Tantek|Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (or a part thereof)"
* [[User:Tantek|Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.
* [[User:DavidJanes|DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
* [[User:Tantek|Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Updated (atom:updated) ==

'''STATUS - RESOLVED - 'updated''''

* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +½ Paul Bryson, Not as human readable
** +0.5 [[User:Tantek|Tantek]] (want to consider it, while we can)
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[User:PaulBryson|PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[User:Tantek|Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."
* [[User:Tantek|Tantek]]: They are both user defined values but *different* user defined values. It is VERY important to note this distinction because Atom chose to note it.In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.
* [[User:DavidJanes|DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
go back throught [[blog-post-examples]] to see what conventions we have.
* [[User:Tantek|Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Author (atom:author) ==

'''STATUS - RESOLVED - 'author' required, should use <code><address></code>'''

* <code>author</code> (Atom consistency)
** +1 [[User:Tantek|Tantek]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]

=== Discussion ===
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[User:Tantek|Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is <address> not sufficient for 'author' semantics?
* [[User:DimitriGlazkov|DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what <address> implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].

== Entry Contributor (atom:contributor) ==
** -1 Tantek (see Discussion)
* <code>contributor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

=== Discussion ===
* [[User:Tantek|Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
* [[User:DavidJanes|DavidJanes]]: '''RESOLUTION: DEFERRED'''

== Entry Geo (geo:Point) ==
* [[User:Brian|Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

=== GeoRSS Resources ===
* [[User:Brian|Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[User:Brian|Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions and Comments ==

=== Limitations ===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[User:DavidJanes|DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

=== Relationship to hReview definitions needs clarification ===
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

[[User:Tantek|Tantek]]: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

=== hCards ===

[[User:DavidJanes|DavidJanes]]: Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

RESOLVED: MUST use hCard for author.

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[User:Tantek|Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[User:DavidJanes|DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre>has an assumed defined mapping to<pre><nowiki><div class="author vcard">bonehead</div></div></nowiki></pre>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.

=== Comparisons ===

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--[[User:DrErnie|Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).
* [[User:Tantek|Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

=== Repeated Elements ===
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].

Your thoughts please... -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.

=== Opaqueness ===
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.

==== Opaqueness of other microformat elements ====
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- [[User:BenjaminCarlyle|BenjaminCarlyle]]

* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --
* [[User:Tantek|Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.

==== Opaqueness of summary and content ====
[[User:DavidJanes|DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

=== Identification ===
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

=== HTML Title ===
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

=== rel-tag ===
Should hAtom use rel-tag for atom category elements? -- [[User:DavidJanes|DavidJanes]]

* [[User:Tantek|Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

=== Excess disambiguation rules? ===
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

=== Dependencies ===
==== mfo ====
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples]].

=== Is atom:content necessary? ===
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

=== Published as default value for atom:updated ===
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.
: + 1 [[User:RobertBachmann|Robert Bachmann]]

=== Designating the page author ===

(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

* How do I designate the page author(s)?
** <code>class="author"</code> outside of the hAtom entry?
** <code><address class="author"></code> outside of the hAtom entry?
** <code><address></code> outside of the hAtom feed (i.e. at the page level)?
* How do I designate the feed author(s)?

(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.

==== Proposal ====
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.

== Entry Updated Required? -- Blogger ==
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...

= See Also =
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

= Template =

Please use this format (copy and paste this to the end of the list to add your issues):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

hatom-issues-fr

2007-05-01T12:57:27Z

Gazza: Fixed broken links

__TOC__

= hAtom 0.2 =

Cette section est destinées à discuter de ce que vous aimeriez voir dans la prochaine version de hAtom, c'est à dire 0.2.

==Geo==
*2006-02-03 soulevée par Brian
*# Nous pouvons utiliser le microformat [[geo-fr|geo]] dans [[hatom-fr|hAtom]] pour représenter un élément GeoRSS

== Relation de rel-bookmark vers url+uid ==
Le concept de permalien est disponible dans hCard et hCalendar sous les classes url et uid. Cette combinaison fait correspondre la sémantique du permalien en indiquant que l'url devrait être déréréférencée pour trouver une version dynamique ou mise à jour du contenu, et que cette url est un id unique stable qui peut être utilisé pour identifier le contenu.

hAtom 0.1 utilise rel-bookmark pour le concept du permalien. L'état actuel du [[uid-brainstorming-fr]] indique que le concept permalien hCard et hCalendar doit être probablement utilisé dans les microformats subséquents. Ce peut être important de réconcilier hAtom avec cette trajectoire. Les réconciliations possibles comprennent :

1) Laisser les choses telles qu'elles sont. Les deux concepts des permaliens doivent être maintenus séparés.

2) Traiter les deux concepts comme équivalents. Permettre les deux dans hAtom et considérer permettre les deux dans d'autres formats. Par ex <a rel="bookmark" href="http://example.com/"> trouvera les valeurs uid et url si elles ne sont pas fournies explicitement.

3) Choisir l'un sur l'autre pour hAtom et peut être aussi pour les futurs microformats. "url uid" permet quelque plus grande liberté (l'uid peut être pointé comme un uid non url), mais ce n'est pas clair à cette étape si cette liberté est garanties ou recommandable à autoriser.

== Fil XXX (atom:xxx) ==

section Gabarit : s'il y a quelque chose provenant clairement d'un ''Fil'' Atom que vous aimeriez dans hAtom 0.2, utilisez cette section comme un gabarit et répliquez là ici au bon endroit. Voir la section hAtom en dessous pour plus de détails.

== Format Datetime (atom:updated et atom:published) ==
2006-05-23 soulevée [[User:RobertBachmann|Robert Bachmann]]

Atom exige l'utilisation de datetimes RFC3339 alors qu'hAtom 0.1 ne spécifie pas quels formats datetimes peuvent être utilisés.

== Fil id (atom:id) ==
2006-04-01 soulevée par [[User:RobertBachmann|Robert Bachmann]]

atom:id est requis pour atom:feed. De ce fait ce devrait être disponibles aussi dans hAtom.
Le permalien Feed devrait être utilisé comme le feed id.

== Feed permalink (atom:permalink) ==
2006-04-01 soulevée [[User:RobertBachmann|Robert Bachmann]]

Je propose les règles suivantes :

* a Feed Permalink element is identified by [[rel-bookmark]] at the feed level*
* a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
* a Feed Permalink element represents the concept of an Atom link in a feed.
* if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.

: 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
: 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
: "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
: IMO this would be good enough for at least 80% of the cases.

* 2006-04-12 [[User:DavidJanes|DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.

* [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

== Feed updated (atom:updated) ==
2006-04-01 soulevé [[User:RobertBachmann|Robert Bachmann]]

atom:updated is required for atom:feed. Thus it should be available in hAtom to.
I'm proposing the following rules:

* The Feed Updated element is identified by the class name <code>updated</code> at the feed level*
* If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.

Algorithm:

<pre>
$a = array();
for each $entry in $feed {
if ($entry.updated)
$a.add(pad_datetime($entry.updated))
else
$a.add(pad_datetime($entry.published))
}
$a.sort_by( datetime_to_utc($element) )
$feed_updated = $a[0];
</pre>

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* 2006-04-12 [[User:DavidJanes|DavidJanes]] I like this. And the definition of "feed level"

== Feed title (atom:title) ==
2006-04-01 souvlevée par [[User:RobertBachmann|Robert Bachmann]]

atom:title is required for atom:feed. Thus it should be available in hAtom to.

I'm proposing the following rules:

* a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
* a Feed SHOULD have an Feed Title
* a Feed Title element represents the concept of an Atom feed title
* if the Feed Title is missing, use
** <del>the first <code><h#></code> element in the Feed, or</del>
** the <code><title></code> of the page, or
** assume it is the empty string

* 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.

:: 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
:: 2006-04-12 [[User:DavidJanes|DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings

* 2006-04-12 [[User:DavidJanes|DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?

: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.

* 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

== Feed author et Entrée author (atom:author) ==
2006-04-01 soulevée par [[User:RobertBachmann|Robert Bachmann]]

I'm proposing the following rules for Feed author:

* a Feed Author element is represented by class name <code>author</code> at the feed level*
* a Feed Author element represents the concept of a Atom author
* a Feed Author element MUST be encoded in a [[hcard|hCard]]
* a Feed Author element SHOULD be encoded in a <code><address></code> element
* a Feed MAY have more than one Feed Author elements
* if the Feed Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>

I'm proposing the following rules for entry author:

* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an Atom author
* an Entry Author element MUST be encoded in an [[hcard|hCard]]
* an Entry Author element SHOULD be encoded in an <code><address></code> element
*<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
* <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the Entry is invalid hAtom
</ins>
* an Entry MAY have more than one Entry Author elements
<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
: 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

== Entrée XXX (atom:xxx) ==

Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

== Entrée id (atom:id) ==
2006-04-01 soulevée par [[User:RobertBachmann|Robert Bachmann]]

atom:id est requis pour atom:entry. De ce fait il devrait être dipsonible aussi dans hATom.

L'Entrée permalien devrait être utilisée comme l'id d'entrée.

* --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT) : J'ajouterais "Seulement si l'attribut id n'est pas défini pour l'élément qui contient l'entrée.3 L'attribut id peut être un uri tag. Si vous utilisez toujours le permalient Entry comme l'id d'entrée et le fil Atom utilise les tags uris, vous finiriez avec deux ids différents pour la même entrée/

2006-12-31 réponse par [[User:ComputerKid|Emanla Eraton]]
Non, ce ne devrait pas être un permalien. Ce devrait être un "tag:" id pour les entrées.

== Author ==

=== author en tant que hCard est bien trop comme exigence ===

The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[User:Tantek|Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[User:pnhChris|pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[User:Tantek|Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.

* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[User:Tantek|Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

== Autres Questions et Problématiques ==

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Exigée ? -- Problématique de Blogger ===
The [[hatom-fr|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? -- [[User:Singpolyma|singpolyma]] 05:45, 28 Mar 2006 (PST)

* [[User:DavidJanes|DavidJanes]]: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example <code>title="day month-name year, hour12:minute ampm tz"</code>) but I think this is asking too much from creators and parsers.

** [[User:Singpolyma|singpolyma]] 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats. My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs ''cannot'' be parsed by other's hAtom parers as hAtom is now unless they too are so leniant.

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
The [[hatom-fr|hAtom]] 0.1 spec states the follwing two items about the Feed element:

# the Feed element is optional and, if missing, is assumed to be the page
# hAtom documents MAY have multiple Feed elements

I'm concerned about the implementation details of multiple feeds and that the current 0.1 spec isn't sufficient to define multiple distinct feeds in a single html document and that even if some of those areas were modified if there are real mechanisms out there to support a document with multiple feeds.

To provide examples of how multiple feeds might reside in a document under hAtom 0.1 I've created this collection of [http://placenamehere.com/mf/hatom_tests/ hAtom multiple feed tests]

Some of the questions that need to be answered (more details and some conclusions at a later time):

# Can a unique reference be made to each feed? Are there ambiguous references?
# Can a unique label or feed name be generated from each feed for the purpose of selection by the subscriber?
#* Using the feed title seems to be an option. It is likely (thought not guaranteed) that it is unique.
# What changes need to be made to the spec to make the publishing of multiple feeds in a document less ambiguous?
#* [[User:RobertBachmann|Robert Bachmann]] (2006-05-23): IMO the simplest soultion would be to require that each feed element MUST have an XHTML id attribute.
# What rules are needed for the detection, selection and consumption of feed documents so that people can select and maintain a subscription to the proper feed?
# How should a consuming application deal with potential changes to feeds found in a document over time (either id changes, additional feeds added, removal of feed, etc)? (this issue could be generalized to single feed documents as well)
# [[User:ChrisCasciano|Chris Casciano]] (2006-07-24): A good chat session on this issue can be found [http://rbach.priv.at/Microformats-IRC/2006-05-25#T224929 here]

==== Règles Brouillons pour plusieurs fils ====
(2006-07-24): Written by [[User:ChrisCasciano|Chris Casciano]]

* If there is only one feed on a page spec+parsing rules from 0.1 apply
* If there are multiple feeds, each feed should explicitly define the root hfeed element with both class="hfeed" and a fragment identifier (id).
* Specific feeds can be addressed via their fragment id.
* If no fragment id is specified for a page with multiple hatom feeds then their content is merged via atom's SOURCE semantics

===== Discussion de Règles Brouillons =====
* Issue: what is the result of trying to address a feed at a non-existing fragment identifier? Same as no fragment id specified, or a not found error?
* Issue: for authors, is there any way we can control a redirect for a feed addressed via fragment id?
* Issue: are there any other long term management issues or other authoring considerations we need to think about for 0.2?
* Issue: is the reliance on class + id too strict? we may be losing other non-ambiguous constructs for sake of simplicity (e.g. roots are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)

= hAtom 0.1 =

'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).

__TOC__

== Contributeurs ==
* Danny Ayers
* Robert Bachmann
* Paul Bryson
* Benjamin Carlyle
* Chris Casciano
* Tantek Çelik
* David Janes
* Ryan King
* Kevin Marks
* Scott Reynen
* Brian

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])'''

=== Proposition Initiale ===

<code>atomfeed</code> (or rather, "atom-entry")

* [[User:DannyAyers|DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
* [[User:DavidJanes|DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
* [[User:DavidJanes|DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[User:DavidJanes|DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[User:Tantek|Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[User:DannyAyers|DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --
* [[User:Tantek|Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
* [[User:Tantek|Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** hfeed

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

* <code>feed</code> (Atom consistency)
* <code>atom-feed</code> (Atom consistency with prefix)
* <code>hfeed</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 MarkRickerby
** +1 DannyAyers

==== Discussion ====

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[User:Tantek|Tantek]]

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Proposition Initiale===

<code>atomentry</code> (or rather, "atom-entry")

* [[User:DannyAyers|DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[User:DannyAyers|DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** [[User:Tantek|Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[User:MarkRickerby|MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[User:DavidJanes|DavidJanes]]
** +1 [[User:Tantek|Tantek]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
** +1 [[User:RyanKing|RyanKing]]
** +1 [[User:MarkRickerby|MarkRickerby]]
** +1 [[User:DannyAyers|DannyAyers]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[User:RyanKing|RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[User:Tantek|Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in [[hcalendar|hCalendar]] (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from [[hcalendar|hCalendar]], and pointing folks to use [[hatom|hAtom]] instead, even in the context of an [[hcalendar|hCalendar]] element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and [[hatom|hAtom]] properties so that [[hatom|hAtom]] inside an [[hcalendar|hCalendar]] could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create [[hatom|hAtom]] via the journal feature of said tool.

== Entrée Titre (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''

=== propositions ===

The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[User:Tantek|Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[User:Kevin Marks|Kevin Marks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[User:Tantek|Tantek]]
** +1 [[User:Kevin Marks|Kevin Marks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]], atom:entry/title only
** +½ [[User:DavidJanes|DavidJanes]], atom:entry/title only
** +½ [[User:PaulBryson|PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[User:Tantek|Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[User:PaulBryson|PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[User:DavidJanes|DavidJanes]] see my note below
** -1 [[User:Tantek|Tantek]] (does not mean the "name" of the post/entry)
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[User:DavidJanes|DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[User:Tantek|Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name. Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.
* [[User:DavidJanes|DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[User:DavidJanes|DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.
* [[User:DavidJanes|DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[User:PaulBryson|PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==

'''STATUS - RESOLVED going with entry-content'''

* <code>content</code> (Atom consistency)
** -1 [[User:Tantek|Tantek]]
** +1 [[User:DavidJanes|DavidJanes]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[User:ChrisCasciano|ChrisCasciano]]
** -1 Kevin Marks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 Kevin Marks
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[User:Tantek|Tantek]]
** +1 Kevin Marks
** +1 [[User:ChrisCasciano|ChrisCasciano]]
* <code>atom-content</code>
** +0.5 [[User:Tantek|Tantek]]
* <code>hcontent</code>
** -1 [[User:Tantek|Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.

=== Discussion ===
* [[User:Tantek|Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
* [[User:ChrisCasciano|ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
* [[User:Tantek|Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".
* [[User:Tantek|Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.
* [[User:ChrisCasciano|ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
* [[User:Kevin Marks|Kevin Marks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.
* [[User:ChrisCasciano|ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')

== Entry Summary (atom:summary) ==

'''STATUS - RESOLVED - going with 'entry-summary''''

The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[User:Tantek|Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 Kevin Marks
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs

=== Discussion ===
* [[User:Tantek|Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
* [[User:Tantek|Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. In addition:
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.
* [[User:ScottReynon|ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.
* [[User:ChrisCasciano|ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

* <code>rel="bookmark"</code> (HTML consitency)
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 Kevin Marks

=== Discussion ===
* [[User:Kevin Marks|Kevin Marks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[User:DavidJanes|DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[User:DavidJanes|DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[User:Tantek|Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
** +0.5 [[User:Tantek|Tantek]]
** +1 [[User:DavidJanes|DavidJanes]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +0.5 [[User:Tantek|Tantek]] (want to consider it, while we can)
* <code>VJOURNAL CREATED</code>

=== Discussion ===
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[User:Tantek|Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (or a part thereof)"
* [[User:Tantek|Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.
* [[User:DavidJanes|DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
* [[User:Tantek|Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Updated (atom:updated) ==

'''STATUS - RESOLVED - 'updated''''

* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +½ Paul Bryson, Not as human readable
** +0.5 [[User:Tantek|Tantek]] (want to consider it, while we can)
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[User:PaulBryson|PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[User:Tantek|Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."
* [[User:Tantek|Tantek]]: They are both user defined values but *different* user defined values. It is VERY important to note this distinction because Atom chose to note it.In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.
* [[User:DavidJanes|DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
go back throught [[blog-post-examples]] to see what conventions we have.
* [[User:Tantek|Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Author (atom:author) ==

'''STATUS - RESOLVED - 'author' required, should use <code><address></code>'''

* <code>author</code> (Atom consistency)
** +1 [[User:Tantek|Tantek]]
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]

=== Discussion ===
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[User:Tantek|Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is <address> not sufficient for 'author' semantics?
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what <address> implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].

== Entry Contributor (atom:contributor) ==
** -1 Tantek (see Discussion)
* <code>contributor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

=== Discussion ===
* [[User:Tantek|Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
* [[User:DavidJanes|DavidJanes]]: '''RESOLUTION: DEFERRED'''

== Entry Geo (geo:Point) ==
* [[User:Brian|Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

=== Ressources GeoRSS ===
* [[User:Brian|Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[User:Brian|Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions et Commentaires ==

=== Limites===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[User:DavidJanes|DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

=== Les relations vers les définitions hReview ont besoin de clarification ===
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

[[User:Tantek|Tantek]]: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

=== hCards ===

[[User:DavidJanes|DavidJanes]]: Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

RESOLVED: MUST use hCard for author.

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[User:Tantek|Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[User:DavidJanes|DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre>has an assumed defined mapping to<pre><nowiki><div class="author vcard">bonehead</div></div></nowiki></pre>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.

=== Comparisons ===

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--[[User:DrErnie|Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).
* [[User:Tantek|Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

=== Eléments répétés===
Nous permettons à certains éléments d'être répétés, comme un Permalien d'Entrée, l'Entrée Publiée et le Titre de l'Entreée, même s'il peut y avoir au plus une valeur réelle. Nous fournissons des règles de "désambiguation" pour trouver quelle est la vraie valeur. Voir [[hatom-fr#Nesting_Rules|ici]], [[hatom-fr#Entrée_Title|ici]], [[hatom-fr#Entrée_Permalink|ici]] et [[hatom#Entrée_Publiée|ici]].

Vos idées, svp... -- [[User:DavidJanes|David Janes]]

'''STATUT - RESOU'''. La spec a des règles explicites de désambiguation pour tous ces items s'ils apparaissent plusieurs fois.

=== Opacité ===
Si vous avez des soucis à propos de l'[[hatom-fr#hAtom_Opaque-fr|opacité]], ce qui veut dire arrêter l'interprétation en dessous de certains éléments hAtom, soulevez-les là.

==== Opacité des autres éléments microformat ====
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- [[User:BenjaminCarlyle|BenjaminCarlyle]]

* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --
* [[User:Tantek|Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.

==== Opacité du résumé et du contenu ====
[[User:DavidJanes|DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

=== Identification ===
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

=== HTML Title ===
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

=== rel-tag ===
Should hAtom use rel-tag for atom category elements? -- [[User:DavidJanes|DavidJanes]]

* [[User:Tantek|Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

=== Excess disambiguation rules? ===
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

=== Dépendances ===
==== mfo ====
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples-fr]].

=== Is atom:content necessary? ===
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

=== Published as default value for atom:updated ===
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.
: + 1 [[User:RobertBachmann|Robert Bachmann]]

=== Désigner l'auteur de la page ===

(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

* How do I designate the page author(s)?
** <code>class="author"</code> outside of the hAtom entry?
** <code><address class="author"></code> outside of the hAtom entry?
** <code><address></code> outside of the hAtom feed (i.e. at the page level)?
* How do I designate the feed author(s)?

(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.

==== Proposition ====
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.

== Entry Updated Obligé ? -- Blogger ==
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].
*# The [[hatom-fr|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern-fr]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...

= See Also =
* [[hatom-fr|hAtom]] - la proposition draft
* [[hatom-faq-fr|hAtom-faq]] - base de connaissance
* [[blog-post-brainstorming-fr|billets de blogs-brainstorming]]
* [[blog-post-formats-fr|billets de blogs-formats]]
* [[blog-post-examples-fr|billets de blogs - exemples]]
* [[blog-description-format-fr]] - comme décrire un blog (à l'opposition des entrées individuelles, ce qui est ce que nous faisons ici)
* [[mfo-examples-fr|mfo-exemples]]
* [[naming-principles-fr|principes de nommage]]

= Gabarit =

SVP utilisez ce format (copiez et coller ça à la fin de la liste pour ajouter vos problématiques) :
* AAAA-MM-JJ soulevé par [http://votrepageperso.exemple.com VOTRENOM].
*# ''Problématique 1 : Voici la première problématique que je rencontre.''
*# ''Problématique 2 : Voici la seconde problématique que je rencontre.''

xfolk-issues

2007-05-01T12:55:31Z

Gazza: Fixed broken link

= xFolk issues =

These are externally raised issues about [[xfolk|xFolk]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://thecommunityengine.com/home Bud]

== Template ==
Please use this format:
* <nowiki>{{OpenIssue}}</nowiki> YYYY-MM-DD raised by AUTHORNAME
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Issues ==

* {{OpenIssue}} 2007-01-01 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Applying a tag in an xFolk entry also applies it to the linking page. However, certain tags (e.g. "NSFW") may apply to the page linked to, but '''''not''''' to the linking page.

2007-01-03 addressed by [[User:Bud|Bud Gibson]]. Well, we had a lot of list discussion on this while creating xFolk. Actually, that was pre-list. The rationale is that the tags apply to the items in the container not the page simply by convention in xFolk. It's a specialization of reltag. The real question I think is what are the scoping rules for reltag. The assumption here is that the reltag tags only apply to the link within xfolkentry.

* {{OpenIssue}} *Why is this called "xFolk", and not, say, xBookmark(s) or hBookmark(s)? [[User:AndyMabbett|Andy Mabbett]] 09:16, 19 Nov 2006 (PST)

2007-01-03 addressed by [[User:Bud|Bud Gibson]]. Mainly because the purpose of the microformat was originally to allow harvesting into aggregation services for creating "folksonomies".

* {{OpenIssue}} 2006-06-12 raised by [[User:Singpolyma|singpolyma]]
*# ''using title attribute for the tagged link <a> element, if it exists, as the entry title'' -- I use the title attribute for a summary description, since this is more [[XOXO]]-compatible. While I lose the ability to have xfolk harvest my descriptions that way, I'm not really worried about that. What I'm more worried about is xfolk using my descriptions as the title...

2007-01-03 addressed by [[User:Bud|Bud Gibson]]. I'm in a quandary as to how to address this one. It seems like a basic incompatibility.

* {{OpenIssue}} 2006-04-20 raised by [[User:RCanine|Ryan Cannon]]
*# ''Issue 1: As xFolk is intended as a list, it seems tedious to have to place <code>class="xfolkentry"</code> on every element. Are there implementation problems with creating a container class with that implies <code>class="xfolkentry"</code> on every child node?.''

* {{OpenIssue}} 2007-04-27 raised by [[User:Kevin Marks|Kevin Marks]]
*# I wondered why xfolk uses class="taggedlink" rather than rel="taggedlink" as a rel value seems more semantic for labelling the link.

==Related pages==
{{template:xfolk-related-pages}}