「ほっ」と。キャンペーン

カテゴリ:SuperOPAC開発日記( 16 )

多種類情報資源相互参照システム2016

最近、とつぜんふってわいたかのように『グラフデータベース』にハマってます。
これは、たぶん…丸山自身が1999年あたりから取り組んでいたことを、いとも簡単にあっさりと実現させてくれる可能性をもったデータベースだと確信すらしています。
僕がいま注目しているグラフデータベースは、こちら。


これを少しさわりながら、データ入力の効率化に、これまでに作ってきた「多種類情報資源相互参照システム」が使えないかなぁ〜と思ったところ、なんと! これまでのシステムを根本的にバージョンアップさせるアイデアがグラフデータベースからもたらされました。
正直なところ、2016年になって「多種類情報資源相互参照システム」をバージョンアップさせることになろうとは、感動するほどのおどろきでした。

ということで、このブログはその感動を少しでもわかっていただければ…と、思って書き始めていますが、できるだけ簡易な言葉でかきますので、どうぞお付き合いいただければ、幸いです。

【第1世代多種類情報資源相互参照システム】
a0001068_22325667.jpeg
まずは一般的な、多対多のデータベースを考えます。
一般的なリレーショナルデータベースは、簡単にいえばエクセルの表のようなものです。A,B,Cとならぶ列の方向に、人物データベース(テーブル)ならば、整理番号(ID番号)、名前、ふりがな、性別、生年月日などの項目をつくり、1行方向に一人目、二人目、三人目…と、レコードを追加していきます。この人物テーブルとは別に団体テーブルを作ります。団体番号、名称、代表者、住所、などなど。
そして、この人物テーブルと団体テーブルという種類の異なるテーブルを関連付けます。一人の個人が複数の団体に関係性をもち、ひとつの団体が複数の人物と関係性を持つので、ここでは[多対多]の関連付けが必要となります。その際には、両方の関係性を記述するための関連付けのテーブルが必要です。関連付けテーブルには、人物ID、団体ID、関係性という項目を用意します。人物テーブルの人物IDと関連付けテーブルの人物IDをつなぎ、団体テーブルの団体IDと関連付けテーブルの団体IDを関連付けます。これにより人物と団体とが[多対多]の関連づけを持つシステムをつくることができます。
しかしこれには、とても大きな問題がありました。人物と団体だけでなく、場所や出来事、その他のアイテムを相互に関連づけるとなると、それぞれに[関連付けテーブル]を用意しなければなりません。しかもその多対多の関連付けテーブルは、2つの種類なら1つ、5つの種類なら6つ、6つの種類なら10こという具合に、多種類になればなるほど、その関連付けテーブルが増えてしまうのです。
これでは、ちょっとした変更に対してもとても大きな負担が発生します。
関連付けひとつとっても、固定化された関係性よりも、関係性にも始まりと終わりがあったり、様々な関係性の属性が生まれることもあります。そうした変更に対応するには、このシステムでは膨大な手数がかかってしまいます。


そこで、次に考えたのがこちら。
【第2世代の多種類情報資源相互参照システム】
a0001068_22332055.jpeg
最初の多種類情報資源相互参照システムは、まずは多種類の情報資源の共通部分を抜き出して、ユニティテーブルを用意します。このユニティテーブルは、情報の種類(タイプ)によって、それぞれ人物テーブル、団体テーブル、場所テーブル、出来事テーブルなど個別の項目を用意したテーブルを1対1で関連づけます。
これにより、ユニティは種類によって多種類の情報を扱うことができるようになり、新しい情報資源の種類が増えても、このユニティテーブルと新しい情報資源のテーブルとを1対1で繋げばよいだけになります。
関連付けも、1つのユニティテーブルをA、関連するBにもユニティテーブルを接続することで、相互参照する基本的な仕組みは1つの関連付けテーブルで実現できます。
これならば、関連付けテーブルに後から属性を追加するのも簡単になり、メンテナンスの手間が大幅に削減できます。
FileMaker Proで実現する場合は、情報の種類(タイプ)によって表示するレイアウトを変更することで、それぞれの種類の項目のみを表示させることができます。
欠点としては、それぞれの情報種類のID番号に重複が生まれてしまうこともあり、レイアウト切り替えだけがたより…になるということがあります。(例えば、ひとつのユニティIDが、人物テーブルにも場所テーブルにも入力可能で、レイアウトの切り替えを間違えると、別の情報がリンクされてしまうことがあります)。

それでも、かなり有効に使えてきていて、このデータベース構造は実験用OPACに使っていたりします。

そして昨日、グラフデータベースを勉強している中で、なんとかデータ入力を効率化してやろうと思って、FileMaker Proを使ったシステムをつくろうとした瞬間に、それは起こったのでした!

【第3世代 多種類情報資源相互参照システム】
a0001068_23444288.jpeg

グラフデータベースが、ノード(点)とリレーション(線)でできているという特徴があり、Neo4jの場合は、それぞれのプロパティ(属性)も付与されています。
実はそれをそのまま、FileMaker Pro というRDBで表現すると、上記の図のようになるのです。

ノードテーブルには、ノードIDとラベル(第二世代でいうところのタイプ)があり、関連付けのリレーションテーブルにはノードA側ID、ノードB側のID、関連性があればOK!

正直なところ、「え!これでよかったのか。」という驚きです。

多種類情報資源は、ラベルの記述によって変更します。ここに、人物、団体、場所、出来事、アイテム…などなどの情報資源の種類を記入。
さらにそれらの各項目は、ノードとノードプロパティテーブルを1対1で接続し、いわゆる入力項目は、必要に応じて、Key(キー:項目)とValue(バリュー:値)で、必要な項目と必要な分だけ入力する…という形式にすることができます。これで、人物データベース用の項目、団体データベース用の項目等などを、あらかじめ用意する必要がなくなるのです。データベース的な言い方をすれば、あらかじめスキーマ(データベース構造)を決めなくてもいい!…という画期的な「多種類情報資源相互参照システム」ができあがるのです。パチパチパチ!
a0001068_23535557.jpeg
一昨日の早朝におもいつき、早速FileMaker Proで実装中。この基本構造に加え、作業効率化のための項目も付け加えながら、システムを構築中で、そのシステムによってNeo4jの入力作業の効率(入力用のテキストデータ作成)の手間が大幅に削減される見通。

で…ここで疑問???
FileMaker Proで実装できるなら、わざわざNeo4jを使わなくてもいいじゃないか?
そう。単純な検索ならば、それでもよいのですが、そこはグラフデータベースの強い[グラフ理論による検索]を必要としているからなのです。これはFileMekerや他のRDB(SQL)では不可能に近い。

ということで、この感動(?)を少しでも共有できれば幸いです。

また、4月以降「グラフデータベース勉強会」を小さいながらも始めてみたいなぁ〜と思っています。
興味・関心のある方は、ぜひ山中湖情報創造館のサイトをチェックしていてください。
では、また。

a0001068_00165269.jpeg
a0001068_00154777.jpeg


[PR]
by maruyama_takahiro | 2016-02-28 22:47 | SuperOPAC開発日記 | Comments(0)

本の索引から人工知能へ

ブログ記事を書くなどと、久しぶりのことではあるが、ここいら書きとめておかないと忘れてしまいそうなので、facebookに書くのも良いけれど、久しぶりにブログに書いてみたりする。

本の索引がなぜ、人工知能につながるのか…。
本を検索するための書誌データがあり、全文検索は技術的に可能だが権利的にムニャムニャ〜。でも権利的に問題なく、しかも人工知能社会に貢献…いや貢献どころか、人工知能を支える知識ベースは、図書館に存在していることに、気がついて欲しいと思うのだ。

本の索引
 図書館の仕事を初めて10年以上になる。最初は図書館業界でも有名な我らが理事長の元、門前の小僧もなんとやらで、図書館に対してはど素人でもそれなりに勉強しながらやってこれた。当初より僕は「図書館の本をバラバラに分解したい」と思っている、図書館業界にはあるまじき考え方の持ち主ではあったが、多分それは、今でも変わらない。物理的にバラすことができないならば、デジタル的にバラすことはできないか。バラしたのちに再構築できる技術はないだろうか?などと考えたものである。最初は図鑑や辞典などの項目ごとに解体できないだろうか? などと思っていたが、本には索引があるじゃないか!と改めて本のページを開くと、これがまたすごいことになっている。
 日本の書籍には「索引」が欠落している。
 諸外国のいわゆる洋書を紐解けば、児童向けの十数ページの本であっても1ページ程度のINDEXが付いている。またドキュメンタリーや伝記においては、INDEXの充実ぶりは目をみはるものがある。日本語に翻訳された書籍ではINDEXも翻訳されるものもあるが、必ずしもすべてではない。原書にはあったINDEXが、邦訳では削除されている事例も見受けられる。
 それほどまでに、日本語の書籍には「索引」が少ない。
 理由はいろいろあろうが、索引は著者が作るもの、いやいや編集部が作らなければ、そんな時間はないから外注に、おいおいそんなコストは出せないと出版社…と、まぁこんな感じで『日本の書籍には索引がない』状態が、今もなお続いている。逆に言えば、これは未開拓の地が広がっている…とも言える。まだまだ、開拓できる知的フロンティアが、図書館には存在している。

索引データベースを作る
 すでに索引の付いている本から、索引をデータベース化する。
 1冊の本に対して索引を作る…データベース的に言えば、本1冊を1レコードとしたデータベースに、索引フィールドを作成し、複数行の索引データを入力する方法もあるが、これでは次の応用ができない。
 書籍データベースに、索引フィールドを作るのではなく、書籍データベースとは別に、索引データベースを作り、リレーションを取る。リレーショナルを使うことで、何件になるわからない索引を1行1件で蓄積するデータベースを構築することができる。何をリレーションのキーにするかは見当が必要であるが、書籍データベースとは別に、索引データベースを構築することで、むしろ「総合的な索引データベース」を構築することができる。
同じ見出語の索引を持つ書籍には、何があるか。それぞれ何ページにその見出語が掲載されているか。複数の本にわたって総合索引データベースが構築出来れば、それだけでも図書館の使い勝手は大きく向上する。
 実のところ、今での「レファレンス辞典」という形で、図鑑や辞典などの見出語とその掲載文献をまとめたものはある。しかし、業界向けということもあり非常に高価なのだ。また、児童向けではないし、子供向けの図鑑は対象外である。
 この総合索引データベースを、図書館が自ら作るようになることで、図書館の使い勝手向上を図る余地は、とても大きいと思うのだ。

 総合索引データベースにおけるフィールドの基本構造は、
[索引ID]
[見出語(索引語)]
[見出語ふりがな]
[書籍ID]
[掲載ページ]
これに、若干利便性を高めるためのフィールドを幾つか付け加える感じ。

索引データベースから見出語を抽出
 総合索引データベースは、一件一件の索引情報を入力するものですが、この索引データベースで登場する[見出語(索引語)]を抽出する作業が必要である。
見出語データベースあるいは見出語マスターと言ってもいい。

見出語マスターの基本構造は、
[見出語ID]
[見出語]
[見出語(ふりがな)]
ど、同時に、総合索引データベースのフィールドに[見出語ID]を追加する必要がある。

見出語マスターは、索引語から抽出したものであるが、そこにはちょっとした落とし穴がある。[同意語]の問題だ。同意語という以前に、例えば人名表記(特に外国人)に関しては、実に様々ものが登場する。例えば、アインシュタイン。すでにテストケースで作っていても、これだけある。

アインシュタイン
アインシュタイン, アルバート
アインシュタイン、アルベルト
(アルベルト・)アインシュタイン

これらが同じ人物の名前であることを捉えなければならない。そこで、総合索引データベースと見出語マスターとを、多対多でリレーションする必要があり、そのためのデータベースを一つ間に入れる必要がある。
見出語リンク用データベース
[見出語ID]
[索引ID]
これを入れることで、一つの見出語に対して複数の書籍からの索引を関連付けるだけでなく、一つの索引レコードから、複数の見出語をリレーションすることが可能となる。

目録カードの時代で言えば、[アインシュタイン]と描かれている人物典拠カードに、[アインシュタイン,アルバート][アインシュタイン、アルベルト][(アイルベルト・)アインシュタイン]  をも見よ と書くところかもしれない。

さて、ここまでは従来の図書館情報学における資料組織論として取り扱える内容である。
まぁ、残念ながら現在の電子化された目録データベースでは、ここまで取り組んでいる事例は、知らない。もしあれば、不勉強な私にぜひ教えていただきたい。
ここからが、次のステップである。

見出語どうしの関連づけ
一つ一つの見出語を「情報」とするならば、その情報を別の情報を持って記述したものを「知識」としよう。するとこういうことを描くことができる。
 「見出語A」は「見出語B」の「なんとかである」。

例えば、
「ロボット學天則」は「西村真琴」が「作った」
「西村晃」は「西村真琴」の「息子(である)」ちなみに、息子にはさらに「次男」という属性もつく。
  → 自動的に、「西村真琴」は「西村晃」の「父(である)」

こんな関連づけを、見出語にいっぱいつけていく。そんなデータベース作りを考えている。
僕はこれを『多種類情報資源相互参照システム』として構築する事ができる。
AはBのxxである。という関連づけ。しかもその関連づけには様々な属性を付加する事もできる。
そしてこれは、後に(現在)において、『グラフ Graph 』という名前で呼ばれるようになり、Googleは「ナレッジ・グラフ」という名称を用いているようだ。

グラフとセマンティック
 数年前に Google 社が、ナレッジ・グラフ というものを開発した。また、Open Graph というプロトコルもある。

 ナレッジグラフ Wikipedia
 Open Graph protocol

Wikipediaの解説を見ただけではよくわからないところもあるが、要するに 情報は一人ではいられない。他の情報を関連性を持ちながら存在し、その関連性を結んでいけば、連結した先の知識も答えとして導き出すことができる。
例えば、一冊一冊の小説から、時代と場面と登場人物を関連付けながらグラフをつないでいけば、

 文献に見られる、大正時代に、東京御茶ノ水YMCA会館の前を、通った人のリスト(架空人物を含む)が欲しい。

といえば、直接の回答が存在していなくても、結びつきを辿りながら、そんなリストを作り出すことができたりする。
現在、Web技術の方面では、『セマンティックWeb』とか『Linked Data』、『トリプル』とか『SPARQL』と言ったキーワードによる分野で、そんなことが実現出来るWebの記述方法と検索方法が検討されているが、その技術を持って、対象をWebから既存の出版物…特に「図書館の蔵書」を対象にすることで、人類の叡智を結びつけるようなことができるのではないか。「本」というパッケージに囚われている叡智を解放することができるのではないだろうか…などということを考えていたりする。

・・・【追記】
 実はこの夏に、SoftBankの人型ロボット(ヒューマノイド)のPepperが、やってきた。彼の(一応少年の設定)プログラミングをしている中で、なるほど!そういう解決方法があるのか。という場面に遭遇した。
 このブログで言えば、「見出語」マスターの上位に「コンセプト」マスターを置くと、複数の見出語を一括りの概念で括ることができそうだ。そのあたり、もしかしたら図書館情報学で言うところの『件名表目標』が使えるかもしれない。

Pepperの開発環境である Choreographe における QiChat Script でいうと、上の「アインシュタイン」は、

concept:(einstein)[アインシュタイン Einstein "アルバート アインシュタイン" "アインシュタイン、アルベルト" "(アイルベルト・)アインシュタイン" "Albert Einstein" ]

とすることで、[]の中のどの表記(文字列)が来ても、全て einstein という言葉(変数)に対応します。

というわけで、この膨大な「索引データベース」を構築する/構築し続けることで、日本の人工知能は図書館の蔵書から叡智を得ていくのではないだろうか?
[PR]
by maruyama_takahiro | 2015-10-20 10:26 | SuperOPAC開発日記 | Comments(0)

叡智の銀河 基本構成

a0001068_0253023.jpg


1996年 山梨インデックス(株式会社アド井上にて)
1999年 須玉オープンミュージアム(NPO法人 文化資源活用協会にて)
2000年 八ヶ岳フロント(八ヶ岳情報文化研究所として)
2005年 SuperOPAC(山中湖情報創造館にて)
2008年 SuperDB fujiyama(だだ今、山中湖情報創造館内にて稼働中)

などと作っては壊ししてきましたが、これからは『叡智の銀河』として、これまでの集大成づくりに取り組みたいと思っています。その基本構成は、こんな感じ。

・多種類情報資源相互参照システムは、今でもSuperDB fujiyamaとして稼働しています。

・見出し語データベースは、とにかく見出し語だけのデータベースを作りたい(どこかにありませんか?)。

・組織化プラットフォームは、リチャード・ワーマンの組織化手法である
  ・50音順 A-Z順
  ・時間(年表〜カレンダー)
  ・空間(地図)
  ・カテゴリー(分類法)
  ・ヒエラルキー(連続量・階層)
 に組織化できるプラットフォームを作りたい。

・叡智の盛りつけ皿は、これまで組織化手法として捉えていた、グループ化(セット、コレクション化)、物語化(ストリー化)を、利用者自らが作ることができる[編集場 Editing Field]としてのシステムをつくりたい。作ることができるだけでなく、それも叡智の銀河のひとつのコンテンツとすることができる...などなど。

と、これだけできれば、かなりおもしろい『知識共有システム』あるいは『知識の持続的成長モデル システム』がつくれるんじゃないかなぁ...と、思っています。
これまでは、FileMakerでしたが、この秋からMySQL + PHPのOSS(オープンソースソフトウェア)としての開発に取り組めそうです。
[PR]
by maruyama_takahiro | 2008-09-02 00:20 | SuperOPAC開発日記 | Comments(0)

SuperDB 2008

当館の若手スタッフを中心に、いろいろなデータベースが構築されているが、いよいよそれを統合するというので、見せてもらった。

...残念ながら...の結果を見てしまったので、ここはひとつオジさんパワー(死語?)で、何を思ったか、血迷ったか...結局徹夜してシステムを組ませていただきました。

実際に使うためには、まだまだユーザーインターフェイスとか、使い勝手とか、あれやこれや手を入れないことには、日々の仕事に使えるものにはなりませんが、それでもデータベース構造、システムアーキテクチャー的には、ほぼ思った通りのものができたと思います。

考えてみてください。

 博物館や美術館、図書館という施設情報と
 著名人の情報と
 企業や団体の情報と
 新聞記事にクリッピングと
 地域のイベント情報と
 図書と
 その目次情報と

 それらがすべてひとつのシステムの中で、扱う事ができ、さらにすべての情報から一発で検索ができる(インデックスの作り方で、たぶんもうちょっと早くなる...はず)。そんなシステムなのです。

 ひとまず、SuperDB2008(仮名)としておきましょうか。

というわけで、このシステムを動かすためには、データベースの基本は知っておいて欲しいので、今日はちょっとばかり特別レッスンなど...

これのウェブ版ができたらなぁ....あの案件などいっぱつで解決(?)しちゃう...かもね。
[PR]
by maruyama_takahiro | 2008-07-22 00:07 | SuperOPAC開発日記 | Comments(0)

SuperOPAC2008

ふっと思いついて...SuperOPAC2008を作り始めてしまいました。
いわゆるサーキュレーション用というよりも、純粋に資料の検索用として作成してます。

図書も雑誌も視聴覚資料も、新聞のクリッピングも雑誌記事のクリッピングも、一切合切をひとつのデータベースシステムとして取り扱えるOPACです。

当面は、スタッフのスキルアップをねらいとして、山中湖情報創造館内にいったいどんな資料があるのかを、全体的に把握できる...そんなOPACなのです。

※基幹の図書館情報システムのデータベースと、ODBCでやり取りできれば...かなり楽になるんだけどなぁ....※

※それと、県内の図書館情報ネットで、検索キーワードをURLに埋め込めるようになれば...館内で見つからない資料を、ワンクリックで山梨県内の図書館資料を対象とした検索画面に切り替えられるのですが...※
[PR]
by maruyama_takahiro | 2008-04-23 23:28 | SuperOPAC開発日記 | Comments(0)

リンク用Scriptができた!

FileMakerを使って、「SuperOPAC」やら「叡智の銀河」を作っているのですが、さきほどやっと相互参照のリンク先を、クリックひとつで表示できるようになりました。パチパチパチ\(^o^)/

組んでみれば、たかただ3行のScript。
[関連するレコードを表示...]を、2段階ジャンプすることで、相手先の情報が表示されます。表示するときに、情報タイプをレイアウトで指定してあげれば、完璧!

すごく大きな一歩が踏み出せました。
アドバイスいただきましたみなさん、ありがとうございます。
[PR]
by maruyama_takahiro | 2006-12-19 02:17 | SuperOPAC開発日記 | Comments(1)

SuperOPAC: ちょっとだけ公開します。

研究用サイトですが、ちょっとだけ公開します。

SuperOPAC 研究サイト

※公開すると開発できなくなりますので、しばらくお休み...です※

【特徴】
1.多種類の情報を一元的に扱える
  (ニュースクリップやイベント、施設、団体、人物、書籍の串刺し検索が可能)
2.情報を相互に関連づけができる
  (「山中湖情報創造館」を検索してください。関連する情報に情報連鎖を与えることができます)
3.ついでに作った機能ですが、目次の表示もできます。
  (『ぼくは「つばめ」のデザイナー』を検索してください。)
4.イベントカレンダーの機能があります。

...そうそう...
OPACもランダムに検索してくれると、意外な本との出会いがあって、けっこうハマります。
[今日の四冊]は、そんな機能です。

【将来的には】
・書籍から関連する書籍(この本を読んだ方は、こんな本もおススメ...とか)
・イベントや施設などに関連する情報連鎖をつける

〈ノード〉と〈リンク〉でデータベースが構成されているのですが、[関連する情報]は単に関連する...というだけではなく、どんな関係性があるのか...を記述する必要があると思っています。

関係性の一例
 ・親⇄子
 ・作家⇄作品
とか、さらには関係性に[時間/期間]も関係している
 ・山中湖情報創造館⇄副館長(いつからいつまで)
とか。〈リンク〉にそんな属性をつけることが、大切になってくるように考えています。

【さらに究極の目標は...】
・カレンダーから派生して、歴史年表が作れるようにする
  (歴史の日付って、けっこう曖昧なので、それに対応するには〜〜〜)
[PR]
by maruyama_takahiro | 2006-03-16 08:19 | SuperOPAC開発日記 | Comments(2)

それでも、見出しの著作権は認められず!!

知財高裁の判決に関する報道の続きです。

Google ニュースによる関連記事 Google News.

要約すれば、
見出しの表現が著作物として保護されるための創作性はなく、著作権侵害にはあたらないが、法的保護の対象となるものである。
デジタルアライアンスの行為は、社会的に許容される限度を越えたものであり…損害賠償を命じた。

で...気になるのは、見出しの無断利用については、「社会的に許容される限度」もあるという文章にも読めます。
図書館が、地域の情報源として新聞や雑誌の記事を無償で紹介することは、「社会的に許容される限度」の範囲内になると...思うのだが、どうだろうか?
[PR]
by maruyama_takahiro | 2005-10-06 22:13 | SuperOPAC開発日記 | Comments(0)

【報道】『見出し無断使用、ネット会社に賠償命令…読売逆転勝訴』...って!

記事見出しに著作権はあるか/ないか....について
今日新たに出た判決のニュースです。

見出し無断使用、ネット会社に賠償命令…読売逆転勝訴 Yahoo! News /読売新聞

 原告である読売新聞の報道だけに、逆転勝訴が目立っていますが、賠償は命じたものの、使用差し止めは認めなかったようなので、判決の全文が知りたいところですね。

それでね。
例えば、この投稿のように、記事を紹介するのもダメって言われると...かなり厳しいなぁ。
[PR]
by maruyama_takahiro | 2005-10-06 20:00 | SuperOPAC開発日記 | Comments(0)

目次の著作権はあるの・ないの?

書名には著作権はありません。
僕が『坊ちゃん』とか『東京タワー』とか名付けた題名をつけて、著作/創作することには、何の問題もありません。

「新聞記事の見出し」に関しても、東京地裁では、「著作権はない」との判決も出ています。

そこで、目次には著作権があるか...と調べてみたのですが...
・目次に著作権を主張しているところもある
・「編集者の著作権」豊田きいち著では、
---以下引用---
目次の著作物政を要約すると、次のようになる。
1 書籍や学術雑誌、ミニコミ誌、あるいは社内報などの小冊子の目次のように、記事の掲載ページを素直に示したものは、独立の著作物とは言えないであろう。著作権が発生しない。
---------
とある。目次の著作権については裁判にもならず判例も出ていないので、なんとも言いがたいが、「新聞記事の見出し」同様に、書籍や雑誌などの見出しにも著作権は発生しないと言ってしまってもよいのではないだろうか。

仮に...新聞名とか雑誌名とかのタイトルを主張するのであれば、それは『商標』として登録すべきじゃないのかなぁ...と、思うのです。
[PR]
by maruyama_takahiro | 2005-10-02 15:31 | SuperOPAC開発日記 | Comments(0)