[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[drf:1085] DSpaceにおけるメタデータの扱いについて



北大 杉田です。

江別の鈴木さんから最近の話題に関して、いくつかアドバイスを
いただきました。OKをいただいたのでこの場に回送します。

> 1.textversionについて
> 
> DSpaceは内部メタデータをDCメタデータスキーマのタグで持っているので、
> どうしても話がごちゃごちゃになりますが、極端に言えば、oai_dcとして外部に
> 提供する際に正しく変換できるのであれば、内部メタデータの(スキーマ名・)
> 要素名・限定子名は何でも良いといえます。
> 
> ただし、DSpaceで提供されているoai_dcクロスウォークは2つの例外
> (dc.contributor.authorをcreatorに変換、description.provenanceを出力しない)
> を除いて、すべての要素を単に限定子をはずした形で提供するので、次の2つの
> 問題を引き起こします。
> 
> (1) dc.rights.textversion を rights要素として出力する
>   など、スキーマ定義上は正しいが、意味的には間違っている
>   データを出力
> 
> (2) dc.textversion.none を textversion要素として出力する
>   など、スキーマ定義的に正しくないデータを出力
> 
> また、アイテムの詳細表示画面では(スキーマ名・)要素名・
> 限定子名がそのまま表示されてしまうので(これは単なる
> 内部名称ですが)変なデータが使用されているように見える
> という問題もあります。
> 
> これに対応するには、前者はoai_dcクロスウォークプログラムの修正、
> 後者は正しいタグ名の使用になると思います。なお、デフォルトの
> oai_dcクロスウォークはDCスキーマのデータしか出力の対象としない
> ので、DSpace1.4.xの場合は、独自定義のフィールドをDC以外のスキーマ
> で作成すれば対応できます。

正確な解説、ありがとうございます。

> ちなみに、oai_dcとしてはtextversionの情報内容は出力する必要はないと
> 思います。

はい。
仮に出すなら何らかの項目に単純にダムダウンするのでなく、版情報である
ことをわかるように字頭に「本文ファイルのバージョン:」と自動付加する
とかしないと意味不明ですね。

> 2.著者名、別名、翻字形、所属について
> 
> 要素名にcontributorを使うのか、creatorを使うのかはどちらでも
> 良いのですが、私は
> 
> 著者名(タイトルの言語に合わせた言語での名前)は contributor.author
> 別名(記述対称にある著者名以外の言語での名前)は contributor.alternative
> 翻字形(アイテム作成者が作成した翻字形の名前)は contributor.transcription
> 著者所属                   は contributor.affiliation

alternative、transcriptionはそれぞれ別名、翻字形と使い分けるとよいと
いうことですね。なるほど。

> として、oai_dcでは、affiliationを除いて、そのままcreatorで出力すれば
> 良いと思います。oai_dcで元レコードの再現は所詮不可能であり、検索キーと
> して考えれば有用だと思われるからです。
> 
> 著者所属はリポジトリを電子ジャーナルとして見せたい場合以外は、
> そもそも登録する必要がないと考えます。

電子ジャーナルとして見せたい場合ですが、

 著者:杉田茂樹
 著者:鈴木敬二
 著者所属:北海道大学
 著者所属:独立コンサルタント

でなく

 著者:杉田茂樹(北海道大学)、鈴木敬二(独立コンサルタント)

とか、

 著者:杉田茂樹1)、鈴木敬二2)
 著者所属:1)北海道大学、2)独立コンサルタント

とかのように出したいです。
それには次項3.の面から初期状態のDSpaceは不向きですね。
本学は、「杉田茂樹(北海道大学)、鈴木敬二(独立コンサルタント)」
の形をべたっと表示用に記録しておくための別項目を新設し一部の紀要で
使ってます。

> 3. 著者情報を構造的に管理できない件について
> 
> これも問題になるのは電子ジャーナルとして見せたい場合だけだと
> 思います。必要であれば研究者DBとの連携などで実現すれば良いと
> 思います。
> 
> Barrelでは、研究者ページを実現するために、EPersonとは別にResearcher
> クラスを作成しています。研究者の指定にはこのクラスのIDを使用しますが、
> EPersonとResearcherは第3の識別番号(研究者DBとのリンクで使用することを
> 想定)を介してリンクしています。入力は、contributor.authorに
> "姓, 名||識別番号" という形で行い(識別番号の付与により典拠処理を
> していることになります)、内部で Researcher IDに変換し識別番号は外部には
> 出力しないようにしています。
> 
> このResearcherレコードを整備するか、研究者DBとリンクすることにより
> 著者情報の構造的管理は実現できると思います。

そういえば研究者DBとリンクしているIRでは、リポジトリ内の人の情報
を外部情報と紐付けするための拡張をしているのでしょうね。
フォローありましたらよろしくお願いします>先行館さま

> 典拠といえば、dspace-devel メーリングリストでベルギーの会社の人がすでに
> DSpaceで典拠機能を開発したというポストがありました。
> 
> また、先日DSpaceにどんな機能が欲しいかのアンケート結果が出ましたが
> 上位3つが「もっと使える統計機能」「エンバーゴ処理機能」「バッチデータ修正
> 機能」だったそうです。まったく夢のない話だと思います。

このアンケート結果ってどこの何ものでしょう?
夢のある機能、どんなのがありますかね。
以前、http://drf.lib.hokudai.ac.jp/drfml/msg00267.htmlというような
のもありましたが、そういえばこのときはほとんどどこかに既存の機能が
選択肢だったので、あまり夢のある話にはつながりませんでしたですね。

#ただ「もっと使える統計機能」は、文献提供者にとって魅力のある統計
#を供給したいのでそれなりに夢のある話な気がします。

-- 
杉田茂樹 <sugita @ xxxxxxxxxxxxxxxxx>
北海道大学附属図書館学術システム課システム管理担当
電話番号:011-706-2524,ファクシミリ:011-706-4099
http://eprints.lib.hokudai.ac.jp