SelfDOIについて

今年から国内の機関リポジトリで各大学が独自にDOIを設定出来るようになるそうです。 http://www.nii.ac.jp/irp/archive/system/jalc

この管理入力についてのガイドラインが公開されたので、見てみました。

使用できるDOIには、JaLC DOIとCrossRef DOIの２種類があり、対象と費用が異なっています。 CrossRefの方が対象が限られており、１データあたり１ドルの費用が必要になります。 どちらを選択することもできますが、１データに入力できるのはどちらか１つになります。

システム的には入力時にどちらにするか選べる必要があることになります。 更に、どちらも選択する事が出来ないようにする必要があります。

OAI-PMHで出力するメタデータ

OAI-PMHで出力するメタデータは、junii2でオプショナルな要素とされているものが使用されています。

まずselfDOI項目のraという属性でJaLCなのかCrossRefなのかを指定します。 加えて、JaLCの場合は、creatorのid属性、CrossRefの場合はタイトル等のlang属性です。

どちらも今までjunii2のガイドラインに出てきていない要素ですので対応していないところも多いのではないでしょうか。 Earmasの場合、何かしらの対応が必要になります。

creatorのid属性は、なんとでもなりそうですが、lang属性の機能追加は大変です。

  • 「言語」項目の値を見て自動で設定する
  • 入力フィールドの横に言語選択を追加する
  • 入力されている内容を見てアルファベットと記号だけなら英語にする

といった対応が考えられますが、「言語」項目の値のとおりに入力されているかどうかは何の保証もありませんし、 入力フィールドの横に言語選択を追加するのは入力が面倒です。入力されている内容がアルファベットかどうかで判断 するのは正確さに疑問が残ります。

現実的な落とし所としては、CrossRefを使用する場合は入力時にちゃんとチェックをし、うっかり防止で指定の項目がアルファベットのみかどうかのチェックをして、lang属性はenにする。というところではないかと思われます。

入力時のチェックに関する問題

JaLCとCrossRefのどちらも、使用できる対象のデータのNiiTypeが決まっており、それ以外のNIItypeのデータには使用できません。 CrossRefを使用する場合は、データ入力に関する制限がjunii2とは異なっており雑誌に関数情報や、書籍に関する情報が必須になっていたりします。

selfDOIを使っている場合、内容によりJaLCとCrossRefかを判断し、必須項目のチェック、入力値のチェックを変える必要があります。 これは、汎用のシステムでは無理でこれにシステム的に対応しようとすると、ほとんど専用のシステムになります。

また、この仕様がどの程度確定した情報なのかもわからないため、費用かけて機能追加して1年で仕様が変更になるといった事も考えられます。

OpenEarmasでは専用のチェック機能を付け、有効にした場合、データ登録時に入力内容をチェックする、といった感じで想像しています。

データ自体に関する制限

システムのデータに関する制限として

  • NIItypeは変更できない。
  • selfDOIを入力したデータを削除した場合、使用したDOIが欠番になる。
  • 登録したselfDOIを削除する場合、一度selfDOI項目を空にしてハーベストされるまで待つ必要がある、使用したselfDOIは欠番になる。

という制限があり、運用上の色々と問題が考えられます。

selfDOIを連番で振っている場合はそれほど大きな問題になりませんが、オープンアクセスサミットでの北海道大学での事例(http://www.nii.ac.jp/irp/event/2014/OA_summit/docs/1_03.pdf)のように 「紀要タイトル＋巻号＋ページ」とする場合、運用によっては問題が出てきそうです。

selfDOIを間違えてしまった場合

例えば「紀要タイトル＋巻号＋ページ」のページを間違えて前の論文と間違えていた場合

正しい
A論文のselfDOI : abc.123.1
B論文のselfDOI : abc.123.10

間違い
A論文のselfDOI : abc.123.10
B論文のselfDOI : abc.123.1

この場合、どうしようもありません。修正する方法がなく、消すと欠番になるため、このような間違いをした場合、 この規則とは外れるデータを登録することになります。

公開を間違えてしまった場合

まだ公開するつもりではなかったデータを誤って公開してしまった場合、一旦取り下げて再度公開する事があります。 この場合、selfDOIが欠番になるため、やはり「紀要タイトル＋巻号＋ページ」という規則とは異なるデータを登録することになります。

使用したselfDOIの管理

使用中と欠番となったselfDOIの値を間違って入力してしまわないように管理する必要があります。

使用中のselfDOIの値、公開データを削除して欠番になった場合のみでしたら、システム内にあるデータとの突き合わせをすればいいだけですが、selfDOI項目の値を空にして欠番にした場合、 履歴をすべて保持しているシステム以外はシステム内にデータがないためチェックができません。

そのため、selfDOI項目については重複チェック用のデータを用意して、公開時に使用したselfDOIを追加していくといった処理が必要になります。OpenEarmasでもこの方法になります。

selfDOIの修正処理

ガイドラインには修正時の処理は書かれていませんので、直接値を修正して良いのかどうかはわかりません。ガイドラインに書かれていることだけで対応すると、修正する場合は

  1. selfDOIの値を消す
  2. ハーベストされるまで待つ
  3. selfDOIの値を直す
  4. ハーベストされるまで待つ

という事になります。少なくとも2回ハーベストされる必要があるため、修正は反映されるまで機関によっては2ヶ月3ヶ月かかるという事になります。

selfDOIを使用する場合

まず、selfDOIを連番にするか規則を元に手入力するかを検討する必要があります。

連番にする場合は特に問題はありませんが、規則を元に手入力するは、規則のとおりに入力できなくなった時の対応を考えておく必要があります。

その上で、入力チェックをどこまでやるのか、雑誌単位での自動付番をするのか等を検討することになります。

何にせよまずは、信用できる業者に相談してみるのがいいのではないでしょうか。
(例えば ENUTechnologiesのような・・・)

Scopusの参照数

ScopusのAPIが更新され参照数の取得方法か変わりました。古い方法では2015年の4月には使えなくなるようです。

新しいAPIですが、どうやら旧APIのキーとは別になっているようで、http://dev.elsevier.com/ から新しいAPIのキーを取得する必要があります。

APIキーを取得したら画面に参照数を表示させます。

OpenEarmasの場合、使用方法は簡単で表示させたい設定で

<img src="http://api.elsevier.com/content/abstract/citation-count?doi=${document.doi}&httpAccept=image/jpeg&apiKey=1234567890"></img>

を入力します。※ ${document.doi}の部分はDOI項目のコードに合わせて変更して下さい。APIキーは取得したものに置き換えて下さい。

f:id:enuagashima:20141208163039p:plain

これだけでScopusの参照数が表示されるようになります。

f:id:enuagashima:20141208163036p:plain

機関リポジトリシステムに必要な機能

ソースコードのリポジトリのコミットメッセージを英語で書いていたのですが、片言の英語の上に説明が不十分すぎて後から見た時に自分でわからないので、諦めて日本語でメッセージを書く事にした永島です。

機関リポジトリソフトウェアを作って５年が過ぎ、どのような機能が機関リポジトリの運用に必要になるのかがおよそわかってきたので、今回は機関リポジトリソフトウェアにどのような機能が必要になってOpenEarmasではどのように解決しているかについてです。

公開データと未公開データ

機関リポジトリソフトウェアをよくあるデータベースシステムだと考えると、単純に登録したデータが公開されれば良いように思えるため、機関リポジトリの話をすると「なぜそんなに複雑なのか」といった質問をされることも結構あります。

機関リポジトリソフトウェアを複雑にしている最大の理由が、データを公開と未公開で２重に持つ必要がある事です。

理由

機関リポジトリシステムへのデータ入力作業の負荷は結構大きく、公開データに責任を持てる図書館の担当者ではなく臨職さんだったりアルバイトさんデータを入力する場合があります。この場合、入力したデータを誰も確認無しで直接公開されるというのは問題があり一度確認をした後に公開という流れが必要になります。

これは、入力と公開の権限の問題ですが、他に処理手順の問題もあります。

とりあえずメタデータが集まったので入力しておき、入力後に許諾の確認や、本文PDFのやりとりを行うといった手順で登録作業を行う場合があります。この場合も、データは入力するがまだ公開はしないという「下書き」のような状態が必要になります。

対応

新規登録だけでしたら下書きフラグでも作っておけばいいのですが、修正の場合はフラグ管理では対応出来ません。修正はまれなので、修正時は例外的に即反映という事も考えたのですが、データの修正は本文PDFの修正や部局の名前変更等で意外と発生する処理のようで無視出来ませんでした。

そこで、OpenEarmasでは、データを公開と未公開の２重に持ち、「新規作成」「修正」「削除」したデータは未公開データとなり「公開処理」を行う事で公開データとしてコピーされ、公開側の画面に反映されます。 (この機能は実際に作るのはかなり面倒で、しかもシステム全体に影響するため何をするにもネックになります。何度「これさえ無ければ」と思ったかわかりません)

マスター

一般的なデータベースの場合、種類マスタや分類マスタなどのマスタ機能があるのですが、機関リポジトリソフトウェアのマスタは一筋縄ではいかず、特殊なデータの処理が必要になります。

理由

一般的なデータベースの場合は、同じデータを何度も入力する項目はプルダウン等の選択項目にして、入力ミス等での表記の揺れを抑えます。しかし、機関リポジトリの場合、入力ミスでもなく、記載ミスでもなく、論文自体の表記が揺れます。表記は揺れるのですが、機関リポジトリに登録されるデータは論文の目録のデータですので、記載されているまま登録するのが筋です。

当然そのまま入力するとデータが揺れます。

著者の場合ですと、「英語日本語等の言語の違い」「結婚等で実際に名前が変わる」「記載されているのが略称等の表現の違い」で表記か揺れます。雑誌の場合は「統廃合」や「雑誌名の変更」などです。

これらの表記の揺れは何もせずそのまま揺らしておくと、検索では旧姓で入力しないとヒットしなかったり、一覧では同じ人の別名が並ぶ事になります。 機関リポジトリシステムでは、これらを解決しながら、元の論文の表記のままのデータを登録する必要があります。

対応

OpenEarmasでは、マスタは用意して選択可能な状態にはするのですが、マスタはとしてのデータはIDのみです。IDを元にマスタを検索し「一覧でのデータの同定」「検索対象の追加データ」として使用します。個々のデータの詳細画面ではIDと一緒に入力する論文の記載のままを情報を表示させます。

マスタの情報と直接入力の情報の両方を使用することで、柔軟な検索や整理された一覧を可能にしています。

最も問題が多い著者用の人物マスタでは、他のマスタが「コード」「日本語表記」「英語表記」だけなのに比べ「ID」「日本語名」「英語名」「名前読み」「別名1」「別名2」「別名3」「日本語所属」「英語所属」「URL」「科研費研究者番号等のID欄5つ」と非常に多くの情報を入力出来るようになっています。

姓名とリンクが表示されるだけですが、内部的には多くのデータを使用することで検索や一覧の正確性を高めています。

補足

マスタにあるデータのみを対象にした一覧が作成できます。

著者や雑誌名といったマスタ使用項目は、マスタにあるデータのみを入力するわけではありません。学外の雑誌までマスタ化するのは大変ですし、著者マスタでは学外への異動で管理対象から外したい場合もあります。

そのため、マスタと各データを直接連動させずマスタの修正、削除を行った場合でも各データは変わらず表示される必要がありました。

OpenEarmasの選択項目は、ID欄を内部項目ではなく入力可能な入力欄とし、入力されたIDがマスタにあるかどうかでマスタの値を一覧や検索で使用するかどうかを変化させています。IDは入力がなくても無効なIDでも動作するため非常に緩い連携ですが、柔軟な運用が可能です。

この機能を利用して、有効なIDがあるかどうかで一覧にフィルタをかけることで、マスタに含むデータのみで作った「学内著者一覧」や「学内刊行物一覧」等の一覧を作成する事ができます。

次回へ続く

ハンドルについて

機関リポジトリでハンドルと言えば、CNRIが運営するHandle Systemというサービスの事です。

サービスの内容は、CNRIと契約してハンドルを使うと、通常は http://example-u.ac.jp/9999 のようなリポジトリのデータに対するURLが http://hdl.handle.net/9999/9999 のようなURLに変わるというものです。

このURLの変換を行うために、リポジトリ固有のURLをHandle Systemに登録してHandle System専用のURLをもらい、リポジトリシステムは画面にそのURLを表示します。

http://hdl.handle.net/9999/9999 というHandle SystemのURLにアクセスすると サーバは登録されているオリジナルのURLに移動するようにブラウザに応答します。

このサービスは、リポジトリのURLはシステム変更等があっても変化せず未来永劫同じURLで使えるべき、という事で提供されているらしく国内ではそれなりに使われています。

しかし、OpenEarmasでは今のところ対応する予定はありません。その理由は

世界で多く使われているeprintsは標準ではハンドルに対応していない。

国内のリポジトリではかなりの割合でハンドルが使われています。国内で多く利用されている初期のDSpaceではハンドルをつかうのが標準で使わないようにするのにカスタマイズが必要でした。しかもその頃はサービスの利用料が無料でしたので何も考えず流れで使われていたのではないかと思います。

国内ではDSpaceが多く使われていますが、海外で多く使われているeprintではhandleを使うほうが大変です。国内を見ればリポジトリではハンドルを使うのが普通という感じがしなくもないですが、世界的に見れば使って当然といったサービスではなく選択肢の一つという感じなのではと思います。

ドメインの価値

ハンドルを使ってしまうと、データのURLとして http://hdl.handle.net/9999/9999 のようなハンドルのURLを使うことになるのですが、そのURLはカッコイイでしょうか。個人的には http://ir.example-u.ac.jp/9999 のような機関のURLの方がカッコイイと思いますし、「ああ、機関リポジトリのデータとして登録されているんだ」という事が一目瞭然で良いと思っています。

hdl.handle.net のURLは契約すればもらえますが ir.example-u.ac.jp のような機関のURLは、その機関に所属していなければもらえません。どちらが価値が高いかは明らかで、わざわざお金を払って機関ドメインのURLから変更する理由は無いのではないでしょうか。

システム移行でもURLは変わらない

「システム移行等でURLか変わるといけない」ということでhandleなのですが、そもそもシステム移行でURLが変わることはほぼありません。 よほど独特なシステムを使っている場合は別ですが大抵の機関リポジトリシステムの場合、URLは

http://hostname.domain/any/9999

のような形になります。数字部分は内部のデータIDですので、データ移行時に工夫すれば移行後も同じ番号にする事は簡単です。 その他の部分についても、WebサーバでURLを書き換える等の方法でなんとでもなります。

実際に機関リポジトリでのURLが変わるのは、機関のドメインが変わる時くらいでシステム移行くらいではおこりません。そして機関のドメインが変わるような場合は、機関リポジトリが同じ形で運営出来るか分からないという状況では無いでしょうか。

Handle Systemの動向に左右される。

これが一番大きな理由です。大学にリポジトリへのアクセスは直接の場合もあるでしょうが大半はGoogleやCinii等の検索サービス経由だと思います。そこではデータに対するURLとしてhandleのURLが使われていますので、もし Handle System がサービス停止した場合、現実的にはデータにアクセスできなくなります。

トラブルでの停止でもアクセスできなくなりますし、サービスの廃止、内容の変更、値上げ、など Handle System の動向に機関のサービスが左右されることになります。

アーカイブだから未来永劫同じURLで使えるようにするためのサービスの動向にアーカイバ左右される、というのはなにか本末転倒な気がします。

メリットも

使ったほうが良い理由もあります。ハンドルはそれ自体が世界で１つのIDとして考えることができるためDOIのようなデータを特定するための情報として扱われています。そのため、DOIやPMID等の情報と同じようにハンドルを指定してデータを特定するサービスもあり、今後そのようなサービスを使っていこうと考えているとすれば、ハンドルを使わない手はないと思います。

というわけで、最後にPRです。

弊社では Earmas で培った eprint d-space e-repository から移行の経験を生かし、OpenEarmasでもデータが揃えば最短で１週間という素早いデータ移行が可能です(ハンドルは使えませんが) そんな OpenEarmasのクラウド版 Earmas Cloud ( http://www.earmas.net/ ) をよろしくお願い致します。

開発ブログはじめました

はじめましてENUの永島です。

せっかくオープンソースで開発することにしたので、ソースコード以外も色々とオープンにして行こうということで開発ブログを始めました。

OpenEarmasって何？という人も多いと思いますので、簡単に説明をしますと「学術情報リポジトリ用のソフトウェア」です。 学術情報リポジトリというのは「大学等の研究機関が論文をアーカイブして公開するためのソフトウェア」です。

去年まではクローズドなアプリとして販売していたのですが、今年オープンソース版を作成して公開しました。

クローズド版とオープンソース版はプログラム的には開発言語から違っている完全に別物なのですが、プログラムだけではなくコンセプトも異なります。

Earmas(クローズド)

  • 開発言語はJava
  • ポータビリティーを高く
  • データベースを使わずデータはファイルで管理
  • 機能追加しやすく

「Javaさえインストールされていれば基本的に動く」という事を前提に作られています。全てのデータがファイルベースで管理されているため、システムの移動やコピーが簡単でバックアップも普通のファイルコピーで行うことができます。また、共同リポジトリや資料等のコレクションデータベースを立ち上げる時などに、システムをディレクトリごとコピーをして設定を変更するだけで新しいリポジトリが作れます。

その反面、設定もファイルベースで行う必要があるため慣れるまでは大変で、ファイルの対しての処理が多く大量のデータの処理や表示は遅いためキャッシュが必須。要望に合わせて後から次々と機能追加を行っているため、コードが複雑になっています。

OpenEarmas(オープンソース)

  • 開発言語はRuby(on Rails)
  • 全ての設定は画面上から
  • RDBを使う
  • コードの構造をシンプルにする

システムの追加や変更は依頼されるので管理を簡単にしてもあまり意味がなかったという経験から、OpenEarmasでは管理より設定のしやすさを重視しています。画面上から全ての設定ができるようにし、高速にデータ修正ができるようRDBでデータを管理しています。

Earmasの初期はRDBを使ったWebアプリだったのですが紆余曲折あり今の形に落ち着き、OpenEarmasでまた普通のWebアプリに戻ったわけですが、データは10万件程度のデータが投入されたとしても高速にリストの閲覧を可能にするためにちょっと凝った構造にしています。

プログラム自体は、職業プログラマではなく情報系に詳しい図書館職員の方がソースを見る可能性が高いという前提で、なるべく抽象化や部品化を行わずソースが追いかけやすく誰が見てもなんとなくやっている事がわかるようにしてあります。そのため若干冗長な記述やソースベタ書きな定数などありますが、フラットで変更がしやすい構造になっています。

また、せっかく論文を公開するなら綺麗に見せるべき、ということでOpenEarmasでは見せ方を重視しており画面関係の設定が非常に多くなっています。

どう使い分けるか

EarmasとOpenEarmasはどちらの方が優れているといった上下関係はありません。どちらを使えばいいのかは

  • 共同リポジトリやコレクション系データベースなど、同じようなシステムを複数作成する場合は管理が簡単なEarmas。
  • データにも見た目にもこだわった、オリジナルなリポジトリを作りたい場合はOpenEarmas。

という感じで考えて頂ければと思います。

OpenEarmasでは、サーバの管理がそもそも面倒という要望に答えてwebサービス版のEarmas Cloud(ファーエンドテクノロジー株式会社)もあります。 http://www.earmas.net/