hcard-ja

From Microformats Wiki
Revision as of 18:00, 27 October 2007 by Vantguarde (talk | contribs)
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" サブプロパティに空文字列があるものとみなします。

Implied "n" Optimization

Although vCard requires that the "N" property be present, the authors of the vCard specification (RFC2426) themselves do not include "N" properties in their vCards near the end of the spec (p.38). This apparent contradiction can be resolved by simply allowing the "FN" property to imply "N" property values in typical cases provided in the spec. We do so explicitly in hCard.

If "FN" and "ORG" are not the same (see previous section), and the value of the "FN" property is exactly two words (separated by whitespace), and there is no explicit "N" property, then the "N" property is inferred from the "FN" property. For "FN"s with either one word see below, and for three or more, the author MUST explicitly markup the "N", except for the organization contact info case, see above for that.

  1. The content of "FN" is broken into two "words" separated by whitespace.
  2. The first word of the "FN" is interpreted as the "given-name" for the "N" property.
  3. The second/last word of the "FN" is interpreted as the "family-name" for the "N" property.
  4. Exception: If the first word ends in a "," comma OR if the second word is a single character (optionally followed by a period "."), then the first word (minus the comma at the end if any) is interpreted as the "family-name" and the second word is interpreted as the "given-name".

This allows simplification in the typical case of people stating:

  • given-name (space) family-name
  • family-name (comma) given-name
  • family-name (comma) given-name-first-initial
  • family-name (space) given-name-first-initial (optional period)

Implied "nickname" Optimization

Due to the prevalence of the use of nicknames/handles/usernames in actual content published on the Web (e.g. authors of reviews), hCard also has an implied "nickname" optimization to handle this.

Similar to the implied "n" optimization, if "FN" and "ORG" are not the same, and the value of the "FN" property is exactly one word, and there is no explicit "N" property, then:

  1. The content of the "FN" MUST be treated as a "nickname" property value.
  2. Parsers SHOULD handle the missing "N" property by implying empty values for all the "N" sub-properties.

Though parsers MUST follow the implied nickname optimization, publishers SHOULD explicitly indicate the "nickname" even in this case, e.g.: 

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

The hCard MAY have additional explicit "nickname" property values in addition to the implied nickname.

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.

More Examples

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

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.

References

Normative References

Informative References

Specifications That Use hCard

Similar Work

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.

Insert non-formatted text here

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