皆やる気満々です。（見た目は…笑）
やはり休みは必要なんですね。
前回作業から大分時間が過ぎたので、今日は前回の発見の再現です。
つまり、
- ArchivematicaからDIP生成
- DIPをAtoMへ流す（このときターゲットとなるFondsは事前にAtoMに作成しておく）
- 流したデータのCSVを出力して、source idをkeymapテーブルから探して
- CSVにそのsoure id をLegacyIDとして入力してから、追記する
です！
では復習です。ポイントは、
- AtoMに登録されたデータは、idが２つ存在する。
source id = legacy id target id = ニセ legacy id - source idは登録するデータを区別する。しかし、AtoMのシステム上では重複し得る。
- target idはデータベース上のデータを区別する。AtoMのjob番号のようなものが自動で付与されるが、source idが重複する時などの識別に使われると思われる。
です。
まだ我々が議論しているのは、このような作業を想定している場合です。受け入れた記録を、とにかくフォンドだけをAtoMに作成しておいて、その後はAtoMに直接登録するのではなく、せっかくArchivematicaを使っているのだから、DIPをAtoMへアップロードしたい。（ボリューム多い記録を整理する際にあり得る作業過程かと。）
しかし、DIPにはlegacy idもindetifierもないのに、どうやってAtoMにあるフォンドにデータを追加するかです。
ということで作業は進みます。
【前回作業の再現】
- AtoMにFondsを作成：803 shumutam
- Archivematicaからデータ入力して、SIPを作成する。Ingestのダッシュボードにある鉛筆の絵のアイコンを押すとメタデータ（dublin core)の追加ができる。ここで入れたデータはArchivematicaのMETSには反映された。しかし、AtoMへは反映されないみたい。
- ArchivemeticaからDIP生成 → ここまで無事完了
- DIPをAtoMへ流す（このときターゲットとなるFondsは事前にAtoMに作成しておく）→ 無事完了
- 流したデータのCSVを出力して、source idをkeymapテーブルから探す → 問題発生！なんと該当するsource idがkeymapテーブルにありません。ガガンガン〜〜〜w|;ﾟﾛﾟ|w
ここで作業は次に進まずあーだこーだの議論と実験に入りました。
【実験１】
AtoMのUIで入力したFondsのCSVを出力してみる。出てきたLegacyIDはkeymapテーブルの中にはない。
→UIで登録する場合、keymapテーブルに登録されないことがわかりました。
【実験２】
AtoMにCSVでFondsを生成。
→keymap tableにはフォンドのsource idがありました。
【実験１と２でわかったこと】
どうも、CSVで登録しなければkeymapテーブルには登録されない模様です。たしかにUIから登録する場合は、source nameもないですよね。
【実験３】
もしかしてフォンド以下のデータが登録されないとsourc idは生成されないのでは？そこで、とにかく実験２のファイルに確認できた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に準拠してないかも。
ではでは、今日は前回の発見が発見ではなかったということを発見して終わります!
はぁ・・・・そうですか・・・・(ﾉ_･､)ｼｸｼｸ
=====================================
次回
１）ArchivematicaからAtoMにDipをいれる
２）AtoMからCSVをexport
３）そのcsvをAtoMにimport
４）この時、注意するオプション
- update optionにチェック
- file nameはexportしたときのnameをそのまま使う
