hcard-ja: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
(properties)
Line 2: Line 2:
<h1>hCard</h1>
<h1>hCard</h1>
{{TOC-right}}
{{TOC-right}}
hCardはvCard ([[rfc-2426|RFC2426]])のプロパティと値を用い、[[semantic-xhtml|セマンティックなXHTML]]で人や会社、組織や場所を表現するシンプルなフォーマットです。hCardは[[microformats-ja|microformats]]のひとつであり、(X)HTMLやAtom、RSSやその他のXMLに埋め込むことができます。
hCardはvCard ([[rfc-2426|RFC2426]]) のプロパティと値を用い、[[semantic-xhtml|セマンティックなXHTML]]で人や会社、組織や場所を表現するシンプルなフォーマットです。hCardは[[microformats-ja|microformats]]のひとつであり、(X)HTMLやAtom、RSSやその他のXMLに埋め込むことができます。


hCardを利用してみたいですか？ではまず、[http://microformats.org/code/hcard/creator hCard creator]を使い、コンタクト情報を公開してください。または、[[hcard-authoring|hCard authoring tips]]を読み、あなたのコンタクトページをhCardでマークアップしてください。
hCardを利用してみたいですか？ではまず、[http://microformats.org/code/hcard/creator hCard creator]を使い、コンタクト情報を公開してください。または、[[hcard-authoring|hCard authoring tips]]を読み、あなたのコンタクトページをhCardでマークアップしてください。
Line 16: Line 16:
権利に関する情報は、[[hcard#Copyright|著作権]]と[[hcard#Patents|特許]]のセクションをご覧ください。
権利に関する情報は、[[hcard#Copyright|著作権]]と[[hcard#Patents|特許]]のセクションをご覧ください。


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


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


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


[http://microformats.org/code/hcard/creator hCard creator]を使い、出てきたHTMLコードをblogやWebサイトに貼り付け、コンタクト情報を公開してください。
[http://microformats.org/code/hcard/creator hCard creator]を使い、出てきたHTMLコードをblogやWebサイトに貼り付け、コンタクト情報を公開してください。
Line 29: Line 29:
== フォーマット ==
== フォーマット ==
=== 基本情報 ===
=== 基本情報 ===
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426])のプロパティ名や値が、hCardの基礎を構成します。
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) のプロパティ名や値が、hCardの基礎を構成します。


hCardは、vCardのオブジェクト/プロパティ名を小文字にしたものをclass属性の値として使用します。vCardオブジェクトの入れ子関係は、そのままXHTML要素の入れ子関係に置き換えられます。
hCardは、vCardのオブジェクト/プロパティ名を小文字にしたものをclass属性の値として使用します。vCardオブジェクトの入れ子関係は、そのままXHTML要素の入れ子関係に置き換えられます。


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


=== プロパティとサブプロパティ ===
=== プロパティとサブプロパティ ===
Line 56: Line 56:


=== プロパティについて ===
=== プロパティについて ===
<nowiki>*</nowiki> 'n' プロパティは、[[hcard#Implied_.22n.22_Optimization|'n'の省略ルール]]が適用できる場合は、{{任意プロパティ}}となります。<br />
<nowiki>*</nowiki> 'n' プロパティは、[[hcard#Implied_.22n.22_Optimization|'n' の省略ルール]]が適用できる場合は、任意 ({{optional}}) プロパティとなります。<br />
<nowiki>**</nowiki> tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することが{{できます}}。
<nowiki>**</nowiki> tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することができます。


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


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


=== More Semantic Equivalents ===
=== "Human readable" か Machine readable" か ===
プロパティの中には、HTML要素で表現するほうがより良くその意味を伝えるものがあります。以下のプロパティはそれに続く(X)HTMLで表現すべき(SHOULD)です。
要素の内容のうち、人間に見えるテキスト情報が、そのプロパティの値を表します。しかし、いくつか例外が存在します。
* vCardの<code>URL</code>は、hCardでは<code>class="vcard"</code>を含む要素の内部にある<code><a class="url" href="...">...</a></code>になります。
* 同様にvCardの<code>EMAIL</code>は、<code><nowiki><a class="email" href="mailto:...">...</a></nowiki></code>になります。
* vCardの<code>PHOTO</code>は、<code><img class="photo" src="..." alt="...の写真" /></code>または<code><object class="photo" data="..." type="...">...の写真</object></code>になります。
* vCardの<code>UID</code>は、単純に、hCardを特定するURL(またはEMAIL)へのもう一つの意味付けになります。


=== Singular vs. Plural Properties ===
もし <code>&lt;abbr&gt;</code> 要素がプロパティに用いられている場合、要素の内容ではなく <code>&lt;abbr&gt;</code> 要素の '<code>title</code>' 属性値がプロパティの値となります。要素の内容は、より人間にとって読みやすい値の表現となります。
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.
もし <code>&lt;a&gt;</code> 要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります ({{must}})。
# 'photo' プロパティと、他にURLを取るすべてのプロパティでは、<code>href="..."</code> 属性の値がプロパティの値となります。
# その他のプロパティでは、要素の内容がプロパティの値となります。


==== Singular properties ==== 
もし <code>&lt;img&gt;</code> 要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります ({{must}})。
# 'photo' プロパティと、他にURLを取るすべてのプロパティでは、<code>src="..."</code> 属性の値がプロパティの値となります。
# その他のプロパティでは、<code>&lt;img&gt;</code> 要素の '<code>alt</code>' 属性の値がプロパティの値となります。


Singular properties: "FN", "N", "BDAY", "TZ", "GEO", "SORT-STRING", "UID", "CLASS". 
もし <code>&lt;object&gt;</code> 要素が一つ以上のプロパティに用いられている場合、次のように処理される必要があります ({{must}})。
# 'photo' プロパティと、他にURLを取るすべてのプロパティでは、<code>data="..."</code> 属性の値がプロパティの値となります。
# その他のプロパティでは、要素の内容がプロパティの値となります。


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.
=== Value excerpting ===
 
Sometimes only part of an element which is the equivalent for a property is used for the value of the property.  This typically occurs when a property has a subtype, like 'tel'. For this purpose, the special class name "<code>value</code>" is used to excerpt out the subset of the element that is the value of the property. E.g. here is an hCard fragment for marking up a home phone number:<br />
==== 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 <code>&lt;abbr&gt;</code> element is used for a property, then the '<code>title</code>' attribute of the <code>&lt;abbr></code> 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 <code>&lt;a&gt;</code> element is used for one or more properties, it must be treated as follows:
# For the "PHOTO" property and any other property that takes a URL as its value, the <code>href="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.
 
If an <code>&lt;img&gt;</code> element is used for one or more properties, it must be treated as follows:
# For the "PHOTO" property and any other property that takes a URL as its value, the <code>src="..."</code> attribute provides the property value.
# For other properties, the <code>&lt;img></code> element's '<code>alt</code>' attribute is the value of the property.
 
If an <code>&lt;object&gt;</code> element is used for one or more properties, it must be treated as follows:
# For the "PHOTO" property and any other property that takes a URL as its value, the <code>data="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.
 
=== 値の抽出 ===
 
あるプロパティに一致する要素があっても、その要素の一部のみをそのプロパティの値として使用すべき場合があります。
これは典型的には、TELに対するTYPE=HOMEや、TYPE=WORKのようにプロパティが下位の型を持つ場合におこります。
このため、要素中のプロパティの値となる部分を指定するための特別のクラス名"<code>value</code>"が導入されています。
例:ここにhCardの自宅の電話番号をマークアップするためのhCardの一部があります。<br />


vCard:
vCard:
Line 122: Line 97:
</nowiki></pre>
</nowiki></pre>


このhCardの断片は次のように表示することができます:
This hCard fragment could be displayed as:


<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
Line 131: Line 106:
</div>
</div>


=== 例外となるプロパティ ===
<!-- note for Tantek: review/edit property casing from here on -->


vCardには意味のないプロパティ、または、すでにウェブページのなかではすでにその意味が含まれているものがあります。このセクションでは、それらのプロパティについて、どうしたら良いか(または何をすべきでないか)を説明します。
=== Property Exceptions ===
vCard has several properties which either do not make sense on, or are already implied within the context of a web page.  This section explains what to (not) do with them.


# '''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 <code><title></code> element in (X)HTML documents) to construct the NAME property, MAY output a PROFILE value of "<code>VCARD</code>" 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.
# vCard's '''NAME''', '''PROFILE''', '''SOURCE''', '''PRODID''', '''VERSION''' properties are defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of [[rfc-2426|RFC2426]].  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 <code><title></code> element in (X)HTML documents) to construct the NAME property, {{may}} output a PROFILE value of "<code>VCARD</code>" per [[rfc-2426|RFC2426]], {{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 [[rfc-2426|RFC2426]] Section 3.6.9.


=== 組織の連絡先情報 ===
=== Organization Contact Info ===
If the "FN" and "ORG" properties have the exact same value (typically because they are set on the same element, e.g. class="fn org"), then the hCard represents contact information for a company, organization or place and {{should}} be treated as such. In this case the author also {{must-not}} set the "N" property, or set it (and any sub-properties) explicitly to the empty string "". Thus parsers {{should}} handle the missing "N" property, in this case by implying empty values for all the "N" sub-properties.
"FN"と"ORG"プロパティが完全に同じ値を持つ場合、(典型的にはclass="fn org"のように、一つの要素に両方が指定されている場合)、そのhCardは、会社または組織の連絡先情報を表し、そのように取り扱われるべきです。この場合、hCardの作成者は、"N"プロパティを設定しないか、"N"プロパティとその全ての下位プロパティの値を空文字列に設定するかのどちらかでなくてはいけません(MUST)。パーザーは存在しない"N"プロパティを、"N"とその全ての下位プロパティの値を空文字列に設定したものとして解釈します。


=== Implied "n" Optimization ===
=== Implied "n" Optimization ===
Although vCard requires that the "N" property be present, the authors of the vCard specification ([[rfc-2426|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.


vCardでは"N"プロパティを必須となっていますが、vCard仕様(RFC 2426)の終わり近くにある著者達のvCardには"N"プロパティが含まれていません。(p.38) この明らかな矛盾は、仕様書上にある例のような場合に関して、単に"FN"プロパティの値から"N"プロパティの値を導くことができるようにすれば解決します。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, [http://microformats.org/wiki/hcard#Organization_Contact_Info see above] for that.
もし"FN"と"ORG"がおなじでなく(全セクション参照)、"FN"プロパティの値が正確に2語(空白で区切られた)からなり、さらに明示的な"N"プロパティがない場合、"N"プロパティは"FN"から導出されます。"FN"が1語のみ、または3語以上の場合は、hCardの作成者は"N"を明示的にマークアップしなければなりません(MUST)。これについては、組織の連絡先情報の場合は例外となります。 [http://microformats.org/wiki/hcard-ja#Organization_Contact_Info 上記を参照]


# "FN"内容は空白により2語に分割されます。
# The content of "FN" is broken into two "words" separated by whitespace.
# "FN"の最初の語は"N"プロパティの"given-name"として解釈されます。
# The ''first'' word of the "FN" is interpreted as the "given-name" for the "N" property.
# "FN"の''2番目/最後''の語は"N"プロパティの"family-name"として解釈されます。
# The ''second/last'' word of the "FN" is interpreted as the "family-name" for the "N" property.
# 例外: もしも最初の語がカンマ","で終わっているか、 2番目の語が1文字(または後ろに余分のピリオド"."が付加されたもの)である場合、最初の語(最後にカンマがあればそれを取り除いたもの)は"family-name"として、2番目の語は"given-name"として解釈されます。
# 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
* given-name (space) family-name
* family-name (comma) given-name
* family-name (comma) given-name
Line 159: Line 133:


=== Implied "nickname" Optimization ===
=== 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 [[hReview|reviews]]), hCard also has an implied "nickname" optimization to handle this.


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 [[hReview|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:


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:
# The content of the "FN" {{must}} be treated as a "nickname" property value.
# Parsers {{should}} handle the missing "N" property by implying empty values for all the "N" sub-properties.


# The content of the "FN" is treated as a "nickname" property value.
Though parsers {{must}} follow the implied nickname optimization, publishers {{should}} explicitly indicate the "nickname" even in this case, e.g.:
# 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.
<pre><nowiki>
<span class="vcard">
<span class="fn nickname">daveman692</span>
</span>
</nowiki></pre>
 
The hCard {{may}} have additional explicit "nickname" property values in addition to the implied nickname.


=== Implied "organization-name" Optimization ===
=== 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".
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 ===
=== 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.


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.
=== type subproperty values ===
 
=== 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:
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:


Line 204: Line 179:
</div>
</div>


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.
The following lists are ''informative''. See [[rfc-2426|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
* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
Line 212: Line 187:
=== XMDP Profile ===
=== XMDP Profile ===


See [[hcard-profile]] for the [http://gmpg.org/xmdp XMDP] profile of hCard which contains the above complete list of properties, with references to their RFC 2426 definitions.
See [[hcard-profile]] for the [http://gmpg.org/xmdp XMDP] profile of hCard which contains the above complete list of properties, with references to their [[rfc-2426|RFC2426]] definitions.


=== Parsing Details ===
=== Parsing Details ===

Revision as of 16:08, 27 October 2007

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に従って記述することができます。

複数のプロパティ

ひとつの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. その他のプロパティでは、要素の内容がプロパティの値となります。

Value excerpting

Sometimes only part of an element which is the equivalent for a property is used for the value of the property. This typically occurs when a property has a subtype, like 'tel'. For this purpose, the special class name "value" is used to excerpt out the subset of the element that is the value of the property. E.g. here is an hCard fragment for marking up a home phone number:

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>

This hCard fragment could be displayed as:

home: +1.415.555.1212


Property Exceptions

vCard has several properties which either do not make sense on, or are already implied within the context of a web page. This section explains what to (not) do with them.

  1. vCard's NAME, PROFILE, SOURCE, PRODID, VERSION properties are defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of RFC2426. 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 RFC2426, 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.

Organization Contact Info

If the "FN" and "ORG" properties have the exact same value (typically because they are set on the same element, e.g. class="fn org"), then the hCard represents contact information for a company, organization or place and SHOULD be treated as such. In this case the author also MUST NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "". Thus parsers SHOULD handle the missing "N" property, in this case by implying empty values for all the "N" sub-properties.

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=22917"