FC2ブログ

浅葱さんのブログ

ええ、以前はぷらしのすとか言っていましたよ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

メモ

あまり信頼できないソースから OAI-PMH でハーベスティングしたメタデータストリームに対して検索サービスを作りたい。

信頼できない、とは、たとえば内容が違うのに <fileIdentifier> が重複するものが大量に出てくるとか、同じ内容で id が異なるものが怒涛のように出てくるとか、とんちんかんな内容のものがどんどこ混入するといった事故を想定している。そういうことは自分もやるし備えも必要だ。

すると、OAI-PMH の結果を直接貯蔵する DB とは別に検索用の DB は別にもったほうがいい。 パターンマッチに基づくパッチあて操作なんかを挟み込むことができる。

OAI-PMH のプロバイダもやる必要があるが、contact 以外の人物が勝手にパッチをあてたレコードを第三者提供すると責任問題になるので、一次DBから直送すればよい。一次DBはスイッチに近い性格となるから、ストレージ管理としては容量指定で古いものから消していかなければならないだろう。あまり難しい判断をさせるべきではない。

どうせ検索のバージョンアップ時に DB 再構築とかするけど、そのときは OAI の DB から平行に別マシンが吸い上げつつ DB 再構築をやって、完成したら旧サーバとさしかえてしまえばよいからハッピーだ。

ところが困ったことに、古いレコードも更新されなければずっと生き続けるということがある。それでは一次DBから直近のレコードだけなめても生きているレコードセット全体を再現できないということになるので、OAIの受信ストリームは別に抜き出して、テラバイトディスクか何か安いところにぶちこんでおくしかないだろう。あるいは一次DBでエキスパイヤをやめてしまえばこの区別も不要となる。

当面はそのほうがいいかな。いずれは必要なレコードだけ取捨して再コンパイルする長期保存DBを作るんだろうけど。

二次DBの保存形式は、いかようでもよいが、オリジナル形式での出力を求められるとなると、おのずとオリジナル未改変版が必要になってしまう。そうすると実は二次DBが長期保存ということになってしまう。

いやそれは目が粗い。インデックスはどのみち必要なのだから、適宜消化吸収されたレコードとオリジナルの未改変バイト列の対がレコードの実態である。で、未改変のほうがアーカイブというところにあって、消化されたほうが別のところにあって必要なときだけアーカイブを参照するということになる。結局三角形の絵はかわらない。

スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://prasinos.blog2.fc2.com/tb.php/731-78a47c96
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。