hcard-ja

From Microformats Wiki
Revision as of 13:54, 29 October 2007 by Vantguarde (talk | contribs) (→‎Implied "n" Optimization: forgot about translating the title)
Jump to navigation Jump to search

hCard

hCardはvCard (RFC2426) のプロパティと値を用い、セマンティックなXHTMLで人や会社、組織や場所を表現するシンプルなフォーマットです。hCardはmicroformatsのひとつであり、(X)HTMLやAtom、RSSやその他のXMLに埋め込むことができます。

hCardを利用してみたいですか？ではまず、hCard creatorを使い、コンタクト情報を公開してください。または、hCard authoring tipsを読み、あなたのコンタクトページをhCardでマークアップしてください。

hCard仕様書

編集者
Tantek Çelik (Technorati, Inc.)
作成者
Tantek Çelik (Technorati, Inc.)
Brian Suda
謝辞
謝辞のセクションをご覧ください。

権利に関する情報は、著作権と特許のセクションをご覧ください。

はじめに

vCard (RFC2426) は、Appleのアドレスブック機能をはじめさまざまなところで実装され、広く使われているフォーマットです。

さて、多くのブロガーは、自分の名前を出し友人や家族のことを書いています。人に関するこれらの情報にすこし構造を加えるだけで、アグリゲーターやスパイダーがその情報を取得し、vCardへ自動的に変換しアプリケーションで利用することができます。

この仕様は、hCard というフォーマットを定義します。これはvCardのプロパティや値を、XTHMLでそのまま表現しようとするものです。ブロガーはhCardをWebページに埋め込み、CSSで思うようにデザインすることができます。また、hCardはアプリケーションが他のファイルを参照することなしに、そのページから情報を取り出すことを可能とします。

hCard creatorを使い、出てきたHTMLコードをblogやWebサイトに貼り付け、コンタクト情報を公開してください。

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オブジェクトの入れ子関係は、そのままXHTML要素の入れ子関係に置き換えられます。

ルートclass名

hCardのルートclass名は "vcard" です。"vcard" というclass名が指定された要素を、hCard と呼びます。

プロパティとサブプロパティ

hCardのプロパティは、hCard内の要素によって表されます。次にリストするプロパティをclass属性に指定することにより、プロパティを表現します。いくつかのプロパティはサブプロパティを持ちますが、これらはプロパティ要素の中にサブプロパティ要素を設け表現します。

プロパティリスト

hCardのプロパティは次の通りです。サブプロパティは括弧内に記述しています。

必須プロパティ

  • fn
  • n* (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)

任意プロパティ

  • nickname, sort-string
  • url, email (type, value), tel** (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

プロパティについて

* 'n' プロパティは、'n' の省略ルールが適用できる場合は、任意 (OPTIONAL) プロパティとなります。
** tel - 電話番号は、E.123に従って記述することができます (MAY)。

複数のプロパティ

ひとつのhCardは、一つ以上の 'fn'、'n'、'bday'、'tz'、'geo'、'sort-string'、'uid'、'class' を持つことはありません。これらのプロパティが複数ある場合は、最初の値を残し、他の値を無視することが推奨されます。

他のプロパティは複数あっても構いません (MAY)。この場合、複数あるプロパティはその数だけ新しいインスタンスを作成します。

"Human readable" か "Machine readable" か

要素の内容のうち、人間に見えるテキスト情報が、そのプロパティの値を表します。しかし、いくつか例外が存在します。

もし <abbr> 要素がプロパティに用いられている場合、要素の内容ではなく <abbr> 要素の 'title' 属性値がプロパティの値となります。要素の内容は、より人間にとって読みやすい値の表現となります。

もし <a> 要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。

  1. 'photo' プロパティと、他にURLを取るすべてのプロパティでは、href="..." 属性の値がプロパティの値となります。
  2. その他のプロパティでは、要素の内容がプロパティの値となります。

もし <img> 要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。

  1. 'photo' プロパティと、他にURLを取るすべてのプロパティでは、src="..." 属性の値がプロパティの値となります。
  2. その他のプロパティでは、<img> 要素の 'alt' 属性の値がプロパティの値となります。

もし <object> 要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります (MUST)。

  1. 'photo' プロパティと、他にURLを取るすべてのプロパティでは、data="..." 属性の値がプロパティの値となります。
  2. その他のプロパティでは、要素の内容がプロパティの値となります。

値の抜粋

要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'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ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。

  1. 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)。しかし、組織名の場合はこのルールに当てはまりません。この場合は組織のコンタクト情報で書かれているルールが適用されます。

  1. "FN" の内容は、ホワイトスペースで区切られた二つの "単語" に分解されます。
  2. "FN" の 最初の 単語は、"N" プロパティの "given-name" として扱われます。
  3. "FN" の 次の/最後の 単語は、"N" プロパティの "family-name" として扱われます。
  4. 例外: もし最初の単語がコンマ "," で終わる、または二つ目の単語が一文字 (または一文字とピリオド ".")であった場合、コンマを抜いた最初の単語が "family-name" となり、二つ目の単語が "given-name" となります。

これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。

  • given-name (スペース) family-name
  • family-name (コンマ) given-name
  • family-name (コンマ) given-nameのイニシャル
  • family-name (スペース) given-nameのイニシャル (任意のピリオド)

"nickname" の推測処理

ユーザーレビューの作者など、Webにおいてニックネームやハンドル、そしてユーザーネームは広く普及しています。そこで、hCardは "nickname" を推測する処理方法を規定しました。

"nickname" の推測機構は "n" の推測処理と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。

  1. "FN" プロパティの内容は "nickname" プロパティの値として解釈される必要があります (MUST)。
  2. パーサは存在しない "N" プロパティについて、"N" のサブプロパティに空の値を与えたと仮定し、処理することが推奨されます (SHOULD)。

パーサはニックネームの推測処理に従う必要がありますが (MUST)、hCardの作成者は "nickname" プロパティを明示することが推奨されます (SHOULD)。次のような場合においてもです。 

<span class="vcard">
 <span class="fn nickname">daveman692</span>
</span>

また、hCardは推測されたニックネームに加え、明示的に記述された "nickname" プロパティを持つことができます (MAY)。

Implied "organization-name" Optimization

The "ORG" property has two subproperties, organization-name and organization-unit. Very often authors only publish the organization-name. Thus if an "ORG" property has no "organization-name" inside it, then its entire contents MUST be treated as the "organization-name".

Tags as Categories

Categories in hCard MAY be represented by tags with rel-tag. When a category property is a rel-tag, the tag (as defined by rel-tag) is used for that category.

type subproperty values

The 'type' subproperty in particular takes different values depending on which property it is a subproperty of. These 'type' subproperty values are case-INSENSITIVE, meaning "Home" is the same as "home", as well as multivalued, e.g. a tel can be home and preferred:

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>

This could be displayed as:

Home (preferred): +1.415.555.1212

The following lists are informative. See RFC2426 sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values. They are repeated here for convenience. Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.

  • 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, "other IANA registered address types"

XMDP Profile

See hcard-profile for the XMDP profile of hCard which contains the above complete list of properties, with references to their RFC2426 definitions.

Parsing Details

See hCard parsing.

Examples

This section is informative.

Sample vCard

Here is a sample vCard: 

BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
ORG:Technorati
END:VCARD

and an equivalent in hCard with various elements optimized appropriately. See hCard Example 1 for the derivation. 

<div class="vcard">
 <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
 <div class="org">Technorati</div>
</div>

This hCard might be displayed as:

Tantek Çelik
Technorati

Note: The version information is unnecessary in hCard markup directly since the version will be defined by the profile of hCard that is used/referred to in the 'profile' attribute of the <head> element.

Live example

Here are the WikiMedia Foundation's contact details, as a live hCard which will be detected, on this page, by microformat parsing tools:

Wikimedia Foundation Inc.

work

200 2nd Ave. South #358
St. Petersburg FL  33701-4313
USA
Phone: work+1-727-231-0101
Email:
Fax: +1-727-258-0207

The mark-up (wrapped, and emboldening omitted, for clarity) used is: 

<div class="vcard">
  <div class="fn org">Wikimedia Foundation Inc.</div>
  <div class="adr">
    <span class="type">work</span>
    <div class="street-address">200 2nd Ave. South #358</div>
    <div>
      <span class="locality">St. Petersburg</span> 
      <abbr class="region" title="Florida">FL</abbr>  <span class="postal-code">33701-4313</span>
    </div>
    <div class="country-name">USA</div>
  </div>
  <div>Phone: <span class="tel"><span class="type">work</span>+1-727-231-0101</span></div>
  <div>Email: <span class="email">info@wikimedia.org</span></div>
  <div>
    <span class="tel"><span class="type">Fax</span>: 
    <span class="value">+1-727-258-0207</span></span>
  </div>
</div>

More Examples

See hCard examples for more examples, including all examples from vCard RFC2426 converted into hCard.

Buttons

You can use these buttons on pages with hCards. See buttons#hCard for any recent additions.

Examples in the wild

This section is informative. The number of hCard examples in the wild has expanded far beyond the capacity of being kept inline in this specification. They have been moved to a separate page.

See hCard Examples in the wild.

Implementations

This section is informative. The number of hCard implementations has also expanded beyond the capacity of keeping them inline. They have been moved to a separate page.

See hCard Implementations.

Copyright

Per the public domain release on the authors' user pages (Tantek Çelik, Brian Suda) this specification is released into the public domain.

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.

Patents

This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.

References

Normative References

Informative References

Specifications That Use hCard

Similar Work

Inspiration and Acknowledgments

Thanks to: my good friend Vadim who introduced me to vCard many years ago, and if I'd only paid more attention then, perhaps I could have helped a lot of people avoid wasting a lot of time reinventing various standards wheels.

Notes on derivation from vCard

This section is informative.

More Semantic Equivalents

For some properties there are HTML elements which better match and convey their semantics. The following properties SHOULD be encoded with the following (X)HTML:

  • URL in vCard becomes <a class="url" href="...">...</a> inside the element with class="vcard" in hCard.
  • Similarly, EMAIL in vCard becomes <a class="email" href="mailto:...">...</a>
  • PHOTO in vCard becomes <img class="photo" src="..." alt="Photo of ..." /> or <object class="photo" data="..." type="...">Photo of ...</object>
  • UID in vCard simply becomes another semantic applied to a specific URL (or EMAIL) for an hCard.

Singular and Plural derivations

The lists of singular and plural properties have been derived by analyzing the semantics of the individual properties in vCard RFC2426 and determining logically that they MUST be singular per their semantics. See hcard-singular-properties for explanations.

Plural Properties Singularized

Since plural property names become their singular equivalents, even if the original plural property permitted only a single value with multiple components, those multiple components are represented each with their own singularly named property and the the property is effectively multivalued and subject to the above treatment of multivalued properties.

Further Reading

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.

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-ja&oldid=22976"