2018年8月25日土曜日

【18】AtoMへCSVで追記

めずらしく、いや、いつものことですが、ぼーとしている頭で道場始まりました。夏バテに一週間の疲労がピークに達している金曜日なのです。ということで、今日のブログは適当に書きます〜(笑)

前回の作業を思い出すのにおよそ30分が経過。(ほら、大丈夫かい?)
でもなかなか次のステップがわからず(笑)、前回のブログに書いてある次回の作業を素直にまずやってみることになりました。

今日の作業
DIPを作成し、AtoMにいれ、CSVを出して、また入れます。(本当にざっくりですみません)

つまり、
1)ArchivemeticaからAtoMにDipをいれる
2)AtoMからCSVをexport
3)そのcsvをAtoMにimport
4)この時、注意するオプション

  • update optionにチェック
  • file nameはexportしたときのnameをそのまま使う

です。

【実験1】
AtoMのターゲットfonds:shumutam(シリーズ1個)
ここに、Archivemeticaから作成したDIPを、アップロード。ここまではいつもの通りで、ちゃんとshumutamにシリーズが反映されました。

なので、CSVをexportします〜

そのCSVに編集を加えず、update optionにチェックして、出した時のファイル名をそのまま使ってimportしてみます〜 (え~と、この作業の目的がなんだったのか、記憶が曖昧ですが、とにかく今日は素直にやります。)

結果、ターゲットのフォンドに新しいシリーズが追加されました。exportされたCSVにあるlegacy IDをそのままimportしているので、新しいシリーズとして認識されました。(まぁ、当然のことか・・・)

しかし、CSVにちゃんと入れた画像のリンクがAtoMに反映されませんでした。しかも、複数あるなか、一番目の画像のURLだけが反映されました。(ほぉ~(*゚с゚*) 実に不可解だ~)

【実験2】
そこで、第2案として前回のブログにある「後日追記」を試してみることにしました。
https://irisawadojo.blogspot.com/2018/08/2018-08-1dipatom.html

exportしたCSVには、フォンドのsource idだけをkeymapから探して入力し、ほかは我々が決めて書き換えてしまう方法です。そこで、フォンド以外のデータのlegacy IDに、shumuta2, 3, 4を入れてみました。そしてreplaceのoptionにチェックしてimport(これは追記ではなく書き換えです)。

じゃじゃん〜

しかし、ここでよくわからず、skip unmatched records にチェックを入れたらunmatched dataがdeleteされ(ココまではOK)、replaceができませんでした(これはダメ)。なので、CSVで入れようとしたデータが登録されませんでした。(えへへ〜〜 実際登録する際には注意しましょう!)

とういうことで、CSVを再度アップロードしました。

じゃじゃん〜

結果、ちゃんと決めたLegacy IDで登録されました。


  ※ただいま議論中~ (何となく雰囲気伝わりますか? ^^;)

【今日の結論】
  1. DIPをAtoMのターゲットフォンドにuploadした時点では、AtoMにデータは反映されるが、legacy IDはまだない。keymapを見るとまだフォンドのlegacy ID(keymap上ではsource ID)しかないことがわかる。
  2. その状態で、CSVをexportし、title, identifier, repository(第2条件)を合わせて、Legacy IDとsource file name(第一条件)は我々が決める。
    今日の実験では、フォンドのlegacy IDを一致させましたが、結局最初DIPを入れる際には、各レポジトリで管理するlegacy IDをここで初めて指定するのが一般的だと考えられるので、upload時にデータを同定する第1条件は考えず、第2条件を合わせればOKなのではというのが今日の発見です。つまり、フォンドのlegacy IDも我々が決めれば大丈夫。
  3. importする際には、ignore matches and create new...(後日追記:これはDelete matches and replace with imported records..の間違いです)のoptionにチェックして、フォンドを書き換える。この時点で、指定したlegacy ID, source file nameがkeymapに登録される。
  4. 次は、今のsource fileに(今度は、第一条件を合わせれば良い)archival descriptionをガンガン書いて、追記するoptionにチェックして(replaceでの問題ないような気がしますが…)AtoMへアップロードすれば、DIPを入れることができる・・・・・・・かな?

そこで、誰かが言いました。
「でも~~ 画像が読み込めないのはつらいですね!」
その通りです。

archivemeticaにある画像のURLを確認し、CSVにURLをちゃんと入力して、再度AtoMにCSVをimportしてみましたが、やはり失敗しました。

ここで時間切れです。
ガソリンを入れて、栄養も取らないと長く走れませんので。大事です。では、次回をお楽しみに!

====================
次回
今日の復習(欠席した人のためにですよ!皆来て~)
画像が行方不明になる理由を考えます。




2018年8月5日日曜日

DCメタデータはAtoMに反映されるそうです。

ArchivematicaのDIPとAtoMの階層記述をリンクさせる問題について、ググっていたら、Slide ShareでDan Gilleanの発表したスライドに出くわしました。
URLはこちらです。
36枚目のスライドを見ると、AtoMのオブジェクト(=DIP)に、ArchivematicaのDublin Coreメタデータ(以下、DCメタ)がくっつけられるとあります。
CSVファイル方式でも、集合型の付与方式(SIP単位、つまりArchivematicaの画面上での入力、なお画面上での入力をDC metadata templateというらしい)でも方法は関係ないようです。

それで、Archivematicaの説明書のDIPアップロードの部分を見ていたら、

If you want to create a child level of description under the target description, you must add the title of that level of description using the DC metadata template prior to normalization.

If you add metadata to the DIP during Ingest, a file-level record will be created in AtoM below the chosen parent record. The metadata will be written to this file-level record and the digital objects will be added as child items. If you do not add metadata, the digital objects will be added to the parent record directly.

という記述がありました。
Fileレベルが何を指すのか、わかりませんが、DIPのターゲットとするAtoM記述の子供レベルのメタデータは、DCメタで作れるかもしれません。

次回は、こちらもテストしたいなと思います。

なお、Dan Gilleanのスライドは、AtoMとArchivematicaの今後追加したい機能も書かれているので、時間のある方はぜひお読みください。

AtoMでつくる階層記述型のメタデータも、将来的には、ArchivematicaのAIPに後から追加できるようにしたいようです。
AtoMとArchivematicaの連動性は、引き続き強化されていく見通しです。

それでは、また!
   橋本



【17】DIPのAtoMへのアップロード

今日は時間より早くメンバーが集まりました〜〜
皆やる気満々です。(見た目は…笑)
やはり休みは必要なんですね。

前回作業から大分時間が過ぎたので、今日は前回の発見の再現です。

つまり、

  1. ArchivematicaからDIP生成
  2. DIPをAtoMへ流す(このときターゲットとなるFondsは事前にAtoMに作成しておく)
  3. 流したデータのCSVを出力して、source idをkeymapテーブルから探して
  4. CSVにそのsoure id をLegacyIDとして入力してから、追記する


です!

では復習です。ポイントは、


  1. AtoMに登録されたデータは、idが2つ存在する。
     source id = legacy id target id  = ニセ legacy id
  2. source idは登録するデータを区別する。しかし、AtoMのシステム上では重複し得る。
  3. target idはデータベース上のデータを区別する。AtoMのjob番号のようなものが自動で付与されるが、source idが重複する時などの識別に使われると思われる。


です。

まだ我々が議論しているのは、このような作業を想定している場合です。受け入れた記録を、とにかくフォンドだけをAtoMに作成しておいて、その後はAtoMに直接登録するのではなく、せっかくArchivematicaを使っているのだから、DIPをAtoMへアップロードしたい。(ボリューム多い記録を整理する際にあり得る作業過程かと。)
しかし、DIPにはlegacy idもindetifierもないのに、どうやってAtoMにあるフォンドにデータを追加するかです。

ということで作業は進みます。

【前回作業の再現】

  1. AtoMにFondsを作成:803 shumutam
  2. Archivematicaからデータ入力して、SIPを作成する。Ingestのダッシュボードにある鉛筆の絵のアイコンを押すとメタデータ(dublin core)の追加ができる。ここで入れたデータはArchivematicaのMETSには反映された。しかし、AtoMへは反映されないみたい。
  3. ArchivemeticaからDIP生成 → ここまで無事完了
  4. DIPをAtoMへ流す(このときターゲットとなるFondsは事前にAtoMに作成しておく)→ 無事完了
  5. 流したデータのCSVを出力して、source idをkeymapテーブルから探す → 問題発生!なんと該当するsource idがkeymapテーブルにありません。ガガンガン〜〜〜w|;゚ロ゚|w 


ここで作業は次に進まずあーだこーだの議論と実験に入りました。

【実験1】
AtoMのUIで入力したFondsのCSVを出力してみる。出てきたLegacyIDはkeymapテーブルの中にはない。
UIで登録する場合、keymapテーブルに登録されないことがわかりました。

【実験2】
AtoMにCSVでFondsを生成。
keymap tableにはフォンドのsource idがありました。

【実験1と2でわかったこと】
どうも、CSVで登録しなければkeymapテーブルには登録されない模様です。たしかにUIから登録する場合は、source nameもないですよね。


【実験3】
もしかしてフォンド以下のデータが登録されないとsourc idは生成されないのでは?そこで、とにかく実験2のファイルに確認できたfondsのsource idだけを書き換えて、いくつかアイテムを入れて、追記してみます。

→ 追記ではなく、新規登録されました。それはそうだな…だって、fonds以外のsource idがなかったので、CSVで出てきた番号(これはtarget id)のまま登録しているから、新規登録されるだろうな…そして、keymapテーブルには、このtarget idがsource idとして登録され、それに該当する新しいtarget idも付与される。

-----------------------------------------------------------------
(後日追記)
ここまで作業内容をまとめていたら、一つ気づいたこと。
DIPをAtoMに流したところでsource idは生成されないので、そのCSVをexportしてarchival discriptionを入れてから、AtoMに追記ではなく、Fondsのsource idだけをマッチングさせて新規登録してしまえば(書き換える)、Fondsのsource idは残しつつ、下位レベルのデータにsource idが生成される(もしくは管理上必要なidを入力する)。
結果的にこの時点で、source nameもすべてのデータのsource idも確定できるのでは?もしkeymapテーブルに同じFondsのsource idと古いtarget idでログが残っていれば、このfondsが書き換えられたことがわかる。確かkeymapテーブルのデータは該当するデータを削除しなければ記録が消えなかったと思う。
-----------------------------------------------------------------

ということで今日の結論は、やはりDIPをAtoMにCSVを利用して追記する際必要なlegacy idとsource nameをどう特定するのかわかりません〜です。

うん?
では前回の発見はなんだった?
DIPをAtoMに入れたらsource idがあったぞ!
しかし、今日の実験でそれは皆の勘違いだったのでは?というまさかの結論になりました。つまり、前回作業で使ったファイルは、昔作業したものが偶然残っていて、我々はそれがその日入れたDIPのidだと勘違いしたのである…です。

ひどい話だ…皆欠席するからこういうことになるんだ!あぁ〜前回味わった達成感は何だったのだろう〜
(; ̄ー ̄川 


【いくつかの疑問】
  • DIPをAtoMに入れたところで、あまりDIPの情報がAtoMに反映されないみたい。DIPを利用するメリットは何があるの?
  • ArchivematicaはOAISに準拠してないかも。


ではでは、今日は前回の発見が発見ではなかったということを発見して終わります!

はぁ・・・・そうですか・・・・(ノ_・、)シクシク


=====================================
次回
1)ArchivematicaからAtoMにDipをいれる
2)AtoMからCSVをexport
3)そのcsvをAtoMにimport
4)この時、注意するオプション

  • update optionにチェック
  • file nameはexportしたときのnameをそのまま使う



最近の投稿

【108】Archives in the Digital Age: The use of AI and machine learning in the Swedish archival sectorを読む

 Gijs Aangenendt氏の修士論文、Archives in the Digital Age: The use of AI and machine learning in the Swedish archival sectorを半分読みました。 前半は、AIを扱ったアーカ...

人気の投稿