[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[drf:1071] Re: リポジトリについておたずねいたします(Re: [drf:1019] Re: 機関リポジトリ公開時にすべきこと)
- Date: Mon, 18 May 2009 13:21:23 +0900
北大 杉田です。
http://drf.lib.hokudai.ac.jp/drfml/msg01013.html
に関して、質問を頂きましたのでこちらでお返事します。
> > DRF1019の書き込みに関連して細かい点についてご教示いただきたくメールを差し上げました。
> > http://drf.lib.hokudai.ac.jp/drfml/msg01013.html
> > お忙しいところ申し訳ございませんが、ご教示くださいますよう、お願いいたします。
> >
> > 1.textversionについて
> > 少なくとも
> > ・クロスウォークで、dc.rights.textversionがrightsとして出力され
> > ないように設定する。
> > さらに言えば、
> > ・DSpaceのメタデータ設定中、textversionの親要素がrightsである状態
> > を解除する。
> > のがよいかと思います。
> > → 解除するという意味は rights.textversion のDspace側の要素/限定子はそのままにしておきtextversionのみ表示されるようにシス
> > テムを修正するということでしょうか。
「少なくとも」以下はそういうことです。
「さらに言えば」以下はそうではなく、
(1) DSpace上で、
(2) textversionをrights配下の限定子とするのでなく、
(3a) 適当なDCレベルのエレメントをでっちあげる。
(3b) またはでっちあげて、それの限定子として定義する。
つまり、rights.textversionではなく、textversionとか、sonohoka.textversionとい
うような項目名にするということです。
> > ダブリンコアの定義によると使用できる要素は決まっているため、要素に勝手にtextversionを設定することはできない、という理解でよろ
> > しいでしょうか。
前述の意味ですので以下は余談ですが、純技術的には、ダブリンコアは、その仕様上、
自由に拡張することが許容されているので、自由に限定子を設定することができます。
だからtextversionという限定子をrightsエレメントに対して定義することはダブリン
コアの仕様上は純技術的にはとくに問題ありません。
(つまり、言おうとしたのは、仕様上は許容されるが、理に適っていない、というこ
とです。版情報は権利情報ではありませんから)
> > 京大さんのリポジトリhttp://repository.kulib.kyoto-u.ac.jp/dspace/handle/2433/73228の詳細表示をみるとdc.textversion となってお
> > りrightsが表示されておりません。
京大はDCレベルの適当なエレメントとしてそのものずばり「textversion」というエレ
メントを設定しているのだと思います。
> > 2.contributorとcreatorの使い分けについて
> > 著者として、contributor.authorを使っているところとcreator.noneを使っているところがあります。OAIへのハーベストは著者をcreator
> > ,著者ローマ字読みをcontributorへ、どちらもcreatorにしているところなど様々です。
creator
contributor.author
はどちらも適切だと思いますが、「著者をcreator、著者ローマ字読みをcontributor」は
完全に誤りです。
著者 creator
著者ヨミ creator
著者 contributor.author
著者ヨミ contributor.author
も、誤りかどうかは微妙ですが、質問者さんがおっしゃる通り、二人に見えてしまうので
好ましくないように思います。
著者 creator
著者ヨミ creator.alternative
(alternativeというのは別標記形を記録するためによく使用される限定子です)
などが正しいです。
> > 同じ著者なのに、creatorとしてハーベストすると2名存在するようにも見えるし、contributorにハーベストすると寄与者となり意味が違っ
> > てくるように思います。このあたりはどのような考え方で北大さんはハーベストされているのでしょうか。
まず、参考までに、DSpaceは、画面上contributorに入力すると、画面上はcontributor
として出力されますが、ハーベストされる際はcreatorとして出力されます。
これは、
・図書館資料の記述のためのダブリン・コア・ライブラリー・アプリケーション・プ
ロファイル(LAP)の検討グループが、
「著者と貢献者って、程度問題であって、厳密な区別じゃないじゃない。じゃいっ
そのこと全員貢献者扱いでいいんじゃない?」
と考え、LAPではcreatorを廃止した。
・DSpaceは基本メタデータセットとしてLAPを採用した。
・しかし、相互運用性確保のために日和って、LAPを採用したにも関わらずOAI-PMH対応
では、せっかく採用したcontributor.authorをcreatorに変換して出力する仕様にした。
http://www.nii.ac.jp/metadata/irp/dspace-docs-jp_1_3/application.html#oai
> さらに、OAIコミュニティの慣習に合わせるために、contributor.authorの値はcreatorとして提供されます。
という経緯によるものです。
で、その上で、北大はDSpaceのデフォルトの設定に従わず、著者はcreatorに入力し、
ハーベストもcreatorで出しています。
で、ところで、本学では著者のヨミは基本的に持っていませんが、漢字形とアルファ
ベット形が論文に記されているときなどに、一方をcreator、一方をcreator.alternative
として扱っています。
で、で、上では、「二人に見えてしまうので好ましくない」と申し上げましたにも
関わらずかっこわるいのですが、北大IRは現状oai_dcにおいて、
<dc:creator>姓, 名</dc:creator>
<dc:creator>Family, Given</dc:creator>
と両方単なるcreatorで出しちゃってます。直そっと。
> > 北大さんのOAIのハーベストを参考にさせてもらおうと以下のように入力しましたが、エラーとなってしまいました。
> > http://eprints.lib.hokudai.ac.jp/dspace-oai/request?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:dspace.eprints.lib.hokudai.ac.jp/dspace:2115/38441
> > こちらもご教示いただけないでしょうか。
正しくは、
http://eprints.lib.hokudai.ac.jp/dspace-oai/request?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:eprints.lib.hokudai.ac.jp:2115/38441
です。
identifierの部分は次のような構成です。
oai:eprints.lib.hokudai.ac.jp:2115/38441
~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~
「oai」固定 : 各リポジトリの自称(通例ホスト名が使われる) : リポジトリ内のアイテムの固有ID
(http://www.nii.ac.jp/irp/archive/translation/oai-pmh2.0/OpenArchivesProtocol.htm#UniqueIdentifier 参照のこと。)
固有IDは、DSpaceではCNRIハンドルが使用されますが、それはDSpace特有の事情です。
例えばE-repositoryでは8桁数字だったかと思います。
> > 業者さんから送られてきた項目対応表は独自項目として、creator.affiliation,
> > creator.transcriptionが追加されましたが、contributor.author,contributor.alternative
> > とこちらはcontributorのままになっています。大学側でどちらかに統一してもらっ
> > てもシステム的に問題はない事項でしょうか。
業者さんの提示してきた案は、つまり、
affiliation(所属?)
transcription(ヨミ?)
author(著者である旨の言明)
alternative(別標記形?)
をcreatorとcontributorに泣き別れにするという案でしょうか。論外です。
統一してもらうべきです。
また、alternativeとtranscriptionはどう使い分けるのでしょう。
#ただし、著者所属機関をcontributor(その著作の成立に貢献した者)として
#記録する、という考え方は在り得ます。
#creator: 杉田茂樹
#contributor: 北海道大学
--
SUGITA Shigeki <sugita @ xxxxxxxxxxxxxxxxx>
Hokkaido University Library, JAPAN
http://eprints.lib.hokudai.ac.jp