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

[drf:1075] Re: リポジトリについておたずねいたします



北大 杉田です。

別途またお問い合わせを頂きました。

以下、DSpace限定の話題で恐縮です。

>> > <dc:creator>姓, 名</dc:creator>
>> > <dc:creator>Family, Given</dc:creator>
>> >
>> > と両方単なるcreatorで出しちゃってます。直そっと。
> 
>  とのことですが,これは,
> 
> ・どのように直しますか?
> ・どうやって直しますか?

この書き手の方のご意図は、技術的な観点ではなく、人の情報の記録を
どうするかという点にあるようですので、以下分けて。

(1) 技術的には

フォローよろしく;>北大野中さん


(2) それはそれとして

ちゃんとしたいのですが、DSpaceでは著者とその著者の付帯情報(別標
記とか、あるいは所属とか)を、構造的に管理することができません。

すなわち、二名の共著アイテムに、
 creator 杉田, 茂樹
 creator 野中, 雄司
 creator:alternative スギタ, シゲキ
 creator:alternative ノナカ, ユウジ
と記録したときに、
 杉田茂樹 - スギタシゲキ
 野中雄司 - ノナカユウジ
という対の関係ではなく、4つのばらばらな項目としてフラットにデー
タベースに格納されてしまう。

なので、(1)に(野中さんが)示すよう、単にalternativeは出さない、
ということに留めます。

>北陸先端大さん、小樽商大さん

著者ごとに著者の識別番号などを対関係で管理できるようなシステム改
造をされていたかと思います。
あれはテーブルを追加しているのでしたっけ。その考え方を拡張すれば
いろいろできそうですね。フォローありましたらよろしくお願いします。

>みなさま、

でも、今後18か月をかけて、人の識別(情報の記録)のためのインフラ
整備について取り組もう、というのが国際情勢です(以下の「5」)。
ウォッチしておく必要はあるかと思います。

http://repinf.pbworks.com/Interoperable-identification-infrastructure
People identifiers: develop a people identifier collection service (both human and machine queryable) to enable people to create equivalence/non-equivalence assertions between a subset of their different digital identities, and to store these equivalences





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