hcard-ja

From Microformats Wiki
Revision as of 15:22, 27 October 2007 by Vantguarde (talk | contribs) (intro)
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
謝辞
謝辞のセクションをご覧ください。

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

Introduction

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のオブジェクト/プロパティ名を小文字にしたものをクラス名として使用します。vCardオブジェクト上での入れ子関係は、そのままXHTML要素の入れ子関係に置き換えられます。

More Semantic Equivalents

プロパティの中には、HTML要素で表現するほうがより良くその意味を伝えるものがあります。以下のプロパティはそれに続く(X)HTMLで表現すべき(SHOULD)です。

  • vCardのURLは、hCardではclass="vcard"を含む要素の内部にある<a class="url" href="...">...</a>になります。
  • 同様にvCardのEMAILは、<a class="email" href="mailto:...">...</a>になります。
  • vCardのPHOTOは、<img class="photo" src="..." alt="...の写真" />または<object class="photo" data="..." type="...">...の写真</object>になります。
  • vCardのUIDは、単純に、hCardを特定するURL(またはEMAIL)へのもう一つの意味付けになります。

Singular vs. Plural Properties

For properties which are singular (e.g. "N" and "FN"), the first descendant element with that class should take effect, any others being ignored.

For properties which can be plural (e.g. "TEL"), each class instance should create a instance of that property.

Singular properties

Singular properties: "FN", "N", "BDAY", "TZ", "GEO", "SORT-STRING", "UID", "CLASS".

All other properties are plural. This list has 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.

Human vs. Machine readable

If an <abbr> element is used for a property, then the 'title' attribute of the <abbr> element is the value of the property, instead of the contents of the element, which instead provide a human presentable version of the value.

If an <a> element is used for one or more properties, it must be treated as follows:

  1. For the "PHOTO" property and any other property that takes a URL as its value, the href="..." attribute provides the property value.
  2. For other properties, the element's content is the value of the property.

If an <img> element is used for one or more properties, it must be treated as follows:

  1. For the "PHOTO" property and any other property that takes a URL as its value, the src="..." attribute provides the property value.
  2. For other properties, the <img> element's 'alt' attribute is the value of the property.

If an <object> element is used for one or more properties, it must be treated as follows:

  1. For the "PHOTO" property and any other property that takes a URL as its value, the data="..." attribute provides the property value.
  2. For other properties, the element's content is the value of the property.

値の抽出

あるプロパティに一致する要素があっても、その要素の一部のみをそのプロパティの値として使用すべき場合があります。 これは典型的には、TELに対するTYPE=HOMEや、TYPE=WORKのようにプロパティが下位の型を持つ場合におこります。 このため、要素中のプロパティの値となる部分を指定するための特別のクラス名"value"が導入されています。 例:ここにhCardの自宅の電話番号をマークアップするための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には意味のないプロパティ、または、すでにウェブページのなかではすでにその意味が含まれているものがあります。このセクションでは、それらのプロパティについて、どうしたら良いか(または何をすべきでないか)を説明します。

  1. NAME, PROFILE, SOURCE, PRODID, VERSION properties as defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of RFC 2426. Content publishers MUST NOT use these properties in their hCards, and as such, hCard consumers/parsers MUST IGNORE these properties if they are found within an hCard. Instead. hCard to vCard converters SHOULD use the title of the page where the hCard is found (e.g. the <title> element in (X)HTML documents) to construct the NAME property, MAY output a PROFILE value of "VCARD" per RFC 2426, SHOULD use the URL of the page where the hCard is found to construct the SOURCE property (e.g. perhaps as a parameter to a URL/service that converts hCards to vCards), for an output vCard stream (e.g. a .vcf file). Only services/applications that output actual vCards should write the PRODID property, with the product identifier for said service/application. Similarly only such services/applications should write the VERSION property, with the value "3.0" (without quotes) per RFC2426 Section 3.6.9.

組織の連絡先情報

"FN"と"ORG"プロパティが完全に同じ値を持つ場合、(典型的にはclass="fn org"のように、一つの要素に両方が指定されている場合)、そのhCardは、会社または組織の連絡先情報を表し、そのように取り扱われるべきです。この場合、hCardの作成者は、"N"プロパティを設定しないか、"N"プロパティとその全ての下位プロパティの値を空文字列に設定するかのどちらかでなくてはいけません(MUST)。パーザーは存在しない"N"プロパティを、"N"とその全ての下位プロパティの値を空文字列に設定したものとして解釈します。

Implied "n" Optimization

vCardでは"N"プロパティを必須となっていますが、vCard仕様(RFC 2426)の終わり近くにある著者達のvCardには"N"プロパティが含まれていません。(p.38) この明らかな矛盾は、仕様書上にある例のような場合に関して、単に"FN"プロパティの値から"N"プロパティの値を導くことができるようにすれば解決します。hCardでは明示的にそれを行います。

もし"FN"と"ORG"がおなじでなく(全セクション参照)、"FN"プロパティの値が正確に2語(空白で区切られた)からなり、さらに明示的な"N"プロパティがない場合、"N"プロパティは"FN"から導出されます。"FN"が1語のみ、または3語以上の場合は、hCardの作成者は"N"を明示的にマークアップしなければなりません(MUST)。これについては、組織の連絡先情報の場合は例外となります。 上記を参照

  1. "FN"内容は空白により2語に分割されます。
  2. "FN"の最初の語は"N"プロパティの"given-name"として解釈されます。
  3. "FN"の2番目/最後の語は"N"プロパティの"family-name"として解釈されます。
  4. 例外: もしも最初の語がカンマ","で終わっているか、 2番目の語が1文字(または後ろに余分のピリオド"."が付加されたもの)である場合、最初の語(最後にカンマがあればそれを取り除いたもの)は"family-name"として、2番目の語は"given-name"として解釈されます。

これにより、人物の記述について、以下のような典型的なケースを単純化できます。

  • 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 on the Web 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" 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.

Note: 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 can optionally 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.

ルートクラス名

hCardのルートとなるクラス名は"vcard"です。

プロパティリスト

以下はhCardのプロパティのリストです。(下位のプロパティは、括弧の中に示します。)これらはvCardから取ったものです。

  • 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

Property Notes

  • tel - Authors MAY want to follow the E.123 standard for writing values of telephone numbers.

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 RFC 2426 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 RFC 2426 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=22915"