hcard-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(minor tweaks, plus noted that encoding org contact info was accepted (a while ago))
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(198 intermediate revisions by 38 users not shown)
Line 1: Line 1:
<h1> hCard Brainstorming </h1>
{{DISPLAYTITLE: hCard Brainstorming }}
This page is for brainstorming about various uses and details of [[hcard|hCard]].
This page is for brainstorming about various uses and details of [[hcard|hCard]].  This page contains <em>proposals</em>.  For the current state please see [[hcard|hCard]].


__TOC__
Brainstorm proposals that illustrate how to use the existing hCard spec will likely be incorporated into existing hCard documentation such as:
* [[hcard-authoring]]
* [[hcard-examples]]
* ... and potentially additional documentation.


== Authors ==
Proposals that are minor bug fixes or enhancements may be incorporated into hCard 1.0.1. See the [[#for_hCard_1.0.1|for hCard 1.0.1 section]] below.
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]


== Contributors ==
Proposals that are more substantial enhancements such as new hCard properties may be incorporated into hCard 1.1. See the [[#for_hCard_1.1|for hCard 1.1 section]] below.
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* ...
* ... and many others


== Examples ==
== Editors ==
 
* [http://suda.co.uk/ Brian Suda]
* 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].
* [http://tantek.com/ Tantek Çelik]
 
=== 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>
== Problems Being Solved ==
<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
Some of the problems that [[hcard|hCard]] helps to solve:


* 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)
* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* annoying "update your contact info" email from various centralized contact info services
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]
* [[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]]
 
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 ==
== Encoding "modern" attributes ==
Line 70: Line 35:


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


== CSS Styles ==
A suggestion relating to the rise of VoIP protocol (Skype, etc):
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, then you can hide that tag in CSS with the following code:
Should these protocols be marked up using the <code><nowiki><span type="tel"></nowiki></code>. It seems logical that a means to communicate with another via voice should be marked up as a telephone address, rather than the currently suggested URL property.
<pre><nowiki>
<span style="display: none">Hidden Data</span>
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.


== Auto-Discovery ==
== Auto-Discovery ==
There is currently a debate over the best way to add an auto discovery link to your HTML to extract the vCard.


On the page with the hCard encoding, the best link would be as follows:
See [[hcard-brainstorming-autodiscovery]]
<code><nowiki> <link rel="alternate" type="text/vcard" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.
 
[[User:EtanWexler|EtanWexler]] disagrees with the value of the “type” attribute. The [http://www.iana.org/ Internet Assigned Numbers Authority] has no registration for a “text/vcard” type. 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. So a different rel type must be established to decribe that relationship. The ideas vary from specific to vague. The list and categories follow:
<pre><nowiki>
rel="contactinfo"
rel="profile"
rel="author"
rel='PIM'
rel='person'
rel='about'
rel='contact'
rel='hcard'
rel='microformat'
</nowiki></pre>
Example of mixing two rel types to a single page.
rel="hcard xfn"
 
Note: using rel="vcard" indicates a link directly to a vCard. If the document links to an hCard instead, the indication is untrue and inappropriate.
 
=== 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 ==
== geo improvements ==
''See [[geo-brainstorming]]''


These improvements apply to both [[geo]] and [[hcard|hCard]].
== how to use with HTML5 ==
 
Per [http://lists.w3.org/Archives/Public/public-html/2009Jun/0811.html Theresa O'Connor's email to public-html]:
I (Tantek) have seen examples of where there is a human viewable/clickable presentation of a point on a map, and the desire to include the machine readable geo information with the same element, e.g. something like:
Add a section in hCard describing how to use hCard in [[HTML5]], including optional use of HTML5's &lt;time&gt; element and microdata feature. Encourage [[HTML5]] to drop the "vcard" predefined microdata vocabulary and reference an updated hCard spec instead. [[User:Tantek|Tantek]]
 
<pre><nowiki>
<abbr class="geo" title="machine-readable-geo-info">
human readable/clickable point on a map
</abbr>
</nowiki></pre>
 
But to do this we must specify a syntax for putting both the latitude and longitude into the title attribute as the machine-readable-geo-info.
 
Fortunately, there already is a syntax for that, in vCard RFC 2426 3.4.2:
<pre>
  Type value: A single structured value consisting of two float values
  separated by the SEMI-COLON character (ASCII decimal 59).
 
  Type special notes: This type specifies information related to the
  global position of the object associated with the vCard. The value
  specifies latitude and longitude, in that order (i.e., "LAT LON"
  ordering).
 
...
 
  Type example:
 
        GEO:37.386013;-122.082932
</pre>
 
Thus:
<pre><nowiki>
<abbr class="geo" title="37.386013;-122.082932">
Mountain View, CA
</abbr>
</nowiki></pre>
 
I think this is pretty much a no-brainer, because the rules for parsing "geo" are simply altered to:
 
 
=== latitude longitude shorthand ===
 
If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property  (e.g. following rules for parsing <code><nowiki><abbr title></nowiki></code>, <code><nowiki><img alt></nowiki></code> etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order.
 
=== geo links ===
 
In addition, people may publish Google Maps links like this:
 
<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>
 
(N.B. I tried and failed to get Yahoo Maps and local to do something intelligent with both "37.386013;-122.082932" and "37.386013 -122.082932").
 
Is it worth permitting this to be a geo as well?
 
I'm raising this to make sure it is considered.


However, my first guess is NO for two reasons.
== Other use cases ==
Please add your suggestions!


# No such examples in the wild have been documented or seen as of yet (I certainly haven't seen any).
hCard microformats could be used to:
# It would involve additional parsing requirements which are almost certainly going to be site/domain specific, and encoding a particular site's query parameter syntax into a format seems like a bad idea (against principle of decentralization). 
*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)
This could be mitigated if mapping services would simply accept the literal vCard GEO syntax "37.386013;-122.082932", e.g. http://maps.google.com/maps?q=37.386013;-122.082932 (which currently doesn't work) then we could make a simple rule such as for hyperlinks, parse the href attribute for a geo value at the end of the href, delimited before the value by a "=" (or perhaps "/" for services that use friendlier URLs).
*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 ==
== Issues with vCard Applications ==
Line 239: Line 124:
</nowiki></pre>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]
-- [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>
<span class="agent">
<dfn class="vcard">
  <span class="email">
  <a class="internet" href="mailto:jfriday@host.com">
    <span class="fn">Joe Friday</span>
  </a>
  </span>
  <span class="tel">+1-919-555-7878</span>
  <span class="title">Area Administrator, Assistant</span>
</dfn>
</span>
</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 ==
Line 247: Line 153:


=== Distributed Commentor Icons ===
=== 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.   
* 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.   
Line 263: Line 171:
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).
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
There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities:
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:
Example of the original link:
Line 273: Line 183:
</nowiki></pre>
</nowiki></pre>


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


Line 282: Line 192:
''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.
''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)
(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 ==
== Tutorials ==
Line 288: Line 206:
** as a business, get people to put you in their address book so they'll find you later
** 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.
** 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 ==
== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page.


== Post vCard additions ==
See [[hcard-parsing-brainstorming]]
 
== 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)
 
== key property for webid ==
[[vCard]] has a 'key' property which has seen little use on real world web pages as part of [[hCard]].
 
However, there are plenty of easily findable real world [[key-examples|examples of people publishing their public keys]] in visible text on web pages, and thus it's reasonable to include (keep) the 'key' property to mark those up.
 
What's missing is a recommended processing model and/or user flow for making use of such publicly published public keys in the 'key' property of hCard.
 
One possible such processing model and user flow is that described by the [[http://www.w3.org/wiki/WebID W3C WebID effort]].
 
It seems at least theoretically possible to use the vCard/hCard 'key' property to represent the necessary information in a profile for webid functionality.[http://lists.w3.org/Archives/Public/public-xg-webid/2012Jan/0355.html]
 
In particular, perhaps the upcoming digest (di) URI scheme may also help with this:
* http://tools.ietf.org/html/draft-hallambaker-digesturi-02
 
=== di: (DIGEST) URI scheme exploitation ===
 
Example of an hCard snippet  with di: scheme URI handled where  "fingerprint" holds the hash of your local x.509 certificate:
 
<a class="fingerprint" href="di:md5;nXVtqM9r5r6yncqI4muYDQ?hashtag=webid&amp;uri=http%3A%2F%2Fid.myopenlink.net%2Fc%2FBNP43U">Fingerprint</a>
 
==== Complete Example ====
 
<div id="hcard" class="vcard">
    <a class="url fn" href="http://linkeddata.uriburner.com/about/id/http/idehen.me/2012/01/27/identity-verification-via-blog-post/">kingsley Uyi Idehen (ProxyURI DI scheme Post2)</a>
    <a class="email" href="mailto:kidehen@openlinksw.com">kidehen@openlinksw.com</a>
    <a class="key" href="data:application/x-x509-user-cert;base64,MIIEwTCCBCqgAwIBAgICAR0wDQYJKoZIhvcNAQENBQAwdjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcUCkJ1cmxpbmd0b24xHjAcBgNVBAoUFU9wZW5saW5rIFNvZnR3YXJlIEluYzEaMBgGA1UEAxQRaWQubXlvcGVubGluay5uZXQwHhcNMTIwMTMxMTc1ODU0WhcNMTMwMTMwMTc1ODU0WjCBljE3MDUGA1UEAxMua2luZ3NsZXkgVXlpIElkZWhlbiAoUHJveHlVUkkgREkgc2NoZW1lIFBvc3QyKTE0MDIGA1UEChMrcGVyc29uYWwgRGF0YSBTcGFjZSB3aXRoIGJhc2ljIEhUTUwgRG9jIElkUDElMCMGCSqGSIb3DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK17rGuI0uTqmpT1uE2tgGi5JwZT04UvTOIhmVx5DybmviDtzMA4GMA48/bMTsXBeQirfzw3zE4slacA9bGPdsfYTCyGzqMKBWSpdG+2k7Ij08ExBAq1402kOMYJsBky7Pbd2rcmhI0fiaelbz+h7/YTgvQtOIcY1A7GTllupzRmRbz6GZcZi4KbVOdCPg31vHeoqX+tIj4LxpPzejOTDCyJU5nX+brHJtUY2VpLzGDTzkUrjMN4PO2cc00yaAz3Y1un+034q3DakCj5Lj8sFX6vHM5Zk96dQ7FU4qse0k4L/mfKeDiQzCsTbxFDI5wVluNwOoiJLNO+6Xl4MkItP40CAwEAAaOCAbcwggGzMB0GA1UdDgQWBBRFB30GtRZN3mx28ksgz+PXOMRn2TCBjAYDVR0RBIGEMIGBhmdodHRwOi8vbGlua2VkZGF0YS51cmlidXJuZXIuY29tL2Fib3V0L2lkL2h0dHAvaWRlaGVuLm1lLzIwMTIvMDEvMjcvaWRlbnRpdHktdmVyaWZpY2F0aW9uLXZpYS1ibG9nLXBvc3QvgRZraWRlaGVuQG9wZW5saW5rc3cuY29tMC0GCWCGSAGG+EIBDQQgFh5WaXJ0dW9zbyBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwgaEGA1UdIwSBmTCBloAURQd9BrUWTd5sdvJLIM/j1zjEZ9mheqR4MHYxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRMwEQYDVQQHFApCdXJsaW5ndG9uMR4wHAYDVQQKFBVPcGVubGluayBTb2Z0d2FyZSBJbmMxGjAYBgNVBAMUEWlkLm15b3BlbmxpbmsubmV0ggIBHTAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBDQUAA4GBAB3tL+38HkBYJIHaT7ZiNed3ajUZaQJppehJoY62nwhZyz5BdjXBllXHZE/s1ZaKAQhqCX8oS0/Rkc42tUXCpGW7IkwikngMm6DNqpfA6k211lroZJ1rP7Vk/3mft7yja7lQ9HjG9isqLXyYL9IhPPvK7a1NmA0SkjioY557YT18">Public Key</a>
    <a class="fingerprint" href="di:md5;nXVtqM9r5r6yncqI4muYDQ?hashtag=webid&amp;uri=http%3A%2F%2Fid.myopenlink.net%2Fc%2FBNP43U">Fingerprint</a>
  </div>
 
 
=== hCard and WebID ===
 
Next steps are to post sample hCards that attempt to represent required webid information:
 
* example from Kingsley Idehen (discussed initially in [http://lists.w3.org/Archives/Public/public-xg-webid/2012Jan/0525.html WebID IG mailing list hCard + WebID thread])
* actual functioning example for certificate:
-----BEGIN CERTIFICATE-----
MIIEczCCA9ygAwIBAgICAQIwDQYJKoZIhvcNAQENBQAwdjELMAkGA1UEBhMCVVMx
FjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcUCkJ1cmxpbmd0b24xHjAc
BgNVBAoUFU9wZW5saW5rIFNvZnR3YXJlIEluYzEaMBgGA1UEAxQRaWQubXlvcGVu
bGluay5uZXQwHhcNMTIwMTE4MTk0MjA3WhcNMTMwMTE3MTk0MjA3WjBlMR4wHAYD
VQQDFBVAa2lkZWhlbiAoQnJvd2VySUQgMikxHDAaBgNVBAoTE1BlcnNvbmFsIERh
dGEgU3BhY2UxJTAjBgkqhkiG9w0BCQEWFmtpZGVoZW5Ab3Blbmxpbmtzdy5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDICiEcwzeVRFJNTxlEDrJp
dBxtMH/y9LVYQGn3qnAP8RpEthW0rrdQg8q8hlMz2zKMwqp5ko/2h0gOLogYRk+p
Q6Ws0afEZaqhC+cA6uXpvkw7BVhk6SXAbIYgZr2u0zdPk1k85iHOOvXPnTOqetDJ
Mwk1hnKVKbJ7K4nS9aUek6nuICJ2FMSaV3HNCIjooJx5qnNquksRuSGp1sua+u0s
qCtTSJNNZsvpxMEJS3pFvQ49i2J89K5xctAsP4w7xTbC6L5eaDNEnW1ap9/mgmDZ
xTxRUxW4uaY8WZIRXmjPEJVszYnpbdXESgtZ4DCr8w8JY6iwVVI8mrfBmtRKDmFp
AgMBAAGjggGbMIIBlzAdBgNVHQ4EFgQU2O63RnUaQVLD3cu3xGPUUfsdbbwwcQYD
VR0RBGowaIZOaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L212L2RhdGEvYWZhY2Y2
Yjg2OGU2Y2IzNmY3MWQyY2VjYzZkNTMxYTI2Y2UxZjJlZiN0aGlzgRZraWRlaGVu
QG9wZW5saW5rc3cuY29tMC0GCWCGSAGG+EIBDQQgFh5WaXJ0dW9zbyBHZW5lcmF0
ZWQgQ2VydGlmaWNhdGUwgaEGA1UdIwSBmTCBloAU2O63RnUaQVLD3cu3xGPUUfsd
bbyheqR4MHYxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRMw
EQYDVQQHFApCdXJsaW5ndG9uMR4wHAYDVQQKFBVPcGVubGluayBTb2Z0d2FyZSBJ
bmMxGjAYBgNVBAMUEWlkLm15b3BlbmxpbmsubmV0ggIBAjAgBgNVHSUBAf8EFjAU
BggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB
DQUAA4GBAKnEpLrpS49OV2lLXjMzsZcWH7SWLmt1tPMD8bB0rC7Dh12Z3rpJ/+jq
GMJarWEppj9/dEQq16Hrb6GqelCgo2Xw9B/bu52q16bT1vOOfl6trcKrUcWeiM+0
7JJjyWxUulEAnmtpH/NPX0x/37Yg5KpnQMs3F/h1IIl105H5cR5H
-----END CERTIFICATE-----
 
 
<div id="hcard" class="vcard">
    <a class="url fn" href="http://id.myopenlink.net/mv/data/afacf6b868e6cb36f71d2cecc6d531a26ce1f2ef#this">@kidehen (BrowerID 2)</a>
    <a class="email" href="mailto:kidehen@openlinksw.com">kidehen@openlinksw.com</a>
    <a class="key" href="data:application/x-x509-user-cert;base64,MIIEczCCA9ygAwIBAgICAQIwDQYJKoZIhvcNAQENBQAwdjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcUCkJ1cmxpbmd0b24xHjAcBgNVBAoUFU9wZW5saW5rIFNvZnR3YXJlIEluYzEaMBgGA1UEAxQRaWQubXlvcGVubGluay5uZXQwHhcNMTIwMTE4MTk0MjA3WhcNMTMwMTE3MTk0MjA3WjBlMR4wHAYDVQQDFBVAa2lkZWhlbiAoQnJvd2VySUQgMikxHDAaBgNVBAoTE1BlcnNvbmFsIERhdGEgU3BhY2UxJTAjBgkqhkiG9w0BCQEWFmtpZGVoZW5Ab3Blbmxpbmtzdy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDICiEcwzeVRFJNTxlEDrJpdBxtMH/y9LVYQGn3qnAP8RpEthW0rrdQg8q8hlMz2zKMwqp5ko/2h0gOLogYRk+pQ6Ws0afEZaqhC+cA6uXpvkw7BVhk6SXAbIYgZr2u0zdPk1k85iHOOvXPnTOqetDJMwk1hnKVKbJ7K4nS9aUek6nuICJ2FMSaV3HNCIjooJx5qnNquksRuSGp1sua+u0sqCtTSJNNZsvpxMEJS3pFvQ49i2J89K5xctAsP4w7xTbC6L5eaDNEnW1ap9/mgmDZxTxRUxW4uaY8WZIRXmjPEJVszYnpbdXESgtZ4DCr8w8JY6iwVVI8mrfBmtRKDmFpAgMBAAGjggGbMIIBlzAdBgNVHQ4EFgQU2O63RnUaQVLD3cu3xGPUUfsdbbwwcQYDVR0RBGowaIZOaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L212L2RhdGEvYWZhY2Y2Yjg2OGU2Y2IzNmY3MWQyY2VjYzZkNTMxYTI2Y2UxZjJlZiN0aGlzgRZraWRlaGVuQG9wZW5saW5rc3cuY29tMC0GCWCGSAGG+EIBDQQgFh5WaXJ0dW9zbyBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwgaEGA1UdIwSBmTCBloAU2O63RnUaQVLD3cu3xGPUUfsdbbyheqR4MHYxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRMwEQYDVQQHFApCdXJsaW5ndG9uMR4wHAYDVQQKFBVPcGVubGluayBTb2Z0d2FyZSBJbmMxGjAYBgNVBAMUEWlkLm15b3BlbmxpbmsubmV0ggIBAjAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBDQUAA4GBAKnEpLrpS49OV2lLXjMzsZcWH7SWLmt1tPMD8bB0rC7Dh12Z3rpJ/+jqGMJarWEppj9/dEQq16Hrb6GqelCgo2Xw9B/bu52q16bT1vOOfl6trcKrUcWeiM+07JJjyWxUulEAnmtpH/NPX0x/37Yg5KpnQMs3F/h1IIl105H5cR5H">Public Key</a>
    <a class="key" href="http://id.myopenlink.net/certgen/cert/213">Public Key Ref</a>
  </div>
 
This exploration could help document how the hCard 'key' property should be used, and perhaps even written up at least as examples/suggestions in the hCard spec itself.
 
TODO:  we need an hCard field for holding a crypto hash (e.g., SHA1 or MD5) of an x.509 certificate. There's already [http://tools.ietf.org/html/draft-hallambaker-digesturi-02 data: scheme URI] in place for this purpose.
 
=== Usage Scenario Examples ===
 
==== Exposing Your WebID ====
Use a blog post ([http://kidehen.blogspot.com/2012/01/hcard-webid-test-post.html like this]) to publicize information that serves as a declaration of identity verifiable by me, using the WebID protocol. Once in place, structured data middleware can then ingest the blog post and produce a Linked Data resource that's available in a variety of formats that includes: HTML ([http://linkeddata.uriburner.com/about/id/entity/http/kidehen.blogspot.com/2012/01/hcard-webid-test-post.html#hcard like this]), and many others (just look at footer section of the sample HTML page).
 
==== Using hCard to facilitate WebID verification ====
Actually used hCard embedded in a blog post to create a resource that's looked up by a WebID verifier. Basically, the verifier is following the URL from the subjectAlternativeName (SAN) extension in an x.509 certificate to an HTML resource that contains embedded hCard.
 
Examples:
 
* [http://kidehen.blogspot.com/2012/01/hcard-inside-post-as-identity-provider.html Blogspot Post] -- via a live sample post
* [http://goo.gl/Tfup4 Howto Guide covering entire life cycle] -- creation, publication, and verification (basic URI which only works with verifiers that can transform hCard to RDF)
* [http://goo.gl/j2ei8 Howto Guide covering entire life cycle] -- creation, publication, and verification (leveraging a proxy/wrapper Linked Data URI that provides hCard to RDF conversion on behalf of WebID verifiers) .
 
== Post vCard 3 additions ==
 
'''This subsection is out of date. Many of these suggestions made it into [[vcard4]] and thus [[h-card]].'''
 
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]]
 
* '''[[relationship-status]]'''
* '''[[interested-in]]'''
* '''[[looking-for]]'''
 
Thus see (and add to): [[vcard-suggestions]]


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.
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]]
* [[user-profile]]


This section is for documentation of such suggested additions.  Note, we will require empirical evidence of actual *real world* examples on the Web of people publishing this information as part of contact information, before considering such additions/extensions.
Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.


* altitude. From [[hcard-issues]].
Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1
** No evidence provided that contact information on the Web publishes this information.
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 ==
== TODO ==
Line 308: Line 351:
* 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.
* 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.
* 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


== References ==
== CSS Styles ==
=== Normative References ===
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.
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
 
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
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:
* [http://gmpg.org/xmdp/ XMDP]
<pre><nowiki>
=== Informative References ===
<span style="display: none">Hidden Data</span>
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
</nowiki></pre>
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
Transforming applications will still find the data and use it when converting hCards to vCards.
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]


== Other Implementations/Ideas ==
== 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
* [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 and back.
* It would also be possible to convert XFN and hCard to FoaF.
* [http://microid.org/ MicroID in hCard]


== Accepted Suggestions ==
== Accepted Suggestions ==
Line 358: Line 402:
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]
* +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>
<P><B>NVIDIA CORPORATE OFFICE:</B> <BR>
          2701 San Tomas Expressway<BR>
          Santa Clara, CA 95050<BR>
          Tel: 408-486-2000<BR>
          Fax: 408-486-2200<BR>
          ...
        </P>
</pre>
[[http://www.supermarketguru.com/page.cfm/369 Supermarketguru.com]]
<pre>
  <p>
      <font face="Verdana, Helvetica, Arial" size=2>
        <b>Phil Lempert:</b> <a href="mailto:plempert@supermarketguru.com">plempert@supermarketguru.com</a><br>
      </font>
      <font face="Verdana, Helvetica, Arial, sans-serif" size=2>SupermarketGuru.com<br>
          3015 Main Street, Suite 320<BR>Santa Monica, California 90405<br>
          Telephone: 323-860-3070
      </font>
  </p>
</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)
== Peopletagging ==
Just documenting this here so it's written down.  I have been adding class="url" to hcards of people in my blog posts as a way of approximating "people tagging" (like the Facebook "tag people mentioned in this note").
I used to want to use class="url" rel="tag" in an hCard to do this, but the URL form requirements of rel="tag" do not fit typical profile URLs at all, so I have stopped trying to do things that way.
-- [[User:Singpolyma|Singpolyma]] 23:32, 25 June 2009 (UTC)


== Rejected Suggestions ==
== Rejected Suggestions ==
See [[hcard-brainstorming-rejected]].
== 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]
* [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}}
* [[adr-poll]]
= for hCard 1.0.1 =
[[hcard-1-0-1|hCard 1.0.1]] will incorporate some number of hCard brainstorms. Because this is minor bug fix revision (3rd digit), in general no new hCard properties will be added, however bug fixes and [[hcard-issues-resolved|issue resolutions]] involving critical areas such as internationalization and accessibility may introduce additional syntax for existing properties (e.g. <code>value-title</code> from the [[value-class-pattern]]). Some sources of changes for hCard 1.0.1:
* [[hcard-issues-resolved]]
* [[value-class-pattern]] (require parsers to support)
As I evaluate brainstorms listed above, if they make sense to include in hCard 1.0.1, I'll move them here. [[User:Tantek|Tantek]]
== deprecate unused properties ==
There are a few properties in hCard that have either received little/no use, or don't make seem to make sense. Thus per the [[simplicity]]/[[minimal-vocabulary]] [[principles]], it makes sense to drop them, or at least in 1.0.1 ''obsolete'' them (outright dropping them in 1.1), to both:
* discourage use by authors (though given the lack of use, it's not clear that authors need any more discouragement)
* encourage implementations to ''ignore'' them, as they would any non-hCard class names.
Properties to deprecate and why:
* <code>class</code> - no [[hcard-examples-in-wild|examples]] in practice, the access classification notions of public/private/confidential don't really make sense outside the context of a specific access protocol/interface (e.g. [[OAuth]].
* <code>mailer</code> - "the type of electronic mail software that is used by the individual" - no [[hcard-examples-in-wild|examples]] in practice, odd to include a preference for just one type of software.
* <code>rev</code> - several reasons:
** There are insufficient examples to really justify keeping this.
** Cognitive name collision with the (now deprecated in HTML5) "rev" attribute.
** Re-use more specific and well-defined "last-modified" property from [[hCalendar]] instead to preserve functionality, thus reducing the overall vocabulary in use.
== only require fn ==
Through the use of several shorthand rules, 'fn' is already effectively the only required property, thus it would be clearer to simply state that and document how fn sometimes can be used to infer 'n'/'nickname' property values.
== root only shorthand syntax ==
This depends on the "only require fn" proposal above.
Per the [[microformats]] [[principle]] [[start-simple]], and as evidenced by many folks [[hcard-faq#Can_you_mix_properties_and_the_root_class_name|asking]] if it is possible to use markup like:
<source lang=html4strict style="background:#fee"><span class="vcard fn">Tantek Çelik</span></source>
it makes sense to introduce an even more minimal root only shorthand syntax (ROSS) that achieves the same goal, e.g.:
<source lang=html4strict style="background:#efe"><span class="vcard">Tantek Çelik</span></source>
It works as follows:
* if an hCard has no explicit properties (only the root class name has been specified/found)
** (or perhaps if an hCard root element has no child elements - this is the case that appears to occur in practice)
* then parse the contents of the root hCard element as text and use that text to imply the 'fn' property, the only required hCard property.
** all [[hcard-parsing]] special element handling still applies, e.g. if the root element is an <code>abbr</code>, use the 'title' attribute, if the root element is an <code>img</code>, use the 'alt' attribute.
* additionally, the root element is one of the following, then the respective additional property is implied as well:
** <code>&lt;a href="http://example.com"&gt;</code> - set the 'url' property to the 'href' attribute
** <code>&lt;img src="http://example.com/p.jpg"&gt;</code> - set the 'photo' property to the 'src' attribute
** <code>&lt;object data="http://example.com/p"&gt;</code>
*** if the 'type' attribute is a MIME type starting with "image/", then set the 'photo' property to the 'data' attribute
*** if the 'type' attribute is a MIME type starting with "audio/", then set the 'sound' property to the 'data' attribute
Issues:
* could only be used for "people" hCards, since no "org", nor any location properties would be implied.
This notion of root only shorthand syntax (ROSS), could (and probably should) be generalized to all [[compound-microformats]]. Of course it will require that all [[compound-microformats]] has only one required property (all others being optional), thats value is then implied by the content of the root only syntax. Thus:
* add to [[hcalendar-brainstorming]]: [[hcalendar-1-0-1|hCalendar 1.0.1]] should only require "summary"
* add to [[hreview-brainstorming]]: [[hreview-0-4|hReview 0.4]] should only require "item", which itself should only require "fn", and those both should be implied by the root-only shorthand syntax.
* add to [[hatom-brainstorming]]: [[hatom-0-2|hAtom 0.2]] perhaps should not require any properties, and for the ROSS case, should imply the value of the "entry-content" property.
In addition, all compound properties of a microformat should have zero or one required subproperties, and similar to ROSS, should imply their required (or primary optional if none are required) subproperty accordingly. E.g.
* "adr" should/could imply "extended-address"
* "geo" could imply "latitude" from the first decimal number in its text value, and if it is followed by non-numerical content (e.g. a "," or ";" or " " or " longitude:"), "longitude" from the first decimal number that followed that chunk of non-numerical content.
== 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&nbsp;locality" or "fn&nbsp;street-address")?
'''For further consideration''': One real problem right now is that we provide a field for our users to enter a 'Location' on our [http://timespeople.nytimes.com/view/user/9354457/1/index.html User Pages]. In real life this has ranged from '8th floor', 'New York', 'Company Name', My Desk', 'http://some.site.com' - the majority being generalized geographic city or state names. Right now there is no property to properly handle this, but this one appears to come close. If this cannot be used for such purposes I would ask that this be looked into further as I don't think its a unique problem.
* Have you considered using <code>label</code> instead of <code>adr</code>?


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.''
=== Examples in the wild ===


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:
* 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>
<pre><nowiki>
<span class="vcard">
<span class="vcard">
...
<span class="adr">
<ul class="categories">
  <span class="fn extended-address">Picnic benches</span>
<li><a href="http://w3c.org">W3C</a></li>
  <span class="street-address">South Park</span>
</ul>
  <span class="locality">San Francisco</span>
...
  <span class="region">California</span>
</span>
</span>
</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">
  <span class="street-address">Marine Parade</span><br />
  <span class="locality">Brighton &amp; Hove</span>,
  <span class="region">England</span>
  <span class="postal-code">BN2 1TB</span><br />
  <span class="country">United Kingdom</span><br />
  <span class="tel">01273 606674</span>
  </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>
  <span class="street-address">Marine Parade</span><br />
  <span class="locality">Brighton &amp; Hove</span>,
  <span class="region">England</span>
  <span class="postal-code">BN2 1TB</span><br />
  <span class="country">United Kingdom</span><br />
  <span class="tel">01273 606674</span>
  </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">
  <span class="fn org">Powell's Pool</span>
  <span class="adr">
    <span class="extended-address">Sutton Park</span>
    <span class="locality">Birmingham</span>
    <span class="country-name">England</span>
  </span>
</div>
</nowiki></pre>
 
[[User:AndyMabbett|Andy Mabbett]] 05:40, 15 Dec 2007 (PST)
 
===Revised proposal===
*See revised proposal at [http://microformats.org/discuss/mail/microformats-discuss/2007-December/011169.html microformats-discuss/2007-December/011169.html]
** [http://buzzword.org.uk/cognition/ Cognition] supports this.
 
=== 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 <strong><code>featurename</code></strong> tag.
 
<blockquote><h3>Feature Type, Feature Name, and Relationship Tags</h3><p>The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.</p><pre><nowiki>
    &lt;georss:point&gt;45.256 -110.45&lt;/georss:point&gt;
    &lt;georss:featuretypetag&gt;city&lt;/georss:featuretypetag&gt;
 
    &lt;georss:relationshiptag&gt;is-centered-at&lt;/georss:relationshiptag&gt;
 
    &lt;georss:featurename&gt;Podunk&lt;/georss:featurename&gt;
</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.
* [http://buzzword.org.uk/cognition/ Cognition] has supported this for ages.
 
=== 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>
<span class="vcard">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span>
</span>
</nowiki></pre>
</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.
would be treated from a parsing perspective as:
 
<pre><nowiki>
<span class="vcard"><span class="n">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span></span>
</nowiki></pre>
 
Which, with the '''implied "fn" from "n" optimization''' above, would then be effectively treated as:
<pre><nowiki>
<span class="vcard"><span class="fn n">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span></span>
</nowiki></pre>
 
<div class="discussion">
* a related request from the mailing list: http://microformats.org/discuss/mail/microformats-discuss/2007-September/010791.html
* from the [https://addons.mozilla.org/en-US/firefox/addon/4106#reviews Firefox Operator reviews], by Anthony Watson on July 30, 2009, a comment in apparent support of implying n from n sub-properties and fn from n as well:
** "If I don't set an fn class, but only use the given-name and family name classes, the Operator toolbar doesn't light up. fn should be optional, otherwise I'm forced to hide the redundant element(s)."
</div>
 
== 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>
 
= for hCard 1.1 =
[[hcard-1-1|hCard 1.1]] will incorporate all fixes going into hCard 1.0.1, and in addition, as a minor feature revision, will incorporate changes and a few new properties based on:
* [[hcard-1-0-1]]
* existing research and [[hcard-issues-resolved|resolved issues]]
* [[vcard-suggestions]]
* vCard 4.0 proposed standard - properties that represent existing content in the wild
* potentially other widely used characteristics from sites using hCard (e.g. Wikipedia infobox and other templates).
 
hCard 1.1 will likely be one of a few predefined vocabularies as part of the [[microformats-2]] work and only defined within the microformats-2 syntax.
 
As I evaluate brainstorms listed below, if they make sense to include in hCard 1.1, I'll move them here. [[User:Tantek|Tantek]]
 
== languages spoken ==
Consider [[languages-spoken]] as a possible addition based on examples gathered.
 
== coverage area ==
Consider [[coverage-area-examples]] as a possible addition based on examples gathered.
 
= just brainstorming =
The following brainstorming suggestions are interesting ideas for how to use or improve hCard but are theoretical (no real world examples found yet), or have insufficient real world examples to be deserving of explicit inclusion in the specification.
 
== named phone numbers ==
hCard is already specified for use for:
* people
* organizations
* named locations
Numerous examples of all of these can be found on the web.
 
Another possible addition is a named telephone numbers. So far the examples are fairly limited:
* W3C [http://www.w3.org/1998/12/bridge/Zakim.html Zakim  Teleconference Bridge] (note also [http://www.w3.org/2002/01/UsingZakim Using Zakim] instructions)
* ...
 
In this case, Zakim, for example, has a name, a telephone number, and a URL for "status".
 
It also makes sense as something that might be in your address book, and therefore have a [[vCard]] serialization.
 
So it ''might'' make sense to have an hCard for Zakim which contained the information that you might want added to your address book about it.
 
Another way to achieve this would be with perhaps a new/different "tel" microformat extracted from hCard, perhaps even a named "tel" microformat (e.g. with root class name "vtel", properties "fn", "tel", "url" based on the above example.).
 
= for hCard 2 =
== done ==
* [[hcard-implied]] - has been incorporated and generalized for all microformats

Latest revision as of 16:25, 18 July 2020

This page is for brainstorming about various uses and details of hCard. This page contains proposals. For the current state please see hCard.

Brainstorm proposals that illustrate how to use the existing hCard spec will likely be incorporated into existing hCard documentation such as:

Proposals that are minor bug fixes or enhancements may be incorporated into hCard 1.0.1. See the for hCard 1.0.1 section below.

Proposals that are more substantial enhancements such as new hCard properties may be incorporated into hCard 1.1. See the for hCard 1.1 section below.

Editors

Problems Being Solved

Some of the problems that hCard helps to solve:


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.
    • <a class="email" href="mailto:steve@mac.com">...
  • MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
  • Internet Relay Chat (IRC), use "irc:" URLs.

A suggestion relating to the rise of VoIP protocol (Skype, etc):

Should these protocols be marked up using the <span type="tel">. It seems logical that a means to communicate with another via voice should be marked up as a telephone address, rather than the currently suggested URL property.

Auto-Discovery

See hcard-brainstorming-autodiscovery

geo improvements

See geo-brainstorming

how to use with HTML5

Per Theresa O'Connor's email to public-html: Add a section in hCard describing how to use hCard in HTML5, including optional use of HTML5's <time> element and microdata feature. Encourage HTML5 to drop the "vcard" predefined microdata vocabulary and reference an updated hCard spec instead. Tantek

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 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 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.

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

-- Brian Suda

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:

<a href="http://mywebsite.com/" class="fn n">
    <span class="given-name">John</span>
    <span class="other-names">Q.</span>
    <span class="family-name">Public</span>
</a>

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:

John Q. Public

    John
    Q.
    Public

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

-- 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.

-- 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 ? This may give the hCard some added semantic value in the XHTML document.

<span class="agent"> 
 <span class="vcard">
  <span class="email">
   <a class="internet" href="mailto:jfriday@host.com">
    <dfn>
       <span class="fn">Joe Friday</span>
    </dfn>
   </a>
  </span>
  <span class="tel">+1-919-555-7878</span>
  <span class="title">Area Administrator, Assistant</span>
 </span>
</span>

-- Ben Ward

  • If the answer to the above Q is "yes", why not use the following?
<dfn class="fn">Joe Friday</dfn>

or

<span class="agent"> 
 <dfn class="vcard">
  <span class="email">
   <a class="internet" href="mailto:jfriday@host.com">
    <span class="fn">Joe Friday</span>
   </a>
  </span>
  <span class="tel">+1-919-555-7878</span>
  <span class="title">Area Administrator, Assistant</span>
 </dfn>
</span>

This would mark the entire hcard as the "defining instance".

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 spec.

Distributed Commentor Icons

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

  • See 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:

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

Spam prevention

hCard uses mailto: links, and therefore it automatically "inherits" the disadvantage of mailto: 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:

<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a> 

Example of the "encoded" link (with rel-nofollow added):

<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>

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.

Parsing

See hcard-parsing-brainstorming

Birthday Reminders

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

key property for webid

vCard has a 'key' property which has seen little use on real world web pages as part of hCard.

However, there are plenty of easily findable real world examples of people publishing their public keys in visible text on web pages, and thus it's reasonable to include (keep) the 'key' property to mark those up.

What's missing is a recommended processing model and/or user flow for making use of such publicly published public keys in the 'key' property of hCard.

One possible such processing model and user flow is that described by the [W3C WebID effort].

It seems at least theoretically possible to use the vCard/hCard 'key' property to represent the necessary information in a profile for webid functionality.[1]

In particular, perhaps the upcoming digest (di) URI scheme may also help with this:

di: (DIGEST) URI scheme exploitation

Example of an hCard snippet with di: scheme URI handled where "fingerprint" holds the hash of your local x.509 certificate:

<a class="fingerprint" href="di:md5;nXVtqM9r5r6yncqI4muYDQ?hashtag=webid&uri=http%3A%2F%2Fid.myopenlink.net%2Fc%2FBNP43U">Fingerprint</a>

Complete Example

   <a class="url fn" href="http://linkeddata.uriburner.com/about/id/http/idehen.me/2012/01/27/identity-verification-via-blog-post/">kingsley Uyi Idehen (ProxyURI DI scheme Post2)</a>
   <a class="email" href="mailto:kidehen@openlinksw.com">kidehen@openlinksw.com</a>
   <a class="key" href="data:application/x-x509-user-cert;base64,MIIEwTCCBCqgAwIBAgICAR0wDQYJKoZIhvcNAQENBQAwdjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcUCkJ1cmxpbmd0b24xHjAcBgNVBAoUFU9wZW5saW5rIFNvZnR3YXJlIEluYzEaMBgGA1UEAxQRaWQubXlvcGVubGluay5uZXQwHhcNMTIwMTMxMTc1ODU0WhcNMTMwMTMwMTc1ODU0WjCBljE3MDUGA1UEAxMua2luZ3NsZXkgVXlpIElkZWhlbiAoUHJveHlVUkkgREkgc2NoZW1lIFBvc3QyKTE0MDIGA1UEChMrcGVyc29uYWwgRGF0YSBTcGFjZSB3aXRoIGJhc2ljIEhUTUwgRG9jIElkUDElMCMGCSqGSIb3DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK17rGuI0uTqmpT1uE2tgGi5JwZT04UvTOIhmVx5DybmviDtzMA4GMA48/bMTsXBeQirfzw3zE4slacA9bGPdsfYTCyGzqMKBWSpdG+2k7Ij08ExBAq1402kOMYJsBky7Pbd2rcmhI0fiaelbz+h7/YTgvQtOIcY1A7GTllupzRmRbz6GZcZi4KbVOdCPg31vHeoqX+tIj4LxpPzejOTDCyJU5nX+brHJtUY2VpLzGDTzkUrjMN4PO2cc00yaAz3Y1un+034q3DakCj5Lj8sFX6vHM5Zk96dQ7FU4qse0k4L/mfKeDiQzCsTbxFDI5wVluNwOoiJLNO+6Xl4MkItP40CAwEAAaOCAbcwggGzMB0GA1UdDgQWBBRFB30GtRZN3mx28ksgz+PXOMRn2TCBjAYDVR0RBIGEMIGBhmdodHRwOi8vbGlua2VkZGF0YS51cmlidXJuZXIuY29tL2Fib3V0L2lkL2h0dHAvaWRlaGVuLm1lLzIwMTIvMDEvMjcvaWRlbnRpdHktdmVyaWZpY2F0aW9uLXZpYS1ibG9nLXBvc3QvgRZraWRlaGVuQG9wZW5saW5rc3cuY29tMC0GCWCGSAGG+EIBDQQgFh5WaXJ0dW9zbyBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwgaEGA1UdIwSBmTCBloAURQd9BrUWTd5sdvJLIM/j1zjEZ9mheqR4MHYxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRMwEQYDVQQHFApCdXJsaW5ndG9uMR4wHAYDVQQKFBVPcGVubGluayBTb2Z0d2FyZSBJbmMxGjAYBgNVBAMUEWlkLm15b3BlbmxpbmsubmV0ggIBHTAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBDQUAA4GBAB3tL+38HkBYJIHaT7ZiNed3ajUZaQJppehJoY62nwhZyz5BdjXBllXHZE/s1ZaKAQhqCX8oS0/Rkc42tUXCpGW7IkwikngMm6DNqpfA6k211lroZJ1rP7Vk/3mft7yja7lQ9HjG9isqLXyYL9IhPPvK7a1NmA0SkjioY557YT18">Public Key</a>
   <a class="fingerprint" href="di:md5;nXVtqM9r5r6yncqI4muYDQ?hashtag=webid&uri=http%3A%2F%2Fid.myopenlink.net%2Fc%2FBNP43U">Fingerprint</a>


hCard and WebID

Next steps are to post sample hCards that attempt to represent required webid information:


BEGIN CERTIFICATE-----

MIIEczCCA9ygAwIBAgICAQIwDQYJKoZIhvcNAQENBQAwdjELMAkGA1UEBhMCVVMx FjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcUCkJ1cmxpbmd0b24xHjAc BgNVBAoUFU9wZW5saW5rIFNvZnR3YXJlIEluYzEaMBgGA1UEAxQRaWQubXlvcGVu bGluay5uZXQwHhcNMTIwMTE4MTk0MjA3WhcNMTMwMTE3MTk0MjA3WjBlMR4wHAYD VQQDFBVAa2lkZWhlbiAoQnJvd2VySUQgMikxHDAaBgNVBAoTE1BlcnNvbmFsIERh dGEgU3BhY2UxJTAjBgkqhkiG9w0BCQEWFmtpZGVoZW5Ab3Blbmxpbmtzdy5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDICiEcwzeVRFJNTxlEDrJp dBxtMH/y9LVYQGn3qnAP8RpEthW0rrdQg8q8hlMz2zKMwqp5ko/2h0gOLogYRk+p Q6Ws0afEZaqhC+cA6uXpvkw7BVhk6SXAbIYgZr2u0zdPk1k85iHOOvXPnTOqetDJ Mwk1hnKVKbJ7K4nS9aUek6nuICJ2FMSaV3HNCIjooJx5qnNquksRuSGp1sua+u0s qCtTSJNNZsvpxMEJS3pFvQ49i2J89K5xctAsP4w7xTbC6L5eaDNEnW1ap9/mgmDZ xTxRUxW4uaY8WZIRXmjPEJVszYnpbdXESgtZ4DCr8w8JY6iwVVI8mrfBmtRKDmFp AgMBAAGjggGbMIIBlzAdBgNVHQ4EFgQU2O63RnUaQVLD3cu3xGPUUfsdbbwwcQYD VR0RBGowaIZOaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L212L2RhdGEvYWZhY2Y2 Yjg2OGU2Y2IzNmY3MWQyY2VjYzZkNTMxYTI2Y2UxZjJlZiN0aGlzgRZraWRlaGVu QG9wZW5saW5rc3cuY29tMC0GCWCGSAGG+EIBDQQgFh5WaXJ0dW9zbyBHZW5lcmF0 ZWQgQ2VydGlmaWNhdGUwgaEGA1UdIwSBmTCBloAU2O63RnUaQVLD3cu3xGPUUfsd bbyheqR4MHYxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRMw EQYDVQQHFApCdXJsaW5ndG9uMR4wHAYDVQQKFBVPcGVubGluayBTb2Z0d2FyZSBJ bmMxGjAYBgNVBAMUEWlkLm15b3BlbmxpbmsubmV0ggIBAjAgBgNVHSUBAf8EFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB DQUAA4GBAKnEpLrpS49OV2lLXjMzsZcWH7SWLmt1tPMD8bB0rC7Dh12Z3rpJ/+jq GMJarWEppj9/dEQq16Hrb6GqelCgo2Xw9B/bu52q16bT1vOOfl6trcKrUcWeiM+0 7JJjyWxUulEAnmtpH/NPX0x/37Yg5KpnQMs3F/h1IIl105H5cR5H


END CERTIFICATE-----


   <a class="url fn" href="http://id.myopenlink.net/mv/data/afacf6b868e6cb36f71d2cecc6d531a26ce1f2ef#this">@kidehen (BrowerID 2)</a>
   <a class="email" href="mailto:kidehen@openlinksw.com">kidehen@openlinksw.com</a>
   <a class="key" href="data:application/x-x509-user-cert;base64,MIIEczCCA9ygAwIBAgICAQIwDQYJKoZIhvcNAQENBQAwdjELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxEzARBgNVBAcUCkJ1cmxpbmd0b24xHjAcBgNVBAoUFU9wZW5saW5rIFNvZnR3YXJlIEluYzEaMBgGA1UEAxQRaWQubXlvcGVubGluay5uZXQwHhcNMTIwMTE4MTk0MjA3WhcNMTMwMTE3MTk0MjA3WjBlMR4wHAYDVQQDFBVAa2lkZWhlbiAoQnJvd2VySUQgMikxHDAaBgNVBAoTE1BlcnNvbmFsIERhdGEgU3BhY2UxJTAjBgkqhkiG9w0BCQEWFmtpZGVoZW5Ab3Blbmxpbmtzdy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDICiEcwzeVRFJNTxlEDrJpdBxtMH/y9LVYQGn3qnAP8RpEthW0rrdQg8q8hlMz2zKMwqp5ko/2h0gOLogYRk+pQ6Ws0afEZaqhC+cA6uXpvkw7BVhk6SXAbIYgZr2u0zdPk1k85iHOOvXPnTOqetDJMwk1hnKVKbJ7K4nS9aUek6nuICJ2FMSaV3HNCIjooJx5qnNquksRuSGp1sua+u0sqCtTSJNNZsvpxMEJS3pFvQ49i2J89K5xctAsP4w7xTbC6L5eaDNEnW1ap9/mgmDZxTxRUxW4uaY8WZIRXmjPEJVszYnpbdXESgtZ4DCr8w8JY6iwVVI8mrfBmtRKDmFpAgMBAAGjggGbMIIBlzAdBgNVHQ4EFgQU2O63RnUaQVLD3cu3xGPUUfsdbbwwcQYDVR0RBGowaIZOaHR0cDovL2lkLm15b3BlbmxpbmsubmV0L212L2RhdGEvYWZhY2Y2Yjg2OGU2Y2IzNmY3MWQyY2VjYzZkNTMxYTI2Y2UxZjJlZiN0aGlzgRZraWRlaGVuQG9wZW5saW5rc3cuY29tMC0GCWCGSAGG+EIBDQQgFh5WaXJ0dW9zbyBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwgaEGA1UdIwSBmTCBloAU2O63RnUaQVLD3cu3xGPUUfsdbbyheqR4MHYxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRMwEQYDVQQHFApCdXJsaW5ndG9uMR4wHAYDVQQKFBVPcGVubGluayBTb2Z0d2FyZSBJbmMxGjAYBgNVBAMUEWlkLm15b3BlbmxpbmsubmV0ggIBAjAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBDQUAA4GBAKnEpLrpS49OV2lLXjMzsZcWH7SWLmt1tPMD8bB0rC7Dh12Z3rpJ/+jqGMJarWEppj9/dEQq16Hrb6GqelCgo2Xw9B/bu52q16bT1vOOfl6trcKrUcWeiM+07JJjyWxUulEAnmtpH/NPX0x/37Yg5KpnQMs3F/h1IIl105H5cR5H">Public Key</a>
   <a class="key" href="http://id.myopenlink.net/certgen/cert/213">Public Key Ref</a>

This exploration could help document how the hCard 'key' property should be used, and perhaps even written up at least as examples/suggestions in the hCard spec itself.

TODO: we need an hCard field for holding a crypto hash (e.g., SHA1 or MD5) of an x.509 certificate. There's already data: scheme URI in place for this purpose.

Usage Scenario Examples

Exposing Your WebID

Use a blog post (like this) to publicize information that serves as a declaration of identity verifiable by me, using the WebID protocol. Once in place, structured data middleware can then ingest the blog post and produce a Linked Data resource that's available in a variety of formats that includes: HTML (like this), and many others (just look at footer section of the sample HTML page).

Using hCard to facilitate WebID verification

Actually used hCard embedded in a blog post to create a resource that's looked up by a WebID verifier. Basically, the verifier is following the URL from the subjectAlternativeName (SAN) extension in an x.509 certificate to an HTML resource that contains embedded hCard.

Examples:

Post vCard 3 additions

This subsection is out of date. Many of these suggestions made it into vcard4 and thus h-card.

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.
  • 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).

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 has already done this. Other related efforts:

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 Persondata aligns very closely with hCard, but has additional date and place of birth & death fields. 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:

<span style="display: none">Hidden Data</span>

Transforming applications will still find the data and use it when converting hCards to vCards.

Other Implementations/Ideas

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 Apple Address Book supports this semantic when importing vCards.

See the 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.

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

[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.

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

          Fax: 408-486-2200<BR>
          ...
        </P>

[Supermarketguru.com]

   <p>
      <font face="Verdana, Helvetica, Arial" size=2>
        <b>Phil Lempert:</b> <a href="mailto:plempert@supermarketguru.com">plempert@supermarketguru.com</a><br>
      </font>
      <font face="Verdana, Helvetica, Arial, sans-serif" size=2>SupermarketGuru.com<br>
          3015 Main Street, Suite 320<BR>Santa Monica, California 90405<br>
          Telephone: 323-860-3070 
      </font>
   </p>

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. Andy Mabbett 00:33, 8 Jan 2008 (PST)

Peopletagging

Just documenting this here so it's written down. I have been adding class="url" to hcards of people in my blog posts as a way of approximating "people tagging" (like the Facebook "tag people mentioned in this note").

I used to want to use class="url" rel="tag" in an hCard to do this, but the URL form requirements of rel="tag" do not fit typical profile URLs at all, so I have stopped trying to do things that way.

-- Singpolyma 23:32, 25 June 2009 (UTC)

Rejected Suggestions

See hcard-brainstorming-rejected.

References

Related Pages

The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.


for hCard 1.0.1

hCard 1.0.1 will incorporate some number of hCard brainstorms. Because this is minor bug fix revision (3rd digit), in general no new hCard properties will be added, however bug fixes and issue resolutions involving critical areas such as internationalization and accessibility may introduce additional syntax for existing properties (e.g. value-title from the value-class-pattern). Some sources of changes for hCard 1.0.1:

As I evaluate brainstorms listed above, if they make sense to include in hCard 1.0.1, I'll move them here. Tantek

deprecate unused properties

There are a few properties in hCard that have either received little/no use, or don't make seem to make sense. Thus per the simplicity/minimal-vocabulary principles, it makes sense to drop them, or at least in 1.0.1 obsolete them (outright dropping them in 1.1), to both:

  • discourage use by authors (though given the lack of use, it's not clear that authors need any more discouragement)
  • encourage implementations to ignore them, as they would any non-hCard class names.

Properties to deprecate and why:

  • class - no examples in practice, the access classification notions of public/private/confidential don't really make sense outside the context of a specific access protocol/interface (e.g. OAuth.
  • mailer - "the type of electronic mail software that is used by the individual" - no examples in practice, odd to include a preference for just one type of software.
  • rev - several reasons:
    • There are insufficient examples to really justify keeping this.
    • Cognitive name collision with the (now deprecated in HTML5) "rev" attribute.
    • Re-use more specific and well-defined "last-modified" property from hCalendar instead to preserve functionality, thus reducing the overall vocabulary in use.

only require fn

Through the use of several shorthand rules, 'fn' is already effectively the only required property, thus it would be clearer to simply state that and document how fn sometimes can be used to infer 'n'/'nickname' property values.

root only shorthand syntax

This depends on the "only require fn" proposal above.

Per the microformats principle start-simple, and as evidenced by many folks asking if it is possible to use markup like:

<span class="vcard fn">Tantek Çelik</span>

it makes sense to introduce an even more minimal root only shorthand syntax (ROSS) that achieves the same goal, e.g.:

<span class="vcard">Tantek Çelik</span>

It works as follows:

  • if an hCard has no explicit properties (only the root class name has been specified/found)
    • (or perhaps if an hCard root element has no child elements - this is the case that appears to occur in practice)
  • then parse the contents of the root hCard element as text and use that text to imply the 'fn' property, the only required hCard property.
    • all hcard-parsing special element handling still applies, e.g. if the root element is an abbr, use the 'title' attribute, if the root element is an img, use the 'alt' attribute.
  • additionally, the root element is one of the following, then the respective additional property is implied as well:
    • <a href="http://example.com"> - set the 'url' property to the 'href' attribute
    • <img src="p.jpg"> - set the 'photo' property to the 'src' attribute
    • <object data="http://example.com/p">
      • if the 'type' attribute is a MIME type starting with "image/", then set the 'photo' property to the 'data' attribute
      • if the 'type' attribute is a MIME type starting with "audio/", then set the 'sound' property to the 'data' attribute

Issues:

  • could only be used for "people" hCards, since no "org", nor any location properties would be implied.

This notion of root only shorthand syntax (ROSS), could (and probably should) be generalized to all compound-microformats. Of course it will require that all compound-microformats has only one required property (all others being optional), thats value is then implied by the content of the root only syntax. Thus:

In addition, all compound properties of a microformat should have zero or one required subproperties, and similar to ROSS, should imply their required (or primary optional if none are required) subproperty accordingly. E.g.

  • "adr" should/could imply "extended-address"
  • "geo" could imply "latitude" from the first decimal number in its text value, and if it is followed by non-numerical content (e.g. a "," or ";" or " " or " longitude:"), "longitude" from the first decimal number that followed that chunk of non-numerical content.

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 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. class="fn extended-address"), then

  1. The hCard represents contact information for a place and SHOULD be treated as such.
  2. The author also MUST NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "".
  3. 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")?

For further consideration: One real problem right now is that we provide a field for our users to enter a 'Location' on our User Pages. In real life this has ranged from '8th floor', 'New York', 'Company Name', My Desk', 'http://some.site.com' - the majority being generalized geographic city or state names. Right now there is no property to properly handle this, but this one appears to come close. If this cannot be used for such purposes I would ask that this be looked into further as I don't think its a unique problem.

  • Have you considered using label instead of adr?

Examples in the wild

  • The named location "Picnic benches" in the address "Picnic benches, South Park, San Francisco, California" in a blog post on adactio.com.
<span class="vcard">
 <span class="adr">
  <span class="fn extended-address">Picnic benches</span>
  <span class="street-address">South Park</span>
  <span class="locality">San Francisco</span>
  <span class="region">California</span>
 </span>
</span>

Potential examples in the wild

  • The location "Phone Boxes by the Sealife Centre" on Upcoming is currently marked up as "fn org":
<div class="vcard">
 <div class="fn org">Phone Boxes by the Sealife Centre</div>
  <div class="adr">
   <span class="street-address">Marine Parade</span><br />
   <span class="locality">Brighton & Hove</span>,
   <span class="region">England</span>
   <span class="postal-code">BN2 1TB</span><br />
   <span class="country">United Kingdom</span><br />
   <span class="tel">01273 606674</span>
  </div>
 <div class="note">Just a meeting place, in case the venue changes.</div>
</div>

This could be marked up as:

<div class="vcard">
 <div class="adr">
  <div class="fn extended-address">Phone Boxes by the Sealife Centre</div>
   <span class="street-address">Marine Parade</span><br />
   <span class="locality">Brighton & Hove</span>,
   <span class="region">England</span>
   <span class="postal-code">BN2 1TB</span><br />
   <span class="country">United Kingdom</span><br />
   <span class="tel">01273 606674</span>
  </div>
 <div class="note">Just a meeting place, in case the venue changes.</div>
</div>

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.

<div class="vcard">
  <span class="fn org">Powell's Pool</span>
  <span class="adr">
    <span class="extended-address">Sutton Park</span>
    <span class="locality">Birmingham</span>
    <span class="country-name">England</span>
  </span>
</div>

Andy Mabbett 05:40, 15 Dec 2007 (PST)

Revised proposal

named location formats

Previous named location format efforts:

Simple GeoRSS featurename

The Simple GeoRSS vocabulary contains the following named location example in the "Additional Properties" section that references a featurename tag.

Feature Type, Feature Name, and Relationship Tags

The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.

    <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>

A search for featurename on georss.org fails to find any other references however, including a definition.

An 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. Flickr, 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 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 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 Flickr and 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 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. class="fn nickname"), then

  1. The content of the "fn" is treated as a "nickname" property value.
  2. 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:

<span class="vcard">
 <span class="given-name">Tantek</span>
 <span class="family-name">Çelik</span>
</span>

would be treated from a parsing perspective as:

<span class="vcard"><span class="n">
 <span class="given-name">Tantek</span>
 <span class="family-name">Çelik</span>
</span></span>

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

<span class="vcard"><span class="fn n">
 <span class="given-name">Tantek</span>
 <span class="family-name">Çelik</span>
</span></span>

Examples

  • See hcard-examples, which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in RFC 2426.

Using RFC2806 with hCard

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 : Uniform Resource Identifier (URI) SCHEMES

tel   telephone [RFC2806]
fax   fax       [RFC2806]
modem modem     [RFC2806]

It is practical to write your tel number like this.

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

or even

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

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

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.

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

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

for hCard 1.1

hCard 1.1 will incorporate all fixes going into hCard 1.0.1, and in addition, as a minor feature revision, will incorporate changes and a few new properties based on:

  • hcard-1-0-1
  • existing research and resolved issues
  • vcard-suggestions
  • vCard 4.0 proposed standard - properties that represent existing content in the wild
  • potentially other widely used characteristics from sites using hCard (e.g. Wikipedia infobox and other templates).

hCard 1.1 will likely be one of a few predefined vocabularies as part of the microformats-2 work and only defined within the microformats-2 syntax.

As I evaluate brainstorms listed below, if they make sense to include in hCard 1.1, I'll move them here. Tantek

languages spoken

Consider languages-spoken as a possible addition based on examples gathered.

coverage area

Consider coverage-area-examples as a possible addition based on examples gathered.

just brainstorming

The following brainstorming suggestions are interesting ideas for how to use or improve hCard but are theoretical (no real world examples found yet), or have insufficient real world examples to be deserving of explicit inclusion in the specification.

named phone numbers

hCard is already specified for use for:

  • people
  • organizations
  • named locations

Numerous examples of all of these can be found on the web.

Another possible addition is a named telephone numbers. So far the examples are fairly limited:

In this case, Zakim, for example, has a name, a telephone number, and a URL for "status".

It also makes sense as something that might be in your address book, and therefore have a vCard serialization.

So it might make sense to have an hCard for Zakim which contained the information that you might want added to your address book about it.

Another way to achieve this would be with perhaps a new/different "tel" microformat extracted from hCard, perhaps even a named "tel" microformat (e.g. with root class name "vtel", properties "fn", "tel", "url" based on the above example.).

for hCard 2

done

  • hcard-implied - has been incorporated and generalized for all microformats