図書館情報学を学ぶ

はてなダイアリーで公開していたブログ「図書館情報学を学ぶ」のはてなブログ移行版です。

マイクロフィルムは誰に使われているのか

上の記事で「マイクロフィルムを知っている人はほとんどいない」という種の発言をしたところ、コメントやトラックバック等で多くの方に「誰でも知っている」「卒業研究で誰もが使う」というツッコミをいただきました。
思慮の浅い発言だと反省している一方で、では具体的にどのような分野でよく使われているのか、興味が湧いてきました。卒業研究で使うとは言っても、情報科学の分野で使われているとは想像し難いので、分野によって利用状況は違うのではないかと思うのです。
ということで、以下の質問を人力検索はてなに投稿してみました。

質問紙調査としてはダメダメだと思いますが、マイクロフィルムをよく使っている方は回答頂ければと思います。

ブログのタイプ

id:higepon氏がいかに自分の学習プロセスをきちんと記録しているかが分かる記事。
ブログは大きく分けて「主張系」と「日誌系」の2つに分かれます。前者は論文や雑誌記事と同様に、自分の考えを発表することで社会に影響を与えようとするために書くブログ。後者は日記のように自分の考えを整理するために書くブログ。id:higepon氏のブログは後者ですね。
自分のブログを振り返ってみると、あまり目的が定まってなくて「こうもり」状態になっているように思う。プロジェクト型ブックハンティングとか主張めいたことを書いているのだけど、目的としては「意見を他人にぶつける」ことではなく「自分の考えを整理する」ために書いている。
このあたりの混乱があって最近はブログが迷走気味になっているように感じる。
うまい考え方というか、取り組み方が無いものか。

DjangoでModelを変更したときに注意すること

Djangoネタ再び。Djangoチュートリアルを進めている人向けの記事です。やたら分かりにくい文章になってしまいました・・・・・・もっと技術的な話をするスキルを身につけないと。
下の記事に間違いなどあれば是非コメントください。

1

例えば、Django上でlibというアプリケーションを作成して、モデルを定義するとDjangoでは以下のようなコードでModelを定義します。

from django.db import models

class Person(models.Model)
   name = models.CharField(maxlength=200)

class Book(models.Model)
   title = models.CharField(maxlength=200)
   pub_date = models.DateTimeField('date published')
   author = models.ForeignKey(Person.name)

書誌情報を管理するデータベースを構築するとして、まず簡単に本に関するデータモデルBookと、著者などの人に関するデータモデルPersonを定義してみます。
Personにはnameという属性があり、ここには200文字以内で名前を入力することができます。
Bookにはtitle・pub_date・authorの3つの属性があり、それぞれ本のタイトル、出版年月日、著者名を表しています。このうち、authorはPersonと関連づけられています。例えばJohnという名前を持ったPersonが登録されていると、BookのauthorとしてJohnを選択することができます。
上のようにモデルを定義した上で、コマンドライン上で以下のコマンドを実行します。

python manage.py syncdb

すると、上で定義したモデルに対応したデータがSQL上で自動的に定義されます。つまり、SQL文を書かずともデータベースの構築を行うことができます。非常に便利ですね。

2

また、後で新たなModelを定義してsyncdbを実行しても、新しいModelに対応したテーブルを作成してくれます。以下のようなコードを書いたとします。

from django.db import models

class Person(models.Model)
   name = models.CharField(maxlength=200)

class Book(models.Model)
   title = models.CharField(maxlength=200)
   pub_date = models.DateTimeField('date published')
   author = models.ForeignKey(Person.name)

class Library(models.Model)
   name = models.CharField(maxlength=200)

上のコードには新たにLibraryというモデルが追加されています。この場合にsyncdbをすると、ちゃんとLibraryに対応したテーブルを作成してくれます。

2

ただし、以下のようなコードに修正すると、問題が発生します。

from django.db import models

class Person(models.Model)
   name = models.CharField(maxlength=200)

class Book(models.Model)
   title = models.CharField(maxlength=200)
   pub_date = models.DateTimeField('date published')
   author = models.ForeignKey(Person.name)
   library = models.ForeignKey(Library.name)

class Library(models.Model)
   name = models.CharField(maxlength=200)

Bookモデルに所蔵している図書館の情報を登録するために、Bookモデルにlibraryという属性を追加しています。今までの作業からすると、既にあるモデルを書き換えても、syncdbを実行すれば自動的にデータベース側も修正してくれると期待すると思います。
しかし、これを実行するとlibraryに対応したテーブルが無いというエラーが出ます。
実は、Djangoでは既に定義されたモデルを書き換えても自動的に修正してくれません。修正点は手動でSQLを書いて修正する必要があります。

3

Djangoチュートリアルを読むと、これは意図的なものだそうです。データベースの列を勝手に書き換えるなどの処理は、他のプログラムに影響を与えてしまうため、安易に自動処理をするとトラブルが起こりやすい。そのため、修正するときは手動で行って、影響が起こらないか確認しながら行って欲しい、という考えによるものだそうです。
つまり、「スタートは面倒見てやるけど、その後の処理は自分でちゃんとやれよ」ということですね。
上のようなモデルに対応したSQLは、次のように書きます。

ALTER TABLE lib_book ADD (
   library INT, FOREIGN KEY (lib_book.library) REFERENCES (lib_library.id)
); 

このSQLMySQLなどのデータベース管理システム上で実行すると、修正したモデルと対応をとることができ、エラーも起こらなくなります。

4

一見面倒くさい作業のような気もしますが、作業を通してデータベース上では実際にどのように定義されているのかが分かって大変ためになりました。Djangoの良いところは過保護になりすぎず、フレームワークの機能を利用しながら、基本的なスキルを習得しやすいような仕様になっている点ですね。自転車の練習をしている子どもの後ろで倒れないように支えてあげているのだけど、しばらくするとそっと手を離す父親みたいな感じがしますね。

Python+Djangoを学び始めました

卒業研究でWebベースのシステムを構築するにあたって、サーバーサイドのプログラミング言語をどれにするかで悩んでいたのですが、id:katz3さんに倣ってPythonとすることにしました。私の所属している研究室ではRubyPHPを選択する人が多いので物珍しい目で見られています。
フレームワークDjangoを選んだのですが、これが非常に使いやすいので少し紹介したいと思います。
Webフレームワークの多くはMVC(Model・View・Controller)という概念のもとに設計されています。Modelによって扱うデータを定義して、Viewによって取得したデータを表示するUIを作成し、Controllerによってユーザーがデータを入力・操作するUIを作成する、というのがMVCによるWebサービス構築の流れになります。プログラムの役割が適切に分割されている点は素晴らしいのですが、画面にプログラム結果を表示させるのにMVCすべてを定義する必要があるので、若干面倒に感じます。
Ruby On Railsは既にあるサンプルプログラムをコピー・修正して自分のサービスを構築するという方式でこの問題を解決しています。ただ、この場合プログラムの中身がブラックボックスになりがちで、自分でプログラムした実感が湧かないという問題があります。
Djangoでは、「Django Admin」というモデルを操作するインターフェースを備えた汎用的なアプリケーションが附属しており、Modelを定義するとすぐにAdminによってデータを追加したり表示させることができます。phpMyAdminをもっとWebサービス寄りにしたような感じですね。このAdminがあるので、データの定義をするだけでも、最低限のインターフェースを備えたシステムとして使用することが出来ます。なので、プログラムを自分で書きながら、サービスを構築している実感を得やすいという利点があると思います。
Ruby On Railsと比べると、Railsがすべて一旦作ってあげる方式なのに対して、DjangoはControllerやViewに行き着くまでの補助輪を付けてくれている方式であると言えます。
自分もまだModelの定義までしか勉強できていないのですが、自分の卒研日誌の記録システムを構築してAdmin上で利用しています。手作り感と達成感のバランスが良くて中々楽しく学習できています。
まだ自分の周囲では使われていないPython(+Django)ですが、これから学習しつつ、他の人々にアピールしていきたいなと思います。

関連書籍

Djangoについて解説した数少ない書籍。MVCの考えに沿って分かり易く解説されています。後半でブログツールをDjangoで作るチュートリアルがあります。

筑波大学附属図書館のPVがいつの間にか公開されてる

screenshot

今日ふとTulips*1を覗いたらサイドバーに見知らぬバナーが。クリックしてみたら上のページに飛ばされました。どうやら筑波大学付属図書館のPVらしいです。
内容は筑波大生の週七(しゅうな)の1週間の大学生活を紹介したもので、サークルやレポートなど様々な局面で大学図書館がフル活用されています。
つくば市の地図を所蔵していることや、サークルに関係あるような雑誌を所蔵していること、セミナー室を借りることができるなど、図書館を使わない大学生に向けてアピールしている姿勢が伺えます。
また、レファレンスサービスや相互貸借サービスなどの図書館サービスも紹介していてなかなか質の高いPVになっていました。
このPV、誰が作ったんだろうと思ったら、どうやらShizukuメンバーid:yhwhが編集に参加していた模様。

学生が図書館経営に参加するスタイルは非常に良いですね。こういう試みがもっと増えるといいのですが。

*1:筑波大学附属図書館のWebサイト

C.G.W.さんのSBMパスファインダー、無事稼働!

以前実現が危ぶまれていたG.C.W.さんのSBMパスファインダー計画ですが、障害を乗り越え遂にシステムが稼働したそうです!

G.C.Wさん、おめでとうございます。今後もシステムの稼働状況などをお聞かせください。*1
なお、以前書いたSBMパスファインダーのまとめ記事も更新いたしました。

*1:できれば実際に見せていただきたいという思いもありますw

松岡正剛氏が図書館を語る

ちょっと前の記事ですが、千夜千冊で有名な松岡正剛氏が『司書』という本を紹介し、同時に司書の歴史についても少し解説されています。

日本ではあまり司書の重要性が一般の方に認知されていない傾向がありますが、欧米では司書は専門性の高い仕事として見られています。特に書物しかなかった時代においては、その地位は非常に高かったようです。

かくて図書館と司書はしだいにナショナル・プロジェクトの先頭に立ったり、グローバル・スタンダードの先兵ともなっていった。「図書館はその国の文化のインデックスにほかならない」と言ったのは、たしかレーニンだったはずである(104夜)。

気になるのは、上の引用文に書かれていた「司書や蔵書家は近代に向かうにしたがい、文人サロンの偉大な亭主ともなった」という表現。現在の司書は、人々が学び、考え、主張するような場の亭主としての役割を持っているのでしょうか。別に批判ではなく、そのような役割をもった司書が実はたくさんいるに違いない、と期待したいのです^ ^);
松岡氏はこの記事の他にも図書館に関する書評をいくつか書いています。

松岡氏が現在の日本の図書館をどのように見ているのか、ぜひ聞いてみたいですね。