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

タグ:叡智の銀河 ( 12 ) タグの人気記事

本の索引から人工知能へ

ブログ記事を書くなどと、久しぶりのことではあるが、ここいら書きとめておかないと忘れてしまいそうなので、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)

知のエコシステム Knownledge Ecosystem (手続きコピペ&感謝の還元:例001)

example001

例えば、こんな図を描いてみました。
FCP: formalities copy & paste 手続きコピー&ペーストに対応したサイトやアプリ、プラグインなどを経由したデータは、必ず[権利の所在][還元方法]に関する属性データを保持しなければなりません。
また、この規格に対応したワープロやDTPソフトなどは、編集中はもちろんのこと、編集後に電子書籍フォーマットに書き出す際にも、この属性情報を保持していることが必要です。それによって電子書籍が正しい参照や引用を行っていることを証明することになり、販売(二次利用の販売)が可能になります。

また、その電子書籍が購入された場合には、その代金の一部が[感謝の還元情報]に基づき、もとの権利者に還元される仕組みです。

これによって、[正しい手続きのもとで著作物が二次利用され、元の権利者にも還元される]という仕組みが生まれます。

また、電子書籍からは[何を参照したか、引用したか、二次利用したか]などの情報を常に見ることができるとともに、引用元からは、この著作物が[どのようなコンテンツで利用されたのか]を把握することができます。いわばブログのトラックバックのようなものです。
[PR]
by maruyama_takahiro | 2010-07-13 01:54 | 日々是電網 | Comments(4)

知のエコシステム Knownledge Ecosystem (手続きコピペ&感謝の還元)

知のエコシステム

(画面をクリックして、拡大表示でご覧下さい)
[PR]
by maruyama_takahiro | 2010-07-04 19:16 | 日々是電網 | Comments(0)

知のエコシステム Knownledge Ecosystem (その4、5)

Knownledge Ecosystem

ひとまずこの連載は、5つのパートで出来てます。
今回はOUTPUTとCONTROL

OUTPUT:出力
 他者のコンテンツを引用も含めた二次利用しつつ、EDIT:編集によって作成された[私のコンテンツ]は、自家消費しているうちは、まぁ多少データにつじつまがあわないところがあっても許されますが、これを、MARKET:市場に出して、配布するとなると有料・無料を問わず、データに整合性がなければなりません。ここは「知のエコシステム」が成立する上で重要なこと。

 私の作ったコンテンツは、他のこのようなコンテンツを二次利用しています。

が崩れていては、配布も販売もできません。ということで、OUTPUT:出力に必要な要因としては

・二次利用情報が成立しているかの確認
 (もし、編集途中で二次利用情報が崩れてしまった場合は、[再手続き]処理によって、もう一度引用元を洗い出しながら、正しい手続きである[二次利用情報]を、コンテンツに埋め込む作業を行う。

・配布用フォーマットにエキスポート
 再配布のためのフォーマットが、Kindle用なのか、ePUBなのか、PDFなのか、WORDや他のフォーマットなのか…等々によって、出力させる。

・MARKET:市場に[出荷]する。

食の市場をみればわかることだが、農家がいきなり市場に持っていくこともあれば、[農協]のような団体を通じて出荷することもある。また加工食品メーカーなどの法人も市場に出荷する。電子書籍時代においては、出版社はたぶんそんな位置づけになる。個人が電子書籍を出荷してもいいだろうし、出版社を通して出荷してもいい。

そして、購読者がそのタイトルに対して、無料ならそのまま。有料ならば対価を払って、コンテンツを購読し…それが、INPUT:入力として大きな「知のエコシステム」の循環が出来上がる。

ワンポイント
「知のエコシステム」においては、二次利用元に対する 1)権利の所在属性と、2)ライセンス課金属性が含まれる。これにより[自著]がいくばくかの金額で売れた場合、そこで使用した二次利用著作物のライセンス課金情報によって、二次利用した権利者のもとに[感謝の還元]が行われることとなる。
 ひとつの著作物が、二次利用として使われれば使われるほどその著作者に、ちゃんとただしくお金がめぐってくる。そんな感じだ。
 権利の所在情報やライセンス課金情報は、かなり個人の要望を反映した、様々なカタチを実現できるものである必要があると思うが、それでも、こうした[手続きコピペ]と[感謝の還元]が組み込まれることで、『知のエコシステム』は、大手のメディア企業だけでなく、市井のアマチュア個人であっても、そのエコシステムの循環の中で、自分の「知」を貢献させることができる。

 最初に、「食」の流通と似ていると書いたが、もう一方で エコシステムという名称のとおり、生態系と生物多様性のありかた…「命」の多様性と循環とも似ている。一部の巨大生物だけが生き残るのではなく、むしろ変化に対応した大小様々な生物=「知のカタチ」が棲息し、そこでこの『知のエコシステム』が持続可能な社会を作り上げていくのではないだろうか。


そして、最後の
Control:制御
 これは[私]という存在。私という存在からみれば、常に自分を中心に(?)この『知のエコシステム』は回っている。

 ・正しい手続きの元手のコピー&ペースト(二次利用)
 ・感謝の還元

 これは何も、ひとつの閉じた生態系である必要はない。一部には[権利管理団体]を作る必要がある…みたいな議論もあるようだが、そこはちょっと違う。様々なプラットフォームがあり、様々な課金システムが存在してよいと思う。ただし共通API仕様に基づくシステムである必要がある。

というわけで、とても大雑把ではあるが、『知のエコシステム Knownledge Ecosysytem』の循環は、同じ平面をぐるぐると回っているのではなく、回る毎に螺旋状に上昇していくイメージがある。それは「人類の叡智」がいっぽいっぽさらなる高みを目指していく…そういう姿の反映なのだ。

(ひとまず、ここまで)
[PR]
by maruyama_takahiro | 2010-07-04 09:56 | 日々是電網 | Comments(0)

知のエコシステム Knownledge Ecosystem (その3)

Knownledge Ecosystem

EDIT: 編集
 松岡正剛氏によれば、編集には64もの技法があるそうだが、それを全部把握するなどとても凡人の私にはできない。だが、調理に置き換えて考えれば、煮る・焼く・蒸す・ゆでる・炊くなど、家庭料理の基本があるように、編集にも基本があると思う。デジタル系/インターネット系における「知のエコシステム」において、EDIT:編集は、この調理の基本のようなものである。

 ・方針を決める
 ・洗う
 ・切る
 ・素材をまとめる
 ・火を通す
 ・味付けをする

 これらが、ほぼ同時に行われ、最後に

 ・盛りつける(これは少しOUTPUTにもかかる)

 知のエコシステムにおける EDITは、まるで調理なのだ。

洗う: INPUTで集めてきた素材を、文字通り洗い直してみる。それは正しそうか、必要だろうか、どのように調理しようか…等々を、事前に考えるのだ。

切る: クリッピング&スクラップと同様に、どの部分を使うのか、使いやすい様に項目でまとめることはできないか。コンテンツの形態として[文章(テキスト)][写真][イラスト][図版]…さらには[動画の一部分]や[音楽]といった素材もあるかもしれない。

素材をまとめる>:様々なメディアから切り抜いてきた素材を、テーマでまとめてみたり、別々のデータを組み合わせてみたり…単独のメディアに掲載されたいたコンテンツも、他のメディアに掲載されていた同じテーマのコンテンツと並べてみると、見えなかったことが見えてきたりする。

火を通す:素材をそのまま[引用]として使うもよし、あるいは自分で租借し自分の言葉で記述するもよし、煮るなる焼くなり、蒸すなり炊くなり…たぶんこのあたりには松岡式64手法などが適用できるのであろう。

味付け:そして大事なのは、ただ単に切り抜きを集めただけではなく、自分なりの味付けが必要なのだ。観察・仮説を立てる・データを揃える・実証してみせる…等々。様々なメディアに掲載されているコンテンツを集め、それらを調理する中からみえてくるもの。あるいは、最初に立てた方針の下に自分なりの料理になるように素材を編集する/調理すること。

盛りつけ:これはOUTPUTにもかかってくる事だが、調理した料理を器に盛りつけることも大事。知のエコシステムの中での盛りつけ方には、大きくわけて、1)平面メディアとしての紙面づくり(※紙面と書いてはいるがディスプレイ上で平面として見せるもの)、2)動画、3)音声などがあるように思う。

…と、まぁこんな風に、「知のエコシステム」では、EDIT:編集=調理と考えて、既存の様々な知から、自分なりの新しい知の創造(編集)を行う過程を考えることが大切なんだなぁ。

(このつづきは、また後日
[PR]
by maruyama_takahiro | 2010-07-04 00:15 | 日々是電網 | Comments(0)

「物語」の持つ[情報組織化力]を考えてみる

情報建築家であるリチャード・ワーマン氏によるLATCHに加え、

 ・個人の嗜好によるグループ化
 ・物語化

という2つの情報組織化手法を加えたいと常々考えている。

まずは、リチャード・ソール・ワーマン氏による情報の組織化手法とは
・場所 (Location)
・アルファベット (Alphabet)
・時間 (Time)
・分野 (Category)
・階層  (Hierarchy)※ 過去の著書では 連続量(Continuum)
略してLATCH(ラチ)というのだそうですが、これらはある意味で[機械的に]組織化できる手法です。僕が考えるに、これらの情報の組織化の一番の目的は、「探したい情報がどのあたりにあるのかの目安をつけるため」だと思っています。たぶん探している情報はだいたいこの辺にあるんじゃないかな…が、この5つの手法によって明確になってきます。

それに加えて、僕が2つ付け加えたのは、もっと[人為的][作為的][情緒的]な『情報組織化』なのです。これには僕の中では2つのアプローチから出てきました。

アプローチその1:多種類情報資源
 情報にはいろいろなタイプがあります。[人物][場所][出来事][物品]などなど。データベースを構築する際には、必ず一つのフィールド構造(項目:フィールドの組み合わせ)が必要になります。情報のタイプが異なるとこのフィールド構造が違うので同じデータベースファイルで扱うことができません。例えば、人物データベースには[生年月日フィールド]があっても、場所データベースには[生年月日フィールド]は不要…とか。なので違うタイプの情報を一つのデータベースで扱うことができないのです。さらにそれらの情報相互の[関係性]を記述できるデータベーウを構築使用とすると、情報の種類の数倍の関係性記述用データベースが必要となったり、大変でした。それをあるとき僕は「多種類情報資源相互参照システム」として作り上げることができました。これによって[人物]や[場所]、[出来事]、[物品]等々多種類の情報を扱うことができ、さらに相互の関係性を記述することも可能になったのです。
 そこまでできてはじめて気がつきました。
 「多種類の情報資源を相互に関連づけて記述する情報組織化の手法は、なんとも普通の『物語』じゃないか…」ってね。

アプローチその2:flickrのset / group 機能
 リチャード・ワーマンの情報組織化は、それぞれの情報のメタデータの記述があれば、半ば[機械的に]組織化できる手法です。が、そんな方法によらない、もっと人間的で、意図的で作為的で、個人の嗜好などによって自由に組み立てられる組織化法があるということを、僕はflickrのset機能で感じました。ただの好みなんです。これとこれとこれを…なんてset化できちゃう。個人の範囲では set 。さらに他の方の参加も受け入れる group などの有り様をみていると、人間の意志の介在によって構築される[情報組織化]手法もあるのではないか…と、気がついた訳です。

というわけで、
 ・物語化:多種類の情報資源を組織化する手法
 ・セット(グループ)化:当人の意図によって作為的にグルーピングする組織化

リチャード・ワーマン氏の5つに加え、マルヤマ式の2つで、僕の中での[情報組織化手法(論)]は、いちおう出来上がったのでありました。
[PR]
by maruyama_takahiro | 2009-09-21 08:03 | 日々是電網 | Comments(0)

OPAC vs 知識のWitch Pot

時間的にも距離的にも会場に行けない者としては、こちらのレポートは、本当に助かります。

 ・2009-05-12 かたつむりは電子図書館の夢をみるか

『もう、「本」や「図書館」はいらない!?』と題したトークセッション。語るは国立国会図書館館長の長尾真さんと、評論家/翻訳家である山形浩生さん。

 ・図書館は視えなくなるか? 
―データベースからアーキテクチャへ ―
d-labo Tokyo Midtown Tower

僕はこのブログでのレポートを読んだ限りではありますが、長尾館長にしろ山形さんにしろ大原則として「本」というかたまりを扱おうとしているのではないか...と、思えてしまうんです。SGMLなどの構造化も知識は[本というかたまりの中にある]という前提なんです。たぶん、将来/未来のOPACを考える上でも示唆的ではあると思うのですが、ここに図書館とOPACの限界を感じてしまいます。つまり...OPACでの検索結果は、印刷物であろうと電子出版であろうと「本」というかたまりを扱うということ。

それに対して、僕は根本的に異なるもののイメージを持っていたりします。たとえで言えば、僕のイメージは、「魔女の鍋 Witch Pot」なんです。「知識を煮込む魔女の鍋」そんなイメージ。図書館に対しても、OPACにはないもうひとつの(オルタナティブな)図書館情報システム。

簡単なたとえで言えば、図書館で扱う本のひとつひとつを《食材》のように捉えます。図書館は知識のスーパーマーケットみたいな感じ。大根や人参、魚やお肉などを扱っているようなものです。それに対して、《食材》を考えてみれば、お惣菜などの調理済みの食材を売っていたり、冷凍職員や加工食品を売っていたりします。今の図書館はひいき目にみても、そこまでなんです。ここでポイントなのが図書館は知識の食材屋さんであっても、知識のレストランではないです。だから調理されたものではなく、知の素材である「本」にこだわるんですね。

僕のイメージする「知識の魔女の鍋」では、「本」は野菜をカットするように切り刻みます。百科事典なら「見出し語」で切ったり、写真集や画集ならば一点一点の作品で切ってみたりとか...それらを「図書館」という大鍋に入れてぐつぐつと煮込む。もう「本」という原形すらとどめない状態まで煮込む。実際に本を切り刻む訳にはいきませんが、もし本当にやるとしたら、同じ本を『3冊』購入し、1冊は奇数ページ切り抜き用、1冊は偶数ページ切り抜き用、残りの1冊は切り刻むことなく排架用とします。奇数ページも偶数ページも見出し語単位で切り抜いた知識は「目録カード」のように50音順に引き出しに入れる...そんな感じ(見出し語の50音順や、件名、カテゴリー分類などいろいろな方法があるようにも思いますが)。

そんな風に「知識を煮込む魔女の鍋」の中でぐつぐつとした後は、知識のパスタサーバを使います。そのパスタサーバには調べたいことを書いて、鍋のなかでかき回すと....あ〜ら不思議。からまるスパゲッティのように、必要とする知識がずるずるずる〜っと引き上げられてくる。
これをお皿に盛りつければ、調べたいこと料理のできあがり。
もう本来の野菜のカタチ(いわば「本」)にはこだわりません。ビストロの料理のように知りたい知識がぞれぞれの素材からからまりあって目の前に出てくる感じです。

というわけで、OPACがどんなに進化したとしても検索結果を「本」とするのに対して、知識のWitchPotは「本」を知識単位でばらばらにしたものを再構築/再構成できる...そんな情報拠点であり情報システムをイメージしていたりするのです。
[PR]
by maruyama_takahiro | 2009-05-13 22:48 | 地域の情報拠点 | Comments(0)

地域を百科事典にする...図書館の一つの役割かもしれない

品川小学校の取り組みに、いたく感動している。

 ・品川小学校
 ページが表示されたら、「知の森へようこそ エンサイクロペディアスクールという提案」をクリックしてください。

 ある情報システムを使って、学校全体をひとつの「百科事典」化する取り組み。これはおもしろそうですね。

この発想は、図書館にも欲しいところです。

1.図書館内を「百科事典化」する。
 たぶん、今の書誌情報とOPACでは十分に対応できるとは思えないのだが、ひょっとしたら、かつての「目録カード」システムは、それを指向していたんじゃないかな...と、思われるふしがある。

2.地域を「百科事典化」する。
 これは図書館というよりも、「地域を支える情報拠点」として取り組まなければならないひとつの大きなテーマだと思う。
 ただ、残念ながら今の図書館には、蔵書を百科事典化する仕組みもないし、それを延長したかたちで、地域を百科事典化する仕組みも持っていない。

 地域の公共図書館は、1)郷土資料、2)地域資料、3)地域情報、4)地域コンテンツとするめるなかで、描くビジョンは「地域を百科事典化する」ことに向かう必要があるんじゃないかな...と、本当に強く強く感じているのです。
[PR]
by maruyama_takahiro | 2009-01-31 11:27 | 地域の情報拠点 | Comments(0)

「理想のOPAC」僕なりのビジョン

結論から言えば、僕にとっての理想のOPACは、

 Online Public Access Catalog for Knowledge (OPACK)

である。学のあるないにとらわれず(大学教授であろうと町中の商店主であろうと)、すべての人類(人々)が培ってきた全ての叡智をカタログ化し、それをオンラインでパブリックにアクセスできるもの。まずは、ここから始める、ここがスタートポイントである。

その上で、具体的にどんなものに叡智が詰まっているのか(本に記録されているのなら何と言う本なのか、映像に記録されているならなんというタイトルなのか、その叡智は博物館のような施設にあるのか、それとも誰か研究者の頭脳の中なのか...)そうしたことどもをカタログ化するのだ。
その上で、具体的なサービスを提供するには、どんな機能が必要なのか、どんな形状なのか、どんな項目なのか...等々を落とし込みながら、まぁ、最終的には目録カードのようなカタチになるのか、コンピュータの検索端末になるのか...は、ただの表現手段でしかない。

さて、図書館が本だけではない...といい始めているにも関わらず、OPAC=文献検索にとらわれてしまっていては...未来をつくる地域の情報拠点たる図書館像には...なかなか届かない...かもしれないぞ。
[PR]
by maruyama_takahiro | 2009-01-18 23:14 | これからの図書館 | 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)