hcard-ja
<entry-title>hCard</entry-title>
hCard は、vCard (RFC2426) のプロパティと値を利用して、HTML で人や会社、組織や場所を表現する microformat です。hCard は HTML や XHTML はもちろんのこと、Atom、RSS、その他の XML に埋め込むことができます。
hCard を利用するには、いくつかの方法があります。
- hCard creator hCard を利用し、作成したコードをページにはりつける。
- hCard authoring tips を読んで、hCard のマークアップを行う。
hCard 仕様書
- 編集者
- Tantek Çelik (http://tantek.com/, and before at Technorati, Inc., and at Microsoft Corporation)
- 作者
- Tantek Çelik (affiliations above)
- Brian Suda (http://suda.co.uk/)
- 謝辞
- 謝辞のセクションをご覧ください。
権利に関する情報は、著作権と特許のセクションをご覧ください。
はじめに
vCard (RFC2426) は、Apple のアドレスブック機能をはじめ、さまざまなところで実装され、広く使われているフォーマットです。
さて、多くのブロガーは自分の名前を出し、友人や家族のことを書いています。人に関するこれらの情報にすこし構造を加えるだけで、アグリゲーターやスパイダーはその情報を取得し、vCard へ自動的に変換しアプリケーションで利用することができます。
この仕様は、hCard というフォーマットを定義します。これは vCard のプロパティや値を、XTHML でそのまま表現しようとするものです。ブロガーは hCard を Web ページに埋め込み、CSS で思うようにデザインすることができます。また、hCard はアプリケーションが他のファイルを参照することなしに、そのページから情報を取り出すことを可能とします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
フォーマット
基本情報
vCard (RFC2426) のプロパティ名や値が、hCard の基礎となります。
hCard は、vCard のオブジェクト/プロパティ名を小文字にして、class 属性の値に使用します。vCard オブジェクトの入れ子関係は、そのまま HTML での入れ子関係に置き換えられます。
ルート class 名
hCard のルート class 名は "vcard" です。"vcard" という class 名が指定された要素を、hCard と呼びます。
プロパティとサブプロパティ
hCard のプロパティは、hCard 内の要素によって表されます。次のリストにあるプロパティを class 属性に指定することにより、プロパティを表現します。いくつかのプロパティはサブプロパティを持ちますが、これらはプロパティ要素の中にサブプロパティ要素を設け表現します。
プロパティリスト
hCard のプロパティは次の通りです。サブプロパティは括弧内に記述しています。
必須プロパティ
- fn
- n1 (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)
任意プロパティ
- nickname, sort-string
- url, email (type, value), tel2 (type, value)
- adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
- geo (latitude, longitude), tz
- photo, logo, sound, bday
- title, role, org (organization-name, organization-unit)
- category, note
- class, key, mailer, uid, rev
プロパティについて
1. ^: 'n' プロパティは、"n" の推測処理にあるルールに当てはまる場合は、任意 (OPTIONAL) プロパティとなります。
2. ^: tel - 電話番号は、E.123に従って記述することができます (MAY)。文字の入った電話番号 (例: +1-555-FORMATS) は、数字で表記しなければなりません (MUST)。abbr
を利用して、ソフトウェアには数字から成る電話番号の方を伝えることもできます (<abbr title="+15553676287">+1-555-FORMATS</abbr>
)。
複数のプロパティ
ひとつの hCard は、一つ以上の 'fn'、'n'、'bday'、'tz'、'geo'、'sort-string'、'uid'、'class' を持つことはありません。これらのプロパティが複数ある場合は、最初の値を残し、他の値を無視するべきです (SHOULD)。
他のプロパティは複数あっても構いません (MAY)。この場合、複数あるプロパティはその数だけ新しいインスタンスを作成します。
"Human readable" か "Machine readable" か
要素の内容のうち、人間に見えるテキスト情報が、そのプロパティの値を表します。しかし、いくつか例外が存在します。
もし <abbr>
要素がプロパティに用いられている場合、要素の内容ではなく <abbr>
要素の 'title
' 属性値がプロパティの値となります。要素の内容は、より人間にとって読みやすい値の表現となります。
もし <a>
要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。
- 'photo' プロパティと、他に URL を取るすべてのプロパティでは、
href="..."
属性の値がプロパティの値となります。 - その他のプロパティでは、要素の内容がプロパティの値となります。
もし <img>
要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。
- 'photo' プロパティと、他に URL を取るすべてのプロパティでは、
src="..."
属性の値がプロパティの値となります。 - その他のプロパティでは、
<img>
要素の 'alt
' 属性の値がプロパティの値となります。
もし <object>
要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。
- 'photo' プロパティと、他にURLを取るすべてのプロパティでは、
data="..."
属性の値がプロパティの値となります。 - その他のプロパティでは、要素の内容がプロパティの値となります。
値の抜粋
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合は特別な class 名である "value
" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップする hCard を例に取り説明しましょう。
vCard:
TEL;TYPE=HOME:+1.415.555.1212
hCard:
<span class="tel"> <span class="type">home</span>: <span class="value">+1.415.555.1212</span> </span>
この hCard は次のように表示されるでしょう。
home: +1.415.555.1212
プロパティの例外
vCard には、Web ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。
- vCard の NAME、PROFILE、SOURCE、PRODID、VERSION プロパティは RFC2426 のセクション2.1.2、2.1.3、2.1.4、3.6.3、3.6.9 で定義されていますが、hCard ではこれらのプロパティを使ってはいけません (MUST NOT)。hCard を利用するものは、もしこれらのプロパティが使われていた場合、それらを無視する必要があります (MUST)。hCard から vCard へ変換するコンバーターは、これらのプロパティの代わりに hCard が埋め込まれている Web ページの情報を用いて、これらのプロパティを埋めることになります。まず、NAME プロパティは文書のタイトル ((X)HTML 文書の場合、
<title>
要素) を用いることが推奨されます (SHOULD)。PROFILE の値には、RFC2426 より "VCARD
" の値を使うことができます (MAY)。SOURCE プロパティには、ページの URL を用いることが推奨されます (SHOULD)。hCard を vCard に変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODID プロパティは、実際に vCard を出力するサービスやアプリケーションのみが記述するべきです (SHOULD)。同様に、そのようなアプリケーションのみが、RFC2426 のセクション 3.6.9 に倣い、VERSION プロパティに "3.0" という値をつけるべきです (SHOULD)。
組織のコンタクト情報
もし、"FN" と "ORG" プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、その hCard は会社や組織、場所のコンタクト情報を表すものとみなされます (SHOULD)。このとき、作成者は "N" プロパティを記述することはできない (MUST NOT)、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます (SHOULD)。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。
"n" の推測処理
vCard では "N" プロパティの記述が必須となっています。ところが vCard 仕様書 (RFC2426) では、最後の方 (p.38) にある作者の vCard に "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCard では次のように規定します。
もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります (MUST)。しかし、組織名の場合はこのルールに当てはまりません。この場合は組織のコンタクト情報で書かれているルールが適用されます。
- "FN" の内容は、ホワイトスペースで区切られた二つの "単語" に分解されます。
- "FN" の 最初の 単語は、"N" プロパティの "given-name" として扱われます。
- "FN" の 次の/最後の 単語は、"N" プロパティの "family-name" として扱われます。
- 例外: もし最初の単語がコンマ "," で終わる、または二つ目の単語が一文字 (または一文字とピリオド ".")であった場合、コンマを抜いた最初の単語が "family-name" となり、二つ目の単語が "given-name" となります。
これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。
- given-name (スペース) family-name
- family-name (コンマ) given-name
- family-name (コンマ) given-name のイニシャル
- family-name (スペース) given-name のイニシャル (任意のピリオド)
注: 日本語で名前を記述するときには、この推測処理を利用することはできません。必ず given-name、family-name プロパティを利用し、明示的に名前を記述しなければなりません。
<div class="vcard"> <span class="fn n"> <span class="family-name">マイクロ</span> <span class="given-name">太郎</span> </span> </div>
"nickname" の推測処理
ユーザーレビューの作者など、Web においてニックネームやハンドル、そしてユーザーネームは広く普及しています。そこで、hCard は "nickname" を推測する処理方法を規定しました。
"nickname" の推測機構は "n" の推測処理と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。
- "FN" プロパティの内容は "nickname" プロパティの値として解釈される必要があります (MUST)。
- パーサは存在しない "N" プロパティについて、"N" のサブプロパティに空の値を与えたと仮定し、処理することが推奨されます (SHOULD)。
パーサはニックネームの推測処理に従う必要がありますが (MUST)、hCard の作成者は "nickname" プロパティを明示することが推奨されます (SHOULD)。次のような場合においてもです。
<span class="vcard"> <span class="fn nickname">daveman692</span> </span>
また、hCard は推測されたニックネームに加え、明示的に記述された "nickname" プロパティを持つことができます (MAY)。
"organization-name" の推測処理
"ORG" プロパティは organization-name と organization-unit という二つのサブプロパティを持っています。しかしほとんどの場合、作成者は organization-name のみを記述します。よって、もし "ORG" プロパティが "organization-name" プロパティを内側に持たない場合、"ORG" プロパティの内容は必ず "organization-name" とみなされます (MUST)。
カテゴリーとしてのタグ
hCard のカテゴリーは rel-tag を用い、タグとして表現することも可能です (MAY)。"category" プロパティが rel-tag である場合、そのタグはカテゴリーとして扱われます。
'type' サブプロパティの値
'type' サブプロパティがとる値は、その親プロパティによって異なります。これらの 'type' サブプロパティの値は大文字小文字を区別しません (case-INSENSITIVE)。よって "Home" は "home" と同じであり、その他の値と組み合わせた場合についても同様です。たとえば、家の電話番号で、かつ優先番号であるものは次のようになります。
vCard:
TEL;TYPE=HOME,PREF:+1.415.555.1212
hCard:
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred): <span class="value">+1.415.555.1212</span> </span>
この例は次のように表示されるでしょう。
Home (preferred): +1.415.555.1212
type with unspecified value
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.
<span class="tel"><span class="type">Home</span> +1.415.555.1212</span>
is equivalent to:
<span class="tel"><span class="type">Home</span><span class="value"> +1.415.555.1212</span></span>
And thus the type is "home" and the value is "+1.415.555.1212".
adr tel email types
次のリストは 参考情報 です。
規範的な type の値は RFC2426 のセクション 3.2.1 ADR、3.3.1 TEL、3.3.2 EMAIL を参照してください (ここでは利便性の為にコピーしています)。type サブプロパティのデフォルト値はリストの最初に並んでおり、また大文字で記述されています。また、これらの type は複数指定することができます。
- adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
- tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, car, isdn, pcs
- email type: INTERNET, x400, pref, "IANA に登録された他のアドレスタイプ"
注: 日本語などの言語では、これらサブプロパティの多くを利用することができません。サブタイプはマークアップの制限上、その内容を訳すことができないからです。
XMDP プロファイル
hCard の XMDP プロファイルは hcard-profile をご覧ください。hcard-profile には上で説明したプロパティの全てが、RFC2426 のセクション番号付きでリスト化されています。
パース処理
hCard parsing をご覧ください。
hCard の例
このセクションは参考情報です。
vCard のサンプル
次にあるのは vCard のサンプルです。
BEGIN:VCARD VERSION:3.0 N:Çelik;Tantek FN:Tantek Çelik URL:http://tantek.com/ END:VCARD
この vCard を hCard で表現すると次のようになります。なお、推測処理ができるプロパティについては省略してあります。他の例は hCard Example 1 をご覧ください。
<div class="vcard"> <a class="url fn" href="http://tantek.com/">Tantek Çelik</a> </div>
この hCard は次のように表示されるでしょう。
Note: hCard のマークアップにはバージョン情報が必要ありません。なぜならバージョンは <head> 要素の 'profile' 属性に記述されたプロファイルで定義されているからです。
hCard の実例
次にあるのは Commercenet のコンタクト情報です。この情報は hCard を用いて記述されているので、microformats をパース処理するツールにより見つけることができます。
Palo Alto, CA 94301
The mark-up, emboldening omitted for clarity, with the following semantic improvements:
abbr
to expand abbreviations- hyperlinking the org name with the url
<div class="vcard"> <a class="fn org url" href="http://www.commerce.net/">CommerceNet</a> <div class="adr"> <span class="type">Work</span>: <div class="street-address">169 University Avenue</div> <span class="locality">Palo Alto</span>, <abbr class="region" title="California">CA</abbr> <span class="postal-code">94301</span> <div class="country-name">USA</div> </div> <div class="tel"> <span class="type">Work</span> +1-650-289-4040 </div> <div class="tel"> <span class="type">Fax</span> +1-650-289-4041 </div> <div>Email: <span class="email">info@commerce.net</span> </div> </div>
その他の例
hCard examples には vCard 仕様書 RFC2426 の例をすべて hCard にしたものをはじめ、もっとたくさんの例があります。
hCard ボタン
hCard を使ったあなたのページに、次にあるボタンを貼り付けましょう。buttons#hCard には、最近追加されたボタンもあります。
- (ミラー: )
- CSS でボタン風にデザインすることもできます。microformat badges @ re-run をご覧ください。
実世界での例
このセクションは参考情報です。すでに世界には多くの hCard が存在しています。以前はこの仕様書で紹介していましたが、数が増えすぎてしまったため、別のページを用意しました。
hCard Examples in the wild で、実際に使われている hCard をご覧ください。
実装
このセクションは参考情報です。前のセクションと同じく、hCard の実装についても別のページを用意しています。
hCard Implementations で、hCard の実装についてご覧ください。
著作権
仕様の作成者である Tantek Çelik および Brian Suda が、自分のページでパブリックドメインの声明を行っています。よって、この仕様はパブリックドメインです。
Public Domain Contribution Requirement. Since the author(s) released this work into the public domain, in order to maintain this work's public domain status, all contributors to this page agree to release their contributions to this page to the public domain as well. Contributors may indicate their agreement by adding the public domain release template to their user page per the Voluntary Public Domain Declarations instructions. Unreleased contributions may be reverted/removed.
特許
This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.
参考文献
規範的な参考文献
- XHTML 1.0 SE
- vCard RFC2426
- ITU 勧告 E.123 電話番号フォーマット (有料)
- RFC 2119
その他の参考文献
- hCard history
- X.520 in Postscript (HTMLization courtesy of Google Cache) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
- HTML reformatted version of RFC2426
- CSS1
- XHTML 1.1
- Wikipedia summary of ITU-T Recommendation E.123 - for "TEL" values.
- Internet Mail Consortium Personal Data Interchange vCard and vCalendar
- ISO8601
hCard を利用する仕様
hCard に似通っているもの
原案及び謝辞
vCard を "何年も前に" 教えてくれた私の良き友人 Vadim に感謝しています。ただ、もしあのときから vCard を気にかけていたら、もっと多くの車輪の再発明を防げたかもしれませんが。
vCard における由来
このセクションは 参考情報 です。
意味的に同等なもの
いくつかのプロパティにおいて、その意味を上手く表現できる HTML 要素が存在します。次に挙げるプロパティは、その例に書かれている (X)HTML で表現すべきです (SHOULD)。
- vCard の
URL
は hCard にて<a class="url" href="...">...</a>
と表します。このプロパティは、class="vcard"
をつけた要素の中に書かれます。 - 同様に vCard の
EMAIL
は<a class="email" href="mailto:...">...</a>
となります。 - vCard の
PHOTO
は<img class="photo" src="..." alt="Photo of ..." />
、または<object class="photo" data="..." type="...">Photo of ...</object>
となります。 - vCard の
UID
hCard において、特定の URL (または EMAIL) といった、別の意味に置き換えられます。
出現回数が一回のプロパティ
プロパティの出現回数は、vCard RFC2426 で定義されるプロパティを一つずつ調べ、そのセマンティクスから一つのみでなければならない (MUST) を導き出したものです。hcard-singular-properties に解説があるので、そちらをご覧ください。
単数化されたプロパティ
いくつかの複数系のプロパティ名が単数名化されています。このため、もし元となる複数形のプロパティが、複数のコンポーネントからなるひとつの値を取るものであっても、それらのコンポーネントは、単数名化されたプロパティを複数持つものとなります。
その他の読み物
- Garrett Dimon による Digital Web Magazine: Microformats Primer は hCard の良い解説です。
- Drew McLellan による Practical Microformats with hCard
- Chris Silver Smith による Local Search Engine Optimization using Microformats
- Andrew D. Hume は usable microformats という、hCard に関する記事を書いています。
- Jesse Skinner's introduction to hCard
- Shaun Shull's によるHow Microformats Affect SEO という素晴らしい記事があります。彼の hCard を例に取って解説しています。
- 24 Ways: Styling hCards with CSS 24 Ways の記事です。John Allsopp が CSS を用い、hCard をスタイリングしています。
- このページについて書かれた blog と hCard タグ もご覧ください。
- RFC 4770 インスタントメッセージングの拡張
- A real life use case of Microformat hCard in action by Bob Ngu
- Getting Semantic With Microformats, Part 3: hCard by Emily Lewis
- Microformats: The Fine Art of Markup: hCard by Andy Clarke
関連ページ
- hCard
- hCard cheatsheet - hCard properties
- hCard creator (feedback) - create your own hCard.
- hCard authoring - learn how to add hCard markup to your existing contact info.
- hCard examples - example usage of various classes within hCard.
- hCard examples in the wild - an on-going list of websites which use hCards.
- hcard-supporting-user-profiles - sites with user profiles marked up with hCard - a very common example.
- hCard FAQ - if you have any questions about hCard, check here.
- hCard implementations - websites or tools which either generate or parse hCards.
- hCard parsing - normative details of how to parse hCards.
- hCards and pages - semantic distinctions between different hCards on a page, and how to identify each
- hcard-user-interface - techniques and issues surrounding user-interfaces to author, publish, and display hCards.
- hCard profile - the XMDP profile for hCard
- hCard singular properties - an explanation of the list of singular properties in hCard.
- hCard tests - a wiki page with actual embedded hCards to try parsing.
- hCard advocacy - encourage others to use hCard
- hCard "to do" - jobs to do
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.
- hCard brainstorming - brainstorms and other explorations relating to hCard.
- hcard-parsing-brainstorming - brainstorming specific to parsing of hCard
- geo brainstorming
- hCard feedback - general feedback (as opposed to specific issues).
- hCard issues - specific issues with the specification.
- vCard errata - corrections to the vCard specification, which underlies hCard.
- vCard suggestions - suggested improvements to the vCard specification.