ブナの森の撮影だったのに、ブナの画像をアップしていなかったことに気が付きました。
鎌池で見つけた芽吹いたばかりのブナの若葉です。露出補正プラスかマイナスかで意見が分かれました。光を受けた若葉の輝きと若葉を覆う銀色の産毛を出したかったので、露出補正マイナスでの撮影です。
オオカメノキも名前で損をしていますが、この木もその仲間です。
名前は「タムシバ」、漢字変換では 田虫歯 となりました。
どこで区切って読めばよいのかわかりません。タームシバか、タムーシバか、タムシーバか。どこで区切っても、語感がよくありません。
別名は 「ニオイコブシ」、こちらの名前の方が奇麗です。花もコブシに似ています。山や傾斜地をこのんで咲いています。
下見の時には芽吹き始めだったブナの森も、すでに若葉の季節になっていました。
森のいたるところでオオカメノキの白い花が満開となっています。
この葉が亀の甲羅に似ているところからオオカメノキという名前がついたとか。くっきりとした葉脈と円形の形が印象的ですが、もう少し気の利いた名前はなかったのでしょうか？
オオカメノキの別名はムシカリ、葉っぱが虫に好まれるので付けられたようですが、これもパッとしません。秋には見事な紅葉で楽しませてくれる木なのですが、名前で損をしているようです。
キーワード出現率はSEOで有効か？
キーワード出現率とは、ページ中の全単語に占める特定の単語の比率のことだ。このキーワード出現率を適正に保つことが検索エンジン対策と重要である といわれている。はたしてそうだろうか？
Google検索結果の上位ランク10サイトのキーワード出現率
FC2 SEOがキーワード出現率チェッカーを提供してくれている。このツールを使って、あるキーワードの上位ページの出現率を調査してみよう。ついでにキーワード出現頻度＝回数も記録しておこう。ランキングは、2009年6月9日時点のもの
- 1位:http://ja.wikipedia.org/wiki/%E3%82%BF%E3%82%AA%E3%83%AB
- 61回、 7.14% (FC2 SEO)
- 76回、 2.90% (SEO 検索エンジン最適化)
- 2位:http://www.rakuten.ne.jp/gold/pukapuka/
- 49回、 9.76% (FC2 SEO)
- 83回、 6.78% (SEO 検索エンジン最適化)
- 3位:http://www.makasetaro.com/
- 90回、 9.7% (FC2 SEO)
- 189回、 8.93% (SEO 検索エンジン最適化)
- 4位:http://taorunomori.com/
- 54回、 9.31% (FC2 SEO)
- 123回、 9.12% (SEO 検索エンジン最適化)
- 5位:http://www.itohen.jp/
- 60回、 10.86% (FC2 SEO)
- 179回、 10.21% (SEO 検索エンジン最適化)
- 6位:http://tokubaihiroba.jp/ ★
- 12回、 15.78% (FC2 SEO)
- 22回、 11.34% (SEO 検索エンジン最適化)
- 7位:http://www.stia.jp/
- 22回、 7.94% (FC2 SEO)
- 31回、 5.48% (SEO 検索エンジン最適化)
- 8位:http://imabaritowel.com/
- 1回、 10.00% (FC2 SEO)
- 11回、 8.46% (SEO 検索エンジン最適化)
- 9位:http://www.towel-kobou.com/
- 44回、 7.91% (FC2 SEO)
- 62回、 5.51% (SEO 検索エンジン最適化)
- 10位:http://www.ichihiro.co.jp/art/
- 8回、 4.21% (FC2 SEO)
- 13回、 4.74% (SEO 検索エンジン最適化)
FC2のキーワード出現率にはALT が含まれていない！
ここで疑問がでてきた。8位のページはHTMLを見ると10回はキーワードが使われている。大半が 画像のALT属性としてだ。FC2 SEOのキーワード出現率は ALT属性を除外して出現率を計算しているらしい。
ALＴ属性も計算の対象とする SEO 検索エンジン最適化 のキーワード出現率ツールで調査しなおしてみる。一覧の数値の上段がFC2 SEO、下段がSEO 検索エンジン最適化での算出値
Yahoo!(YST)上位ランク10サイトのキーワード出現率
- 1位:http://www.towels.jp/
- 37回、 17.28% (FC2 SEO)
- 57回、 14.36% (SEO 検索エンジン最適化)
- 2位:http://www.towels.co.jp/
- 42回、 16.4% (FC2 SEO)
- 75回、 16.09% (SEO 検索エンジン最適化)
- 3位:http://shaddy.jp/towel/
- 19回、 11.04% (FC2 SEO)
- 31回、 7.33% (SEO 検索エンジン最適化)
- 4位:www.e-kanno.com/
- 45回、 9.67% (FC2 SEO)
- 135回、 9.77% (SEO 検索エンジン最適化)
- 5位:http://www.taorunomori.com/ ★
- 54回、 9.31% (FC2 SEO)
- 123回、 9.12% (SEO 検索エンジン最適化)
- 6位:http://www.imabaritowel.net/
- 82回、 6.59% (FC2 SEO)
- 110回、 4.33% (SEO 検索エンジン最適化)
- 7位:http://www.kontex.jp/
- 41回、 8.57% (FC2 SEO)
- 58回、 5.24% (SEO 検索エンジン最適化)
- 8位:http://www.taoruya.com/
- 39回、 8.33% (FC2 SEO)
- 56回、 6.55% (SEO 検索エンジン最適化)
- 9位:http://www.toucher-home.com/ ★
- 35回、 8.23% (FC2 SEO)
- 65回、 7.36% (SEO 検索エンジン最適化)
- 10位:http://www.nagaimasa.jp/
- 22回、 10.42% (FC2 SEO)
- 41回、 9.93% (SEO 検索エンジン最適化)
さて、キーワード出現率はSEOに影響しているのか？
一概にキーワード出現率 何%がSEOで重要だ とは言い切れない結果になった。15%を超えても上位にランクインしているサイトもあれば、2%台で上位のサイトもある。
そもそも、キーワード出現率ツールによって、あるいはツールの設定によって、算出される出現率が大幅に異なってくる。巷で言われているキーワード出現率とは、テキストだけのことなのか？ 画像のALT属性までを含んだ率のことなのか？
Yahoo!トップダウンペナルティとキーワード出現率
Yahoo!のスパムサイト対策である トップダウンペナルティは、過剰なキーワードの出現に対する罰であるといわれている。Googleのトップ１０サイトのうちでもっともキーワード出現率の高い 6位のサイトに注目して、Yahoo!(YST)の順位を追ってみると・・・。
同じサイトが 38位にランクインしている。キーワード出現率は危険区域ともいえる 15.78%(FC2 SEO)、11.34%(SEO検索エンジン最適化)を記録しているが、トップダウンペナルティではないようだ。何より、Yahoo!(YST)の一位のサイトの出現率は17.28% / 14.36%だ。
この調査からは、Yahoo!トップダウンペナルティは必ずしもキーワード出現率が一定の値を超えた場合に適用されるわけではない という結果が導かれた。
調査した6位のサイトは出現率こそ高いものの、出現頻度は 12回(FC2 SEO)、 22回(SEO検索エンジン最適化)と少ない。出現率よりも、出現頻度や出現する場所、さらには文脈との関係が影響しているのではないか。
それにしても Google と Yahoo!(YST)の検索順位がこんなにも違っているとは！（両方でトップ１０にいるのは１サイトのみ）。ちなにみYahoo!(YST)のトップ10は、すべてYahoo!ビジネスエキスプレス登録サイトだ。
★印は各検索エンジンの検索結果先頭ページに表示されていたスポンサーサイト(スポンサーサイト自体はGoogle179社、Yahoo!39社)
相互リンクの疑問
Googleのページランク神話がまだ広く信じられていた頃、ページランクの向上に有効だということで一生懸命、相互リンクに励んだ人も多いだろう。
相互リンクが本当にページランクのアップに有効かどうか？は別なお話しとして、さらにページランクのアップがSEOで有効かどうか？も別なお話しとして、ここでは、相互リンクの相手が本当にリンクをはっていてくれているかどうか？ の疑問について調べてみよう。
相手からのリンクを調べる方法
これは結構たいへんだ。GoogleやYahoo!(YST)のlink:http://・・・・ でもリンク先は表示してくれるが、フィルターが掛けてあるので本当のリンクの有無はわからない。
相手先のサイトに行き、すべてのページのリンクをしらみつぶしに調べる・・・これは面倒だ。
被リンクの数を調査するツールがあった
相手からのリンク＝被リンクを調査してくれるツールがある。
SEO-SO 相互リンクチェックツールがそのツールだ。
自サイトのURL（別に自分のサイトでなくてもＯＫ）と自サイトのリンクページのURLを入力し、チェックをクリック。これだけで、リンクページのURLから相手先のサイトを調査して、自サイトへのリンクの有無とその数を表示してくれる。
相互リンク専門のツールではないので、片リンクならリンク数はゼロとなるが、相互リンクなら少なくとも 1つはリンクがなくてはならない。
相手もリンクしてくれているか？
さて、あなたの相互リンク先はリンクをはっていてくれていましたか？
この記事は、SEO-SO 相互リンクチェックツールの調査の正確性を保証するものではなく、ツールの正確性を検証したわけでもないことにご注意を。ツールを使用して調査した場合、相互リンク先がリンクしていても検知できないことも十分考えられます。
このサイトについて言えば、トップページのリンクにある 「SEO対策ディレクトリ型検索エンジン Su-Jine」へのリンクは、相手先リンクなしという調査結果だったが、相手先のサイトを確認したところ、「[コンサルティング] 中小企業診断士兼システムエンジニアの複眼ブログ - 中小企業診断士の経営視点とSEのシステム技術の両面からIT・システム開発・Web技術情報を提供 」というサイト紹介とリンクがあった。あまりツールを過信せず、概要の把握に使い、最終的には自分の目で確認するしかないということ。あくまで目安としてお使いください。
Google Ajax Feed API の復習
以前の記事 GoogleAjaxFeedAPI を自分で読んで実行したが、我ながらよくわからんところがあったので、もう一度この記事にはり付けてみた。
同じことをやっても面白くないので、記事タイトルと記事の終りに、記事URLへのリンクを入れた。
FC2ブログの場合、headにスクリプトを入れるとうまく動作しないようだ。この記事の中にスクリプトも書いている。変なRSSも出るが、これもFC2ブログの場合のみか。静的なHTMLにはりつけたサンプルでは正常に表示されている。
このところ、Hard Days Nights な日々が続き、更新も滞っていましたが、気分を変えて行きましょう。
ブナの芽吹きです。生まれたてのブナの葉は、光を浴びて銀色に光ります。
茶色の小さな冬芽の中に、こんな精緻な若葉が仕込まれているとは！
XHTMLの先頭に書くべきだといわれているXML宣言について、３回の連載記事としてW3CのXHTML Recommendation を確認してきました。
ところが 「XHTMLはHTMLをXMLの構文で再構築したもの」だと言われています。しかも記事で取り上げているのは XML宣言です。やはり、XMLのRecommendationも読んでおいたほうが良さそうです。
XMLのRecommendationは量も内容ももりだくさん
W3CのサイトでXMLのRecommendationが入手できる。Extensible Markup Language (XML) 1.0 (Fifth Edition) 第二版あたりを取り上げた情報もあるが、現在は第五版が最新版だ。
XMLのRecommendationはページ数も多い。さらにEBNFという記法で書かれている。すべてを読むのはたいへんだ。XMLに対する本格的な取り組みも必要だが、ここではXML宣言に関係する部分に限定して読んでみよう。
XML文書ではXML宣言が必要か？
膨大で難解な仕様を前に立ちすくんでいたが、「XMLドキュメントにXML宣言が必要か」という疑問に関しては、意外と簡単に答えは得られた。
2.8 Prolog and Document Type Declaration の章の冒頭に答えがある。
Definition: XML documents SHOULD begin with an XML declaration which specifies the version of XML being used.(W3C Recommedation XML)
簡潔な文だ。これならExciteに翻訳してもらわなくても理解できそうだ。
定義：XML文書は使用されているXMLのバージョンを特定したXML宣言で始めるSHOULD
ところが問題になるのは SHOULD だ。わざわざ大文字で書かれている。辞書検索では、「should 《義務》〜すべきである、〜べきだ、〜しなくてはならない(Goo辞書)」 と説明されている。同じような意味を持つ単語に must もある。 「must 〜しなければならない、〜する必要 がある(Goo辞書)」
MUST と SHOULD どう違うのか？
W3C Recommendationは用語の使い方にも気を配っている
実はこの must,shouldなどについては W3Cと同様にインターネット上の標準を定める組織 IETFのRFC(RequestForComments)で規定されている（IETFは、インターネットそのもののインフラとなる規定を中心に扱い、W3Cはその上で利用されるWWWに関連する規定を中心に扱っている ＠ITより）。Request for Comments: 2119 「Key words for use in RFCs to Indicate Requirement Levels」
XML Recommendation には、MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAYなどの用語は、RFC2119の表現に従って解釈すべきだと明記されている。
追記 やはり最新版を読まないと正確な話しはできない
W3C XML Recommedation 1998年2月10日 日本語訳を参照すると、1.2 定義で、MUST, MAYがW3C勧告の中で規定されていたようである。「MUST:適合する文書又はXMLプロセサは，記述されたとおりに動作することが要求され る。そうでなければ，エラーとする。」
同訳の参照の中に RFC2119 は含まれていない。さらに同訳では SHOULD は定義されていない。
ところが、最新版の第五版では、参照の中に RFC2119 が含まれ、1.2 Terminology から MUST,MAYの定義が削除され、RFC2119の説明に従うということが明記されている。(to be interpreted as described in [IETF RFC 2119].)
つまり、過去はいざ知らず、現在のW3C XML勧告では、RFC2119の用語定義に基づいて解釈することが求められている ということだ。やはり、最新版を読まなければ正確な判断はできない。
MUSTが絶対要求、SHOULDは・・・
翻訳にも疲れた。RFC2119の日本語訳を作成してくれた方がいるので、ここではありがたく参照させていただく。
- MUST
- この単語、もしくは用語 "REQUIRED" や "SHALL" は、定義が仕様書の絶対の要求であることを意味する
- SHOULD
- この単語、もしくは形容詞の "RECOMMENDED" は、特定の状況で、特定の item を無視するための有効な理由が存在するかもしれないが、完全な実装は異なった方針を選択する前に、理解され注意深くよく考えられなければならないことを意味する。
正しさのレベル
「HTML的に正しい」あるいは「W3Cの勧告通りなので正しい」などと言っているが、実は正しさにもレベルがある というわけだ。
MUSTとSHOULD、辞書的な意味ではどちらも 「・・・・すべき」だが、W3C Recommendation の中では厳密に使い分けられている。
MUST は絶対要求、これに反していると「正しい」ことにはならない。一方、SHOULDは「注意深くよく考えられなければならない」とされ、「実装は異なった方針を選択」することにも言及されている。
XML宣言の定義は SHOULD
このXML宣言の定義では SHOULD が使われている。絶対要求のMUSTではない。
SHOULDの説明文の中に、「無視するための有効な理由が存在するかもしれない」とあり、さらに「異なった選択をする」とある。つまり SHOULD が使われている場合、SHOULDの通りにしない という判断もありうるという意味だろう。
RFCに基づいてXML宣言の定義を再翻訳すると
「SHOULD とは、言っていることを理解し、背景をかんがえなくてはならないが、良く考えた結果としててW3Cの言っているとおりにしない場合もありうる」ということだ。
先ほどの我流翻訳にRFCの規定を反映させると、下のような定義になるのではないか。
定義：XML文書は使用されているXMLのバージョンを特定したXML宣言で始めた方が良いが、これに従わない有効な理由があれば、注意深く良く考えて異なる方針を選択しても良い。
SHOULD に従っていなければ「正しくない」のか
「XML文書は使用されているXMLのバージョンを特定したXML宣言で始めるSHOULD」という定義に従っていない文書、つまり、「XML宣言が先頭にない文書は正しいXML文書ではない」 と言えるのか？
MUSＴ に反すると「正しくない」、これはたいていの人が一致する見解だろう。絶対要求を守っていないのだから。ではSHOULDの通りにしなかった場合は？ やはり 「正しくない」 のだろうか？
XHTMLの先頭に書くべきだといわれているXML宣言について、W3C Recommendation を確認しています。今回は、そのPart3、XHTMLに関する最終回です。
W3Cのサイトでは XHTML10-2のURLは http://www.w3.org/TR/2002/REC-xhtml1-20020801/ ですが、 Latest version http://www.w3.org/TR/xhtml1 をクリックとしても XHTML10-2 のページを開きます。一方、XHTML10-1 は、Previous version に位置づけられ、URLも http://www.w3.org/TR/2000/REC-xhtml1-20000126/ です。
このことからも XHTML10-1は古い仕様であり、現在準拠すべき仕様は XHTML10-2 である ということが分かります。
W3C XHTML10-2改訂版には補足があった
XHTML1.0 の改訂版である XHTML10-2 には encodingに関するAppendix 「C.1. Processing Instructions and the XML Declaration（処理命令とXML宣言）」が追加されていた。
例によって、前半部から引用＆Exceite翻訳してみよう。
Be aware that processing instructions are rendered on some user agents. Also, some user agents interpret the XML declaration to mean that the document is unrecognized XML rather than HTML, and therefore may not render the document as expected. For compatibility with these types of legacy browsers, you may want to avoid using processing instructions and XML declarations.
W3C Recommendation XHTML10-2より
処理命令が何人かのユーザエージェントの上に表されるのを意識してください。 また、何人かのユーザエージェントは、HTMLよりむしろドキュメントが認識されていないXMLであることを意味するXML宣言を解釈して、したがって、予想されるようにドキュメントを表さないかもしれません。 これらのタイプのレガシーブラウザとの互換性のために、あなたは、処理命令とXML宣言を使用するのを避けたがっているかもしれません。
Excite翻訳結果
「予想されるようにドキュメントを表さないかもしれません。」
W3Cのおっしゃる通り、勝手な解釈で予想外の結果を表示してしまうユーザエージェント、つまりブラウザがあるのです。そして、これまたW3Cのおっしゃる通り、勝手な解釈をするブラウザのために振り回されるのを避けたいのです。
Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.
W3C Recommendation XHTML10-2より
しかしながら、XML宣言がドキュメントに含まれていないときだけ、ドキュメントがデフォルト文字符号化UTF-8かUTF-16を使用できるのを覚えてください。
Excite翻訳結果
しかしながら、XML宣言が文書に含まれていない時には、その文書はデフォルト文字符号化であるUTF-8かUTF-16だけが使用できることを忘れないこと ・・・こんな意味でしょうか？しかしながらと力んでいますが、本文で述べたことの繰り返しです。
XHTML改訂仕様にはさらに続きがあった
⇒
W3C Recommendationを読んでみると・・・Part3 XHTML最終回の続きを読む
信州の桜は足早に通り過ぎていきました。
夜桜の画像でお別れとします。
