[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
    > > お忙しいところ申し訳ございませんが、ご教示くださいますよう、お願いいたします。
    > >
    > > １．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」というエレ
    メントを設定しているのだと思います。

    > > ２．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

- Follow-Ups:
  - [drf:1097] Re: リポジトリについておたずねいたします
    - From: 杉田茂樹
  - [drf:1075] Re: リポジトリについておたずねいたします
    - From: 杉田茂樹

- Prev by Date: [drf:1070] DuraSpace!?　[Fwd: [SOAF] NEWS RELEASE: Fedora Commons and DSpace Foundation Join Together to Create DuraSpace™]
- Next by Date: [drf:1072] Re: [kucsi:01244] [drf:1059] Re: PDF上の文字をコピペすると文字化け
- Previous by thread: [drf:1069] [drf:1060]　について
- Next by thread: [drf:1075] Re: リポジトリについておたずねいたします
- Index(es):
  - Date
  - Thread