hcard-ja

From Microformats Wiki
Revision as of 09:31, 20 February 2007 by KoichiWada (talk | contribs) (4. Format以下一部翻訳)
Jump to navigation Jump to search

hCard

hCardは個人、会社、組織、および場所を表現する、シンプルでオープンに配布されているフォーマットです。 semantic XHTMLの中のvCard標準(RFC2426)の属性(propreties)および属性値(values)と一対一に対応した表現となっています。

hCardを使い始めたいですか？ 連絡先を書いて公開するのにはhCard creatorを使いましょう。または、hCard authoring tipsに従って現在のあなたの連絡先のページにhCardマークアップを追加しましょう。

Specification

Editor

Tantek Çelik, Technorati, Inc.

Authors

Copyright

This specification is (C) 2004-2024 by the authors. However, the authors intend to submit (or already have submitted, see details in the spec) this specification to a standards body with a liberal copyright/licensing policy such as the GMPG, IETF, and/or W3C. Anyone wishing to contribute should read their copyright principles, policies and licenses (e.g. the GMPG Principles) and agree to them, including licensing of all contributions under all required licenses (e.g. CC-by 1.0 and later), before contributing.

Patents

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

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.

Introduction

The vCard standard (RFC2426), has been broadly interoperably implemented (e.g. Apple's "Address Book" application built into MacOSX).

In addition, many bloggers identify themselves by name and discuss their friends and family. With just a tad bit of structure, bloggers can discuss people in their blog(s) in such a way that spiders and other aggregators can retrieve this information, automatically convert them to vCards, and use them in any vCard application or service.

This specification introduces the hCard format, which uses a 1:1 representation of the properties and values of the aforementioned vCard standard, in semantic XHTML. Bloggers can both embed hCards directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCard enables applications to retrieve information directly from web pages without having to reference a separate file.

Use the hCard creator and copy the HTML code it generates to your blog or website to publish your contact info.

Semantic XHTML Design Principles

Note: the Semantic XHTML Design Principles were written primarily within the context of developing hCard and hCalendar, thus it may be easier to understand these principles in the context of the hCard design methodology (i.e. read that first). Tantek

XHTML is built on XML, and thus XHTML based formats can be used not only for convenient display presentation, but also for general purpose data exchange. In many ways, XHTML based formats exemplify the best of both HTML and XML worlds. However, when building XHTML based formats, it helps to have a guiding set of principles.

  1. Reuse the schema (names, objects, properties, values, types, hierarchies, constraints) as much as possible from pre-existing, established, well-supported standards by reference. Avoid restating constraints expressed in the source standard. Informative mentions are ok.
    1. For types with multiple components, use nested elements with class names equivalent to the names of the components.
    2. Plural components are made singular, and thus multiple nested elements are used to represent multiple text values that are comma-delimited.
  2. Use the most accurately precise semantic XHTML building block for each object etc.
  3. Otherwise use a generic structural element (e.g. <span> or <div>), or the appropriate contextual element (e.g. an <li> inside a <ul> or <ol>).
  4. Use class names based on names from the original schema, unless the semantic XHTML building block precisely represents that part of the original schema. If names in the source schema are case-insensitive, then use an all lowercase equivalent. Components names implicit in prose (rather than explicit in the defined schema) should also use lowercase equivalents for ease of use. Spaces in component names become dash '-' characters.
  5. Finally, if the format of the data according to the original schema is too long and/or not human-friendly, use <abbr> instead of a generic structural element, and place the literal data into the 'title' attribute (where abbr expansions go), and the more brief and human readable equivalent into the element itself. Further informative explanation of this use of <abbr>: Human vs. ISO8601 dates problem solved

フォーマット

一般

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