スポンサーサイト
日本の鉄道駅のよみがな
普通にATOKとかには入っていると思いますし
一般的に売っていたり配布している辞書には入っていると思うのですが
ウィキペディアのダンプから日本国内の鉄道駅と思われるものと、
そのよみがなを拾ってみました。
索引用にMeCabの辞書を作りなおそうかと考えているのですが
これはそのテストです。
可能な限り読みの間違い等ありましたら修正もする予定です。
ただ、なくなった駅をタイムリーに削除したりする予定はありません。
具体的には指定した名前のカテゴリを含むページを拾いだして
そのページのデータから読みを適当に抽出し、
で並べています。自動でとれなかったところは今回は手動で補いました。
適当なRegExでひろっているのでまだ精度が出ないのです。orz
この形式になっているのは、エディタなどで変換できればいいかなと。
とにかく項目名と読みの組み合わせが欲しかったのです。
全部駅名なので固有名詞です。
また、索引作成を目指しているので、形態素単位ではなく
「駅」まではいっています。
むしろかな漢字変換にいいのかもしれません。
ライセンスはGFDLです。
鉄道駅を選んだのは、比較的フォーマットが統一されていて
地名がたくさんあったからで、私自身は鉄道は基本的に守備範囲外なので
細かい違い等見落としまくっていると思います。
私的には単なるトライアルです。
以下196Kありますがpostできるのでしょうか。。
一般的に売っていたり配布している辞書には入っていると思うのですが
ウィキペディアのダンプから日本国内の鉄道駅と思われるものと、
そのよみがなを拾ってみました。
索引用にMeCabの辞書を作りなおそうかと考えているのですが
これはそのテストです。
可能な限り読みの間違い等ありましたら修正もする予定です。
ただ、なくなった駅をタイムリーに削除したりする予定はありません。
具体的には指定した名前のカテゴリを含むページを拾いだして
そのページのデータから読みを適当に抽出し、
漢字表記|よみ
で並べています。自動でとれなかったところは今回は手動で補いました。
適当なRegExでひろっているのでまだ精度が出ないのです。orz
この形式になっているのは、エディタなどで変換できればいいかなと。
とにかく項目名と読みの組み合わせが欲しかったのです。
全部駅名なので固有名詞です。
また、索引作成を目指しているので、形態素単位ではなく
「駅」まではいっています。
むしろかな漢字変換にいいのかもしれません。
ライセンスはGFDLです。
鉄道駅を選んだのは、比較的フォーマットが統一されていて
地名がたくさんあったからで、私自身は鉄道は基本的に守備範囲外なので
細かい違い等見落としまくっていると思います。
私的には単なるトライアルです。
以下196Kありますがpostできるのでしょうか。。
五十音順について
間に進めているネタが、処理が終わらなくて全然進まないので
先に日本語の50音について考えてみます。
50音順は意外と面倒くさいものです。
日本語で言う「辞書順」と数学的にいう「辞書順」が違うのもその原因の一つですし、
意識しないで辞書で触れて刷り込まれているのもその大きな理由だと思います。
最も現代っ子にとって辞書とは電子辞書を指すようなのでその限りではないかもしれませんが
慣れ親しんだ順列じゃないと気持ち悪いけど、
冷静に考えると自分がまともと思える順列をそらで言うのはなかなか難しいです。
[[五十音順]]にはこんな例がでています
Wikipedia [[五十音順]] 2008年12月6日 (土) 16:59 211.124.132.117
なんとなく私個人としてはした二つのルールはなじみが無い感じがします。
ワープロがでてきてからはそういう並びが増えたような気がしますが
ノートにはそれに関してコメントがありますね。※私が書いたものではありません。
あと50音順については[[Wikipedia‐ノート:ウィキプロジェクト 索引/配列順]]で
oxhopさんがとても興味深い調査をしてくださっています。
いずれにしても、仮名にしたものをそのまま信じて並べても五十音順にはならない、
ということです。
50音順のソートはExclelとかAccess、OracleのDBならできますが
細かいルールの設定とかは知る限り無いと思います。
もちろん理想は50音順には設定も何もなくてきっちり規格があることですけどね。
ブログではmySQL 3.23 あいうえお順にソートして表示したい
なんていうのはあるようですが
これだと長音(ー)や拗音の扱いがテキトーになってしまいます。
ただ、方針的にはこの方法で行くのが楽だと思います。
つまり
そのために、文字コード順に並べると
もとの読みが50音順になる文字列なり数字なりの変換を考えればいいわけです。
100万項目を超えても現実的な時間でソートするには
DBを使うなら数値、プログラムならバイナリでしょう。
途中結果を保存したり、結果を編集したりすることも視野に入れて
数値にしてみようと思います。
しかし、数値にしてもひらがなとカタカナ以外も残るので、
結局文字列が残ってしまいます。
そのため、途中保存用のDBは少しややこしいことに
だいたいのケースはこれで行けると思います。
先に日本語の50音について考えてみます。
50音順は意外と面倒くさいものです。
日本語で言う「辞書順」と数学的にいう「辞書順」が違うのもその原因の一つですし、
意識しないで辞書で触れて刷り込まれているのもその大きな理由だと思います。
最も現代っ子にとって辞書とは電子辞書を指すようなのでその限りではないかもしれませんが
慣れ親しんだ順列じゃないと気持ち悪いけど、
冷静に考えると自分がまともと思える順列をそらで言うのはなかなか難しいです。
[[五十音順]]にはこんな例がでています
* 濁音・半濁音は清音と同一視し、同一視した際に同じ語になる場合は、清音→濁音→半濁音の順とする。
(は→ば→ぱ→はあ→ばあ→ぱあ→ひ)
o 別の例:濁音・半濁音は、清音と別の文字として扱う。順序は、清音→濁音→半濁音の順とする。
(は→はん→ば→ばん→ぱ→ぱん→ひ)
* 長音は、直前の音の母音と同一視する。同一視した際に同じ語になる場合は、母音→長音の順とする。
(ああく→あーく→ああけ)
o 別の例:長音は無視する。無視した際に同じ語になる場合は、長音無し→長音ありの順とする。
(ああく→あく→あーく→あけ)
o 別の例:長音は独立した別の文字として、「ん」の次に置く。
(あわ→あん→あんわ→あー→あーん→い)
* 拗音・促音などの小さい字は、大きい字と同一視し、同一視した際に同じ語になる場合は、大きい字→小さい字の順とする。
(きや→きゃ→きやく→きゃく→きゆ)
* 「ヴ」は、「う」に濁点の扱いとする。
o 別の例:「ヴァ・ヴィ・ヴ・ヴェ・ヴォ」は「バ・ビ・ブ・ベ・ボ」と同一視する。
* 「わ」行の「ゐ」「ゑ」「を」はそれぞれ「あ」行の「い」「え」「お」と同一視する。同一視した際に同じ語になる場合は、「あ」行→「わ」行の順とする。
o 別の例:「ゐ」「ゑ」「を」を「わ」行として扱う。
Wikipedia [[五十音順]] 2008年12月6日 (土) 16:59 211.124.132.117
なんとなく私個人としてはした二つのルールはなじみが無い感じがします。
ワープロがでてきてからはそういう並びが増えたような気がしますが
ノートにはそれに関してコメントがありますね。※私が書いたものではありません。
あと50音順については[[Wikipedia‐ノート:ウィキプロジェクト 索引/配列順]]で
oxhopさんがとても興味深い調査をしてくださっています。
いずれにしても、仮名にしたものをそのまま信じて並べても五十音順にはならない、
ということです。
50音順のソートはExclelとかAccess、OracleのDBならできますが
細かいルールの設定とかは知る限り無いと思います。
もちろん理想は50音順には設定も何もなくてきっちり規格があることですけどね。
ブログではmySQL 3.23 あいうえお順にソートして表示したい
なんていうのはあるようですが
これだと長音(ー)や拗音の扱いがテキトーになってしまいます。
ただ、方針的にはこの方法で行くのが楽だと思います。
つまり
- 読みとは別に、ソート用の文字列を用意する
- ソート用の文字列をDBの機能を使ってソートする
そのために、文字コード順に並べると
もとの読みが50音順になる文字列なり数字なりの変換を考えればいいわけです。
100万項目を超えても現実的な時間でソートするには
DBを使うなら数値、プログラムならバイナリでしょう。
途中結果を保存したり、結果を編集したりすることも視野に入れて
数値にしてみようと思います。
しかし、数値にしてもひらがなとカタカナ以外も残るので、
結局文字列が残ってしまいます。
そのため、途中保存用のDBは少しややこしいことに
元々のタイトル text
MeCabで推定した読み text
読みのソート用文字列 int
記事に含まれる読みと思われる部分 text
文字列は部分か? int
タイトル内の分かち書きに当たる部分 text
記事に含まれるカテゴリ text
記事のサイズ int
page_is_redirect int
だいたいのケースはこれで行けると思います。
現状の索引の形式とよみがな
現在の索引はいろんな理由から結構複雑な形式になっています。
理由を議論したりしているところはあんまり参考にしていませんが[[利用者:Meltbeen/索引の分析#容量削減技術]]の3番がおそらく大きな理由だと考えています。
一番最近に追加された索引は[[Wikipedia:索引 わかは]]のようなのでちょっとこれを眺めてみます。
のっけから
こんなソースになっています。
はじめの[[わかば]]はカテゴリを読んで曖昧を付加すれば良いでしょう。
次に、同じ読みのものを次の段に並べています。
これは技術的には不可能ではありませんが、面倒です。
それはわかばの位置ではわかりにくいのですが、例えば
の若葉台検車区を見てください。
ここではたまたま「わかばだい」の読みで若葉台だけがあげられていますが
ほかにもわかばだいの表記があったらどうなるでしょうか。
よみがなと、漢字表記が対応づけできるのは漢字が読めるからです。
コンピューターは漢字を読めませんので、たとえば
ここから
のようなソースを生成するには、漢字表記のどこまでが「えいせい」なのかを知っている必要があります。
しかしWikipediaの記事の読みに漢字の区切りは入っていません。
記事名か、冒頭の表記が
の様に分かち書きされていない限りは
どこかで分かち書きをしてあげないと、できないのです。
つまり、現在の形の索引作成には、記事に書いた読みをそのまま利用できません。
完全に利用できないわけではありませんが
利用するにはかなりの手をかけないと無理と言えるでしょう。
そしてでてきたのが自動索引のたぐいで、
[[Wikipedia‐ノート:ウィキプロジェクト 索引]]で
TETRAさんによるもの、Suisuiさんによるもの、Tietewさんによるものへのリンクがあります。
いずれも形態素解析で分かち書きをし、索引の形に整形したもののように見えます。
とくにTietewさんによるものは当時の全ページを網羅し、
リダイレクトを処理し、
曖昧さ回避の表示もされています。(ほか二つは記事名のみ)
読みだけではなく名詞の判定をしてそれをもとにひとくくりにする作業もされています。
[[Wikipedia:ウィキプロジェクト 索引/MeCab索引]]に簡単ながら作業内容も記載されています。
これが現在動いていればこんなことをしようとは思わなかったでしょう。
カテゴリに当たる【】の中の再現はルールも一定ではないので
機械的には不可能と思われます。
ノートでどなたかがおっしゃっているカテゴリを入れる方法が現実的で便利に見えます。
記事の名前からそのジャンルを判別できるのは駅と大学と道路ぐらいしかありませんから。
カテゴリを入れる際には何らかのテーブルが必要と考えています。
入れないカテゴリのテーブル、とかね。
はじめはカテゴリをつけるつもりはありませんのでいまは飛ばしましょう。
次は順序について考えます。
理由を議論したりしているところはあんまり参考にしていませんが[[利用者:Meltbeen/索引の分析#容量削減技術]]の3番がおそらく大きな理由だと考えています。
一番最近に追加された索引は[[Wikipedia:索引 わかは]]のようなのでちょっとこれを眺めてみます。
のっけから
==わかは==
*[[わかば]]【曖昧】
**[[わかば (朝ドラ)]]
**[[わかば (護衛艦)]]
**[[わかば (タバコ)]]
**[[わかば (列車)]] ⇒[[修学旅行列車]]
*[[ワカバ]]【デュオ】
*[[若葉]](わかば)【曖昧】
**[[若葉 (埼玉県)]]
**[[若葉 (新宿区)]]【[[東京都]]】
**[[若葉 (つくば市)]]【[[茨城県]]】
**[[若葉 (初春型駆逐艦)]]
こんなソースになっています。
はじめの[[わかば]]はカテゴリを読んで曖昧を付加すれば良いでしょう。
次に、同じ読みのものを次の段に並べています。
これは技術的には不可能ではありませんが、面倒です。
それはわかばの位置ではわかりにくいのですが、例えば
==わかはた==
*[[若葉台]](わかばだい)【曖昧】
**[[若葉台 (稲城市)]]
**[[若葉台 (流山市)]]
**[[若葉台駅]](=えき)【[[京王相模原線]]】
**[[若葉台検車区]](=けんしゃく)【[[京王電鉄]]】
**[[若葉台CATV]](=しーえーてぃーびー)
*[[若葉トリオ]](わかば-)【芸人】
の若葉台検車区を見てください。
ここではたまたま「わかばだい」の読みで若葉台だけがあげられていますが
ほかにもわかばだいの表記があったらどうなるでしょうか。
よみがなと、漢字表記が対応づけできるのは漢字が読めるからです。
コンピューターは漢字を読めませんので、たとえば
衛星放送(えいせいほうそう)
ここから
* [衛星]]
**[[衛星放送]]( - ほうそう)
のようなソースを生成するには、漢字表記のどこまでが「えいせい」なのかを知っている必要があります。
しかしWikipediaの記事の読みに漢字の区切りは入っていません。
記事名か、冒頭の表記が
'''衛星-放送'''(えいせい-ほうそう)
の様に分かち書きされていない限りは
どこかで分かち書きをしてあげないと、できないのです。
つまり、現在の形の索引作成には、記事に書いた読みをそのまま利用できません。
完全に利用できないわけではありませんが
利用するにはかなりの手をかけないと無理と言えるでしょう。
そしてでてきたのが自動索引のたぐいで、
[[Wikipedia‐ノート:ウィキプロジェクト 索引]]で
TETRAさんによるもの、Suisuiさんによるもの、Tietewさんによるものへのリンクがあります。
いずれも形態素解析で分かち書きをし、索引の形に整形したもののように見えます。
とくにTietewさんによるものは当時の全ページを網羅し、
リダイレクトを処理し、
曖昧さ回避の表示もされています。(ほか二つは記事名のみ)
読みだけではなく名詞の判定をしてそれをもとにひとくくりにする作業もされています。
[[Wikipedia:ウィキプロジェクト 索引/MeCab索引]]に簡単ながら作業内容も記載されています。
これが現在動いていればこんなことをしようとは思わなかったでしょう。
カテゴリに当たる【】の中の再現はルールも一定ではないので
機械的には不可能と思われます。
ノートでどなたかがおっしゃっているカテゴリを入れる方法が現実的で便利に見えます。
記事の名前からそのジャンルを判別できるのは駅と大学と道路ぐらいしかありませんから。
カテゴリを入れる際には何らかのテーブルが必要と考えています。
入れないカテゴリのテーブル、とかね。
はじめはカテゴリをつけるつもりはありませんのでいまは飛ばしましょう。
次は順序について考えます。
Wikipediaの索引を自動化する
ここまでやってきて、短期的な目標は何かというと
Wikipedia日本語版の索引作成を自動化する、と言うものです。
Wikipedia:索引には恐るべき数の項目が列挙されています。
まず現状を調べてみましょう。
Wikipedia:索引 で始まるページ名からリンクされている標準名前空間のページを集めて、ダブりをはじいてカウントしてみると、
28万ページほどあるようです。
このためにpagelinksテーブルをimportするのに丸一日、
このクエリの発行に6時間半もかかりました。
あーしんど。
SQLは適当です。
索引がはじめにDBから抜き出して投稿されたのが2003年11月28日。この頃の記事数は1万5000ぐらいと思われるので、凄まじい増殖を遂げています。
一方で現状の記事数は57万程度。
索引にはリダイレクトも含まれているのでnamespace=0にあるページをカウントすると
これが全部索引にのるわけではないんですが(白紙化ページやゴミもあるため)
割合的に約1/3弱(74/28≒2.6)の網羅ということになります。
リダイレクト以外の記事は
このくらいです。もちろんこれには曖昧さ回避や一覧も含みます。
Wikipedia名前空間は含みません。
索引手動作成はすごいけど、追加速度は記事の増加ペースよりも遅く、
今後も追いつくことはなさそうだなぁ。
ということを言いたかっただけです。
次に続きます。。。
Wikipedia日本語版の索引作成を自動化する、と言うものです。
Wikipedia:索引には恐るべき数の項目が列挙されています。
まず現状を調べてみましょう。
Wikipedia:索引 で始まるページ名からリンクされている標準名前空間のページを集めて、ダブりをはじいてカウントしてみると、
mysql> select count(DISTINCT aa.page_id) from page aa, page bb, pagelinks where aa.page_title=pl_title and pl_from=bb.page_id and aa.page_namespace=0 and aa.page_is_redirect=0 and bb.page_namespace=4 and bb.page_title like '索引%';
+----------------------------+
| count(DISTINCT aa.page_id) |
+----------------------------+
| 289046 |
+----------------------------+
1 row in set (6 hours 24 min 25.29 sec)
28万ページほどあるようです。
このためにpagelinksテーブルをimportするのに丸一日、
このクエリの発行に6時間半もかかりました。
あーしんど。
SQLは適当です。
索引がはじめにDBから抜き出して投稿されたのが2003年11月28日。この頃の記事数は1万5000ぐらいと思われるので、凄まじい増殖を遂げています。
一方で現状の記事数は57万程度。
索引にはリダイレクトも含まれているのでnamespace=0にあるページをカウントすると
mysql> select count(page_id) from page where page_namespace =0;
+----------------+
| count(page_id) |
+----------------+
| 747841 |
+----------------+
1 row in set (36.22 sec)
これが全部索引にのるわけではないんですが(白紙化ページやゴミもあるため)
割合的に約1/3弱(74/28≒2.6)の網羅ということになります。
リダイレクト以外の記事は
mysql> select count(page_id) from page where page_namespace =0 and page_is_redirect = 0;
+----------------+
| count(page_id) |
+----------------+
| 476460 |
+----------------+
1 row in set (37.26 sec)
このくらいです。もちろんこれには曖昧さ回避や一覧も含みます。
Wikipedia名前空間は含みません。
索引手動作成はすごいけど、追加速度は記事の増加ペースよりも遅く、
今後も追いつくことはなさそうだなぁ。
ということを言いたかっただけです。
次に続きます。。。




