Microformats Wiki - User contributions [en]

rel-tag-ja

2011-11-01T15:56:03Z

KitaitiMakoto: sync: english: 2011-10-27T15:57:29

<entry-title>rel="tag"</entry-title>

__TOC__

== 仕様ドラフト 2005-01-10 ==
; 編者/作者
:[http://tantek.com/ Tantek Çelik]
:[http://epeus.blogspot.com/ Kevin Marks]

; 原案
:[http://powazek.com/ Derek Powazek]

; 短縮URL
:http://tr.im/reltag

=== 著作権 ===
{{MicroFormatCopyrightStatement2004-ja}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
* [[User:Kevin Marks|Kevin Marks]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

=== 特許 ===
{{MicroFormatPatentStatement-ja}}

== 概要 ==
[[rel-tag-ja|rel-tag]]は[[microformats-ja|microformats]]のひとつです。ハイパーリンクに<code>rel="tag"</code>を書き加える事により、リンク元のページに対しページ作者が定義した「タグ（キーワードやテーマ）」を関連づけることができます。
タグはblogの記事内容すべてに関係する言葉とは限りません。たとえば次のようなリンクでタグを関連づけるとします。

<source lang=html4strict><a href="http://technorati.com/tag/tech" rel="tag">tech</a></source>

これは作者がこのWebページ（または内容の一部）に「tech」というタグをつけていることを意味します。

リンク先のページはWeb上に存在するべき（SHOULD）であり、またタグの意味はリンクテキストの内容よりも、リンク先のページが持つ情報が優先されます。たとえば次のようなマークアップでページに対しタグ付けを行ったとします。

<source lang=html4strict><a href="http://technorati.com/tag/tech" rel="tag">fish</a></source>

URLの最後にある単語がタグの意味として扱われるので、この場合ページのタグは「fish」ではなく「tech」となります。

== rel-tagの意図、範囲 ==
rel-tagはWebページ（又はその一部）に「タグ付け」をする目的で作られました。このため、任意のURLやページ外部のコンテンツに対し、rel-tagによりタグ付けを行える様にはできていません。現在のページから外部のURLへのタグ付けの一般的な構文についての要望はありますが、rel-tagにおいてその議論はなされるべきでないと考えています。[[xfolk|xFolk]]や[[hreview|hReview]]、[[hcard |hCard]]、[[hcalendar|hCalendar]]、[[hrecipe|hRecipe]]にてURLのタグ付けについて考えられているので、そちらを参照してください。

タグを用いるシステムにおいては、タグの表現に特化したrel-tagは優れたフォーマットと言えるでしょう。

== XMDPプロファイル ==
[[rel-tag-profile]] を参照してください。

== タグスペースとタグの扱い ==
タグはURIの中に分かりやすい形で埋め込まれています、そのためURIからタグを機械的に抽出することが比較的容易です。具体的に説明すると、タグはURIパスの最後にある単語（一番後ろの"/"より後の文字列）となります。たとえば<source lang=html4strict>http://www.example.com/tags/foo</source>というURIが示すタグは「foo」となります。

このため、ある二つのURIをタグとみなし比較する場合は、まず始めにタグをパスの最後から抽出することが推奨（SHOULD）されます。

''タグの抽出・比較についてはもう少し標準的な仕組みが必要だと考えています。''

rel="tag"を埋め込んだハイパーリンクが示す先はタグスペース（同じタグの付いた文書の一覧またはタグの定義）であるよう求められています。たとえば、リンク先の文書が次のURLで表されるとします。

<source lang=html4strict>http://technorati.com/tag/tech </source>

この場合、この文書は「tech」というタグに関するタグスペースであるとみなされます。

タグとなる文字列はURLパスの最後にのみ記すことを許されています。これはクエリパラメータやフラグメント識別子がタグとして認識されないことを意味します。さて、次のURLはどう扱われるでしょうか。

<source lang=html4strict>http://technorati.com/tag/tech?tag=fish#emu </nowiki></source>

この場合も先述のとおり「tech」というタグに関するもので、「fish」や「emu」についてのものではないことに注意してください。

タグスペースに関する決まり事は「タグとなる文字列がURLパスの最後にあること」のみです。このためタグスペースはどのドメインにおいても提供可能となっています。ページ作者はいくつかのタグスペースを選びリンクすることで、特定の意味をタグに持たせることが可能です。たとえばWikipediaのページをタグスペースに用いる事ができます。

<source lang=html4strict> http://en.wikipedia.org/wiki/Technology </source>

この場合、タグは「Technology」を指します。

URLの末にあるスラッシュは無視されます。つまり次のURL

<source lang=html4strict> http://technorati.com/tag/Technology/ </source>
これをrel-tagに用いる場合、最後のスラッシュは取り除かれ、
<source lang=html4strict> http://technorati.com/tag/Technology </source>
と同じ扱いを受けることになります。

== タグのエンコード ==
タグにおけるスペースは「<code>+</code>」又は「<code>%20</code>」へとエンコードして含めることが可能です。Unicode文字は[http://www.ietf.org/rfc/rfc3986.txt <nowiki>RFC 3986</nowiki>]で述べられている様にエンコードされます。たとえば次のようになります。

<source lang=html4strict><a href="http://technorati.com/tag/Sant%C3%A9+et+bien-%C3%AAtre" rel="tag">Santé et bien-être</a> </source>

Wikipediaをタグスペースとして利用する場合には「<code>%20</code>」を利用すべきです。Wikipediaは「+」を「<code>%2B</code>」へと置換してしまうため、通常ページのタイトルに存在しない「+」を表示させてしまうからです。

== 目にみえるメタデータとしてのタグ ==
<code>rel="tag"</code>を含んだハイパーリンクは、Webページ上に現れるよう期待されています。これはページ上に現れず、閲覧者の目に届く事がほとんどないmetaキーワードとrel-tagの大きな違いです。タグがWebページに表示されるため、metaキーワードよりも弾力的にキーワードspamなどの問題に対処することができると考えています。

タグのリンクが目に見えることにより、ページ閲覧者はそのリンクが悪用されたものかを簡単に知ることができます。このためリンクを用いた不正行為をある程度抑止できると考えています。どんな目に見えないメタデータが生成されているのかを知らないページ作成者にも効果的でしょう。

このため、<code><link rel="tag" href="..." /></code> のような目に見えないタグリンクの表現は実装されるべきではありません（SHOULD NOT）。

== rel-tagの利用例 ==
このセクションは'''参考情報'''です。

以下はrel-tagを実装したWebサイトのリストです。rel-tagをパースしている、又はタグのインデックスを作っていたり、タグの整理が行われているWebサイトの例をお探しなら、きっとこのリストが役立つでしょう。もしあなたがrel-tagを利用していたら、気軽に'''このリストの上'''に追加してください。リストが大きくなったら、[[rel-tag-examples-in-wild]] といった別のページにて紹介する予定です。 

* [http://trustafriend.com Trust a Friend] uses rel-tag for reviewed businesses in a city. For example: [http://trustafriend.com/reviews/le-gigot-cornelia-st-new-york-ny/ Le Gigot] has the tags: [http://trustafriend.com/us/newyork/french French] and [http://trustafriend.com/us/newyork/restaurant Restaurant].
* [http://en.newsgrail.com/ Newsgrail] uses rel-tag for an implementation of structured sematic tagging by [http://opencalais.com/ OpenCalais].
* [http://davidswain.co.uk Actor David Swain] uses rel-tag on all "tag" links on his site each pointing to its own tag-space.
* [http://beeets.com beeets] is a tag-based event search engine that uses rel-tag on all "tag" links, each pointing to its own tag-space.
* [http://www.beginrunning.com/ Begin Running] uses rel-tag on pages containing tagged content.
* [http://www.sunfactory.fr/en/ Sun Factory] uses rel-tag on some of its product pages. For example : [http://www.sunfactory.fr/en/personalized-gifts/statuette-trophy-soccer-player-football.html Trophy Soccer Player].
* [http://laibcoms.asia/blog/ Snow World] uses rel-tag on all "tag" links. As is built in [http://b2evolution.net b2evolution].
* [http://gameshogun.ws/ gameshogun™] uses rel-tag on all "tag" links. A [http://b2evolution.net b2evolution] implementation.
* [http://clothesonline.info ClothesOnline] uses rel-tag for categorizing shops and brands, for example: [http://clothesonline.info/brands/canada-goose Canada Goose].
* [http://huffduffer.com/ Huffduffer] uses rel-tag on every page, pointing to its own tag space e.g. http://huffduffer.com/tags/microformats
* [http://www.pantrymothtrap.com/ Pantry Moth Traps] implements the rel-tag in articles where an authoritative source is known. (for example in the article [http://www.pantrymothtrap.com/MothTrapsPick.html Moth Trap Picks] the tag [http://www.cleanertoday.com/tag/moth%20trap Moth Trap])
* [http://www.hightechcville.com/ HighTechCville] uses rel-tag on all the pages listing tagged content for [http://www.hightechcville.com/people people], [http://www.hightechcville.com/organizations organizations] and [http://www.hightechcville.com/events events] related to high tech in Charlottesville, VA.
* [http://skateboardspot.info skateboardspot.info] uses rel-tag in spotguide entries which are added to the site and categorized by the users (for example: [http://skateboardspot.info/cat/spotguide/action/view/id/1 “El Toro High School” spotguide entry]).
* [http://www.idoneos.com Idoneos.com] uses rel-tag for conceptual links to its own tag space, a collection of 'concepts' (mostly spanish).
* [http://www.professionalontheweb.com Professional On The Web] uses rel-tag for user entered tags which categorize web professionals and freelancers.
* [https://www.coderesort.com/p/epicode/wiki/CloudCuckoo CloudCuckoo] (secure site but open to all) an [http://www.episerver.com EPiServer] module distributed free by [http://www.interakting.co.uk Interakting], generates tag clouds with rel-tag links.
* [http://www.lifetime.com Lifetime.com] uses rel- and rev-tags in all content pages.
* [http://www.my-warehouse.de the my-Warehouse shopsystem] implements rel-tags in box headings and categories links.
* Joseph Bergantine uses tags to categorize [http://bergantinedesign.us/wallpaper/ wallpapers] and [http://bergantinedesign.us/blog/my-name-is-rachel-corrie blog posts]
* [http://www.codesignville.com Codesignville] uses rel-tag to indicate content categories.
* [http://www.bossalive.com BossaLive] uses rel-tag for tagging music. Publishes rel-tags for album, artist and genre.
** Also uses [[hcard|hCard]] on user profile pages.
* [http://www.qmpeople.com/ qmpeople] Uses rel-tag for translated tags into english, french and italian to meet new friends in different countries.
* [http://www.keevu.com Keevu.com] uses rel-tag to indicate content categories on most pages, like [http://www.keevu.com/venues venues]
* [http://www.amazingincredible.com Amazing Incredible] uses rel-tag on content pages
* [http://www.auctionlink.com.au AuctionLink]では[http://www.auctionlink.com.au/TagList/Auctioneers/ Auction Sales Listings]のタグにrel-tagを用いています。
** Could also use [[hcard|hCard]], e.g. on [http://www.auctionlink.com.au/Auctioneers/Auctioneer/Bonhams_Goodman_1/] [[User:AndyMabbett|Andy Mabbett]]
* Christian Hessは[http://www.hess-cr.com blog]と他のページでrel-tagを用いています。
* [http://spacedust.atspace.com/ Spacedust]はギャラリーページのマークアップにrel-tagを利用しています。
* [http://my.opera.com/dstorey/blog/ My Opera]では、全てのユーザのblogエントリがrel-tagを利用しています。
* [http://dev.opera.com/articles/view/making-wii-friendly-pages/ Dev Opera]では、記事のタグにrel-tagが使われています。
* [http://www.international.unt.edu UNT International]はほとんどのページにおいて、カテゴリをrel-tagで表現しています。
* [http://yedda.com Yedda] - Yeddaは利用者が自分につけたタグ、そしてYeddaにて質問された事柄につけられたタグにrel-tagを利用しています。
* [http://www.lingr.com Lingr]はユーザが入力したすべてのタグを表示しています。
* [http://odeo.com ODEO]では[http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html rel-tagを利用しています]。
* [http://eventful.com Eventful]ではユーザがつけたタグの表現に、rel-tagが使われています。
* [http://spinn3r.com Spinn3r] implements rel-tag as well as RSS and Atom subject and categories.
* [http://www.weboffate.com Web of Fate] publishes rel-tags for future predictions.

== 実装 ==
このセクションは'''参考情報'''です。

次に紹介されているリストは、rel-tagを実装しているアプリケーションのものです。もしあなたがrel-tagを利用したサービスやソフトウェアを開発していたら、気軽に'''このリストの上'''に追加してください。リストが大きくなったら、[[rel-tag-implementations]] といった別のページにて紹介する予定です。

* [http://b2evolution.net b2evolution] A blog platform which generates rel-tag for all tags on blog posts (starting from v3.x).
* [http://www.textcube.org Textcube.org] makes a blogging tool, Textcube which generates rel-tag for tags on blog posts.
* [http://hashtags.org/ HashTags] tags Twitter posts, converting "#example" into a tag of "example"
* [http://ikiwiki.info ikiwiki] generates rel-tag for all tagged pages (as of version 2.6)
* [http://www.hubtag.com HubTag] helps users find a unique tag across the web for their event - eg. JohnAndBettysWeddingWimbledonMarch07
* [http://www.necctar.com Necctar] is a search engine exclusively based on tag microformat parsing and processing. Necctar uses tags entered by bloggers to index the world wide web
* Nutchは[[rel-tag]]のパーサを[http://www.mail-archive.com/nutch-commits@lucene.apache.org/msg01014.html svnレポジトリにコミットしました]。
* [http://webstandards.org/ Web Standards Project]が提供している[http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver拡張スイート]を導入することにより、Dreamweaver 8でrel-tagを用いたタギングができます。
* スライドショー作成サービス[http://scooch.gr0w.com/ Scooch]では、作成者がスライドショーに埋め込んだタグのタグクラウドを見ることができます。
* Weblogシステム[http://www.s9y.org Serendipity]のFreetagプラグインは、エントリのタグ付けを可能とします。（FreetagプラグインはSPARTACUSのなかにあります。）
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf]は[http://textpattern.com/ Textpattern]でrel-tagや他のmicroformatsをテンプレートやエントリで利用可能とするプラグインです。[http://placenamehere.com/ Chris Casciano]により制作されました。
* [http://www.rainskit.com/blog/493/trutags-a-tagging-plugin-for-textpattern tru_tags]は[http://textpattern.com/ Textpattern]で、キーワード欄からエントリのタグ付けを可能とするプラグインです。
* [http://clothesonline.info ClothesOnline] uses rel-tag for categorizing shops and brands, for example: [http://clothesonline.info/brands/canada-goose Canada Goose].
* [http://news.livejournal.com/86492.html?thread=24881884 LiveJournal]には[http://www.livejournal.com/support/faq.bml?cat=tags タグに関するサポートページ]が用意されています。
* [http://trac.labnotes.org/cgi-bin/trac.cgi/wiki/TagsLinks TagsLinks]を用いて、ページに埋め込まれたタグと、他のサービスが用意したタグスペースをつなげることができます。
* [http://www.octofinder.com OctoFinder] uses rel-tag for all live news tag clouds.
* [http://dev.wp-plugins.org/wiki/BunnysTechnoratiTags WordPress用のタグ付けプラグイン]です。
** Note that some sites using WordPress (http://microformatique.com/ for instance) are getting incorrect tags. The tag is ?cat=12 instead of the actual tag value.
* [http://noone.org/blog/tags/Tagging Blosxom用のタグ付けプラグイン]です。
* Technoratiはrel-tagを実装した最初のサービスです。[http://technorati.com/tag/ Technorati Tags]から、Technoratiがインデックスしているタグを見ることが出来ます。
* [http://consumingexperience.blogspot.com/2005/12/updated-multiple-word-technorati-tag.html Bloggerでタグを利用するためのGreasemonkeyスクリプト]です。
* [http://tools.microformatic.com/help/xhtml/rel-lint/ rel-lint]は[[User:DrewMcLellan|Drew McLellan]]による、rel-tagを検証するツールです。

== 参照 ==
=== 標準仕様 ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML 1]
* [http://gmpg.org/xmdp/ XMDP]
* RFC 3986ではURIの構文を規定しています。Section 3.3にURLパスとパスセグメントに関する記述があります。

=== 参考 ===
* [[hreview|hReview]]ではrel-tagを一般的なタグ、またレート付けに用いています。
* [[xfolk|xFolk]]はrel-tagを用いて、タグ付けされたリソースの分散型処理を可能としています。
* [http://developers.technorati.com/wiki/attentionxml Attention.XML]はrel-tagを用い、読者がページやweblogの投稿、又はフィードへのタグ付けを行えるようにしています。
* [[hcard|hCard]]では、rel-tagを用いたカテゴリの作成が可能です。
* [[hcalendar|hCalendar]]でも、rel-tagを用いたカテゴリの作成が可能です。
* [http://technorati.com/help/tags.html Using Technorati Tags]で、Technoratiにおけるタグの扱いを知ることが出来ます。
* rel-tagは http://developers.technorati.com/wiki/RelTag からの寄稿により作成されました。
* microformatique.comの[http://microformatique.com/?p=61 Know your rel-tag]に、rel-tagについての説明があります。

== ディスカッション ==
* フィードバックは[[rel-tag-feedback]]にてお願いします。
* [http://www.technorati.com/cosmos/referer.html rel-tagについて言及しているページ]も参照してください。
* これまでの経緯については[http://www.powazek.com/ Derek Powazek]による[http://www.powazek.com/2005/07/000532.html How Tags Happened at Technorati]をお読み下さい。

=== Q&A ===
* rel-tagに関して分からないことがありますか？それがrel属性に関する疑問ならば[[rel-faq|rel FAQ]]を、rel-tagに関する疑問であれば[[rel-tag-faq|rel-tag FAQ]]をお読み下さい。これらのページを読んでも疑問が解消されない場合は、[http://microformats.org/discuss microformats-discuss]にメールを投稿するとよいでしょう。

==Related pages==
{{rel-tag-related-pages}}

[[Category:Specifications]]
[[Category:rel-tag]]

rel-tag-ja

2011-08-25T16:35:11Z

KitaitiMakoto: sync: english: 2011-08-20T01:37:01

<entry-title>rel="tag"</entry-title>

__TOC__

== 仕様ドラフト 2005-01-10 ==
; 編者/作者
:[http://tantek.com/ Tantek Çelik]
:[http://epeus.blogspot.com/ Kevin Marks]

; 原案
:[http://powazek.com/ Derek Powazek]

; 短縮URL
:http://tr.im/reltag

=== 著作権 ===
{{MicroFormatCopyrightStatement2004-ja}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
* [[User:Kevin Marks|Kevin Marks]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

=== 特許 ===
{{MicroFormatPatentStatement-ja}}

== 概要 ==
[[rel-tag-ja|rel-tag]]は[[microformats-ja|microformats]]のひとつです。ハイパーリンクに<code>rel="tag"</code>を書き加える事により、リンク元のページに対しページ作者が定義した「タグ（キーワードやテーマ）」を関連づけることができます。
タグはblogの記事内容すべてに関係する言葉とは限りません。たとえば次のようなリンクでタグを関連づけるとします。

<source lang=html4strict><a href="http://technorati.com/tag/tech" rel="tag">tech</a></source>

これは作者がこのWebページ（または内容の一部）に「tech」というタグをつけていることを意味します。

リンク先のページはWeb上に存在するべき（SHOULD）であり、またタグの意味はリンクテキストの内容よりも、リンク先のページが持つ情報が優先されます。たとえば次のようなマークアップでページに対しタグ付けを行ったとします。

<source lang=html4strict><a href="http://technorati.com/tag/tech" rel="tag">fish</a></source>

URLの最後にある単語がタグの意味として扱われるので、この場合ページのタグは「fish」ではなく「tech」となります。

== rel-tagの意図、範囲 ==
rel-tagはWebページ（又はその一部）に「タグ付け」をする目的で作られました。このため、任意のURLやページ外部のコンテンツに対し、rel-tagによりタグ付けを行える様にはできていません。現在のページから外部のURLへのタグ付けの一般的な構文についての要望はありますが、rel-tagにおいてその議論はなされるべきでないと考えています。[[xfolk|xFolk]]や[[hreview|hReview]]、[[hcard |hCard]]、[[hcalendar|hCalendar]]、[[hrecipe|hRecipe]]にてURLのタグ付けについて考えられているので、そちらを参照してください。

タグを用いるシステムにおいては、タグの表現に特化したrel-tagは優れたフォーマットと言えるでしょう。

== XMDPプロファイル ==
[[rel-tag-profile]] を参照してください。

== タグスペースとタグの扱い ==
タグはURIの中に分かりやすい形で埋め込まれています、そのためURIからタグを機械的に抽出することが比較的容易です。具体的に説明すると、タグはURIパスの最後にある単語（一番後ろの"/"より後の文字列）となります。たとえば<source lang=html4strict>http://www.example.com/tags/foo</source>というURIが示すタグは「foo」となります。

このため、ある二つのURIをタグとみなし比較する場合は、まず始めにタグをパスの最後から抽出することが推奨（SHOULD）されます。

''タグの抽出・比較についてはもう少し標準的な仕組みが必要だと考えています。''

rel="tag"を埋め込んだハイパーリンクが示す先はタグスペース（同じタグの付いた文書の一覧またはタグの定義）であるよう求められています。たとえば、リンク先の文書が次のURLで表されるとします。

<source lang=html4strict>http://technorati.com/tag/tech </source>

この場合、この文書は「tech」というタグに関するタグスペースであるとみなされます。

タグとなる文字列はURLパスの最後にのみ記すことを許されています。これはクエリパラメータやフラグメント識別子がタグとして認識されないことを意味します。さて、次のURLはどう扱われるでしょうか。

<source lang=html4strict>http://technorati.com/tag/tech?tag=fish#emu </nowiki></source>

この場合も先述のとおり「tech」というタグに関するもので、「fish」や「emu」についてのものではないことに注意してください。

タグスペースに関する決まり事は「タグとなる文字列がURLパスの最後にあること」のみです。このためタグスペースはどのドメインにおいても提供可能となっています。ページ作者はいくつかのタグスペースを選びリンクすることで、特定の意味をタグに持たせることが可能です。たとえばWikipediaのページをタグスペースに用いる事ができます。

<source lang=html4strict> http://en.wikipedia.org/wiki/Technology </source>

この場合、タグは「Technology」を指します。

URLの末にあるスラッシュは無視されます。つまり次のURL

<source lang=html4strict> http://technorati.com/tag/Technology/ </source>
これをrel-tagに用いる場合、最後のスラッシュは取り除かれ、
<source lang=html4strict> http://technorati.com/tag/Technology </source>
と同じ扱いを受けることになります。

== タグのエンコード ==
タグにおけるスペースは「<code>+</code>」又は「<code>%20</code>」へとエンコードして含めることが可能です。Unicode文字は[http://www.ietf.org/rfc/rfc3986.txt <nowiki>RFC 3986</nowiki>]で述べられている様にエンコードされます。たとえば次のようになります。

<source lang=html4strict><a href="http://technorati.com/tag/Sant%C3%A9+et+bien-%C3%AAtre" rel="tag">Santé et bien-être</a> </source>

Wikipediaをタグスペースとして利用する場合には「<code>%20</code>」を利用すべきです。Wikipediaは「+」を「<code>%2B</code>」へと置換してしまうため、通常ページのタイトルに存在しない「+」を表示させてしまうからです。

== 目にみえるメタデータとしてのタグ ==
<code>rel="tag"</code>を含んだハイパーリンクは、Webページ上に現れるよう期待されています。これはページ上に現れず、閲覧者の目に届く事がほとんどないmetaキーワードとrel-tagの大きな違いです。タグがWebページに表示されるため、metaキーワードよりも弾力的にキーワードspamなどの問題に対処することができると考えています。

タグのリンクが目に見えることにより、ページ閲覧者はそのリンクが悪用されたものかを簡単に知ることができます。このためリンクを用いた不正行為をある程度抑止できると考えています。どんな目に見えないメタデータが生成されているのかを知らないページ作成者にも効果的でしょう。

このため、<code><link rel="tag" href="..." /></code> のような目に見えないタグリンクの表現は実装されるべきではありません（SHOULD NOT）。

== rel-tagの利用例 ==
このセクションは'''参考情報'''です。

以下はrel-tagを実装したWebサイトのリストです。rel-tagをパースしている、又はタグのインデックスを作っていたり、タグの整理が行われているWebサイトの例をお探しなら、きっとこのリストが役立つでしょう。もしあなたがrel-tagを利用していたら、気軽に'''このリストの上'''に追加してください。リストが大きくなったら、[[rel-tag-examples-in-wild]] といった別のページにて紹介する予定です。 

* [http://en.newsgrail.com/ Newsgrail] uses rel-tag for an implementation of structured sematic tagging by [http://opencalais.com/ OpenCalais].
* [http://davidswain.co.uk Actor David Swain] uses rel-tag on all "tag" links on his site each pointing to its own tag-space.
* [http://beeets.com beeets] is a tag-based event search engine that uses rel-tag on all "tag" links, each pointing to its own tag-space.
* [http://www.beginrunning.com/ Begin Running] uses rel-tag on pages containing tagged content.
* [http://www.sunfactory.fr/en/ Sun Factory] uses rel-tag on some of its product pages. For example : [http://www.sunfactory.fr/en/personalized-gifts/statuette-trophy-soccer-player-football.html Trophy Soccer Player].
* [http://laibcoms.asia/blog/ Snow World] uses rel-tag on all "tag" links. As is built in [http://b2evolution.net b2evolution].
* [http://gameshogun.ws/ gameshogun™] uses rel-tag on all "tag" links. A [http://b2evolution.net b2evolution] implementation.
* [http://clothesonline.info ClothesOnline] uses rel-tag for categorizing shops and brands, for example: [http://clothesonline.info/brands/canada-goose Canada Goose].
* [http://huffduffer.com/ Huffduffer] uses rel-tag on every page, pointing to its own tag space e.g. http://huffduffer.com/tags/microformats
* [http://www.pantrymothtrap.com/ Pantry Moth Traps] implements the rel-tag in articles where an authoritative source is known. (for example in the article [http://www.pantrymothtrap.com/MothTrapsPick.html Moth Trap Picks] the tag [http://www.cleanertoday.com/tag/moth%20trap Moth Trap])
* [http://www.hightechcville.com/ HighTechCville] uses rel-tag on all the pages listing tagged content for [http://www.hightechcville.com/people people], [http://www.hightechcville.com/organizations organizations] and [http://www.hightechcville.com/events events] related to high tech in Charlottesville, VA.
* [http://skateboardspot.info skateboardspot.info] uses rel-tag in spotguide entries which are added to the site and categorized by the users (for example: [http://skateboardspot.info/cat/spotguide/action/view/id/1 “El Toro High School” spotguide entry]).
* [http://www.idoneos.com Idoneos.com] uses rel-tag for conceptual links to its own tag space, a collection of 'concepts' (mostly spanish).
* [http://www.professionalontheweb.com Professional On The Web] uses rel-tag for user entered tags which categorize web professionals and freelancers.
* [https://www.coderesort.com/p/epicode/wiki/CloudCuckoo CloudCuckoo] (secure site but open to all) an [http://www.episerver.com EPiServer] module distributed free by [http://www.interakting.co.uk Interakting], generates tag clouds with rel-tag links.
* [http://www.lifetime.com Lifetime.com] uses rel- and rev-tags in all content pages.
* [http://www.my-warehouse.de the my-Warehouse shopsystem] implements rel-tags in box headings and categories links.
* Joseph Bergantine uses tags to categorize [http://bergantinedesign.us/wallpaper/ wallpapers] and [http://bergantinedesign.us/blog/my-name-is-rachel-corrie blog posts]
* [http://www.codesignville.com Codesignville] uses rel-tag to indicate content categories.
* [http://www.bossalive.com BossaLive] uses rel-tag for tagging music. Publishes rel-tags for album, artist and genre.
** Also uses [[hcard|hCard]] on user profile pages.
* [http://www.qmpeople.com/ qmpeople] Uses rel-tag for translated tags into english, french and italian to meet new friends in different countries.
* [http://www.keevu.com Keevu.com] uses rel-tag to indicate content categories on most pages, like [http://www.keevu.com/venues venues]
* [http://www.amazingincredible.com Amazing Incredible] uses rel-tag on content pages
* [http://www.auctionlink.com.au AuctionLink]では[http://www.auctionlink.com.au/TagList/Auctioneers/ Auction Sales Listings]のタグにrel-tagを用いています。
** Could also use [[hcard|hCard]], e.g. on [http://www.auctionlink.com.au/Auctioneers/Auctioneer/Bonhams_Goodman_1/] [[User:AndyMabbett|Andy Mabbett]]
* Christian Hessは[http://www.hess-cr.com blog]と他のページでrel-tagを用いています。
* [http://spacedust.atspace.com/ Spacedust]はギャラリーページのマークアップにrel-tagを利用しています。
* [http://my.opera.com/dstorey/blog/ My Opera]では、全てのユーザのblogエントリがrel-tagを利用しています。
* [http://dev.opera.com/articles/view/making-wii-friendly-pages/ Dev Opera]では、記事のタグにrel-tagが使われています。
* [http://www.international.unt.edu UNT International]はほとんどのページにおいて、カテゴリをrel-tagで表現しています。
* [http://yedda.com Yedda] - Yeddaは利用者が自分につけたタグ、そしてYeddaにて質問された事柄につけられたタグにrel-tagを利用しています。
* [http://www.lingr.com Lingr]はユーザが入力したすべてのタグを表示しています。
* [http://odeo.com ODEO]では[http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html rel-tagを利用しています]。
* [http://eventful.com Eventful]ではユーザがつけたタグの表現に、rel-tagが使われています。
* [http://spinn3r.com Spinn3r] implements rel-tag as well as RSS and Atom subject and categories.
* [http://www.weboffate.com Web of Fate] publishes rel-tags for future predictions.

== 実装 ==
このセクションは'''参考情報'''です。

次に紹介されているリストは、rel-tagを実装しているアプリケーションのものです。もしあなたがrel-tagを利用したサービスやソフトウェアを開発していたら、気軽に'''このリストの上'''に追加してください。リストが大きくなったら、[[rel-tag-implementations]] といった別のページにて紹介する予定です。

* [http://b2evolution.net b2evolution] A blog platform which generates rel-tag for all tags on blog posts (starting from v3.x).
* [http://www.textcube.org Textcube.org] makes a blogging tool, Textcube which generates rel-tag for tags on blog posts.
* [http://hashtags.org/ HashTags] tags Twitter posts, converting "#example" into a tag of "example"
* [http://ikiwiki.info ikiwiki] generates rel-tag for all tagged pages (as of version 2.6)
* [http://www.hubtag.com HubTag] helps users find a unique tag across the web for their event - eg. JohnAndBettysWeddingWimbledonMarch07
* [http://www.necctar.com Necctar] is a search engine exclusively based on tag microformat parsing and processing. Necctar uses tags entered by bloggers to index the world wide web
* Nutchは[[rel-tag]]のパーサを[http://www.mail-archive.com/nutch-commits@lucene.apache.org/msg01014.html svnレポジトリにコミットしました]。
* [http://webstandards.org/ Web Standards Project]が提供している[http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver拡張スイート]を導入することにより、Dreamweaver 8でrel-tagを用いたタギングができます。
* スライドショー作成サービス[http://scooch.gr0w.com/ Scooch]では、作成者がスライドショーに埋め込んだタグのタグクラウドを見ることができます。
* Weblogシステム[http://www.s9y.org Serendipity]のFreetagプラグインは、エントリのタグ付けを可能とします。（FreetagプラグインはSPARTACUSのなかにあります。）
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf]は[http://textpattern.com/ Textpattern]でrel-tagや他のmicroformatsをテンプレートやエントリで利用可能とするプラグインです。[http://placenamehere.com/ Chris Casciano]により制作されました。
* [http://www.rainskit.com/blog/493/trutags-a-tagging-plugin-for-textpattern tru_tags]は[http://textpattern.com/ Textpattern]で、キーワード欄からエントリのタグ付けを可能とするプラグインです。
* [http://clothesonline.info ClothesOnline] uses rel-tag for categorizing shops and brands, for example: [http://clothesonline.info/brands/canada-goose Canada Goose].
* [http://news.livejournal.com/86492.html?thread=24881884 LiveJournal]には[http://www.livejournal.com/support/faq.bml?cat=tags タグに関するサポートページ]が用意されています。
* [http://trac.labnotes.org/cgi-bin/trac.cgi/wiki/TagsLinks TagsLinks]を用いて、ページに埋め込まれたタグと、他のサービスが用意したタグスペースをつなげることができます。
* [http://www.octofinder.com OctoFinder] uses rel-tag for all live news tag clouds.
* [http://dev.wp-plugins.org/wiki/BunnysTechnoratiTags WordPress用のタグ付けプラグイン]です。
** Note that some sites using WordPress (http://microformatique.com/ for instance) are getting incorrect tags. The tag is ?cat=12 instead of the actual tag value.
* [http://noone.org/blog/tags/Tagging Blosxom用のタグ付けプラグイン]です。
* Technoratiはrel-tagを実装した最初のサービスです。[http://technorati.com/tag/ Technorati Tags]から、Technoratiがインデックスしているタグを見ることが出来ます。
* [http://consumingexperience.blogspot.com/2005/12/updated-multiple-word-technorati-tag.html Bloggerでタグを利用するためのGreasemonkeyスクリプト]です。
* [http://tools.microformatic.com/help/xhtml/rel-lint/ rel-lint]は[[User:DrewMcLellan|Drew McLellan]]による、rel-tagを検証するツールです。

== 参照 ==
=== 標準仕様 ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML 1]
* [http://gmpg.org/xmdp/ XMDP]
* RFC 3986ではURIの構文を規定しています。Section 3.3にURLパスとパスセグメントに関する記述があります。

=== 参考 ===
* [[hreview|hReview]]ではrel-tagを一般的なタグ、またレート付けに用いています。
* [[xfolk|xFolk]]はrel-tagを用いて、タグ付けされたリソースの分散型処理を可能としています。
* [http://developers.technorati.com/wiki/attentionxml Attention.XML]はrel-tagを用い、読者がページやweblogの投稿、又はフィードへのタグ付けを行えるようにしています。
* [[hcard|hCard]]では、rel-tagを用いたカテゴリの作成が可能です。
* [[hcalendar|hCalendar]]でも、rel-tagを用いたカテゴリの作成が可能です。
* [http://technorati.com/help/tags.html Using Technorati Tags]で、Technoratiにおけるタグの扱いを知ることが出来ます。
* rel-tagは http://developers.technorati.com/wiki/RelTag からの寄稿により作成されました。
* microformatique.comの[http://microformatique.com/?p=61 Know your rel-tag]に、rel-tagについての説明があります。

== ディスカッション ==
* フィードバックは[[rel-tag-feedback]]にてお願いします。
* [http://www.technorati.com/cosmos/referer.html rel-tagについて言及しているページ]も参照してください。
* これまでの経緯については[http://www.powazek.com/ Derek Powazek]による[http://www.powazek.com/2005/07/000532.html How Tags Happened at Technorati]をお読み下さい。

=== Q&A ===
* rel-tagに関して分からないことがありますか？それがrel属性に関する疑問ならば[[rel-faq|rel FAQ]]を、rel-tagに関する疑問であれば[[rel-tag-faq|rel-tag FAQ]]をお読み下さい。これらのページを読んでも疑問が解消されない場合は、[http://microformats.org/discuss microformats-discuss]にメールを投稿するとよいでしょう。

==Related pages==
{{rel-tag-related-pages}}

[[Category:Specifications]]
[[Category:rel-tag]]

value-class-pattern-ja

2011-08-25T16:32:30Z

KitaitiMakoto: sync: english: 2011-08-18T11:20:33

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://ufs.cc/w/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://ufs.cc/w/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
[[hAtom]] を読み込んで Atom を生成するマイクロフォーマット実装は更に以下に従わなければなりません（{{must}}）。
* 日付と日時の値を全て [[RFC3339]] のフォーマットに正規化する

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Is the value-class pattern supported by any of the microformats tools?'''
** '''A: Yes'''. See the [[value-class-pattern#Implementations|implementations]] section.
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** '''A: 'class' is for field names, not data.''' The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** '''A: New attributes are invalid.''' Microformats exist and function in ''valid'' HTML. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''Shouldn't the <code>title</code> attribute should only be used for content?'''
** '''A: 'title' is used for content, machine readable content.''' The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

=== 購読とパース用ツール ===
* [[Google]] parses <code>value-title</code> as part of their [http://googlewebmastercentral.blogspot.com/2010/01/introducing-new-rich-snippets-format.html support for hCalendar rich snippets], as documented specifically in the [https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164506 microformats example for rich snippet events].
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* HTML::Microformats and its predecessors support <code>value</code> excerpting. HTML::Microformats (though not its predecessors) supports <code>value-title</code>.
=== 公開用ツール ===
* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
== 記事 ==
This section is '''informative'''.

Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/articles/getting-semantic-with-microformats-part-8-value-class-pattern Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 参照 ==
This section is '''informative'''.
* [http://www.useit.com/alertbox/9608.html Jakob Nielsen: International Web Usability]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

== 翻訳 ==
Read the value-class-pattern specification in additional languages:
* [[value-class-pattern|english]]
* [[value-class-pattern-fr|français]]

hresume-ja

2011-08-01T16:29:57Z

KitaitiMakoto: sync: english: 2011-07-31T04:12:11

<entry-title>hResume</entry-title>
{{DraftSpecification-ja}}
__TOC__
hResumeは、経歴(resume)や履歴書(CV)を公開するためのmicroformatです。hResume is one of several open microformat standards suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML.

Want to get started with writing an hResume? Use the [http://recherche.telecom-bretagne.eu/labo_communicant/dev_labc/hResumeCreator.php hResume Creator] to create your hResume and publish it, or follow the hResume authoring tips to add hResume markup to your web page or blog.

==Microformats Draft Specification==

; Editor/Author: [http://theryanking.com Ryan King]
; Acknowledgments: See [http://microformats.org/wiki/hresume#Acknowledgements acknowledgments].

Microformats [http://microformats.org/wiki/hresume#Copyright copyright] and [http://microformats.org/wiki/hresume#Patents patents] statements apply.

== Status ==
Draft, version 0.1.

== Introduction ==
=== Semantic XHTML Design Principles ===
{{semantic-xhtml-design-principles-ja}}

== Format ==
=== In General ===
The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.

=== Schema ===
The hResume schema consists of the following:

* hResume
** summary. optional. text.
** contact info. required. '''Must''' use [[hcard|hCard]]. '''Should''' use <code class="element"><address></code> + [[hcard|hCard]].
** experience. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** education. optional One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization
** publications. optional. One or more citations. Use cite tag.

=== Field details ===
The fields of the hResume schema represent the following:

* '''<code class="class-name">hresume</code>''':: root class name
* '''<code class="class-name">summary</code>''':: The class name <code class="class-name">summary</code> is used to mark up an overview of qualifications and objectives.
* '''contact''':: Current contact info in an [[hCard]]. '''Should''' use <code class="element"><address></code> with [[hCard]] when possible.
* '''<code class="class-name">education</code>''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.
* '''<code class="class-name">experience</code>''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''<code class="class-name">skill</code>''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.
* '''<code class="class-name">affiliation</code>''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization
* '''<code class="class-name">publications</code>''':: just use <code class="element"><cite></code>. When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.

=== XMDP Profile ===
* [[hresume-profile]] (@TODO)

=== Notes ===
This section is informative.

*...

== Examples ==
=== Summary ===
An example summary:

<source lang=html4strict>

I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996,
designing with pastels while others will still using tiled background images and frames...

</source>

=== Contact ===
<source lang=html4strict>
<address class="vcard">
Pedro Sanchez

123 Fake St.
Preston, Idaho 83263

Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a>
Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a>
Phone: +01.208.555.4567
</address>
</source>

=== Education ===
<source lang=html4strict>
<ol class="vcalendar">
<li class="education vevent">
<a class="url summary" href="http://example.edu/">Preston High School</a>
(<abbr class="dtstart" title="2001-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
</li>
...
</source>

=== Experience ===
==== Basic ====
A basic experience event:

<source lang=html4strict>
<ol class="vcalendar">
<li class="experience vevent">
President,
Preston High School,
<abbr class="dtstart" title="2004-09-01">May 2004</abbr> - <abbr title="2005-05-25">present</abbr>
</li>
...
</source>

==== Job Titles ====
To express one or more job titles/positions in the same experience event you should use [[hCard]]s. [[hcard]] requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't reasonable to repeat your name for every job title you mark up in [[hResume|hresume]]. So, you may use an <code class="element"><object></code> and the class name '<code class="class-name">include</code>' with a reference to the <code class="class-name">fn</code> somewhere else on the page.

For example, this [[hCard]] refers to another [[hCard]]

<pre>

<object data="#j" class="include"></object>
Preston High School
Class President

</pre>

Where "<code class="attr-value">j</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact [[hCard]] at the top of the page, e.g. (shown here as a verbose [[hCard]] for purposes of illustration that the reference may be to a subtree, not just a text node):

<source lang=html4strict>
<address class="vcard">

Pedro
Sanchez

</address>
</source>

This method of hCard property indirection via an object element [[include-pattern|has been generalized]] to apply to any/all string/text properties in hCard.
Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.

=== Skills ===
Some sample skills tags:
<source lang=html4strict>
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a>
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.
</source>

=== Affiliations ===
<source lang=html4strict>
National Honor Society
</source>

=== Publications ===
<source lang=html4strict>
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
</source>

== Examples in the wild ==
See [[hresume-examples-in-wild]]

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse hResumes. If you have an hResume implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page like [[hresume-implementations]].

* [http://www.cvmatch4jobs.com/ cvmatch4jobs] has implemented hResume import for publicly published CV's. A Career site for 3 UK building and proprety magazines from publishers UBM. 19 Jan 2010.

* [http://careercv.mad.co.uk/ CareerCV] has implemented hResume import for publicly published CV's. A Career site for major UK design magazines from publishers Centaur Communications. 19 Jan 2010.

* [http://lab.madgex.com/hresume/ Madgex] has implemented hResume to Microsoft Word and PDF conversion API. 13 Dec 2009.

* [http://careers.stackoverflow.com/ Stack Overflow] generates hResume for its public CV hosting service for programmers. [http://careers.stackoverflow.com/klmr Stack Overflow CV example] Dec 2009.

* [http://jobs.guardian.co.uk/profile/ Guardian Jobs] has implemented hResume import for publicly published CV's. 4 Sep 2009.

* [http://www.yiid.com/ YIID - Your Internet Identity] supports importing of hResumes (e.g. here is the result of an import: http://pfefferle.yiid.com/cv [requires login] via @pfefferle)

* [[Resume.app]]

* [http://www.xing.com/ Xing] generates hResume for all Public Profiles. [http://www.xing.com/profile/Matthias_Pfefferle Xing Public Profile Example].

* [http://linkedin.com LinkedIn] generates hResume for all Public Profiles. [http://www.linkedin.com/in/steveganz LinkedIn Public Profile Example].

* [http://www.antix.co.uk Anthony Johnston] has implemented hResume (Creation and Import) in the [http://cv.antix.co.uk Antix CV Builder], an example resume using this site can be found [http://cv.antix.co.uk/ant here]
** The example resume is ''invalid''; job titles are marked with an hCard that is missing a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:23, 1 May 2007 (PDT)
*** This is fixed now --[[User:Antix|Ant]] 00:38, 8 Dec 2007 (GMT)

* The [http://spurinc.com Spur] team has created an hResume WordPress plugin located at [http://hresume.weblogswork.com/?page_id=3 hResume Plugin]. See an example of the hResume markup [http://hresume.weblogswork.com/?page_id=6 here]. Neat feature of the hResume plugin is that it automatically creates a new page for the resume - no cutting and pasting...

* Spur also created a standalone hResume Creator located at [http://hresume.weblogswork.com/hresumecreator/ hResume Creator]. The creator will generate hResume markup ready to cut and paste into your webpage.

== Copyright ==
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
* [[RyanKing]]: I release all of my contributions to the public domain.

Per the above, and the public domain release on the author, [[User:RyanKing|RyanKing]]'s, user page this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

== Patents ==
{{MicroFormatPatentStatement-ja}}

== References ==
=== Normative References ===
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[include-pattern|include pattern]]
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag| Rel-Tag]]
* [[rfc-2119]]
* @TODO

=== Informative References ===
@TODO

== Acknowledgements ==
=== Concept ===
* [http://theryanking.com/ Ryan King], [http://technorati.com Technorati]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati]
* James Levine [http://simplyhired.com Simply Hired]
* [http://epeus.blogspot.com/ Kevin Marks], [http://technorati.com Technorati]

== Related Pages ==
{{hresume-related-pages}}

== Further Reading ==
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].
* [http://www.ablognotlimited.com/articles/getting-semantic-with-microformats-part-6-hresume/ Getting Semantic With Microformats, Part 6: hResume] by Emily Lewis

[[Category:hResume]]

hcard-ja

2011-08-01T16:28:01Z

KitaitiMakoto: sync: english: 2011-07-31T07:09:51

<entry-title>hCard 1.0</entry-title>

[[User:Tantek|Tantek Çelik]] (Editor, Author), [[User:Brian|Brian Suda]] (Author)
----
<dfn style="font-style:normal;font-weight:bold">hCard</dfn> は、vCard ([[rfc-2426|RFC2426]]) のプロパティと値を利用して、[[semantic-xhtml|HTML]] で人や会社、組織や場所を表現する [[microformats-ja|microformat]] です。hCard は HTML や XHTML はもちろんのこと、Atom、RSS、その他の XML に埋め込むことができます。

[[hcard-ja#原案及び謝辞|謝辞のセクション]]をご覧ください。
権利に関する情報は、[[hcard#Copyright|著作権]]と[[hcard#Patents|特許]]のセクションをご覧ください。

== 例 ==
hCards are most often used to represent people:
<source lang=html4strict>
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>
and organizations:
<source lang=html4strict>
<div class="vcard">
<a class="url fn org" href="http://microformats.org/">microformats.org</a>
</div>
</source>

The class '''<code>vcard</code>''' is a ''[[hcard#Root_Class_Name|root class name]]'' that indicates the presence of an hCard. The classes '''<code>url</code>''', '''<code>fn</code>''', and '''<code>org</code>''' are ''properties'' that indicate aspects of the hCard. See the [[hcard#Property_List|list of properties]] for more.

'''Want to get started with writing an [[hcard|hCard]]?''' Use the [http://microformats.org/code/hcard/creator hCard creator] to write up some contact information and publish it, or follow the [[hcard-authoring|hCard authoring tips]] to add hCard markup to your current contact page.

== 状態 ==
hCard 1.0 is a microformats.org specification. Public discussion on hCard takes place on [[hcard-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== 利用できる言語 ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== 訂正事項と更新事項 ===
Known errors and issues in this specification are corrected in [[hcard-issues-resolved|resolved]] and [[hcard-issues-closed|closed]] issues. Please check there before reporting [[hcard-issues|issues]].

The hCard 1.0.1 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

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

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

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

== 適合性 ==
{{rfc-2119-intro-ja}}

== フォーマット ==
=== 基本情報 ===
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) のプロパティ名や値が、hCard の基礎となります。

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

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

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

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

'''必須プロパティ'''
* '''fn'''
* '''n'''[[#note1|1]]
** family-name
** given-name
** additional-name
** honorific-prefix
** honorific-suffix

任意プロパティ
* [[adr]]
** post-office-box
** extended-address
** street-address
** locality
** region
** postal-code
** country-name
** type
** value
* agent
* bday
* category
* class
* email (type, value)
* geo
** latitude
** longitude
* key
* label
* logo
* mailer
* nickname
* note
* org (organization-name, organization-unit)
* photo
* rev
* role
* sort-string
* sound
* tel[[#note2|2]] (type, value)
* title
* tz
* uid
* url

=== プロパティについて ===
[[#property-list-n|1. ^]]: 'n' プロパティは、[[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]にあるルールに当てはまる場合は、任意 ({{optional}}) プロパティとなります。 
[[#property-list-tel|2. ^]]: tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することができます ({{may}})。文字の入った電話番号 (例: +1-555-FORMATS) は、数字で表記しなければなりません ({{must}})。<code>abbr</code> を利用して、ソフトウェアには数字から成る電話番号の方を伝えることもできます (<code><nowiki><abbr title="+15553676287">+1-555-FORMATS</abbr></nowiki></code>)。

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

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

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

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

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

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

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

=== 値の抜粋 ===
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合は特別な class 名である "<code>value</code>" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップする hCard を例に取り説明しましょう。 

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>

home:
+1.415.555.1212

</source>

この hCard は次のように表示されるでしょう。

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

home:
+1.415.555.1212

</div>

You may want to customize/localize the visible punctuation and not want to include it in what machines see. Use multiple class="value" elements which are then concatenated. E.g.

<source lang=html4strict>

home:
+1.415.555.1212

</source>

No change in display, but the parsed hCard property value then becomes in vCard:

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+14155551212
</nowiki></pre>


=== プロパティの例外 ===
vCard には、Web ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。

# vCard の '''NAME'''、'''PROFILE'''、'''SOURCE'''、'''PRODID'''、'''VERSION''' プロパティは [[rfc-2426|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 文書の場合、<code><title></code> 要素) を用いることが推奨されます ({{should}})。PROFILE の値には、[[rfc-2426|RFC2426]] より "<code>VCARD</code>" の値を使うことができます ({{may}})。SOURCE プロパティには、ページの URL を用いることが推奨されます ({{should}})。hCard を vCard に変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODID プロパティは、実際に vCard を出力するサービスやアプリケーションのみが記述するべきです ({{should}})。同様に、そのようなアプリケーションのみが、[[rfc-2426|RFC2426]] のセクション 3.6.9 に倣い、VERSION プロパティに "3.0" という値をつけるべきです ({{should}})。

=== 組織のコンタクト情報 ===
もし、"FN" と "ORG"（organization；組織）プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、その hCard は会社や組織、場所のコンタクト情報を表すものとみなされます ({{should}})。このとき、作成者は "N" プロパティを記述することはできない ({{must-not}})、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます ({{should}})。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。

=== "N" の推測処理 ===
vCard では "N" プロパティの記述が必須となっています。ところが vCard 仕様書 ([[rfc-2426|RFC2426]]) では、最後の方 (p.38) にある作者の vCard に "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCard では次のように規定します。

もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります ({{must}})。しかし、組織名の場合はこのルールに当てはまりません。この場合は[[hcard-ja#.E7.B5.84.E7.B9.94.E3.81.AE.E3.82.B3.E3.83.B3.E3.82.BF.E3.82.AF.E3.83.88.E6.83.85.E5.A0.B1|組織のコンタクト情報]]で書かれているルールが適用されます。

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

これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。
* given-name (スペース) family-name
* family-name (コンマ) given-name
* family-name (コンマ) given-name のイニシャル
* family-name (スペース) given-name のイニシャル (任意のピリオド)

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語で名前を記述するときには、この推測処理を利用することはできません。必ず given-name、family-name プロパティを利用し、明示的に名前を記述しなければなりません。

<pre><nowiki>
<div class="vcard">

マイクロ
太郎

</div>
</nowiki></pre>
</div>

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

"nickname" の推測機構は [[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。

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

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

<source lang=html4strict>

daveman692

</source>

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

=== "organization-name" の推測処理 ===
"ORG" プロパティは organization-name と organization-unit という二つのサブプロパティを持っています。しかしほとんどの場合、作成者は organization-name のみを記述します。よって、もし "ORG" プロパティが "organization-name" プロパティを内側に持たない場合、"ORG" プロパティの内容は必ず "organization-name" とみなされます ({{must}})。

=== カテゴリーとしてのタグ ===
hCard のカテゴリーは [[rel-tag]] を用い、タグとして表現することも可能です ({{may}})。"category" プロパティが rel-tag である場合、そのタグはカテゴリーとして扱われます。

=== 'type' サブプロパティの値 ===
'type' サブプロパティがとる値は、その親プロパティによって異なります。これらの 'type' サブプロパティの値は大文字小文字を区別しません (case-INSENSITIVE)。よって "Home" は "home" と同じであり、その他の値と組み合わせた場合についても同様です。たとえば、家の電話番号で、かつ優先番号であるものは次のようになります。

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
Home (preferred):
+1.415.555.1212

</source>

この例は次のように表示されるでしょう。

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
Home (preferred):
+1.415.555.1212

</div>

==== type with unspecified value ====
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.

<source lang=html4strict>
Home +1.415.555.1212
</source>

is equivalent to:

<source lang=html4strict>
Home +1.415.555.1212
</source>

And thus the type is "home" and the value is "+1.415.555.1212".

==== adr tel email types ====
次のリストは ''参考情報'' です。

規範的な type の値は [[rfc-2426|RFC2426]] のセクション 3.2.1 ADR、3.3.1 TEL、3.3.2 EMAIL を参照してください (ここでは利便性の為にコピーしています)。type サブプロパティのデフォルト値はリストの最初に並んでおり、また大文字で記述されています。また、これらの type は複数指定することができます。

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref, "IANA に登録された他のアドレスタイプ"

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語などの言語では、これらサブプロパティの多くを利用することができません。サブタイプはマークアップの制限上、その内容を訳すことができないからです。
</div>

=== プロファイル ===
hCard の XMDP プロファイル は http://microformats.org/profile/hcard にあります。

hCard を使うコンテンツは、
<source lang=html4strict>
<link rel="profile" href="http://microformats.org/profile/hcard">
</source>
や
<source lang=html4strict>
このコンテンツは <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a> を使っています。
</source>
又は
<source lang=html4strict>
<head rel="profile" href="http://microformats.org/profile/hcard">
</source>
などとしてこのプロファイルに触れるべきです（{{should}}）。
（profile 属性は HTML5 で廃止予定です）
なお、上にある方法を組み合わせてもかまいません。

=== パース処理 ===
[[hcard-parsing|hCard parsing]] をご覧ください。

== hCard の例 ==
このセクションは参考情報です。

=== vCard のサンプル ===
次にあるのは vCard のサンプルです。
<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
END:VCARD
</nowiki></pre>

この vCard を hCard で表現すると次のようになります。なお、推測処理ができるプロパティについては省略してあります。他の例は [[hcard-example1-steps| hCard Example 1]] をご覧ください。

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

この hCard は次のように表示されるでしょう。
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]
</div>

Note: hCard のマークアップにはバージョン情報が必要ありません。なぜならバージョンは <head> 要素の 'profile' 属性に記述されたプロファイルで定義されているからです。

=== hCard の実例 ===
次にあるのは [http://www.commerce.net/ Commercenet] のコンタクト情報です。この情報は hCard を用いて記述されているので、microformats をパース処理するツールにより見つけることができます。

<div class="vcard">
<div class="fn org">'''CommerceNet'''</div>
<div class="url">'''<nowiki>http://www.commerce.net/</nowiki>'''</div>
<div class="adr">'''Work:'''
<div class="street-address">'''169 University Avenue'''</div>
'''Palo Alto''', '''CA'''  '''94301'''
<div class="country-name">'''USA'''</div>
</div>
<div class="tel">'''Work +1-650-289-4040'''</div>
<div class="tel">'''Fax +1-650-289-4041'''</div>
<div>'''Email <nowiki>info@commerce.net</nowiki>'''</div>
</div>

The mark-up, emboldening omitted for clarity, with the following semantic improvements:
* <code>abbr</code> to expand abbreviations
* hyperlinking the org name with the url

<source lang=html4strict>
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
Work:
<div class="street-address">169 University Avenue</div>
Palo Alto,
<abbr class="region" title="California">CA</abbr>  
94301
<div class="country-name">USA</div>
</div>
<div class="tel">
Work +1-650-289-4040
</div>
<div class="tel">
Fax +1-650-289-4041
</div>
<div>Email:
info@commerce.net
</div>
</div>
</source>

=== その他の例 ===
[[hcard-examples|hCard examples]] には vCard 仕様書 [[rfc-2426|RFC2426]] の例をすべて hCard にしたものをはじめ、もっとたくさんの例があります。

== 実世界での例 ==
このセクションは'''参考情報'''です。すでに世界には多くの hCard が存在しています。以前はこの仕様書で紹介していましたが、数が増えすぎてしまったため、別のページを用意しました。

[[hcard-examples-in-wild|hCard Examples in the wild]] で、実際に使われている hCard をご覧ください。

== 実装 ==
このセクションは'''参考情報'''です。前のセクションと同じく、hCard の実装についても別のページを用意しています。

[[hcard-implementations|hCard Implementations]] で、hCard の実装についてご覧ください。

== 記事 ==
このセクションは'''参考情報'''です。hCard の他の読み物は[[hcard-articles-ja|hCard の記事]]をご覧ください。

== hCard ボタン ==
hCard を使ったあなたのページに、次にあるボタンを貼り付けましょう。[[buttons#hCard]] には、最近追加されたボタンもあります。

* http://www.crowley.nl/images/hcard.png (ミラー:http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS でボタン風にデザインすることもできます。[http://re-run.com/about/microformat-badges microformat badges @ re-run] をご覧ください。

== 著作権 ==
仕様の作成者である [[User:Tantek|Tantek Çelik]] および [[User:Brian|Brian Suda]] が、自分のページでパブリックドメインの声明を行っています。よって、この仕様はパブリックドメインです。

{{MicroFormatPublicDomainContributionStatement}}

== 特許 ==
{{MicroFormatPatentStatement-ja}}

== 参考文献 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU 勧告 E.123] 電話番号フォーマット (有料)
* [[rfc-2119|RFC 2119]]

=== その他の参考文献 ===
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* [[iso-8601|ISO8601]]

==== hCard を利用する仕様 ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== hCard に似通っているもの ====
このセクションは'''参考情報'''です。
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== 原案及び謝辞 ==
このセクションは'''参考情報'''です。
vCard を "何年も前に" 教えてくれた私の良き友人 [http://vadim.com/ Vadim] に感謝しています。ただ、もしあのときから vCard を気にかけていたら、もっと多くの車輪の再発明を防げたかもしれませんが。

== vCard における由来 ==
このセクションは ''参考情報'' です。

<div id="Semantic_XHTML_Design_Principles">[[hcard-design-methodology]] をご覧ください。</div>

=== 意味的に同等なもの ===
いくつかのプロパティにおいて、その意味を上手く表現できる HTML 要素が存在します。次に挙げるプロパティは、その例に書かれている (X)HTML で表現すべきです ({{should}})。

* vCard の <code>URL</code> は hCard にて <code><a class="url" href="...">...</a></code> と表します。このプロパティは、<code>class="vcard"</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="Photo of ..." /></code>、または <code><object class="photo" data="..." type="...">Photo of ...</object></code> となります。
* vCard の <code>UID</code> hCard において、特定の URL (または EMAIL) といった、別の意味に置き換えられます。

=== 出現回数が一回のプロパティ ===
[[hcard-ja#.E3.83.97.E3.83.AD.E3.83.91.E3.83.86.E3.82.A3.E3.81.AE.E5.87.BA.E7.8F.BE.E5.9B.9E.E6.95.B0|プロパティの出現回数]]は、vCard RFC2426 で定義されるプロパティを一つずつ調べ、そのセマンティクスから一つのみでなければならない ({{must}}) を導き出したものです。[[hcard-singular-properties]] に解説があるので、そちらをご覧ください。

==== 単数化されたプロパティ ====
いくつかの複数系のプロパティ名が単数名化されています。このため、もし元となる複数形のプロパティが、複数のコンポーネントからなるひとつの値を取るものであっても、それらのコンポーネントは、単数名化されたプロパティを複数持つものとなります。

== 関連ページ ==
{{hcard-related-pages}}

[[Category:hCard]]

== 翻訳 ==
* [[hcard|english]]（英語）
* [[hcard-fr|français]]（フランス語）
* [[hcard-ru|Русский]]（ロシア語）
* [[hcard-zh|汉语]]（中国語）

value-class-pattern-ja

2011-07-24T11:07:09Z

KitaitiMakoto: sync: english: 2011-07-16T07:54:07

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
[[hAtom]] を読み込んで Atom を生成するマイクロフォーマット実装は更に以下に従わなければなりません（{{must}}）。
* 日付と日時の値を全て [[RFC3339]] のフォーマットに正規化する

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Is the value-class pattern supported by any of the microformats tools?'''
** '''A: Yes'''. See the [[value-class-pattern#Implementations|implementations]] section.
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** '''A: 'class' is for field names, not data.''' The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** '''A: New attributes are invalid.''' Microformats exist and function in ''valid'' HTML. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''Shouldn't the <code>title</code> attribute should only be used for content?'''
** '''A: 'title' is used for content, machine readable content.''' The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

=== 購読とパース用ツール ===
* [[Google]] parses <code>value-title</code> as part of their [http://googlewebmastercentral.blogspot.com/2010/01/introducing-new-rich-snippets-format.html support for hCalendar rich snippets], as documented specifically in the [https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164506 microformats example for rich snippet events].
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* HTML::Microformats and its predecessors support <code>value</code> excerpting. HTML::Microformats (though not its predecessors) supports <code>value-title</code>.
=== 公開用ツール ===
* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
== 記事 ==
This section is '''informative'''.

Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/articles/getting-semantic-with-microformats-part-8-value-class-pattern Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 参照 ==
This section is '''informative'''.
* [http://www.useit.com/alertbox/9608.html Jakob Nielsen: International Web Usability]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

== 翻訳 ==
Read the value-class-pattern specification in additional languages:
* [[value-class-pattern|english]]
* [[value-class-pattern-fr|français]]

rel-tag-ja

2011-05-11T14:52:56Z

KitaitiMakoto: sync: english: 2011-05-11T16:12:42

<entry-title>rel="tag"</entry-title>

__TOC__

== 仕様ドラフト 2005-01-10 ==
; 編者/作者
:[http://tantek.com/ Tantek Çelik]
:[http://epeus.blogspot.com/ Kevin Marks]

; 原案
:[http://powazek.com/ Derek Powazek]

; 短縮URL
:http://tr.im/reltag

=== 著作権 ===
{{MicroFormatCopyrightStatement2004-ja}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
* [[User:Kevin Marks|Kevin Marks]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

=== 特許 ===
{{MicroFormatPatentStatement-ja}}

== 概要 ==
[[rel-tag-ja|rel-tag]]は[[microformats-ja|microformats]]のひとつです。ハイパーリンクに<code>rel="tag"</code>を書き加える事により、リンク元のページに対しページ作者が定義した「タグ（キーワードやテーマ）」を関連づけることができます。
タグはblogの記事内容すべてに関係する言葉とは限りません。たとえば次のようなリンクでタグを関連づけるとします。

<source lang=html4strict><a href="http://technorati.com/tag/tech" rel="tag">tech</a></source>

これは作者がこのWebページ（または内容の一部）に「tech」というタグをつけていることを意味します。

リンク先のページはWeb上に存在するべき（SHOULD）であり、またタグの意味はリンクテキストの内容よりも、リンク先のページが持つ情報が優先されます。たとえば次のようなマークアップでページに対しタグ付けを行ったとします。

<source lang=html4strict><a href="http://technorati.com/tag/tech" rel="tag">fish</a></source>

URLの最後にある単語がタグの意味として扱われるので、この場合ページのタグは「fish」ではなく「tech」となります。

== rel-tagの意図、範囲 ==
rel-tagはWebページ（又はその一部）に「タグ付け」をする目的で作られました。このため、任意のURLやページ外部のコンテンツに対し、rel-tagによりタグ付けを行える様にはできていません。現在のページから外部のURLへのタグ付けの一般的な構文についての要望はありますが、rel-tagにおいてその議論はなされるべきでないと考えています。[[xfolk|xFolk]]や[[hreview|hReview]]、[[hcard |hCard]]、[[hcalendar|hCalendar]]、[[hrecipe|hRecipe]]にてURLのタグ付けについて考えられているので、そちらを参照してください。

タグを用いるシステムにおいては、タグの表現に特化したrel-tagは優れたフォーマットと言えるでしょう。

== XMDPプロファイル ==
[[rel-tag-profile]] を参照してください。

== タグスペースとタグの扱い ==
タグはURIの中に分かりやすい形で埋め込まれています、そのためURIからタグを機械的に抽出することが比較的容易です。具体的に説明すると、タグはURIパスの最後にある単語（一番後ろの"/"より後の文字列）となります。たとえば<source lang=html4strict>http://www.example.com/tags/foo</source>というURIが示すタグは「foo」となります。

このため、ある二つのURIをタグとみなし比較する場合は、まず始めにタグをパスの最後から抽出することが推奨（SHOULD）されます。

''タグの抽出・比較についてはもう少し標準的な仕組みが必要だと考えています。''

rel="tag"を埋め込んだハイパーリンクが示す先はタグスペース（同じタグの付いた文書の一覧またはタグの定義）であるよう求められています。たとえば、リンク先の文書が次のURLで表されるとします。

<source lang=html4strict>http://technorati.com/tag/tech </source>

この場合、この文書は「tech」というタグに関するタグスペースであるとみなされます。

タグとなる文字列はURLパスの最後にのみ記すことを許されています。これはクエリパラメータやフラグメント識別子がタグとして認識されないことを意味します。さて、次のURLはどう扱われるでしょうか。

<source lang=html4strict>http://technorati.com/tag/tech?tag=fish#emu </nowiki></source>

この場合も先述のとおり「tech」というタグに関するもので、「fish」や「emu」についてのものではないことに注意してください。

タグスペースに関する決まり事は「タグとなる文字列がURLパスの最後にあること」のみです。このためタグスペースはどのドメインにおいても提供可能となっています。ページ作者はいくつかのタグスペースを選びリンクすることで、特定の意味をタグに持たせることが可能です。たとえばWikipediaのページをタグスペースに用いる事ができます。

<source lang=html4strict> http://en.wikipedia.org/wiki/Technology </source>

この場合、タグは「Technology」を指します。

URLの末にあるスラッシュは無視されます。つまり次のURL

<source lang=html4strict> http://technorati.com/tag/Technology/ </source>
これをrel-tagに用いる場合、最後のスラッシュは取り除かれ、
<source lang=html4strict> http://technorati.com/tag/Technology </source>
と同じ扱いを受けることになります。

== タグのエンコード ==
タグにおけるスペースは「<code>+</code>」又は「<code>%20</code>」へとエンコードして含めることが可能です。Unicode文字は[http://www.ietf.org/rfc/rfc3986.txt <nowiki>RFC 3986</nowiki>]で述べられている様にエンコードされます。たとえば次のようになります。

<source lang=html4strict><a href="http://technorati.com/tag/Sant%C3%A9+et+bien-%C3%AAtre" rel="tag">Santé et bien-être</a> </source>

Wikipediaをタグスペースとして利用する場合には「<code>%20</code>」を利用すべきです。Wikipediaは「+」を「<code>%2B</code>」へと置換してしまうため、通常ページのタイトルに存在しない「+」を表示させてしまうからです。

== 目にみえるメタデータとしてのタグ ==
<code>rel="tag"</code>を含んだハイパーリンクは、Webページ上に現れるよう期待されています。これはページ上に現れず、閲覧者の目に届く事がほとんどないmetaキーワードとrel-tagの大きな違いです。タグがWebページに表示されるため、metaキーワードよりも弾力的にキーワードspamなどの問題に対処することができると考えています。

タグのリンクが目に見えることにより、ページ閲覧者はそのリンクが悪用されたものかを簡単に知ることができます。このためリンクを用いた不正行為をある程度抑止できると考えています。どんな目に見えないメタデータが生成されているのかを知らないページ作成者にも効果的でしょう。

このため、<code><link rel="tag" href="..." /></code> のような目に見えないタグリンクの表現は実装されるべきではありません（SHOULD NOT）。

== rel-tagの利用例 ==
このセクションは'''参考情報'''です。

以下はrel-tagを実装したWebサイトのリストです。rel-tagをパースしている、又はタグのインデックスを作っていたり、タグの整理が行われているWebサイトの例をお探しなら、きっとこのリストが役立つでしょう。もしあなたがrel-tagを利用していたら、気軽に'''このリストの上'''に追加してください。リストが大きくなったら、[[rel-tag-examples-in-wild]] といった別のページにて紹介する予定です。 

* [http://en.newsgrail.com/ Newsgrail] uses rel-tag for an implementation of structured sematic tagging by [http://opencalais.com/ OpenCalais].
* [http://davidswain.co.uk Actor David Swain] uses rel-tag on all "tag" links on his site each pointing to its own tag-space.
* [http://beeets.com beeets] is a tag-based event search engine that uses rel-tag on all "tag" links, each pointing to its own tag-space.
* [http://www.beginrunning.com/ Begin Running] uses rel-tag on pages containing tagged content.
* [http://laibcoms.asia/blog/ Snow World] uses rel-tag on all "tag" links. As is built in [http://b2evolution.net b2evolution].
* [http://gameshogun.ws/ gameshogun™] uses rel-tag on all "tag" links. A [http://b2evolution.net b2evolution] implementation.
* [http://clothesonline.info ClothesOnline] uses rel-tag for categorizing shops and brands, for example: [http://clothesonline.info/brands/canada-goose Canada Goose].
* [http://huffduffer.com/ Huffduffer] uses rel-tag on every page, pointing to its own tag space e.g. http://huffduffer.com/tags/microformats
* [http://www.pantrymothtrap.com/ Pantry Moth Traps] implements the rel-tag in articles where an authoritative source is known. (for example in the article [http://www.pantrymothtrap.com/MothTrapsPick.html Moth Trap Picks] the tag [http://www.cleanertoday.com/tag/moth%20trap Moth Trap])
* [http://www.hightechcville.com/ HighTechCville] uses rel-tag on all the pages listing tagged content for [http://www.hightechcville.com/people people], [http://www.hightechcville.com/organizations organizations] and [http://www.hightechcville.com/events events] related to high tech in Charlottesville, VA.
* [http://skateboardspot.info skateboardspot.info] uses rel-tag in spotguide entries which are added to the site and categorized by the users (for example: [http://skateboardspot.info/cat/spotguide/action/view/id/1 “El Toro High School” spotguide entry]).
* [http://www.idoneos.com Idoneos.com] uses rel-tag for conceptual links to its own tag space, a collection of 'concepts' (mostly spanish).
* [http://www.professionalontheweb.com Professional On The Web] uses rel-tag for user entered tags which categorize web professionals and freelancers.
* [https://www.coderesort.com/p/epicode/wiki/CloudCuckoo CloudCuckoo] (secure site but open to all) an [http://www.episerver.com EPiServer] module distributed free by [http://www.interakting.co.uk Interakting], generates tag clouds with rel-tag links.
* [http://www.lifetime.com Lifetime.com] uses rel- and rev-tags in all content pages.
* [http://www.my-warehouse.de the my-Warehouse shopsystem] implements rel-tags in box headings and categories links.
* Joseph Bergantine uses tags to categorize [http://bergantinedesign.us/wallpaper/ wallpapers] and [http://bergantinedesign.us/blog/my-name-is-rachel-corrie blog posts]
* [http://www.codesignville.com Codesignville] uses rel-tag to indicate content categories.
* [http://www.bossalive.com BossaLive] uses rel-tag for tagging music. Publishes rel-tags for album, artist and genre.
** Also uses [[hcard|hCard]] on user profile pages.
* [http://www.qmpeople.com/ qmpeople] Uses rel-tag for translated tags into english, french and italian to meet new friends in different countries.
* [http://www.keevu.com Keevu.com] uses rel-tag to indicate content categories on most pages, like [http://www.keevu.com/venues venues]
* [http://www.amazingincredible.com Amazing Incredible] uses rel-tag on content pages
* [http://www.auctionlink.com.au AuctionLink]では[http://www.auctionlink.com.au/TagList/Auctioneers/ Auction Sales Listings]のタグにrel-tagを用いています。
** Could also use [[hcard|hCard]], e.g. on [http://www.auctionlink.com.au/Auctioneers/Auctioneer/Bonhams_Goodman_1/] [[User:AndyMabbett|Andy Mabbett]]
* Christian Hessは[http://www.hess-cr.com blog]と他のページでrel-tagを用いています。
* [http://spacedust.atspace.com/ Spacedust]はギャラリーページのマークアップにrel-tagを利用しています。
* [http://my.opera.com/dstorey/blog/ My Opera]では、全てのユーザのblogエントリがrel-tagを利用しています。
* [http://dev.opera.com/articles/view/making-wii-friendly-pages/ Dev Opera]では、記事のタグにrel-tagが使われています。
* [http://www.international.unt.edu UNT International]はほとんどのページにおいて、カテゴリをrel-tagで表現しています。
* [http://yedda.com Yedda] - Yeddaは利用者が自分につけたタグ、そしてYeddaにて質問された事柄につけられたタグにrel-tagを利用しています。
* [http://www.lingr.com Lingr]はユーザが入力したすべてのタグを表示しています。
* [http://odeo.com ODEO]では[http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html rel-tagを利用しています]。
* [http://eventful.com Eventful]ではユーザがつけたタグの表現に、rel-tagが使われています。
* [http://spinn3r.com Spinn3r] implements rel-tag as well as RSS and Atom subject and categories.
* [http://www.weboffate.com Web of Fate] publishes rel-tags for future predictions.

== 実装 ==
このセクションは'''参考情報'''です。

次に紹介されているリストは、rel-tagを実装しているアプリケーションのものです。もしあなたがrel-tagを利用したサービスやソフトウェアを開発していたら、気軽に'''このリストの上'''に追加してください。リストが大きくなったら、[[rel-tag-implementations]] といった別のページにて紹介する予定です。

* [http://b2evolution.net b2evolution] A blog platform which generates rel-tag for all tags on blog posts (starting from v3.x).
* [http://www.textcube.org Textcube.org] makes a blogging tool, Textcube which generates rel-tag for tags on blog posts.
* [http://hashtags.org/ HashTags] tags Twitter posts, converting "#example" into a tag of "example"
* [http://ikiwiki.info ikiwiki] generates rel-tag for all tagged pages (as of version 2.6)
* [http://www.hubtag.com HubTag] helps users find a unique tag across the web for their event - eg. JohnAndBettysWeddingWimbledonMarch07
* [http://www.necctar.com Necctar] is a search engine exclusively based on tag microformat parsing and processing. Necctar uses tags entered by bloggers to index the world wide web
* Nutchは[[rel-tag]]のパーサを[http://www.mail-archive.com/nutch-commits@lucene.apache.org/msg01014.html svnレポジトリにコミットしました]。
* [http://webstandards.org/ Web Standards Project]が提供している[http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver拡張スイート]を導入することにより、Dreamweaver 8でrel-tagを用いたタギングができます。
* スライドショー作成サービス[http://scooch.gr0w.com/ Scooch]では、作成者がスライドショーに埋め込んだタグのタグクラウドを見ることができます。
* Weblogシステム[http://www.s9y.org Serendipity]のFreetagプラグインは、エントリのタグ付けを可能とします。（FreetagプラグインはSPARTACUSのなかにあります。）
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf]は[http://textpattern.com/ Textpattern]でrel-tagや他のmicroformatsをテンプレートやエントリで利用可能とするプラグインです。[http://placenamehere.com/ Chris Casciano]により制作されました。
* [http://www.rainskit.com/blog/493/trutags-a-tagging-plugin-for-textpattern tru_tags]は[http://textpattern.com/ Textpattern]で、キーワード欄からエントリのタグ付けを可能とするプラグインです。
* [http://clothesonline.info ClothesOnline] uses rel-tag for categorizing shops and brands, for example: [http://clothesonline.info/brands/canada-goose Canada Goose].
* [http://news.livejournal.com/86492.html?thread=24881884 LiveJournal]には[http://www.livejournal.com/support/faq.bml?cat=tags タグに関するサポートページ]が用意されています。
* [http://trac.labnotes.org/cgi-bin/trac.cgi/wiki/TagsLinks TagsLinks]を用いて、ページに埋め込まれたタグと、他のサービスが用意したタグスペースをつなげることができます。
* [http://www.octofinder.com OctoFinder] uses rel-tag for all live news tag clouds.
* [http://dev.wp-plugins.org/wiki/BunnysTechnoratiTags WordPress用のタグ付けプラグイン]です。
** Note that some sites using WordPress (http://microformatique.com/ for instance) are getting incorrect tags. The tag is ?cat=12 instead of the actual tag value.
* [http://noone.org/blog/tags/Tagging Blosxom用のタグ付けプラグイン]です。
* Technoratiはrel-tagを実装した最初のサービスです。[http://technorati.com/tag/ Technorati Tags]から、Technoratiがインデックスしているタグを見ることが出来ます。
* [http://consumingexperience.blogspot.com/2005/12/updated-multiple-word-technorati-tag.html Bloggerでタグを利用するためのGreasemonkeyスクリプト]です。
* [http://tools.microformatic.com/help/xhtml/rel-lint/ rel-lint]は[[User:DrewMcLellan|Drew McLellan]]による、rel-tagを検証するツールです。

== 参照 ==
=== 標準仕様 ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML 1]
* [http://gmpg.org/xmdp/ XMDP]
* RFC 3986ではURIの構文を規定しています。Section 3.3にURLパスとパスセグメントに関する記述があります。

=== 参考 ===
* [[hreview|hReview]]ではrel-tagを一般的なタグ、またレート付けに用いています。
* [[xfolk|xFolk]]はrel-tagを用いて、タグ付けされたリソースの分散型処理を可能としています。
* [http://developers.technorati.com/wiki/attentionxml Attention.XML]はrel-tagを用い、読者がページやweblogの投稿、又はフィードへのタグ付けを行えるようにしています。
* [[hcard|hCard]]では、rel-tagを用いたカテゴリの作成が可能です。
* [[hcalendar|hCalendar]]でも、rel-tagを用いたカテゴリの作成が可能です。
* [http://technorati.com/help/tags.html Using Technorati Tags]で、Technoratiにおけるタグの扱いを知ることが出来ます。
* rel-tagは http://developers.technorati.com/wiki/RelTag からの寄稿により作成されました。
* microformatique.comの[http://microformatique.com/?p=61 Know your rel-tag]に、rel-tagについての説明があります。

== ディスカッション ==
* フィードバックは[[rel-tag-feedback]]にてお願いします。
* [http://www.technorati.com/cosmos/referer.html rel-tagについて言及しているページ]も参照してください。
* これまでの経緯については[http://www.powazek.com/ Derek Powazek]による[http://www.powazek.com/2005/07/000532.html How Tags Happened at Technorati]をお読み下さい。

=== Q&A ===
* rel-tagに関して分からないことがありますか？それがrel属性に関する疑問ならば[[rel-faq|rel FAQ]]を、rel-tagに関する疑問であれば[[rel-tag-faq|rel-tag FAQ]]をお読み下さい。これらのページを読んでも疑問が解消されない場合は、[http://microformats.org/discuss microformats-discuss]にメールを投稿するとよいでしょう。

==Related pages==
{{rel-tag-related-pages}}

[[Category:Specifications]]
[[Category:rel-tag]]

hcard-ja

2011-04-17T15:26:02Z

KitaitiMakoto: sync: english: 2011-04-15T01:42:45

<entry-title>hCard 1.0</entry-title>

[[User:Tantek|Tantek Çelik]] (Editor, Author), [[User:Brian|Brian Suda]] (Author)
----
<dfn style="font-style:normal;font-weight:bold">hCard</dfn> は、vCard ([[rfc-2426|RFC2426]]) のプロパティと値を利用して、[[semantic-xhtml|HTML]] で人や会社、組織や場所を表現する [[microformats-ja|microformat]] です。hCard は HTML や XHTML はもちろんのこと、Atom、RSS、その他の XML に埋め込むことができます。

[[hcard-ja#原案及び謝辞|謝辞のセクション]]をご覧ください。
権利に関する情報は、[[hcard#Copyright|著作権]]と[[hcard#Patents|特許]]のセクションをご覧ください。

== 例 ==
hCards are most often used to represent people:
<source lang=html4strict>
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>
and organizations:
<source lang=html4strict>
<div class="vcard">
<a class="url fn org" href="http://microformats.org/">microformats.org</a>
</div>
</source>

The class '''<code>vcard</code>''' is a ''[[hcard#Root_Class_Name|root class name]]'' that indicates the presence of an hCard. The classes '''<code>url</code>''', '''<code>fn</code>''', and '''<code>org</code>''' are ''properties'' that indicate aspects of the hCard. See the [[hcard#Property_List|list of properties]] for more.

'''Want to get started with writing an [[hcard|hCard]]?''' Use the [http://microformats.org/code/hcard/creator hCard creator] to write up some contact information and publish it, or follow the [[hcard-authoring|hCard authoring tips]] to add hCard markup to your current contact page.

== 状態 ==
hCard 1.0 is a microformats.org specification. Public discussion on hCard takes place on [[hcard-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== 利用できる言語 ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== 訂正事項と更新事項 ===
Known errors and issues in this specification are corrected in [[hcard-issues-resolved|resolved]] and [[hcard-issues-closed|closed]] issues. Please check there before reporting [[hcard-issues|issues]].

The hCard 1.0.1 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

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

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

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

== 適合性 ==
{{rfc-2119-intro-ja}}

== フォーマット ==
=== 基本情報 ===
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) のプロパティ名や値が、hCard の基礎となります。

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

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

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

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

'''必須プロパティ'''
* '''fn'''
* '''n'''[[#note1|1]] (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)

任意プロパティ
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value)
* agent
* bday
* category
* class
* email (type, value)
* geo (latitude, longitude)
* key
* label
* logo
* mailer
* nickname
* note
* org (organization-name, organization-unit)
* photo
* rev
* role
* sort-string
* sound
* tel[[#note2|2]] (type, value)
* title
* tz
* uid
* url

=== プロパティについて ===
[[#property-list-n|1. ^]]: 'n' プロパティは、[[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]にあるルールに当てはまる場合は、任意 ({{optional}}) プロパティとなります。 
[[#property-list-tel|2. ^]]: tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することができます ({{may}})。文字の入った電話番号 (例: +1-555-FORMATS) は、数字で表記しなければなりません ({{must}})。<code>abbr</code> を利用して、ソフトウェアには数字から成る電話番号の方を伝えることもできます (<code><nowiki><abbr title="+15553676287">+1-555-FORMATS</abbr></nowiki></code>)。

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

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

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

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

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

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

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

=== 値の抜粋 ===
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合は特別な class 名である "<code>value</code>" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップする hCard を例に取り説明しましょう。 

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>

home:
+1.415.555.1212

</source>

この hCard は次のように表示されるでしょう。

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

home:
+1.415.555.1212

</div>

You may want to customize/localize the visible punctuation and not want to include it in what machines see. Use multiple class="value" elements which are then concatenated. E.g.

<source lang=html4strict>

home:
+1.415.555.1212

</source>

No change in display, but the parsed hCard property value then becomes in vCard:

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+14155551212
</nowiki></pre>


=== プロパティの例外 ===
vCard には、Web ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。

# vCard の '''NAME'''、'''PROFILE'''、'''SOURCE'''、'''PRODID'''、'''VERSION''' プロパティは [[rfc-2426|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 文書の場合、<code><title></code> 要素) を用いることが推奨されます ({{should}})。PROFILE の値には、[[rfc-2426|RFC2426]] より "<code>VCARD</code>" の値を使うことができます ({{may}})。SOURCE プロパティには、ページの URL を用いることが推奨されます ({{should}})。hCard を vCard に変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODID プロパティは、実際に vCard を出力するサービスやアプリケーションのみが記述するべきです ({{should}})。同様に、そのようなアプリケーションのみが、[[rfc-2426|RFC2426]] のセクション 3.6.9 に倣い、VERSION プロパティに "3.0" という値をつけるべきです ({{should}})。

=== 組織のコンタクト情報 ===
もし、"FN" と "ORG"（organization；組織）プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、その hCard は会社や組織、場所のコンタクト情報を表すものとみなされます ({{should}})。このとき、作成者は "N" プロパティを記述することはできない ({{must-not}})、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます ({{should}})。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。

=== "N" の推測処理 ===
vCard では "N" プロパティの記述が必須となっています。ところが vCard 仕様書 ([[rfc-2426|RFC2426]]) では、最後の方 (p.38) にある作者の vCard に "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCard では次のように規定します。

もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります ({{must}})。しかし、組織名の場合はこのルールに当てはまりません。この場合は[[hcard-ja#.E7.B5.84.E7.B9.94.E3.81.AE.E3.82.B3.E3.83.B3.E3.82.BF.E3.82.AF.E3.83.88.E6.83.85.E5.A0.B1|組織のコンタクト情報]]で書かれているルールが適用されます。

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

これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。
* given-name (スペース) family-name
* family-name (コンマ) given-name
* family-name (コンマ) given-name のイニシャル
* family-name (スペース) given-name のイニシャル (任意のピリオド)

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語で名前を記述するときには、この推測処理を利用することはできません。必ず given-name、family-name プロパティを利用し、明示的に名前を記述しなければなりません。

<pre><nowiki>
<div class="vcard">

マイクロ
太郎

</div>
</nowiki></pre>
</div>

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

"nickname" の推測機構は [[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。

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

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

<source lang=html4strict>

daveman692

</source>

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

=== "organization-name" の推測処理 ===
"ORG" プロパティは organization-name と organization-unit という二つのサブプロパティを持っています。しかしほとんどの場合、作成者は organization-name のみを記述します。よって、もし "ORG" プロパティが "organization-name" プロパティを内側に持たない場合、"ORG" プロパティの内容は必ず "organization-name" とみなされます ({{must}})。

=== カテゴリーとしてのタグ ===
hCard のカテゴリーは [[rel-tag]] を用い、タグとして表現することも可能です ({{may}})。"category" プロパティが rel-tag である場合、そのタグはカテゴリーとして扱われます。

=== 'type' サブプロパティの値 ===
'type' サブプロパティがとる値は、その親プロパティによって異なります。これらの 'type' サブプロパティの値は大文字小文字を区別しません (case-INSENSITIVE)。よって "Home" は "home" と同じであり、その他の値と組み合わせた場合についても同様です。たとえば、家の電話番号で、かつ優先番号であるものは次のようになります。

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
Home (preferred):
+1.415.555.1212

</source>

この例は次のように表示されるでしょう。

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
Home (preferred):
+1.415.555.1212

</div>

==== type with unspecified value ====
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.

<source lang=html4strict>
Home +1.415.555.1212
</source>

is equivalent to:

<source lang=html4strict>
Home +1.415.555.1212
</source>

And thus the type is "home" and the value is "+1.415.555.1212".

==== adr tel email types ====
次のリストは ''参考情報'' です。

規範的な type の値は [[rfc-2426|RFC2426]] のセクション 3.2.1 ADR、3.3.1 TEL、3.3.2 EMAIL を参照してください (ここでは利便性の為にコピーしています)。type サブプロパティのデフォルト値はリストの最初に並んでおり、また大文字で記述されています。また、これらの type は複数指定することができます。

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref, "IANA に登録された他のアドレスタイプ"

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語などの言語では、これらサブプロパティの多くを利用することができません。サブタイプはマークアップの制限上、その内容を訳すことができないからです。
</div>

=== プロファイル ===
hCard の XMDP プロファイル は http://microformats.org/profile/hcard にあります。

hCard を使うコンテンツは、
<source lang=html4strict>
<link rel="profile" href="http://microformats.org/profile/hcard">
</source>
や
<source lang=html4strict>
このコンテンツは <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a> を使っています。
</source>
又は
<source lang=html4strict>
<head rel="profile" href="http://microformats.org/profile/hcard">
</source>
などとしてこのプロファイルに触れるべきです（{{should}}）。
（profile 属性は HTML5 で廃止予定です）
なお、上にある方法を組み合わせてもかまいません。

=== パース処理 ===
[[hcard-parsing|hCard parsing]] をご覧ください。

== hCard の例 ==
このセクションは参考情報です。

=== vCard のサンプル ===
次にあるのは vCard のサンプルです。
<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
END:VCARD
</nowiki></pre>

この vCard を hCard で表現すると次のようになります。なお、推測処理ができるプロパティについては省略してあります。他の例は [[hcard-example1-steps| hCard Example 1]] をご覧ください。

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

この hCard は次のように表示されるでしょう。
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]
</div>

Note: hCard のマークアップにはバージョン情報が必要ありません。なぜならバージョンは <head> 要素の 'profile' 属性に記述されたプロファイルで定義されているからです。

=== hCard の実例 ===
次にあるのは [http://www.commerce.net/ Commercenet] のコンタクト情報です。この情報は hCard を用いて記述されているので、microformats をパース処理するツールにより見つけることができます。

<div class="vcard">
<div class="fn org">'''CommerceNet'''</div>
<div class="url">'''<nowiki>http://www.commerce.net/</nowiki>'''</div>
<div class="adr">'''Work:'''
<div class="street-address">'''169 University Avenue'''</div>
'''Palo Alto''', '''CA'''  '''94301'''
<div class="country-name">'''USA'''</div>
</div>
<div class="tel">'''Work +1-650-289-4040'''</div>
<div class="tel">'''Fax +1-650-289-4041'''</div>
<div>'''Email <nowiki>info@commerce.net</nowiki>'''</div>
</div>

The mark-up, emboldening omitted for clarity, with the following semantic improvements:
* <code>abbr</code> to expand abbreviations
* hyperlinking the org name with the url

<source lang=html4strict>
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
Work:
<div class="street-address">169 University Avenue</div>
Palo Alto,
<abbr class="region" title="California">CA</abbr>  
94301
<div class="country-name">USA</div>
</div>
<div class="tel">
Work +1-650-289-4040
</div>
<div class="tel">
Fax +1-650-289-4041
</div>
<div>Email:
info@commerce.net
</div>
</div>
</source>

=== その他の例 ===
[[hcard-examples|hCard examples]] には vCard 仕様書 [[rfc-2426|RFC2426]] の例をすべて hCard にしたものをはじめ、もっとたくさんの例があります。

== 実世界での例 ==f
このセクションは'''参考情報'''です。すでに世界には多くの hCard が存在しています。以前はこの仕様書で紹介していましたが、数が増えすぎてしまったため、別のページを用意しました。

[[hcard-examples-in-wild|hCard Examples in the wild]] で、実際に使われている hCard をご覧ください。

== 実装 ==
このセクションは'''参考情報'''です。前のセクションと同じく、hCard の実装についても別のページを用意しています。

[[hcard-implementations|hCard Implementations]] で、hCard の実装についてご覧ください。

== 記事 ==
このセクションは'''参考情報'''です。hCard の他の読み物は[[hcard-articles-ja|hCard の記事]]をご覧ください。

== hCard ボタン ==
hCard を使ったあなたのページに、次にあるボタンを貼り付けましょう。[[buttons#hCard]] には、最近追加されたボタンもあります。

* http://www.crowley.nl/images/hcard.png (ミラー:http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS でボタン風にデザインすることもできます。[http://re-run.com/about/microformat-badges microformat badges @ re-run] をご覧ください。

== 著作権 ==
仕様の作成者である [[User:Tantek|Tantek Çelik]] および [[User:Brian|Brian Suda]] が、自分のページでパブリックドメインの声明を行っています。よって、この仕様はパブリックドメインです。

{{MicroFormatPublicDomainContributionStatement}}

== 特許 ==
{{MicroFormatPatentStatement-ja}}

== 参考文献 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU 勧告 E.123] 電話番号フォーマット (有料)
* [[rfc-2119|RFC 2119]]

=== その他の参考文献 ===
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* [[iso-8601|ISO8601]]

==== hCard を利用する仕様 ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== hCard に似通っているもの ====
このセクションは'''参考情報'''です。
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== 原案及び謝辞 ==
このセクションは'''参考情報'''です。
vCard を "何年も前に" 教えてくれた私の良き友人 [http://vadim.com/ Vadim] に感謝しています。ただ、もしあのときから vCard を気にかけていたら、もっと多くの車輪の再発明を防げたかもしれませんが。

== vCard における由来 ==
このセクションは ''参考情報'' です。

<div id="Semantic_XHTML_Design_Principles">[[hcard-design-methodology]] をご覧ください。</div>

=== 意味的に同等なもの ===
いくつかのプロパティにおいて、その意味を上手く表現できる HTML 要素が存在します。次に挙げるプロパティは、その例に書かれている (X)HTML で表現すべきです ({{should}})。

* vCard の <code>URL</code> は hCard にて <code><a class="url" href="...">...</a></code> と表します。このプロパティは、<code>class="vcard"</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="Photo of ..." /></code>、または <code><object class="photo" data="..." type="...">Photo of ...</object></code> となります。
* vCard の <code>UID</code> hCard において、特定の URL (または EMAIL) といった、別の意味に置き換えられます。

=== 出現回数が一回のプロパティ ===
[[hcard-ja#.E3.83.97.E3.83.AD.E3.83.91.E3.83.86.E3.82.A3.E3.81.AE.E5.87.BA.E7.8F.BE.E5.9B.9E.E6.95.B0|プロパティの出現回数]]は、vCard RFC2426 で定義されるプロパティを一つずつ調べ、そのセマンティクスから一つのみでなければならない ({{must}}) を導き出したものです。[[hcard-singular-properties]] に解説があるので、そちらをご覧ください。

==== 単数化されたプロパティ ====
いくつかの複数系のプロパティ名が単数名化されています。このため、もし元となる複数形のプロパティが、複数のコンポーネントからなるひとつの値を取るものであっても、それらのコンポーネントは、単数名化されたプロパティを複数持つものとなります。

== 関連ページ ==
{{hcard-related-pages}}

[[Category:hCard]]

== 翻訳 ==
* [[hcard|english]]（英語）
* [[hcard-fr|français]]（フランス語）
* [[hcard-ru|Русский]]（ロシア語）
* [[hcard-zh|汉语]]（中国語）

hcard-ja

2011-04-13T15:07:44Z

KitaitiMakoto: sync: english: 2011-04-13T20:15:17

<entry-title>hCard 1.0</entry-title>


<dfn style="font-style:normal;font-weight:bold">hCard</dfn> は、vCard ([[rfc-2426|RFC2426]]) のプロパティと値を利用して、[[semantic-xhtml|HTML]] で人や会社、組織や場所を表現する [[microformats-ja|microformat]] です。hCard は HTML や XHTML はもちろんのこと、Atom、RSS、その他の XML に埋め込むことができます。

'''hCard を利用するには、いくつかの方法があります。'''
*[http://blog.livedoor.jp/forestk/misc/microformats/hCard/creator-ja/ hCard creator] hCard を利用し、作成したコードをページにはりつける。
*[[hcard-authoring|hCard authoring tips]] を読んで、hCard のマークアップを行う。

<div class="vcard">
; 編集者
: [[User:Tantek|Tantek Çelik]] (http://tantek.com/, and before at [http://technorati.com Technorati, Inc.], and at [http://microsoft.com/ Microsoft Corporation])
</div>
; 作者: [http://tantek.com/ Tantek Çelik] (affiliations above)
: [[User:Brian|Brian Suda]] (http://suda.co.uk/)

; 謝辞: [[hcard-ja#原案及び謝辞|謝辞のセクション]]をご覧ください。

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

== 例 ==
hCards are most often used to represent people on the web:
<source lang=html4strict>
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>
The class '''<code>vcard</code>''' is a ''[[hcard#Root_Class_Name|root class name]]'' that indicates the presence of an hCard. The classes '''<code>url</code>''' and '''<code>fn</code>''' are ''properties'' that indicate aspects of the hCard. See the [[hcard#Property_List|list of properties]] for more.

'''Want to get started with writing an [[hcard|hCard]]?''' Use the [http://microformats.org/code/hcard/creator hCard creator] to write up some contact information and publish it, or follow the [[hcard-authoring|hCard authoring tips]] to add hCard markup to your current contact page.

== 状態 ==
hCard 1.0 is a microformats.org specification. Public discussion on hCard takes place on [[hcard-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== 利用できる言語 ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== 訂正事項と更新事項 ===
Known errors and issues in this specification are corrected in [[hcard-issues-resolved|resolved]] and [[hcard-issues-closed|closed]] issues. Please check there before reporting [[hcard-issues|issues]].

The hCard 1.0.1 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

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

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

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

{{rfc-2119-intro-ja}}

== フォーマット ==
=== 基本情報 ===
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) のプロパティ名や値が、hCard の基礎となります。

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

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

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

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

'''必須プロパティ'''
* '''fn'''
* '''n'''[[#note1|1]] (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)

任意プロパティ
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value)
* agent
* bday
* category
* class
* email (type, value)
* geo (latitude, longitude)
* key
* label
* logo
* mailer
* nickname
* note
* org (organization-name, organization-unit)
* photo
* rev
* role
* sort-string
* sound
* tel[[#note2|2]] (type, value)
* title
* tz
* uid
* url

=== プロパティについて ===
[[#property-list-n|1. ^]]: 'n' プロパティは、[[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]にあるルールに当てはまる場合は、任意 ({{optional}}) プロパティとなります。 
[[#property-list-tel|2. ^]]: tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することができます ({{may}})。文字の入った電話番号 (例: +1-555-FORMATS) は、数字で表記しなければなりません ({{must}})。<code>abbr</code> を利用して、ソフトウェアには数字から成る電話番号の方を伝えることもできます (<code><nowiki><abbr title="+15553676287">+1-555-FORMATS</abbr></nowiki></code>)。

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

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

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

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

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

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

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

=== 値の抜粋 ===
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合は特別な class 名である "<code>value</code>" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップする hCard を例に取り説明しましょう。 

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>

home:
+1.415.555.1212

</source>

この hCard は次のように表示されるでしょう。

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

home:
+1.415.555.1212

</div>

You may want to customize/localize the visible punctuation and not want to include it in what machines see. Use multiple class="value" elements which are then concatenated. E.g.

<source lang=html4strict>

home:
+1.415.555.1212

</source>

No change in display, but the parsed hCard property value then becomes in vCard:

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+14155551212
</nowiki></pre>


=== プロパティの例外 ===
vCard には、Web ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。

# vCard の '''NAME'''、'''PROFILE'''、'''SOURCE'''、'''PRODID'''、'''VERSION''' プロパティは [[rfc-2426|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 文書の場合、<code><title></code> 要素) を用いることが推奨されます ({{should}})。PROFILE の値には、[[rfc-2426|RFC2426]] より "<code>VCARD</code>" の値を使うことができます ({{may}})。SOURCE プロパティには、ページの URL を用いることが推奨されます ({{should}})。hCard を vCard に変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODID プロパティは、実際に vCard を出力するサービスやアプリケーションのみが記述するべきです ({{should}})。同様に、そのようなアプリケーションのみが、[[rfc-2426|RFC2426]] のセクション 3.6.9 に倣い、VERSION プロパティに "3.0" という値をつけるべきです ({{should}})。

=== 組織のコンタクト情報 ===
もし、"FN" と "ORG"（organization；組織）プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、その hCard は会社や組織、場所のコンタクト情報を表すものとみなされます ({{should}})。このとき、作成者は "N" プロパティを記述することはできない ({{must-not}})、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます ({{should}})。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。

=== "N" の推測処理 ===
vCard では "N" プロパティの記述が必須となっています。ところが vCard 仕様書 ([[rfc-2426|RFC2426]]) では、最後の方 (p.38) にある作者の vCard に "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCard では次のように規定します。

もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります ({{must}})。しかし、組織名の場合はこのルールに当てはまりません。この場合は[[hcard-ja#.E7.B5.84.E7.B9.94.E3.81.AE.E3.82.B3.E3.83.B3.E3.82.BF.E3.82.AF.E3.83.88.E6.83.85.E5.A0.B1|組織のコンタクト情報]]で書かれているルールが適用されます。

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

これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。
* given-name (スペース) family-name
* family-name (コンマ) given-name
* family-name (コンマ) given-name のイニシャル
* family-name (スペース) given-name のイニシャル (任意のピリオド)

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語で名前を記述するときには、この推測処理を利用することはできません。必ず given-name、family-name プロパティを利用し、明示的に名前を記述しなければなりません。

<pre><nowiki>
<div class="vcard">

マイクロ
太郎

</div>
</nowiki></pre>
</div>

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

"nickname" の推測機構は [[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。

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

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

<source lang=html4strict>

daveman692

</source>

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

=== "organization-name" の推測処理 ===
"ORG" プロパティは organization-name と organization-unit という二つのサブプロパティを持っています。しかしほとんどの場合、作成者は organization-name のみを記述します。よって、もし "ORG" プロパティが "organization-name" プロパティを内側に持たない場合、"ORG" プロパティの内容は必ず "organization-name" とみなされます ({{must}})。

=== カテゴリーとしてのタグ ===
hCard のカテゴリーは [[rel-tag]] を用い、タグとして表現することも可能です ({{may}})。"category" プロパティが rel-tag である場合、そのタグはカテゴリーとして扱われます。

=== 'type' サブプロパティの値 ===
'type' サブプロパティがとる値は、その親プロパティによって異なります。これらの 'type' サブプロパティの値は大文字小文字を区別しません (case-INSENSITIVE)。よって "Home" は "home" と同じであり、その他の値と組み合わせた場合についても同様です。たとえば、家の電話番号で、かつ優先番号であるものは次のようになります。

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
Home (preferred):
+1.415.555.1212

</source>

この例は次のように表示されるでしょう。

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
Home (preferred):
+1.415.555.1212

</div>

==== type with unspecified value ====
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.

<source lang=html4strict>
Home +1.415.555.1212
</source>

is equivalent to:

<source lang=html4strict>
Home +1.415.555.1212
</source>

And thus the type is "home" and the value is "+1.415.555.1212".

==== adr tel email types ====
次のリストは ''参考情報'' です。

規範的な type の値は [[rfc-2426|RFC2426]] のセクション 3.2.1 ADR、3.3.1 TEL、3.3.2 EMAIL を参照してください (ここでは利便性の為にコピーしています)。type サブプロパティのデフォルト値はリストの最初に並んでおり、また大文字で記述されています。また、これらの type は複数指定することができます。

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref, "IANA に登録された他のアドレスタイプ"

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語などの言語では、これらサブプロパティの多くを利用することができません。サブタイプはマークアップの制限上、その内容を訳すことができないからです。
</div>

=== プロファイル ===
hCard の XMDP プロファイル は http://microformats.org/profile/hcard にあります。

hCard を使うコンテンツは、
<source lang=html4strict>
<link rel="profile" href="http://microformats.org/profile/hcard">
</source>
や
<source lang=html4strict>
このコンテンツは <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a> を使っています。
</source>
又は
<source lang=html4strict>
<head rel="profile" href="http://microformats.org/profile/hcard">
</source>
などとしてこのプロファイルに触れるべきです（{{should}}）。
（profile 属性は HTML5 で廃止予定です）
なお、上にある方法を組み合わせてもかまいません。

=== パース処理 ===
[[hcard-parsing|hCard parsing]] をご覧ください。

== hCard の例 ==
このセクションは参考情報です。

=== vCard のサンプル ===
次にあるのは vCard のサンプルです。
<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
END:VCARD
</nowiki></pre>

この vCard を hCard で表現すると次のようになります。なお、推測処理ができるプロパティについては省略してあります。他の例は [[hcard-example1-steps| hCard Example 1]] をご覧ください。

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

この hCard は次のように表示されるでしょう。
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]
</div>

Note: hCard のマークアップにはバージョン情報が必要ありません。なぜならバージョンは <head> 要素の 'profile' 属性に記述されたプロファイルで定義されているからです。

=== hCard の実例 ===
次にあるのは [http://www.commerce.net/ Commercenet] のコンタクト情報です。この情報は hCard を用いて記述されているので、microformats をパース処理するツールにより見つけることができます。

<div class="vcard">
<div class="fn org">'''CommerceNet'''</div>
<div class="url">'''<nowiki>http://www.commerce.net/</nowiki>'''</div>
<div class="adr">'''Work:'''
<div class="street-address">'''169 University Avenue'''</div>
'''Palo Alto''', '''CA'''  '''94301'''
<div class="country-name">'''USA'''</div>
</div>
<div class="tel">'''Work +1-650-289-4040'''</div>
<div class="tel">'''Fax +1-650-289-4041'''</div>
<div>'''Email <nowiki>info@commerce.net</nowiki>'''</div>
</div>

The mark-up, emboldening omitted for clarity, with the following semantic improvements:
* <code>abbr</code> to expand abbreviations
* hyperlinking the org name with the url

<source lang=html4strict>
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
Work:
<div class="street-address">169 University Avenue</div>
Palo Alto,
<abbr class="region" title="California">CA</abbr>  
94301
<div class="country-name">USA</div>
</div>
<div class="tel">
Work +1-650-289-4040
</div>
<div class="tel">
Fax +1-650-289-4041
</div>
<div>Email:
info@commerce.net
</div>
</div>
</source>

=== その他の例 ===
[[hcard-examples|hCard examples]] には vCard 仕様書 [[rfc-2426|RFC2426]] の例をすべて hCard にしたものをはじめ、もっとたくさんの例があります。

== 実世界での例 ==f
このセクションは'''参考情報'''です。すでに世界には多くの hCard が存在しています。以前はこの仕様書で紹介していましたが、数が増えすぎてしまったため、別のページを用意しました。

[[hcard-examples-in-wild|hCard Examples in the wild]] で、実際に使われている hCard をご覧ください。

== 実装 ==
このセクションは'''参考情報'''です。前のセクションと同じく、hCard の実装についても別のページを用意しています。

[[hcard-implementations|hCard Implementations]] で、hCard の実装についてご覧ください。

== 記事 ==
このセクションは'''参考情報'''です。hCard の他の読み物は[[hcard-articles-ja|hCard の記事]]をご覧ください。

== hCard ボタン ==
hCard を使ったあなたのページに、次にあるボタンを貼り付けましょう。[[buttons#hCard]] には、最近追加されたボタンもあります。

* http://www.crowley.nl/images/hcard.png (ミラー:http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS でボタン風にデザインすることもできます。[http://re-run.com/about/microformat-badges microformat badges @ re-run] をご覧ください。

== 著作権 ==
仕様の作成者である [[User:Tantek|Tantek Çelik]] および [[User:Brian|Brian Suda]] が、自分のページでパブリックドメインの声明を行っています。よって、この仕様はパブリックドメインです。

{{MicroFormatPublicDomainContributionStatement}}

== 特許 ==
{{MicroFormatPatentStatement-ja}}

== 参考文献 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU 勧告 E.123] 電話番号フォーマット (有料)
* [[rfc-2119|RFC 2119]]

=== その他の参考文献 ===
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* [[iso-8601|ISO8601]]

==== hCard を利用する仕様 ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== hCard に似通っているもの ====
このセクションは'''参考情報'''です。
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== 原案及び謝辞 ==
このセクションは'''参考情報'''です。
vCard を "何年も前に" 教えてくれた私の良き友人 [http://vadim.com/ Vadim] に感謝しています。ただ、もしあのときから vCard を気にかけていたら、もっと多くの車輪の再発明を防げたかもしれませんが。

== vCard における由来 ==
このセクションは ''参考情報'' です。

<div id="Semantic_XHTML_Design_Principles">[[hcard-design-methodology]] をご覧ください。</div>

=== 意味的に同等なもの ===
いくつかのプロパティにおいて、その意味を上手く表現できる HTML 要素が存在します。次に挙げるプロパティは、その例に書かれている (X)HTML で表現すべきです ({{should}})。

* vCard の <code>URL</code> は hCard にて <code><a class="url" href="...">...</a></code> と表します。このプロパティは、<code>class="vcard"</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="Photo of ..." /></code>、または <code><object class="photo" data="..." type="...">Photo of ...</object></code> となります。
* vCard の <code>UID</code> hCard において、特定の URL (または EMAIL) といった、別の意味に置き換えられます。

=== 出現回数が一回のプロパティ ===
[[hcard-ja#.E3.83.97.E3.83.AD.E3.83.91.E3.83.86.E3.82.A3.E3.81.AE.E5.87.BA.E7.8F.BE.E5.9B.9E.E6.95.B0|プロパティの出現回数]]は、vCard RFC2426 で定義されるプロパティを一つずつ調べ、そのセマンティクスから一つのみでなければならない ({{must}}) を導き出したものです。[[hcard-singular-properties]] に解説があるので、そちらをご覧ください。

==== 単数化されたプロパティ ====
いくつかの複数系のプロパティ名が単数名化されています。このため、もし元となる複数形のプロパティが、複数のコンポーネントからなるひとつの値を取るものであっても、それらのコンポーネントは、単数名化されたプロパティを複数持つものとなります。

== 関連ページ ==
{{hcard-related-pages}}

[[Category:hCard]]

== 翻訳 ==
* [[hcard|english]]（英語）
* [[hcard-fr|français]]（フランス語）
* [[hcard-ru|Русский]]（ロシア語）
* [[hcard-zh|汉语]]（中国語）

value-class-pattern-ja

2011-03-22T14:43:14Z

KitaitiMakoto: sync: english: 2011-03-22T01:32:18

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
[[hAtom]] を読み込んで Atom を生成するマイクロフォーマット実装は更に以下に従わなければなりません（{{must}}）。
* 日付と日時の値を全て [[RFC3339]] のフォーマットに正規化する

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Is the value-class pattern supported by any of the microformats tools?'''
** '''A: Yes'''. See the [[value-class-pattern#Implementations|implementations]] section.
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** '''A: 'class' is for field names, not data.''' The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** '''A: New attributes are invalid.''' Microformats exist and function in ''valid'' HTML. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''Shouldn't the <code>title</code> attribute should only be used for content?'''
** '''A: 'title' is used for content, machine readable content.''' The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

=== 購読とパース用ツール ===
* [[Google]] parses <code>value-title</code> as part of their [http://googlewebmastercentral.blogspot.com/2010/01/introducing-new-rich-snippets-format.html support for hCalendar rich snippets], as documented specifically in the [https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164506 microformats example for rich snippet events].
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* HTML::Microformats and its predecessors support <code>value</code> excerpting. HTML::Microformats (though not its predecessors) supports <code>value-title</code>.
=== 公開用ツール ===
* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/articles/getting-semantic-with-microformats-part-8-value-class-pattern Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

hrecipe-ja

2011-03-20T11:49:09Z

KitaitiMakoto: sync: english: 2011-03-18T01:07:19

<entry-title>hRecipe-ja</entry-title>
<h1>hRecipe</h1>
{{Template:DraftSpecification-ja}}
{{TOC-right}}

http://www.livingathome.de/test/recipe/hRecipe.png

[[recipe|hRecipe]] はシンプル、オープン、分散されたフォーマットで、(X)HTML、Atom、RSS、そして任意の XML で料理のレシピについての情報を埋め込むのに適しています。hRecipe はオープンスタンダードな [[microformats]] の一つです。このページとマイクロフォーマットは、パブリックドメインです。

== hRecipe Microformat Draft Specification ==

=== 編者 ===
* [[User:ThomasLoertsch | Thomas Loertsch]] ([http://www.essen-und-trinken.de Gruner+Jahr])
=== 作者 ===
* [[User:Phae|Frances Berriman]] (BBC)
* [[User:BenWard|Ben Ward]]
* [[User:TobyInk|Toby Inkster]]

=== 貢献者===
[[User:AndyMabbett|Andy Mabbett]], [[User:Phae|Frances Berriman]], [[User:IamCam|Cameron Perry]], [[User:JohnLeMasney|John LeMasney]], [[User:Tantek|Tantek Çelik]], [[User:SudarshanP|SudarshanP]], [[User:CiaranMc|Ciaran McNulty]], [[User:LeeJordan|Lee Jordan]], [[User:RobertBachmann|Robert Bachmann]], [[User:JeffMcNeill|jeffmcneill]], [[User:ManuSporny|Manu Sporny]], [[User:RyanKing|Ryan King]], HollyMarieKoltz, Straup, [[User:ChristopheDucamp|Christophe Ducamp]], Mercman, [[User:Yde|Yde]], [[User:AmeerDawood|Ameer Dawood]], Scottk, [[User:Lee_Jordan|Lee Jordan]], MonroAlmon, EstevaoSamuel, [[User:Brian|Brian Suda]], SteveL, JohnLeMasney,

Microformats [[#Copyright]] and [[#Patents]] statements apply.

== 概要 ==

マイクロフォーマットの hRecipe は食事や飲み物、食材の調理方法をマークアップするためにデザインされています。

ブラウザがウェブページに記述されているレシピについての意味的な情報を抽出するのは困難です。メタデータはレシピの著者やレシピ名と材料、調理方法、調理時間についての詳細など、レシピに関係する情報を提供します。

そのような情報をマークアップしておくことで閲覧者にいくらかの有益な情報を提供することができます。もしウェブブラウザがそれぞれのウェブページに含まれるレシピに関する固有の意味を理解できれば、豊かな相互作用を生み出すことができます。例えば、特定の検索は材料や著者のために Google や Wikipedia などの一般的な検索サービスで実行されるかもしれません。さらにクローラによる分類は、より正確になることができます。1ページで見つけられたレシピが20ほどあって、ある材料を含んでいるなら、そのページが料理だけではなく、その特定の材料についてのページと仮定することができます。

レシピの集約とシンジケーションおよび流通と共有と促進を可能にするために、作者はレシピのメタデータを分類するオープンスタンダードな hRecipe マイクロフォーマットを提案します。作者は [[recipe-formats]] についてのワイルドで初期の試みにおいて多数の [[recipe-examples]] を研究し、レシピコンテンツのためにシンプルで小さいスキーマである hRecipe を設計しました。フィードバックは [[recipe-feedback|hRecipe feedback]] ページでお願いします。

=== インスピレーションと謝辞 ===

研究成果やアイデアを提案したり、hRecipe-format やレシピに関係した議論をおこなった様々な人達に感謝しています。

=== 範囲 ===

hRecipe は食物と食事の準備ための説明と材料リストに注釈を付けるフォーマットです。レシピは常にいくつもの共通したプロパティを共有します。hRecipe は最小限の一般的なサブセットをベースにしています。

=== 範囲外 ===

人間が食べることのできないレシピは hRecipe の範囲外です。

== 書式 ==

{{rfc-2119-intro-ja}}

=== 通例 ===

hRecipe フォーマットは多くのレシピサイトで使われている一般的なプロパティのセットと、今日のウェブで使われているフォーマットをベースにしています。プロパティ名は関連する microformat standards で定義済みのものがベースに選ばれました。 
いくつかのプロパティはレシピを説明するのに必要な最小限のセットを上回る''実験的''な記述ですが、ウェブでは一般的に利用されています。それらが（ hRecipe ）フォーマットに含まれるのに十分関連するプロパティかどうかは、わかりません。これらのプロパティの実装と導入は観察され、さらに決定されて提供されるでしょう。それらのプロパティは非推奨ではありません。しかし最終的な仕様から削除される可能があるので注意して使用してください。

=== スキーマ ===
hRecipe スキーマは以下のプロパティで構成されます:

* '''hrecipe'''
** '''fn'''. 必須。テキスト。レシピの名前。
** '''ingredient'''. 必須。1つ又はそれ以上の任意の妥当な (x)HTML でマークアップされたテキスト。
*** '''''value''''' and '''''type'''''. 任意。（実験的）
** '''''yield'''''.任意。テキスト。
** '''''instructions'''''. 任意。任意の妥当な (x)HTML でマークアップされたテキスト。
** '''''duration'''''. 任意。1つ又はそれ以上のテキスト。
** ''photo''. 任意。1つ又はそれ以上。画像のような任意の要素を含んだ URLを使用。（実験的）
** ''summary''. 任意。テキスト。（実験的）
** ''author''. 任意。1つ又はそれ以上（実験的）
** ''published''. 任意。（実験的）
** ''nutrition''. 任意。1つ又はそれ以上（実験的）
*** ''value'' and ''type''. 任意。（実験的）
** ''tag''. 任意。1つ又はそれ以上（実験的）

=== プロパティの詳細 ===

<code>fn</code>, <code>photo</code>, <code>author</code>, <code>value</code> と <code>type</code> のプロパティは [[hcard-ja|hCard]] に従います。<code>duration</code> のプロパティは [[hAudio]] に従います。<code>summary</code> のプロパティは [[hcalendar-ja|hCalendar]] に従います。<code>published</code> のプロパティは [[hAtom]] に従います。<code>tag</code> のプロパティは [[rel-tag-ja|rel-tag]] に従います。

hRecipe スキーマのフィールドは次のように表します：

==== hRecipe ====

hRecipe はレシピの識別や値の記述、メタデータの関連付けに用いられます。　

* hRecipe プロパティは <code>hrecipe</code> 名で識別されます。

==== fn ====

1つのレシピのタイトルです。概要は短いテキストで構成され関連性のあるグループ間を識別するのに使用されます。これは、食事や食材の名前に簡単な説明をします。

* プロパティは <code>fn</code> で識別されます。
* レシピは <code>fn</code> が必須です。
* プロパティは [[hCard]] のルールに従う必要があります。例）プレーンテキストのみ使用

==== ingredient ====

レシピに使われているひとつまたは複数の材料を記述します。

* プロパティは <code>ingredient</code> で識別されます。
* レシピにはひとつまたは複数の <code>ingredient</code>s を含む必要があります。
* プロパティには（材料のリストなどを）妥当な HTML マークアップで含むことができます。
* プロパティは hCard の規則に従った <code>value</code> (値)と <code>type</code> (型)を含むことができます。<source lang=html4strict>125ml milk</source>この場合、それぞれの材料は <code>ingredient</code> プロパティに含むかたちでマークアップしなければなりません。これらのサブプロパティは実験的で最終的な仕様から削除される可能性か、[[measure|分量]]から"数値(num)”と"単位(unit)"に置き換えられます。

==== yield ====

このレシピで何人分の分量または数量（個数）を指定します。

* プロパティは <code>yield</code> で識別されます。
* レシピは <code>yield</code> を含むことができます。

==== instructions ====

レシピの方法手順。

* プロパティは <code>instructions</code> で識別されます。
* レシピは <code>instructions</code> を含むことができます。
* プロパティは妥当な HTML でマークアップされた文章や手順のリストを含むことができます。

==== duration ====

調理に必要な時間を記述します。例えば生地を準備するための時間、生地の発酵に必要な時間、生地を焼く時間、ケーキ等を飾る時間など、複数の調理時間のプロパティを示すために使用することができます。

* プロパティは <code>duration</code> で識別されます。
* レシピは、ひとつもしくは複数の <code>duration</code> プロパティを含めることができます。
* プロパティは [[value-class-pattern|value-class-pattern]] で略述した期間をコード化してください。調理時間が1時間30分の場合、ISO 8601 形式の"PT1H30M"に変換し、以下のようにコード化することができます：<source lang=html4strict> 90 min</source>

==== photo ====

添付写真

* プロパティは、<code>photo</code> で識別されます。
* レシピは、ひとつもしくは複数の <code>photo</code> プロパティを含めることができます。
* プロパティは、img 要素を使用してください。a 要素や object 要素など URL を含んだ他の要素を使用することができますが、推奨されていません。[[hRecipe#Semantic_XHTML_Design_Principles|注釈]]を参照してください。
* プロパティは、実験的で最終的な仕様から削除される可能性があります。

==== summary ====

概要はレシピに関する短い紹介または付帯事項を提供します。

* プロパティは <code>summary</code> で識別されます。
* レシピは <code>summary</code> を含むことができます。
* プロパティは [[hCalendar]] のルールに従う必要があります。プレーンテキストはこれらの要件を満たします。
* プロパティは実験的で最終的な仕様から削除される可能性があります。

==== author ====

著者は、レシピを書いた人です。

* プロパティは <code>author</code> で識別されます。
* レシピは、ひとつもしくは複数の <code>author</code> プロパティを含めることができます。
* 要素の内容は "vcard fn" 標準のプレーンテキスト文字列が利用されます。何よりも [[hCard]] の仕様に従わなければなりません。
* プロパティは、実験的で最終的な仕様から削除される可能性があります。

==== published ====

レシピが公開された日付。

* プロパティは <code>published</code> で識別されます。
* レシピは <code>published</code> を含むことができます。
* プロパティは [[value-class-pattern|value-class-pattern]] を使用してエンコードされます：<source lang=html4strict>Published 14. Oct 2008</source>
* プロパティは、''実験的''で最終的な仕様から削除される可能性があります。

==== nutrition ====

カロリーや脂肪、食物繊維など栄養分情報

* プロパティは <code>nutrition</code> で識別されます。
* レシピは、ひとつもしくは複数の <code>nutrition</code> プロパティを含めることができます。
* プロパティは [[hCard]] の規則に従った <code>value</code> (値)と <code>type</code> (型)を含むことができます。この場合、それぞれの栄養分情報の項目は <code>nutrition</code> プロパティに含むかたちでマークアップしなければなりません。これらのサブエレメントは実験的で最終的な仕様から削除される可能性か、[[measure|分量]]から"数値(num)”と"単位(unit)"に置き換えられます。
* <code>nutrition</code> は、''実験的''で最終的な仕様から削除される可能性があります。

==== tag ====

主成分や食事の種類などレシピのテーマや重要な面などキーワードに示します。

* プロパティは <code>tag</code> で識別されます。
* レシピは、ひとつもしくは複数の <code>tag</code> プロパティを含めることができます。
* プロパティは [[rel-tag]] のルールに従う必要があります。
* プロパティは、''実験的''で最終的な仕様から削除される可能性があります。

=== Version history ===

* Version 0.22 changed the proposed formatting of time and date from the [[datetime-design-pattern|datetime-design-pattern]], which has [[datetime-design-pattern#Accessibility_issues|accessibility issues]], to the [[value-class-pattern|value-class-pattern]]. Also corrected some errors in the example especially with regard to the correct handling of vcard properties.
* Version 0.21 changed the status of ingredient/value and ingredient/type to ''experimental'', mentioning that there still is discussion if they should be replaced by 'num' and 'unit' from [[measure]] (which is still in brainstorming).
* Version 0.2: From [http://microformats.org/wiki/index.php?title=hrecipe&oldid=37357 Version 0.1] some elements have been renamed to strenghten re-use of established elements: '''fn''' for '''hRecipe-title''', '''summary''' for '''hRecipe-summary''', '''duration''' for '''preparation-time''', '''value''' and '''type''' for '''num''' and '''unit'''. Also some elements have been marked '''experimental''' because of concerns of element bloat. See the [[hrecipe-issues]] page for a more thorough discussion. Draft 0.1 was already a result of long lasting efforts. Nonetheless after publishing of it there has been a lively debate about some properties. Since they mostly could be resolved version 0.2 is considered fairly stable now, although of course you never know ;-)

=== Parser Processing Notes ===

* もし" author "プロパティがプレーンテキストのみ含んでいるならば、" vcard fn "形式と見なすべきです。

=== Semantic XHTML Design Principles ===

{{semantic-xhtml-design-principles-ja}}

==== More Semantic Equivalents ====

いくつかのプロパティはよりセマンティックな同義な語で、したがってそれらは例のように特別な処理をできます：

* For "photo", use <code><img class="photo" src="..." alt="" /></code>

==== Language ====

* 自然言語で書かれているレシピを明確に伝えるなら、標準的な (X)HTMLで class="hrecipe" の要素に 'lang' または 'xml:lang' 属性を付加してください。
**例：<code><nowiki>I like Kartoffelknödel best.</nowiki></code>
* もし hRecipe (例えば材料の名前)の一部が異なる言語であるなら、その箇所に 'lang' または 'xml:lang' 属性で言語を指定してください。
* hRecipe が書かれている自国語を取り扱う必要がある hRecipe パーサーは特定の標準的な (X)HTML 'lang' または 'xml:lang' 属性で処理しなければなりません。
* 他のいかなる言語も hRecipe の上で指定されてなく、自国語を取り扱う必要がある hRecipe パーサーはページ内の自国語を発見し、それを hRecipe に適用するために DOM ツリーを横断するかもしれません。

==== Human vs. Machine Readable ====

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

もし <code><a></code> 要素がひとつまたは複数のプロパティに用いられている場合、次のように処理される必要があります (must)：
# 'photo' プロパティと、他に URL を取るすべてのプロパティでは、<code>href="..."</code> 属性の値がプロパティの値となります。
# その他のプロパティでは、要素の内容がプロパティの値となります。

もし <code><img></code> 要素を 'photo' プロパティに用いる場合、<code>src="..."</code> 属性の値をプロパティの値として使用する必要があります (must)。

もし <code><object></code> 要素を 'photo' プロパティに用いる場合、<code>data="..."</code> 属性の値をプロパティの値として使用する必要があります (must)。

=== Notes ===

このセクションは参考です。

*Non so far.

== XMDP Profile ==

<source lang=html4strict>
<dl class="profile">
<dt>class</dt>
<dd>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>
<dt>hrecipe</dt>
<dd>
Used to identify and describe metadata associated with instructions for creating meals, drinks or food-based items.
</dd>
<dt>fn</dt>
<dd>
The title of the recipe.
</dd>
<dt>ingredient</dt>
<dd>
Describes the ingredient(s) used in the recipe.
</dd>
<dt>yield</dt>
<dd>
Specifies the quantity produced by the recipe.
</dd>
<dt>instructions</dt>
<dd>
The method of the recipe.
</dd>
<dt>duration</dt>
<dd>
The time it takes to prepare the meal described by the recipe.
</dd>
<dt>photo</dt>
<dd>
Accompanying image.
</dd>
<dt>summary</dt>
<dd>
The summary provides a short introduction or an accompanying statement about the recipe.
</dd>
<dt>author</dt>
<dd>
The person who authored the recipe..
</dd>
<dt>published</dt>
<dd>
The date that the recipe was made available to the public.
</dd>
<dt>nutrition</dt>
<dd>
Nutritional information like calories, fat, dietary fiber etc.
</dd>
<dt>tag</dt>
<dd>
Keyword(s) describing the recipe.
</dd>
</dl>
</dd>
</dl>
</source>

== Examples ==

このセクションは参考です。

ここでは実際のウェブサイトからにあるレシピの情報を、簡単に hRecipe として使うことができるいくつかの例がいくつかあります（will be）。差し当たり、以下のように不自然な例である必要があります。

<source lang=html4strict><div class="hrecipe">
<h1 class="fn">Pommes Frites</h1>

Pommes frites originate in outer space. They are served hot. 
This recipe is only an example. Don't try this at home!


Contributed by CJ Tom and the
<a class="url fn" href="http://example.com">Cooky Gang</a>.

Published 14. Oct 2008
<img src="/img/pommes.png" class="photo" width="100" height="100" alt="Pommes Frites"/>
<h2>Ingredients</h2>
<ul>
<li class="ingredient">
500
gramme potatoes, hard cooking.
</li>
<li class="ingredient">
1 spoonful of salt
</li>
<li>
You may want to provide some
Ketchup and Mayonnaise
as well.
</li>
</ul>
<h2>Instructions</h2>
<ul class="instructions">
<li>First wash the potatoes.</li>
<li>Then slice and dice them and put them in boiling fat.</li>
<li>After a few minutes take them out again.</li>
</ul>
<h2>Further details</h2>
Enough for 12 children.
Preparation time is approximately
 90 min

Add half an hour to prepare your homemade Ketchup.
This recipe is <a href="http://www.example.com/tags/difficulty/easy" rel="tag">easy</a> and <a href="http://www.example.com/tags/tastyness/delicious" rel="tag">delicious</a>.


Pommes Frites have more than
1000
Joule
Energy,
while Ketchup and Mayonnaise have
0 vitamins.

</div>
</source>


== 実装例 ==

このセクションは'''参考情報'''です。

hRecipe が利用されているサイトやページです。リストが大きくなったら、[[hrecipe-examples-in-wild]] といった別のページにて紹介する予定です。

* [http://www.epicurious.com/ Epicurious.com]'s [http://www.epicurious.com/recipesmenus/ recipes] have been marked up with hRecipe as of April 2010. (E.g., [http://www.epicurious.com/recipes/food/views/Chocolate-Almond-and-Banana-Parfaits-357369 Chocolate, Almond, and Banana Parfaits])
* [http://www.williams-sonoma.com/ Williams-Sonoma]'s [http://www.williams-sonoma.com/recipe/ recipes section], e.g. [http://www.williams-sonoma.com/recipe/cherry-almond-bundt-cake.html Cherry Almond Bundt Cake]
* http://foodnetwork.com/ has marked up all their recipes with hRecipe as of 2009-10, e.g. [http://www.foodnetwork.com/recipes/ina-garten/deep-dish-apple-pie-recipe2/index.html Deep-Dish Apple Pie recipe]
* [http://www.plantoeat.com/ Plan to Eat]'s [http://www.plantoeat.com/recipe_book recipe planner] is now in hRecipe format as of April 2010. (E.g., [http://www.plantoeat.com/recipes/4583/1fv1A5vFhjm Pasta With Smashed Peas])
* essen & trinken. As of spring 2009 [http://www.essen-und-trinken.de essen & trinken] publishes all recipes with hRecipe-conformant metadata encoded in RDF. See [[hrecipe-rdf]] for technical details.
* It's Ripe! As of January 2009, [http://itsripe.com/recipes/ http://itsripe.com] supports hRecipe for recipe pages and will soon add support in lists.
* [http://recipe.gnavi.co.jp/ ぐるなびレシピ] レシピ詳細ページで hRecipe をサポート。ただし全レシピ詳細ページに hRecipe はサポートしていない。
*'''Wild Mushroom, Pancetta & Truffle Risotto''' by Toby Inkster
** [http://tobyinkster.co.uk/blog/2008/10/23/mushroom-risotto/ Marked up as hRecipe] using the September 2007 draft format
** [http://srv.buzzword.org.uk/recipebook/tobyinkster.co.uk/blog/2008/10/23/mushroom-risotto/ RecipeBook XML] output from Cognition.
** [http://srv.buzzword.org.uk/rdf-xml/tobyinkster.co.uk/blog/2008/10/23/mushroom-risotto/ RDF/XML] and [http://srv.buzzword.org.uk/turtle/tobyinkster.co.uk/blog/2008/10/23/mushroom-risotto/ Turtle] output from Cognition.

== Implementations ==
このセクションは'''参考情報'''です。

hRecipe の生成や処理できるツールです。リストが大きくなったら、[[hrecipe-implementations]] といった別のページにて紹介する予定です。

* Cognition. As of September 2008, [http://buzzword.org.uk/cognition/ Cognition] has experimental support for this format. ([http://buzzword.org.uk/cognition/uf-plus.html#hrecipe Details of support].) Recipes may be exported in [[recipe-formats#RecipeBook_XML|RecipeBook XML]] format or RDF.
* WordPress Plugin. There's a [http://wordpress.org/ WordPress ] [http://wordpress.org/extend/plugins/hrecipe/ hRecipe Plugin] available which makes adding hRecipe metadata to recipes very easy, practically effortless. Very nice!
* hRecipeHelper. Released 16th March, 2011 [https://chrome.google.com/webstore/detail/cgpnljccbfcjhhekfnikhpllfjpjidlj hRecipeHelper] A Chrome Extension for building hRecipe formatted HTML for blogging or websites.

== 参考文献 ==

=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard|hCard]]
* [[abbr-design-pattern]]
* [[datetime-design-pattern]]

=== その他の参考文献 ===
* [http://www.w3.org/TR/REC-CSS1 CSS1]
* ISO.8601.1988
** International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
* [http://www.w3.org/TR/1998/NOTE-datetime-19980827 W3C NOTE-datetime-19980827]
* [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy]
* Other recipe metadata efforts. See [[recipe-formats]].
* [[grouping-examples]]
* [[grouping-brainstorming]]
* [[xoxo|XOXO]]

=== コピーライト ===

著者によって2008年11月14日に [[Microformats_Wiki:Copyrights]] を通じ、hRecipe はパブリックドメインになりました。使用、配布、再版またはいかなる種類の他の制限も、この仕様のテキストまたは内容に関して含まれていません。

== 特許 ==
{{MicroFormatPatentStatement-ja}}

=== Public Domain Release ===

このページの著者と編集者はドキュメント上の著作権を放棄することによって　パブリックドメインでこのページの文書を公開しています。

* [[User:Phae|Frances Berriman]] (BBC)
* [[User:BenWard|Ben Ward]]
* [[User:TobyInk|Toby Inkster]]
* [[User:ThomasLoertsch | Thomas Loertsch]] ([http://www.essen-und-trinken.de Gruner+Jahr])

== 進行中の仕様 ==
この仕様は現在進行中です。更なる特徴が議論され、理解され、書かれた時には追加されるでしょう。

== derivative works ==
* [[hrecipe-rdf|hRecipe in RDF]] - mapping of hRecipe into a RDF vocabulary called "aRecipe"

==related pages==
* [[hrecipe-issues|hRecipe issues]] - issues regarding the hRecipe draft
* [[hrecipe-feedback|hRecipe feedback]] - general feedback regarding hRecipe

Per the microformats [[process]], the [[recipe]] effort developed
* [[recipe-examples]]
* [[recipe-formats]]
* [[recipe-brainstorming]] (see also [[recipe-brainstorming-archive]])
* [[recipe-issues]]
towards the development of this draft.

[[Category:Draft Specifications]]

value-class-pattern-ja

2011-03-02T17:07:02Z

KitaitiMakoto: sync: english: 2011-02-26T01:24:55

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
[[hAtom]] を読み込んで Atom を生成するマイクロフォーマット実装は更に以下に従わなければなりません（{{must}}）。
* 日付と日時の値を全て [[RFC3339]] のフォーマットに正規化する

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Is the value-class pattern supported by any of the microformats tools?'''
** '''A: Yes'''. See the [[value-class-pattern#Implementations|implementations]] section.
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** '''A: 'class' is for field names, not data.''' The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** '''A: New attributes are invalid.''' Microformats exist and function in ''valid'' HTML. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''Shouldn't the <code>title</code> attribute should only be used for content?'''
** '''A: 'title' is used for content, machine readable content.''' The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

=== 購読とパース用ツール ===
* [[Google]] parses <code>value-title</code> as part of their [http://googlewebmastercentral.blogspot.com/2010/01/introducing-new-rich-snippets-format.html support for hCalendar rich snippets], as documented specifically in the [https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164506 microformats example for rich snippet events].
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* HTML::Microformats and its predecessors support <code>value</code> excerpting. HTML::Microformats (though not its predecessors) supports <code>value-title</code>.
=== 公開用ツール ===
* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

value-class-pattern-ja

2011-02-23T12:46:59Z

KitaitiMakoto: unified the translation of 'parse'

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
[[hAtom]] を読み込んで Atom を生成するマイクロフォーマット実装は更に以下に従わなければなりません（{{must}}）。
* 日付と日時の値を全て [[RFC3339]] のフォーマットに正規化する

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Is the value-class pattern supported by any of the microformats tools?'''
** '''A: Yes'''. See the [[value-class-pattern#Implementations|implementations]] section.
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** '''A: 'class' is for field names, not data.''' The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** '''A: New attributes are invalid.''' Microformats exist and function in ''valid'' HTML. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''Shouldn't the <code>title</code> attribute should only be used for content?'''
** '''A: 'title' is used for content, machine readable content.''' The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

=== 購読とパース用ツール ===
* [[Google]] parses <code>value-title</code> as part of their [http://googlewebmastercentral.blogspot.com/2010/01/introducing-new-rich-snippets-format.html support for hCalendar rich snippets], as documented specifically in the [https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164506 microformats example for rich snippet events].
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
=== 公開用ツール ===
* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

value-class-pattern-ja

2011-02-23T12:42:00Z

KitaitiMakoto: sync: english: 2011-02-22T05:24:46

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
[[hAtom]] を読み込んで Atom を生成するマイクロフォーマット実装は更に以下に従わなければなりません（{{must}}）。
* 日付と日時の値を全て [[RFC3339]] のフォーマットに正規化する

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Is the value-class pattern supported by any of the microformats tools?'''
** '''A: Yes'''. See the [[value-class-pattern#Implementations|implementations]] section.
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** '''A: 'class' is for field names, not data.''' The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** '''A: New attributes are invalid.''' Microformats exist and function in ''valid'' HTML. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''Shouldn't the <code>title</code> attribute should only be used for content?'''
** '''A: 'title' is used for content, machine readable content.''' The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

=== 購読と解析用ツール ===
* [[Google]] parses <code>value-title</code> as part of their [http://googlewebmastercentral.blogspot.com/2010/01/introducing-new-rich-snippets-format.html support for hCalendar rich snippets], as documented specifically in the [https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164506 microformats example for rich snippet events].
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
=== 公開用ツール ===
* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

hcard-ja

2011-02-03T16:06:44Z

KitaitiMakoto: sync: english: 2011-02-03T00:35:05

<entry-title>hCard 1.0</entry-title>


<dfn style="font-style:normal;font-weight:bold">hCard</dfn> は、vCard ([[rfc-2426|RFC2426]]) のプロパティと値を利用して、[[semantic-xhtml|HTML]] で人や会社、組織や場所を表現する [[microformats-ja|microformat]] です。hCard は HTML や XHTML はもちろんのこと、Atom、RSS、その他の XML に埋め込むことができます。

'''hCard を利用するには、いくつかの方法があります。'''
*[http://blog.livedoor.jp/forestk/misc/microformats/hCard/creator-ja/ hCard creator] hCard を利用し、作成したコードをページにはりつける。
*[[hcard-authoring|hCard authoring tips]] を読んで、hCard のマークアップを行う。

<div class="vcard">
; 編集者
: [[User:Tantek|Tantek Çelik]] (http://tantek.com/, and before at [http://technorati.com Technorati, Inc.], and at [http://microsoft.com/ Microsoft Corporation])
</div>
; 作者: [http://tantek.com/ Tantek Çelik] (affiliations above)
: [[User:Brian|Brian Suda]] (http://suda.co.uk/)

; 謝辞: [[hcard-ja#原案及び謝辞|謝辞のセクション]]をご覧ください。

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

== 状態 ==
hCard 1.0 is a microformats.org specification. Public discussion on hCard takes place on [[hcard-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== 利用できる言語 ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== 訂正事項と更新事項 ===
Known errors and issues in this specification are corrected in [[hcard-issues-resolved|resolved]] and [[hcard-issues-closed|closed]] issues. Please check there before reporting [[hcard-issues|issues]].

The hCard 1.0.1 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

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

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

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

{{rfc-2119-intro-ja}}

== フォーマット ==
=== 基本情報 ===
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) のプロパティ名や値が、hCard の基礎となります。

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

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

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

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

'''必須プロパティ'''
* '''fn'''
* '''n'''[[#note1|1]] (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)

任意プロパティ
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value)
* agent
* bday
* category
* class
* email (type, value)
* geo (latitude, longitude)
* key
* label
* logo
* mailer
* nickname
* note
* org (organization-name, organization-unit)
* photo
* rev
* role
* sort-string
* sound
* tel[[#note2|2]] (type, value)
* title
* tz
* uid
* url

=== プロパティについて ===
[[#property-list-n|1. ^]]: 'n' プロパティは、[[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]にあるルールに当てはまる場合は、任意 ({{optional}}) プロパティとなります。 
[[#property-list-tel|2. ^]]: tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することができます ({{may}})。文字の入った電話番号 (例: +1-555-FORMATS) は、数字で表記しなければなりません ({{must}})。<code>abbr</code> を利用して、ソフトウェアには数字から成る電話番号の方を伝えることもできます (<code><nowiki><abbr title="+15553676287">+1-555-FORMATS</abbr></nowiki></code>)。

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

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

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

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

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

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

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

=== 値の抜粋 ===
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合は特別な class 名である "<code>value</code>" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップする hCard を例に取り説明しましょう。 

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>

home:
+1.415.555.1212

</source>

この hCard は次のように表示されるでしょう。

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

home:
+1.415.555.1212

</div>



=== プロパティの例外 ===
vCard には、Web ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。

# vCard の '''NAME'''、'''PROFILE'''、'''SOURCE'''、'''PRODID'''、'''VERSION''' プロパティは [[rfc-2426|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 文書の場合、<code><title></code> 要素) を用いることが推奨されます ({{should}})。PROFILE の値には、[[rfc-2426|RFC2426]] より "<code>VCARD</code>" の値を使うことができます ({{may}})。SOURCE プロパティには、ページの URL を用いることが推奨されます ({{should}})。hCard を vCard に変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODID プロパティは、実際に vCard を出力するサービスやアプリケーションのみが記述するべきです ({{should}})。同様に、そのようなアプリケーションのみが、[[rfc-2426|RFC2426]] のセクション 3.6.9 に倣い、VERSION プロパティに "3.0" という値をつけるべきです ({{should}})。

=== 組織のコンタクト情報 ===
もし、"FN" と "ORG"（organization；組織）プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、その hCard は会社や組織、場所のコンタクト情報を表すものとみなされます ({{should}})。このとき、作成者は "N" プロパティを記述することはできない ({{must-not}})、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます ({{should}})。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。

=== "N" の推測処理 ===
vCard では "N" プロパティの記述が必須となっています。ところが vCard 仕様書 ([[rfc-2426|RFC2426]]) では、最後の方 (p.38) にある作者の vCard に "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCard では次のように規定します。

もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります ({{must}})。しかし、組織名の場合はこのルールに当てはまりません。この場合は[[hcard-ja#.E7.B5.84.E7.B9.94.E3.81.AE.E3.82.B3.E3.83.B3.E3.82.BF.E3.82.AF.E3.83.88.E6.83.85.E5.A0.B1|組織のコンタクト情報]]で書かれているルールが適用されます。

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

これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。
* given-name (スペース) family-name
* family-name (コンマ) given-name
* family-name (コンマ) given-name のイニシャル
* family-name (スペース) given-name のイニシャル (任意のピリオド)

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語で名前を記述するときには、この推測処理を利用することはできません。必ず given-name、family-name プロパティを利用し、明示的に名前を記述しなければなりません。

<pre><nowiki>
<div class="vcard">

マイクロ
太郎

</div>
</nowiki></pre>
</div>

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

"nickname" の推測機構は [[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。

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

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

<source lang=html4strict>

daveman692

</source>

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

=== "organization-name" の推測処理 ===
"ORG" プロパティは organization-name と organization-unit という二つのサブプロパティを持っています。しかしほとんどの場合、作成者は organization-name のみを記述します。よって、もし "ORG" プロパティが "organization-name" プロパティを内側に持たない場合、"ORG" プロパティの内容は必ず "organization-name" とみなされます ({{must}})。

=== カテゴリーとしてのタグ ===
hCard のカテゴリーは [[rel-tag]] を用い、タグとして表現することも可能です ({{may}})。"category" プロパティが rel-tag である場合、そのタグはカテゴリーとして扱われます。

=== 'type' サブプロパティの値 ===
'type' サブプロパティがとる値は、その親プロパティによって異なります。これらの 'type' サブプロパティの値は大文字小文字を区別しません (case-INSENSITIVE)。よって "Home" は "home" と同じであり、その他の値と組み合わせた場合についても同様です。たとえば、家の電話番号で、かつ優先番号であるものは次のようになります。

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
Home (preferred):
+1.415.555.1212

</source>

この例は次のように表示されるでしょう。

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
Home (preferred):
+1.415.555.1212

</div>

==== type with unspecified value ====
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.

<source lang=html4strict>
Home +1.415.555.1212
</source>

is equivalent to:

<source lang=html4strict>
Home +1.415.555.1212
</source>

And thus the type is "home" and the value is "+1.415.555.1212".

==== adr tel email types ====
次のリストは ''参考情報'' です。

規範的な type の値は [[rfc-2426|RFC2426]] のセクション 3.2.1 ADR、3.3.1 TEL、3.3.2 EMAIL を参照してください (ここでは利便性の為にコピーしています)。type サブプロパティのデフォルト値はリストの最初に並んでおり、また大文字で記述されています。また、これらの type は複数指定することができます。

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref, "IANA に登録された他のアドレスタイプ"

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語などの言語では、これらサブプロパティの多くを利用することができません。サブタイプはマークアップの制限上、その内容を訳すことができないからです。
</div>

=== プロファイル ===
hCard の XMDP プロファイル は http://microformats.org/profile/hcard にあります。

hCard を使うコンテンツは、
<source lang=html4strict>
<link rel="profile" href="http://microformats.org/profile/hcard">
</source>
や
<source lang=html4strict>
このコンテンツは <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a> を使っています。
</source>
又は
<source lang=html4strict>
<head rel="profile" href="http://microformats.org/profile/hcard">
</source>
などとしてこのプロファイルに触れるべきです（{{should}}）。
（profile 属性は HTML5 で廃止予定です）
なお、上にある方法を組み合わせてもかまいません。

=== パース処理 ===
[[hcard-parsing|hCard parsing]] をご覧ください。

== hCard の例 ==
このセクションは参考情報です。

=== vCard のサンプル ===
次にあるのは vCard のサンプルです。
<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
END:VCARD
</nowiki></pre>

この vCard を hCard で表現すると次のようになります。なお、推測処理ができるプロパティについては省略してあります。他の例は [[hcard-example1-steps| hCard Example 1]] をご覧ください。

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

この hCard は次のように表示されるでしょう。
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]
</div>

Note: hCard のマークアップにはバージョン情報が必要ありません。なぜならバージョンは <head> 要素の 'profile' 属性に記述されたプロファイルで定義されているからです。

=== hCard の実例 ===
次にあるのは [http://www.commerce.net/ Commercenet] のコンタクト情報です。この情報は hCard を用いて記述されているので、microformats をパース処理するツールにより見つけることができます。

<div class="vcard">
<div class="fn org">'''CommerceNet'''</div>
<div class="url">'''<nowiki>http://www.commerce.net/</nowiki>'''</div>
<div class="adr">'''Work:'''
<div class="street-address">'''169 University Avenue'''</div>
'''Palo Alto''', '''CA'''  '''94301'''
<div class="country-name">'''USA'''</div>
</div>
<div class="tel">'''Work +1-650-289-4040'''</div>
<div class="tel">'''Fax +1-650-289-4041'''</div>
<div>'''Email <nowiki>info@commerce.net</nowiki>'''</div>
</div>

The mark-up, emboldening omitted for clarity, with the following semantic improvements:
* <code>abbr</code> to expand abbreviations
* hyperlinking the org name with the url

<source lang=html4strict>
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
Work:
<div class="street-address">169 University Avenue</div>
Palo Alto,
<abbr class="region" title="California">CA</abbr>  
94301
<div class="country-name">USA</div>
</div>
<div class="tel">
Work +1-650-289-4040
</div>
<div class="tel">
Fax +1-650-289-4041
</div>
<div>Email:
info@commerce.net
</div>
</div>
</source>

=== その他の例 ===
[[hcard-examples|hCard examples]] には vCard 仕様書 [[rfc-2426|RFC2426]] の例をすべて hCard にしたものをはじめ、もっとたくさんの例があります。

== 実世界での例 ==f
このセクションは'''参考情報'''です。すでに世界には多くの hCard が存在しています。以前はこの仕様書で紹介していましたが、数が増えすぎてしまったため、別のページを用意しました。

[[hcard-examples-in-wild|hCard Examples in the wild]] で、実際に使われている hCard をご覧ください。

== 実装 ==
このセクションは'''参考情報'''です。前のセクションと同じく、hCard の実装についても別のページを用意しています。

[[hcard-implementations|hCard Implementations]] で、hCard の実装についてご覧ください。

== 記事 ==
このセクションは'''参考情報'''です。hCard の他の読み物は[[hcard-articles-ja|hCard の記事]]をご覧ください。

== hCard ボタン ==
hCard を使ったあなたのページに、次にあるボタンを貼り付けましょう。[[buttons#hCard]] には、最近追加されたボタンもあります。

* http://www.crowley.nl/images/hcard.png (ミラー:http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS でボタン風にデザインすることもできます。[http://re-run.com/about/microformat-badges microformat badges @ re-run] をご覧ください。

== 著作権 ==
仕様の作成者である [[User:Tantek|Tantek Çelik]] および [[User:Brian|Brian Suda]] が、自分のページでパブリックドメインの声明を行っています。よって、この仕様はパブリックドメインです。

{{MicroFormatPublicDomainContributionStatement}}

== 特許 ==
{{MicroFormatPatentStatement-ja}}

== 参考文献 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU 勧告 E.123] 電話番号フォーマット (有料)
* [[rfc-2119|RFC 2119]]

=== その他の参考文献 ===
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* [[iso-8601|ISO8601]]

==== hCard を利用する仕様 ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== hCard に似通っているもの ====
このセクションは'''参考情報'''です。
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== 原案及び謝辞 ==
このセクションは'''参考情報'''です。
vCard を "何年も前に" 教えてくれた私の良き友人 [http://vadim.com/ Vadim] に感謝しています。ただ、もしあのときから vCard を気にかけていたら、もっと多くの車輪の再発明を防げたかもしれませんが。

== vCard における由来 ==
このセクションは ''参考情報'' です。

<div id="Semantic_XHTML_Design_Principles">[[hcard-design-methodology]] をご覧ください。</div>

=== 意味的に同等なもの ===
いくつかのプロパティにおいて、その意味を上手く表現できる HTML 要素が存在します。次に挙げるプロパティは、その例に書かれている (X)HTML で表現すべきです ({{should}})。

* vCard の <code>URL</code> は hCard にて <code><a class="url" href="...">...</a></code> と表します。このプロパティは、<code>class="vcard"</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="Photo of ..." /></code>、または <code><object class="photo" data="..." type="...">Photo of ...</object></code> となります。
* vCard の <code>UID</code> hCard において、特定の URL (または EMAIL) といった、別の意味に置き換えられます。

=== 出現回数が一回のプロパティ ===
[[hcard-ja#.E3.83.97.E3.83.AD.E3.83.91.E3.83.86.E3.82.A3.E3.81.AE.E5.87.BA.E7.8F.BE.E5.9B.9E.E6.95.B0|プロパティの出現回数]]は、vCard RFC2426 で定義されるプロパティを一つずつ調べ、そのセマンティクスから一つのみでなければならない ({{must}}) を導き出したものです。[[hcard-singular-properties]] に解説があるので、そちらをご覧ください。

==== 単数化されたプロパティ ====
いくつかの複数系のプロパティ名が単数名化されています。このため、もし元となる複数形のプロパティが、複数のコンポーネントからなるひとつの値を取るものであっても、それらのコンポーネントは、単数名化されたプロパティを複数持つものとなります。

== 関連ページ ==
{{hcard-related-pages}}

[[Category:hCard]]

== 翻訳 ==
* [[hcard|english]]（英語）
* [[hcard-fr|français]]（フランス語）
* [[hcard-ru|Русский]]（ロシア語）
* [[hcard-zh|汉语]]（中国語）

Main Page

2010-10-23T20:04:12Z

KitaitiMakoto: Undo revision 43187 by BryanLittle01 (Talk). It's spam.

<entry-title>Welcome to the microformats wiki!</entry-title>
__TOC__
Please start with the [[introduction]] page and read [[how-to-play]] before making any edits.

==Introduction==
This wiki is the central resource of the microformats community. You'll find current versions of published microformat specifications, specification drafts and publishing patterns. The wiki also hosts development resources, such as brainstorming pages for new formats and issue tracking pages for all current and in-development microformats.

== Get Started==
To get started with microformats:

* First, be familiar writing your pages and applications with semantically rich, descriptive, ‘[[posh|<abbr title="Plain Old Semantic HTML">POSH</abbr>]]’ <abbr title="HyperText Mark-up Language">HTML</abbr>.
* Learn about microformats from the [http://microformats.org/about/ about page], [http://microformats.org/ blog], [[press]], [[presentations]], [[books]], [[podcasts]], & [[screencasts]] pages.
* Take a look at established specifications such as [[hcard|hCard]] and [[hcalendar|hCalendar]], and follow the [[hcard-examples|examples]] to start publishing microformats.
* Have questions? Read the [[faq|frequently asked questions]] and see the [[glossary]] for terms and definitions. You can also post to the {{MicroformatsMailingList}}.
* Want to learn more in person? Check out microformats [[events]].

==Definition==
Microformats are small patterns of HTML to represent commonly published things like [[hcard|people]], [[hcalendar|events]], [[hatom|blog posts]], [[hreview|reviews]] and [[rel-tag|tags]] in web pages.

Microformats enable the publishing of higher fidelity information on the Web; the fastest and simplest way to provide feeds and APIs for the information in your website.

* Read more explanations of [[what-are-microformats|what microformats are]], and [[what-can-you-do-with-microformats|what you can do with them]].

== How to contribute ==
Do you want to help take microformats to the next level? You can:

* [[get-started|Get started]] by adding microformats to your website, services, and products.
* [[advocacy|Advocate]] the use of microformats on other web sites, especially those you use.
* Write a [[testimonial]].
* Do something on the [[to-do|to do list]].
* Join the [[irc|IRC Channel]] and [[mail|mailing lists]] to learn and help answer questions (read the [[mailing-lists#General_guidelines|general guidelines]] before posting).
* [[Main_Page#microformats_wiki_translations|Translate this microformats wiki into other languages]] to make microformats more accessible to readers of languages around the world.
* Before proposing any new microformats, make sure your website is [[POSH]], [[get-started|uses existing microformats]], and then read the [[process]].

This wiki has a number of enhancements to assist development and contributions to microformats. Before you start editing, see the [[wiki-2|wiki introduction page]] for instructions.

== Specifications ==
The list of current, stable [[microformats|Microformats]] open standard specifications.

* [[hcalendar|hCalendar]] - [http://microformats.org/code/hcalendar/creator hCalendar creator]
* [[hcard|hCard]] - [http://microformats.org/code/hcard/creator hCard creator]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [[XFN]] - [http://gmpg.org/xfn/creator XFN creator]
* [[XMDP]]
* [[xoxo|XOXO]]

''If you're tempted to try your hand at writing a microformat please read '''[[process|the process]]''' page first!''

== Drafts ==
Drafts are newer microformats, for which the specifications haven't been completed yet. Drafts are somewhat mature in the development [[process]] (see [[exploratory-discussions]] for additional efforts that are not as far along in the process). The stability of these documents cannot be guaranteed, and implementers should be prepared to keep abreast of future developments and changes. Please watch the wiki pages for updates.

* [[adr|adr]] - for marking up address information
* [[geo|geo]] - for marking up [http://en.wikipedia.org/wiki/WGS84 WGS84] geographic coordinates (latitude; longitude)
* [[hatom|hAtom]] - syndicating episodic content (e.g. weblog postings)
* [[haudio|hAudio]]
* [[hlisting|hListing]] - open, distributed listings
* [[hmedia|hMedia]] - A single media publishing format that relates to Images, Video and Audio.
* [[hnews|hNews]]
* [[hproduct|hProduct]]
* [[hrecipe|hRecipe]] - for cooking+baking recipes
* [[hresume|hResume]] - for publishing resumes and CVs
* [[hreview|hReview]] - [http://microformats.org/code/hreview/creator hReview creator]
* [[rel-directory]] - to indicate that the destination of a hyperlink is a directory listing containing an entry for the current page
* [[rel-enclosure]] - for indicating attachments (e.g. files) to download and cache
* [[rel-home]] - indicate a hyperlink to the homepage of the site
* [[rel-payment]] - indicate a payment mechanism
* [[robots-exclusion|robots exclusion]]

* [[xfolk|xFolk]]

== Design Patterns ==
{{design_patterns}} 

== Exploratory Discussions ==
See: [[exploratory-discussions]] for details of research and analysis of real-world [[examples]], existing formats, and brainstorming of possible new microformats, per the microformats [[process]].

== Examples ==
* [[examples-in-the-wild]]
* [[implementations]]
* [[zen-garden]]

== Resources ==
See [[resources]].

== User centric development ==
*[[user-interface]]
*[[data-portability]]
*[[social-network-portability]]

== Shared work areas ==
* [[to-do]]
* [[templates]]
* [http://microformats.org/wiki/delete pages for deletion] 
* [[Special:Specialpages|"Special" wiki pages]]
* [[year-in-review]]

== Tools, test cases, additional research ==
The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting [[tools|tools and services]] that need to process more than one microformat. That section is intended for editors, [[parsers]], [[validators]], test cases, and other information relevant across multiple microformats.

== Microformats wiki translations ==
You may read and edit microformats articles in many other languages:

* languages with over 100 articles
** [[Main_Page-fr|Français (French)]] {{UpdateMarker-fr}}
* languages with over 10 articles
** [[Main_Page-pt-br|Português (Brazilian Portuguese)]]
** [[Main_Page-ja|日本語 (Japanese)]]
** [[Main_Page-ru|Русский (Russian)]]
* languages with over 2 articles
** [[Main_Page-cs|Česky (Czech)]] {{NewMarker}}
** [[Main_Page-de|Deutsch (German)]]
** [[Main_Page-es|Español (Spanish)]]
** [[Main_Page-gl|Galego (Galician)]] {{NewMarker}}
** [[Main_Page-pl|Polski (Polish)]]
** [[Main_Page-ro|Română (Romanian)]] {{NewMarker}}
** [[Main_Page-zh|汉语 (Chinese)]]
** [[Main_Page-id|Indonesia (Bahasa Indonesia)]] {{NewMarker}}
* languages just started
** [[Main_Page-fa|پارسی (Farsi)]] {{NewMarker}}
** [[Main_Page-ar|العربية (Arabic)]]
** [[Main_Page-th|ภาษาไทย (Thai)]]
** [[Main_Page-it|Italiano (Italian)]] {{NewMarker}}
** [[Main_Page-ko|한국어 (Korean)]] {{NewMarker}}
* elsewhere
**[http://en.wikipedia.org/wiki/Microformat Wikipedia's article on microformats] has been translated into a number of languages.

See also [[other-languages]], and [[how-to-start-new-translation|how-to-start-a-new-translation]].

xFolk-ja

2010-10-03T07:00:31Z

KitaitiMakoto: created

#REDIRECT [[xfolk-ja]]

hresume-ja

2010-10-03T06:47:49Z

KitaitiMakoto: sync: english: 2010-10-01T03:16:25

<entry-title>hResume</entry-title>
{{DraftSpecification-ja}}
__TOC__
hResumeは、経歴(resume)や履歴書(CV)を公開するためのmicroformatです。hResume is one of several open microformat standards suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML.

Want to get started with writing an hResume? Use the [http://hresume.weblogswork.com/hresumecreator/ hResume Creator] to create your hResume and publish it, or follow the hResume authoring tips to add hResume markup to your web page or blog.

==Microformats Draft Specification==

; Editor/Author: [http://theryanking.com Ryan King]
; Acknowledgments: See [http://microformats.org/wiki/hresume#Acknowledgements acknowledgments].

Microformats [http://microformats.org/wiki/hresume#Copyright copyright] and [http://microformats.org/wiki/hresume#Patents patents] statements apply.

== Status ==
Draft, version 0.1.

== Introduction ==
=== Semantic XHTML Design Principles ===
{{semantic-xhtml-design-principles-ja}}

== Format ==
=== In General ===
The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.

=== Schema ===
The hResume schema consists of the following:

* hResume
** summary. optional. text.
** contact info. required. '''Must''' use [[hcard|hCard]]. '''Should''' use <code class="element"><address></code> + [[hcard|hCard]].
** experience. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** education. optional One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization
** publications. optional. One or more citations. Use cite tag.

=== Field details ===
The fields of the hResume schema represent the following:

* '''<code class="class-name">hresume</code>''':: root class name
* '''<code class="class-name">summary</code>''':: The class name <code class="class-name">summary</code> is used to mark up an overview of qualifications and objectives.
* '''contact''':: Current contact info in an [[hCard]]. '''Should''' use <code class="element"><address></code> with [[hCard]] when possible.
* '''<code class="class-name">education</code>''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.
* '''<code class="class-name">experience</code>''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''<code class="class-name">skill</code>''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.
* '''<code class="class-name">affiliation</code>''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization
* '''<code class="class-name">publications</code>''':: just use <code class="element"><cite></code>. When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.

=== XMDP Profile ===
* [[hresume-profile]] (@TODO)

=== Notes ===
This section is informative.

*...

== Examples ==
=== Summary ===
An example summary:

<source lang=html4strict>

I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996,
designing with pastels while others will still using tiled background images and frames...

</source>

=== Contact ===
<source lang=html4strict>
<address class="vcard">
Pedro Sanchez

123 Fake St.
Preston, Idaho 83263

Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a>
Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a>
Phone: +01.208.555.4567
</address>
</source>

=== Education ===
<source lang=html4strict>
<ol class="vcalendar">
<li class="education vevent">
<a class="url summary" href="http://example.edu/">Preston High School</a>
(<abbr class="dtstart" title="2001-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
</li>
...
</source>

=== Experience ===
==== Basic ====
A basic experience event:

<source lang=html4strict>
<ol class="vcalendar">
<li class="experience vevent">
President,
Preston High School,
<abbr class="dtstart" title="2004-09-01">May 2004</abbr> - <abbr title="2005-05-25">present</abbr>
</li>
...
</source>

==== Job Titles ====
To express one or more job titles/positions in the same experience event you should use [[hCard]]s. [[hcard]] requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't reasonable to repeat your name for every job title you mark up in [[hResume|hresume]]. So, you may use an <code class="element"><object></code> and the class name '<code class="class-name">include</code>' with a reference to the <code class="class-name">fn</code> somewhere else on the page.

For example, this [[hCard]] refers to another [[hCard]]

<pre>

<object data="#j" class="include"></object>
Preston High School
Class President

</pre>

Where "<code class="attr-value">j</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact [[hCard]] at the top of the page, e.g. (shown here as a verbose [[hCard]] for purposes of illustration that the reference may be to a subtree, not just a text node):

<source lang=html4strict>
<address class="vcard">

Pedro
Sanchez

</address>
</source>

This method of hCard property indirection via an object element [[include-pattern|has been generalized]] to apply to any/all string/text properties in hCard.
Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.

=== Skills ===
Some sample skills tags:
<source lang=html4strict>
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a>
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.
</source>

=== Affiliations ===
<source lang=html4strict>
National Honor Society
</source>

=== Publications ===
<source lang=html4strict>
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
</source>

== Examples in the wild ==
See [[hresume-examples-in-wild]]

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse hResumes. If you have an hResume implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page like [[hresume-implementations]].

* [http://www.cvmatch4jobs.com/ cvmatch4jobs] has implemented hResume import for publicly published CV's. A Career site for 3 UK building and proprety magazines from publishers UBM. 19 Jan 2010.

* [http://careercv.mad.co.uk/ CareerCV] has implemented hResume import for publicly published CV's. A Career site for major UK design magazines from publishers Centaur Communications. 19 Jan 2010.

* [http://lab.madgex.com/hresume/ Madgex] has implemented hResume to Microsoft Word and PDF conversion API. 13 Dec 2009.

* [http://careers.stackoverflow.com/ Stack Overflow] generates hResume for its public CV hosting service for programmers. [http://careers.stackoverflow.com/klmr Stack Overflow CV example] Dec 2009.

* [http://jobs.guardian.co.uk/profile/ Guardian Jobs] has implemented hResume import for publicly published CV's. 4 Sep 2009.

* [http://www.yiid.com/ YIID - Your Internet Identity] supports importing of hResumes (e.g. here is the result of an import: http://pfefferle.yiid.com/cv [requires login] via @pfefferle)

* [[Resume.app]]

* [http://www.xing.com/ Xing] generates hResume for all Public Profiles. [http://www.xing.com/profile/Matthias_Pfefferle Xing Public Profile Example].

* [http://linkedin.com LinkedIn] generates hResume for all Public Profiles. [http://www.linkedin.com/in/steveganz LinkedIn Public Profile Example].

* [http://www.antix.co.uk Anthony Johnston] has implemented hResume (Creation and Import) in the [http://cv.antix.co.uk Antix CV Builder], an example resume using this site can be found [http://cv.antix.co.uk/ant here]
** The example resume is ''invalid''; job titles are marked with an hCard that is missing a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:23, 1 May 2007 (PDT)
*** This is fixed now --[[User:Antix|Ant]] 00:38, 8 Dec 2007 (GMT)

* The [http://spurinc.com Spur] team has created an hResume WordPress plugin located at [http://hresume.weblogswork.com/?page_id=3 hResume Plugin]. See an example of the hResume markup [http://hresume.weblogswork.com/?page_id=6 here]. Neat feature of the hResume plugin is that it automatically creates a new page for the resume - no cutting and pasting...

* Spur also created a standalone hResume Creator located at [http://hresume.weblogswork.com/hresumecreator/ hResume Creator]. The creator will generate hResume markup ready to cut and paste into your webpage.

== Copyright ==
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
* [[RyanKing]]: I release all of my contributions to the public domain.

Per the above, and the public domain release on the author, [[User:RyanKing|RyanKing]]'s, user page this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

== Patents ==
{{MicroFormatPatentStatement-ja}}

== References ==
=== Normative References ===
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[include-pattern|include pattern]]
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag| Rel-Tag]]
* [[rfc-2119]]
* @TODO

=== Informative References ===
@TODO

== Acknowledgements ==
=== Concept ===
* [http://theryanking.com/ Ryan King], [http://technorati.com Technorati]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati]
* James Levine [http://simplyhired.com Simply Hired]
* [http://epeus.blogspot.com/ Kevin Marks], [http://technorati.com Technorati]

== Related Pages ==
{{hresume-related-pages}}

== Further Reading ==
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].
* [http://www.ablognotlimited.com/articles/getting-semantic-with-microformats-part-6-hresume/ Getting Semantic With Microformats, Part 6: hResume] by Emily Lewis

[[Category:hResume]]

Main Page

2010-06-06T11:43:30Z

KitaitiMakoto: Reverted edits by Goodnfl, Salewatches2010 and ArmaNang to last version by Tantek

resume-examples

2010-06-02T16:59:48Z

KitaitiMakoto: Undo revision 42626 by Jinmartt (Talk). It's spam.

<h1> Resume Examples </h1>

This space is for collecting and doing a simple analysis of resumes found on the WWW as part of the [[process]] in the development of a [[resume]] microformat. See the [[hresume|hResume]] draft.

__TOC__

== Resume Styles ==

In typical human discussion, when people refer to "resume formats" they mean how you organize and layout your resume for human consumption. However that term is ambiguous as could also refer to the data format of the resume (as it does on microformats.org). Thus the human organization/layout aspect of a resume we label the '''resume style''', and reserve the meaning of ''resume format'' for resume *data* format. For resume data format research, see [[resume-formats]].

In discussion with the SimplyHired guys, they noted that they have seen two general resume styles which cover the majority of cases.

Remember, in this discussion we want to try and cover the generalities of 80-90% of human resume styles (conventions for how people publish, whether on the web or paper).

Also, this page is for documentation and analysis of current examples of resumes on the web, and description of common resume formats, only. For analysis and ideas, see [[resume-brainstorming]].

=== other resume styles ===

* see [http://www.dummies.com/WileyCDA/DummiesArticle/id-636,subcat-JOB.html Choosing a resume format] for a basic overview of Reverse Chronological format (RC), Functional format, Hybrid format, Accomplishment format, Targeted format, Linear format, Professional format, Keyword format, Academic Curriculum Vitae (CV), International Curriculum Vitae format, and Portfolio format.

== Resumes from the wild ==

=== Tantek Çelik ===
* [http://tantek.com/projects/resume.html Tantek Çelik] (needs updating, this is over two years out of date)

==== Summary ====

Tantek has a summary list at the top:
<blockquote><pre><nowiki>
<ul class="quals">
<li>
Manager & technical leader (10 years). Led and set direction for teams of up to 12.
</li>
...
</nowiki></pre></blockquote>

==== Employment ====

Tantek then lists his employment history:
<blockquote><pre><nowiki>
<h2>Employment & Products</h2>
<ol class="experience">
<li class="job" id="technorati">
<h3>2004 - present<a href="http://www.technorati.com" class="company">Technorati</a>,
<a href="http://maps.yahoo.com/py/maps.py?BFCat=&Pyt=Tmap&addr=665+3rd+St&csz=San+Francisco+CA+94107"
class="location">San Francisco, CA</a></h3>
<h4>2004 July - present
Senior Technologist.</h4>
Investigate and define new standards and new technologies companywide. Lead adoption of and implementation of valid
semantic XHTML and CSS across all web sites. A primary contributor to the design, development, and launch of
<a href="http://politics.technorati.com">politics.technorati.com</a> "Election Watch 2004" site in 13 days.
<div class="completed">
<h5>Websites Developed and Launched</h5>
<ul class="websites">
<li><a href="http://www.technorati.com/">Technorati main site</a> (valid XHTML+CSS green redesign, XHTML strict
update)</li>
<li><a href="http://politics.technorati.com/">Election Watch 2004</a> (initial valid XHTML+CSS release, XHTML
strict update with new Attention Index, Charts features)</li>
</ul>
</div>
</li>
</nowiki></pre></blockquote>

The implied scheme seems to be (in CSS selectors):

<blockquote><pre><nowiki>
ol.experience
ol.experience li.job
ol.experience li.job .dates
ol.experience li.job .company
ol.experience li.job .jobtitle
ol.experience li.job .completed
ol.experience li.job .products
</nowiki></pre></blockquote>

The set of .jobtitle, .completed and .products is repeated for cases where he had more than one position at a company.

==== patents ====
Tantek also has a section on patents:

<blockquote><pre><nowiki>
<div class="patents" id="patents">
<h2><abbr title="United States">US</abbr> Patents</h2>
<div class="issued">
<h3 class="sidelabel">Issued(6):</h3>
<ol>
<li id="PatNo5752056" value="5752056">
<h4>
<a href="http://patft.uspto.gov/netacgi/nph-Parser?d=PALL&p=1&u=%2Fnetahtml%2F
srchnum.htm&r=1&f=G&l=50&s1=5,752,056&OS=&RS=">
System for binding document parts and handlers by fidelity of parts or by automatic
translation of parts</a></h4>
<a class="altlink" href="http://www.delphion.com/details?pn=US05752056__">(delphion US05752056)</a>
<a class="inventor">[sole inventor]</a></li>
...
</nowiki></pre></blockquote>

I'm not going to dig into this, because I already doubt it will be common enough for inclusion. --[[User:RyanKing|RyanKing]] 13:33, 18 Jan 2006 (PST)

==== Publications ====

<blockquote><pre><nowiki>
<div class="publications" id="publications">
<h2>Publications & Presentations</h2>

<h3 id="recs">Recommendations and Candidate Recommendations (CRs)</h3>
<ol>

<li>Çelik T.
"<a class="title" href="http://www.w3.org/TR/css3-ui">CSS3 Basic User Interface Module</a>"
<a class="publisher" href="http://w3.org/TR">W3C Technical Reports and Publications</a>
&lt;<a class="URL" href="http://www.w3.org/TR/2004/CR-css3-ui-20040511">http://www.w3.org/TR/2004/CR-css3-ui-20040511</a>&gt;
(2004)
</li>
</nowiki></pre></blockquote>

Definite material for citation microformat work. Need analysis in that context. --[[User:RyanKing|RyanKing]] 13:33, 18 Jan 2006 (PST)

==== presentations ====
<blockquote><pre><nowiki>
<h3 id="presentations">Invited Presentations</h3>
<ol>
<li>Marks K, Çelik T.
"<a class="title" href="http://sdforum.org/SDForum/Templates/CalendarEvent.aspx?CID=1524"> Semantic XHTML:
Can your website be your API? - Using semantic XHTML to show what you mean</a>",
<a class="publisher" href="http://sdforum.org/"><abbr title="Software Development Forum">SD Forum</abbr></a>
<a class="event" href="http://www.sdforum.org/SDForum/Templates/Level1.aspx?pid=10117&sid=7">Web Services
<abbr title="Special Interest Group">SIG</abbr></a>,
eBay's Silicon Valley Conference Center 2161 North First Street San Jose, CA 95131
(28 September 2004)
</li>
...
</nowiki></pre></blockquote>

Tantek has a list of presentations, which includes presenters' names, event URL, publisher (seems to be used
like 'organizer'), the event (ie, conference, workshop) URL and name, location and date.

==== Education ====
<blockquote><pre><nowiki>
<div class="education">
<h2>Education</h2>
<ol>
<li class="school">
<h3>20 June 2001<a href="http://www.edwardtufte.com/tufte/"
class="institution">Edward Tufte</a></h3>
<ul class="courses">
<li><a href="http://www.edwardtufte.com/tufte/courses">Presenting Data and Information</a></li>
</ul>
</li>
....
</nowiki></pre></blockquote>

Tantek lists his education, including 'dates', a list of 'courses' (which includes name and optional URL) and list of degrees.

==== Awards ====
<blockquote><pre><nowiki>
<div class="awards" id="awards">
<h2>Awards</h2>
<ol>
<li>2004
<a href="http://2004.sxsw.com/interactive">SXSW interactive conference</a>,

<a href="http://2004.sxsw.com/interactive/panels/ratings04/">Top rated moderator (4.70 out of possible 5.0)</a>.</li>
</nowiki></pre></blockquote>

List with dates, event name, url and award name.

==== Interests ====
<blockquote><pre><nowiki>
<div class="interests">
<h2>Other Interests</h2>
<ul>
<li>Alternative transport: skate, bicycle, motorcycle. Run? Only
<a href="http://www.asylumsfx.com/movies/belly.mov" target="m">when chased</a>.</li>
</nowiki></pre></blockquote>

==== Affiliations ====
<blockquote><pre><nowiki>
<h2>Member of</h2>
<ul><li><a href="http://www.cpsr.org">Computer Professionals for Social Responsibility (<abbr>CPSR</abbr>)</a> (life),</li>
</nowiki></pre></blockquote>

List of memberships/affiliations, each with URL and name.

==== Overall Implied Schema ====

The overall implied schema, as evidenced by this example.

{|
! Field name !! description
|-
| summary || a list of qualifications and competencies
|-
| employment || a list of jobs, each including dates, company, job title, completed, products
|-
| patents || a list of patents- pending and granted with descriptions, a URL, list of inventors
|-
| publications || a list of writings, each including author(s), title, url and published year
|-
| presentations || a list of invited presentations, each including presenters names, the presentation's title, the occassion/event and location
|-
| education || a list, each item including the date (range), the institution and a list of courses, with a URLs and names
|-
| awards || a list of awards, each with name, url and date
|-
| interests || a list of personal interests
|-
| affiliations || a list of affiliations, each with organization name, url and association type
|}

=== Dan Connolly ===
[http://www.w3.org/People/Connolly/misc/vita Dan Connolly] (needs elaboration for MIT purposes; has been GRDDL'd to some extent)

==== Affilitations ====
For affiliations, Dan has:
<blockquote><pre><nowiki>
<div class="affiliation">
Research Scientist 
MIT Computer Science and Artificial Intelligence Laboratory (<a rel="aff"
href="http://www.csail.mit.edu/">CSAIL</a>)
</div>
</nowiki></pre></blockquote>

Implied schema:
{|
! css selector !! semantics
|-
| div.affiliation || wrapper
|-
| div.affiliation em.position || the job position/title
|-
| div.affiliation b.org || the organization with which he is affiliated
|-
| div.affiliation b.org a[rel="aff"] || href is URL of the organization and textnode is an abbreviation of the organization name
|}

==== Contact ====
For contact info:
<blockquote><pre><nowiki>
<div class="contact">
200 Technology Square
Cambridge, MA
02139 
<code class='homePageAddr'>http://www.w3.org/People/Connolly/</code>
</div>
</nowiki></pre></blockquote>

Dan has a series of <div>'s, (should be a list, no?), each with this implied schema:

{|
! css selector !! semantics
|-
| div.contact || wrapper
|-
| div.contact span.street || hcard:street-address?
|-
| div.contact span.city || hcard:locality ?
|-
| div.contact span.st || hcard:region ?
|-
| div.contact span.zip || hcard:postal-code ?
|-
| div.contact homePageAddr || hcard:url ?
|}

==== Education ====

<blockquote><pre><nowiki>
<h2>Education</h2>
</nowiki></pre></blockquote>
...followed by more affiliation <code>div</code>'s (see above).

Under his education entry, he has a list of what appear to be honors/awards:

<blockquote><pre><nowiki>
<ul>
<li>National Merit Scholar</li>
<li>Natural Sciences <a
href="http://www.cs.utexas.edu/users/cline/dsbrochure.html">Dean's
Scholar</a></li>
<li><a href="http://www.arlut.utexas.edu/">Applied Research
Laboratories</a> Scholarship</li>
</ul>
</nowiki></pre></blockquote>

==== Publications ====

Publications section:

<blockquote><pre><nowiki>
<h2>Selected Publications</h2>
<ul>
<li>Berners-Lee, Connolly, Swick, <a href="/1999/04/WebData"><cite>Web
Architecture: Describing and Exchanging Data</cite></a> (World Wide Web
Consortium Note, 1999)</li>
<li><dl>
<dt>Connolly, <a
href="http://helix.nature.com/webmatters/xml.html"><cite>The XML
Revolution</cite></a> Nature's <a
href="http://helix.nature.com/webmatters/">Web Matters</a>, Oct 1998 
</dt>
</dl>
</li>
....
</nowiki></pre></blockquote>

This list of publications has authors, URL and title of the work.

==== Professional Experience ====

<blockquote><pre><nowiki>
<div>
<h2>Professional Experience</h2>
<ul>
<li>Domain Lead, W3C Architecture Domain, 1996-1998</li>
...
</nowiki></pre></blockquote>

A list of items, each with job title, the organization and a date range.

==== Appearance and Awards ====

<blockquote><pre><nowiki>
<div>
<h2>Selected Appearances and Awards</h2>
<ul>
<li><a
href="http://www.zdnet.com/intweek/printhigh/120897/top25.html"><cite>The
Top 25 Unsung Heroes Of The Net</cite></a> by <a
href="http://www.zdnet.com/intweek/">Inter@ctive Week</a> 1997</li>
....
</nowiki></pre></blockquote>

A list, each item with URL, title and publication/event.

==== Overall Implied Schema ====

The implied schema of Dan's resume seems to be:

{|
! field !! description
|-
| affiliations || a list of affiliations, current and past, each with organization info
|-
| contact info || current contact info including mailing address and URL
|-
| education || a list of affiliations, like above, then a list of honors/awards
|-
| publications || a list of citations
|-
| professional experience || a list of: title, time-frame, organization
|-
| appearances and awards || a list of events
|}

=== Mark Pilgrim ===
* http://diveintomark.org/about/resume/

==== Contact ====

Mark uses an [[hCard]] to give contact info:

<blockquote><pre><nowiki>
<div class="vcard">
<h1 class="fn">Mark Pilgrim</h1>
<address class="adr">
Apex, NC 
<a class="email" href="pilgrim@gmail.com">pilgrim@gmail.com</a> 
other contact information available upon request
</address>
</div>
</nowiki></pre></blockquote>

==== Status ====

Mark declares his current work/job seeking status:

<blockquote><pre><nowiki>
<h2>Status</h2>
seeking full-time employment in the Raleigh, NC area (telecommuting OK)
</nowiki></pre></blockquote>

==== Publications ====

A list of publications:

<blockquote><pre><nowiki>
<h2>Publications</h2>
<ul>
<li><cite>Greasemonkey Hacks</cite> – 2005, O'Reilly Media.</li>
<li><cite>Dive Into Python</cite> – 2004, Apress. Also available for free online
at <samp><a href="http://diveintopython.org/">diveintopython.org</a></samp>.
The book was written in DocBook XML and transformed into HTML, PDF, Word, Windows
Help, and plain text with XSL stylesheets. It has been translated into six languages.</li>
<li>Columns on <cite>XML.com</cite> – 2002-2004, O'Reilly Media. Full list at
<samp><a href="http://xml.com/pub/at/25">xml.com/pub/at/25</a></samp></li>
</ul>
</nowiki></pre></blockquote>

==== Projects/Publications ====

More publications and open source projects:

<blockquote><pre><nowiki>
<h2>Open Source and 
Self-Publications</h2>
<ul>
<li><cite>Universal Feed Parser</cite> – <samp><a href="http://feedparser.org/">
feedparser.org</a></samp> – parse RSS and Atom feeds in Python</li>
<li><cite>Feed Validator</cite> – <samp><a href="http://feedvalidator.org/">
feedvalidator.org</a></samp> – validate RSS and Atom feeds</li>
<li><cite>Dive Into Greasemonkey</cite> – <samp><a href="http://diveintogreasemonkey.org/">
diveintogreasemonkey.org</a></samp> – a book on remixing web sites with JavaScript</li>
<li><cite>Dive Into Accessibility</cite> – <samp><a href="http://diveintoaccessibility.org/">
diveintoaccessibility.org</a></samp> – a book on web accessibility techniques</li>
<li>Python web services libraries – <samp><a href="http://diveintomark.org/projects/">
diveintomark.org/projects</a></samp></li>
<li>Screencasts (video tutorials) – <samp><a href="http://howto.diveintomark.org/">
howto.diveintomark.org</a></samp></li>
</ul>
</nowiki></pre></blockquote>

==== Professional Experience ====
<blockquote><pre><nowiki>
<h2>Professional Experience</h2>

<div class="employer">
<h3>March 2004 – present, accessibility architect at IBM</h3>
<ul>
<li>Implemented advanced web accessibility in AJAX applications using Firefox 1.5 and
WindowEyes screenreader. Co-wrote best practices guidelines for these techniques.</li>
<li>Wrote developer guidelines for creating accessible applications and custom graphical
controls in SWT-based Eclipse applications.</li>
<li>Designed accessibility API for OpenOffice.org-based office suite. Coordinated with
Freedom Scientific (assistive technology vendor) and development team to ensure interoperability.</li>
</ul>
...
</nowiki></pre></blockquote>

Several <code><div></code>'s of <code>class="employer"</code>, each with timeframes and lists of accomplishments.

==== Education ====
<blockquote><pre><nowiki>
<h2>Education</h2>
<h3>June 1995, Earlham College</h3>
BA of philosophy, 3.8 GPA
</nowiki></pre></blockquote>

==== Overall implied schema ====
{|
! field !! description
|-
|contact || current contact info, already an [[hcard]]
|-
|status || text describing work availability
|-
|publications || list of citations
|-
|projects/ Self-Publications || a list of projects (w/ URLs) and books published online
|-
|professional Experience || a list of jobs, each with timeframes and accomplishments
|-
|education || a list of: school, graduation date, degree and GPA
|}

=== Eran Globen ===
http://hellonline.com/resume.html

==== Objective ====

<blockquote><pre><nowiki>
<h2>Objective</h2>

Pursuing a hands-on...
</nowiki></pre></blockquote>

==== Summary ====

<blockquote><pre><nowiki>
<h2>Summary</h2>

Software engineer with
over 7 years experience in all...
</nowiki></pre></blockquote>

==== Professional Experience ====

<blockquote><pre><nowiki>
<h2>Professional Experience</h2>

2001-Present: limbo Technologies 
Chief Technology Officer
 
Provided services to several companies on various projects in several fields
including scaling of web server farms, security planning and auditing and
updating ASP based applications to ASP.NET technology.
...
</nowiki></pre></blockquote>

Appears to be a list of:

* time range
* company
* job title
* description

==== Education/ Military ====
<blockquote><pre><nowiki>
<h2>Education and Military Service</h2>

Tel Aviv Univeristy 
Computer Science 
Graduated with Bachelor's Degree (BSc.) 

Israeli Defense Force 

Army Intelligence Core 
Honorable Discharge in 1996 for one full standard term of Isreali Military Service. 
...
</nowiki></pre></blockquote>

List including organization (school/military), degee.

==== Interests ====
<blockquote><pre><nowiki>
<h2>Related Knowledge and Interests</h2>

Platforms: Administrative knowledge of Window NT through
Server2003. Working knowledge of Linux 2.2.19 to current. 

Database: MS-SQL Server 6.5-2k nearing DBA level, MS-Access, working knowledge of Oracle Database Systems.

Languages: VB, VBScript, Java, C, C++, C#, (T-)SQL, WML, XML, and Perl. 

Technologies: ADO, ASP, ASP.NET, COM, WAP, Client/Server; Expansive knowledge
of networking, specifically TCP/IP, with a strong interest in systems and
network security 

Current Studies and Interests: 
Expansive knowledge of networking, specifically
TCP/IP, with a strong interest in systems and network security. Also interested
in wireless, including cellular and Ethernet based internet technologies including
Location Based Services and Wireless Gaming. 
...
</nowiki></pre></blockquote>

A collection of interests grouped by category.

==== Overall Implied Schema ====

{|
! field !! summary
|-
|objective || text describing career goals
|-
|summary || an overview of qualifications
|-
|professional Experience || list of employment, each as an event
|-
|education/ Military || list of education and military service, each with title/degree, org and timeframe
|-
|interests || text describing current interests
|}

=== Tara Hunt ===
http://horsepigcow.com/tararesume.htm

==== Contact Info ====
(markup simplified to protect the guilty --[[User:RyanKing|RyanKing]] 15:38, 19 Jan 2006 (PST))
<blockquote><pre><nowiki>
<div align="left">
762 Adelaide West, Toronto,
ON M6J 1B1 
e. <a href="mailto:tara@roguestrategies.com">tara@roguestrategies.com</a>
w. <a href="http://www.roguestrategies.com" target="_blank">www.roguestrategies.com</a> 
c. 416-837-8972 h. 416-703-5391 


</div>
</nowiki></pre></blockquote>

==== Summary ====

<blockquote><pre><nowiki>
<td>We
live in the world of uber-savvy consumers and never-ceasing media inundation.
It is simple to have a market presence, but nearly impossible to make a
market connection. These connections are what today's entrepreneur requires
to survive. Creating authentic bonds is at the core of every one of my strategies.
This is marketing uncommon.</td>
</nowiki></pre></blockquote>

==== Qualifications ====
<blockquote><pre><nowiki>
I AM QUALIFIED
I have experience in each of the following areas:
...
<ul ...>
<li>e-Marketing (e-Content Development) 
<li>CMS (Content Management)
...
</nowiki></pre></blockquote>

==== Education ====
<blockquote><pre><nowiki>
I AM EDUCATED 
Bachelor of Arts (Communications & Culture) - University of Calgary 1994-1999
</nowiki></pre></blockquote>

==== Qualifications?/Experience ====
<blockquote><pre><nowiki>
<font...>I AM VERSATILE 
Computer Programs:
Microsoft CMS, Adobe Photoshop CS, Illustrator CS, Acrobat 6, Macromedia Flash
MX, Dreamweaver 4, Fireworks 4, HTML, DHTML, XML, Javascript, CSS, Microsoft
Word, Excel, Outlook, PowerPoint, FrontPage, Access, Project, CMS - Mac &
PC platforms.
Public Speaking Experience:
Delivered academic papers, developed and presented a self-branding seminar,
and enjoy networking and speaking to groups of people.
...
</nowiki></pre></blockquote>

==== Portfolio ====
<blockquote><pre><nowiki>
Designed recently:
...
<li><a href="http://www.joestiff.com" target="_blank">www.joestiff.com</a> 
...
</nowiki></pre></blockquote>

==== Professional Experience ====
<blockquote><pre><nowiki>
I AM A PROFESSIONAL 
HR PROFESSIONALS ASSOCIATION OF ONTARIO 2003 - current 
New Media Manager (www.hrpao.org)
SKILLS USED: New media management,
digital marketing, brand development, strategic planning, budgeting, project
management, customer relationship management, market research, trend analysis,
copywriting/editing, presentation development & delivery, web design
At HRPAO, I: 
<ul type="square">
<li>pilot and manage a major
Content Management System (CMS) changeover/upgrade 

...
</ul>
</nowiki></pre></blockquote>

==== Affiliations ====
<blockquote><pre><nowiki>
CURRENT PROFESSIONAL
AFFILIATIONS 
Canadian Marketing Association (CMA) 
Second Wind Network 
Creative Class 100 - www.creativeclass.org
</nowiki></pre></blockquote>

==== publications ====
<blockquote><pre><nowiki>
RECENTLY PUBLISHED 
Business in the Blogosphere: Conference & Corporate Blogging as a Marketing Tool 
Marketing Watchdog Journal, May 2005
</nowiki></pre></blockquote>

==== Overall Implied Schema ====

{|
! field !! summary
|-
|contact info || contact info - address, email, url
|-
|summary || summary of qualification
|-
|qualifications || list of qualification
|-
|education || list of education events, includes school, timeframe, school location
|-
|qualifications?/Experience || list of skills and tools
|-
|portfolio || list of URLs and titles
|-
|professional Experience || a list of job events
|-
|affiliations || a list of URL/name of organization
|-
|publications || a list of citations
|}

=== Casey Conroy ===
http://caseyconroy.com/a_resume.html

==== Professional Experience ====
<blockquote><pre><nowiki>
PROFESSIONAL EXPERIENCE 

GRAPHIC DESIGNER, Webster University 
August 2004–present 
Responsible for the design and production of one- two- and four-color printed and interactive publications.
Also responsible for vendor and account management. All clients are internal. 
</nowiki></pre></blockquote>

Includes: Job title, Organization, start and end time and a summary.

==== Education ====

<blockquote><pre><nowiki>
EDUCATION 
Missouri State University 
BFA in Design, magna cum laude, December 2001 
Dual Emphasis: Graphic Design and Illustration 
</nowiki></pre></blockquote>

Includes: school name, degree recieved, honors, graduation date and a summary of studies

==== Professional Skills ====
<blockquote><pre><nowiki>
PROFESSIONAL SKILLS (Macintosh Platform) 
ADOBE: Illustrator, ImageReady, InDesign, Photoshop, Streamline 
MACROMEDIA: Dreamweaver, Fireworks, Flash, FreeHand 
MICROSOFT: Excel, PowerPoint, Word 
OTHER: BBEdit, QuarkXPress 
PROGRAMMING LANGUAGES: HTML, CSS 
</nowiki></pre></blockquote>

A list of skills and tools.

==== Published Work ====
<blockquote><pre><nowiki>
PUBLISHED WORK 
CMYK magazine, issue #19, 2002, Design Annual 
Print magazine, September/October, 2002, Continental Shift 
</nowiki></pre></blockquote>

A list of publications, with publication information.

==== Exhibitions ====
<blockquote><pre><nowiki>
EXHIBITIONS 
AIGA Design Show Nine, Saint Louis: Fall 2002 
University & College Designers Association, British Columbia: Spring 2001 
</nowiki></pre></blockquote>

==== Memberships ====
<blockquote><pre><nowiki>
MEMBERSHIPS 
American Institute of Graphic Arts 
</nowiki></pre></blockquote>

A list of organizations in which he's a member.

==== Overall Implied Schema ====

{|
! field !! description
|-
| professional Experience || a list including title, organization, timeframe and a description
|-
| education || a list including organization (school), degree, honors, graduation date and area of study
|-
| professional Skills || an outline of skills/tools broken down by general categories
|-
| published Work || a list of citations
|-
| exhibitions || a list of events
|-
| memberships || a list of organizations
|-
|}

=== Brian Suda ===
http://suda.co.uk/cv/

==== Objective ====
<blockquote><pre><nowiki>
<h2 id="objective">Objective</h2>
I am currently looking to work full-time in an environment that allows me to use both my technical and
creative backgrounds. I am seeking a position that does not have a rigid structure or inflexible goals, but
one which allows me to create new initiatives.
</nowiki></pre></blockquote>

==== Education ====

<blockquote><pre><nowiki>
<h2 id="education">Education</h2>

<a class="ex-ref" href="http://www.ed.ac.uk" title="Master of Science, Computer Systems and Software Engineering">
The University of Edinburgh</a> 
Edinburgh, Scotland 
Master of Science, 
Informatics, Computer Science 

</nowiki></pre></blockquote>

Includes degree, school, location.

==== Employment ====
<blockquote><pre><nowiki>
<h2 id="employment">Employment</h2>

9/01–9/02, 1/05–Present 
Technology Developer 
<a class="ex-ref" href="http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1
&q=paradigm+new+media+group" title="Technology Developer">Paradigm New Media Group</a> 
Saint Louis, <abbr title="Missouri">MO</abbr> <abbr title="United States of America" class="initialism">USA</abbr>
 

</nowiki></pre></blockquote>

Includes the start and end date, job title, company url, company name and company location.

==== Overall Implied Schema ====

{|
! !!
|-
|objective || a summary of career goals
|-
|education || a list including the school (organization), the degree/program and the location
|-
|employment || a list including the organization, timeframe, job title and location
|}

== Experiments in microformatting ==
* [http://cs.usfca.edu/~rking/resume.html ryan king]
* [http://cs.usfca.edu/~rking/niall.html Niall Kennedy] (microformatted by RyanKing)
* My resume uses hCard, hCalendar, XFN, and rel-license: http://edward.oconnor.cx/resume/ [[User:EdwardOConnor|EdwardOConnor]]
* [http://steve.ganz.name/resume/resume.html Steve Ganz] - A work-in-progress. Currently using [[hCard]], [[hCalendar]], and a little [http://gmpg.org/xfn/ XFN]. Where there weren't any appropriate existing microformats to draw upon, I looked to [http://xmlresume.sourceforge.net/ XML Resume] for semantics or simply improvised (class="qualifications"). I also created a few custom link type values: rel="employer current" and rel="employer former" (no profile yet).
* [http://maetl.coretxt.net.nz/cv/ Mark Rickerby] - a barebones CV written in the first week of 2006
* [http://xavierroy.com/resume/ Xavier Roy] - a resume sample hacked and copied from various sources including the above ones...

== Aggregate Analysis ==

The table below is a merge+sort of the above "Overall Aggregate Analysis" tables. This should highlight where we have regularities across examples.

{|
! affiliations/memberships
|-
|affiliations || a list of affiliations, current and past, each with organization info
|-
|affiliations || a list of affiliations, each with organization name, url and association type
|-
|affiliations || a list of URL/name of organization
|-
|memberships || a list of organizations
|-

! appearances/awards
|-
|appearances and awards || a list of events
|-
|awards || a list of awards, each with name, url and date
|-

! contact info
|-
|contact || current contact info, already an hcard
|-
|contact info || contact info - address, email, url
|-
|contact info || current contact info including mailing address and URL
|-

! education/military
|-
|education || a list including organization (school), degree, honors, graduation date and area of study
|-
|education || a list including the school (organization), the degree/program and the location
|-
|education || a list of affiliations, like above, then a list of honors/awards
|-
|education || a list of: school, graduation date, degree and GPA
|-
|education || a list, each item including the date (range), the institution and a list of courses, with a URLs and names
|-
|education || list of education events, includes school, timeframe, school location
|-
|education/ military || list of education and military service, each with title/degree, org and timeframe
|-

! employment/professional experience
|-
|employment || a list including the organization, timeframe, job title and location
|-
|employment || a list of jobs, each including dates, company, jobtitle, completed, products
|-
|professional experience || a list including title, organization, timeframe and a description
|-
|professional experience || a list of job events
|-
|professional experience || a list of jobs, each with timeframes and accomplishments
|-
|professional experience || a list of: title, timeframe, organization
|-
|professional experience || list of employment, each as an event
|-

!exhibitions
|-
|exhibitions || a list of events
|-

! interests
|-
|interests || a list of personal interests
|-
|interests || text describing current interests
|-

! objective
|-
|objective || a summary of career goals
|-
|objective || text describing career goals
|-

!patents
|-
|patents || a list of patents- pending and granted with descriptions, a URL, list of inventors
|-

! portfolio
|-
|portfolio || list of URLs and titles
|-

! presentations
|-
|presentations || a list of invited presentations, each including presenters names, the presentation's title, the occassion/event and location
|-

! skills
|-
|professional skills || an outline of skills/tools broken down by general categories
|-

!publications
|-
|publications || a list of citations
|-
|publications || a list of citations
|-
|publications || a list of writings, each including author(s), title, url and published year
|-
|publications || list of citations
|-
|published work || a list of citations
|-
|projects/ self-publications || a list of projects (w/ URLs) and books published online
|-

! qualifications
|-
|qualifications || list of qualification
|-
|qualifications/experience || list of skills and tools
|-

! status
|-
|status || text describing work availability
|-

! summary
|-
|summary || a list of qualifications and competencies
|-
|summary || an overview of qualifications
|-
|summary || summary of qualification
|-
|}

== Diploma Examples ==

It has been suggested that hResume include diplomas/certificates. See [http://microformats.org/discuss/mail/microformats-discuss/2006-June/004364.html]

This section is for adding diploma examples.

== First example ==
==== Employment ====
<blockquote><pre><nowiki>
markup example goes here
</nowiki></pre></blockquote>

Short description here.

== Related Pages ==
{{hresume-related-pages}}

Main Page

2010-06-02T16:57:01Z

KitaitiMakoto: Reverted edits by Alfredo5y9 and Goodnfl to last version by Tantek

xfolk-ja

2010-05-28T11:32:17Z

KitaitiMakoto: sync: english: 2010-05-28T05:34:41

<entry-title>xFolk RC1</entry-title>

{{DraftSpecification-ja}}

'''xFolk'''（"xFolksonomy"に由来）は、ブックマークのコレクションを公開するための簡単でオープンなフォーマットです。これによって、サービスがウェブベースのブックマークソフトウェアでのユーザー体験の向上とデータの共有をよりうまくできるようになります。xFolk は HTML または XHTML、Atom、RSS、任意の XML に埋め込むことができます。これはオープンな[[microformats-ja|マイクロフォーマット]]標準の一つです。

__TOC__

== 仕様ドラフト ==

=== 編者/作者 ===
[http://thecommunityengine.com/ Bud Gibson] ([http://thecommunityengine.com The Community Engine])

=== 著作権 ===
{{MicroFormatCopyrightStatement2005}}

=== 特許 ===
{{MicroFormatPatentStatement-ja}}

=== 謝辞 ===
各項目が、部分的に、一度にたくさんのカテゴリーに属していてもかまわないというアイディアをもたらしてくれた [http://www.cnbc.cmu.edu/~plaut/ David Plaut] に感謝します。また、より最近ですが、思慮深い批評と推進で xFolk の開発に貢献してくれた [http://tantek.com/ Tantek Celik]、[http://epeus.blogspot.com/ Kevin Marks]、[http://steve.osdir.com/ Steve Mallet]、[http://hybernaut.com/ Brian DelVecchio]、[http://blogmarks.net Francois Hodierne]に感謝します。

== はじめに ==
ソーシャルブックマークサービスでは、ユーザーはブックマークを保存し、タグを付け、ほかのユーザーと共有します。ここ数年でこういったサービスの数は[http://en.wikipedia.org/wiki/Social_bookmarking 20を超え]、その中には[http://del.icio.us del.icio.us]、[http://furl.net furl]、[http://de.lirio.us de.lirio.us]（訳注：現在は [http://www.simpy.com/ Simpy] に引き継がれたようです）、jots（訳注：現在はサービス終了）、[http://blogmarks.net blogmarks]という人気サービス例も含まれます。

相互運用可能なデータのオープンスタンダードがないことは、ソーシャルブックマークサービスを使う上での大きな問題です。オープンスタンダードがあればソーシャルブックマークデータを簡単に集めて再構築し、gataga（訳注：現在はサービス終了）による実験的なブックマーク検索エンジンのような方向性の、新しいサービスを発明することが可能になるのです。また、[http://johnvey.com/features/deliciousdirector/ 目下は del.icio.us で行われている]ような、サービスをまたがって機能する JavaScript を書いてユーザー体験を全面的に向上させることもできるようになります。

xFolk は両方の利点を持つことを目標にした、ソーシャルブックマークのオープンスタンダードです。xFolk を取り入れたソーシャルブックマークサービスは、データサービスの一歩先を歩くことになるでしょう。ですが、データ自体はサードパーティのスクリプトが操作したり、共有したりすることが簡単な物になります。その結果、ブックマークサービスは低コストでユーザーに幅広い選択肢を提供し、本質的な差別化に力を注ぐことができるようになります。独立したブックマーク保管サービスを運営する個人やグループは、自分で作れる以上の幅広い機能を選べるようになります。

== セマンティック XHTML デザイン指針 ==
{{semantic-xhtml-design-principles-ja}}

== フォーマット ==
ソーシャルブックマークサービス、リンクブログ（訳注：リンクとそれに対するコメントからなるブログ）、[http://thecommunityengine.com/home/archives/xfolk 他所]でのリポートを幅広く分析した結果、ブックマークサービスと'''たくさんの'''異なるリンクブログで公開されているデータは暗黙的に次のスキーマに従って書かれていることが分かりました。

* ブックマークしたりタグを付けるリンク
* エントリーの題名
* リンクに付けるタグ
* リンクの追加説明や概要

初期の xFolk 標準が繰り返し使われたおかげで、この一般的なスキーマは次のようにしてマークアップへと変換できることが実証されています。

# 各エントリーに <code>xfolkentry</code> という class を持つコンテナ要素を作る
# ブックマークしたりタグを付けるリンクには <code>taggedlink</code> という class を持つ <a> 要素を使う
# エントリーの題名には、もしあれば <a> 要素の title 属性を、なければその値を使う
# タグには [[rel-tag-ja|rel-tag]] を使う
# 追加説明や概要には、<code>description</code> という class を持つコンテナ要素（ など）を使う

xFolk エントリーでは、題名を伴ったタグを付けるリンクが必須で、他の要素は全て省略できます。エントリーには複数のタグあってもかまいませんし、<code>description</code> class の要素が複数あってもかまいません。<code>description</code> class を持つ複数の要素の順序は、文書に現れるままの順です。xFolk エントリー内の意味的な要素は任意の深さにネストできます。

たくさんのソーシャルブックマークシステムが存在して、それぞれが独自のマークアップの慣例を持っています。さらに、たくさんの人が既に個人のリンクブログを公表しています。xFolk の第一の目標は、こうした現在の慣例に適合させるのが簡単であるようデザインすることなので、xFolk エントリーで使う要素の種類には厳密な前提条件がほとんどありません。意味を決める機能は、要素よりも class 属性や（[[rel-tag-ja|rel-tag]] の場合は）rel 属性の値に与えられるのです。

開発者は [http://www.w3.org/TR/xpath XPath] か相当する文法を使って xFolk エントリーの要素にアクセスすることが期待されます。XPath を使うための条件は、HTML 文書が整形式であることです。妥当な文書ではなくてもかまいません。このため、最善ではないかもしれませんが、妥当性検証をしていない HTML 文書の中で xFolk が使えるようになるのです。

=== XMDP プロファイル ===
xFolk の [http://gmpg.org/xmdp XMDP] プロファイルは、[[xfolk-profile-ja|xFolk profile]] を参照してください。

== 例 ==

下に [http://del.icio.us del.icio.us] の標準マークアップに見られるブックマークの例を示します。要素の class 属性の値を変更して xFolk に適合させる必要のある場所は、行の末尾にコメントで印を付けています。
<pre><div class="post"> 
<div>
<a class="delLink" href="http://www.sifry.com/alerts/archives/000306.html"> 
Sifry's Alerts: Technorati launches Related Tags
</a>
</div>
<div class="extended"> 
Ever wanted to see what posts are related to other posts, what tags
are related to others? Now you can! Just check under the Tag
description on most tag pages, like this one, or this one, and you'll
see the patterns. Can you smell the emergence?
どの投稿がどの投稿と関係あるのか、どのタグがどのタグと関係あるのか、
分かるようになってほしいとずっと思ってた。ようやくなった！
こことかこことか、ほとんどのタグページでタグを記述した部分の下をチェックしてほしい。
何かが起きそうなにおいがするだろ？
（訳注：『Emergence』は書名。邦題は『創発―蟻・脳・都市・ソフトウェアの自己組織化ネットワーク』。
　個の局所的な働きが全体の組織だった働きを生むという現象を解説）
</div>
<div class="meta">
to
<a class="delNav" href="/fpgibson/folksonomy">folksonomy</a> 
<a class="delNav" href="/fpgibson/technorati">technorati</a> 
... <a class="delNav" href="/url/cbcabf7de070fdb46598ee679367be49">
and 1 other person
</a>
... on 2005-04-09
</div>
</div></pre>

これに相当する xFolk は以下の通りです。class 属性の変更が必要だった行の末尾にコメントを付けています。
<pre><nowiki>
<div class="xfolkentry"> 
<div>
<a class="taggedlink" href="http://www.sifry.com/alerts/archives/000306.html"> 
Sifry's Alerts: Technorati launches Related Tags
</a>
</div>
<div class="description"> 
Ever wanted to see what posts are related to other posts, what tags
are related to others? Now you can! Just check under the Tag
description on most tag pages, like this one, or this one, and you'll
see the patterns. Can you smell the emergence?
どの投稿がどの投稿と関係あるのか、どのタグがどのタグと関係あるのか、
分かるようになってほしいとずっと思ってた。ようやくなった！
こことかこことか、ほとんどのタグページでタグを記述した部分の下をチェックしてほしい。
何かが起きそうなにおいがするだろ？
</div>
<div class="meta">
to
<a rel="tag" href="/fpgibson/folksonomy">folksonomy</a> 
<a rel="tag" href="/fpgibson/technorati">technorati</a> 
... <a class="delNav" href="/url/cbcabf7de070fdb46598ee679367be49">
and 1 other person
</a>
... on 2005-04-09
</div>
</div>
</nowiki></pre>

マークアップを xFolk に従う物に変換するのは、ほとんどの場合簡単です。xFolk の長所は、
全てのサービスやリンクブログにまたがって、精度を失うことの無いまま使い回せる class 属性のセットを提供していることです。
次の節ではこの点を説明する例をさらに多く提示します。

下は（リストのマークアップを使った）別の簡単な例です。
<pre>
<nowiki>
<ul>
<li>
<ul class="xfolkentry">
<li><a class="taggedlink" href="http://microformats.org/wiki/Main_Page">microformats wiki</a></li>
<li class="description">マイクロフォーマットを勉強して実践する主な場所で……</li>
<li class="description">コミュニティ駆動の Wiki</li>
<li class="meta">
Tags :
<a rel="tag" href="http://del.icio.us/tag/microformats">microformats</a>
<a rel="tag" href="http://del.icio.us/tag/websocial">websocial</a>
<a rel="tag" href="http://del.icio.us/tag/semantics">semantics</a>
</li>
</ul>
</li>

<li>

</li>

</ul>
</nowiki>
</pre>

== より多くの例 ==

開発者がサイトに xFolk を取り入れるのに役立つ例がたくさんあります。

=== 実世界での例 ===

実際に機能中の、xFolk でブックマークを公開しているシステムの例です。パース、索引作成、整理などを試せる「実際に利用されている」例を探し始めるには絶好でしょう。自分が xFolk を使ってブックマークを公表しているなら、遠慮せずそのサイトをこのリストの一番上に加えてください。リストが大きくなり過ぎたら、別の Wiki ページを作ります。

* [http://greenvoice.com Greenvoice] はユーザーが作る環境ニュースのリンクリストで、xFolk でマークアップされています。
* [http://www.idoneos.com Idoneos.com] はコンセプトごとに繋がった情報ページ（多くはスペイン語）のコレクションで、xFolk を使ってブックマークにタグ付けしています。
* [http://ashaszin.lautre.net/ Ashaszin] - [http://spip.net SPIP] を使って運営されている小さなブログ。xFolk でタグ付けした del.icio.us リンクとウェブフィードがあります。
* [http://www.rolandinsh.lv/blog/ Rolands Umbrovskis - blog] ブログの記事は全て xFolk でマークアップされています。
* [http://www.bbc.co.uk/worldservice/bangladeshboat BBC World Service Bangladesh River Journey] はソーシャルネットワークマッシュアップで、hAtom エントリーのブックマークに、基本的な xFolk を使っています。[http://dharmafly.com/blog/bangladeshboat Dharmafly のブログでの議論] を参照。
* [http://waferbaby.com/hussy waferbaby の Hussy] は、現在 xFolk を使ってリンクを公開しています（訳注：2008 年 11 月現在、確認できません）。
* [http://smarking.com/ Smarking] は、現在 xFolk を使って（検索結果を含む）共有リンクを公開しています。
* [http://unalog.com unalog] は、現在 xFolk を使って（検索結果を含む）共有リンクを公開しています（訳注：現在終了）。
* [http://de.lirio.us de.lirio.us] は、現在 xFolk を使ってブックマークを公開しています（<code>description</code> の代わりに、廃止予定の <code>extended</code> という class 属性を使っています。[[xfolk-profile-ja |XMDP]] を参照）（訳注：現在は [http://www.simpy.com/ Simpy] に引き継がれ、そちらでは xFolk は使用されていないようです）。
* [http://blogmarks.net/my/tools,export blogmarks] は現在、ブログへのブックマークを xFolk でエクスポートします（訳注：アカウント未所持のため、未確認。通常ページでは xFolk を使用しています）。
* [http://thecommunityengine.com The Community Engine] は、[http://thecommunityengine.com/home メインエントリー]と[http://thecommunityengine.com/webcites 公開ブックマーク]で xFolk を使っています（<code>description</code> の代わりに、廃止予定の <code>extended</code> という class 属性を使っています。[[xfolk-profile-ja |XMDP]] を参照）。
* [http://groovymother.com/links/ Groovy Links] は xFolk でマークアップされているリンクブログです（訳注：現在はこのページは無く、[http://groovymother.com/ ホームページ]が対応）。
* [http://tommorris.org/blog/ Tom Morris] - 日々の del.icio.us リンクが xFolk、[[hcard-ja|hCard]]、[[vote-links-ja|Vote Links]] でマークアップされています。

=== <div id=".E3.81.95.E3.82.89.E3.81.AA.E3.82.8B.E3.82.BD.E3.83.BC.E3.82.B7.E3.83.A3.E3.83.AB.E3.83.96.E3.83.83.E3.82.AF.E3.83.9E.E3.83.BC.E3.82.AF.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9" name=".E3.81.95.E3.82.89.E3.81.AA.E3.82.8B.E3.82.BD.E3.83.BC.E3.82.B7.E3.83.A3.E3.83.AB.E3.83.96.E3.83.83.E3.82.AF.E3.83.9E.E3.83.BC.E3.82.AF.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9">ソーシャルブックマークサービスへの付加</div> ===

次の例では、一つのサービスに、どのようにして xFolk を適用できるのかが説明されています（訳注：現在の scuttle 0.7.4 では xFolk を使ってリンクがマークアップされています）。

* [[xfolk-scuttle | scuttle]]

=== リンクブログ ===

ソーシャルブックマークサービスは、人々がリンクを公開する最近の例と言うに過ぎません。リンクブログは、ほとんどブログの初期の頃からありました。これはその発端から、あまり意味的でないマークアップをされる傾向があったため、xFolk にするにはもう少し労力を使う必要があります。次の例は、個別の作業説明し、それぞれがどのようにしてうまくいくのかを描いています。

* [[xfolk-kottke | kottke]]
* [[xfolk-pollas | pollas]]
* [[xfolk-jacobian | jacobian]]
* [[xfolk-julian-bez | julian-bez]]

=== スパム ===
スパム業者には、リンクファームにタグを付けるのに xFolk を利用している所もあります。（恐らく、実際にそのサイトにリンクさせるには、悪いアイディアでしょう。）例えば、
* phontron.info

== 実装 ==

次の実装は、xFolk を作ったり使ったりして開発されました。もし xFolk の実装を持っていたらこのリストの一番上に自由に加えてください。リストが大きくなり過ぎた時には、別の Wiki ページを作ります。

* [http://sourceforge.jp/projects/sfnet_semanticscuttle/ SemanticScuttle] は自分で扱えるソーシャルブックマークソフトウェアで、xFolk をネイティブサポートしています。
* [http://buzka.com Buzka]はソーシャルブックマークサービスで、現在は xFolk をサポートしています（訳注：2008年11月現在はサポートされていないようです）。
* [http://blip.tv Blip.tv]は動画ホスティングサイトで、現在は [http://blog.blip.tv/blog/2006/08/19/blip-supports-xfolk/ xFolk をサポートしています]（訳注：2008年11月現在はサポートされていないようです）。
* [http://www.s9y.org/ Serendipity] は PHP によるフレキシブルなブログ/CMS アプリケーションです。現在、xFolk をサポートする[http://www.numblog.de/archives/241-Social-Bookmarks-Plugin-for-Serendipity.html ソーシャルブックマークプラグイン]（ダウンロードは Serendipity の [http://spartacus.s9y.org/index.php?mode=bygroups_sidebar_en Plugin/Template ページ]からできます）があります。
* [http://claimid.com claimID] は各人のリンクを xFolk で実装しています。
* [http://ma.gnolia.com ma.gnolia] は、現在 xFolk をサポートしています。
* [http://smarking.com/ Smarking.com]（ソーシャルブックマークサービス）はタグ付けされたリンクを xFolk でマークアップしています！豆知識：[http://3spots.blogspot.com/2006/05/social-bookmarking-smarking.html 3spots: Social + bookMARKING = Smarking]。このページ自体は [[hreview-ja|hReview]] です。
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - Tails エクステンションの Flock 0.5.12 移植版。hCard、hCalendar、xFolk、hReview を探して便利なツールバーに表示します（訳注：現在のバージョンの Flock には未対応のため、未確認）。
* [http://blog.codeeg.com/tails-firefox-extension/ Tails] は、ウェブページにマイクロフォーマット（[[hcard-ja|hCard]]、[[hcalendar-ja|hCalendar]]、[[hreview-ja|hReview]]、[[xfolk-ja|xFolk]]）ががあれば教えてくれる Firefox エクステンションです（訳注：Firefox 2 では動作しますが、Firefox 3 ではインストールできません）。
* Bud Gibson と Mike Migurski は、xFolk reblog ツールでありサービスである [http://thecommunityengine.com/veg-o-matic veg-o-matic] を [http://thecommunityengine.com/home/archives/2005/09/vegomatic_an_al.html 書きました]。
* [http://inside.glnetworks.de/ Martin Rehfeld] は [http://blogmatrix.blogmatrix.com/ David Janes] の仕事を改良して、xFolk を含む多くのマイクロフォーマット要素を見つけてポップアップメニューによって提供する [[Greasemonkey]] [http://inside.glnetworks.de/2006/06/05/microformats-have-arrived-in-firefox-15-greasemonkey-06/ スクリプト] を作りました。''これは現在、Firefox 1.5+/Greasemonkey 0.6.4+ で動作します。
* [http://www.midgard-project.org/midcom-permalink-6416db7e1f0e297b4cf3dcc285702a8d net.nemein.bookmarks] は [http://www.midgard-project.org/ Midgard CMS] 中のブックマーク管理プログラムで、書き出しのネイティブフォーマットとして xFolk を使用します。[http://bergie.iki.fi/links/ 例] 参照（2008年11月現在、確認できません）。
* [http://de.lirio.us de.lirio.us] は現在、xFolk 0.4（説明箇所で <code>extended</code> class 属性を使用）を使ってブックマークを公表しています（訳注：現在は Simpy に引き継がれ、そちらでは xFolk は使われていないようです）。
* [http://dev.blogmarks.net/wiki/BlogSync blogmarks] は現在、ブックマークをブログへ xFolk 0.4 を使ってエクスポートします（ページを下へスクロールしてのエクスポート例を見てください。<code>description</code> の代わりに <code>extended</code> class 属性を使っています）。
* [http://pokkari.com/microformat/javadoc/ Sivitols] は Java のマイクロフォーマット用ライブラリです（現在リンク切れ）。現在は xFolk RC1 標準しか実装されていませんが、より多くのマイクロフォーマットのサポートが予定されています。（出典は [http://blog.blip.tv/blog/microformats/]）
* [http://bildu.net Bildu] は xFolk（rel-tag も）をサポートするバスク語のソーシャルブックマークサービスです（訳注：サービスというより、使っているオープンソースソフトウェア [http://sourceforge.net/projects/scuttle/ scuttle] が xFolk をサポート）。
* [http://bookmarks.excite.co.uk/ Excite Bookmarks] は xFolk と rel-tag をサポートするソーシャルブックマークサービスです（訳注：2008年11月現在、rel-tag のみサポート）。

== 参照 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[rel-tag-ja|rel-tag]]

=== その他の参考文献 ===
* [http://thecommunityengine.com/home/archives/xfolk xFolk に関する記事]（リンク切れ）
* [http://thecommunityengine.com/home/archives/tags/microformats マイクロフォーマットのビジネス上の価値]（リンク切れ）
* [http://gataga.com gataga ソーシャルブックマーク検索エンジン]（ドメイン失効）
* [http://johnvey.com/features/deliciousdirector/ del.icio.us の ajax ベースのインターフェイス]
* [http://en.wikipedia.org/wiki/Social_bookmarking ウィキペディアでのソーシャルブックマークの定義]（[http://ja.wikipedia.org/wiki/ソーシャルブックマーク日本語]）

=== 関連作業 ===
* [[hreview-ja | hReview]]

== 現在の進行状況 ==
この仕様は最近バージョン RC1 のように安定し始めましたが、いまだ現在進行中です。望まれれば、ブックマークエントリーをできるだけ軽量にしてもっと広くアクセスできるようにするという目標のためには、リリース候補（release candidate）のバージョンを重ねる準備があります。前のバージョンからの変更は、開発者がこの狙いに限定して実装した経験を動機として行いました。以降の変更もおおむね実装上の関心を動機として行われるでしょう。このマイクロフォーマットの更なる可能性については下の「今後の方向性」をご覧ください。

=== xFolk 0.4 からの変更点 ===
もっと他のマイクロフォーマットの使用法と実装中に出てきたいくらかの要請に沿うため、class 属性の <code>extended</code> という値は廃止予定となり、<code>description</code> が推奨されています。また、実装上の使用例で見受けられたため、複数の要素で <code>extended</code> class を使ってもよいという変更もされました。

=== <div id=".E4.B8.BB.E3.81.AA.E6.96.B9.E5.90.91.E6.80.A7">今後の方向性</div> ===
xFolk の拡張はいくつか考えられます。そういった拡張には、たいていの場合 xFolk を他のマイクロフォーマットと組み合わせるのが一番の方法です。たとえば、ブックマークしたアイテムに関する自分の評価を表したいと思うかもしれません。これは xFolk と一緒に [[vote-links-ja | Vote Links]] か [[hreview-ja | hReview]] を使うことでできます。

また、全てのブックマークをタグ付きで提供するなど、xFolk を拡張して整合データに様々なソーシャルブックマークサービスの API を付けて提供することを考えるかもしれません。現在、どの標準でもこういった API の仕様はあまりに流動的です。API とそれが提供する機能は、ソーシャルブックマークサービスとメタサービスが自分を差別化する一つの方法を表しています。

"xFolk definition" という関係の深いフォーマットが開発中です。xFolk definition ではソーシャルブックマークで使われるタグを厳密に定義する手段を提供することになるでしょう。

=== ブレインストーミング ===
* [[xfolk-brainstorming|xFolk brainstorming]]

== 議論 ==

=== Q&A ===
* xFolk に関する疑問がある時には、[[xfolk-faq|xFolk FAQ]] をチェックしてください。もし答えが見つからなければ、質問してください！

=== 問題 ===
* この仕様の問題提起は、別ページの [[xfolk-issues|xFolk issues]] の文書に追加してください。

== 関連ページ ==
{{template:xfolk-related-pages}}
* [[xfolk-profile-ja|xFolk メタデータプロファイル]]（日本語）
* [[xfolk-issues-ja|xFolk の問題]]（日本語）

[[Category:xFolk]]

hcard-parsing

2010-05-12T14:58:19Z

KitaitiMakoto: Reverted edits by Empress09 to last version by Tantek

<h1>hCard parsing</h1>
{{TOC-right}}
by [http://tantek.com/log/ Tantek Çelik]

== introduction ==

When I first conceived of [[hcard|hCard]], it was clear to me how to unambiguously parse both for the existence of hCards in arbitrary (X)HTML (and anywhere that arbitrary (X)HTML can be embedded, e.g. RSS, Atom, "generic XML"), and hCard properties and values.

I worked directly with Brian Suda to capture these thoughts in an implementation, and Brian wrote X2V, an XSLT script that converts hCards to vCards, thus simultaneously demonstrating the parsability of hCards, and the immediate utility of hCard content interoperating with widespread existing vCard applications.

I am now documenting those thoughts directly here so that additional implementations, rather than having to reverse engineer X2V, can be built directly from these elementary concepts.

== scope ==
Although this page is written specifically to explain how to parse [[hcard|hCard]], the concepts and algorithms contained therein serve as an example for how other [[compound-microformat|compound microformats]] are to be parsed.

== URL handling ==
An hCard parser may begin with a <abbr title="Uniform Resource Locator">URL</abbr> to retrieve.

If the <abbr>URL</abbr> lacks a [http://www.w3.org/TR/html401/intro/intro.html#h-2.1.2 fragment identifier], then the parser should parse the entire retrieved resource for [[hcard|hCards]].

If the <abbr>URL</abbr> has a fragment identifier, then the parser should parse ''only'' the node indicated by the fragment identifier and its descendants, looking for [[hcard|hCards]], starting with the indicated node, which may itself be a single [[hcard|hCard]].

== root class name ==
Each compound microformat starts with a root element with a relatively unique class name. By that I mean a class name which isn't simply a common word, and is unlikely to have been used outside the context of the microformat. By choosing such a root class name the microformat avoids (for all practical purposes) colliding with existing class names that may exist within the (X)HTML context. This is essential to enabling such compound microformats to be ''embedded'' inside current, existing content, as well as future content.

Fortunately this is not a new problem to solve. The root object names chosen for vCard (RFC 2426) and iCalendar (RFC 2445) similarly had to avoid such collisions and did so by choosing names that were unlikely to have been introduced into a MIME object context. The principle of ''reuse'' dictates that we should reuse the names for these root objects in those RFCs rather than invent our own. Given the same semantics, a design should reuse the names, rather than inventing a second name for the same semantic (a common design mistake made in environments that require namespaces).

In the vCard specification, the names are case-insensitive due to the (lack of) requirements of their context. (X)HTML class names are case sensitive per those specifications. Thus we are required to pick a canonical case for the class name equivalents of vCard object and property names. All lowercase is chosen to follow the precedent (i.e. ''reuse'' the pattern) set by XHTML, which similarly had to canonicalize the case of element and attribute names that it took from HTML4, which itself was case-insensitive due to its context (SGML). Additionally, reasons for avoiding mixed-case (e.g. camel case) in the context of class names may be found in the essay [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class], specifically, the section titled [http://tantek.com/log/2002/12.html#atoc_csensitivity Class sensitivity].

Thus the root class name of an [[hcard|hCard]] is "vcard".

== finding hCards ==
An (X)HTML document indicates that it may contain [[hcard|hCards]] by referencing the [[hcard-profile|hCard XMDP profile]]. See [http://gmpg.org/xmdp/description XMDP] for more details.

A parser finds [[hcard|hCards]] in an (X)HTML context by looking for elements with the root class name ''vcard'' just as the following [http://www.w3.org/TR/REC-CSS2/selector.html#class-html CSS class selector] does:
<pre>
.vcard
</pre>

For example, the following CSS style statement sets the background of all [hcard|hCards] to green:
<pre>
.vcard { background: green; }
</pre>

Note that the (X)HTML class attribute is a space separated set of class names.

Thus all of the following are valid hCard root elements:
* <code><div class="vcard"> </div></code>
* <code> </code>
* <code><address class="vcard author"> </address></code>
* <code><li class="reviewer vcard first"> </li></code>

Once the root element of an [[hCard]] is found, that element and all its descendants (except those inside nested hCards) are all that is needed to parse the [[hCard]].

Thus it is possible for a well-formed [[hCard]] to be extracted from an overall non well-formed context, if the parser has the ability to find elements by class name within that non well-formed context.

== nested hCards ==
When parsing an hCard, if a parser finds a nested hCard, it should treat that hCard as its own object, and treat properties of the nested hCard as only belonging to the nested hCard, not the containing hCard.

This is essential for example for handling use of the "agent" property to nest an hCard that is the agent of another hCard. See [[hcard-examples-rfc2426#AGENT_Example_2|hCard examples from RFC2426 AGENT Example 2]] for an actual example.

Similarly, parsers should treat nested [[hCalendar]], [[hReview]], [[hResume]] [[xFolk]] in the same way, properties inside them {{must}} only apply to the nested microformat, not to the containing microformat.

All references below to "inside the hCard", "within the contents of the hCard", and similar phrasing {{must}} be interpreted with taking this nesting rule into account.

== hCard properties ==
The complete list of class names for hCard properties are documented in the [[hcard-profile|hCard profile]].

=== forward compatible parsing ===

When parsing the contents of an [[hCard]], any unrecognized class names must be ignored.

Similarly, unrecognized values for [[hCard]] properties must also be ignored.

=== finding hCard properties ===
To parse an hCard for an hCard property (e.g. "fn"), the parser simply looks for the first element with that class name inside the hCard.

This can also be expressed as the first element that matches this CSS selector:

<pre>
.vcard .fn /* note exception for nested hCards, see below */
</pre>

Some properties, like "fn", should only appear once, and thus the parser stops looking for the property after it has found the first occurrence in document order. Additional occurrences are ignored.

Other properties, like "adr", "email", "url", "tel", etc., may (and often do) appear more than once, and thus the parser continues to look for each occurrence within the contents of the hCard.

==== not finding nested hCard properties ====
Per the [[#nested_hCards|nested hCards rule]], properties inside a nested hCard {{must not}} apply to the current hCard being parsed. E.g. elements with class name "fn" that match this CSS selector:

<pre>
.vcard .vcard .fn
</pre>

{{must not}} affect the outer hCard.

=== parsing hCard properties and values ===
In general, once an element for a property is found, that element is used for the value.

In particular, once an element for a property is found:
# first, look for [[hcard-parsing#class_value_handling|class value children]] and use them as [[hcard-parsing#class_value_handling|described below]]
# otherwise, if there is a [[hcard-parsing#more_semantic_exceptions|more semantic exception]], use that as [[hcard-parsing#more_semantic_exceptions|described below]]
# finally, always fallback to using the contents of the element for the value

==== class value handling ====

For all properties, if the element for a property has one or more children with a class name of "value", then concatenate the node values for all those child elements with class name of "value", in their document order, and use that concatenation as the value of the property. (also called value excerpting)

==== more semantic exceptions ====

There are several exceptions to accomodate [http://microformats.org/wiki/hcard#Semantic_XHTML_Design_Principles semantic XHTML and more semantic equivalents].

===== email property =====
For the "email" property in particular, when the element is:
* <code><a href="mailto:..."></code> OR <code><area href="mailto:..."></code> : parse the value of the 'href' attribute, omitting the "mailto:" prefix and any "?" query suffix (if present), in the attribute. For details on the "mailto:" URL scheme, see RFC 2368.

===== tel property =====
For the "tel" property in particular, when the element is:
* <code><a href="tel:..."></code> OR <code><area href="tel:..."></code> : parse the value of the 'href' attribute, omitting the "tel:" prefix and any "?" query suffix (if present), in the attribute. For details on the "tel:" URL scheme, see RFC 2806.

===== properties of type URL or URI =====
For properties that may take type URL or URI parsers MUST handle relative URLs/URIs and normalize them to their respective absolute URLs/URIs, following the containing document's language's rules for resolving relative URLs/URIs (e.g. <base> for HTML, xml:base for XML).

===== properties of type URL or URI or UID =====
For properties that may take type URL, URI, or UID, when the element for that property is:
* <code><a href></code> OR <code><area href></code> : use the value of the 'href' attribute.
* <code><img src></code> : use the value of the 'src' attribute. If the 'src' is a "data:" URL, use the MIME type in that "data:" URL for the TYPE subproperty.
* <code><object data></code> : use the value of the 'data' attribute for the value. If the 'data' is a "data:" URL, use the MIME type in that "data:" URL for the TYPE subproperty, otherwise if the the 'type' attribute is present, us that for the TYPE subproperty.

===== properties not of type URL or URI or UID =====
For properties with values NOT of type URL, URI, or UID, when the element for a property is:
* <code><img alt></code> OR <code><area alt></code> : use the value of the 'alt' attribute.

===== all properties =====
For all properties, when the element for a property is:
* <code><abbr title></code>: use the value of the 'title' attribute. If there is no 'title' attribute then use the contents of the element.
** For properties which take an ISO8601 datetime value, parsers *should* pad any necessary precision (e.g. seconds), and *should* normalize any datetimes with timezone offsets, (e.g. <code>20050814T2305-0700</code>) into UTC (<code>20050815T060500Z</code>). Note that floating dates and times MUST NOT be made into UTC/Z absolute time zoned values.
* <code> </code> OR <code><hr /></code>: the value is the empty string. These two elements do not represent any semantics and thus it is probably an error (at least an abuse) for an author to use them with microformats class names. Nonetheless, if found, treat the value as empty.

==== white-space handling ====

hCard parsers should handle white-space parsing per XML white-space handling rules, with the following two additions:

# <code><pre></code> handling. Any content parsed as part of an hCard property that is inside a <pre> element must preserve all white-space per XML white-space preservation rules.
# <code> </code> handling. Any occurrence of a <code> </code> inside the element(s) for a value must be treated as a carriage-return (\n) in the respective location in the value.

=== hCard sub-properties ===

There are some hCard properties whose values themselves have structure (AKA structured type value) and are composed of multiple pieces, which we refer to as sub-properties.

For example, the "n" property consists of the sub-properties "family-name", "given-name", "additional-name", "honorific-prefix", and "honorific-suffix".

E.g. from section 3.1.2 of RFC 2426, modified to include Ph.D.

<pre>
N:Public;John;Quinlan;Mr.;Esq.,Ph.D.
</pre>

In [[hCard]] this "n" property would be marked up as

<pre>

Mr.
John
Quinlan
Public,
Esq.,
Ph.D.

</pre>

Which would be rendered as:

Mr. John Quinlan Public, Esq., Ph.D.

=== hCard property parameters ===

Some hCard properties have one or more parameters, most often "type", with an enumerated set of values. We represent the specific ''value'' of the parameter as a class name on an element inside the element representing the property.

For example, the "adr" property has a type parameter which takes the values: "dom", "intl", "post", "parcel", "home", "work", "pref".

The "type" parameter is treated like a sub-property.

To encode the "type" of an "adr" property, a nested element with class="type" is used to markup the value of the type parameter.

Example with the "tel" property with a value of type "work":

<pre>

work:
+1.123.456.7890

</pre>

=== Value excerpting ===

Note the element with class="value" used in the above example.

Sometimes only part of an element which is the equivalent for a property should be 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 introduced to excerpt out the subset of the element that is the value of the property.

Per the section in hCard on [[hcard#type_with_unspecified_value|type with unspecified value]], if the subtype is specified on a property, and there is no descendant of the property element with class name of "value", then the remainder (excluding the subtype) of the property element is considered the value.

== Include Pattern and Table Headers ==

When processing elements from the [[include-pattern]] or table headers inclusion methods, such elements should be processed as if they were inline.

== Proposed Additions ==
These are proposed additions to hCard parsing. Implementations MAY follow these conventions in order to gain implementation experience, and SHOULD report back on the results.

=== DEL element handling ===

When dealing with an HTML document that is hCard encoded, the parser SHOULD honor the <code><del></code> element.

There are two possibilities here (adopting both may be possible):

1. Skip any occurences of <code><del></code> elements and their contents entirely inside the contents of a property.

2. If the <code><del></code> element is used for a property itself, it could be useful as a way communication the of tombstoning / obsoleting of that particular property value, and thus while a parser that is converting to a vCard SHOULD simply do what is indicated in (1), applications which parsed hCard directly (rather than only supporting vCard) COULD treat such occurences of <code><del></code> elements as a way to remove obsolete information (with user confirmation of course) from a local contact information store.

=== Plain Text Formatting of Structural/Semantic HTML ===
There are several structural/semantic elements in HTML which have useful default styling which could be converted into ASCII (AKA Plain Text) equivalents as a low resolution way of communicating that structure. Note that <code> </code> and <code><pre></code> are already handled in the section above titled [http://microformats.org/wiki/hcard-parsing#white-space_handling White-space Handling].

When parsing the hCard <code>note</code> property (or <code>description</code> in hCalendar and hReview), hierarchically convert the following HTML tags into their plain text styling equivalents.

* <code><div></code>, <code></div></code>, <code><dl></code>, <code></dl></code>, <code><dt></code>, <code></li></code>, <code></dd></code> - Append a soft <code>\n</code> to the output. By "soft <code>\n</code>", we mean only do so if there isn't already a line break (in contrast to a "hard" (implied by default) <code>\n</code>). Two things in particular order to ensure that <code><div> <div></code> does not result in two <code>\n</code> characters in a row:
*# only output the <code>\n</code> if something other than whitespace (including <code>\n</code>) was outputted immediately previously.
*# omit any immediately subsequent whitespace characters.
* <code><li></code> - Append a soft <code>\n</code> and then </code> * </code>. (Note: Indenting the contents of the list item is not particularly practical, since that would require line-breaking, and that would depend on knowing the width of when the plain text is rendered. Wrapping to 70 characters may be a good assumption for plain text email, but is probably a very bad assumption for vCard output).
* <code></dt></code> - Append <code>:\n</code>
* <code><dd></code> - Append a soft <code>\n</code> and then </code> </code> (two space ASCII 32 characters).
* <code><h1></code>, <code></h1></code>, <code><h2></code>, <code></h2></code>, <code><h3></code>, <code></h3></code>, <code><h4></code>, <code></h4></code>, <code><h5></code>, <code></h5></code>, <code><h6></code>, <code></h6></code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>. (Note: we may want to consider some conventions to indicate the heading level. Perhaps only the relative heading level inside the property matters, e.g. whatever level HTML heading is seen first is treated as a first level heading, then any subsequent HTML heading elements are treated relative to that original heading (this is because it is likely that the property is embedded somewhere deep inside an HTML document following higher heading levels). Any subsequent higher level headings should perhaps cause a warning, and then simply be treated as a first level heading. Given that, the [http://microformats.org/wiki/wiki-formats#straw_proposals straw proposal for heading syntax] from Ian Hickson is one reasonable possibility, with the only issue being that for first and second level headings, how wide to make the line of '-'s or '='s, which is a similar problem to the line-breaking problem noted above when considering indenting the contents of list-items. Thus perhaps it might be sufficient to simply set a first level heading in ALL CAPS (same as the third level heading in Ian's proposed syntax), and let second and deeper level headings be simply implied by the "one line of text with two line breaks both before and after" convention. Rarely has there been more than one level of heading found within a DESCRIPTION property, and I've never seen more than two even if it is possible.)
* <code></code>, <code></code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>. (Note: Typical books indent the start of a paragraph approximately three spaces "<code> </code>", and implementations may wish to consider doing so as well. Keep in mind that on the Web, typical paragraphs do not start with a first line indent.)
* <code><q></code>, <code></q></code> - Append a double-quote '"' character.
* <code></code> - Append an open parenthesis "("
* <code></code> - Append a a close parenthesis ")".
* <code></code> - Append an open bracket "["
* <code></code> - Append a a close bracket "[". <code></code> are often used for footnotes which in plain text are often formatted as bracketed numbers.
* <code><table></code>, <code></table></code>, <code><tbody></code>, <code></tbody></code>, <code><thead></code>, <code></thead></code>, <code><tfoot></code>, <code></tfoot></code>, <code><tr></code>, <code></tr></code>, <code><caption></code>, <code></caption></code> - Append a soft <code>\n</code>. Of course one could try to do a lot more with representing the structure of the table, but that is almost certainly more work than it is worth, nevermind the complexities introduced by COLSPAN, ROWSPAN etc. At least by approximating the table sections and rows the table may be more readable.
* <code></td></code>, <code></th></code> - Append a space and a tab character (ASCII 32, ASCII 9 respectively). It's not clear that what subsequent application would be able to make use of this visually, but at least the tabular nature of the structure is indicated and it makes it possible to copy and paste the table into something that handles tabular content like a spreadsheet and have the tabular structure reflected.

==== More challenging elements ====
* <code><ol></code> - it would be nice to number list items inside an ordered list rather than bullet them, but keeping track of list item numbers/counts is a non-trivial piece of state information for the parser to deal with, and thus we are omitting this behavior for now.

==== Use of CSS computed styles instead of HTML default styles ====
Rather than assuming the default presentation for these elements, and using that for the basis of plain text formatting, a parser could use the respective equivalent computed style properties and use those instead. However, requiring an hCard parser to also implement Cascading Style Sheets (e.g. CSS1) is out of scope. Some environments (i.e. a browser DOM) may already provide this information, and in that case, it may be easy for an hCard parser (e.g. a clientside javascript parser) to use computed style properties. E.g. instead of the elements above, the following computed styles could be used:
* display:block - Append a soft <code>\n</code>
** text-indent (non-zero value, on an element with display:block or display:list-item) - Append a number of spaces equivalent to value of the text-ident property divided by the computed font-size property of the element.
** margin-top, margin-bottom (non-zero value, on an element with display:block or display:list-item) - Append a number of "\n" equivalent to the value divided by the computed font-size property of the element. Obviously this won't properly collapse vertical margins.
* display:list-item - Append a soft <code>\n</code> followed by " * "
* etc.
This is enough extra work that I'm not sure it is worth spending the time documenting more equivalents. The above are sufficient to illustrate the possibility.

== Outstanding Issues ==

=== Issues 3 ===

Might be worth considering defining the parsing in terms of the DOM, so that it applies to HTML and XHTML equally without ambiguity.

== Resolved Issues ==

This section is informative.

The following issues have been explored and resolved inline in the text of hcard-parsing above.

=== Resolved as of 2005-09-16 ===

==== ISSUE 1 ====

Should we make plural sub-property names into singular versions and simply allow multiple instances? I.e. the singular honorific prefix would make more sense if it was classed as such, and the list implied by the value for honorific-suffixes could be made more explicit (and thus more easily machine parseable):

<pre>

Mr.
John
Quinlan
Public,
Esq.,
Ph.D.

</pre>

RESOLUTION: Adopt singular class name equivalents for plural property and sub-property names.

==== ISSUE 2 ====

Restricting the "type" sub-property values to being expressed in class names seems less than ideal. It's taking a piece of information which is very often visible in the content, and forcing it to be invisible.

Here is an example of an extensive bit of contact information on a web page:

http://www.patchlink.com/company/contact.html

<pre>
Mailing Address
3370 N. Hayden Road, #123-175
Scottsdale, AZ 85251-6632

Physical Address
8515 E Anderson
Scottsdale, AZ 85255
</pre>

Note that the type information for each "adr" is explicit in the content. This content could be marked up like this:

<pre>
<div class="adr">
<abbr style="display:block" class="type" title="postal,parcel">Mailing Address</abbr>
<div class="street-address">3370 N. Hayden Road, #123-175</div>
Scottsdale, AZ
85251-6632
</div>
<div class="adr">
<abbr style="display:block" class="type" title="work,pref">Physical Address</abbr>
<div class="street-address">8515 E Anderson</div>
Scottsdale, AZ
85255
</div>
</pre>

RESOLUTION: The "type" parameter MUST be marked-up when content is available (like the above two examples). We are ditching the type-value-as-another class name pattern.

In addition since there are some potentical problems with the "type" parameter for TEL and EMAIL properties. Since there are no defined sub-properties (unlike ADR's post-code, locality, etc) the entire node-value of TEL is taken as the value. For example:
<pre>
+1.123.456.7890 <abbr class="type" title="work">(work)</abbr>
</pre>
would be represented in vCard as:
<pre>
TEL;TYPE=work:+123.456.7890 (work)
</pre>

We are introducing another sub-property class="value" to enable excerpting of a the value of an element of for a property.

<pre>
+1.123.456.7890 <abbr class="type" title="work">(work)</abbr>
</pre>

Then parsers would first need to look for class="value" and take the node value of that if it exists rather than class="tel".

If one or more child elements with the class name of "value" are present inside the element for a property, then concatenate the node values of those child elements (in the order found) and use that as the value of the property. This would be before using the node value of the element for a property itself.

== References ==

=== Normative References ===
* [[hcard|hCard]]
* vCard (RFC 2426)
* [http://w3.org/TR/XHTML1 XHTML 1.0 Recommendation]
* [http://w3.org/TR/html401 HTML 4.01 Recommendation]
* [http://gmpg.org/xmdp/ XMDP]

=== Informative References ===
* [http://w3.org/TR/REC-CSS1 CSS1 Recommendation]

== Related Pages ==
{{hcard-related-pages}}

Main Page

2010-05-11T14:23:18Z

KitaitiMakoto: Reverted edits by Larrsmith07 to last version by Tantek

Main Page-ja

2010-05-02T20:01:11Z

KitaitiMakoto: sync: english: 2010-05-02T19:01:28

<entry-title> Microformats Wikiにようこそ！</entry-title>

__TOC__
初めての方は、[[introduction-ja|Microformats の手引き]]からどうぞ。編集を始める前に、[[how-to-play-ja]]を読んでください。

== はじめに ==
この wiki は microformats コミュニティの中心的なリソースです。発表済みの microformats 仕様、仕様ドラフト、発表パターンの現在のバージョンを見つけることができます。新しいフォーマットのプレインストーミングページや、認められたフォーマットや開発中のフォーマットの問題追跡ページといった開発用のリソースもあります。

== スタートするには ==
Microformats を始めるには…

* まず、自分のページやアプリケーションで、意味的に豊かで説明的で、'[[posh-ja|<abbr title="Plain Old Semantic HTML">POSH</abbr>]]' な <abbr title="HyperText Mark-up Language">HTML</abbr> を書くことに慣れましょう。
* 「[http://microformats.org/about/ microformats について]」のページ、[http://microformats.org/ ブログ]、[[press|メディア紹介例]]や[[presentations-ja|プレゼンテーション]]、microformats に関する[[books|書籍]]、[[podcasts|ポッドキャスト]]、[[screencasts|スクリーンキャスト]]ページなどで microformats について学びましょう。
* [[hcard-ja|hCard]] や [[hcalendar|hCalendar]] などの確立した仕様を軽く読み、[[hcard-examples|examples]] に倣って microformats を公開しましょう。
* 質問がある場合は、[[faq|よく聞かれる質問]]や、用語と定義については[[glossary|用語集]]をご覧ください。 {{MicroformatsMailingList}}に投稿することもできます。
* 誰かから直接話を聞きたければ、[[events|microformats のイベント]]に参加してみてください。

== 定義 ==
Microformats とは、[[hcard-ja|人]]や[[hcalendar-ja|イベント]]、[[hatom|ブログ記事]]、[[hreview-ja|レビュー]]、[[rel-tag-ja|タグ]]のような、一般的に公開されているものをWebページ上で記述する際に使う小規模なマークアップの法則です。

Microformats を使えば、さらに詳しい情報をWebで発信することができるようになります。サイト上の情報のフィードやAPIを最も素早く簡単に提供するための手段といえます。

* [[what-are-microformats|Microformats とは何か]]、[[what-can-you-do-with-microformats|これを使って何ができるか]]についてもさらに詳しい説明があります。

== 協力するには ==
Microformats をさらに良くするには、みなさんの協力が必要です。

* Webサイトやサービス、製品で[[get-started|Microformats を利用]]する。
* マイクロフォーマットをもっと使ってもらえるよう、[[advocacy|周りにすすめる]]。
* [[testimonial|Microformats の推薦文]]を書く。
* [[to-do|TO DOリスト]]にあるタスクをこなす。
* [[irc-ja|IRCチャンネル]]や[[mail|メーリングリスト]]で学んだり、質問に答える (メールを送る前に、[[mailing-lists#General_guidelines|一般的なガイドライン]]を読んでください)。
* さまざまな言葉で読めるように、Microformats wikiの翻訳を手伝う ([[Main_Page-ja#.E4.BB.96.E8.A8.80.E8.AA.9E.E3.81.A7.E3.81.AE Microformats _wiki|他言語での Microformats wiki]])。
* 新しい Microformats を提案する前に、あなたのWebサイトが[[POSH]]であり、[[get-started|すでにある Microformats を利用]]済みである事を確認する。そのあと、[[process|新しいフォーマットを提案する際のプロセス]]について良く読む。

この wiki には microformats の開発と貢献を支援するために多数の改善が含まれています。編集を始める前に [[wiki-2|wiki 紹介ページの説明]]をご覧ください。

== 仕様 ==
以下は最新の安定版 [[microformats-ja|microformats]] の公開標準仕様一覧です。

* [[hcalendar-ja|hCalendar]] (翻訳中!) - [http://microformats.org/code/hcalendar/creator hCalendar creator]
* [[hcard-ja|hCard]] - [http://microformats.org/code/hcard/creator hCard creator]
* [[rel-license-ja|rel-license]]
* [[rel-nofollow-ja|rel-nofollow]]
* [[rel-tag-ja|rel-tag]]
* [[vote-links-ja|Vote Links]]
* [[XFN-ja|XFN]] - [http://gmpg.org/xfn/creator XFN creator]
* [[XMDP|XMDP]]
* [[xoxo-ja|XOXO]]

もし自分で microformats を作ってみたい場合は [[process]] ページをまずお読みください。

== ドラフト ==

ドラフトとは、まだ完成していない比較的新しい microformats です。開発過程を経ていくぶん成熟してはいますが、文書の安定性は保証されておらず、実装する側は将来開発と変更に対応する準備をしておくべきです。アップデートに備えて wiki ページに注意しておいてください。

* [[adr|adr]] - 住所のマークアップ
* [[geo|geo]] - [http://en.wikipedia.org/wiki/WGS84 世界測地系]による、緯度と経度のマークアップ
* [[hatom|hAtom]] - 更新情報を配信する (例: ブログの投稿)
* [[haudio|hAudio]]
* [[hlisting|hListing]] - オープンな分散的クラシファイド広告
* [[hmedia|hMedia]] - 画像、動画、音声に関する統一メディア公開フォーマット
* [[hnews|hNews]]
* [[hproduct|hProduct]]
* [[hrecipe-ja|hRecipe]] (翻訳中!) - お菓子や料理のレシピ
* [[hresume-ja|hResume]] (翻訳中!) - 履歴書の公開
* [[hreview-ja|hReview]] - [http://microformats.org/code/hreview/creator hReview creator]
* [[rel-directory]]- リンク先が、現在のページへのリンクを含んだディレクトリ一覧であることを表す
* [[rel-enclosure]] - ダウンロードやキャッシュ用の添付（ファイルなど）であることを表す
* [[rel-home]] - サイトのホームページへのリンクであることを表す
* [[relpayment|rel-payment]] - 支払いメカニズムであることを表す
* [[robots-exclusion|robots-exclusion]]
* [[xfolk-ja|xFolk]]

== デザインパターン ==
{{design_patterns-ja}} 

== 予備的な論議 ==
実際の[[examples|利用例]]の調査と分析、既存のフォーマット、Microformats の [[process]] を通じて新しい Microformats となる可能性のあるものについてのブレインストーミングついて、詳しくは[[exploratory-discussions|予備的な論議]]をご覧ください。

== 例 ==
* [[examples-in-the-wild-ja|実際の利用例]]
* [[implementations|ツールの実装]]
* [[zen-garden|Zen Garden]]

== リソース ==
[[resources|リソースページ]]をご覧ください。

== ユーザ中心開発 ==
*[[user-interface]]
*[[data-portability]]
*[[social-network-portability]]

== 共有作業領域 ==
* [[to-do|TODOリスト]]
* [[templates]]
* [http://microformats.org/wiki/delete pages for deletion] 
* [[Special:Specialpages|特別ページ]]
* [[year-in-review]]

== ツール、テストケース、リサーチ ==
例やコード、テストケースなどはそれぞれ個々の Microformats のページに記載しています。
ただほんの少しだけ、複数の Microformats の処理を必要とする分野横断的な[[tools|ツールとサービス]]があります。
[[tools|ツールとサービス]]は、複数の Microformats 全体に関連したエディタ、[[parsers|パーサ]]、[[validators|バリデータ]]、テストケース、およびその他の情報を対象としたページです。

== 他言語の Microformats Wiki ==
色んな言語で Microformats の記事を読んだり編集したりできます。

* 100個以上の記事がある言語
** [[Main_Page|English (本家の英語)]]
** [[Main_Page-fr|Français (フランス語)]] {{UpdateMarker-fr}}
* 10個以上の記事がある言語
** [[Main_Page-pt-br|Português (ブラジル系ポルトガル語)]]
** [[Main_Page-ja|日本語]]
** [[Main_Page-ru|Русский (ロシア語)]]
* 2個以上の記事がある言語
** [[Main_Page-cs|Česky (チェコ語)]] {{NewMarker}}
** [[Main_Page-de|Deutsch (ドイツ語)]]
** [[Main_Page-es|Español (スペイン語)]]
** [[Main_Page-gl|Galego (ガリーシア語)]] {{NewMarker}}
** [[Main_Page-pl|Polski (ポーランド語)]]
** [[Main_Page-ro|Română (ルーマニア語)]] {{NewMarker}}
** [[Main_Page-zh|汉语 (中国語)]]
** [[Main_Page-id|Indonesia (バハサ・インドネシア)]] {{NewMarker}}
* 翻訳が始まったばかりの言語
** [[Main_Page-fa|پارسی (ペルシア語)]] {{NewMarker}}
** [[Main_Page-ar|العربية (アラビア語)]]
** [[Main_Page-th|ภาษาไทย (タイ語)]]
** [[Main_Page-it|Italiano (イタリア語)]] {{NewMarker}}
** [[Main_Page-ko|한국어 (韓国語)]] {{NewMarker}}
* その他
**[http://ja.wikipedia.org/wiki/ Microformats Wikipediaの Microformats ページ]は、多くの言語版ができています。

[[other-languages]]や[[how-to-start-new-translation|how-to-start-a-new-translation]]もご覧ください。

hcard-ja

2010-04-29T21:29:54Z

KitaitiMakoto: /* 翻訳 */ "漢語" to "汉语"

<entry-title>hCard 1.0</entry-title>


<dfn style="font-style:normal;font-weight:bold">hCard</dfn> は、vCard ([[rfc-2426|RFC2426]]) のプロパティと値を利用して、[[semantic-xhtml|HTML]] で人や会社、組織や場所を表現する [[microformats-ja|microformat]] です。hCard は HTML や XHTML はもちろんのこと、Atom、RSS、その他の XML に埋め込むことができます。

'''hCard を利用するには、いくつかの方法があります。'''
*[http://blog.livedoor.jp/forestk/misc/microformats/hCard/creator-ja/ hCard creator] hCard を利用し、作成したコードをページにはりつける。
*[[hcard-authoring|hCard authoring tips]] を読んで、hCard のマークアップを行う。

<div class="vcard">
; 編集者
: [[User:Tantek|Tantek Çelik]] (http://tantek.com/, and before at [http://technorati.com Technorati, Inc.], and at [http://microsoft.com/ Microsoft Corporation])
</div>
; 作者: [http://tantek.com/ Tantek Çelik] (affiliations above)
: [[User:Brian|Brian Suda]] (http://suda.co.uk/)

; 謝辞: [[hcard-ja#原案及び謝辞|謝辞のセクション]]をご覧ください。

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

== 状態 ==
hCard 1.0 is a microformats.org specification. Public discussion on hCard takes place on [[hcard-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== 利用できる言語 ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== 訂正事項と更新事項 ===
Known errors and issues in this specification are corrected in [[hcard-issues-resolved|resolved]] and [[hcard-issues-closed|closed]] issues. Please check there before reporting [[hcard-issues|issues]].

The hCard 1.0.1 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

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

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

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

{{rfc-2119-intro-ja}}

== フォーマット ==
=== 基本情報 ===
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) のプロパティ名や値が、hCard の基礎となります。

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

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

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

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

'''必須プロパティ'''
* '''fn'''
* '''n'''[[#note1|1]] (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)

任意プロパティ
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value)
* agent
* bday
* category
* class
* email (type, value)
* geo (latitude, longitude)
* key
* label
* logo
* mailer
* nickname
* note
* org (organization-name, organization-unit)
* photo
* rev
* role
* sort-string
* sound
* tel[[#note2|2]] (type, value)
* title
* tz
* uid
* url

=== プロパティについて ===
[[#property-list-n|1. ^]]: 'n' プロパティは、[[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]にあるルールに当てはまる場合は、任意 ({{optional}}) プロパティとなります。 
[[#property-list-tel|2. ^]]: tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することができます ({{may}})。文字の入った電話番号 (例: +1-555-FORMATS) は、数字で表記しなければなりません ({{must}})。<code>abbr</code> を利用して、ソフトウェアには数字から成る電話番号の方を伝えることもできます (<code><nowiki><abbr title="+15553676287">+1-555-FORMATS</abbr></nowiki></code>)。

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

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

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

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

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

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

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

=== 値の抜粋 ===
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合は特別な class 名である "<code>value</code>" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップする hCard を例に取り説明しましょう。 

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>

home:
+1.415.555.1212

</source>

この hCard は次のように表示されるでしょう。

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

home:
+1.415.555.1212

</div>



=== プロパティの例外 ===
vCard には、Web ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。

# vCard の '''NAME'''、'''PROFILE'''、'''SOURCE'''、'''PRODID'''、'''VERSION''' プロパティは [[rfc-2426|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 文書の場合、<code><title></code> 要素) を用いることが推奨されます ({{should}})。PROFILE の値には、[[rfc-2426|RFC2426]] より "<code>VCARD</code>" の値を使うことができます ({{may}})。SOURCE プロパティには、ページの URL を用いることが推奨されます ({{should}})。hCard を vCard に変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODID プロパティは、実際に vCard を出力するサービスやアプリケーションのみが記述するべきです ({{should}})。同様に、そのようなアプリケーションのみが、[[rfc-2426|RFC2426]] のセクション 3.6.9 に倣い、VERSION プロパティに "3.0" という値をつけるべきです ({{should}})。

=== 組織のコンタクト情報 ===
もし、"FN" と "ORG"（organization；組織）プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、その hCard は会社や組織、場所のコンタクト情報を表すものとみなされます ({{should}})。このとき、作成者は "N" プロパティを記述することはできない ({{must-not}})、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます ({{should}})。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。

=== "n" の推測処理 ===
vCard では "N" プロパティの記述が必須となっています。ところが vCard 仕様書 ([[rfc-2426|RFC2426]]) では、最後の方 (p.38) にある作者の vCard に "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCard では次のように規定します。

もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります ({{must}})。しかし、組織名の場合はこのルールに当てはまりません。この場合は[[hcard-ja#.E7.B5.84.E7.B9.94.E3.81.AE.E3.82.B3.E3.83.B3.E3.82.BF.E3.82.AF.E3.83.88.E6.83.85.E5.A0.B1|組織のコンタクト情報]]で書かれているルールが適用されます。

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

これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。
* given-name (スペース) family-name
* family-name (コンマ) given-name
* family-name (コンマ) given-name のイニシャル
* family-name (スペース) given-name のイニシャル (任意のピリオド)

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語で名前を記述するときには、この推測処理を利用することはできません。必ず given-name、family-name プロパティを利用し、明示的に名前を記述しなければなりません。

<pre><nowiki>
<div class="vcard">

マイクロ
太郎

</div>
</nowiki></pre>
</div>

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

"nickname" の推測機構は [[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。

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

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

<source lang=html4strict>

daveman692

</source>

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

=== "organization-name" の推測処理 ===
"ORG" プロパティは organization-name と organization-unit という二つのサブプロパティを持っています。しかしほとんどの場合、作成者は organization-name のみを記述します。よって、もし "ORG" プロパティが "organization-name" プロパティを内側に持たない場合、"ORG" プロパティの内容は必ず "organization-name" とみなされます ({{must}})。

=== カテゴリーとしてのタグ ===
hCard のカテゴリーは [[rel-tag]] を用い、タグとして表現することも可能です ({{may}})。"category" プロパティが rel-tag である場合、そのタグはカテゴリーとして扱われます。

=== 'type' サブプロパティの値 ===
'type' サブプロパティがとる値は、その親プロパティによって異なります。これらの 'type' サブプロパティの値は大文字小文字を区別しません (case-INSENSITIVE)。よって "Home" は "home" と同じであり、その他の値と組み合わせた場合についても同様です。たとえば、家の電話番号で、かつ優先番号であるものは次のようになります。

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
Home (preferred):
+1.415.555.1212

</source>

この例は次のように表示されるでしょう。

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
Home (preferred):
+1.415.555.1212

</div>

==== type with unspecified value ====
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.

<source lang=html4strict>
Home +1.415.555.1212
</source>

is equivalent to:

<source lang=html4strict>
Home +1.415.555.1212
</source>

And thus the type is "home" and the value is "+1.415.555.1212".

==== adr tel email types ====
次のリストは ''参考情報'' です。

規範的な type の値は [[rfc-2426|RFC2426]] のセクション 3.2.1 ADR、3.3.1 TEL、3.3.2 EMAIL を参照してください (ここでは利便性の為にコピーしています)。type サブプロパティのデフォルト値はリストの最初に並んでおり、また大文字で記述されています。また、これらの type は複数指定することができます。

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref, "IANA に登録された他のアドレスタイプ"

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語などの言語では、これらサブプロパティの多くを利用することができません。サブタイプはマークアップの制限上、その内容を訳すことができないからです。
</div>

=== プロファイル ===
hCard の XMDP プロファイル は http://microformats.org/profile/hcard にあります。

hCard を使うコンテンツは、
<source lang=html4strict>
<head profile="http://microformats.org/profile/hcard">
</source>
や
<source lang=html4strict>
<link rel="profile" href="http://microformats.org/profile/hcard">
</source>
又は
<source lang=html4strict>
このコンテンツは <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a> を使っています。
</source>
などとしてこのプロファイルに触れるべきです（{{should}}）。
なお、上にある方法を組み合わせてもかまいません。

=== パース処理 ===
[[hcard-parsing|hCard parsing]] をご覧ください。

== hCard の例 ==
このセクションは参考情報です。

=== vCard のサンプル ===
次にあるのは vCard のサンプルです。
<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
END:VCARD
</nowiki></pre>

この vCard を hCard で表現すると次のようになります。なお、推測処理ができるプロパティについては省略してあります。他の例は [[hcard-example1-steps| hCard Example 1]] をご覧ください。

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

この hCard は次のように表示されるでしょう。
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]
</div>

Note: hCard のマークアップにはバージョン情報が必要ありません。なぜならバージョンは <head> 要素の 'profile' 属性に記述されたプロファイルで定義されているからです。

=== hCard の実例 ===
次にあるのは [http://www.commerce.net/ Commercenet] のコンタクト情報です。この情報は hCard を用いて記述されているので、microformats をパース処理するツールにより見つけることができます。

<div class="vcard">
<div class="fn org">'''CommerceNet'''</div>
<div class="url">'''<nowiki>http://www.commerce.net/</nowiki>'''</div>
<div class="adr">'''Work:'''
<div class="street-address">'''169 University Avenue'''</div>
'''Palo Alto''', '''CA'''  '''94301'''
<div class="country-name">'''USA'''</div>
</div>
<div class="tel">'''Work +1-650-289-4040'''</div>
<div class="tel">'''Fax +1-650-289-4041'''</div>
<div>'''Email <nowiki>info@commerce.net</nowiki>'''</div>
</div>

The mark-up, emboldening omitted for clarity, with the following semantic improvements:
* <code>abbr</code> to expand abbreviations
* hyperlinking the org name with the url

<source lang=html4strict>
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
Work:
<div class="street-address">169 University Avenue</div>
Palo Alto,
<abbr class="region" title="California">CA</abbr>  
94301
<div class="country-name">USA</div>
</div>
<div class="tel">
Work +1-650-289-4040
</div>
<div class="tel">
Fax +1-650-289-4041
</div>
<div>Email:
info@commerce.net
</div>
</div>
</source>

=== その他の例 ===
[[hcard-examples|hCard examples]] には vCard 仕様書 [[rfc-2426|RFC2426]] の例をすべて hCard にしたものをはじめ、もっとたくさんの例があります。

== 実世界での例 ==
このセクションは'''参考情報'''です。すでに世界には多くの hCard が存在しています。以前はこの仕様書で紹介していましたが、数が増えすぎてしまったため、別のページを用意しました。

[[hcard-examples-in-wild|hCard Examples in the wild]] で、実際に使われている hCard をご覧ください。

== 実装 ==
このセクションは'''参考情報'''です。前のセクションと同じく、hCard の実装についても別のページを用意しています。

[[hcard-implementations|hCard Implementations]] で、hCard の実装についてご覧ください。

== 記事 ==
このセクションは'''参考情報'''です。hCard の他の読み物は[[hcard-articles-ja|hCard の記事]]をご覧ください。

== hCard ボタン ==
hCard を使ったあなたのページに、次にあるボタンを貼り付けましょう。[[buttons#hCard]] には、最近追加されたボタンもあります。

* http://www.crowley.nl/images/hcard.png (ミラー:http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS でボタン風にデザインすることもできます。[http://re-run.com/about/microformat-badges microformat badges @ re-run] をご覧ください。

== 著作権 ==
仕様の作成者である [[User:Tantek|Tantek Çelik]] および [[User:Brian|Brian Suda]] が、自分のページでパブリックドメインの声明を行っています。よって、この仕様はパブリックドメインです。

{{MicroFormatPublicDomainContributionStatement}}

== 特許 ==
{{MicroFormatPatentStatement-ja}}

== 参考文献 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU 勧告 E.123] 電話番号フォーマット (有料)
* [[rfc-2119|RFC 2119]]

=== その他の参考文献 ===
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* [[iso-8601|ISO8601]]

==== hCard を利用する仕様 ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== hCard に似通っているもの ====
このセクションは'''参考情報'''です。
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== 原案及び謝辞 ==
このセクションは'''参考情報'''です。
vCard を "何年も前に" 教えてくれた私の良き友人 [http://vadim.com/ Vadim] に感謝しています。ただ、もしあのときから vCard を気にかけていたら、もっと多くの車輪の再発明を防げたかもしれませんが。

== vCard における由来 ==
このセクションは ''参考情報'' です。

<div id="Semantic_XHTML_Design_Principles">[[hcard-design-methodology]] をご覧ください。</div>

=== 意味的に同等なもの ===
いくつかのプロパティにおいて、その意味を上手く表現できる HTML 要素が存在します。次に挙げるプロパティは、その例に書かれている (X)HTML で表現すべきです ({{should}})。

* vCard の <code>URL</code> は hCard にて <code><a class="url" href="...">...</a></code> と表します。このプロパティは、<code>class="vcard"</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="Photo of ..." /></code>、または <code><object class="photo" data="..." type="...">Photo of ...</object></code> となります。
* vCard の <code>UID</code> hCard において、特定の URL (または EMAIL) といった、別の意味に置き換えられます。

=== 出現回数が一回のプロパティ ===
[[hcard-ja#.E3.83.97.E3.83.AD.E3.83.91.E3.83.86.E3.82.A3.E3.81.AE.E5.87.BA.E7.8F.BE.E5.9B.9E.E6.95.B0|プロパティの出現回数]]は、vCard RFC2426 で定義されるプロパティを一つずつ調べ、そのセマンティクスから一つのみでなければならない ({{must}}) を導き出したものです。[[hcard-singular-properties]] に解説があるので、そちらをご覧ください。

==== 単数化されたプロパティ ====
いくつかの複数系のプロパティ名が単数名化されています。このため、もし元となる複数形のプロパティが、複数のコンポーネントからなるひとつの値を取るものであっても、それらのコンポーネントは、単数名化されたプロパティを複数持つものとなります。

== 関連ページ ==
{{hcard-related-pages}}

[[Category:hCard]]

== 翻訳 ==
* [[hcard|english]]（英語）
* [[hcard-fr|français]]（フランス語）
* [[hcard-ru|Русский]]（ロシア語）
* [[hcard-zh|汉语]]（中国語）

Search engines-ja

2010-04-29T13:35:36Z

KitaitiMakoto: /* ブログ検索 */ translated rest

<entry-title>検索エンジン</entry-title>


{{TOC-right}}
ウェブ（つまり、自分のサイト以外も）を横断してマイクロフォーマットを索引化する検索エンジンの[[implementations|実装]]です。

== ウェブ検索 ==
一般的なウェブ検索です。一般にマイクロフォーマットを使ってウェブサイトを索引化する検索エンジンです。

=== Google ===
{{main|google-search}}

[http://google.com/ Google.com] はメインの検索で [[rel-nofollow-ja|rel-nofollow]]、[[hcard-ja|hCard]]、[[hreview-ja|hReview]]、[[hreview-aggregate|hReview の収集]]、[[hProduct]]（[http://www.google.com/support/webmasters/bin/answer.py?answer=99170 リッチスニペット]用に2009-05-12 以降）をサポートしています。Google は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://www.google.com/advanced_search 検索オプション - ライセンス]）と [[XFN-ja|XFN]] をサポートします。詳細は[[google-search|Google 検索]]をご覧ください。

=== Yahoo ===
{{main|yahoo-search}}
[http://search.yahoo.com Yahoo 検索]は [[rel-nofollow-ja|rel-nofollow]] をサポートしています。Yahoo は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://search.yahoo.com/cc Yahoo Creative Commons search]）をサポートしています。[http://developer.yahoo.com/search/boss/ Yahoo Search BOSS] や [http://developer.yahoo.net/blog/archives/2008/06/monkey_microformat.html Yahoo Search Monkey] を通して hCard、hCalendar、hReview、XFN、geo、rel-tag、adr をサポートしています。詳細は [[yahoo-search|Yahoo 検索]]をご覧ください。

== ブログ検索 ==
ブログの投稿とブログ一般の検索です。特にウェブ上でマイクロフォーマットを使ったブログ、ブログ投稿、その他リアルタイムのリソースを索引化する検索エンジンです。

=== IceRocket ===
* [http://www.icerocket.com IceRocket]、追加のインターフェイスを通じて
** [http://www.icerocket.com/tags IceRocket のタグ検索]は（[http://www.icerocket.com/c?p=tags rel-tag でタグ付けされたブログ投稿]を検索するために）[[rel-tag-ja|rel-tag]] をサポートしています。

=== Technorati ===
* [http://technorati.com Technorati] ([[rel-nofollow-ja|rel-nofollow]])
** [http://technorati.com/tags/ Technorati のタグ検索]は（rel-tag でタグ付けされたブログ投稿を検索するために）[[rel-tag-ja|rel-tag]] をサポートしています。

== プロトタイプやアルファ版 ==
=== socialsearchme ===
* [http://scrape.singpolyma.net/profile/ singpolyma social web search] ([[xfn]], [[hCard]]) part of the [http://code.google.com/p/diso/ diso] project.
** memorable URL: http://socialsearchme.com/
** e.g. try a [http://scrape.singpolyma.net/profile/?q=Jeremy search for Jeremy]
** 2008-08-19 [http://singpolyma.net/2008/08/diso-gets-search/ DiSo Gets Search] - blog post announcing it!
==== to do ====
* both <code>socialsearchme.com/?q=b</code> and <code>socialsearchme.com/b</code> should redirect/retrieve <code>scrape.singpolyma.net/profile/?q=b</code>.

=== Technorati Kitchen ===
* [http://kitchen.technorati.com Technorati Kitchen]
** [http://kitchen.technorati.com/contacts/search/ Technorati contacts search] ([[hCard]])
** [http://kitchen.technorati.com/events/search/ Technorati events search] ([[hCalendar]])

=== VIREL ===
* [http://virel.de/ VIREL] indexes both [[hCard]] and [[hCalendar]] and provides a user interface (pop-up menu) to choose between searching contacts or events.
** 2008-09-09 Tag Edge: [http://tagedge.com/2008/09/09/virel-microformats-search-engine/ Virel: Microformats Search Engine]

== マイクロフォーマットによる検索結果 ==
Search engines that publish microformats in their results (but may not necessarily be indexing microformats).
=== Karniyarik ===
* [http://www.karniyarik.com Karniyarik] Vertical Search Engine for Online Products ([http://www.karniyarik.com/karniyarik-web Stealth Beta]). Karniyarik's search results lists products and their vendors, which are marked up with [[hCard]] (e.g. [http://www.karniyarik.com/search.jsp?query=bebek+bezi search results for bebek bezi - diapers]). In addition, Karniyarik's [http://www.karniyarik.com/aboutus.jsp about page] is marked up with hCard.

== 関連ページ ==
* [[implementations]]

Search engines-ja

2010-04-29T13:31:39Z

KitaitiMakoto: /* ブログ検索 */ translated

<entry-title>検索エンジン</entry-title>


{{TOC-right}}
ウェブ（つまり、自分のサイト以外も）を横断してマイクロフォーマットを索引化する検索エンジンの[[implementations|実装]]です。

== ウェブ検索 ==
一般的なウェブ検索です。一般にマイクロフォーマットを使ってウェブサイトを索引化する検索エンジンです。

=== Google ===
{{main|google-search}}

[http://google.com/ Google.com] はメインの検索で [[rel-nofollow-ja|rel-nofollow]]、[[hcard-ja|hCard]]、[[hreview-ja|hReview]]、[[hreview-aggregate|hReview の収集]]、[[hProduct]]（[http://www.google.com/support/webmasters/bin/answer.py?answer=99170 リッチスニペット]用に2009-05-12 以降）をサポートしています。Google は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://www.google.com/advanced_search 検索オプション - ライセンス]）と [[XFN-ja|XFN]] をサポートします。詳細は[[google-search|Google 検索]]をご覧ください。

=== Yahoo ===
{{main|yahoo-search}}
[http://search.yahoo.com Yahoo 検索]は [[rel-nofollow-ja|rel-nofollow]] をサポートしています。Yahoo は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://search.yahoo.com/cc Yahoo Creative Commons search]）をサポートしています。[http://developer.yahoo.com/search/boss/ Yahoo Search BOSS] や [http://developer.yahoo.net/blog/archives/2008/06/monkey_microformat.html Yahoo Search Monkey] を通して hCard、hCalendar、hReview、XFN、geo、rel-tag、adr をサポートしています。詳細は [[yahoo-search|Yahoo 検索]]をご覧ください。

== ブログ検索 ==
ブログの投稿とブログ一般の検索です。特にウェブ上でマイクロフォーマットを使ったブログ、ブログ投稿、その他リアルタイムのリソースを索引化する検索エンジンです。

Search blog posts and blogs in general. Search engines that specifically index blogs, blog posts, and other realtime sources on the web using microformats.
=== IceRocket ===
* [http://www.icerocket.com IceRocket]、追加のインターフェイスを通じて
** [http://www.icerocket.com/tags IceRocket Tag search] support [[rel-tag]] (to search for [http://www.icerocket.com/c?p=tags blog posts tagged with rel-tag]).
=== Technorati ===
* [http://technorati.com Technorati] ([[rel-nofollow-ja|rel-nofollow]])
** [http://technorati.com/tags/ Technorati のタグ検索] は（rel-tag でタグ付けされたブログ投稿を検索するために）[[rel-tag-ja|rel-tag]] をサポートしています。

== プロトタイプやアルファ版 ==
=== socialsearchme ===
* [http://scrape.singpolyma.net/profile/ singpolyma social web search] ([[xfn]], [[hCard]]) part of the [http://code.google.com/p/diso/ diso] project.
** memorable URL: http://socialsearchme.com/
** e.g. try a [http://scrape.singpolyma.net/profile/?q=Jeremy search for Jeremy]
** 2008-08-19 [http://singpolyma.net/2008/08/diso-gets-search/ DiSo Gets Search] - blog post announcing it!
==== to do ====
* both <code>socialsearchme.com/?q=b</code> and <code>socialsearchme.com/b</code> should redirect/retrieve <code>scrape.singpolyma.net/profile/?q=b</code>.

=== Technorati Kitchen ===
* [http://kitchen.technorati.com Technorati Kitchen]
** [http://kitchen.technorati.com/contacts/search/ Technorati contacts search] ([[hCard]])
** [http://kitchen.technorati.com/events/search/ Technorati events search] ([[hCalendar]])

=== VIREL ===
* [http://virel.de/ VIREL] indexes both [[hCard]] and [[hCalendar]] and provides a user interface (pop-up menu) to choose between searching contacts or events.
** 2008-09-09 Tag Edge: [http://tagedge.com/2008/09/09/virel-microformats-search-engine/ Virel: Microformats Search Engine]

== マイクロフォーマットによる検索結果 ==
Search engines that publish microformats in their results (but may not necessarily be indexing microformats).
=== Karniyarik ===
* [http://www.karniyarik.com Karniyarik] Vertical Search Engine for Online Products ([http://www.karniyarik.com/karniyarik-web Stealth Beta]). Karniyarik's search results lists products and their vendors, which are marked up with [[hCard]] (e.g. [http://www.karniyarik.com/search.jsp?query=bebek+bezi search results for bebek bezi - diapers]). In addition, Karniyarik's [http://www.karniyarik.com/aboutus.jsp about page] is marked up with hCard.

== 関連ページ ==
* [[implementations]]

posh-ja

2010-04-29T07:57:48Z

KitaitiMakoto: sync: english: 2010-04-27T02:25:53

<div style="float:right;margin-left:1em">__TOC__</div>
<h1>Plain Old Semantic HTML (POSH)</h1>

<abbr title="Plain Old Semantic HTML">POSH</abbr>のホームページ（日本語版）へようこそ。（[[posh|英語版]]）

== 起源 ==
'''POSH'''という用語は、[http://rbach.priv.at/Microformats-IRC/2007-04-06#T091456 2007年4月6日にmicroformatsのIRCチャネルにおいて]、<kwijibo>によって考案されました。POSHとは、[[plain-old-semantic-html-ja|plain-old-semantic-html]]の頭文字を取った略語です。John Allsopp、Tantek Çelik、Jeremy Keith、Chris Messinaらが[[events/2007-04-18-web-2-expo-dinner|2007年4月18日のWeb 2.0 Expo後に行われたMicroformats Dinner]]で交わした議論を通して、microformatsのよりどころでありそれが正しいサブセットともなっているPOSHの発想と、そのより幅広い目標を広めることの重要性があらためて注目されました。詳しくは[[posh#History|POSHの歴史]]を参照してください。

== 理由 ==
[[semantic-html-ja|意味的（セマンティック）なHTML]]という用語はやや仰々しいため、それがどれほどシンプルなものであり昨今のウェブデザイナーたちの間でいかに確固たる支持を受けているかということも、意味的なマークアップを用いてウェブを真っ当に作ることだけにとどまらない大きなメリットをもたらすということも、うまく伝えられていません。私たちは、そのコンセプトの本質を的確に表現でき、簡単に動詞にも応用できるような（たとえば「to posh」「poshify」「poshed up」などという使い方ができるような）、覚えやすい用語を必要としていたのです。

== POSHとは？ ==
POSHとは、Webページを作成する際に[[semantic-html-ja|意味的なHTML]]を用いることのベストプラクティスを簡潔にあらわしたものです。意味的なHTMLとは、HTML 4.01（またはXHTML 1.0）にある要素と属性のなかで、''[[presentational-ja|表現的]]''ではなく''[[semantic-ja|意味的]]''なものから成るサブセットのこと。POSHを習い理解する最も良い方法は、実践することです。あなたのWebサイトからいちページを選び、[[posh-ja#POSH.E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.83.AA.E3.82.B9.E3.83.88|POSHチェックリスト]]を適用してください。[[posh-ja#POSH.E3.83.97.E3.83.AD.E3.82.BB.E3.82.B9|POSHプロセス]]に則り、そのまま続けてください。POSHについてより詳しく学ぶには、[[posh-ja#POSH.E3.83.AA.E3.82.BD.E3.83.BC.E3.82.B9|POSHリソース]]をお読みください。

== POSHプロセス ==
あなたがPOSHであるために、そしてあなたのウェブサイトをPOSHなものにするためには、何ができるでしょうか？

# POSHなコンテンツを公開する。[[posh-ja#POSH.E3.83.AA.E3.82.BD.E3.83.BC.E3.82.B9|POSHリソース]]に目を通し、あなたのウェブサイトでvalidな[[semantic-html-ja|意味的な(X)HTML]]を公開し、それに伴って[[semantic-class-names]]を使用するように心がけましょう。
# POSHを広める。このページへのリンクを貼って、他の人たちもPOSHになるように、そしてウェブサイトをPOSH対応させる（POSHify）ように勧めてみましょう。
# POSHを改善する。より多くの人が手軽にウェブサイトをPOSH対応させられるように、POSHリソースの収集をお手伝いください。

== POSHチェックリスト ==
* POSHの最初のルールとして、まずあなたのPOSHを必ず[http://validator.w3.org 検証]しましょう。
* 次に、単なる表現上の目的で使われているTABLEや、スペーサーGIF画像、いわゆる[[presentational-html|表現的なHTML]]を取り除きましょう。
* さらに、（BタグやBRタグの濫用を典型とする）[http://tantek.com/log/2002/10.html#L20021022t1432 その場しのぎ（'''B'''ed and '''BR'''eakfast）]のマークアップを修正しましょう。
* [http://tantek.com/log/2002/11.html#L20021128t1352 空っぽアンカー（Anorexic Anchors）]を取り除きましょう。
* よい[[semantic-class-names|意味的なクラス名]]を使いましょう。
* ...

== POSHリソース ==
=== POSHチュートリアル ===
Step by step tutorials to create POSH content or upgrade existing content to POSH.

* [http://westciv.com/style_master/house/tutorials/quick/validation/index.html Validating your css and html] A simple step by step guide to how and why you should validate your markup
* ...

=== POSH関連ブックマーク ===
* Ma.gnoliaの[http://ma.gnolia.com/groups/posh POSHグループ]をチェックしてみてください。
* See pages tagged both [http://del.icio.us/tag/posh+microformats POSH and microformats] on del.icio.us.

=== POSH関連プレゼンテーション ===
Presentations which explain and advocate concepts and techniques for utilizing semantic HTML. If/when this section gets too big, we can move it to [[posh-presentations]].
* [http://tantek.com/presentations/2003SXSW/stylesheets.html CSS: Between the Style Sheets by Tantek Çelik (2003-03)], specifically, see slides 3-4,6 starting with "Leaving the [http://tantek.com/log/2002/10.html#L20021022t1432 ed & eakfast]", and slide 9 "CSS & the Semantic Spectrum" which provides an overview of the semantic spectrum of (X)HTML tags.
* [http://www.tantek.com/presentations/2004etech/realworldsemanticspres.html real world semantics] (2004-02-11)
* [http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html Semantic XHTML: Can your website be your API? - Using semantic XHTML to show what you mean] (2004-09-28)
* [http://tantek.com/presentations/2005/09/elements-of-xhtml/ The Elements of Meaningful XHTML] (2005-09-29, first version: [http://tantek.com/presentations/2005/03/elementsofxhtml/ 2005-03-13 at SXSW Interactive]).
* ...
* See also more microformats [[presentations]] in general.

=== POSH関連書籍 ===
Modern web design books which document good semantic HTML practices.
* <cite>[http://www.oreilly.com/catalog/wdnut3/ http://www.oreilly.com/catalog/covers/0596009879_thumb.gif] [http://www.oreilly.com/catalog/wdnut3/ Web Design in a Nutshell, Third Edition]</cite> by Jennifer Niederst Robbins See [http://jenville.com/ Jenville].
* <cite>[http://microformatique.com/book/ Microformats empowering your markup for Web 2.0]</cite> by John Allsopp. Chapter 3 is a detailed and practical overview of the appropriate use of structural, valid and semantic HTML.
* <cite>[http://htmlmastery.com/ http://htmlmastery.com/images/hm-cover-sm.gif][http://htmlmastery.com/ Semantics, Standards and Styling]</cite> by Paul Haine.

=== POSH関連雑誌 ===
Online (and off) magazines which frequently publish articles about semantic HTML. If/when this section gets too big, we can move it to [[posh-magazines]].

* [http://alistapart.com/ A List Apart: For People Making Websites] (see in particular [http://www.alistapart.com/topics/code/htmlxhtml/ HTML and XHTML Articles])
* [http://www.digital-web.com/ Digital Web Magazine]

=== POSH関連ブログ ===
Blogs that with some regularity post high quality discussions, insights, and in general have advanced the state of the art of POSH. If/when this section gets too big, we can move it to [[posh-blogs]].

* [http://dbaron.org/log/current David Baron's weblog]
* [http://zeldman.com/ Jeffrey Zeldman Presents]
* [http://meyerweb.com/ meyerweb.com - Eric Meyer]
* [http://microformatique.com/ Microformatique - John Allsopp]
* [http://simplebits.com/ SimpleBits - Dan Cederholm] (see in particular [http://simplebits.com/bits/simplequiz/ SimpleQuiz])
* [http://tantek.com/ Tantek Çelik]
* ...

=== POSH関連ブログ記事 ===
Blog posts that provide specific, modern, guidance, techniques and tips for using more and better semantic HTML. This list is ''incomplete''. We know there are lots more blog posts out there that fit the aforementioned description - please add them! If/when this section gets too big, we can move it to [[posh-blog-posts]].

* [http://www.plaintxt.org/wp-content/uploads/sandbox-v09_readme.html The Sandbox theme for WordPress readme.html] discusses what POSH is and how the theme helps users use it.
* [http://tantek.com/log/2002/10.html#L20021022t1432 Bed and BReakfast markup (B&BR)] (2002-10-22) - avoiding nonsemantic uses of <nowiki>old and eak</nowiki> tags and using <nowiki><h3>adings and aragraphs</nowiki> instead.
* [http://tantek.com/log/2002/11.html#L20021128t1352 <nowiki><A>norexic </A>nchors</nowiki>] (2002-11-28) - use the "id" attribute on existing elements instead of adding empty <code><nowiki><a name="foo"></a></nowiki></code> elements. Use [[rel-bookmark]] for post permalinks within the document.
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class] (2002-12-16) - introduction to proper use of the HTML 'class' attribute.
* [http://tantek.com/log/2002/12.html#L20021231t1850 Dive into Semantic MARKup] (2002-12-31)
* [http://tantek.com/log/2003/01.html#L20030104t1249 Comment markup, presentation and plumbing] (2003-01-04) - how to markup a list of comments, including example use of the rare "hreflang" attribute.
* [http://meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competent Classing by Eric Meyer] (2004-07-18)
* [http://tantek.com/log/2004/07.html#d20t2359 More about the 'class' attribute] (2004-07-20)
* [http://www.uie.com/articles/holzschlag_interview/ Web Standards in the Real World: An Interview with Molly Holzschlag] (2005-06-01)
* [http://westciv.typepad.com/dog_or_higher/2005/11/webpatterns_and.html Webpatterns and websemantics] (2005-11-18)
* [http://www.thefutureoftheweb.com/blog/2006/2/writing-semantic-html Writing Semantic HTML by Jesse Skinner] (2006-02-22)
* [http://www.thefutureoftheweb.com/blog/2007/1/who-will-read-your-semantic-html Who will read your Semantic HTML?] by Jesse Skinner (2007-01-04)
* [http://microformatique.com/?page_id=109 Semantics in HTML] by John Allsopp (2007-01-08 - 2007-03-12)
** [http://microformatique.com/?p=83 Part I - Traditional HTML Semantics] (2007-01-08)
** [http://microformatique.com/?p=97 Part II - standardizing vocabularies] (2007-02-20)
** [http://microformatique.com/?p=108 Part III - Towards a semantic web] (2007-03-12)
* [http://microformatique.com/?p=82 Built in HTML semantics] A list of the semantic elements and attributes of HTML by John Allsopp (2007-01-08)
* [http://tantek.com/log/2007/04.html#d20t0823 The Importance of Being POSH] by Tantek Çelik (2007-04-20)
* [http://factoryjoe.com/blog/2007/04/21/getting-back-to-posh-plain-ol-semantic-html/ Getting back to POSH (Plain ol’ Semantic HTML)] by Chris Messina (2007-04-21)
* [http://friedcellcollective.net/outbreak/2007/04/22/im-posh-are-you/ I’m POSH - are you?] (2007-04-23)
* [http://www.unintentionallyblank.co.uk/2007/04/24/plain-old-semantic-html/ The Internet’s Upper Class Or Why Your Site Should Be POSH] (2007-04-24)
* [http://nate.koechley.com/blog/2006/12/15/divitis_and_correct_div_usage/ On Appropriate Use of DIVs, or When Divitis Doesn’t Apply] by Nate Koechley, 2006-12-15
* [http://nate.koechley.com/blog/2006/12/22/note_on_structural_and_semantic_meaning/ Quick Comment: Choose Class/ID Names Based on Semantic and/or Structural Meaning] by Nate Koechley, 2006-12-22
* [http://leland.nu/think/2006/07/31/seeing-is-believing/ SEEing is believing] - using standards and efficient design, coding, maintenance, and marketing to produce a search-engine-efficient site by Richard Leland (2006-07-31)
* ...

See [http://technorati.com/search/%22semantic%20HTML%22 more blogs talking about "semantic HTML"] and [http://technorati.com/search/posh+semantic+HTML POSH].

===POSH関連ポッドキャスト===
* [http://www.netmag.co.uk/podcasts/07-05-03-net.mp3 A talk about POSH] in the .Net magazine podcast episode 8 (56 minutes; 26 Mb. Relevant section 30:10-42:40)

=== POSHにまつわる隠れた情報源 ===
The following sites have POSH related articles, tutorials etc. on them, but you have to dig for them from the home page. Help find the hidden POSH treasures in these sites and add ''direct'' links to POSH related articles, tutorials etc. to the specific sections above. You can leave the top level site links here until/unless you have dug thru the entire site and found all the treasures.
* [http://www.w3schools.com/ W3Schools Online Web Tutorials]
* [http://dev.opera.com/ Dev.Opera]
* [http://phpforms.net/tutorial/tutorial.html/ php tutorials] - online web tutorials for beginners.

=== POSH Bling for your Blog ===
If you want to improve your existing blog, there are some pretty simple things you can do:

==== WordPress ====
* Use the [http://www.plaintxt.org/themes/sandbox/ Sandbox] or [http://getk2.com K2] themes that already support hAtom and hCard
* Add the [http://redmonk.net/archives/2007/04/18/wordpress-widget-hcard-about-box/ hCard About Widget] to your site

== POSHを広める ==
Now that you've poshified your website(s), what next? Well, help spread POSH to other websites!

* Promote POSH. Make a POSH button (perhaps using semantic HTML and CSS ;) linking to this page and put it on your site, in your blogroll, in your footer, etc. Maybe even come up with a nice POSH button graphic and share it with the microformats community with a liberal license (public domain, CC-by-3.0, MIT, etc.) Like these:
** [http://redmonk.net/archives/2007/04/25/the-new-question/ http://redmonk.net/wp-content/uploads/2007/04/are_you_posh.png] - [http://creativecommons.org/licenses/by/3.0/ CC-by-3.0]
** [http://redmonk.net/archives/2007/04/26/chic/ http://redmonk.net/wp-content/uploads/2007/04/chic_fancy.png] - [http://creativecommons.org/licenses/by/3.0/ CC-by-3.0]
* Tell a friend. Talk to web design friends about POSH and convince and help them to poshify both their personal websites, and the websites they build for others. Blog about your experience with poshification and what steps you went through to poshify your websites. Write a [[posh-testimonial]]!
* Come up with more ideas to help spread POSH. Here are a few.
** Hold a PoshPit - a one or half day marathon session mixing semantic HTML experts with folks who maintain/run web sites in general and see how many websites you can collectively upgrade to POSH during the course of the day.
** ...

== POSHを改善する ==
As you read the [[posh#Resources|POSH resources]] documented here, what other POSH resources did you find? Add them to this page.

With your experience with both poshifying your sites and helping others do so, what have you learned? What kind of [[posh-issues|issues]] did you run into? What questions were commonly asked? What do you feel like you need to more easily and quickly help more people poshify their content?

== 歴史 ==
A brief history of references to "POSH" in this context and "plain old semantic HTML".

=== plain old semantic HTML ===
The earliest references to "plain old semantic HTML" that have been found so far are:
* [http://groups.google.com/group/comp.infosystems.www.authoring.site-design/msg/2373e9043c08cba4 1998-05-01: Kirrily 'Skud' Robert on comp.infosystems.www.authoring.site-design] - "The site is implemented in HTML 4.0 Transitional with style sheets; this means that anyone with an older browser won't get presentational markup, just plain old semantic HTML. "
* [http://www.highrankings.com/advisor/tables-seo/ 2006-09-21 Drew's comment by on "Tables and SEO"]: "I’d say it’s well worth it for a variety of reasons to only use tables when you’re presenting tabular data, and use plain old semantic HTML to mark up your content in all other cases." (retrieved by [[User:Tantek|Tantek]] 08:20, 20 Apr 2007 (PDT))
If you can find earlier references, please ''add'' them and include a brief quotation of the context of the reference to "plain old semantic HTML".

hcard-ja

2010-04-29T07:45:51Z

KitaitiMakoto: added a link to Chinese page

xfolk-ja

2010-04-26T11:55:49Z

KitaitiMakoto: /* その他の参考文献 */ translated

<entry-title>xFolk RC1</entry-title>

{{DraftSpecification-ja}}

'''xFolk'''（"xFolksonomy"に由来）は、ブックマークのコレクションを公開するための簡単でオープンなフォーマットです。これによって、サービスがウェブベースのブックマークソフトウェアでのユーザー体験の向上とデータの共有をよりうまくできるようになります。xFolk は HTML または XHTML、Atom、RSS、任意の XML に埋め込むことができます。これはオープンな[[microformats-ja|マイクロフォーマット]]標準の一つです。

__TOC__

== 仕様ドラフト ==

=== 編者/作者 ===
[http://thecommunityengine.com/ Bud Gibson] ([http://thecommunityengine.com The Community Engine])

=== 著作権 ===
{{MicroFormatCopyrightStatement2005}}

=== 特許 ===
{{MicroFormatPatentStatement-ja}}

=== 謝辞 ===
各項目が、部分的に、一度にたくさんのカテゴリーに属していてもかまわないというアイディアをもたらしてくれた [http://www.cnbc.cmu.edu/~plaut/ David Plaut] に感謝します。また、より最近ですが、思慮深い批評と推進で xFolk の開発に貢献してくれた [http://tantek.com/ Tantek Celik]、[http://epeus.blogspot.com/ Kevin Marks]、[http://steve.osdir.com/ Steve Mallet]、[http://hybernaut.com/ Brian DelVecchio]、[http://blogmarks.net Francois Hodierne]に感謝します。

== はじめに ==
ソーシャルブックマークサービスでは、ユーザーはブックマークを保存し、タグを付け、ほかのユーザーと共有します。ここ数年でこういったサービスの数は[http://en.wikipedia.org/wiki/Social_bookmarking 20を超え]、その中には[http://del.icio.us del.icio.us]、[http://furl.net furl]、[http://de.lirio.us de.lirio.us]（訳注：現在は [http://www.simpy.com/ Simpy] に引き継がれたようです）、jots（訳注：現在はサービス終了）、[http://blogmarks.net blogmarks]という人気サービス例も含まれます。

相互運用可能なデータのオープンスタンダードがないことは、ソーシャルブックマークサービスを使う上での大きな問題です。オープンスタンダードがあればソーシャルブックマークデータを簡単に集めて再構築し、gataga（訳注：現在はサービス終了）による実験的なブックマーク検索エンジンのような方向性の、新しいサービスを発明することが可能になるのです。また、[http://johnvey.com/features/deliciousdirector/ 目下は del.icio.us で行われている]ような、サービスをまたがって機能する JavaScript を書いてユーザー体験を全面的に向上させることもできるようになります。

xFolk は両方の利点を持つことを目標にした、ソーシャルブックマークのオープンスタンダードです。xFolk を取り入れたソーシャルブックマークサービスは、データサービスの一歩先を歩くことになるでしょう。ですが、データ自体はサードパーティのスクリプトが操作したり、共有したりすることが簡単な物になります。その結果、ブックマークサービスは低コストでユーザーに幅広い選択肢を提供し、本質的な差別化に力を注ぐことができるようになります。独立したブックマーク保管サービスを運営する個人やグループは、自分で作れる以上の幅広い機能を選べるようになります。

== セマンティック XHTML デザイン指針 ==
{{semantic-xhtml-design-principles-ja}}

== フォーマット ==
ソーシャルブックマークサービス、リンクブログ（訳注：リンクとそれに対するコメントからなるブログ）、[http://thecommunityengine.com/home/archives/xfolk 他所]でのリポートを幅広く分析した結果、ブックマークサービスと'''たくさんの'''異なるリンクブログで公開されているデータは暗黙的に次のスキーマに従って書かれていることが分かりました。

* ブックマークしたりタグを付けるリンク
* エントリーの題名
* リンクに付けるタグ
* リンクの追加説明や概要

初期の xFolk 標準が繰り返し使われたおかげで、この一般的なスキーマは次のようにしてマークアップへと変換できることが実証されています。

# 各エントリーに <code>xfolkentry</code> という class を持つコンテナ要素を作る
# ブックマークしたりタグを付けるリンクには <code>taggedlink</code> という class を持つ <a> 要素を使う
# エントリーの題名には、もしあれば <a> 要素の title 属性を、なければその値を使う
# タグには [[rel-tag-ja|rel-tag]] を使う
# 追加説明や概要には、<code>description</code> という class を持つコンテナ要素（ など）を使う

xFolk エントリーでは、題名を伴ったタグを付けるリンクが必須で、他の要素は全て省略できます。エントリーには複数のタグあってもかまいませんし、<code>description</code> class の要素が複数あってもかまいません。<code>description</code> class を持つ複数の要素の順序は、文書に現れるままの順です。xFolk エントリー内の意味的な要素は任意の深さにネストできます。

たくさんのソーシャルブックマークシステムが存在して、それぞれが独自のマークアップの慣例を持っています。さらに、たくさんの人が既に個人のリンクブログを公表しています。xFolk の第一の目標は、こうした現在の慣例に適合させるのが簡単であるようデザインすることなので、xFolk エントリーで使う要素の種類には厳密な前提条件がほとんどありません。意味を決める機能は、要素よりも class 属性や（[[rel-tag-ja|rel-tag]] の場合は）rel 属性の値に与えられるのです。

開発者は [http://www.w3.org/TR/xpath XPath] か相当する文法を使って xFolk エントリーの要素にアクセスすることが期待されます。XPath を使うための条件は、HTML 文書が整形式であることです。妥当な文書ではなくてもかまいません。このため、最善ではないかもしれませんが、妥当性検証をしていない HTML 文書の中で xFolk が使えるようになるのです。

=== XMDP プロファイル ===
xFolk の [http://gmpg.org/xmdp XMDP] プロファイルは、[[xfolk-profile-ja|xFolk profile]] を参照してください。

== 例 ==

下に [http://del.icio.us del.icio.us] の標準マークアップに見られるブックマークの例を示します。要素の class 属性の値を変更して xFolk に適合させる必要のある場所は、行の末尾にコメントで印を付けています。
<pre><div class="post"> 
<div>
<a class="delLink" href="http://www.sifry.com/alerts/archives/000306.html"> 
Sifry's Alerts: Technorati launches Related Tags
</a>
</div>
<div class="extended"> 
Ever wanted to see what posts are related to other posts, what tags
are related to others? Now you can! Just check under the Tag
description on most tag pages, like this one, or this one, and you'll
see the patterns. Can you smell the emergence?
どの投稿がどの投稿と関係あるのか、どのタグがどのタグと関係あるのか、
分かるようになってほしいとずっと思ってた。ようやくなった！
こことかこことか、ほとんどのタグページでタグを記述した部分の下をチェックしてほしい。
何かが起きそうなにおいがするだろ？
（訳注：『Emergence』は書名。邦題は『創発―蟻・脳・都市・ソフトウェアの自己組織化ネットワーク』。
　個の局所的な働きが全体の組織だった働きを生むという現象を解説）
</div>
<div class="meta">
to
<a class="delNav" href="/fpgibson/folksonomy">folksonomy</a> 
<a class="delNav" href="/fpgibson/technorati">technorati</a> 
... <a class="delNav" href="/url/cbcabf7de070fdb46598ee679367be49">
and 1 other person
</a>
... on 2005-04-09
</div>
</div></pre>

これに相当する xFolk は以下の通りです。class 属性の変更が必要だった行の末尾にコメントを付けています。
<pre><nowiki>
<div class="xfolkentry"> 
<div>
<a class="taggedlink" href="http://www.sifry.com/alerts/archives/000306.html"> 
Sifry's Alerts: Technorati launches Related Tags
</a>
</div>
<div class="description"> 
Ever wanted to see what posts are related to other posts, what tags
are related to others? Now you can! Just check under the Tag
description on most tag pages, like this one, or this one, and you'll
see the patterns. Can you smell the emergence?
どの投稿がどの投稿と関係あるのか、どのタグがどのタグと関係あるのか、
分かるようになってほしいとずっと思ってた。ようやくなった！
こことかこことか、ほとんどのタグページでタグを記述した部分の下をチェックしてほしい。
何かが起きそうなにおいがするだろ？
</div>
<div class="meta">
to
<a rel="tag" href="/fpgibson/folksonomy">folksonomy</a> 
<a rel="tag" href="/fpgibson/technorati">technorati</a> 
... <a class="delNav" href="/url/cbcabf7de070fdb46598ee679367be49">
and 1 other person
</a>
... on 2005-04-09
</div>
</div>
</nowiki></pre>

マークアップを xFolk に従う物に変換するのは、ほとんどの場合簡単です。xFolk の長所は、
全てのサービスやリンクブログにまたがって、精度を失うことの無いまま使い回せる class 属性のセットを提供していることです。
次の節ではこの点を説明する例をさらに多く提示します。

下は（リストのマークアップを使った）別の簡単な例です。
<pre>
<nowiki>
<ul>
<li>
<ul class="xfolkentry">
<li><a class="taggedlink" href="http://microformats.org/wiki/Main_Page">microformats wiki</a></li>
<li class="description">マイクロフォーマットを勉強して実践する主な場所で……</li>
<li class="description">コミュニティ駆動の Wiki</li>
<li class="meta">
Tags :
<a rel="tag" href="http://del.icio.us/tag/microformats">microformats</a>
<a rel="tag" href="http://del.icio.us/tag/websocial">websocial</a>
<a rel="tag" href="http://del.icio.us/tag/semantics">semantics</a>
</li>
</ul>
</li>

<li>

</li>

</ul>
</nowiki>
</pre>

== より多くの例 ==

開発者がサイトに xFolk を取り入れるのに役立つ例がたくさんあります。

=== 実世界での例 ===

実際に機能中の、xFolk でブックマークを公開しているシステムの例です。パース、索引作成、整理などを試せる「実際に利用されている」例を探し始めるには絶好でしょう。自分が xFolk を使ってブックマークを公表しているなら、遠慮せずそのサイトをこのリストの一番上に加えてください。リストが大きくなり過ぎたら、別の Wiki ページを作ります。

* [http://greenvoice.com Greenvoice] はユーザーが作る環境ニュースのリンクリストで、xFolk でマークアップされています。
* [http://www.idoneos.com Idoneos.com] はコンセプトごとに繋がった情報ページ（多くはスペイン語）のコレクションで、xFolk を使ってブックマークにタグ付けしています。
* [http://ashaszin.lautre.net/ Ashaszin] - [http://spip.net SPIP] を使って運営されている小さなブログ。xFolk でタグ付けした del.icio.us リンクとウェブフィードがあります。
* [http://www.rolandinsh.lv/blog/ Rolands Umbrovskis - blog] ブログの記事は全て xFolk でマークアップされています。
* [http://www.bbc.co.uk/worldservice/bangladeshboat BBC World Service Bangladesh River Journey] はソーシャルネットワークマッシュアップで、hAtom エントリーのブックマークに、基本的な xFolk を使っています。[http://dharmafly.com/blog/bangladeshboat Dharmafly のブログでの議論] を参照。
* [http://waferbaby.com/hussy waferbaby の Hussy] は、現在 xFolk を使ってリンクを公開しています（訳注：2008 年 11 月現在、確認できません）。
* [http://smarking.com/ Smarking] は、現在 xFolk を使って（検索結果を含む）共有リンクを公開しています。
* [http://unalog.com unalog] は、現在 xFolk を使って（検索結果を含む）共有リンクを公開しています（訳注：現在終了）。
* [http://de.lirio.us de.lirio.us] は、現在 xFolk を使ってブックマークを公開しています（<code>description</code> の代わりに、廃止予定の <code>extended</code> という class 属性を使っています。[[xfolk-profile-ja |XMDP]] を参照）（訳注：現在は [http://www.simpy.com/ Simpy] に引き継がれ、そちらでは xFolk は使用されていないようです）。
* [http://blogmarks.net/my/tools,export blogmarks] は現在、ブログへのブックマークを xFolk でエクスポートします（訳注：アカウント未所持のため、未確認。通常ページでは xFolk を使用しています）。
* [http://thecommunityengine.com The Community Engine] は、[http://thecommunityengine.com/home メインエントリー]と[http://thecommunityengine.com/webcites 公開ブックマーク]で xFolk を使っています（<code>description</code> の代わりに、廃止予定の <code>extended</code> という class 属性を使っています。[[xfolk-profile-ja |XMDP]] を参照）。
* [http://groovymother.com/links/ Groovy Links] は xFolk でマークアップされているリンクブログです（訳注：現在はこのページは無く、[http://groovymother.com/ ホームページ]が対応）。
* [http://tommorris.org/blog/ Tom Morris] - 日々の del.icio.us リンクが xFolk、[[hcard-ja|hCard]]、[[vote-links-ja|Vote Links]] でマークアップされています。

=== <div id=".E3.81.95.E3.82.89.E3.81.AA.E3.82.8B.E3.82.BD.E3.83.BC.E3.82.B7.E3.83.A3.E3.83.AB.E3.83.96.E3.83.83.E3.82.AF.E3.83.9E.E3.83.BC.E3.82.AF.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9" name=".E3.81.95.E3.82.89.E3.81.AA.E3.82.8B.E3.82.BD.E3.83.BC.E3.82.B7.E3.83.A3.E3.83.AB.E3.83.96.E3.83.83.E3.82.AF.E3.83.9E.E3.83.BC.E3.82.AF.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9">ソーシャルブックマークサービスへの付加</div> ===

次の例では、一つのサービスに、どのようにして xFolk を適用できるのかが説明されています（訳注：現在の scuttle 0.7.4 では xFolk を使ってリンクがマークアップされています）。

* [[xfolk-scuttle | scuttle]]

=== リンクブログ ===

ソーシャルブックマークサービスは、人々がリンクを公開する最近の例と言うに過ぎません。リンクブログは、ほとんどブログの初期の頃からありました。これはその発端から、あまり意味的でないマークアップをされる傾向があったため、xFolk にするにはもう少し労力を使う必要があります。次の例は、個別の作業説明し、それぞれがどのようにしてうまくいくのかを描いています。

* [[xfolk-kottke | kottke]]
* [[xfolk-pollas | pollas]]
* [[xfolk-jacobian | jacobian]]
* [[xfolk-julian-bez | julian-bez]]

=== スパム ===
スパム業者には、リンクファームにタグを付けるのに xFolk を利用している所もあります。（恐らく、実際にそのサイトにリンクさせるには、悪いアイディアでしょう。）例えば、
* phontron.info

== 実装 ==

次の実装は、xFolk を作ったり使ったりして開発されました。もし xFolk の実装を持っていたらこのリストの一番上に自由に加えてください。リストが大きくなり過ぎた時には、別の Wiki ページを作ります。

* [http://buzka.com Buzka]はソーシャルブックマークサービスで、現在は xFolk をサポートしています（訳注：2008年11月現在はサポートされていないようです）。
* [http://blip.tv Blip.tv]は動画ホスティングサイトで、現在は [http://blog.blip.tv/blog/2006/08/19/blip-supports-xfolk/ xFolk をサポートしています]（訳注：2008年11月現在はサポートされていないようです）。
* [http://www.s9y.org/ Serendipity] は PHP によるフレキシブルなブログ/CMS アプリケーションです。現在、xFolk をサポートする[http://www.numblog.de/archives/241-Social-Bookmarks-Plugin-for-Serendipity.html ソーシャルブックマークプラグイン]（ダウンロードは Serendipity の [http://spartacus.s9y.org/index.php?mode=bygroups_sidebar_en Plugin/Template ページ]からできます）があります。
* [http://claimid.com claimID] は各人のリンクを xFolk で実装しています。
* [http://ma.gnolia.com ma.gnolia] は、現在 xFolk をサポートしています。
* [http://smarking.com/ Smarking.com]（ソーシャルブックマークサービス）はタグ付けされたリンクを xFolk でマークアップしています！豆知識：[http://3spots.blogspot.com/2006/05/social-bookmarking-smarking.html 3spots: Social + bookMARKING = Smarking]。このページ自体は [[hreview-ja|hReview]] です。
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - Tails エクステンションの Flock 0.5.12 移植版。hCard、hCalendar、xFolk、hReview を探して便利なツールバーに表示します（訳注：現在のバージョンの Flock には未対応のため、未確認）。
* [http://blog.codeeg.com/tails-firefox-extension/ Tails] は、ウェブページにマイクロフォーマット（[[hcard-ja|hCard]]、[[hcalendar-ja|hCalendar]]、[[hreview-ja|hReview]]、[[xfolk-ja|xFolk]]）ががあれば教えてくれる Firefox エクステンションです（訳注：Firefox 2 では動作しますが、Firefox 3 ではインストールできません）。
* Bud Gibson と Mike Migurski は、xFolk reblog ツールでありサービスである [http://thecommunityengine.com/veg-o-matic veg-o-matic] を [http://thecommunityengine.com/home/archives/2005/09/vegomatic_an_al.html 書きました]。
* [http://inside.glnetworks.de/ Martin Rehfeld] は [http://blogmatrix.blogmatrix.com/ David Janes] の仕事を改良して、xFolk を含む多くのマイクロフォーマット要素を見つけてポップアップメニューによって提供する [[Greasemonkey]] [http://inside.glnetworks.de/2006/06/05/microformats-have-arrived-in-firefox-15-greasemonkey-06/ スクリプト] を作りました。''これは現在、Firefox 1.5+/Greasemonkey 0.6.4+ で動作します。
* [http://www.midgard-project.org/midcom-permalink-6416db7e1f0e297b4cf3dcc285702a8d net.nemein.bookmarks] は [http://www.midgard-project.org/ Midgard CMS] 中のブックマーク管理プログラムで、書き出しのネイティブフォーマットとして xFolk を使用します。[http://bergie.iki.fi/links/ 例] 参照（2008年11月現在、確認できません）。
* [http://de.lirio.us de.lirio.us] は現在、xFolk 0.4（説明箇所で <code>extended</code> class 属性を使用）を使ってブックマークを公表しています（訳注：現在は Simpy に引き継がれ、そちらでは xFolk は使われていないようです）。
* [http://dev.blogmarks.net/wiki/BlogSync blogmarks] は現在、ブックマークをブログへ xFolk 0.4 を使ってエクスポートします（ページを下へスクロールしてのエクスポート例を見てください。<code>description</code> の代わりに <code>extended</code> class 属性を使っています）。
* [http://pokkari.com/microformat/javadoc/ Sivitols] は Java のマイクロフォーマット用ライブラリです（現在リンク切れ）。現在は xFolk RC1 標準しか実装されていませんが、より多くのマイクロフォーマットのサポートが予定されています。（出典は [http://blog.blip.tv/blog/microformats/]）
* [http://bildu.net Bildu] は xFolk（rel-tag も）をサポートするバスク語のソーシャルブックマークサービスです（訳注：サービスというより、使っているオープンソースソフトウェア [http://sourceforge.net/projects/scuttle/ scuttle] が xFolk をサポート）。
* [http://bookmarks.excite.co.uk/ Excite Bookmarks] は xFolk と rel-tag をサポートするソーシャルブックマークサービスです（訳注：2008年11月現在、rel-tag のみサポート）。

== 参照 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[rel-tag-ja|rel-tag]]

=== その他の参考文献 ===
* [http://thecommunityengine.com/home/archives/xfolk xFolk に関する記事]（リンク切れ）
* [http://thecommunityengine.com/home/archives/tags/microformats マイクロフォーマットのビジネス上の価値]（リンク切れ）
* [http://gataga.com gataga ソーシャルブックマーク検索エンジン]（ドメイン失効）
* [http://johnvey.com/features/deliciousdirector/ del.icio.us の ajax ベースのインターフェイス]
* [http://en.wikipedia.org/wiki/Social_bookmarking ウィキペディアでのソーシャルブックマークの定義]（[http://ja.wikipedia.org/wiki/ソーシャルブックマーク日本語]）

=== 関連作業 ===
* [[hreview-ja | hReview]]

== 現在の進行状況 ==
この仕様は最近バージョン RC1 のように安定し始めましたが、いまだ現在進行中です。望まれれば、ブックマークエントリーをできるだけ軽量にしてもっと広くアクセスできるようにするという目標のためには、リリース候補（release candidate）のバージョンを重ねる準備があります。前のバージョンからの変更は、開発者がこの狙いに限定して実装した経験を動機として行いました。以降の変更もおおむね実装上の関心を動機として行われるでしょう。このマイクロフォーマットの更なる可能性については下の「今後の方向性」をご覧ください。

=== xFolk 0.4 からの変更点 ===
もっと他のマイクロフォーマットの使用法と実装中に出てきたいくらかの要請に沿うため、class 属性の <code>extended</code> という値は廃止予定となり、<code>description</code> が推奨されています。また、実装上の使用例で見受けられたため、複数の要素で <code>extended</code> class を使ってもよいという変更もされました。

=== <div id=".E4.B8.BB.E3.81.AA.E6.96.B9.E5.90.91.E6.80.A7">今後の方向性</div> ===
xFolk の拡張はいくつか考えられます。そういった拡張には、たいていの場合 xFolk を他のマイクロフォーマットと組み合わせるのが一番の方法です。たとえば、ブックマークしたアイテムに関する自分の評価を表したいと思うかもしれません。これは xFolk と一緒に [[vote-links-ja | Vote Links]] か [[hreview-ja | hReview]] を使うことでできます。

また、全てのブックマークをタグ付きで提供するなど、xFolk を拡張して整合データに様々なソーシャルブックマークサービスの API を付けて提供することを考えるかもしれません。現在、どの標準でもこういった API の仕様はあまりに流動的です。API とそれが提供する機能は、ソーシャルブックマークサービスとメタサービスが自分を差別化する一つの方法を表しています。

"xFolk definition" という関係の深いフォーマットが開発中です。xFolk definition ではソーシャルブックマークで使われるタグを厳密に定義する手段を提供することになるでしょう。

=== ブレインストーミング ===
* [[xfolk-brainstorming|xFolk brainstorming]]

== 議論 ==

=== Q&A ===
* xFolk に関する疑問がある時には、[[xfolk-faq|xFolk FAQ]] をチェックしてください。もし答えが見つからなければ、質問してください！

=== 問題 ===
* この仕様の問題提起は、別ページの [[xfolk-issues|xFolk issues]] の文書に追加してください。

== 関連ページ ==
{{template:xfolk-related-pages}}
* [[xfolk-profile-ja|xFolk メタデータプロファイル]]（日本語）
* [[xfolk-issues-ja|xFolk の問題]]（日本語）

[[Category:xFolk]]

xfolk-ja

2010-04-26T11:48:07Z

KitaitiMakoto: DraftSpecification to DraftSpecification-ja

<entry-title>xFolk RC1</entry-title>

{{DraftSpecification-ja}}

'''xFolk'''（"xFolksonomy"に由来）は、ブックマークのコレクションを公開するための簡単でオープンなフォーマットです。これによって、サービスがウェブベースのブックマークソフトウェアでのユーザー体験の向上とデータの共有をよりうまくできるようになります。xFolk は HTML または XHTML、Atom、RSS、任意の XML に埋め込むことができます。これはオープンな[[microformats-ja|マイクロフォーマット]]標準の一つです。

__TOC__

== 仕様ドラフト ==

=== 編者/作者 ===
[http://thecommunityengine.com/ Bud Gibson] ([http://thecommunityengine.com The Community Engine])

=== 著作権 ===
{{MicroFormatCopyrightStatement2005}}

=== 特許 ===
{{MicroFormatPatentStatement-ja}}

=== 謝辞 ===
各項目が、部分的に、一度にたくさんのカテゴリーに属していてもかまわないというアイディアをもたらしてくれた [http://www.cnbc.cmu.edu/~plaut/ David Plaut] に感謝します。また、より最近ですが、思慮深い批評と推進で xFolk の開発に貢献してくれた [http://tantek.com/ Tantek Celik]、[http://epeus.blogspot.com/ Kevin Marks]、[http://steve.osdir.com/ Steve Mallet]、[http://hybernaut.com/ Brian DelVecchio]、[http://blogmarks.net Francois Hodierne]に感謝します。

== はじめに ==
ソーシャルブックマークサービスでは、ユーザーはブックマークを保存し、タグを付け、ほかのユーザーと共有します。ここ数年でこういったサービスの数は[http://en.wikipedia.org/wiki/Social_bookmarking 20を超え]、その中には[http://del.icio.us del.icio.us]、[http://furl.net furl]、[http://de.lirio.us de.lirio.us]（訳注：現在は [http://www.simpy.com/ Simpy] に引き継がれたようです）、jots（訳注：現在はサービス終了）、[http://blogmarks.net blogmarks]という人気サービス例も含まれます。

相互運用可能なデータのオープンスタンダードがないことは、ソーシャルブックマークサービスを使う上での大きな問題です。オープンスタンダードがあればソーシャルブックマークデータを簡単に集めて再構築し、gataga（訳注：現在はサービス終了）による実験的なブックマーク検索エンジンのような方向性の、新しいサービスを発明することが可能になるのです。また、[http://johnvey.com/features/deliciousdirector/ 目下は del.icio.us で行われている]ような、サービスをまたがって機能する JavaScript を書いてユーザー体験を全面的に向上させることもできるようになります。

xFolk は両方の利点を持つことを目標にした、ソーシャルブックマークのオープンスタンダードです。xFolk を取り入れたソーシャルブックマークサービスは、データサービスの一歩先を歩くことになるでしょう。ですが、データ自体はサードパーティのスクリプトが操作したり、共有したりすることが簡単な物になります。その結果、ブックマークサービスは低コストでユーザーに幅広い選択肢を提供し、本質的な差別化に力を注ぐことができるようになります。独立したブックマーク保管サービスを運営する個人やグループは、自分で作れる以上の幅広い機能を選べるようになります。

== セマンティック XHTML デザイン指針 ==
{{semantic-xhtml-design-principles-ja}}

== フォーマット ==
ソーシャルブックマークサービス、リンクブログ（訳注：リンクとそれに対するコメントからなるブログ）、[http://thecommunityengine.com/home/archives/xfolk 他所]でのリポートを幅広く分析した結果、ブックマークサービスと'''たくさんの'''異なるリンクブログで公開されているデータは暗黙的に次のスキーマに従って書かれていることが分かりました。

* ブックマークしたりタグを付けるリンク
* エントリーの題名
* リンクに付けるタグ
* リンクの追加説明や概要

初期の xFolk 標準が繰り返し使われたおかげで、この一般的なスキーマは次のようにしてマークアップへと変換できることが実証されています。

# 各エントリーに <code>xfolkentry</code> という class を持つコンテナ要素を作る
# ブックマークしたりタグを付けるリンクには <code>taggedlink</code> という class を持つ <a> 要素を使う
# エントリーの題名には、もしあれば <a> 要素の title 属性を、なければその値を使う
# タグには [[rel-tag-ja|rel-tag]] を使う
# 追加説明や概要には、<code>description</code> という class を持つコンテナ要素（ など）を使う

xFolk エントリーでは、題名を伴ったタグを付けるリンクが必須で、他の要素は全て省略できます。エントリーには複数のタグあってもかまいませんし、<code>description</code> class の要素が複数あってもかまいません。<code>description</code> class を持つ複数の要素の順序は、文書に現れるままの順です。xFolk エントリー内の意味的な要素は任意の深さにネストできます。

たくさんのソーシャルブックマークシステムが存在して、それぞれが独自のマークアップの慣例を持っています。さらに、たくさんの人が既に個人のリンクブログを公表しています。xFolk の第一の目標は、こうした現在の慣例に適合させるのが簡単であるようデザインすることなので、xFolk エントリーで使う要素の種類には厳密な前提条件がほとんどありません。意味を決める機能は、要素よりも class 属性や（[[rel-tag-ja|rel-tag]] の場合は）rel 属性の値に与えられるのです。

開発者は [http://www.w3.org/TR/xpath XPath] か相当する文法を使って xFolk エントリーの要素にアクセスすることが期待されます。XPath を使うための条件は、HTML 文書が整形式であることです。妥当な文書ではなくてもかまいません。このため、最善ではないかもしれませんが、妥当性検証をしていない HTML 文書の中で xFolk が使えるようになるのです。

=== XMDP プロファイル ===
xFolk の [http://gmpg.org/xmdp XMDP] プロファイルは、[[xfolk-profile-ja|xFolk profile]] を参照してください。

== 例 ==

下に [http://del.icio.us del.icio.us] の標準マークアップに見られるブックマークの例を示します。要素の class 属性の値を変更して xFolk に適合させる必要のある場所は、行の末尾にコメントで印を付けています。
<pre><div class="post"> 
<div>
<a class="delLink" href="http://www.sifry.com/alerts/archives/000306.html"> 
Sifry's Alerts: Technorati launches Related Tags
</a>
</div>
<div class="extended"> 
Ever wanted to see what posts are related to other posts, what tags
are related to others? Now you can! Just check under the Tag
description on most tag pages, like this one, or this one, and you'll
see the patterns. Can you smell the emergence?
どの投稿がどの投稿と関係あるのか、どのタグがどのタグと関係あるのか、
分かるようになってほしいとずっと思ってた。ようやくなった！
こことかこことか、ほとんどのタグページでタグを記述した部分の下をチェックしてほしい。
何かが起きそうなにおいがするだろ？
（訳注：『Emergence』は書名。邦題は『創発―蟻・脳・都市・ソフトウェアの自己組織化ネットワーク』。
　個の局所的な働きが全体の組織だった働きを生むという現象を解説）
</div>
<div class="meta">
to
<a class="delNav" href="/fpgibson/folksonomy">folksonomy</a> 
<a class="delNav" href="/fpgibson/technorati">technorati</a> 
... <a class="delNav" href="/url/cbcabf7de070fdb46598ee679367be49">
and 1 other person
</a>
... on 2005-04-09
</div>
</div></pre>

これに相当する xFolk は以下の通りです。class 属性の変更が必要だった行の末尾にコメントを付けています。
<pre><nowiki>
<div class="xfolkentry"> 
<div>
<a class="taggedlink" href="http://www.sifry.com/alerts/archives/000306.html"> 
Sifry's Alerts: Technorati launches Related Tags
</a>
</div>
<div class="description"> 
Ever wanted to see what posts are related to other posts, what tags
are related to others? Now you can! Just check under the Tag
description on most tag pages, like this one, or this one, and you'll
see the patterns. Can you smell the emergence?
どの投稿がどの投稿と関係あるのか、どのタグがどのタグと関係あるのか、
分かるようになってほしいとずっと思ってた。ようやくなった！
こことかこことか、ほとんどのタグページでタグを記述した部分の下をチェックしてほしい。
何かが起きそうなにおいがするだろ？
</div>
<div class="meta">
to
<a rel="tag" href="/fpgibson/folksonomy">folksonomy</a> 
<a rel="tag" href="/fpgibson/technorati">technorati</a> 
... <a class="delNav" href="/url/cbcabf7de070fdb46598ee679367be49">
and 1 other person
</a>
... on 2005-04-09
</div>
</div>
</nowiki></pre>

マークアップを xFolk に従う物に変換するのは、ほとんどの場合簡単です。xFolk の長所は、
全てのサービスやリンクブログにまたがって、精度を失うことの無いまま使い回せる class 属性のセットを提供していることです。
次の節ではこの点を説明する例をさらに多く提示します。

下は（リストのマークアップを使った）別の簡単な例です。
<pre>
<nowiki>
<ul>
<li>
<ul class="xfolkentry">
<li><a class="taggedlink" href="http://microformats.org/wiki/Main_Page">microformats wiki</a></li>
<li class="description">マイクロフォーマットを勉強して実践する主な場所で……</li>
<li class="description">コミュニティ駆動の Wiki</li>
<li class="meta">
Tags :
<a rel="tag" href="http://del.icio.us/tag/microformats">microformats</a>
<a rel="tag" href="http://del.icio.us/tag/websocial">websocial</a>
<a rel="tag" href="http://del.icio.us/tag/semantics">semantics</a>
</li>
</ul>
</li>

<li>

</li>

</ul>
</nowiki>
</pre>

== より多くの例 ==

開発者がサイトに xFolk を取り入れるのに役立つ例がたくさんあります。

=== 実世界での例 ===

実際に機能中の、xFolk でブックマークを公開しているシステムの例です。パース、索引作成、整理などを試せる「実際に利用されている」例を探し始めるには絶好でしょう。自分が xFolk を使ってブックマークを公表しているなら、遠慮せずそのサイトをこのリストの一番上に加えてください。リストが大きくなり過ぎたら、別の Wiki ページを作ります。

* [http://greenvoice.com Greenvoice] はユーザーが作る環境ニュースのリンクリストで、xFolk でマークアップされています。
* [http://www.idoneos.com Idoneos.com] はコンセプトごとに繋がった情報ページ（多くはスペイン語）のコレクションで、xFolk を使ってブックマークにタグ付けしています。
* [http://ashaszin.lautre.net/ Ashaszin] - [http://spip.net SPIP] を使って運営されている小さなブログ。xFolk でタグ付けした del.icio.us リンクとウェブフィードがあります。
* [http://www.rolandinsh.lv/blog/ Rolands Umbrovskis - blog] ブログの記事は全て xFolk でマークアップされています。
* [http://www.bbc.co.uk/worldservice/bangladeshboat BBC World Service Bangladesh River Journey] はソーシャルネットワークマッシュアップで、hAtom エントリーのブックマークに、基本的な xFolk を使っています。[http://dharmafly.com/blog/bangladeshboat Dharmafly のブログでの議論] を参照。
* [http://waferbaby.com/hussy waferbaby の Hussy] は、現在 xFolk を使ってリンクを公開しています（訳注：2008 年 11 月現在、確認できません）。
* [http://smarking.com/ Smarking] は、現在 xFolk を使って（検索結果を含む）共有リンクを公開しています。
* [http://unalog.com unalog] は、現在 xFolk を使って（検索結果を含む）共有リンクを公開しています（訳注：現在終了）。
* [http://de.lirio.us de.lirio.us] は、現在 xFolk を使ってブックマークを公開しています（<code>description</code> の代わりに、廃止予定の <code>extended</code> という class 属性を使っています。[[xfolk-profile-ja |XMDP]] を参照）（訳注：現在は [http://www.simpy.com/ Simpy] に引き継がれ、そちらでは xFolk は使用されていないようです）。
* [http://blogmarks.net/my/tools,export blogmarks] は現在、ブログへのブックマークを xFolk でエクスポートします（訳注：アカウント未所持のため、未確認。通常ページでは xFolk を使用しています）。
* [http://thecommunityengine.com The Community Engine] は、[http://thecommunityengine.com/home メインエントリー]と[http://thecommunityengine.com/webcites 公開ブックマーク]で xFolk を使っています（<code>description</code> の代わりに、廃止予定の <code>extended</code> という class 属性を使っています。[[xfolk-profile-ja |XMDP]] を参照）。
* [http://groovymother.com/links/ Groovy Links] は xFolk でマークアップされているリンクブログです（訳注：現在はこのページは無く、[http://groovymother.com/ ホームページ]が対応）。
* [http://tommorris.org/blog/ Tom Morris] - 日々の del.icio.us リンクが xFolk、[[hcard-ja|hCard]]、[[vote-links-ja|Vote Links]] でマークアップされています。

=== <div id=".E3.81.95.E3.82.89.E3.81.AA.E3.82.8B.E3.82.BD.E3.83.BC.E3.82.B7.E3.83.A3.E3.83.AB.E3.83.96.E3.83.83.E3.82.AF.E3.83.9E.E3.83.BC.E3.82.AF.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9" name=".E3.81.95.E3.82.89.E3.81.AA.E3.82.8B.E3.82.BD.E3.83.BC.E3.82.B7.E3.83.A3.E3.83.AB.E3.83.96.E3.83.83.E3.82.AF.E3.83.9E.E3.83.BC.E3.82.AF.E3.82.B5.E3.83.BC.E3.83.93.E3.82.B9">ソーシャルブックマークサービスへの付加</div> ===

次の例では、一つのサービスに、どのようにして xFolk を適用できるのかが説明されています（訳注：現在の scuttle 0.7.4 では xFolk を使ってリンクがマークアップされています）。

* [[xfolk-scuttle | scuttle]]

=== リンクブログ ===

ソーシャルブックマークサービスは、人々がリンクを公開する最近の例と言うに過ぎません。リンクブログは、ほとんどブログの初期の頃からありました。これはその発端から、あまり意味的でないマークアップをされる傾向があったため、xFolk にするにはもう少し労力を使う必要があります。次の例は、個別の作業説明し、それぞれがどのようにしてうまくいくのかを描いています。

* [[xfolk-kottke | kottke]]
* [[xfolk-pollas | pollas]]
* [[xfolk-jacobian | jacobian]]
* [[xfolk-julian-bez | julian-bez]]

=== スパム ===
スパム業者には、リンクファームにタグを付けるのに xFolk を利用している所もあります。（恐らく、実際にそのサイトにリンクさせるには、悪いアイディアでしょう。）例えば、
* phontron.info

== 実装 ==

次の実装は、xFolk を作ったり使ったりして開発されました。もし xFolk の実装を持っていたらこのリストの一番上に自由に加えてください。リストが大きくなり過ぎた時には、別の Wiki ページを作ります。

* [http://buzka.com Buzka]はソーシャルブックマークサービスで、現在は xFolk をサポートしています（訳注：2008年11月現在はサポートされていないようです）。
* [http://blip.tv Blip.tv]は動画ホスティングサイトで、現在は [http://blog.blip.tv/blog/2006/08/19/blip-supports-xfolk/ xFolk をサポートしています]（訳注：2008年11月現在はサポートされていないようです）。
* [http://www.s9y.org/ Serendipity] は PHP によるフレキシブルなブログ/CMS アプリケーションです。現在、xFolk をサポートする[http://www.numblog.de/archives/241-Social-Bookmarks-Plugin-for-Serendipity.html ソーシャルブックマークプラグイン]（ダウンロードは Serendipity の [http://spartacus.s9y.org/index.php?mode=bygroups_sidebar_en Plugin/Template ページ]からできます）があります。
* [http://claimid.com claimID] は各人のリンクを xFolk で実装しています。
* [http://ma.gnolia.com ma.gnolia] は、現在 xFolk をサポートしています。
* [http://smarking.com/ Smarking.com]（ソーシャルブックマークサービス）はタグ付けされたリンクを xFolk でマークアップしています！豆知識：[http://3spots.blogspot.com/2006/05/social-bookmarking-smarking.html 3spots: Social + bookMARKING = Smarking]。このページ自体は [[hreview-ja|hReview]] です。
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - Tails エクステンションの Flock 0.5.12 移植版。hCard、hCalendar、xFolk、hReview を探して便利なツールバーに表示します（訳注：現在のバージョンの Flock には未対応のため、未確認）。
* [http://blog.codeeg.com/tails-firefox-extension/ Tails] は、ウェブページにマイクロフォーマット（[[hcard-ja|hCard]]、[[hcalendar-ja|hCalendar]]、[[hreview-ja|hReview]]、[[xfolk-ja|xFolk]]）ががあれば教えてくれる Firefox エクステンションです（訳注：Firefox 2 では動作しますが、Firefox 3 ではインストールできません）。
* Bud Gibson と Mike Migurski は、xFolk reblog ツールでありサービスである [http://thecommunityengine.com/veg-o-matic veg-o-matic] を [http://thecommunityengine.com/home/archives/2005/09/vegomatic_an_al.html 書きました]。
* [http://inside.glnetworks.de/ Martin Rehfeld] は [http://blogmatrix.blogmatrix.com/ David Janes] の仕事を改良して、xFolk を含む多くのマイクロフォーマット要素を見つけてポップアップメニューによって提供する [[Greasemonkey]] [http://inside.glnetworks.de/2006/06/05/microformats-have-arrived-in-firefox-15-greasemonkey-06/ スクリプト] を作りました。''これは現在、Firefox 1.5+/Greasemonkey 0.6.4+ で動作します。
* [http://www.midgard-project.org/midcom-permalink-6416db7e1f0e297b4cf3dcc285702a8d net.nemein.bookmarks] は [http://www.midgard-project.org/ Midgard CMS] 中のブックマーク管理プログラムで、書き出しのネイティブフォーマットとして xFolk を使用します。[http://bergie.iki.fi/links/ 例] 参照（2008年11月現在、確認できません）。
* [http://de.lirio.us de.lirio.us] は現在、xFolk 0.4（説明箇所で <code>extended</code> class 属性を使用）を使ってブックマークを公表しています（訳注：現在は Simpy に引き継がれ、そちらでは xFolk は使われていないようです）。
* [http://dev.blogmarks.net/wiki/BlogSync blogmarks] は現在、ブックマークをブログへ xFolk 0.4 を使ってエクスポートします（ページを下へスクロールしてのエクスポート例を見てください。<code>description</code> の代わりに <code>extended</code> class 属性を使っています）。
* [http://pokkari.com/microformat/javadoc/ Sivitols] は Java のマイクロフォーマット用ライブラリです（現在リンク切れ）。現在は xFolk RC1 標準しか実装されていませんが、より多くのマイクロフォーマットのサポートが予定されています。（出典は [http://blog.blip.tv/blog/microformats/]）
* [http://bildu.net Bildu] は xFolk（rel-tag も）をサポートするバスク語のソーシャルブックマークサービスです（訳注：サービスというより、使っているオープンソースソフトウェア [http://sourceforge.net/projects/scuttle/ scuttle] が xFolk をサポート）。
* [http://bookmarks.excite.co.uk/ Excite Bookmarks] は xFolk と rel-tag をサポートするソーシャルブックマークサービスです（訳注：2008年11月現在、rel-tag のみサポート）。

== 参照 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[rel-tag-ja|rel-tag]]

=== その他の参考文献 ===
* [http://thecommunityengine.com/home/archives/xfolk articles about xFolk]
* [http://thecommunityengine.com/home/archives/tags/microformats articles about the business value of microformats]
* [http://gataga.com gataga social bookmark search engine]
* [http://johnvey.com/features/deliciousdirector/ an ajax based interface for del.icio.us]
* [http://en.wikipedia.org/wiki/Social_bookmarking social bookmarking defined at wikipedia]

=== 関連作業 ===
* [[hreview-ja | hReview]]

== 現在の進行状況 ==
この仕様は最近バージョン RC1 のように安定し始めましたが、いまだ現在進行中です。望まれれば、ブックマークエントリーをできるだけ軽量にしてもっと広くアクセスできるようにするという目標のためには、リリース候補（release candidate）のバージョンを重ねる準備があります。前のバージョンからの変更は、開発者がこの狙いに限定して実装した経験を動機として行いました。以降の変更もおおむね実装上の関心を動機として行われるでしょう。このマイクロフォーマットの更なる可能性については下の「今後の方向性」をご覧ください。

=== xFolk 0.4 からの変更点 ===
もっと他のマイクロフォーマットの使用法と実装中に出てきたいくらかの要請に沿うため、class 属性の <code>extended</code> という値は廃止予定となり、<code>description</code> が推奨されています。また、実装上の使用例で見受けられたため、複数の要素で <code>extended</code> class を使ってもよいという変更もされました。

=== <div id=".E4.B8.BB.E3.81.AA.E6.96.B9.E5.90.91.E6.80.A7">今後の方向性</div> ===
xFolk の拡張はいくつか考えられます。そういった拡張には、たいていの場合 xFolk を他のマイクロフォーマットと組み合わせるのが一番の方法です。たとえば、ブックマークしたアイテムに関する自分の評価を表したいと思うかもしれません。これは xFolk と一緒に [[vote-links-ja | Vote Links]] か [[hreview-ja | hReview]] を使うことでできます。

また、全てのブックマークをタグ付きで提供するなど、xFolk を拡張して整合データに様々なソーシャルブックマークサービスの API を付けて提供することを考えるかもしれません。現在、どの標準でもこういった API の仕様はあまりに流動的です。API とそれが提供する機能は、ソーシャルブックマークサービスとメタサービスが自分を差別化する一つの方法を表しています。

"xFolk definition" という関係の深いフォーマットが開発中です。xFolk definition ではソーシャルブックマークで使われるタグを厳密に定義する手段を提供することになるでしょう。

=== ブレインストーミング ===
* [[xfolk-brainstorming|xFolk brainstorming]]

== 議論 ==

=== Q&A ===
* xFolk に関する疑問がある時には、[[xfolk-faq|xFolk FAQ]] をチェックしてください。もし答えが見つからなければ、質問してください！

=== 問題 ===
* この仕様の問題提起は、別ページの [[xfolk-issues|xFolk issues]] の文書に追加してください。

== 関連ページ ==
{{template:xfolk-related-pages}}
* [[xfolk-profile-ja|xFolk メタデータプロファイル]]（日本語）
* [[xfolk-issues-ja|xFolk の問題]]（日本語）

[[Category:xFolk]]

tools-ja

2010-04-26T11:45:59Z

KitaitiMakoto: Search engines to Search engines-ja

= ツール、テストケース、追加調査 =


例、コード、テストケースを探すのに一番いい場所は、それぞれ個別のマイクロフォーマット用のページの中にあります。少ないながら、一つだけではないフォーマットを処理する必要のある、横断的なツールやサービスという物があります。このページは複数のマイクロフォーマットをまたぐ編集・解析・検証プログラム、テストケース、その他の情報向けのページです。

*[[accessibility|アクセシビリティ]]
*[[external-issues|外部の問題]]
*[[faqs-for-rdf|RDF の FAQ]]
*[[icalendar-implementations|iCalendar の実装]]
*[[internationalization|国際化]]
*[[microformats-issues|マイクロフォーマットの問題]] - 複数のマイクロフォーマットに関する問題。
*[[parsing-microformats|マイクロフォーマットの解析]]
*[[profile-uri-examples-in-wild|プロファイル URI の現実の例]] （<code>head</code> 要素用のプロファイル URI）
*[[examples-in-wild|現実の例]] - 発表されたマイクロフォーマット用の実例
*[[Search engines-ja|検索エンジン]]
*[http://hg.microformats.org/ ソースコードのリポジトリー] -- [[mercurial-quick-start|リポジトリーからコードをダウンロードする方法]]
*[[user-profile-examples-in-wild|ユーザープロファイルの現実の例]]（ソーシャルウェブサイト向けのユーザープロファイル）
*[[vcard-implementations|vCard の実装]]、[[vcard-errata|vCard の正誤表]]、[[vcard-suggestions|vCard の提案]]
*[[why-are-content-standards-hard|コンテンツ用標準が難しいわけ]]
*[[converting-microformats-to-other-formats|マイクロフォーマットから他のフォーマットへの変換]]
* [http://ujuicer.sandbox.matttthompson.com/ μJuicer] - vCard（.vcf）を hCard に変換する

tools-ja

2010-04-26T11:42:52Z

KitaitiMakoto: /* ツール、テストケース、追加調査 */ fixed duplication

= ツール、テストケース、追加調査 =


例、コード、テストケースを探すのに一番いい場所は、それぞれ個別のマイクロフォーマット用のページの中にあります。少ないながら、一つだけではないフォーマットを処理する必要のある、横断的なツールやサービスという物があります。このページは複数のマイクロフォーマットをまたぐ編集・解析・検証プログラム、テストケース、その他の情報向けのページです。

*[[accessibility|アクセシビリティ]]
*[[external-issues|外部の問題]]
*[[faqs-for-rdf|RDF の FAQ]]
*[[icalendar-implementations|iCalendar の実装]]
*[[internationalization|国際化]]
*[[microformats-issues|マイクロフォーマットの問題]] - 複数のマイクロフォーマットに関する問題。
*[[parsing-microformats|マイクロフォーマットの解析]]
*[[profile-uri-examples-in-wild|プロファイル URI の現実の例]] （<code>head</code> 要素用のプロファイル URI）
*[[examples-in-wild|現実の例]] - 発表されたマイクロフォーマット用の実例
*[[Search engines|検索エンジン]]
*[http://hg.microformats.org/ ソースコードのリポジトリー] -- [[mercurial-quick-start|リポジトリーからコードをダウンロードする方法]]
*[[user-profile-examples-in-wild|ユーザープロファイルの現実の例]]（ソーシャルウェブサイト向けのユーザープロファイル）
*[[vcard-implementations|vCard の実装]]、[[vcard-errata|vCard の正誤表]]、[[vcard-suggestions|vCard の提案]]
*[[why-are-content-standards-hard|コンテンツ用標準が難しいわけ]]
*[[converting-microformats-to-other-formats|マイクロフォーマットから他のフォーマットへの変換]]
* [http://ujuicer.sandbox.matttthompson.com/ μJuicer] - vCard（.vcf）を hCard に変換する

hreview-ja

2010-04-26T11:40:58Z

KitaitiMakoto: inclusion of DraftSpecification to DraftSpecification-ja

<entry-title> hReview 0.3 </entry-title>

{{DraftSpecification-ja}}

[[hreview|hReview]] はHTMLやXHTML, Atom, RSS, 任意のXMLなどにレビュー（商品、サービス、ビジネス、イベントなど）を埋め込むのに適したシンプルかつオープンで分散型のフォーマットです。hReviewはオープンスタンダードな[[microformats]]の一つです。

[[hreview|hReview]]を使い始めてみたいなら、[http://microformats.org/code/hreview/creator hReview creator]でレビューを書いて、作成したコードをページに貼り付けてみてください。

== Microformats Draft Specification 2006-02-22 ==
<div class="vcard">
;Editor
:[[User:Tantek|Tantek Çelik]] (http://tantek.com/, and before at [http://technorati.com Technorati, Inc.])
</div>
; Authors
: [[User:Tantek|Tantek Çelik]] (affiliations above)
: [http://360.yahoo.com/alidiabali Ali Diab] ([http://yahoo.com Yahoo! Inc.])
: [http://ianmcall.blogspot.com/ Ian McAllister] ([http://amazon.com/ Amazon.com])
: [http://journals.aol.com/panzerjohn/abstractioneer John Panzer] ([http://www.aol.com America Online, Inc.])
: [http://ifindkarma.com/blog Adam Rifkin] ([http://labs.commerce.net/ CommerceNet Labs])
: [http://sippey.typepad.com/ Michael Sippey] ([http://sixapart.com Six Apart, Ltd])
[[hreview#Copyright|copyright]] and [[hreview#Patents|patents]] statements apply.

== Status ==
hReview 0.3 は microformats.org の仕様ドラフトです。[[hreview-feedback]]、irc.freenode.net 上の #microformats、[http://microformats.org/discuss/mail/microformats-discuss/ マイクロフォーマット議論メーリングリスト] で hReview に関する公開の議論が行われています。

=== Available languages ===
この仕様の英語版が唯一もととなるバージョンです。この文書の翻訳については [[#Translations]] の節をご覧ください。

=== Errata and Updates ===
この仕様での機知の間違いと問題は[[hreview-issues-resolved|考慮済み]]と[[hreview-issues-closed|解決済み]]問題ページで修正されています。[[hreview-issues|問題]]を報告する前にここを確認してください。

hReview 0.4 へのアップデートは、[[value-class-pattern-ja|value-class パターン]]同様開発中で、機知の訂正事項も含んでいます。

== Introduction ==
非常に多くのウェブサイトが、製品（映画、音楽、本）から企業（レストラン、ホテル、店）、イベント（コンサート、演劇）、人物（歌手、指導者、有名人）、場所（歴史的建造物、公園）、オンラインリソース（ウェブページ、ファイル）やレビューのレビューにいたるまで、あらゆる種類の事物に関する幅広い形式のレビューを公開しています。

こういったレビューの共有、配布、シンジケーション（配信）、アグリゲーション（集約）を可能にし、促進するため、hReview マイクロフォーマットを提案します。これはレビュー配布のオープンスタンダードです。既存の色々な[[review-examples|レビューの例]]や、[[review-formats|レビュー形式]]についての先人の試みを調べ、レビューのおおよそ最小のスキーマとして hReview を設計しました。フィードバックは [[hreview-feedback|hReview フィードバック]]ページにお願いします。

{{rfc-2119-intro-ja}}

=== Scope ===
多くのレビューでは、いくつか一般的な側面が共通しています。この最小の共通部分に基いている所では、hReview が使えます。

==== Out of scope ====
hReview ではレビューの特定の項目に特化したプロパティは除外されています。初めからシンプルかつ最小であり続けることが重要なのです。機能の追加は実装上必要だと認められた時に行われます。

「universal object identifier（統一物品識別子）」の概念――異なるショッピングサイトからいかにして同じ物品・項目・製品を特定するか――は、とても役に立つものもありますが、このフォーマットの範囲外です。

== Format ==
=== 一般 ===
hReviewフォーマットは、現在ウェブ上にたくさんあるレビューサイトとフォーマットに共通して使われているプロパティに基づいています。
使用できるプロパティ名は、[[hcard-ja|hCard]]と[[hcalendar-ja|hCalendar]]標準仕様に関連して定義されているものを元にして選ばれています。

=== Schema ===
hReviewのスキーマは以下の通りです:

* hReview ('''<code>hreview</code>''')
** '''<code>version</code>'''. 任意。テキスト。
** '''<code>summary</code>'''. 任意。テキスト
** item '''<code>type</code>'''. 任意。 product | business | event | person | place | website | url.
** '''<code>item</code>''' info. 必須。'''<code>fn</code>''' ('''<code>url</code>''' || '''<code>photo</code>''' ) | '''[[hcard-ja|hCard]]''' (人物または企業の場合) | '''[[hcalendar-ja|hCalendar]]''' (イベントの場合)
** '''<code>reviewer</code>'''. 任意。'''[[hcard-ja|hCard]]'''。
** '''<code>dtreviewed</code>'''. 任意。 ISO8601 絶対日時（absolute date time）
** '''<code>rating</code>'''. 任意。固定小数点数 [1.0-5.0]。あるいは、任意の '''<code>worst</code>''' (デフォルト：1.0) または '''<code>best</code>'''（デフォルト：5.0）またはその両方を持つ固定小数点数で、この場合も厳密な '''<code>value</code>''' を持つ。
** '''<code>description</code>'''. 任意。任意の妥当な HTML でマークアップされたテキスト。
** tags. 任意。キーワードやフレーズ。'''[[rel-tag-ja|rel-tag]]'''を使い、それぞれ任意の rating を持つ。
** permalink. 任意。'''[[rel-bookmark]]'''と'''[[rel-self]]'''を使う。
** license. 任意。'''[[rel-license]]'''を使う。

=== プロパティの詳細 ===
hReviewのプロパティの詳細は次の通りです。

'''version''':: この任意のプロパティには、コンテンツ中で使用しているhReviewのバージョンを指定することができます。このプロパティを省略すると、hReview仕様のv2.0またはそれ以降の任意のバージョンによって解釈をしていいと宣言したことになります。
実際には、この仕様の著者たちは、初期のバージョンの仕様によって生成されたコンテンツに対する後方互換性を維持することにコミットしています。
このプロパティはvCard RFC2426 section "3.6.9 VERSION Type Definition"で定義されている"VERSION"の文法と互換性があり、
結果としてそれを再利用したものになっています。本仕様に対するこのプロパティの値は"0.3"です。

'''summary''':: この任意のプロパティは、レビュー自体のタイトルを表します。

'''item type''':: この"type"という任意のプロパティはレビューされるitemのタイプを示し、それらは、product、business、event、person、place, website、urlのいずれか一つです。省略されている場合は、そのitemのタイプを導出してよい場合があります。もしitemが[[hcard-ja|hCard]]でもある場合は、そのitemのタイプはhCardの内容に基づいて"business"または"person"になります。もしitemが[[hcalendar-ja|hCalendar]]のeventでもある場合は、itemのタイプは"event"です。

'''item info''':: この必須プロパティは少なくとも''その''item(1つのhReviewは、ただ1つのitemについて説明します)の名前("fn"というサブプロパティを使用 - その名前に対応する整形済み文字列。ただし、イベントの item を除きます。イベントの場合は hCalendar の各 "vevent" の中に "summary" サブプロパティがなければなりません({{must}}))を持たなければなりません({{must}})。そして、そのitemに対応する少なくとも1つのURI ("url")を持つべきです({{should}})。さらに、そのitemの写真または絵("photo")のURLを含めることができます({{may}})。
itemのタイプが"person"または"business"の場合は、そのitem info (fn, url, photo)は[[hcard-ja|hCard]]の中に囲まれている必要があります({{must}})。
itemのタイプが"event"の場合は、そのitem infoは[[hcalendar-ja|hCalendar]] veventの中に囲まれているべきです({{should}})。
itemのURLではないユニークな識別子(e.g. ISBN、UPC など)は、そのitemのURN ("url")として表現することができます({{may}})。
itemの内側に含まれるmicroformats (現在は[[hcard|hCard]]と[[hcalendar|hCalendar]] event)は、item自体にセットすることができます。(e.g. class="item vcard") しかし、item infoの下位プロパティ("fn"、"url"、"photo")を使用する場合は、それらはitemの要素の内側になければなりません({{must}})。

'''reviewer''':: この任意のプロパティはレビューを書いた人を示します。
もしもreviewerが指定されている場合、そのreviewerを表現するhCardが必要です({{must}})。匿名のレビューにするには、"anonymous"(引用符を除く)をその"reviewer"のフルネームとしてください。
"reviewer"がhReviewの内側にない場合、パーザーはそのページのhReviewの外側を探すべきです。
"reviewer"がhReviewの外側にもない場合、パーザーは、そのドキュメントが使用している言語の中で定義されている著者を使うべきです。
すなわち、HTMLドキュメントの場合、 <code><nowiki><address></nowiki></code>で示されているそのページについての連絡先(これは [[hcard|hCard]]で同様にマークアップされているのが理想的です)、Atom 1.0では、<code><nowiki><entry></nowiki></code> <code><nowiki><author></nowiki></code>、または、それがなければ<code><nowiki><feed></nowiki></code> <code><nowiki><author></nowiki></code>、RSSでは<code><nowiki><item></nowiki></code>要素の内側にある<code><nowiki><author></nowiki></code>となります。

'''dtreviewed''':: 公開した時点に関するこの任意のプロパティは、レビューが書かれたか生み出された時点の [[ISO-8601|ISO8601]] 絶対日時（absolute date time）を提供''しなければなりません''（{{must}}）。このプロパティは UTC を使う''べき''（{{should}}）ですが、タイムゾーンオフセット構文を使うことも''できます''（{{may}}）。hReview に dtreviewed が無い場合は、外部の、hReview を取り囲む文脈中を見ます。その文脈が [[hatom|hAtom]] エントリーだった場合、フィードの "published"（見つからなければ "updated"）の日時を使います。それ以外の場合、dtreviewed として hReview を含む文書の（訳注：XML としての）言語（例えば Atom フィードの "published"/"updated" のような物）を参照して作成日時（見つからなければ更新日時）の情報を使い、それも無ければプロトコル（例えば HTTP Last-Modified やファイルシステムの最終更新日時）を使います。

'''rating''':: rating（格付け）は、項目の評価を含んだ 1.0 から 5.0 までの（精度が 10 進小数点以下一桁の）固定小数点数で、デフォルトでは高い値が良い評価を表します。任意で、別の "worst" または "best" またはその両方の数値を定義して違った範囲（例えば 0-10 の 6）を設定することも''できます''（{{may}}）。"best" の値を "worst" よりも小さい数にしてもかまいません。

'''description''':: この任意のプロパティにはレビュアーの意見を書いたテキスト全文が入ります。このプロパティには妥当な HTML マークアップが含まれていても''かまいません''（{{may}}）。ユーザーエージェントは全てのマークアップを保持する''べきです''（{{should}}）。多角的な記述や節をまたぐ記述（例えば賛否や長短）は description プロパティに含まれる''べきです''（{{should}}）。

'''tags''':: タグはレビュアーが item と結びつけたキーワードやフレーズ（ここのキーワードやフレーズのタグには [[rel-tag-ja|rel-tag]] マイクロフォーマットを使います）のリストを使って表現されます。レビュアーは任意で、そのタグに関する rating を各 [[rel-tag-ja|rel-tag]] の中で提供することが''できます''（{{may}}）。例：ambience:5。あるタグのデフォルトの rating は、もしあれば item 全体の rating 範囲を使います。worst～best を設定し直して使うことも''できます''（{{may}}）。レビュー著者は、その方が使いやすければ、同じ意味を保持しながらこの構造を逆転させることも''できます''（{{may}}）。つまり、評価付きのタグを表すのに rating の中に [[rel-tag-ja|rel-tag]] を入れることもできるのです。注：評価付きのタグは、理想としては、そのタグが意味する物を説明しているタグスペース使う''べきです''（{{should}}）。例えば Food:18/30 というのは、Food タグとして 30 点中 18 点が何を意味しているのか説明している Food のタグスペースにリンクしている''べきです''（{{should}}）。

'''permalink''':: この任意のプロパティは hReview の URL です。あるハイパーリンクがレビュー自身の固定リンクだと示すには、このプロパティの <code><a href></code> タグに加えて、<code>rel="self bookmark"</code> を使''わなければなりません''（{{must}}）。ハイパーリンクに既に <code>rel</code> が含まれている場合は、この属性の中に空白で区切って <code>self</code> と <code>bookmark</code> という値を含め''なければなりません''（{{must}}）。索引作成者／プログラムは、（一つのページから何度も索引を作るなど）複数の情報源から同じレビューを特定して照合するための一意の ID として、レビューの固定リンクを使うことが''できます''（{{may}}）。レビュー著者は固定リンクだと示すために、要素に "permalink" というクラス名を使うことができますが、必須ではありません。

'''license''':: hReview はの記事自身が基づいているライセンスへのリンクを'''[[rel-license-ja|rel-license]]''' マイクロフォーマットを使って示します。

次のプロパティ名は [[hcard-ja|hCard]] と [[hcalendar-ja|hCalendar]] マイクロフォーマットからの再利用です： <code>version, summary, fn, url, photo, description</code>。さらに、hCard で記された item とレビュアーには hCard のどのプロパティが含まれていても''かまいません''（{{may}}）。rel 属性の "self" という値は [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 仕様]からの再利用です。

いくつかのプロパティでは、より多くの意味を持つこともあります。ですから、それについては特殊な扱いをしなければなりません。例：

* 全ての "url" は、hReview の中の 'hreview' という class 名を持つ要素の内側で <code><a class="url" href="...">...</a></code> を使う
*また、"photo" については <code><img class="photo" src="..." alt="...の写真" /></code> を使う

* rating は画像や「☆☆☆」といった文字として表現されることも多い。そういった文字はこれについては明確な格付けの略記なので、<code><abbr></code> 要素が特に使いやすい。例：<code><abbr class="rating" title="3.0">☆☆☆</abbr></code>。これは次の節でもさらに検討される。

==== Language ====
* hReview が書かれている自然言語を明確に伝えるため、class="hreview" を持つ要素で HTML 標準の 'lang' 属性を使ってください。例：<code><div class="hreview" lang="en"> ... </div></code>。（item 名などの）hReview の一部が異なる言語で書かれている場合は、その部分に 'lang' 属性を使ってください。
* レビューの言語を扱う必要のある hReview 処理プログラムは、HTML 標準の 'lang' を仕様に従って処理しなければなりません（{{must}}）。

=== Human vs. Machine Readable ===
プロパティに <code><abbr></code> 要素を使う場合、そのプロパティの値には、要素の内容ではなく '<code>title</code>' 属性を使います。そうすることで、また別のユーザーフレンドリーな値の表現を提供することができるのです。

同様に、プロパティに <code><img /></code> を使う時には、次のように扱わなければなりません（{{must}}）。

# "photo" プロパティや、値として URL を使う他のプロパティには <code>src="..."</code> 属性がその値を決めます。
# その他のプロパティには <code><img /></code> 要素の '<code>alt</code>' 属性がプロパティ値になります。

=== Object Includes ===

hReview 0.3 はオブジェクト[[include-pattern|インクルードパターン]]をサポートしています。

一つのページで一つのアイテムとそのアイテムに関する複数のレビューを並べることがよくあります。そのアイテムの各レビューで item info を繰り返さなければならないということを避けるため、次のようにするべきです。最初のレビューを hReview としてマークアップし、item info では一意な "id" 属性を付けます。それ以降のレビューではオブジェクト[[include-pattern|インクルードパターン]]を使って最初のレビューから item info をインクルードします。

=== Notes ===
この節は参考用です。

* レビューを hReview マイクロフォーマットでマークアップすることで、レビューが索引化できるようになるでしょう。これはレビュー自体の著作権には影響しません。レビューの著作権は、上の仕様で述べられているように、公開する人が [[rel-license-ja|rel-license]] を使って厳密に記述できます。
* 列挙された item type の項目は開発中で、拡張されるかもしれません。
* 特定のアイテムに関するより詳しい情報は、残りの情報と一緒に、そのアイテムの URL で記述されているべきです。
* 多くの格付けシステムが 1.0 から 5.0 の範囲を使い、そのほとんどが格付けを星の数（半分も可）で表現します。望むなら、サイトで格付けを表現するのに何らかの画像を使うこともできます。

== Examples ==
以下では現在のウェブサイトからレビューの例をいくつか取り上げて、どれほど簡単にレビューの構造化されたマイクロフォーマットである hReview をサポートするように改良できるかを示します。

すぐに [[hreview-ja|hReview]] を始めたいという人は、[http://microformats.org/code/hreview/creator hReview creator] を使ってレビューを書き、自分のブログで公表してみてください。

=== Restaurant reviews ===

次はレストランの簡単なオンラインレビューです。

<pre><nowiki>
<div>
星5個中5個
<h4>Crepes on Cole は最高</h4>
レビュアー：Tantek - 2005年4月18日
<blockquote>
Crepes on Cole はサンフランシスコの小さなクレープ屋で最高の所の一つだ。
出す物もサービスも素晴らしい。大きい物から小さい物まで、
パーティ用のいろいろな大きさのテーブルがある。窓側の席は、
すぐそこに停まる N-Judah を眺めたり、N-Judah の方から見たりという素晴らしい体験ができる。
わたしはここで近所の WiFi に助けられながらたくさんの仕事をしているのだが、
何度も楽しい集会をしてもいる。
</blockquote>
訪問日：2005年4月
食べたもの：フィレンツェ風クレープ（Florentine crepe）
</div>
</nowiki></pre>

このレビューに hReview を付け加えるのはいい例です。

<pre><nowiki>
<div class="hreview">
星5個中5個
<h4 class="summary">Crepes on Cole は最高</h4>
レビュアー：Tantek -
<abbr class="dtreviewed" title="20050418T2300-0700">2005年4月18日</abbr>
<div class="description item vcard">
Crepes on Cole は
サンフランシスコの小さなクレープ屋で最高の所の一つだ。
出す物もサービスも素晴らしい。大きい物から小さい物まで、
パーティ用のいろいろな大きさのテーブルがある。窓側の席は、
すぐそこに停まる N-Judah を眺めたり、N-Judah の方から見たりという素晴らしい体験ができる。
わたしはここで近所の WiFi に助けられながらたくさんの仕事をしているのだが、
何度も楽しい集会をしてもいる。
</div>
訪問日：2005年4月
食べたもの：フィレンツェ風クレープ（Florentine crepe）
</div>
</nowiki></pre>

このレビュー例ではいくつか hReview としては記録されていないプロパティ（訪問日、食べたもの）があることに注意してください。これは hReview を最小で簡単なものにしておくため、敢えてしたことです。

この例の hReview は次のように表現できます。

星5語中5個 
'''Crepes on Cole は最高''' 
レビュアー：Tantek - 2005年4月18日 

Crepes on Cole はサンフランシスコの小さなクレープ屋で最高の所の一つだ。出す物もサービスも素晴らしい。大きい物から小さい物まで、パーティ用のいろいろな大きさのテーブルがある。窓側の席は、すぐそこに停まる N-Judah を眺めたり、N-Judah の方から見たりという素晴らしい体験ができる。わたしはここで近所の WiFi に助けられながらたくさんの仕事をしているのだが、何度も楽しい集会をしてもいる。

訪問日：2005年4月 
食べたもの：フィレンツェ風クレープ（Florentine crepe） 

==== Multidimensional Restaurant Review ====
レストランのレビューには、そのレストランの異なる面について格付けをしているものもあります。そういった詳細なレビューは、hReview ではタグのついた格付けを使って表現します。また、そのレビューの説明の中にあるインラインのタグに注意してください。

次はそのようなレビューをテキスト形式で表した例です。

Cafe Borrone

1010 El Camino Real, Menlo Park, CA 94025, +1-650-327-0830;
cafeborrone.com

食事：18/30；雰囲気：19/30；サービス：15/30価格：$$...

このカフェはサンフランシスコ半島の素敵なオアシスだ。
外にある噴水は、近くの El Camino の車の音を打ち消してくれる。
Cafe Borrone は壮麗な個人書店の隣にあって、
新たに購入した本や輸入雑誌を広げながら
コーヒーや軽食を取るには理想的な場所だ。
スープとサンドイッチの特別メニューは毎日変わる。
温めたばかりのミニバゲットについてくる、
クルトン入りのコーンチャウダーとチーズの大きな塊が特にすばらしい。
夜は混むことが多く、見知らぬ人と相席になることもある。
エスプレッソ愛好家にはイッリのコーヒーがたまらないだろう。
賑やかさは遅い朝の静けさから夜の圧倒されるようなジャズバンドまで、様々だ。

hReview ではこうなります。

<pre><nowiki>
<div class="hreview">
<div class="item vcard">
<div class="fn org summary">Cafe Borrone</div>

1010 El Camino Real,
Menlo Park,
CA
94025,

+1-650-327-0830;
<a class="url" href="http://cafeborrone.com">cafeborrone.com</a>
</div>
<ul>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
食事：18/30</a>；</li>
<li class="rating"><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
雰囲気：19/30</a>；</li>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
サービス：15/30</a>；</li>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
価格：<abbr class="value" title="2">$$</abbr>...</a></li>
</ul>
<div class="description">
この<abbr class="type" title="business">
<a href="http://en.wikipedia.org/wiki/cafe" rel="tag">カフェ</a></abbr>
はサンフランシスコ半島の素敵なオアシスだ。
外にある噴水は、近くの El Camino の車の音を打ち消してくれる。
Cafe Borrone は壮麗な個人書店の隣にあって、
新たに購入した本や輸入雑誌を広げながら
<a href="http://en.wikipedia.org/wiki/coffee" rel="tag">コーヒー</a>
や軽食を取るには理想的な場所だ。
<a href="http://technorati.com/tag/soup" rel="tag">スープ</a>と
<a href="http://technorati.com/tag/sandwich" rel="tag">サンドイッチ</a>
の特別メニューは毎日変わる。
温めたばかりのミニバゲットについてくる、
クルトン入りのコーンチャウダーとチーズの大きな塊が特にすばらしい。
夜は混むことが多く、見知らぬ人と相席になることもある。
<a href="http://flickr.com/photos/tags/espresso" rel="tag">エスプレッソ</a>
愛好家には
<a href="http://en.wikipedia.org/wiki/Illy" rel="tag">イッリ</a>のコーヒーがたまらないだろう。
遅い朝の静けさから夜の圧倒されるような
<a href="http://en.wikipedia.org/wiki/jazz" rel="tag">ジャズ</a>バンドまで、様々だ。 </div>
レビュー（<a href="http://microformats.org/wiki/hreview">
hReview v0.3</a>）
：匿名。
<abbr class="dtreviewed" title="20050428T2130-0700">2005年4月18日</abbr>。
</div>
</nowiki></pre>

次のような CSS のスタイルシートを添えると……

<pre><nowiki>
a.url { display:block }
ul { margin:1em 0; padding:0 }
ul li { display:inline }
</nowiki></pre>

この hReview は元のテキストと同じように表示できます。

Cafe Borrone 
1010 El Camino Real, Menlo Park, CA 94025, +1-650-327-0830; 
[http://cafeborrone.com/ cafeborrone.com] 
 
[http://en.wikipedia.org/wiki/Food 食事：18/30];
[http://flickr.com/photos/tags/Ambience 雰囲気：19/30];
[http://en.wikipedia.org/wiki/Service サービス：15/30];
[http://en.wikipedia.org/wiki/Price 価格：$$...] 

この[http://en.wikipedia.org/wiki/cafe カフェ]はサンフランシスコ半島の素敵なオアシスだ。外にある噴水は、近くの El Camino の車の音を打ち消してくれる。Cafe Borrone は壮麗な個人書店の隣にあって、新たに購入した本や輸入雑誌を広げながら[http://en.wikipedia.org/wiki/coffee コーヒー]や軽食を取るには理想的な場所だ。[http://technorati.com/tag/soup スープ]と[http://technorati.com/tag/sandwich サンドイッチ]の特別メニューは毎日変わる。温めたばかりのミニバゲットについてくる、クルトン入りのコーンチャウダーとチーズの大きな塊が特にすばらしい。夜は混むことが多く、見知らぬ人と相席になることもある。[http://flickr.com/photos/tags/espresso エスプレッソ]愛好家には[http://en.wikipedia.org/wiki/Illy イッリ]のコーヒーがたまらないだろう。賑やかさは遅い朝の静けさから夜の圧倒されるような[http://en.wikipedia.org/wiki/jazz ジャズ]バンドまで、様々だ。

レビュー（[http://microformats.org/wiki/hreview hReview v0.3]）：匿名。2005年4月28日。

=== Product review ===
以下は製品レビューの例です。

<pre><nowiki>
<div>
<a href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/">
<img src="http://images.amazon.com/images/P/B000089CJI.01._SCTHUMBZZZ_.jpg"
alt="アルバムジャケット写真：The Postal Service：Give Up" />
The Postal Service：Give Up</a>
<blockquote>
「相手の望み通りに接してあげる、
停止信号を守る、病気を治す……
人はそういったことで褒められるべきだと思ってる。
眠るから起こさないで……」

このアルバムでは「Nothing Better」もいい曲だ。
</blockquote>
（★★★★★）
</div>
</nowiki></pre>

このレビューに hReview を足すのもとても簡単ですが、この場合は hReview に必須の rating と reviewer 用の要素を加える必要があります。

<pre><nowiki>
<div class="hreview">
<a class="url fn" href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/">
<img src="http://images.amazon.com/images/P/B000089CJI.01._SCTHUMBZZZ_.jpg"
alt="アルバムジャケット写真：The Postal Service：Give Up" />"
class="photo" />
The Postal Service: Give Up</a>
<div class="description">
「相手の望み通りに接してあげる、
停止信号を守る、病気を治す……
人はそういったことで褒められるべきだと思ってる。
眠るから起こさないで……」

このアルバムでは「Nothing Better」もいい曲だ。
</div>
（<abbr class="rating" title="5">★★★★★</abbr>）
レビュー：
<a class="url fn" href="http://ifindkarma.com/blog/">Adam Rifkin</a>。
<abbr class="dtreviewed" title="200502">2005年2月</abbr>。

</div>
</nowiki></pre>

この hReview は例えばこう表示できます。

[アルバムジャケット写真：]
[The Postal Service：]
[ Give Up ]

The Postal Service：Give Up

「相手の望み通りに接してあげる、停止信号を守る、病気を治す、送り主の住所を書いて手紙を送る……人はそういったことで褒められるべきだと思ってる。眠るから起こさないで……」

このアルバムでは「Nothing Better」もいい曲だ。

（★★★★★）

レビュー：Adam Rifkin。2005年2月。

=== Movie Review ===
最後に、映画のレビューの例です。

<pre><nowiki>
<div>
anonymous, April 18th, 2005
<div>
<a lang="zh" href="http://www.imdb.com/title/tt0299977/">
Ying Xiong (HERO)
</a>
</div>
<div>評価：5 点満点中 4 点</div>
<blockquote>
この映画は音楽と映像が素晴らしい。 </blockquote>
</div>
</nowiki></pre>

hReview ではこうです。

<pre><nowiki>
<div class="hreview">

anonymous,
<abbr class="dtreviewed" title="20050418">April 18th, 2005</abbr>

<div class="item">
<a lang="zh" class="url fn" href="http://www.imdb.com/title/tt0299977/">
Ying Xiong (HERO)
</a>
</div>
<div>評価：5 点満点中 4 点</div>
<div class="description">
この映画は音楽と映像が素晴らしい。 </div>
</div>
</nowiki></pre>

このように表示できます。

匿名。2005年4月18日。 
Ying Xiong（HERO） 
評価：5 点満点中 4 点 

この映画は音楽と映像が素晴らしい。

== Examples in the wild ==
この説は'''参考情報'''です。この仕様の文中で書かれている可能性をはるかに超えて、実際に hReview を使っている例がたくさんあります。これは [[hreview-examples-in-wild|別ページ]]に移しました。

[[hreview-examples-in-wild|hReview Examples in the wild]] を参照してください。

== Implementations ==
この節は'''参考情報'''です。hReview の実装も、この文中で書かれている可能性以上にあります。[[hreview-implementations|別ページ]]に移しました。

[[hreview-implementations|hReview Implementations]] を参照してください。

== Design Principles ==
This section is '''informative'''. hReview was designed using design [[principles]] similar to those that went into [[hCard]] and thus this overview is included for informational purposes.

{{semantic-xhtml-design-principles-ja}}

== Inspiration and Acknowledgments ==
hReview 開発参加のオープンな呼び掛けに応えてくれた皆さんに感謝します。特に次の人たちに、建設的な意見とフィードバックを頂いたことに謝意を示したいと思います。[http://www.richardault.com/ Richard Ault]、[http://dannyayers.com Danny Ayers]、[http://www.vertexdev.com/~jeff/ Jeffrey Barr]、[http://adriancuthbert.blogspot.com/ Adrian Cuthbert]、[http://jason.defillippo.com/ Jason DeFillippo]、[http://www.hybernaut.com/bdv Brian Del Vecchio]、Scott Derringer、[http://budgibson.com/home/ Bud Gibson]、[http://joi.ito.com/ Joi Ito]、[http://www.kanai.net/weblog/ Gen Kanai]、[http://niallkennedy.com/ Niall Kennedy]、[http://labs.commerce.net/wiki/index.php/Rohit_Khare Rohit Khare]、[http://theryanking.com/ Ryan King]、[http://www.jluster.org/ Jonas Luster]、[http://epeus.blogspot.com/ Kevin Marks]、Mark Nottingham、[http://www.powazek.com/ Derek Powazek]、[http://www.judysbook.com/ Jeff Rodenburg]、[http://sifry.com/alerts/ David Sifry]、[http://jystewart.net/ James Stewart]、[http://kung-foo.tv/ Adriaan Tijsseling]、[http://www.flashenabled.com/ Phillip Torrone]、Thai Tran、[http://w6daily.winn.com/ Phillip Winn]、[http://yohei-y.blogspot.com YAMAMOTO Yohei]。

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard-ja|hCard]]
* [[hcalendar-ja|hCalendar]]
* [[rel-tag-ja|rel-tag]]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc3986.txt RFC3986]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

=== Informative References ===
* [http://www.w3.org/TR/REC-CSS1 CSS1]
* ISO.8601.1988
** International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.（国際標準化機構「データ要素と交換フォーマット――情報交換――日付及び時刻の表現」ISO 標準 8601、1988年7月）
* [http://www.w3.org/TR/1998/NOTE-datetime-19980827 W3C NOTE-datetime-19980827]
* [http://www.ietf.org/rfc/rfc3667.txt RFC3667]
* [http://www.ietf.org/rfc/rfc3668.txt RFC3668]
* [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy]
* [http://local.yahoo.com/details?id=21359628 Crepes on Cole reviews on Yahoo!Local]
* そのほかのレビューの取り組み。[[reviews-formats]]をご覧ください。
* http://developers.technorati.com/wiki/hReview に助けられました。

==== Similar Work ====
* [[hlisting-proposal|hListing]]
* [[xoxo-ja|XOXO]]

== Copyright ==
{{MicroformatCopyrightStatement2005}}

=== Patents ===
{{MicroFormatPatentStatement-ja}}

== Work in progress ==
この仕様は現在進行中です。更なる特徴が議論され、理解され、書かれた時には追加されるでしょう。

=== Changes from v0.2 ===
hReview v0.3 では [[hreview-v0.2|hReview v0.2]] から以下の変更がなされました。

規範的な変更：
# 企業と人物の item の description には [[hcard-ja|hCard]] を（使うべき（SHOULD）ではなく）使わなければなりません（MUST）
# "reviewer" が変更されました
## Ryan King と Mark Nottingham のフィードバックにより、reviewer が＊任意＊になりました
## hReview に reviewer が無い場合には、そのページの中の hReview の外側を見て、レビュアーを見つけてください。外側にも "reviewer" が無い場合は、文書の言語に含まれている著者情報（HTML ページの <code><nowiki><address></nowiki></code> など）を reviewer として使ってください。
## レビュアー情報の表現には [[hcard-ja|hCard]] を（使うべき（SHOULD）ではなく）使わなければなりません（MUST）
# "dtreviewed" が変更されました
## Ryan King と Mark Nottingham のフォードバックにより、dtreviewed が＊任意＊になりました
## hReview に dtreviewed が無い場合は、外部の、hReview 取り囲む文脈中を見てください。その文脈が [[hatom|hAtom]] エントリーだった場合、dtreviewed として "published"（見つからなければ "updated"）を使ってください。もしエントリー中に無ければ、フィードの "published"（見つからなければ "updated"）を使ってください。それも無ければ、文書の言語に含まれている情報（例えば Atom フィードの"published"/"updated" のような物）を、その次にプロトコルの情報（例えば HTTP Last-Modified やファイルシステムの最終更新日時）を使ってください。
# 'type' が 'event' の item の表現には [[hcalendar-ja|hCalendar]] を使うべき（SHOULD）です
# 出版会の知識に基づいて、rating の値の桁を 10 進数で一桁加えました
# rating の best/worst を提示（マークアップ）する時に、より厳密に rating の値をマークアップするため [http://microformats.org/wiki/hcard-ja#.E5.80.A4.E3.81.AE.E6.8A.9C.E7.B2.8B hCard の "value" の構造]（例では "tel" プロパティの中で使われているような）を使ってください。
# その hReview 全体のライセンスを示すため [[rel-license-ja|rel-license]] を追加しました
# Eran Globen の提案により、関連する tag を提供するのに、tag の中に rating を入れるのと同じようにして、rating の中に tag を入れられるようにしました。
# item info を繰り返さずに同じ item に複数のレビューを書けるよう [[include-pattern]] のサポートを加えました。

参考すべき変更（いくつかあるが中でも特別な物）：
# 基準や関連項目のタグにはそのタグの格付けを説明しているタグスペースを使うのが理想であることに注意してください。例えば食事：18/30 が何を意味するか説明しているなど。
# 例は適宜更新されます。

== Further Reading ==
* [http://www.technorati.com/cosmos/referer.html このページについて議論しているブログ]（[http://technorati.com/search/http%3A%2F%2Fmicroformats.org%2Fwiki%2Fhreview 英語ページについて議論しているブログ]）もご覧ください。

== Related Pages ==
{{hreview-related-pages-ja}}

[[Category:hReview]]

== Translations ==
更に別の言語で hReview の仕様ドラフトを読んでみましょう。
* [[hreview|english]]
* [[hreview-fr|français]]

Search engines-ja

2010-04-25T15:45:16Z

KitaitiMakoto: /* Yahoo */ translated

<entry-title>検索エンジン</entry-title>


{{TOC-right}}
ウェブ（つまり、自分のサイト以外も）を横断してマイクロフォーマットを索引化する検索エンジンの[[implementations|実装]]です。

== ウェブ検索 ==
一般的なウェブ検索です。一般にマイクロフォーマットを使ってウェブサイトを索引化する検索エンジンです。

=== Google ===
{{main|google-search}}

[http://google.com/ Google.com] はメインの検索で [[rel-nofollow-ja|rel-nofollow]]、[[hcard-ja|hCard]]、[[hreview-ja|hReview]]、[[hreview-aggregate|hReview の収集]]、[[hProduct]]（[http://www.google.com/support/webmasters/bin/answer.py?answer=99170 リッチスニペット]用に2009-05-12 以降）をサポートしています。Google は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://www.google.com/advanced_search 検索オプション - ライセンス]）と [[XFN-ja|XFN]] をサポートします。詳細は[[google-search|Google 検索]]をご覧ください。

=== Yahoo ===
{{main|yahoo-search}}
[http://search.yahoo.com Yahoo 検索]は [[rel-nofollow-ja|rel-nofollow]] をサポートしています。Yahoo は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://search.yahoo.com/cc Yahoo Creative Commons search]）をサポートしています。[http://developer.yahoo.com/search/boss/ Yahoo Search BOSS] や [http://developer.yahoo.net/blog/archives/2008/06/monkey_microformat.html Yahoo Search Monkey] を通して hCard、hCalendar、hReview、XFN、geo、rel-tag、adr をサポートしています。詳細は [[yahoo-search|Yahoo 検索]]をご覧ください。

== ブログ検索 ==
Search blog posts and blogs in general. Search engines that specifically index blogs, blog posts, and other realtime sources on the web using microformats.
=== IceRocket ===
* [http://www.icerocket.com IceRocket] through additional interfaces
** [http://www.icerocket.com/tags IceRocket Tag search] support [[rel-tag]] (to search for [http://www.icerocket.com/c?p=tags blog posts tagged with rel-tag]).
=== Technorati ===
* [http://technorati.com Technorati] ([[rel-nofollow]])
** [http://technorati.com/tags/ Technorati Tag Search] supports [[rel-tag]] (to search for blog posts tagged with rel-tag).

== プロトタイプやアルファ版 ==
=== socialsearchme ===
* [http://scrape.singpolyma.net/profile/ singpolyma social web search] ([[xfn]], [[hCard]]) part of the [http://code.google.com/p/diso/ diso] project.
** memorable URL: http://socialsearchme.com/
** e.g. try a [http://scrape.singpolyma.net/profile/?q=Jeremy search for Jeremy]
** 2008-08-19 [http://singpolyma.net/2008/08/diso-gets-search/ DiSo Gets Search] - blog post announcing it!
==== to do ====
* both <code>socialsearchme.com/?q=b</code> and <code>socialsearchme.com/b</code> should redirect/retrieve <code>scrape.singpolyma.net/profile/?q=b</code>.

=== Technorati Kitchen ===
* [http://kitchen.technorati.com Technorati Kitchen]
** [http://kitchen.technorati.com/contacts/search/ Technorati contacts search] ([[hCard]])
** [http://kitchen.technorati.com/events/search/ Technorati events search] ([[hCalendar]])

=== VIREL ===
* [http://virel.de/ VIREL] indexes both [[hCard]] and [[hCalendar]] and provides a user interface (pop-up menu) to choose between searching contacts or events.
** 2008-09-09 Tag Edge: [http://tagedge.com/2008/09/09/virel-microformats-search-engine/ Virel: Microformats Search Engine]

== マイクロフォーマットによる検索結果 ==
Search engines that publish microformats in their results (but may not necessarily be indexing microformats).
=== Karniyarik ===
* [http://www.karniyarik.com Karniyarik] Vertical Search Engine for Online Products ([http://www.karniyarik.com/karniyarik-web Stealth Beta]). Karniyarik's search results lists products and their vendors, which are marked up with [[hCard]] (e.g. [http://www.karniyarik.com/search.jsp?query=bebek+bezi search results for bebek bezi - diapers]). In addition, Karniyarik's [http://www.karniyarik.com/aboutus.jsp about page] is marked up with hCard.

== 関連ページ ==
* [[implementations]]

hcard-ja

2010-04-25T05:10:04Z

KitaitiMakoto: /* はじめに */ inclusion of rfc-2119-intro to rfc-2119-intro-ja

hreview-ja

2010-04-25T05:07:19Z

KitaitiMakoto: /* Introduction */ inclusion of rfc-2119-intro to rfc-2119-intro-ja

<entry-title> hReview 0.3 </entry-title>

{{DraftSpecification}}

[[hreview|hReview]] はHTMLやXHTML, Atom, RSS, 任意のXMLなどにレビュー（商品、サービス、ビジネス、イベントなど）を埋め込むのに適したシンプルかつオープンで分散型のフォーマットです。hReviewはオープンスタンダードな[[microformats]]の一つです。

[[hreview|hReview]]を使い始めてみたいなら、[http://microformats.org/code/hreview/creator hReview creator]でレビューを書いて、作成したコードをページに貼り付けてみてください。

== Microformats Draft Specification 2006-02-22 ==
<div class="vcard">
;Editor
:[[User:Tantek|Tantek Çelik]] (http://tantek.com/, and before at [http://technorati.com Technorati, Inc.])
</div>
; Authors
: [[User:Tantek|Tantek Çelik]] (affiliations above)
: [http://360.yahoo.com/alidiabali Ali Diab] ([http://yahoo.com Yahoo! Inc.])
: [http://ianmcall.blogspot.com/ Ian McAllister] ([http://amazon.com/ Amazon.com])
: [http://journals.aol.com/panzerjohn/abstractioneer John Panzer] ([http://www.aol.com America Online, Inc.])
: [http://ifindkarma.com/blog Adam Rifkin] ([http://labs.commerce.net/ CommerceNet Labs])
: [http://sippey.typepad.com/ Michael Sippey] ([http://sixapart.com Six Apart, Ltd])
[[hreview#Copyright|copyright]] and [[hreview#Patents|patents]] statements apply.

== Status ==
hReview 0.3 は microformats.org の仕様ドラフトです。[[hreview-feedback]]、irc.freenode.net 上の #microformats、[http://microformats.org/discuss/mail/microformats-discuss/ マイクロフォーマット議論メーリングリスト] で hReview に関する公開の議論が行われています。

=== Available languages ===
この仕様の英語版が唯一もととなるバージョンです。この文書の翻訳については [[#Translations]] の節をご覧ください。

=== Errata and Updates ===
この仕様での機知の間違いと問題は[[hreview-issues-resolved|考慮済み]]と[[hreview-issues-closed|解決済み]]問題ページで修正されています。[[hreview-issues|問題]]を報告する前にここを確認してください。

hReview 0.4 へのアップデートは、[[value-class-pattern-ja|value-class パターン]]同様開発中で、機知の訂正事項も含んでいます。

== Introduction ==
非常に多くのウェブサイトが、製品（映画、音楽、本）から企業（レストラン、ホテル、店）、イベント（コンサート、演劇）、人物（歌手、指導者、有名人）、場所（歴史的建造物、公園）、オンラインリソース（ウェブページ、ファイル）やレビューのレビューにいたるまで、あらゆる種類の事物に関する幅広い形式のレビューを公開しています。

こういったレビューの共有、配布、シンジケーション（配信）、アグリゲーション（集約）を可能にし、促進するため、hReview マイクロフォーマットを提案します。これはレビュー配布のオープンスタンダードです。既存の色々な[[review-examples|レビューの例]]や、[[review-formats|レビュー形式]]についての先人の試みを調べ、レビューのおおよそ最小のスキーマとして hReview を設計しました。フィードバックは [[hreview-feedback|hReview フィードバック]]ページにお願いします。

{{rfc-2119-intro-ja}}

=== Scope ===
多くのレビューでは、いくつか一般的な側面が共通しています。この最小の共通部分に基いている所では、hReview が使えます。

==== Out of scope ====
hReview ではレビューの特定の項目に特化したプロパティは除外されています。初めからシンプルかつ最小であり続けることが重要なのです。機能の追加は実装上必要だと認められた時に行われます。

「universal object identifier（統一物品識別子）」の概念――異なるショッピングサイトからいかにして同じ物品・項目・製品を特定するか――は、とても役に立つものもありますが、このフォーマットの範囲外です。

== Format ==
=== 一般 ===
hReviewフォーマットは、現在ウェブ上にたくさんあるレビューサイトとフォーマットに共通して使われているプロパティに基づいています。
使用できるプロパティ名は、[[hcard-ja|hCard]]と[[hcalendar-ja|hCalendar]]標準仕様に関連して定義されているものを元にして選ばれています。

=== Schema ===
hReviewのスキーマは以下の通りです:

* hReview ('''<code>hreview</code>''')
** '''<code>version</code>'''. 任意。テキスト。
** '''<code>summary</code>'''. 任意。テキスト
** item '''<code>type</code>'''. 任意。 product | business | event | person | place | website | url.
** '''<code>item</code>''' info. 必須。'''<code>fn</code>''' ('''<code>url</code>''' || '''<code>photo</code>''' ) | '''[[hcard-ja|hCard]]''' (人物または企業の場合) | '''[[hcalendar-ja|hCalendar]]''' (イベントの場合)
** '''<code>reviewer</code>'''. 任意。'''[[hcard-ja|hCard]]'''。
** '''<code>dtreviewed</code>'''. 任意。 ISO8601 絶対日時（absolute date time）
** '''<code>rating</code>'''. 任意。固定小数点数 [1.0-5.0]。あるいは、任意の '''<code>worst</code>''' (デフォルト：1.0) または '''<code>best</code>'''（デフォルト：5.0）またはその両方を持つ固定小数点数で、この場合も厳密な '''<code>value</code>''' を持つ。
** '''<code>description</code>'''. 任意。任意の妥当な HTML でマークアップされたテキスト。
** tags. 任意。キーワードやフレーズ。'''[[rel-tag-ja|rel-tag]]'''を使い、それぞれ任意の rating を持つ。
** permalink. 任意。'''[[rel-bookmark]]'''と'''[[rel-self]]'''を使う。
** license. 任意。'''[[rel-license]]'''を使う。

=== プロパティの詳細 ===
hReviewのプロパティの詳細は次の通りです。

'''version''':: この任意のプロパティには、コンテンツ中で使用しているhReviewのバージョンを指定することができます。このプロパティを省略すると、hReview仕様のv2.0またはそれ以降の任意のバージョンによって解釈をしていいと宣言したことになります。
実際には、この仕様の著者たちは、初期のバージョンの仕様によって生成されたコンテンツに対する後方互換性を維持することにコミットしています。
このプロパティはvCard RFC2426 section "3.6.9 VERSION Type Definition"で定義されている"VERSION"の文法と互換性があり、
結果としてそれを再利用したものになっています。本仕様に対するこのプロパティの値は"0.3"です。

'''summary''':: この任意のプロパティは、レビュー自体のタイトルを表します。

'''item type''':: この"type"という任意のプロパティはレビューされるitemのタイプを示し、それらは、product、business、event、person、place, website、urlのいずれか一つです。省略されている場合は、そのitemのタイプを導出してよい場合があります。もしitemが[[hcard-ja|hCard]]でもある場合は、そのitemのタイプはhCardの内容に基づいて"business"または"person"になります。もしitemが[[hcalendar-ja|hCalendar]]のeventでもある場合は、itemのタイプは"event"です。

'''item info''':: この必須プロパティは少なくとも''その''item(1つのhReviewは、ただ1つのitemについて説明します)の名前("fn"というサブプロパティを使用 - その名前に対応する整形済み文字列。ただし、イベントの item を除きます。イベントの場合は hCalendar の各 "vevent" の中に "summary" サブプロパティがなければなりません({{must}}))を持たなければなりません({{must}})。そして、そのitemに対応する少なくとも1つのURI ("url")を持つべきです({{should}})。さらに、そのitemの写真または絵("photo")のURLを含めることができます({{may}})。
itemのタイプが"person"または"business"の場合は、そのitem info (fn, url, photo)は[[hcard-ja|hCard]]の中に囲まれている必要があります({{must}})。
itemのタイプが"event"の場合は、そのitem infoは[[hcalendar-ja|hCalendar]] veventの中に囲まれているべきです({{should}})。
itemのURLではないユニークな識別子(e.g. ISBN、UPC など)は、そのitemのURN ("url")として表現することができます({{may}})。
itemの内側に含まれるmicroformats (現在は[[hcard|hCard]]と[[hcalendar|hCalendar]] event)は、item自体にセットすることができます。(e.g. class="item vcard") しかし、item infoの下位プロパティ("fn"、"url"、"photo")を使用する場合は、それらはitemの要素の内側になければなりません({{must}})。

'''reviewer''':: この任意のプロパティはレビューを書いた人を示します。
もしもreviewerが指定されている場合、そのreviewerを表現するhCardが必要です({{must}})。匿名のレビューにするには、"anonymous"(引用符を除く)をその"reviewer"のフルネームとしてください。
"reviewer"がhReviewの内側にない場合、パーザーはそのページのhReviewの外側を探すべきです。
"reviewer"がhReviewの外側にもない場合、パーザーは、そのドキュメントが使用している言語の中で定義されている著者を使うべきです。
すなわち、HTMLドキュメントの場合、 <code><nowiki><address></nowiki></code>で示されているそのページについての連絡先(これは [[hcard|hCard]]で同様にマークアップされているのが理想的です)、Atom 1.0では、<code><nowiki><entry></nowiki></code> <code><nowiki><author></nowiki></code>、または、それがなければ<code><nowiki><feed></nowiki></code> <code><nowiki><author></nowiki></code>、RSSでは<code><nowiki><item></nowiki></code>要素の内側にある<code><nowiki><author></nowiki></code>となります。

'''dtreviewed''':: 公開した時点に関するこの任意のプロパティは、レビューが書かれたか生み出された時点の [[ISO-8601|ISO8601]] 絶対日時（absolute date time）を提供''しなければなりません''（{{must}}）。このプロパティは UTC を使う''べき''（{{should}}）ですが、タイムゾーンオフセット構文を使うことも''できます''（{{may}}）。hReview に dtreviewed が無い場合は、外部の、hReview を取り囲む文脈中を見ます。その文脈が [[hatom|hAtom]] エントリーだった場合、フィードの "published"（見つからなければ "updated"）の日時を使います。それ以外の場合、dtreviewed として hReview を含む文書の（訳注：XML としての）言語（例えば Atom フィードの "published"/"updated" のような物）を参照して作成日時（見つからなければ更新日時）の情報を使い、それも無ければプロトコル（例えば HTTP Last-Modified やファイルシステムの最終更新日時）を使います。

'''rating''':: rating（格付け）は、項目の評価を含んだ 1.0 から 5.0 までの（精度が 10 進小数点以下一桁の）固定小数点数で、デフォルトでは高い値が良い評価を表します。任意で、別の "worst" または "best" またはその両方の数値を定義して違った範囲（例えば 0-10 の 6）を設定することも''できます''（{{may}}）。"best" の値を "worst" よりも小さい数にしてもかまいません。

'''description''':: この任意のプロパティにはレビュアーの意見を書いたテキスト全文が入ります。このプロパティには妥当な HTML マークアップが含まれていても''かまいません''（{{may}}）。ユーザーエージェントは全てのマークアップを保持する''べきです''（{{should}}）。多角的な記述や節をまたぐ記述（例えば賛否や長短）は description プロパティに含まれる''べきです''（{{should}}）。

'''tags''':: タグはレビュアーが item と結びつけたキーワードやフレーズ（ここのキーワードやフレーズのタグには [[rel-tag-ja|rel-tag]] マイクロフォーマットを使います）のリストを使って表現されます。レビュアーは任意で、そのタグに関する rating を各 [[rel-tag-ja|rel-tag]] の中で提供することが''できます''（{{may}}）。例：ambience:5。あるタグのデフォルトの rating は、もしあれば item 全体の rating 範囲を使います。worst～best を設定し直して使うことも''できます''（{{may}}）。レビュー著者は、その方が使いやすければ、同じ意味を保持しながらこの構造を逆転させることも''できます''（{{may}}）。つまり、評価付きのタグを表すのに rating の中に [[rel-tag-ja|rel-tag]] を入れることもできるのです。注：評価付きのタグは、理想としては、そのタグが意味する物を説明しているタグスペース使う''べきです''（{{should}}）。例えば Food:18/30 というのは、Food タグとして 30 点中 18 点が何を意味しているのか説明している Food のタグスペースにリンクしている''べきです''（{{should}}）。

'''permalink''':: この任意のプロパティは hReview の URL です。あるハイパーリンクがレビュー自身の固定リンクだと示すには、このプロパティの <code><a href></code> タグに加えて、<code>rel="self bookmark"</code> を使''わなければなりません''（{{must}}）。ハイパーリンクに既に <code>rel</code> が含まれている場合は、この属性の中に空白で区切って <code>self</code> と <code>bookmark</code> という値を含め''なければなりません''（{{must}}）。索引作成者／プログラムは、（一つのページから何度も索引を作るなど）複数の情報源から同じレビューを特定して照合するための一意の ID として、レビューの固定リンクを使うことが''できます''（{{may}}）。レビュー著者は固定リンクだと示すために、要素に "permalink" というクラス名を使うことができますが、必須ではありません。

'''license''':: hReview はの記事自身が基づいているライセンスへのリンクを'''[[rel-license-ja|rel-license]]''' マイクロフォーマットを使って示します。

次のプロパティ名は [[hcard-ja|hCard]] と [[hcalendar-ja|hCalendar]] マイクロフォーマットからの再利用です： <code>version, summary, fn, url, photo, description</code>。さらに、hCard で記された item とレビュアーには hCard のどのプロパティが含まれていても''かまいません''（{{may}}）。rel 属性の "self" という値は [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 仕様]からの再利用です。

いくつかのプロパティでは、より多くの意味を持つこともあります。ですから、それについては特殊な扱いをしなければなりません。例：

* 全ての "url" は、hReview の中の 'hreview' という class 名を持つ要素の内側で <code><a class="url" href="...">...</a></code> を使う
*また、"photo" については <code><img class="photo" src="..." alt="...の写真" /></code> を使う

* rating は画像や「☆☆☆」といった文字として表現されることも多い。そういった文字はこれについては明確な格付けの略記なので、<code><abbr></code> 要素が特に使いやすい。例：<code><abbr class="rating" title="3.0">☆☆☆</abbr></code>。これは次の節でもさらに検討される。

==== Language ====
* hReview が書かれている自然言語を明確に伝えるため、class="hreview" を持つ要素で HTML 標準の 'lang' 属性を使ってください。例：<code><div class="hreview" lang="en"> ... </div></code>。（item 名などの）hReview の一部が異なる言語で書かれている場合は、その部分に 'lang' 属性を使ってください。
* レビューの言語を扱う必要のある hReview 処理プログラムは、HTML 標準の 'lang' を仕様に従って処理しなければなりません（{{must}}）。

=== Human vs. Machine Readable ===
プロパティに <code><abbr></code> 要素を使う場合、そのプロパティの値には、要素の内容ではなく '<code>title</code>' 属性を使います。そうすることで、また別のユーザーフレンドリーな値の表現を提供することができるのです。

同様に、プロパティに <code><img /></code> を使う時には、次のように扱わなければなりません（{{must}}）。

# "photo" プロパティや、値として URL を使う他のプロパティには <code>src="..."</code> 属性がその値を決めます。
# その他のプロパティには <code><img /></code> 要素の '<code>alt</code>' 属性がプロパティ値になります。

=== Object Includes ===

hReview 0.3 はオブジェクト[[include-pattern|インクルードパターン]]をサポートしています。

一つのページで一つのアイテムとそのアイテムに関する複数のレビューを並べることがよくあります。そのアイテムの各レビューで item info を繰り返さなければならないということを避けるため、次のようにするべきです。最初のレビューを hReview としてマークアップし、item info では一意な "id" 属性を付けます。それ以降のレビューではオブジェクト[[include-pattern|インクルードパターン]]を使って最初のレビューから item info をインクルードします。

=== Notes ===
この節は参考用です。

* レビューを hReview マイクロフォーマットでマークアップすることで、レビューが索引化できるようになるでしょう。これはレビュー自体の著作権には影響しません。レビューの著作権は、上の仕様で述べられているように、公開する人が [[rel-license-ja|rel-license]] を使って厳密に記述できます。
* 列挙された item type の項目は開発中で、拡張されるかもしれません。
* 特定のアイテムに関するより詳しい情報は、残りの情報と一緒に、そのアイテムの URL で記述されているべきです。
* 多くの格付けシステムが 1.0 から 5.0 の範囲を使い、そのほとんどが格付けを星の数（半分も可）で表現します。望むなら、サイトで格付けを表現するのに何らかの画像を使うこともできます。

== Examples ==
以下では現在のウェブサイトからレビューの例をいくつか取り上げて、どれほど簡単にレビューの構造化されたマイクロフォーマットである hReview をサポートするように改良できるかを示します。

すぐに [[hreview-ja|hReview]] を始めたいという人は、[http://microformats.org/code/hreview/creator hReview creator] を使ってレビューを書き、自分のブログで公表してみてください。

=== Restaurant reviews ===

次はレストランの簡単なオンラインレビューです。

<pre><nowiki>
<div>
星5個中5個
<h4>Crepes on Cole は最高</h4>
レビュアー：Tantek - 2005年4月18日
<blockquote>
Crepes on Cole はサンフランシスコの小さなクレープ屋で最高の所の一つだ。
出す物もサービスも素晴らしい。大きい物から小さい物まで、
パーティ用のいろいろな大きさのテーブルがある。窓側の席は、
すぐそこに停まる N-Judah を眺めたり、N-Judah の方から見たりという素晴らしい体験ができる。
わたしはここで近所の WiFi に助けられながらたくさんの仕事をしているのだが、
何度も楽しい集会をしてもいる。
</blockquote>
訪問日：2005年4月
食べたもの：フィレンツェ風クレープ（Florentine crepe）
</div>
</nowiki></pre>

このレビューに hReview を付け加えるのはいい例です。

<pre><nowiki>
<div class="hreview">
星5個中5個
<h4 class="summary">Crepes on Cole は最高</h4>
レビュアー：Tantek -
<abbr class="dtreviewed" title="20050418T2300-0700">2005年4月18日</abbr>
<div class="description item vcard">
Crepes on Cole は
サンフランシスコの小さなクレープ屋で最高の所の一つだ。
出す物もサービスも素晴らしい。大きい物から小さい物まで、
パーティ用のいろいろな大きさのテーブルがある。窓側の席は、
すぐそこに停まる N-Judah を眺めたり、N-Judah の方から見たりという素晴らしい体験ができる。
わたしはここで近所の WiFi に助けられながらたくさんの仕事をしているのだが、
何度も楽しい集会をしてもいる。
</div>
訪問日：2005年4月
食べたもの：フィレンツェ風クレープ（Florentine crepe）
</div>
</nowiki></pre>

このレビュー例ではいくつか hReview としては記録されていないプロパティ（訪問日、食べたもの）があることに注意してください。これは hReview を最小で簡単なものにしておくため、敢えてしたことです。

この例の hReview は次のように表現できます。

星5語中5個 
'''Crepes on Cole は最高''' 
レビュアー：Tantek - 2005年4月18日 

Crepes on Cole はサンフランシスコの小さなクレープ屋で最高の所の一つだ。出す物もサービスも素晴らしい。大きい物から小さい物まで、パーティ用のいろいろな大きさのテーブルがある。窓側の席は、すぐそこに停まる N-Judah を眺めたり、N-Judah の方から見たりという素晴らしい体験ができる。わたしはここで近所の WiFi に助けられながらたくさんの仕事をしているのだが、何度も楽しい集会をしてもいる。

訪問日：2005年4月 
食べたもの：フィレンツェ風クレープ（Florentine crepe） 

==== Multidimensional Restaurant Review ====
レストランのレビューには、そのレストランの異なる面について格付けをしているものもあります。そういった詳細なレビューは、hReview ではタグのついた格付けを使って表現します。また、そのレビューの説明の中にあるインラインのタグに注意してください。

次はそのようなレビューをテキスト形式で表した例です。

Cafe Borrone

1010 El Camino Real, Menlo Park, CA 94025, +1-650-327-0830;
cafeborrone.com

食事：18/30；雰囲気：19/30；サービス：15/30価格：$$...

このカフェはサンフランシスコ半島の素敵なオアシスだ。
外にある噴水は、近くの El Camino の車の音を打ち消してくれる。
Cafe Borrone は壮麗な個人書店の隣にあって、
新たに購入した本や輸入雑誌を広げながら
コーヒーや軽食を取るには理想的な場所だ。
スープとサンドイッチの特別メニューは毎日変わる。
温めたばかりのミニバゲットについてくる、
クルトン入りのコーンチャウダーとチーズの大きな塊が特にすばらしい。
夜は混むことが多く、見知らぬ人と相席になることもある。
エスプレッソ愛好家にはイッリのコーヒーがたまらないだろう。
賑やかさは遅い朝の静けさから夜の圧倒されるようなジャズバンドまで、様々だ。

hReview ではこうなります。

<pre><nowiki>
<div class="hreview">
<div class="item vcard">
<div class="fn org summary">Cafe Borrone</div>

1010 El Camino Real,
Menlo Park,
CA
94025,

+1-650-327-0830;
<a class="url" href="http://cafeborrone.com">cafeborrone.com</a>
</div>
<ul>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
食事：18/30</a>；</li>
<li class="rating"><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
雰囲気：19/30</a>；</li>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
サービス：15/30</a>；</li>
<li class="rating"><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
価格：<abbr class="value" title="2">$$</abbr>...</a></li>
</ul>
<div class="description">
この<abbr class="type" title="business">
<a href="http://en.wikipedia.org/wiki/cafe" rel="tag">カフェ</a></abbr>
はサンフランシスコ半島の素敵なオアシスだ。
外にある噴水は、近くの El Camino の車の音を打ち消してくれる。
Cafe Borrone は壮麗な個人書店の隣にあって、
新たに購入した本や輸入雑誌を広げながら
<a href="http://en.wikipedia.org/wiki/coffee" rel="tag">コーヒー</a>
や軽食を取るには理想的な場所だ。
<a href="http://technorati.com/tag/soup" rel="tag">スープ</a>と
<a href="http://technorati.com/tag/sandwich" rel="tag">サンドイッチ</a>
の特別メニューは毎日変わる。
温めたばかりのミニバゲットについてくる、
クルトン入りのコーンチャウダーとチーズの大きな塊が特にすばらしい。
夜は混むことが多く、見知らぬ人と相席になることもある。
<a href="http://flickr.com/photos/tags/espresso" rel="tag">エスプレッソ</a>
愛好家には
<a href="http://en.wikipedia.org/wiki/Illy" rel="tag">イッリ</a>のコーヒーがたまらないだろう。
遅い朝の静けさから夜の圧倒されるような
<a href="http://en.wikipedia.org/wiki/jazz" rel="tag">ジャズ</a>バンドまで、様々だ。 </div>
レビュー（<a href="http://microformats.org/wiki/hreview">
hReview v0.3</a>）
：匿名。
<abbr class="dtreviewed" title="20050428T2130-0700">2005年4月18日</abbr>。
</div>
</nowiki></pre>

次のような CSS のスタイルシートを添えると……

<pre><nowiki>
a.url { display:block }
ul { margin:1em 0; padding:0 }
ul li { display:inline }
</nowiki></pre>

この hReview は元のテキストと同じように表示できます。

Cafe Borrone 
1010 El Camino Real, Menlo Park, CA 94025, +1-650-327-0830; 
[http://cafeborrone.com/ cafeborrone.com] 
 
[http://en.wikipedia.org/wiki/Food 食事：18/30];
[http://flickr.com/photos/tags/Ambience 雰囲気：19/30];
[http://en.wikipedia.org/wiki/Service サービス：15/30];
[http://en.wikipedia.org/wiki/Price 価格：$$...] 

この[http://en.wikipedia.org/wiki/cafe カフェ]はサンフランシスコ半島の素敵なオアシスだ。外にある噴水は、近くの El Camino の車の音を打ち消してくれる。Cafe Borrone は壮麗な個人書店の隣にあって、新たに購入した本や輸入雑誌を広げながら[http://en.wikipedia.org/wiki/coffee コーヒー]や軽食を取るには理想的な場所だ。[http://technorati.com/tag/soup スープ]と[http://technorati.com/tag/sandwich サンドイッチ]の特別メニューは毎日変わる。温めたばかりのミニバゲットについてくる、クルトン入りのコーンチャウダーとチーズの大きな塊が特にすばらしい。夜は混むことが多く、見知らぬ人と相席になることもある。[http://flickr.com/photos/tags/espresso エスプレッソ]愛好家には[http://en.wikipedia.org/wiki/Illy イッリ]のコーヒーがたまらないだろう。賑やかさは遅い朝の静けさから夜の圧倒されるような[http://en.wikipedia.org/wiki/jazz ジャズ]バンドまで、様々だ。

レビュー（[http://microformats.org/wiki/hreview hReview v0.3]）：匿名。2005年4月28日。

=== Product review ===
以下は製品レビューの例です。

<pre><nowiki>
<div>
<a href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/">
<img src="http://images.amazon.com/images/P/B000089CJI.01._SCTHUMBZZZ_.jpg"
alt="アルバムジャケット写真：The Postal Service：Give Up" />
The Postal Service：Give Up</a>
<blockquote>
「相手の望み通りに接してあげる、
停止信号を守る、病気を治す……
人はそういったことで褒められるべきだと思ってる。
眠るから起こさないで……」

このアルバムでは「Nothing Better」もいい曲だ。
</blockquote>
（★★★★★）
</div>
</nowiki></pre>

このレビューに hReview を足すのもとても簡単ですが、この場合は hReview に必須の rating と reviewer 用の要素を加える必要があります。

<pre><nowiki>
<div class="hreview">
<a class="url fn" href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/">
<img src="http://images.amazon.com/images/P/B000089CJI.01._SCTHUMBZZZ_.jpg"
alt="アルバムジャケット写真：The Postal Service：Give Up" />"
class="photo" />
The Postal Service: Give Up</a>
<div class="description">
「相手の望み通りに接してあげる、
停止信号を守る、病気を治す……
人はそういったことで褒められるべきだと思ってる。
眠るから起こさないで……」

このアルバムでは「Nothing Better」もいい曲だ。
</div>
（<abbr class="rating" title="5">★★★★★</abbr>）
レビュー：
<a class="url fn" href="http://ifindkarma.com/blog/">Adam Rifkin</a>。
<abbr class="dtreviewed" title="200502">2005年2月</abbr>。

</div>
</nowiki></pre>

この hReview は例えばこう表示できます。

[アルバムジャケット写真：]
[The Postal Service：]
[ Give Up ]

The Postal Service：Give Up

「相手の望み通りに接してあげる、停止信号を守る、病気を治す、送り主の住所を書いて手紙を送る……人はそういったことで褒められるべきだと思ってる。眠るから起こさないで……」

このアルバムでは「Nothing Better」もいい曲だ。

（★★★★★）

レビュー：Adam Rifkin。2005年2月。

=== Movie Review ===
最後に、映画のレビューの例です。

<pre><nowiki>
<div>
anonymous, April 18th, 2005
<div>
<a lang="zh" href="http://www.imdb.com/title/tt0299977/">
Ying Xiong (HERO)
</a>
</div>
<div>評価：5 点満点中 4 点</div>
<blockquote>
この映画は音楽と映像が素晴らしい。 </blockquote>
</div>
</nowiki></pre>

hReview ではこうです。

<pre><nowiki>
<div class="hreview">

anonymous,
<abbr class="dtreviewed" title="20050418">April 18th, 2005</abbr>

<div class="item">
<a lang="zh" class="url fn" href="http://www.imdb.com/title/tt0299977/">
Ying Xiong (HERO)
</a>
</div>
<div>評価：5 点満点中 4 点</div>
<div class="description">
この映画は音楽と映像が素晴らしい。 </div>
</div>
</nowiki></pre>

このように表示できます。

匿名。2005年4月18日。 
Ying Xiong（HERO） 
評価：5 点満点中 4 点 

この映画は音楽と映像が素晴らしい。

== Examples in the wild ==
この説は'''参考情報'''です。この仕様の文中で書かれている可能性をはるかに超えて、実際に hReview を使っている例がたくさんあります。これは [[hreview-examples-in-wild|別ページ]]に移しました。

[[hreview-examples-in-wild|hReview Examples in the wild]] を参照してください。

== Implementations ==
この節は'''参考情報'''です。hReview の実装も、この文中で書かれている可能性以上にあります。[[hreview-implementations|別ページ]]に移しました。

[[hreview-implementations|hReview Implementations]] を参照してください。

== Design Principles ==
This section is '''informative'''. hReview was designed using design [[principles]] similar to those that went into [[hCard]] and thus this overview is included for informational purposes.

{{semantic-xhtml-design-principles-ja}}

== Inspiration and Acknowledgments ==
hReview 開発参加のオープンな呼び掛けに応えてくれた皆さんに感謝します。特に次の人たちに、建設的な意見とフィードバックを頂いたことに謝意を示したいと思います。[http://www.richardault.com/ Richard Ault]、[http://dannyayers.com Danny Ayers]、[http://www.vertexdev.com/~jeff/ Jeffrey Barr]、[http://adriancuthbert.blogspot.com/ Adrian Cuthbert]、[http://jason.defillippo.com/ Jason DeFillippo]、[http://www.hybernaut.com/bdv Brian Del Vecchio]、Scott Derringer、[http://budgibson.com/home/ Bud Gibson]、[http://joi.ito.com/ Joi Ito]、[http://www.kanai.net/weblog/ Gen Kanai]、[http://niallkennedy.com/ Niall Kennedy]、[http://labs.commerce.net/wiki/index.php/Rohit_Khare Rohit Khare]、[http://theryanking.com/ Ryan King]、[http://www.jluster.org/ Jonas Luster]、[http://epeus.blogspot.com/ Kevin Marks]、Mark Nottingham、[http://www.powazek.com/ Derek Powazek]、[http://www.judysbook.com/ Jeff Rodenburg]、[http://sifry.com/alerts/ David Sifry]、[http://jystewart.net/ James Stewart]、[http://kung-foo.tv/ Adriaan Tijsseling]、[http://www.flashenabled.com/ Phillip Torrone]、Thai Tran、[http://w6daily.winn.com/ Phillip Winn]、[http://yohei-y.blogspot.com YAMAMOTO Yohei]。

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard-ja|hCard]]
* [[hcalendar-ja|hCalendar]]
* [[rel-tag-ja|rel-tag]]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc3986.txt RFC3986]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

=== Informative References ===
* [http://www.w3.org/TR/REC-CSS1 CSS1]
* ISO.8601.1988
** International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.（国際標準化機構「データ要素と交換フォーマット――情報交換――日付及び時刻の表現」ISO 標準 8601、1988年7月）
* [http://www.w3.org/TR/1998/NOTE-datetime-19980827 W3C NOTE-datetime-19980827]
* [http://www.ietf.org/rfc/rfc3667.txt RFC3667]
* [http://www.ietf.org/rfc/rfc3668.txt RFC3668]
* [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy]
* [http://local.yahoo.com/details?id=21359628 Crepes on Cole reviews on Yahoo!Local]
* そのほかのレビューの取り組み。[[reviews-formats]]をご覧ください。
* http://developers.technorati.com/wiki/hReview に助けられました。

==== Similar Work ====
* [[hlisting-proposal|hListing]]
* [[xoxo-ja|XOXO]]

== Copyright ==
{{MicroformatCopyrightStatement2005}}

=== Patents ===
{{MicroFormatPatentStatement-ja}}

== Work in progress ==
この仕様は現在進行中です。更なる特徴が議論され、理解され、書かれた時には追加されるでしょう。

=== Changes from v0.2 ===
hReview v0.3 では [[hreview-v0.2|hReview v0.2]] から以下の変更がなされました。

規範的な変更：
# 企業と人物の item の description には [[hcard-ja|hCard]] を（使うべき（SHOULD）ではなく）使わなければなりません（MUST）
# "reviewer" が変更されました
## Ryan King と Mark Nottingham のフィードバックにより、reviewer が＊任意＊になりました
## hReview に reviewer が無い場合には、そのページの中の hReview の外側を見て、レビュアーを見つけてください。外側にも "reviewer" が無い場合は、文書の言語に含まれている著者情報（HTML ページの <code><nowiki><address></nowiki></code> など）を reviewer として使ってください。
## レビュアー情報の表現には [[hcard-ja|hCard]] を（使うべき（SHOULD）ではなく）使わなければなりません（MUST）
# "dtreviewed" が変更されました
## Ryan King と Mark Nottingham のフォードバックにより、dtreviewed が＊任意＊になりました
## hReview に dtreviewed が無い場合は、外部の、hReview 取り囲む文脈中を見てください。その文脈が [[hatom|hAtom]] エントリーだった場合、dtreviewed として "published"（見つからなければ "updated"）を使ってください。もしエントリー中に無ければ、フィードの "published"（見つからなければ "updated"）を使ってください。それも無ければ、文書の言語に含まれている情報（例えば Atom フィードの"published"/"updated" のような物）を、その次にプロトコルの情報（例えば HTTP Last-Modified やファイルシステムの最終更新日時）を使ってください。
# 'type' が 'event' の item の表現には [[hcalendar-ja|hCalendar]] を使うべき（SHOULD）です
# 出版会の知識に基づいて、rating の値の桁を 10 進数で一桁加えました
# rating の best/worst を提示（マークアップ）する時に、より厳密に rating の値をマークアップするため [http://microformats.org/wiki/hcard-ja#.E5.80.A4.E3.81.AE.E6.8A.9C.E7.B2.8B hCard の "value" の構造]（例では "tel" プロパティの中で使われているような）を使ってください。
# その hReview 全体のライセンスを示すため [[rel-license-ja|rel-license]] を追加しました
# Eran Globen の提案により、関連する tag を提供するのに、tag の中に rating を入れるのと同じようにして、rating の中に tag を入れられるようにしました。
# item info を繰り返さずに同じ item に複数のレビューを書けるよう [[include-pattern]] のサポートを加えました。

参考すべき変更（いくつかあるが中でも特別な物）：
# 基準や関連項目のタグにはそのタグの格付けを説明しているタグスペースを使うのが理想であることに注意してください。例えば食事：18/30 が何を意味するか説明しているなど。
# 例は適宜更新されます。

== Further Reading ==
* [http://www.technorati.com/cosmos/referer.html このページについて議論しているブログ]（[http://technorati.com/search/http%3A%2F%2Fmicroformats.org%2Fwiki%2Fhreview 英語ページについて議論しているブログ]）もご覧ください。

== Related Pages ==
{{hreview-related-pages-ja}}

[[Category:hReview]]

== Translations ==
更に別の言語で hReview の仕様ドラフトを読んでみましょう。
* [[hreview|english]]
* [[hreview-fr|français]]

Search engines-ja

2010-04-23T19:46:47Z

KitaitiMakoto: /* ウェブ検索 */ translated abstract

<entry-title>検索エンジン</entry-title>


{{TOC-right}}
ウェブ（つまり、自分のサイト以外も）を横断してマイクロフォーマットを索引化する検索エンジンの[[implementations|実装]]です。

== ウェブ検索 ==
一般的なウェブ検索です。一般にマイクロフォーマットを使ってウェブサイトを索引化する検索エンジンです。

=== Google ===
{{main|google-search}}

[http://google.com/ Google.com] はメインの検索で [[rel-nofollow-ja|rel-nofollow]]、[[hcard-ja|hCard]]、[[hreview-ja|hReview]]、[[hreview-aggregate|hReview の収集]]、[[hProduct]]（[http://www.google.com/support/webmasters/bin/answer.py?answer=99170 リッチスニペット]用に2009-05-12 以降）をサポートしています。Google は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://www.google.com/advanced_search 検索オプション - ライセンス]）と [[XFN-ja|XFN]] をサポートします。詳細は[[google-search|Google 検索]]をご覧ください。

=== Yahoo ===
{{main|yahoo-search}}

[http://search.yahoo.com Yahoo search] supports [[rel-nofollow]]. Through additional interfaces, Yahoo supports [[rel-license]] ([http://search.yahoo.com/cc Yahoo Creative Commons search]) and hCard, hCalendar, hReview, XFN, geo, rel-tag, adr through [http://developer.yahoo.com/search/boss/ Yahoo Search BOSS] and [http://developer.yahoo.net/blog/archives/2008/06/monkey_microformat.html Yahoo Search Monkey]. See [[yahoo-search]] for more details.

== ブログ検索 ==
Search blog posts and blogs in general. Search engines that specifically index blogs, blog posts, and other realtime sources on the web using microformats.
=== IceRocket ===
* [http://www.icerocket.com IceRocket] through additional interfaces
** [http://www.icerocket.com/tags IceRocket Tag search] support [[rel-tag]] (to search for [http://www.icerocket.com/c?p=tags blog posts tagged with rel-tag]).
=== Technorati ===
* [http://technorati.com Technorati] ([[rel-nofollow]])
** [http://technorati.com/tags/ Technorati Tag Search] supports [[rel-tag]] (to search for blog posts tagged with rel-tag).

== プロトタイプやアルファ版 ==
=== socialsearchme ===
* [http://scrape.singpolyma.net/profile/ singpolyma social web search] ([[xfn]], [[hCard]]) part of the [http://code.google.com/p/diso/ diso] project.
** memorable URL: http://socialsearchme.com/
** e.g. try a [http://scrape.singpolyma.net/profile/?q=Jeremy search for Jeremy]
** 2008-08-19 [http://singpolyma.net/2008/08/diso-gets-search/ DiSo Gets Search] - blog post announcing it!
==== to do ====
* both <code>socialsearchme.com/?q=b</code> and <code>socialsearchme.com/b</code> should redirect/retrieve <code>scrape.singpolyma.net/profile/?q=b</code>.

=== Technorati Kitchen ===
* [http://kitchen.technorati.com Technorati Kitchen]
** [http://kitchen.technorati.com/contacts/search/ Technorati contacts search] ([[hCard]])
** [http://kitchen.technorati.com/events/search/ Technorati events search] ([[hCalendar]])

=== VIREL ===
* [http://virel.de/ VIREL] indexes both [[hCard]] and [[hCalendar]] and provides a user interface (pop-up menu) to choose between searching contacts or events.
** 2008-09-09 Tag Edge: [http://tagedge.com/2008/09/09/virel-microformats-search-engine/ Virel: Microformats Search Engine]

== マイクロフォーマットによる検索結果 ==
Search engines that publish microformats in their results (but may not necessarily be indexing microformats).
=== Karniyarik ===
* [http://www.karniyarik.com Karniyarik] Vertical Search Engine for Online Products ([http://www.karniyarik.com/karniyarik-web Stealth Beta]). Karniyarik's search results lists products and their vendors, which are marked up with [[hCard]] (e.g. [http://www.karniyarik.com/search.jsp?query=bebek+bezi search results for bebek bezi - diapers]). In addition, Karniyarik's [http://www.karniyarik.com/aboutus.jsp about page] is marked up with hCard.

== 関連ページ ==
* [[implementations]]

Search engines-ja

2010-04-23T19:43:39Z

KitaitiMakoto: /* Google */ translated

<entry-title>検索エンジン</entry-title>


{{TOC-right}}
ウェブ（つまり、自分のサイト以外も）を横断してマイクロフォーマットを索引化する検索エンジンの[[implementations|実装]]です。

== ウェブ検索 ==
General web search. Search engines that index websites in general using microformats.
=== Google ===
{{main|google-search}}

[http://google.com/ Google.com] はメインの検索で [[rel-nofollow-ja|rel-nofollow]]、[[hcard-ja|hCard]]、[[hreview-ja|hReview]]、[[hreview-aggregate|hReview の収集]]、[[hProduct]]（[http://www.google.com/support/webmasters/bin/answer.py?answer=99170 リッチスニペット]用に2009-05-12 以降）をサポートしています。Google は更に別のインターフェイスを通して [[rel-license-ja|rel-license]]（[http://www.google.com/advanced_search 検索オプション - ライセンス]）と [[XFN-ja|XFN]] をサポートします。詳細は[[google-search|Google 検索]]をご覧ください。

=== Yahoo ===
{{main|yahoo-search}}

[http://search.yahoo.com Yahoo search] supports [[rel-nofollow]]. Through additional interfaces, Yahoo supports [[rel-license]] ([http://search.yahoo.com/cc Yahoo Creative Commons search]) and hCard, hCalendar, hReview, XFN, geo, rel-tag, adr through [http://developer.yahoo.com/search/boss/ Yahoo Search BOSS] and [http://developer.yahoo.net/blog/archives/2008/06/monkey_microformat.html Yahoo Search Monkey]. See [[yahoo-search]] for more details.

== ブログ検索 ==
Search blog posts and blogs in general. Search engines that specifically index blogs, blog posts, and other realtime sources on the web using microformats.
=== IceRocket ===
* [http://www.icerocket.com IceRocket] through additional interfaces
** [http://www.icerocket.com/tags IceRocket Tag search] support [[rel-tag]] (to search for [http://www.icerocket.com/c?p=tags blog posts tagged with rel-tag]).
=== Technorati ===
* [http://technorati.com Technorati] ([[rel-nofollow]])
** [http://technorati.com/tags/ Technorati Tag Search] supports [[rel-tag]] (to search for blog posts tagged with rel-tag).

== プロトタイプやアルファ版 ==
=== socialsearchme ===
* [http://scrape.singpolyma.net/profile/ singpolyma social web search] ([[xfn]], [[hCard]]) part of the [http://code.google.com/p/diso/ diso] project.
** memorable URL: http://socialsearchme.com/
** e.g. try a [http://scrape.singpolyma.net/profile/?q=Jeremy search for Jeremy]
** 2008-08-19 [http://singpolyma.net/2008/08/diso-gets-search/ DiSo Gets Search] - blog post announcing it!
==== to do ====
* both <code>socialsearchme.com/?q=b</code> and <code>socialsearchme.com/b</code> should redirect/retrieve <code>scrape.singpolyma.net/profile/?q=b</code>.

=== Technorati Kitchen ===
* [http://kitchen.technorati.com Technorati Kitchen]
** [http://kitchen.technorati.com/contacts/search/ Technorati contacts search] ([[hCard]])
** [http://kitchen.technorati.com/events/search/ Technorati events search] ([[hCalendar]])

=== VIREL ===
* [http://virel.de/ VIREL] indexes both [[hCard]] and [[hCalendar]] and provides a user interface (pop-up menu) to choose between searching contacts or events.
** 2008-09-09 Tag Edge: [http://tagedge.com/2008/09/09/virel-microformats-search-engine/ Virel: Microformats Search Engine]

== マイクロフォーマットによる検索結果 ==
Search engines that publish microformats in their results (but may not necessarily be indexing microformats).
=== Karniyarik ===
* [http://www.karniyarik.com Karniyarik] Vertical Search Engine for Online Products ([http://www.karniyarik.com/karniyarik-web Stealth Beta]). Karniyarik's search results lists products and their vendors, which are marked up with [[hCard]] (e.g. [http://www.karniyarik.com/search.jsp?query=bebek+bezi search results for bebek bezi - diapers]). In addition, Karniyarik's [http://www.karniyarik.com/aboutus.jsp about page] is marked up with hCard.

== 関連ページ ==
* [[implementations]]

Search engines-ja

2010-04-23T19:28:03Z

KitaitiMakoto: translated abstract

<entry-title>検索エンジン</entry-title>


{{TOC-right}}
ウェブ（つまり、自分のサイト以外も）を横断してマイクロフォーマットを索引化する検索エンジンの[[implementations|実装]]です。

== ウェブ検索 ==
General web search. Search engines that index websites in general using microformats.
=== Google ===
{{main|google-search}}

[http://google.com/ Google.com] supports [[rel-nofollow]], [[hCard]], [[hReview]], [[hreview-aggregate|hReview aggregate]], [[hProduct]] (since 2009-05-12 for [http://www.google.com/support/webmasters/bin/answer.py?answer=99170 rich snippets]) in main search. Through additional interfaces Google supports [[rel-license]] ( [http://www.google.com/advanced_search Google Advanced Search - Usage rights]), and [[XFN]] ([http://code.google.com/apis/socialgraph/ Google Social Graph API]. See [[google-search]] for more details.

=== Yahoo ===
{{main|yahoo-search}}

[http://search.yahoo.com Yahoo search] supports [[rel-nofollow]]. Through additional interfaces, Yahoo supports [[rel-license]] ([http://search.yahoo.com/cc Yahoo Creative Commons search]) and hCard, hCalendar, hReview, XFN, geo, rel-tag, adr through [http://developer.yahoo.com/search/boss/ Yahoo Search BOSS] and [http://developer.yahoo.net/blog/archives/2008/06/monkey_microformat.html Yahoo Search Monkey]. See [[yahoo-search]] for more details.

== ブログ検索 ==
Search blog posts and blogs in general. Search engines that specifically index blogs, blog posts, and other realtime sources on the web using microformats.
=== IceRocket ===
* [http://www.icerocket.com IceRocket] through additional interfaces
** [http://www.icerocket.com/tags IceRocket Tag search] support [[rel-tag]] (to search for [http://www.icerocket.com/c?p=tags blog posts tagged with rel-tag]).
=== Technorati ===
* [http://technorati.com Technorati] ([[rel-nofollow]])
** [http://technorati.com/tags/ Technorati Tag Search] supports [[rel-tag]] (to search for blog posts tagged with rel-tag).

== プロトタイプやアルファ版 ==
=== socialsearchme ===
* [http://scrape.singpolyma.net/profile/ singpolyma social web search] ([[xfn]], [[hCard]]) part of the [http://code.google.com/p/diso/ diso] project.
** memorable URL: http://socialsearchme.com/
** e.g. try a [http://scrape.singpolyma.net/profile/?q=Jeremy search for Jeremy]
** 2008-08-19 [http://singpolyma.net/2008/08/diso-gets-search/ DiSo Gets Search] - blog post announcing it!
==== to do ====
* both <code>socialsearchme.com/?q=b</code> and <code>socialsearchme.com/b</code> should redirect/retrieve <code>scrape.singpolyma.net/profile/?q=b</code>.

=== Technorati Kitchen ===
* [http://kitchen.technorati.com Technorati Kitchen]
** [http://kitchen.technorati.com/contacts/search/ Technorati contacts search] ([[hCard]])
** [http://kitchen.technorati.com/events/search/ Technorati events search] ([[hCalendar]])

=== VIREL ===
* [http://virel.de/ VIREL] indexes both [[hCard]] and [[hCalendar]] and provides a user interface (pop-up menu) to choose between searching contacts or events.
** 2008-09-09 Tag Edge: [http://tagedge.com/2008/09/09/virel-microformats-search-engine/ Virel: Microformats Search Engine]

== マイクロフォーマットによる検索結果 ==
Search engines that publish microformats in their results (but may not necessarily be indexing microformats).
=== Karniyarik ===
* [http://www.karniyarik.com Karniyarik] Vertical Search Engine for Online Products ([http://www.karniyarik.com/karniyarik-web Stealth Beta]). Karniyarik's search results lists products and their vendors, which are marked up with [[hCard]] (e.g. [http://www.karniyarik.com/search.jsp?query=bebek+bezi search results for bebek bezi - diapers]). In addition, Karniyarik's [http://www.karniyarik.com/aboutus.jsp about page] is marked up with hCard.

== 関連ページ ==
* [[implementations]]

Search engines-ja

2010-04-23T19:23:37Z

KitaitiMakoto: sync: english: 2009-05-19T17:12:58

<entry-title>検索エンジン</entry-title>


<h1>検索エンジン</h1>
{{TOC-right}}
Search engine [[implementations]] that index microformats across the web (i.e. not just on their own site).

== ウェブ検索 ==
General web search. Search engines that index websites in general using microformats.
=== Google ===
{{main|google-search}}

[http://google.com/ Google.com] supports [[rel-nofollow]], [[hCard]], [[hReview]], [[hreview-aggregate|hReview aggregate]], [[hProduct]] (since 2009-05-12 for [http://www.google.com/support/webmasters/bin/answer.py?answer=99170 rich snippets]) in main search. Through additional interfaces Google supports [[rel-license]] ( [http://www.google.com/advanced_search Google Advanced Search - Usage rights]), and [[XFN]] ([http://code.google.com/apis/socialgraph/ Google Social Graph API]. See [[google-search]] for more details.

=== Yahoo ===
{{main|yahoo-search}}

[http://search.yahoo.com Yahoo search] supports [[rel-nofollow]]. Through additional interfaces, Yahoo supports [[rel-license]] ([http://search.yahoo.com/cc Yahoo Creative Commons search]) and hCard, hCalendar, hReview, XFN, geo, rel-tag, adr through [http://developer.yahoo.com/search/boss/ Yahoo Search BOSS] and [http://developer.yahoo.net/blog/archives/2008/06/monkey_microformat.html Yahoo Search Monkey]. See [[yahoo-search]] for more details.

== ブログ検索 ==
Search blog posts and blogs in general. Search engines that specifically index blogs, blog posts, and other realtime sources on the web using microformats.
=== IceRocket ===
* [http://www.icerocket.com IceRocket] through additional interfaces
** [http://www.icerocket.com/tags IceRocket Tag search] support [[rel-tag]] (to search for [http://www.icerocket.com/c?p=tags blog posts tagged with rel-tag]).
=== Technorati ===
* [http://technorati.com Technorati] ([[rel-nofollow]])
** [http://technorati.com/tags/ Technorati Tag Search] supports [[rel-tag]] (to search for blog posts tagged with rel-tag).

== プロトタイプやアルファ版 ==
=== socialsearchme ===
* [http://scrape.singpolyma.net/profile/ singpolyma social web search] ([[xfn]], [[hCard]]) part of the [http://code.google.com/p/diso/ diso] project.
** memorable URL: http://socialsearchme.com/
** e.g. try a [http://scrape.singpolyma.net/profile/?q=Jeremy search for Jeremy]
** 2008-08-19 [http://singpolyma.net/2008/08/diso-gets-search/ DiSo Gets Search] - blog post announcing it!
==== to do ====
* both <code>socialsearchme.com/?q=b</code> and <code>socialsearchme.com/b</code> should redirect/retrieve <code>scrape.singpolyma.net/profile/?q=b</code>.

=== Technorati Kitchen ===
* [http://kitchen.technorati.com Technorati Kitchen]
** [http://kitchen.technorati.com/contacts/search/ Technorati contacts search] ([[hCard]])
** [http://kitchen.technorati.com/events/search/ Technorati events search] ([[hCalendar]])

=== VIREL ===
* [http://virel.de/ VIREL] indexes both [[hCard]] and [[hCalendar]] and provides a user interface (pop-up menu) to choose between searching contacts or events.
** 2008-09-09 Tag Edge: [http://tagedge.com/2008/09/09/virel-microformats-search-engine/ Virel: Microformats Search Engine]

== マイクロフォーマットによる検索結果 ==
Search engines that publish microformats in their results (but may not necessarily be indexing microformats).
=== Karniyarik ===
* [http://www.karniyarik.com Karniyarik] Vertical Search Engine for Online Products ([http://www.karniyarik.com/karniyarik-web Stealth Beta]). Karniyarik's search results lists products and their vendors, which are marked up with [[hCard]] (e.g. [http://www.karniyarik.com/search.jsp?query=bebek+bezi search results for bebek bezi - diapers]). In addition, Karniyarik's [http://www.karniyarik.com/aboutus.jsp about page] is marked up with hCard.

== 関連ページ ==
* [[implementations]]

tools-ja

2010-04-23T19:16:07Z

KitaitiMakoto: sync: english: 2008-11-25T21:24:00

= ツール、テストケース、追加調査 =


例、コード、テストケースを探すのに一番いい場所は、それぞれ個別のマイクロフォーマット用のページの中にあります。少ないながら、一つだけではないフォーマットを処理する必要のある、横断的なツールやサービスという物が少しだけあります。このページは複数のマイクロフォーマットをまたぐ編集・解析・検証プログラム、テストケース、その他の情報向けのページです。

*[[accessibility|アクセシビリティ]]
*[[external-issues|外部の問題]]
*[[faqs-for-rdf|RDF の FAQ]]
*[[icalendar-implementations|iCalendar の実装]]
*[[internationalization|国際化]]
*[[microformats-issues|マイクロフォーマットの問題]] - 複数のマイクロフォーマットに関する問題。
*[[parsing-microformats|マイクロフォーマットの解析]]
*[[profile-uri-examples-in-wild|プロファイル URI の現実の例]] （<code>head</code> 要素用のプロファイル URI）
*[[examples-in-wild|現実の例]] - 発表されたマイクロフォーマット用の実例
*[[Search engines|検索エンジン]]
*[http://hg.microformats.org/ ソースコードのリポジトリー] -- [[mercurial-quick-start|リポジトリーからコードをダウンロードする方法]]
*[[user-profile-examples-in-wild|ユーザープロファイルの現実の例]]（ソーシャルウェブサイト向けのユーザープロファイル）
*[[vcard-implementations|vCard の実装]]、[[vcard-errata|vCard の正誤表]]、[[vcard-suggestions|vCard の提案]]
*[[why-are-content-standards-hard|コンテンツ用標準が難しいわけ]]
*[[converting-microformats-to-other-formats|マイクロフォーマットから他のフォーマットへの変換]]
* [http://ujuicer.sandbox.matttthompson.com/ μJuicer] - vCard（.vcf）を hCard に変換する

value-class-pattern-ja

2010-04-23T18:02:04Z

KitaitiMakoto: /* Atom 生成プログラム */ translated

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
[[hAtom]] を読み込んで Atom を生成するマイクロフォーマット実装は更に以下に従わなければなりません（{{must}}）。
* 日付と日時の値を全て [[RFC3339]] のフォーマットに正規化する

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** Microformats exist and function in ''valid'' HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''The <code>title</code> attribute should only be used for content!'''
** The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

value-class-pattern-ja

2010-04-23T17:57:28Z

KitaitiMakoto: /* hAtom の updated での日付の推測処理 */ fixed mistranslation

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
microformats implementations which consume [[hAtom]] and generate
Atom {{must}} in addition:
* normalize all date and datetime values to [[RFC3339]].

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** Microformats exist and function in ''valid'' HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''The <code>title</code> attribute should only be used for content!'''
** The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

value-class-pattern-ja

2010-04-23T17:55:36Z

KitaitiMakoto: /* hAtom の updated での日付の推測処理 */ translated

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
ブログの投稿に於いて日付が普通一度だけ、大抵は "投稿日（published）" として表示されて、それで "投稿日（published）" と "更新日（updated）" の両方を示すのと同じです（URL 付きの実例があれば完璧でしょう）。

ですから、[[hAtom]] entry で "updated" として時間（と、任意でタイムゾーン）だけが明記されている時にその "updated" の日付を "published" から推測できるとすると便利でしょう。例えば同じ日に更新されたブログ投稿ではこうなります。

<source lang=html4strict>

短いブログ投稿の例
は
2009-08-01 の 12:06 に投稿されました。
また、12:10 に更新されました。

</source>

記事を書く人にとってもっと簡単にするため、hAtom 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時を特定できます。そのため、以下のように "updated" span 要素内にある "value" span 要素を不要にできます。

<source lang=html4strict>

短いブログ投稿の例
は 
2009-08-01 の 12:06
また、12:10 に更新されました。

</source>

==== Atom 生成プログラム ====
microformats implementations which consume [[hAtom]] and generate
Atom {{must}} in addition:
* normalize all date and datetime values to [[RFC3339]].

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** Microformats exist and function in ''valid'' HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''The <code>title</code> attribute should only be used for content!'''
** The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

value-class-pattern-ja

2010-04-13T02:36:58Z

KitaitiMakoto: sync: english: 2010-04-13T04:04:57

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
Similarly, in blog posts that indicate both when they were "published" and "updated", the date is usually only displayed once, typically when "published" (real world examples with URLs would help for thoroughness).

Thus it would be convenient if we could imply an [[hAtom]] entry "updated" date from its "published" date when only the time (and optionally timezone) was specified for its "updated", e.g. for a blog post that was updated the same day:

<source lang=html4strict>

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

</source>

To simplify this further for authors, hAtom processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "updated" span:

<source lang=html4strict>

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

</source>

==== Atom 生成プログラム ====
microformats implementations which consume [[hAtom]] and generate
Atom {{must}} in addition:
* normalize all date and datetime values to [[RFC3339]].

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** Microformats exist and function in ''valid'' HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''The <code>title</code> attribute should only be used for content!'''
** The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* 2009-05-12 notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern] by Matthias Pfefferle (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

value-class-pattern-ja

2010-04-08T05:52:43Z

KitaitiMakoto: sync: english: 2010-04-07T10:25:31

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
Similarly, in blog posts that indicate both when they were "published" and "updated", the date is usually only displayed once, typically when "published" (real world examples with URLs would help for thoroughness).

Thus it would be convenient if we could imply an [[hAtom]] entry "updated" date from its "published" date when only the time (and optionally timezone) was specified for its "updated", e.g. for a blog post that was updated the same day:

<source lang=html4strict>

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

</source>

To simplify this further for authors, hAtom processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "updated" span:

<source lang=html4strict>

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

</source>

==== Atom 生成プログラム ====
microformats implementations which consume [[hAtom]] and generate
Atom {{must}} in addition:
* normalize all date and datetime values to [[RFC3339]].

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** Microformats exist and function in ''valid'' HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''The <code>title</code> attribute should only be used for content!'''
** The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

value-class-pattern-ja

2010-03-15T13:34:16Z

KitaitiMakoto: sync: english: 2010-03-11T04:19:26

<entry-title>Value Class Pattern</entry-title>


value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。

''この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートして[[value-class-pattern-feedback|フィードバック]]することが推奨されます。'''注：'''実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。''

[http://microformats.org/blog/2009/05/12/value-class-pattern/ ブログのアナウンス]も参照してください。

__TOC__
; 編集者
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Celik]]
; 短縮 URL
: <kbd>http://tr.im/valueclass</kbd>

マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは [[hcard-ja|hCard]] の <code>tel: type</code> や <code>tel: value</code> など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。

こういったプロパティでは、<code>value</code> という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。

== 簡単な例 ==

自宅の電話番号をマークアップするとしましょう。

vCard の一部はこうです。

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard の一部はこうです。

<source lang=html4strict>

Home:
+1.415.555.1212

</source>

この場合、<code>tel</code> の <code>value</code> は <code>+1.415.555.1212</code> であり、<code>Home: +1.415.555.1212</code> とはなりません。

マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素（value 要素）を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。

別の例を挙げます。今度は（イギリスに）地域化した電話番号を使っています。

<source lang=html4strict>

Home:
+44 (0) 1223 123 123

</source>

この場合、<samp>+441223123123</samp> というのが電話番号の妥当な''データ''ですが、イギリスで国内向けの電話番号を表すには <samp>(0)</samp> を含めます。つまり、世界のどこかから <kbd>+441223123123</kbd> で電話でき、イギリス国内からは <kbd>01223123123</kbd> で電話できるのです。<kbd>'''+440'''1223123123</kbd> というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。

上のマークアップでは二つの <code>value</code> クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。

もう一つ例を示します。[[geo]] の座標に場所の名前を追加しています。

<source lang=html4strict>
ブリックレイヤーズ・アームズの外をぶらぶらしています。

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</source>

文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、<code>value</code> class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。

== パースの基本 ==
# value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
# そういったマイクロフォーマットプロパティの class 名を持つ要素に <code>value</code> という子孫要素（"value" 要素）がある場合は、パーサーは、その要素の以下の部分を使うべきです。
## value 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
## value 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
## その他の要素の場合は、内部のテキストを使います。
# <code>value</code> という class 名を持つプロパティに複数の子孫がある場合（複数の value 要素）
## そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入''せずに''結合するべきです。
## マイクロフォーマットプロパティが日時の値を要求している場合については[[#日付と時刻のパース|日時のパース]]の節を参照してください。
# <code>value</code> という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、<code>value</code> という class の <code>foo</code> 要素に <code>value</code> class の <code>bar</code> という子孫があった場合、<code>value</code> として <code>foo</code> の内容を使います。プロパティの値をさらに分離するために class が <code>value</code> の追加要素を入れ子にして使うことはできません。

例

<source lang=html4strict>


子犬は最高！
でも子猫はもっといい！


</source>

この例では、<code>description</code> に子要素‘<code>value</code>’があり、その子要素には''孫要素''の‘<code>value</code>’があります。ですが、<code>value</code> のパースは最初の階層で止まり、<code>description</code> のデータは「<samp><code>子犬は最高！でも子猫はもっといい！</code></samp>」であり、「<samp>子犬は最高！</samp>」ではありません。

== 日時の値 ==
=== 概要 ===
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。

value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。

これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です：

<source lang=html4strict>
毎週のディナーは、

<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の 18:30

に。

</source>

次の 'dtstart' の値を生成します：

<source lang=text>
DTSTART:2008-06-24T18:30:00
</source>

また、iCalendar 変換プログラムは次の DTSTART を生成します：

<source lang=text>
DTSTART:20080624T183000
</source>

タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時（"floating" datetime）であることを示します。変動日時の例としては、午前７時になるようセットした目覚まし時計や一般的な労働時間の午前９時～午後５時があります。

=== 日付と時刻のパース ===
全ての（それぞれのマイクロフォーマット仕様で定義された）日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて（場合によっては代わりとして）以下のルールが適用されます。

"value" 要素が見付かった時、その要素から次のようにして値をパースします。
* 要素が <code>img</code> か <code>area</code> 要素であれば、その要素の <code>alt</code> 属性の値を使います。
* 要素が <code>abbr</code> 要素であれば、その要素の <code>title</code> 属性の値を使います。
* その他の要素の場合は、内部のテキストを使います。
* 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
* 値に、仕様に従った日付＊のみ＊がある場合、特に次の ISO8601 の日付パターンに（[http://ja.wikipedia.org/wiki/ISO_8601 ウィキペディアの ISO8601 概要] にあるように）適合する場合には、
** YYYY-MM-DD
** YYYY-DDD
** それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日（ordinal day）が必要です。
** 日付を定義する "value" 要素が他にあっても無視します。
* 値に（タイムゾーンはあっても無くても）仕様に従った時刻＊のみ＊がある場合、それは時刻として次のいずれかにマッチするかパースします。
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の最初の 0 は省略できます。
** MM は 00 から 59 までの分です。
** SS は 00 から 59（うるう秒では 60）までの秒で、任意です。省略した場合には 00 秒と推測します。
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の最初の 0 は省略できます。
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ：[[X2V]] はこれを実装しています。
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
*** MM を省略した場合には 00 分と推測します。
** 時刻を定義する "value" 要素が他にあっても無視します。
* 値に、仕様に従ったタイムゾーン＊のみ＊がある場合、それは次のいずれかにマッチするかパースします。
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX は 00 から 12 までのタイムゾーンの時間オフセットで、10 未満の時の最初の 0 は省略できます。
** YY は 00 から 59 までのタイムゾーンの分オフセットですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
** Z は GMT を表す文字 'Z' です。
** タイムゾーンを定義する "value" 要素が他にあっても無視します。

"value" をパースすることで少なくとも日付が特定できるなら、その "value" は全体として妥当です。パーサーは特定した日付に "T" と特定した時刻（特定できれば。秒が与えられなければ 00 秒と推測します）、特定したタイムゾーン（タイムゾーンと何らかの時間が与えられれば）を連結して日付全体の値を構築します。
* YYYY-MM-DD - 時刻ははっきりしません。
* YYYY-MM-DDTHH:MM:SS - 時刻ははっきりしますがタイムゾーンははっきりしません。これは変動時刻です。
* YYYY-MM-DDTHH:MM:SS-XXYY または
* YYYY-MM-DDTHH:MM:SSZ または
* YYYY-MM-DDTHH:MM:SS+XXYY - であれば、時刻もタイムゾーンもどちらもはっきりします。

=== フォーマットに特化した詳細 ===
以下は value class パターンを使った、フォーマットに特化した詳細と最適化です。

;この節の短縮 URL
:http://tr.im/vcpfso （英語）

==== hCalendar の dtend での日付の推測処理 ====
開始日と終了日が同じイベントは普通、イベントの日付を一度だけ表示します（これは DRY [[principles|原則]]から言って価値のあることです）（現実の例：[http://upcoming.yahoo.com/event/3010807/ Upcoming]、……URL つきの例がもっとあれば徹底するのに役立つでしょう）。

そのため、[[hcalendar-ja|hCalendar]] イベントの "dtend" に時刻（と任意でタイムゾーン）しか明記されていない時にも、"dtstart" の日付からそれを推測できると便利でしょう。例えばこうです。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

書く人にとって更に簡単にするため、hCalendar 処理プログラムは value-class パターンの日付と時刻のルールを使って正しい時刻を特定することができます。これによって、次のように "dtend" span 要素内の "value" span 要素を不要にできます。

<source lang=html4strict>

パーティは

2009-06-26の
19:00から
22:00まで。

</source>

hCalendar から iCalendar への変換プログラムは、上二つのどちらの例からでも以下の（妥当な .ics ファイルの一部としての）iCalendar 断片を作り出すべきです。

<source lang=text>
BEGIN:VEVENT
SUMMARY:パーティ
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

注：[[X2V]]は dtend での dtstart からの日付の推測処理を実装しています。

「現実の」例：
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop （現実の例ではありますが、この Wiki 内の例です）

==== iCalendar 生成プログラム ====
[[hcalendar-ja|hCalendar]] を読み込んで iCalendar を生成するマイクロフォーマット実装は、更に次のことをしなければなりません（{{must}}）。
# 日付のダッシュ "-" セパレーターを全て取り除く。
# 時刻のコロン ":" セパレーターを全て取り除く。
# [[dtend-issue]] での解決に従って、日付のみしかない（仕様に従った時刻が無い）hCalendar の <code>dtend</code> プロパティ値（その日を含んでいる）と意味が同じ iCalendar の <code>DTEND</code> プロパティ値（その日を含まない）を生成するため、値の全てに丸一日を加える。
# 日時の＋/－の相対的なタイムゾーンを計算し、"Z" で終わる有効な UTC の値を生成する。

==== hAtom の updated での日付の推測処理 ====
Similarly, in blog posts that indicate both when they were "published" and "updated", the date is usually only displayed once, typically when "published" (real world examples with URLs would help for thoroughness).

Thus it would be convenient if we could imply an [[hAtom]] entry "updated" date from its "published" date when only the time (and optionally timezone) was specified for its "updated", e.g. for a blog post that was updated the same day:

<source lang=html4strict>

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

</source>

To simplify this further for authors, hAtom processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "updated" span:

<source lang=html4strict>

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

</source>

==== Atom 生成プログラム ====
microformats implementations which consume [[hAtom]] and generate
Atom {{must}} in addition:
* normalize all date and datetime values to [[RFC3339]].

=== 起源とテスト ===
この節は参考用です。

value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。

テストケースは [[value-class-date-time-tests]] をご覧ください。

== <code>title</code> 属性からの値のパース ==
<code>value-title</code> という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく <code>title</code> 属性に含まれていることを示すことができます。

これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。

例として日付の即席の地域化を使うことができます。

<source lang=html4strict>
好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、

去年

のことです。

</source>

<code>value-title</code> のパース規則は先述の <code>value</code> と同様ですが、以下の点は異なります。

* マイクロフォーマットのプロパティが <code>value-title</code> という class 名の子要素を持つ場合は、要素の一部をパースする <code>value</code> という class 名とは違い、その要素の <code>title</code> 属性の内容をパースしなければなりません。

=== 機械向けデータ公開用の <code>value-title</code> の使用 ===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>


 
mobile

+44 7773 000 000

</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>

 
March 14th 2009, around half-past four

</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

=== 機械向けデータの <code>value-title</code> のパース ===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code> </code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern.(Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human legible forms of the property data, and warn authors if the forms do not match.

=== value-title の使用制限 ===

Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>.

== テストケース ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr> ==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** Microformats exist and function in ''valid'' HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''The <code>title</code> attribute should only be used for content!'''
** The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== 現実の例 ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== 実装 ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).

* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

== 記事 ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

== 関連ページ ==
This section is '''informative'''.
* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

hcard-ja

2010-02-21T18:44:13Z

KitaitiMakoto: sync: english: 2010-02-20T04:55:40

<entry-title>hCard 1.0</entry-title>


<dfn style="font-style:normal;font-weight:bold">hCard</dfn> は、vCard ([[rfc-2426|RFC2426]]) のプロパティと値を利用して、[[semantic-xhtml|HTML]] で人や会社、組織や場所を表現する [[microformats-ja|microformat]] です。hCard は HTML や XHTML はもちろんのこと、Atom、RSS、その他の XML に埋め込むことができます。

'''hCard を利用するには、いくつかの方法があります。'''
*[http://blog.livedoor.jp/forestk/misc/microformats/hCard/creator-ja/ hCard creator] hCard を利用し、作成したコードをページにはりつける。
*[[hcard-authoring|hCard authoring tips]] を読んで、hCard のマークアップを行う。

<div class="vcard">
; 編集者
: [[User:Tantek|Tantek Çelik]] (http://tantek.com/, and before at [http://technorati.com Technorati, Inc.], and at [http://microsoft.com/ Microsoft Corporation])
</div>
; 作者: [http://tantek.com/ Tantek Çelik] (affiliations above)
: [[User:Brian|Brian Suda]] (http://suda.co.uk/)

; 謝辞: [[hcard-ja#原案及び謝辞|謝辞のセクション]]をご覧ください。

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

== 状態 ==
hCard 1.0 is a microformats.org specification. Public discussion on hCard takes place on [[hcard-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-discuss/ microformats-discuss mailing list].

=== 利用できる言語 ===
The English version of this specification is the only normative version. For translations of this document see the [[#translations]] section.

=== 訂正事項と更新事項 ===
Known errors and issues in this specification are corrected in [[hcard-issues-resolved|resolved]] and [[hcard-issues-closed|closed]] issues. Please check there before reporting [[hcard-issues|issues]].

The hCard 1.0.1 update is currently under development and incorporates known errata corrections as well as the [[value-class-pattern]].

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

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

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

{{rfc-2119-intro}}

== フォーマット ==
=== 基本情報 ===
vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) のプロパティ名や値が、hCard の基礎となります。

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

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

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

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

'''必須プロパティ'''
* '''fn'''
* '''n'''[[#note1|1]] (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)

任意プロパティ
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value)
* agent
* bday
* category
* class
* email (type, value)
* geo (latitude, longitude)
* key
* label
* logo
* mailer
* nickname
* note
* org (organization-name, organization-unit)
* photo
* rev
* role
* sort-string
* sound
* tel[[#note2|2]] (type, value)
* title
* tz
* uid
* url

=== プロパティについて ===
[[#property-list-n|1. ^]]: 'n' プロパティは、[[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]にあるルールに当てはまる場合は、任意 ({{optional}}) プロパティとなります。 
[[#property-list-tel|2. ^]]: tel - 電話番号は、[http://en.wikipedia.org/wiki/E.123 E.123]に従って記述することができます ({{may}})。文字の入った電話番号 (例: +1-555-FORMATS) は、数字で表記しなければなりません ({{must}})。<code>abbr</code> を利用して、ソフトウェアには数字から成る電話番号の方を伝えることもできます (<code><nowiki><abbr title="+15553676287">+1-555-FORMATS</abbr></nowiki></code>)。

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

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

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

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

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

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

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

=== 値の抜粋 ===
要素の一部だけがプロパティの値として当てはまるという場合があります。例えば、'tel' のように、サブタイプを持つようなプロパティです。このような場合は特別な class 名である "<code>value</code>" を用い、プロパティの値として適切なものをマークアップします。家の電話番号をマークアップする hCard を例に取り説明しましょう。 

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>

home:
+1.415.555.1212

</source>

この hCard は次のように表示されるでしょう。

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

home:
+1.415.555.1212

</div>



=== プロパティの例外 ===
vCard には、Web ページの内容としてあまり意味をなさない、もしくは何らかのかたちですでに存在しているプロパティが存在しています。このセクションでは、そのようなプロパティに対し、何を行い、何を行わないかを説明します。

# vCard の '''NAME'''、'''PROFILE'''、'''SOURCE'''、'''PRODID'''、'''VERSION''' プロパティは [[rfc-2426|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 文書の場合、<code><title></code> 要素) を用いることが推奨されます ({{should}})。PROFILE の値には、[[rfc-2426|RFC2426]] より "<code>VCARD</code>" の値を使うことができます ({{may}})。SOURCE プロパティには、ページの URL を用いることが推奨されます ({{should}})。hCard を vCard に変換するサービスならば、そのパラメーターとしても用いることができるでしょう。PRODID プロパティは、実際に vCard を出力するサービスやアプリケーションのみが記述するべきです ({{should}})。同様に、そのようなアプリケーションのみが、[[rfc-2426|RFC2426]] のセクション 3.6.9 に倣い、VERSION プロパティに "3.0" という値をつけるべきです ({{should}})。

=== 組織のコンタクト情報 ===
もし、"FN" と "ORG"（organization；組織）プロパティが同じ値を持っている場合 (多くの場合、これらは class="fn org" と同じ要素に記述されています)、その hCard は会社や組織、場所のコンタクト情報を表すものとみなされます ({{should}})。このとき、作成者は "N" プロパティを記述することはできない ({{must-not}})、もしくは、"" と、空文字列を記述する必要があります。このため、パーサは "N" プロパティの省略をふまえた対応が推奨されます ({{should}})。この場合は、全ての "N" サブプロパティに空文字列があるものとみなします。

=== "n" の推測処理 ===
vCard では "N" プロパティの記述が必須となっています。ところが vCard 仕様書 ([[rfc-2426|RFC2426]]) では、最後の方 (p.38) にある作者の vCard に "N" プロパティが含まれていません。この明らかな矛盾は、"FN" プロパティがこの仕様書のように、多くの場合において "N" プロパティの内容を暗示していると解釈すれば問題なくなります。というわけで、hCard では次のように規定します。

もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値がホワイトスペースで区切られた二つの単語のみで構成されており、さらに "N" プロパティが存在しない場合、"N" は "FN" プロパティの値から推測されます。もし "FN" が単語一つの場合は次の段落を、もし "FN" が三つ以上の単語である場合、作成者は "N" プロパティを明示的にマークアップする必要があります ({{must}})。しかし、組織名の場合はこのルールに当てはまりません。この場合は[[hcard-ja#.E7.B5.84.E7.B9.94.E3.81.AE.E3.82.B3.E3.83.B3.E3.82.BF.E3.82.AF.E3.83.88.E6.83.85.E5.A0.B1|組織のコンタクト情報]]で書かれているルールが適用されます。

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

これらのルールにより、次の表記であれば簡単に名前を "FN" に記述することができます。
* given-name (スペース) family-name
* family-name (コンマ) given-name
* family-name (コンマ) given-name のイニシャル
* family-name (スペース) given-name のイニシャル (任意のピリオド)

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語で名前を記述するときには、この推測処理を利用することはできません。必ず given-name、family-name プロパティを利用し、明示的に名前を記述しなければなりません。

<pre><nowiki>
<div class="vcard">

マイクロ
太郎

</div>
</nowiki></pre>
</div>

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

"nickname" の推測機構は [[hcard-ja#.22n.22_.E3.81.AE.E6.8E.A8.E6.B8.AC.E5.87.A6.E7.90.86|"n" の推測処理]]と似ています。もし "FN" と "ORG" プロパティが同じではなく、また "FN" の値が単語一つで構成され、さらに "N" プロパティが存在しない場合、次のような処理がなされます。

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

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

<source lang=html4strict>

daveman692

</source>

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

=== "organization-name" の推測処理 ===
"ORG" プロパティは organization-name と organization-unit という二つのサブプロパティを持っています。しかしほとんどの場合、作成者は organization-name のみを記述します。よって、もし "ORG" プロパティが "organization-name" プロパティを内側に持たない場合、"ORG" プロパティの内容は必ず "organization-name" とみなされます ({{must}})。

=== カテゴリーとしてのタグ ===
hCard のカテゴリーは [[rel-tag]] を用い、タグとして表現することも可能です ({{may}})。"category" プロパティが rel-tag である場合、そのタグはカテゴリーとして扱われます。

=== 'type' サブプロパティの値 ===
'type' サブプロパティがとる値は、その親プロパティによって異なります。これらの 'type' サブプロパティの値は大文字小文字を区別しません (case-INSENSITIVE)。よって "Home" は "home" と同じであり、その他の値と組み合わせた場合についても同様です。たとえば、家の電話番号で、かつ優先番号であるものは次のようになります。

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<source lang=html4strict>
Home (preferred):
+1.415.555.1212

</source>

この例は次のように表示されるでしょう。

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
Home (preferred):
+1.415.555.1212

</div>

==== type with unspecified value ====
When the type of a property is specified, and there is no explicit value specified, then everything in the property except for the type is considered the value of the property. E.g.

<source lang=html4strict>
Home +1.415.555.1212
</source>

is equivalent to:

<source lang=html4strict>
Home +1.415.555.1212
</source>

And thus the type is "home" and the value is "+1.415.555.1212".

==== adr tel email types ====
次のリストは ''参考情報'' です。

規範的な type の値は [[rfc-2426|RFC2426]] のセクション 3.2.1 ADR、3.3.1 TEL、3.3.2 EMAIL を参照してください (ここでは利便性の為にコピーしています)。type サブプロパティのデフォルト値はリストの最初に並んでおり、また大文字で記述されています。また、これらの type は複数指定することができます。

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref, "IANA に登録された他のアドレスタイプ"

<div style="border: thin dashed #600; width: 95%; padding: .5em 1em; background-color:#fee;">
注: 日本語などの言語では、これらサブプロパティの多くを利用することができません。サブタイプはマークアップの制限上、その内容を訳すことができないからです。
</div>

=== プロファイル ===
hCard の XMDP プロファイル は http://microformats.org/profile/hcard にあります。

hCard を使うコンテンツは、
<source lang=html4strict>
<head profile="http://microformats.org/profile/hcard">
</source>
や
<source lang=html4strict>
<link rel="profile" href="http://microformats.org/profile/hcard">
</source>
又は
<source lang=html4strict>
このコンテンツは <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a> を使っています。
</source>
などとしてこのプロファイルに触れるべきです（{{should}}）。
なお、上にある方法を組み合わせてもかまいません。

=== パース処理 ===
[[hcard-parsing|hCard parsing]] をご覧ください。

== hCard の例 ==
このセクションは参考情報です。

=== vCard のサンプル ===
次にあるのは vCard のサンプルです。
<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
END:VCARD
</nowiki></pre>

この vCard を hCard で表現すると次のようになります。なお、推測処理ができるプロパティについては省略してあります。他の例は [[hcard-example1-steps| hCard Example 1]] をご覧ください。

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

この hCard は次のように表示されるでしょう。
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]
</div>

Note: hCard のマークアップにはバージョン情報が必要ありません。なぜならバージョンは <head> 要素の 'profile' 属性に記述されたプロファイルで定義されているからです。

=== hCard の実例 ===
次にあるのは [http://www.commerce.net/ Commercenet] のコンタクト情報です。この情報は hCard を用いて記述されているので、microformats をパース処理するツールにより見つけることができます。

<div class="vcard">
<div class="fn org">'''CommerceNet'''</div>
<div class="url">'''<nowiki>http://www.commerce.net/</nowiki>'''</div>
<div class="adr">'''Work:'''
<div class="street-address">'''169 University Avenue'''</div>
'''Palo Alto''', '''CA'''  '''94301'''
<div class="country-name">'''USA'''</div>
</div>
<div class="tel">'''Work +1-650-289-4040'''</div>
<div class="tel">'''Fax +1-650-289-4041'''</div>
<div>'''Email <nowiki>info@commerce.net</nowiki>'''</div>
</div>

The mark-up, emboldening omitted for clarity, with the following semantic improvements:
* <code>abbr</code> to expand abbreviations
* hyperlinking the org name with the url

<source lang=html4strict>
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
Work:
<div class="street-address">169 University Avenue</div>
Palo Alto,
<abbr class="region" title="California">CA</abbr>  
94301
<div class="country-name">USA</div>
</div>
<div class="tel">
Work +1-650-289-4040
</div>
<div class="tel">
Fax +1-650-289-4041
</div>
<div>Email:
info@commerce.net
</div>
</div>
</source>

=== その他の例 ===
[[hcard-examples|hCard examples]] には vCard 仕様書 [[rfc-2426|RFC2426]] の例をすべて hCard にしたものをはじめ、もっとたくさんの例があります。

== 実世界での例 ==
このセクションは'''参考情報'''です。すでに世界には多くの hCard が存在しています。以前はこの仕様書で紹介していましたが、数が増えすぎてしまったため、別のページを用意しました。

[[hcard-examples-in-wild|hCard Examples in the wild]] で、実際に使われている hCard をご覧ください。

== 実装 ==
このセクションは'''参考情報'''です。前のセクションと同じく、hCard の実装についても別のページを用意しています。

[[hcard-implementations|hCard Implementations]] で、hCard の実装についてご覧ください。

== 記事 ==
このセクションは'''参考情報'''です。hCard の他の読み物は[[hcard-articles-ja|hCard の記事]]をご覧ください。

== hCard ボタン ==
hCard を使ったあなたのページに、次にあるボタンを貼り付けましょう。[[buttons#hCard]] には、最近追加されたボタンもあります。

* http://www.crowley.nl/images/hcard.png (ミラー:http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS でボタン風にデザインすることもできます。[http://re-run.com/about/microformat-badges microformat badges @ re-run] をご覧ください。

== 著作権 ==
仕様の作成者である [[User:Tantek|Tantek Çelik]] および [[User:Brian|Brian Suda]] が、自分のページでパブリックドメインの声明を行っています。よって、この仕様はパブリックドメインです。

{{MicroFormatPublicDomainContributionStatement}}

== 特許 ==
{{MicroFormatPatentStatement-ja}}

== 参考文献 ==
=== 規範的な参考文献 ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU 勧告 E.123] 電話番号フォーマット (有料)
* [[rfc-2119|RFC 2119]]

=== その他の参考文献 ===
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* [[iso-8601|ISO8601]]

==== hCard を利用する仕様 ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== hCard に似通っているもの ====
このセクションは'''参考情報'''です。
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== 原案及び謝辞 ==
このセクションは'''参考情報'''です。
vCard を "何年も前に" 教えてくれた私の良き友人 [http://vadim.com/ Vadim] に感謝しています。ただ、もしあのときから vCard を気にかけていたら、もっと多くの車輪の再発明を防げたかもしれませんが。

== vCard における由来 ==
このセクションは ''参考情報'' です。

<div id="Semantic_XHTML_Design_Principles">[[hcard-design-methodology]] をご覧ください。</div>

=== 意味的に同等なもの ===
いくつかのプロパティにおいて、その意味を上手く表現できる HTML 要素が存在します。次に挙げるプロパティは、その例に書かれている (X)HTML で表現すべきです ({{should}})。

* vCard の <code>URL</code> は hCard にて <code><a class="url" href="...">...</a></code> と表します。このプロパティは、<code>class="vcard"</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="Photo of ..." /></code>、または <code><object class="photo" data="..." type="...">Photo of ...</object></code> となります。
* vCard の <code>UID</code> hCard において、特定の URL (または EMAIL) といった、別の意味に置き換えられます。

=== 出現回数が一回のプロパティ ===
[[hcard-ja#.E3.83.97.E3.83.AD.E3.83.91.E3.83.86.E3.82.A3.E3.81.AE.E5.87.BA.E7.8F.BE.E5.9B.9E.E6.95.B0|プロパティの出現回数]]は、vCard RFC2426 で定義されるプロパティを一つずつ調べ、そのセマンティクスから一つのみでなければならない ({{must}}) を導き出したものです。[[hcard-singular-properties]] に解説があるので、そちらをご覧ください。

==== 単数化されたプロパティ ====
いくつかの複数系のプロパティ名が単数名化されています。このため、もし元となる複数形のプロパティが、複数のコンポーネントからなるひとつの値を取るものであっても、それらのコンポーネントは、単数名化されたプロパティを複数持つものとなります。

== 関連ページ ==
{{hcard-related-pages}}

[[Category:hCard]]

== 翻訳 ==
* [[hcard|english]]（英語）
* [[hcard-fr|français]]（フランス語）
* [[hcard-ru|Русский]]（ロシア語）