【24】OAISとArchivematicaの機能を比較

寒いっす！
でも大人の勉強会は始まりました。
雨にも負けず、風にも負けず、頑張ります！

今日は、前回の続きです。
Archivematicaの機能とOAISを比較しながら、OAISに関する理解を深めます。

まずはこれから↓
ArchivematicaとOAIS参照モデルの対応関係（スライド49枚目）
https://www.slideshare.net/Archivematica/digital-preservation-with-archivematica-an-introduction

ちゃんと対応関係が出ています。49枚目のスライドがこれ↓

OAISでいう長期保存
１）技術の変化にデータが耐えられる（読める、証拠として機能する）
２）Consumerの立場で読めるようなデータでなければならない。利用者の要求に答えられるような形でなければならない。

以下はマゼンタブック（https://public.ccsds.org/pubs/650x0m2.pdf）で説明する3つのデータパッケージの関係です。この3つがContent Informationとなります。

このContent Informationは、さらにPDIと合わさってパッケージとなります。これにさらに、ISAD(G)などのようなDescrptive Informationが加わることになります。

PDI（Preservation Descriptive Informatiom)の要件（5つ）

• Reference Information:UUIDのような参照情報
• Context Information: Content Informationの関係をMETSに構造情報として記述する
• Provenance Information：データがどんなん出処からできてどんなふうに作成されたかを記述。PREMISの辞書を利用。
• Fixity Information：不変性、チェックサム
• Access Rights Infortmation：アクセス権限、PREMISに記述

このPDIはTransferからAIPが作成する過程で、どんどん情報が加わる。


Archivematicaのシステム概念図↓

https://digitize.library.ubc.ca/digitizers-blog/how-we-digitize-digital-preservation-2/

Archivematicaの画面↓では、左側にmicro serviceというのがあって、各機能でどんな処理をしているかが表示されます。これはingestのときの画面です。

実は、いろいろ沢山メニューを勉強しましたが、全部かけませんでした。
まぁ、あとは各自資料を読むことですね。
今日のOAISの説明でガソリンなしで頑張ってくれたYoさんに感謝！パチパチパチ

===================================
次回は、2019年1月18日（金）です。
１）Archivemaiticaのpreservation planning, Access, Administration の機能
２）Pipelineについて
勉強します〜。皆様よいお年を！

【23】1. ArchivematicaのAppraisal 2. OAISについて

勉強会始まりました〜

今日も見事に雨です。（これは絶対誰かが雨男、雨女に違いない！）

まず、最初はArchimaticaにあるappraisalの機能を使ってみます。今まで一度も使ったことがありません。

マニュアルはここ↓

https://www.archivematica.org/en/docs/archivematica-1.7/#appraisal

主な内容は以下です。

• General description
• Transfers in the Backlog
• Analysis
• File List
• ArchivesSpace Resources
• Adding Files to ArchivesSpace Resources and Starting SIPs
• Arrangement

Archivematicaでのappraisalは、SIPの前にどれをSIPにするかを選別する作業だそうです。なので、まずはtransferして、backlogに入れます。

backlogからUUIDやファイル名を確認して、AppraisalのメニューでUUIDを利用してtransferしたものを検索します。
objectsフォルダにあるファイルの中で、特定のファイルを選んで、ファイルの属性などを分析して、可視化したり、Tagを付けたり、個人情報（PII、credit cardなど）などを識別してくれうようです。
appraisalを行ったあと、SIPを作成しますが、やり方が若干わかりづらいかったです。特に、マニュアルのBacklog paneとArrangement paneの場所と操作方法がわかりにくいので写真を参考にしてください。（あ、ドラックではなくドラッグでした。(；´∀｀)…）

SIPを作成した後、METSを確認したところ、ちゃんとappraisalで選んだものだけのSIPが作成されました。

一応マニュアル通りのことはできましたが、なんのためのTagづけだったのか…よくわかりませんでした。METSを確認したところでも、Tagがどのように反映されたかよくわかりません。appraisalで行ったことが、METSにどう反映されるかについては、もう少し勉強してからですかね。これ以上はペンディング〜　おほほ！　｡ﾟ(ﾟ^Д^ﾟ)ﾟ｡

では、次のテーマに移ります〜
OAIS参照モデルの勉強です！

OAIS（概要）

https://www.dpconline.org/docs/technology-watch-reports/1359-dpctw14-02/file

OAIS概念モデルとArchivematicaのメニューを比較しました。Archievmaticaにある、backlogとappraisalのメニューは、OAIS参照モデルにはありませんが、SIPの前の過程としてArchivematicaでできる固有の機能のようです。

今日は、新しいメンバーや上京したメンバーもいて、かなり真面目な2時間となりました！
（普段は違うかな？　笑）

ではでは、今日はこれで終わります〜

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
次回 12月14日（金）
Archivematicaの今まで使ってないメニュー （Preservation planning, Administration、Storage Service）で遊びます～

OAISを復習してくると、よりわかりやすいと思います。もちろん、時間がなくて勉強できなかったとしても、遠慮なくご参加ください！

【22】AICの作成

こんばんは。

今日も勉強する社会人の夜が始まりました！
今日は東京の道場のほか、京都とロンドンから参加しています〜（ワオ〜）

まず、AtoMの話から〜（^..^）/

今師匠がAtoMメニューの日本語を修正しているとのことです。

まだメニューの和訳が完全ではないので、師匠がそれを修正してくださっています。ArtifectureからAtoMをインストールするだけでは、日本語がまだ完全ではありません。AtoMの中には、日本語化するためのファイルがいくつかありますが、その中で指定されている日本語を直してあげれば、現在の変な日本語訳を変更することができます。しかし、Artifectureで指定したファイルだけでは足りないとのことです。

また、英語に訳語を当てはめるだけでは意味がおかしい場合もあるので、微調整が必要です。

例えば、英語の日本語訳を入れ替えるだけにしてしまうと

英文：A is succeeded by B　

和文：Aによって引き継がれるB

のようになります。

そのため、メニューを見ながら日本語を確認する必要があります。もし、きちんとした日本語訳ができて、それをArtifectureに提供すれば、将来はダウンロードするだけでより完成度の高い日本語版を皆が使えるようになります。（その時を楽しみにしましょう！）

ではでは、今日の本番ですが、ArchivematicaでAICを作成します〜

マニュアルはここ↓

https://www.archivematica.org/en/docs/archivematica-1.7/user-manual/archival-storage/aic/

今日は上記のマニュアル通りやってみることにします！
素直にマニュアル通りに作業を進めると、問題なくAICのを作成する事ができました。ArchivemeticaがあるPCではうまく動かず、途中で別のPCを使うなど、若干手間はかかりましたが、マニュアルに問題がない事の確認ができました。（笑）

なので、AICの作成は、マニュアル通りやってくださいね〜　（これだけ？）


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
次回
Archivematicaの機能でやったことないもので遊んでみます（appraisalとか）。
Archivemeticaの機能とOAISで指定している機能がどのように対応しているかを勉強します。

OAIS（概要）

https://www.dpconline.org/docs/technology-watch-reports/1359-dpctw14-02/file

詳しいやつ

https://public.ccsds.org/pubs/650x0m2.pdf

ArchivematicaとOAIS参照モデルの対応関係（スライド49枚目）
https://www.slideshare.net/Archivematica/digital-preservation-with-archivematica-an-introduction

【21】DIPのアップロード＆CSVでの追記（成功版）

勉強会の日雨が多いのは、ここに雨男がいるからなのかもしれません。(*￣m￣)
今日は、風邪も流行り初めたせいで欠席もあり、少人数で始めます！

前回の話し
AtoMでCSVを再登録するときに、画像がなくなるのは、CSVに出てくるURLの画像を探せないのでは？もしくは再登録する時のオプションのせい？

実験１
CSVのテンプレートにあるdigitalObjectURI項目をdigitalOpjectPathへ変更して登録してみます（こういう方法もあるらしいです）。（usr/…にあるフォルダに、確かに画像ファイルが存在することも確認しました。）登録してみた結果、やはり再登録すると画像が登録されませんでした。

コマンドラインで画像ファイルをよくよくみると、一つの画像ファイルに対して、サムネイルが2つ生成されるようです（もちろんファイル名はすべて異なる）。CSVで再登録する時に入れるファイルは、もとの画像ファイルのURIだけなので、サムネイルは探せないのが当然なのでは？とういう話がでました。

Danさんが教えてくれたのは、サムネイルをregenerateする方法です（前回のブログを参考にしてね）。すべてのサムネイルを再生成するらしい。バックアップを取った際にもサムネイルを再生成する必要があるので、そういうときにDanさんが教えてくれた方法を試す必要があるかもしれません。（今日の作業では、どうも原因が違う気がしたため、試していません。）

このことを総合して考えると、画像がなくなることの原因のもう一つとして、再登録する際にreplaceしているからかもしれないことに気づきました。つまり、追加された部分だけをupdateするのではなく、すべてをreplaceしてしまうので、もとの画像とのつながりが保持できないのでは？ということです。


ここで再登録する再のオプションをupdateにして、実験します。
すべての実験では、以下の作業は同じです。

1. ArchivemeticaでDIPを作成
2. AtoMのあるフォンドに目かけてDIPをアップロード
3. CSVを出力
4. reference codeの列は不要なので削除、第二条件を合わせる
5. 第一条件と他のどこかを追記する

実験２
update matches and ...のオプションにして、LegacyIDとCSVの名前を決めて、再登録します。前の実験は、replace してしまっているので画像がなくなっているけど、今回のオプションでは画像が残るのではないかという推測です。

結果：画像がちゃんと残って追記できました。


実験３
今度は追記成功したCSVを出力して、第一条件をあわせて、第二条件を変更してupdateがちゃんとできるかを確認します。title名だけを変更して、update matches and ...　オプションにチェックを入れて登録してみます。

問題：一つだけtitleが変更されませんでした。
原因：５つのデータの中で、２つのidentifierが重複していました。更新されなかった１つのデータは、identifierを直して何度登録しても更新に失敗しました。
結果：一回間違えた操作をすると更新がうまくできなくなるので、注意が必要かもしれません。


実験４
実験３を正しく再度試します。今回は、DIPを作成してAtoMへアップロードする手順は省略してAtoMだけで試します。第一条件をあわせて、第二条件を変更して追記ができるかやってみます。この作業は、すでに第一条件（Legacy ID, CSV名）が決まっていることが前提です。

問題：何故かデータが新たに作成されました。
推測：CSVを登録する再に、作業中のCSVを開いたままやっているけど、問題ないか？システムでは作業中のCSVがそのまま登録されるということはなんか変で、何かしら区別をつけるはずという推測で（つまり、CSV名が同じではないので追記されてしまう）、CSVを閉じてから再登録してみます。
結果：新しく追加されず、ちゃんと追記されました。やはり、CSVを開いたまま同一ファイルを登録することは影響があるようです。


今日のまとめ

• LegacyIDはCSVを登録したときに登録される。なので、DIPをアップロードしただけではLegacyIDはAtoMに登録されない。
• 第二条件をあわせて、LegacyID， CSV名を決めて、update matches and...のオプションでCSVを登録する。このときのIDとCSV名はきちんと保存管理する必要がある。
• 次回の追記作業は、このCSVファイルを利用して行う。CSVをAtoMからexportする必要はない。（exportしたものを使う場合は、referece code例が追加されているので削除し、Legacy ID, CSV名もexport時のものは削除して、元のファイルに一致させてから使う必要がある。）

気づいた注意点

• CSVは開いたままでもAtoMに登録することができるが、どうもエラーの原因になっているよう。必ず閉じてから登録する。
• 第一条件、第二条件が矛盾る操作をしてしまうと、データが狂って予想以外の動作をする可能性がある（今回は、identifierの重複でデータがおかしくなりました）ので、注意する。
• AtoMは目録の公開用なので、登録したCSVの管理や、LegacyIDの管理は組織でやらなければならない。CSVは一回登録したら名前を変えないようにする（更新の時には、古いバージョンの方の名前を変えるなど）。

原因不明のエラー
ArchivemeticaからAtoMの階層情報を読み込めず、edit metadataから階層設定ができない現象。以前にも同じことが起こって急に直ったのですが、今回も同様。原因不明です。


まだ残った疑問
CSVをexportした再に出てくるLegacyID項目の番号（本当のLegacyIDではない）がなぜ必要かがわからない。


今日はなんとなく結論を導き出すことができました。結構色々遠回りもしましたが、それがあって今日の結論に至ったと思います。とういうことで、今日は割と効率よく作業を進めることができました！
ハッピー　v(^o^ )ー~) ニヤ


=======================
次回
AICについて勉強します。
実務を考えながらユーザーマニュアルを作成するステップに進みます〜　イェーイ～

【20】AtoMの画像を復活させる

雨です。最近道場の日には雨が多い気がします。眠くて帰りがちょっとめんどくさい日ですが、なんとか頑張りましょう！

今日のミッションは、 AtoMのGoogleユーザーフォーラムへの質問に対する答えについて考えます。今までやってきた作業についてArtefectualの担当者（Danさん）へ質問をしました。その質問と答えは以下をご覧ください。
https://groups.google.com/forum/#!topic/ica-atom-users/OWFFysVAdnk

質問と答えを簡単に要約するとこれ↓です。

質問１）
DIP をAtoMに入れたらターゲットにしたトップレベル（Fond)以下の記述がないので、それを CSVで追記しようとしたら、 追記されず新しいものができてしまった。追記する方法は？

答え１）
現状では無理。工夫すればできるかも。事例としてArchives Canada、British Columbia Archivesでは、複数のCSVを利用して階層記述を更新している。将来的には、DIPをAtoMの階層記述にそのまま当てはめることができるようになる。

質問２）
ignore match create new... （後記：実はこれはdelete matches and replace recordsの間違いです）のオプションで記述を入れ替えたら成功したが、DIPのサムネイルの画像が消えてしまった。どうすれば良い？

答え２）
（ 画像を入れる方法をコマンドで教えてもらいました。以下を参照）
https://groups.google.com/forum/#!topic/ica-atom-users/OWFFysVAdnk


とういうことで、今日は答え２のコマンド操作をやってみます。画像が消えた場合の対処方法を考えます。


【今日の作業】

1. AtoMの環境設定： ISAD(G)の必須項目＋repositoryにデータを入れておく 。
2. ArchivematicaからDIPを作ります。（今回はobjectを２つ入れます）
3. AtoMのslugはmatica-to-atom
4. DIPをこのslugに目かけて入れます。
   今日は、なぜかArchivematicaで生成したDIPのAtoMへのUploadがうまく行きません。今日AtoMのUbuntuを更新しているが、もしかしてそれが原因か？ ふむふむ…わからん。 ここで、例の時間です。ぱらぱぱんぱん〜ぱらぱぱんぱん〜ぱらぱぱぱ〜（5分、いや３分 クッキングです。笑）
5. やっと原因判明！qtSwordPluginが動いてなかったことが判明しました。以前も同じことで悩みましたね。（笑）AtoMを再インストールした際には、必ずSword pluginにチェックを入れることを忘れないようにしましょう。
6. AtoMに無事DIPが登録されたので、次に進みます。（やっとここからが本番です！）
   とりあえず、AtoMに記述をCSVを利用して追記します。以前実験したように、AtoMからexportしたCSVの第2条件をあわせてignore mathces and create new…のオプションにチェックをいれてフォンドを書き換えます。
   
   ここでまた…　ぱらぱぱんぱん〜〜ぱらぱぱんぱん〜ぱらぱぱぱぱぱぱぱぱ〜┌(=^‥^=)┘♪└(=^‥^=)┐♪
   
   実は、ここで追記がうまく行かず、大分時間を費やしてしまいました。やっと気づいたのは、AtoMでimportする際のオプションは、ignore mathces and create newではなく、delete matches and replace records…だったのです。(；ﾟДﾟ)
7. その後、実験を続けていましたが、途中で画像がうまく登録されない現象の種類を色々試したりして、時間切れになってしまいました。

結局今日は、答え２でArtefectualのDanさんから教えてもらったSymphonyのコマンドを試してみるまではたどり着きませんでした。ヒューーーー(TдT) ｳｩ…

※後日追記

AtoMのコマンドラインをまとめたスライド

https://www.slideshare.net/accesstomemory/atoms-command-line-tasks-an-introduction

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

ということで次回は、答え２のコマンドをやります〜

【19】AtoMへのArchivematicaのDublin coreメタデータをアップロード

道場はじまりました〜

今日は始まる前から充電満点にして行きます。えへへ〜

今日もAtoMへのDIPのアップロード、そして、Archival Descriptionを追記する作業をやります。（これ、いつ終わるのかな〜〜〜）

まず、DIPをAtoMに入れて、LegacyIDをつけてみます。

今日入れるのは、shumuta0824（５objects)のフォルダーです。

では、DIPを作ります〜

（ぱらぱぱんぱん〜ぱらぱぱんぱん〜ぱぱらぱぱぱぱぱ　わかりました？キューピーの5分クッキングです。）

AtoMのフォンドのslugに目かけてDIPをアップロードします。
予定通りシリーズが2つ追加されました。

次は入れたDIPをCSVでexportします。

ちょっと待った！

ここで、いつものように議論が始まりました。

”前回は第２条件をあわせて書き換えてしまったけど、やはりフォンドを消して再作成するのはどうかと思う…今回は書き換えるのではなく、追記したい！”

（やれやれ…前回の作業で一旦落ち着いたはずですが、２週間後、気持ちが変わったらしいです。(￣▽￣;)アハハ…）

そこで、ArchivematicaのDublin coreのメタデータをAtoMに継承させる方法をやってみます。
マニュアルはこちら↓

https://www.archivematica.org/en/docs/archivematica-1.7/user-manual/transfer/import-metadata/#metadata-csv

【実験】

1. Archivematicaで metadata.csvを作成して、objectと一緒にimportします。今回は、画像１ファイル、ワード１ファイルの2つのobjectを、DCのメタデータが入っているCSVと一緒にArchivemeticaに入れます。この時はCSVのcarriage returnを消してあげます。今回はSakura Editorを使います。Sakura EditorからCSVを開けて改行コードLF(Unix)に設定して、別名で保存する。これでゴミがなくなります。
2. CSVファイルの名前はmetadata.csvにする。（必須）
3. フォルダの構造は以下のように揃えておきます。
   metadata>submissionDocumetation（ここにCSVを入れる）
   objects＞画像フォルダと、ワードフォルダが一個ずつ
   最終的には、metadataフォルダとobjectsフォルダが2つ見える状態になります。
4. この状態で、ArchivematicaからDipを作成します。この時にフォルダのアクセス権限を変更してあげないとAtoMからフォルダが見えません。
5. DIPを作成する際に、このセットになっているフォルダをarrangementに入れるとmetadataフォルダは見えず、objectsだけが見えます（なぜ？）が、
6. そのまま進んで、作成したDIPをAtoMにアップロードします。
7. DCの情報が反映されました！（反映されたかは、AtoMのCSVをexportして確認しましょう。）

【今日の結論】

ArchievmaticaのDCmetadataが反映されることが確認できました。なので今まで悩んでいたArchival Descriptionの追記はこの方法でできることがわかりました〜　パチパチパチ！！




===============================

次回

一度システムをきれいにします。

AtoMにCSVをimportした時に画像が消える問題を検討します！

【18】AtoMへCSVで追記

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

前回の作業を思い出すのにおよそ30分が経過。（ほら、大丈夫かい？）

でもなかなか次のステップがわからず（笑）、前回のブログに書いてある次回の作業を素直にまずやってみることになりました。

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

つまり、
１）ArchivemeticaからAtoMにDipをいれる
２）AtoMからCSVをexport
３）そのcsvをAtoMにimport
４）この時、注意するオプション

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

です。

【実験１】

AtoMのターゲットfonds：shumutam（シリーズ１個）

ここに、Archivemeticaから作成したDIPを、アップロード。ここまではいつもの通りで、ちゃんとshumutamにシリーズが反映されました。

なので、CSVをexportします〜

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

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

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

【実験２】

そこで、第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（第２条件）を合わせて、Legacy IDとsource file name（第一条件）は我々が決める。
   今日の実験では、フォンドのlegacy IDを一致させましたが、結局最初DIPを入れる際には、各レポジトリで管理するlegacy IDをここで初めて指定するのが一般的だと考えられるので、upload時にデータを同定する第１条件は考えず、第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してみましたが、やはり失敗しました。

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

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

次回

今日の復習（欠席した人のためにですよ！皆来て～）

画像が行方不明になる理由を考えます。

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が２つ存在する。
   　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 

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

【実験１】
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をそのまま使う

atomにおけるcsvインポート（アップデート）について

マニュアルより

• legacy idに関する記述が以下にあり
• https://www.accesstomemory.org/en/docs/2.4/user-manual/import-export/csv-import/#legacy-id-mapping-dealing-with-hierarchical-data-in-a-csv

• 上のリンク先の第2パラグラフに、「legacy ID」は「source_id」という名前でデータベースに登録されます。確認したい人はコマンドラインか、phpMyAdmin等のツールを使ってね、と記述あり。

• atomのインタフェースからは確認できない模様
• ということで、csvでインポートする際のlegacy IDは覚えておく必要あり（忘れた場合の対処法は後述）
• やはり、登録時のlegacy IDをキーとして、Update時におけるマッチ判定をしていそう
• phpMyAdmin等のツールを使ってデータベースを覗けば確認できるということで、確認してみた。

• 上記はサンプルデータ（legacy IDが「1」と「2」）をインポートしてみた結果
• 確かにlegacy IDの値はsource_idとして登録されており、またエクスポート時に出現するjob idに基づいて与えられるid（4XXや5XX）は、target_idとして格納されている
• legacy IDを忘れてしまっても、上記のテーブルを参照すれば、再現可能

検証環境（Amazon AWS）

試行錯誤の内容
１．「Example_information_objects_isad-2.3.csv」をインポート
  a. 2行（1フォンド、1アイテム）
  b. legacy IDは「1」と「2」
  c.

2. 1をAtoMからエクスポート
  a. ファイル名は「isad_0000000001.csv」
  b. 2行（1フォンド、1アイテム）aaaa
  c. legacy IDは「446」「469」

3. 2でエクスポートしたファイルを「Example_information_objects_isad-2.3.csv」にRenameしてインポート
  a. ファイル名は「Example_information_objects_isad-2.3.csv」
  b. 2行（1フォンド、1アイテム）
  c. legacy IDは「446」「469」
  d. オプションは「create」
  e. 結果、2行（1フォンド、1アイテム）が新規に登録される
  f.
  g. 【わかったこと】legacy IDがsource_idとして登録される。

4.（質問への回答）source_idが469（target_id：497）の親Fondsを他のFondsにatomのインタフェース上で変更
  a. 結果、parentIdのみ変更される
  b.
  c.【わかったこと】親子関係が変わっても、source_id（legacy id）やtarget_idは変わらない => atomのUI上で親子関係を変更しても問題なさそう

5. 1でインポートしたcsvを「name_changed.csv」に変更し、インポート
  a. ファイル名は「name_changed.csv」
  b. 2行（1フォンド、1アイテム）
  c. legacy IDは「1」「2」
  d. オプションは「create」
  e. 結果、2行（1フォンド、1アイテム）が新規に登録される
  f.
  g.【わかったこと】legacy idは重複し得る。

6. 5のcsvのタイトルを変更してUpdate
  a. 

  b. ファイル名は「name_changed.csv」
  c. 2行（1フォンド、1アイテム）
  d. legacy IDは「1」「2」
  e. タイトルは「abd」「def」
  f. オプションは「update」
  g. 結果、 5で登録された2行（1フォンド、1アイテム）のみ更新される
  h.


  i.【わかったこと】legacy idが重複した場合はsource_nameが一致するもののみアップデートされる。


ここまでの考え
csv export時のlegacy ID（= keymapテーブルにおけるtarget_id）は意味なさそう
=> これがupdate時のマッチング判定には使われなさそう。やはり import時のlegacy ID（= keymapテーブルにおけるsource_id）が重要そう。
引き続き要検討です。

7. 3のcsvのファイル名とタイトルを変更してUpdate
  a.


  b. ファイル名は「名前変更.csv」
  c. 2行（1フォンド、1アイテム）
  d. legacy IDは「446」「469」
  e. タイトルは「source_nameとtitleを変えてみた。legacy idは登録時のものを参照。」「source_nameとtitleを変えてみた。legacy idは登録時のものを参照。」
  f. オプションは「update」
  g. 結果、 新たに2行（1フォンド、1アイテム）が追加される
  h.
  i. 【わかったこと】legacy idが一致しても、source nameかつtitleが違う場合にはマッチ判定されない。
       ①第一条件：legacy idは一致するが、source nameが異なるため、第一条件の
          マッチ判定は通らない
       ②第二条件：title, repository name, identifierの一致を見るが、titleが異なるため
          マッチ判定は通らない
       ③結果：新規に追加される

8. 7のcsvをベースとして、ファイル名（source_name）とlegacy id（source_id）を維持した上で、タイトルのみを変更してみた
  a. ファイル名は「名前変更.csv」
  b. 2行（1フォンド、1アイテム）
  c. legacy IDは「446」「469」
  d. タイトルは「Legacy idとsource_nameを維持した上で、titleだけ変えてみた
     fonds.」「Legacy idとsource_nameを維持した上で、titleだけ変えてみたitem.」
  e.オプションは「update」
  f. 結果、7でインポートした2つのタイトルが更新された。
  g. わかったこと】タイトル（or repository or identifier）を変更したい場合には、
      source_id（インポート時のlegacy id）とsource_name（csvファイル名）を揃える
      必要ありそう

(END)

【16】DIPをAtoMへ登録してからCSVを利用してupdate

風が強くて華奢な女子大生は飛ばされるのではないかと思える天気でしたが、横に増えつつある中年女性は飛ばされる心配もなく、無事道場に着きました。（@^^@)

ですが、今日は参加者が少ない。（皆どうしたんだよ〜〜）

でも、いつものようにガソリンを入れて始めます！

皆を待ちながらしばし議論〜

archivemeticaからAtoMまでの流れを今一度説明するYo!
（ホワイトボードに何か書くYo!)

やはり、exportした時のLegacy IDは、データ更新のときにはあまり気にしないで、もとのLegacy IDを管理するのが正しいのではという話をしました。

そうすると…

DIPにはLegacy IDがない。どうするんだ？　

これがずっと前から悩んでいた問題でした。

さてさて、いつものように結論はなし！
問題を再確認したところで次に進みます。

===============================

今日は久しぶりにArchivemeticaからDIPを作ります！

久しぶりなので、やはりエラーがでました。

我々の期待を裏切らない機械です。

でもなんとかDIPをAtoMに入れました。

そのCSVをexportします。

Legacy IDが付与されて出てきましたが、このLegacy IDを利用して
記述をupdateすると新しくデータが登録されてしまいます。

だから〜DIPで入れたもののLegacy IDを確認するしかないってこと？
（これは面倒だ・・・）

少し紛らわしいので、ここでは元のLegacyIDを元（もと）ちゃん、export時に出てくるLegacy IDを偽ちゃんと呼ぶことにしましょう。

ここで、カッコいいエンジニアの出番です！　シャキ─（σ｀・∀・´）σ

コマンドモードから、keymapテーブルを探し、その中身を確認します。
そこには、source_id, target_id, source_nameが記録されています。

なんと！keymapテーブルでは、偽ちゃんがtarget_idになっていて、それに対応するsource_id（これが元ちゃん）が確認できました。DIPで入れたものでも、元ちゃんが存在するのです。updateに使うLegacy IDは、もちろんここにある元ちゃんということになるのでしょうか。

ではでは、確認した元ちゃんをCSVのLegacy IDとして入力し、タイトルだけを変えてみます。そしてupdate～～～

そうすると、なんとうまくupdateされました！
（ここまでの道のりは長かった…　ITに弱い人間が生きていくのは大変です…）

ここでもう一つ発見！
偽ちゃんは意味のないように思えましたし、なぜそんなものが出てくるのか、ずっと疑問でした。まぎらわしいし、なぜそんなことをする必要があるのか…
予想ではありますが、この偽ちゃんを利用するれば、大量のデータを更新できそうな気がしました。つまり、CSVの偽ちゃんに対応する元ちゃんを探して、自動で入れ替えるプログラムを組めば、機械で処理ができます。

また、色々実験した結果、元ちゃんとsource_nameは重複して存在し得ることがわかりました。しかし、target_idは重複しません。なのでtarget_idがデータベース上で、唯一の識別idとして機能しているのはと思われます。

色々実験した結果、元ちゃんと偽ちゃんに関する理解は少し深まりました。
道場での実験に加えて、メンバーによる個別実験が行われました。
これについては以下の記事を参考にしてください。
https://irisawadojo.blogspot.com/2018/08/atomcsv.html
http://irisawadojo.blogspot.com/2018/07/atomcsvupdate.html

最終的に、わかったことを以下簡単に整理します。

1. KeymapにはLegacy IDがsource_idとして登録される。
2. 親子関係が変わっても、source_idとtarget_idは変わらない。
3. Legacy IDは重複し得る。
4. まったく同じファイルを2回登録すると、target_idのみ異なる。
5. まったく同じファイルを登録した場合は、最新のものが更新される。
6. Legacy IDが重複した場合、source nameが一致するもののみアップデートされる。
7. CSV export時のLegacy ID（kepmapテーブルにおけるtarget_idは更新時のマッチング判定にはつかわれなさそう。（ほかに、Legacy IDが異なるが同じものであることの判定や、Legacy IDとsource_nameが同一であるが異なるものであることの判定などに使われている？）

今日は通常より短めの作業でしたが、一歩進みましたので良い気分で終わります！

• ｡(￣∇￣*)oｸﾞｯﾄﾞ!!d(*￣∇￣)｡

========================
皆気分がよくて、次回やること話すの忘れました。（^^;)

AtoMのCSVによるupdate条件の実験

CSVを利用して、すでにある記述をupdateする際のマッチング条件

・第一条件：Legacy IDとsource_nameがマッチングすればupdate

・第二条件：第一条件を満足しなければ、tilte, repository, identifierがマッチングすればupdate

以下は実験による、kepmapテーブルの変化

kepmapテーブルでは、Legacy ID はsource_idと同一で、target_idはexport時に自動で付与されて出てくるLegacy IDと同一。

実験①
画面キャプチャーなし

実験②
画面キャプチャーなし

実験③
Legacy ID、source_nameが異なり、title、repository, identifierが同じ場合
データは問題なく更新され、keymapには新しいsource_idに元のtarget_idが付与された。

以下keymapテーブルのキャプチャー画面（phpMyAdminを利用）

※同じファイルを2回createした時
Source_idは同一で、target_idが新しく付与される。
タイトルだけを変えてデータを更新してみると、後で登録したフォンド（target_idが947,962）だけが更新された。

以上

ふたたびワークフロー問題

すみません。なんだかやはりこの問題が気になっちゃって。
ちょっと古いArchivematicaのフローを見てみると、やはりSIP段階でDCメタデータを付与しています。

https://wiki.archivematica.org/images/9/96/Archivematica-0.6-WorkflowInstructions-v3.pdf

たしかに、Archivematicaを通さないとウィルスなどチェックできないので、micro-serviceを全部通しちゃって、DIPをAtoMにuploadしちゃえば、ArchivematicaのGUIよりはずっとましです。そしてAtoMにのせてしまうと、今度はAtoMのGUIでは、アイテムレベルを一つ一つ記述するのはたいへん。そこでいったんexportして、記述し直して再インポートする、というフローを今実現しようとしているわけですよね。で、そのうえでもう一回その全体をArchivematicaに入れ直せば、Archivematicaに保存用のAIPとして大事に保存されるのは、記述メタデータつきのよいデータと言うことになる。それもわかるんですが、でもなんだか妙にムダが多いようにも思います。

デジタルオブジェクトは基本的にフラットにArchivematicaには入っていくわけで、それをDCでとりあえず最低限記述しておく（つまりアイテムのタイトルなどはついている）。それをSIP段階で編成すれば、METS上で、Structmapでしたっけ、あそこのlogicalにその編成が反映される。そうすればAtoM上には構造を持ったデータとして入っていく以上、あとはフォンドやシリーズなど上位レベルの記述を充実させるだけですから、それはGUIでもいい、という感じなのではないかなーと。なんか、その方が楽じゃないですかね。

でもやっぱり違うのかなー。悩ましいなー。

でもやっぱり（しつこいですね（笑））これでもpre-ingestでdescriptive metadataつけてる。

https://inforum.library.utoronto.ca/sites/inforum.library.utoronto.ca/files/course_files/winter2018-archivematica-slides.pdf

CCAのTim Walshも、当初BitCuratorでdescriptionつけたりもしていたようですね。
https://www.bitarchivist.net/blog/2017-05-01-buf2017/

ではまた7/5に！

【15】AtoMの再インストール

今日はストレス解消から始めます！
つまり、前回狂ったAtoMを壊すぞ〜〜〜〜　イェ〜

設定は残したまま（？）、AtoMとデータベースをすべて削除します。
その後、
１）AtoMを再インストール
２）データベースをクリエートします。
https://www.accesstomemory.org/ko/docs/2.4/admin-manual/installation/linux/ubuntu-xenial/

でも、削除するのはエンターを押したらあっという間で、全然ストレス解消になりませんでした。　^^;

AtoMの設定が完了したら以下の設定を追加します。
１）言語に日本語を追加
２）pluginを全部インストール

まず、exampleのCSVを入れて動作を確認します。
ubuntuのマシン（サーバー）でexportします。
exportしたもののタイトルだけを変更して、変更が反映されるか試します。

ここで、また前回からの続きの問題にぶつかりました。
exportしたCSVへ追記を行う際にもとのフォンドを同定する条件に関する問題です。

どうも、Legacy IDは複数あるという話が。（え？）
なぜかというと、import時に設定したLegacyIDと、export時に出てくるLagacyIDが異なることに気づいたのです。どうもexport時のLegacyIDはjob番号のよう。
しかし、LegacyIDは所蔵先が入れるものでコントロールするものじゃなかったっけ？

ここで、永遠と続く実験の世界に入り込んでしまったわけでして…（ーー；）
若干場当たり的な実験が続きますが、お付き合いくださいまし。

１）
CSVのLagacyIDに3000を入れてimportしてみる。
それをexportして、3000が残っているかを確認します。
3000は残ってない。
やはりexportしたCSVのLegacyIDはAtoMのjob番号が付与されているよう。

２）
最初importしたCSV（マッチング条件LegacyID、source nameを満足）のタイトルを変えてから再度importしてみる。
結果が…思いつかない…　T..T

３）
exportしたもののタイトルを変えて、delete matching and replace... をオプションにすると、変更が反映された。しかし、それをexportすると、legacyIDが変更された。これは完全に削除してから新しく書き換えているので、LagacyIDも新しいjob番号が付与された模様。deleteは、親（Fond)が合えば下は自動で全部消える設定になっている(マニュアルにそう書いてあるよ〜）。

４）
exportしたCSVのマッチングさせるための2つの条件と関係ない項目を変更して、もう一度実験。タイトルはマッチするかの判断の2番目の条件になっているので、そこが変わるとマッチしてないと判断している可能性があるように思われる。
予感は的中した。アップデートに成功。
つまり、タイトルを判断基準にしているようだ。

５）
６）
・
・
・

何度か実験は続きましたが、条件をどう変更したか、結果がどうなったか覚えられなくなりました。（頭の限界です〜　(^^)a　）

しかし、今日の発見は、マッチングの条件
１）legacy ID, source name
２）title, identifier, repository
の考えられる組み合わせで実験してみると、DIPへの追記のコツがわかりそうだと言うことでした。

現在、CSVに追記してimportした時に該当部分が変更されるのではなく、変なアイテムが追加されちゃったり、階層が狂って追加されたりする現象をなくすためにも、これは確認する価値があるかもしれません。

ということで、今日はここまでです。
ガソリンも2倍注入して、かなり遅くなりました。
若干くたびれたけど、次回も頑張りましょうね。

========================================
次回は、引き続き謎解きに挑戦し、コツが分かったらDIPをAtoMへuploadします〜

【14】 CSVでAtoMへ色々 importする。

今日は足元悪い中、ご来場いただきありがとうございます〜
雨にも負けず、道場は始まります。


★前回CSVエクスポート空っぽだった理由★
現在のAtoMのCultureは、日本語設定になっている。
前回入れたものはシリーズを英語（En）設定にしてしまった。
cultureが英語ではない場合のバグが３つ報告されえている。
これが原因だと思われる。
https://projects.artefactual.com/issues/12155

確実にCSVをエクスポートできるのはやはりEnで設定した場合。
多言語対応と言っている割には、実際そうでもない気がしてきました。（^^;）

ということで 、環境を英語に変えてもう一度チャレンジします。
その前に、とりあえずガソリン入れましょうか〜〜〜　（ニヤリ〜）

その間、先生に設定を直してもらいます。（なんという生徒たちなんだ！）

作業内容を優しく説明してくださいましたが、半分理解不能なので、われわれはガソリンを入れて、見守ります！cultureの変更には、Timezoneも変更します。（America/Vancouverに設定）

ちょんちょんちゃん　ちょんちょんちゃん〜　♪(ｃ=￣∇￣=)ｃ" （作業中）

では、cultureを英語に変更したので、CSVを importして、exportします。

結果は、成功！！（やはりculutureの問題でした。）

この状態で、いまや問題児に変わってしまったフォンドConimal2をexportしてみます。

ダウンロードしたCSVに追記して、importします。

ここで操作を若干見逃し「重複を 無視する」をチェックしてなかったので、シリーズとかアイテムとか重複して全部二重に入力されちゃいました。

でも、これどうやって消すんでしたっけ？（ふむ…）

ここでついに道場には派閥が現れました。

実験組、議論組、ボカン〜組（私はここです）

（しばし議論が飛び交う）

では、 もう一度画面に集中してもらいます。

ボカン～としている間、実験組がいろいろいじっている間に、CSVをimportができなくなりました。

シンプルなデータで、エラーが出そうな内容は何もないのに…

AtoMは気まぐれです。（T,.T）

単純なフォンド、シリーズ、アイテムのCSVを入れているのだけど、なぜか階層が作成されず、全部ばらばらでプラットでimportされました。 何度やっても同じ…

（再起動を〜〜〜　(ﾉﾟοﾟ)ﾉ ｵｵｵｵｫｫｫｫｫｫ-　京都からの叫びです。）

どうもFondsが認識されないのではないかという意見が 。

Fondsの階層があってないようなエラーが出ているので、Fondsの表記が気になる。

なぜかTaxonomyも狂っていて、Fondsがいくつもあるので、整理してみます。

これはすでに入力されているデータに影響があるかもしれないので、注意が必要。

★ここでTaxanomyの偽物を見極めるコツ★

TaxanomyのLevel of DescriptionにあるFondsとか、seriesとかが、たくさん生成されてしまった場合はいらないものを削除できます。FondsとかをクリックするとURLが表示されますが、偽物にはURLの最後が「Fonds-2」のように番号が付いた名前になっている。番号がないものがほんものです。偽物は消しましょう。

もう一度importをチャレンジしますが、失敗。Taxonomyの問題じゃないかもです。

ではexampleCSVファイルを入れてみます。これは、テスト用で提供されているものだからimportされないと本当におかしい。

ちゃじゃん〜

でも失敗。しかも関係のないconimalのdigital objectが 入力された。なぜ？　


おかしい…今日cultureを変えたから？
うん？　これはまさかculture ショック？　（￣□￣；）！！

これはもうAtoM自体が壊れたような感じです。
今日は頑張ってももう何もできない・・・


★こんな状態でも一つ発見はありました！★
例えばitemsが 100件ほど間違った場合、 itemsゼロのfondsを「delete matches and replace・・・」にチェックを入れてimportします。そうすると、 fondsがマッチしているので全部消されたあと、入力したfondsにリプレースされる。つまり、100個のitemsが消えます。


とういうことで、カルチャーショックを受けて今日は終わります！
機械を相手にする作業って大変です。
今日のAtoMはさよならして、次回は生まれ変わったAtoMと作業します。

皆気を付けて帰ってね〜

====================================
次回はAtoMのインストールから復習します。
あたらしいAtoMの環境で、今回出たエラーの解決を再度チャレンジします。
時間があれば、AICを勉強します！

【13】 AtoMのCSV→Archival Description追記→DIPを追加

今日はスカイプメンバーなしでお送りします。
一人は京都でレクチャー中のため欠席、一人は道場にリアルで登場です～


前回はどこまでやったっけ？
AtoMからエクスポートしたCSVを利用して、Archival Descriptionの追記ができることまで確認しました。はい、そうです。
（皆記憶が曖昧で、ここまで思い出すのに結構時間がかかりました。歳を取るとしかたないですね～）

とういうことで、今日は前回のおさらいをしつつ、追記されたFondをターゲットにして、ArchivemeticaからデジタルオブジェクトのDIPを生成し、AtoMへ流すことを目指します！

===================================================

今回使うのは　testtest.csv　です。

まずは、AtoMにあるtesttest.csvから登録したFondのデータをCSVでエクスポートする。
そこに情報を追記して再インポートしよう。


+++ Tips +++++++++++++++++++++++++++++++++++++++++++
Exportするときは、普通にexportを押すと全リストが出てしまいます。必要なものはクリップマークをクリックしたあと、「クリップボードに行く」をクリックすれば、クリップボードに入れたものだけをexportできる。途中にチェックを入れるところが3つあるので（これでわかるのかな？　＾＾；）、それを全部チェックしてからエクスポートする。
++++++++++++++++++++++++++++++++++++++++++++++++++

追記する際には、CSVのLegacyID、Source NameをターゲットFondに合わせる。
Source NameはCSVファイル名です。

では、インポート！えいっ　＝＝＝＝＝＞　～（＋。。＋）～　僕、AtoM


しかし、なぜか追記に失敗しました。

原因がわからず、しばし議論…



では、CSVを同定する際に使われる条件を一つずつつぶして行こうという話になりました。
追記の際に、比較するのは？（覚えていますか？）

１）　LegacyID, Source Name
２）　１）がだめだったら、title, repository, identifierを比較する

１）を合わせても追記に失敗したので、原因がわからないのは当然だよね～
（やっぱり、機械はくせものだ！にゃぁ～疲れる～　ヾ(｡>﹏<｡)ﾉﾞ　）

原因だとは思わないが、ほかに心当たりもないため、２）の条件を試してみる。
まず、title, repository, identifierを登録されているフォンドの情報と合わせてからインポート。
そしたら、なんと追記に成功した。

CSVのデータ：　title=Conimal2、repository=Example Repository、 identifier=F1
AtoMのデータ：　title=Conimal2、repository=Repository、identifier=空白

これを、両方以下に統一させてインポートしたら、追記に成功した。
title=Conimal2、repository=Repository、identifier=F1



ふむ。。。。でもこれは原因にならないはず。。。
逆になんで成功したんだ。。。という意見が。

そこで、他のもためしてみる。
つまり、CSVとAtoMのターゲットFondのデータを異なるように設定してインポートしてみる。

（まさに、実験だ！　ちょっと科学者ぽくなってないわれわれ。(￣ｰ￣)ﾆﾔ... 　）


１）CSVのidentifierだけを異なるように設定　→　成功
２）repositoryだけを異なるように設定　→　成功
３）titleだけを異なるように設定　→　成功


ほら！なんの関係もないじゃん～～～


ということで、今までの実験はなかったことにして、次にすすむ。
（おいおい、開き直ったぞ。）

というか、一応次を進めてみます。

AtoMのConimal2をターゲットにして、デジタルオブジェクト（画像２個、PDF１個、DOCX１個）をArchivematicaにTransfer→Ingest→create SIP→して、DIPを作成する。このDIPをAtoMのConimal2のFondへ流し込む。

えいっ！　よっし！
DIPの入力に成功しました。（パチパチパチ）


そして、AtoMからConimal2のCSVをエクスポートしてみます。
Job management（だったけ？）へ行って、ファイルをダウンロードして中身を確認したところ、AtoMにある記述が全て出力されていないとんでもない状況が判明。フォンドのタイトルもAtoMには入っているけど、CSVにはない。なぜ？(# ﾟДﾟ)つ〃



ここで突然皆飽きたのか、疲れたのか急にいなくなった。
トイレ？ガソリン取りに行った？終わり？


でも、ここでもなぜCSVの記述が完全ではないかはさておき、もう少しがんばります。
（また開き直ったぞ）

今度はFondのタイトルを、Conimal3にして（フォンド名が変わるかどうかを確認するため）、uploadしちゃえ〜〜〜

それで、importします〜 えいっ！

でも、import失敗した。

なぜ〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

後日追記
なぜならエラー・チケットだからさ！

CSV export issues in cultures not in English

https://projects.artefactual.com/issues/12155

なんか同じ作業をなんどもしているような…
まだまだ科学者には近づけませんぬ。

ということで、今日は以上！



＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
次回は

今日は、AtoMでLegacy IDとsource nameが一致してもインポートができない謎を解けなかった。
なので次回は、DIPを流し込んだAtoMのFondデータをエクスポートして、記述をCSVで更新する作業をもう一度やります～

【12】AtoMからエクスポートしたCSVに追記してインポート

今日はイライラする中年女性2名とお送りします〜　（ーー；）
それに、勉強会始まる前からガソリンを入れたので、ちゃんと走ることを祈ります！（笑）

今日の目標は、AtoMからエクポートしたCSVに追記をしてインポートすることです！
関連するマニュアルはここ↓
https://www.accesstomemory.org/en/docs/2.4/user-manual/import-export/csv-import/#update-existing-descriptions-via-csv-import

====================================

おさらい〜〜
前回はarchivemeticaのDIPをそのままAtoMへConimalフォンドとして入力した。そのため、アーカイバル記述がない状態。今日はその記述をCSVで追記する。今までは、フォンドへ追記する際には、既存のデータをすべて空にしてからではないといけなかったが（追記ではなく上書きになるということかな）、空にしなくても変更になった部分だけをCSVで追記できるようになった。これは最近追加された機能なので、やった人はあまりないと思う。

本番に戻ります〜

まずConimalのデータをAtoMからエクスポートしましょう。
Manage jobsからConimal（前回入力したフォンド）のCSVをダウンロードする。

あれ？
ダウンロードをするとすべてのデータのCSVがエクスポートされた。


（一時期メモ不能・・・・なにやっているの皆〜〜〜　＠..@ ）

なんとか状況を把握したので、再開します。

本来は、Conimalフォンドのedit > administrative areaからsource nameの部分に元となるCSVのファイル名が表示されるはずだが、Conimalにはそれがなかった。
おそらくCSVを利用してデータ入力したのではなく、ArchivemeticaからDIPを入力したからかも。
（でもSource nameがないのはおかしいのでは？　ーーa ）


ではでは、CSVを利用してデータを入力して、source nameが現れるかやってみよう。

まず、エクスポートしたConimalのCR（Carriage Return）を消す。
方法は色々あるが、以下の2つでやってみた。
①　unbuntuで新しい名前でCSVを保存し直すとCRが削除される。（へ〜コマンド打たなくてもいいんだ〜）
②　CR削除してくれるアプリを利用して削除する。UTF-8へ変換しつつ、改行をLF（Line feed)にする。→つまり、Linuxで使う改行コードにしてあげること。（よくわからない人はhttps://irisawadojo.blogspot.jp/2018/05/csv-import.html をみてね！）


前処理をして、importしたが、失敗。
エラー：invalid script: cript　　　（はぁ？　なに？）
→　CSVのscrip項目にcriptと入力したのが原因のよう。ISO15924の英語はラテン語のコードLatnを入れなければならない。でも今回はLatnを入れずに、scrip項目のデータは空白のままにした。

でもでも、またエラー。　（T..T）
（もうやめよう・・・）

しばし、議論です。

シーンとなったので、ちょっと整理しようと言ってみたが…
1名だけはい！と言ってくれました。ありがとう。　T.T

皆整理する気はまったくなく（笑）、議論は続き、CSVのフォンド名がないことに気づく。Lagacy IDとsource nameがマッチしない場合、title, repository, identifierの3つがマッチするかを見るとマニュアルにあったので、気になりConimalとフォンド名（titleがないってことかな？）を入力して再度インポートします。

でもでも、またエラー（しょぼん…ほら〜もうやめようってば〜）

最後は、マニュアルのせいにして終わるか。違うか。（へへへ）

それでも諦めず今度は、CSVのフォンド情報だけを入れて更新されるか確認します！
やっぱりだめ。

（だからもうやめようよ〜）

あれ、皆ちょっと喧嘩ぽくなったぞ（爆笑）

それでも諦めず、普通にCSVをインポートしてみたらインポートされた。まぁ、ここまでは当たり前だけど、managemet jobsのレポートを見ると、ちゃんとConimalにはなかった「id」というのが付与されている。

やはりsource nameがなかったこと、idがなくて行のマッチングがずっと失敗したことが気になる。Legacy ID Mappingの部分に出ていたsource_idというのがもしかしたら原因？
でもそうかな〜わからないな〜どうかな〜ほんとうに？わからん〜


というところまでなんとか議論を勧めたが、今回は結構ストレスが溜まった作業になりました。皆二次会で発散してね〜　

以上！（＾＾）／


========================================

次回は、Archivemetica のDIPをuploadするのではなく、ただのCSVを利用してデータをAtoMにインポートしてみる....かな？

AtoMでCSVのimport （自習メモ１）

AtoMのマニュアル（下記）を読んで書くメモです～
長すぎるため、どこまでできるか分からないけど…
https://www.accesstomemory.org/en/docs/2.4/user-manual/import-export/csv-import/#update-existing-descriptions-via-csv-import

CSVインポートのウェブサーバでのタイムアウトを避けるために、裏で非同期的に行われる。これはAtoMのGearmanが管理。「Manage>Jobs」ページで確認できるって。
CSVをインポートするユーザーは管理者としてログインすること。

=======================================

★★データをインポートする前にやること★★

１）インポート作業の複雑さを予想：AtoMがインストールされているサーバーのコマンドラインから、「csv:chenk-import」コマンドを利用して、CSVファイルを確認。行と列の数や、パイプ文字「|」がどのくらいあるか、サンプル行の値（？）を調べる。

２）列(column)を合わせること：CSVの最初列は項目名が入る（データを入れないこと）、項目名の順番は変えないでね。そのままAtoMで表示される。決まったテンプレートを使うこと。我々はISADを使う。

３）文字はUTF-8でなければならない。Windows, MacのスプレッドシートはUTF-8ではない。注意してね。オープンソースのLibreOffice CalcはUTF-8への変換が可能。Excelをいじりたい場合はここ↓
https://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_excel-mso_winother-mso_2010/excel-%E3%81%A7-utf8-%E3%81%AE-csv/25d8bea2-f20c-4feb-9216-e06cb3bf0757

４）end-of line characterはUnix/Linuxの改行文字を使う
＝Line ending、EOL(End of Line)、line breakともいう。

Unix / Linux / FreeBSD / OS X use LF (line feed, \n, 0x0A)
Macs prior to OS X use CR (carriage return, \r, 0x0D)
Windows / DOS use CR+LF (carriage return followed by line feed, \r\n, 0x0D0A)

つまり、システムによって、改行を表す文字が異なるので注意！AtoMは「\n」を使う。
ExcelだとAtoMと合わないnewline characterが沢山ある。\rを削除する方法は下記が参考になるかも（やってみてないけどできるはず…^^;）
https://linux.just4fun.biz/?%E9%80%86%E5%BC%95%E3%81%8DUNIX%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89/%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%81%8B%E3%82%89%E6%94%B9%E8%A1%8C%E3%82%92%E5%89%8A%E9%99%A4%E3%81%99%E3%82%8B#f76585db

５）データ変換
もし他のシステムからエクスポートしたCSVであれば、AtoMへ合わせて変換してね～
（当たり前だけど親切に書いてくれてる…あまり親切じゃない時もあるけど…）

６）時間を予想
例えば20,000ある場合、1000やってみて×20で時間を予測してね～

７）テスト
準備ができたらcloneを作成してテストしてから、本番サーバーに入れてね～
でもcloneの作成方法がわからないのじゃ…　
多分↓のことだろうけど。
http://www.itmedia.co.jp/enterprise/articles/0811/20/news019.html



今日はここまでかな。
時間掛かり過ぎ。しょぼん…

作成：Bee

【11】AtoMへDIPをupload

今日は、新しいメンバーも加わり、スカイプで二人つなげて進行です！
（スカイプの二人は二人で会話して、道場の人は道場で会話をするという異様な風景から作業を始めます。）

今日は、Archivemetica1.7がリリースされたということで、
一つのマシンにArchivemetica1.7とAtoM2.4、両方を入れたものを入澤先生に用意してもらいました。

しかし、これは作業をやりやすくするためのもの。
AtoMは公開用で、Archivemeticaは管理用なので、本来はarchivematicaとAtomを同じサーバー上に入れるのはSecurity上、望ましくない。

インストール時には、
①AtoMを先にインストールしてから、
②Archivematicaをインストールすること
MySQLのバージョンが古いほうを先に入れなければならない。
AtoM2.4のMySQLは5.6、Archivematica1.7のMySQLは5.7が推奨されているので注意すること。

あれ？そういえば新しいマシンはAtoMにまでつなげていないので、archivematicaでアレンジメントができない。どうする？

では、つなげましょう。
Anicoをtransferから再度やりましょう。
1.7のvirusチェックプログラムが変更になったが、早速virusチェックでエラー発生。T.T
結局新しいバージョンを試すのはやめて、旧マシンに戻すことになりました〜
入澤先生よろしくお願いします〜

（皆待つ）

はい。続けましょう。

旧マシンにAnicoをもう一度transferした。

今回は
フォンド：conimal
シリーズ：coffee, animal

Nomalization Reportは、メールアドレスを設定してないので、いつもfailedが出る。
（無視してね〜）
SIP作成後は、Store AIPをクリックしてAIPも作る。

Archivematicaからの準備ができたら、AtoMへ移動して、Fondを作成してから、slag部分（URLの最後のスラッシュの後の部分）をコピーしてArchivemeticaへ入力して、つなげる。

slugを入れてみたが、（いつものことだが　^^;）エラーが出た。
エラー：Response code not expected

いつもの通り、順調に躓いた。おほほ！（T..T）？

原因がわからないので、conimalをフラットなままtransferして、DIPのuploadができるかやってみる。

（ガソリンも補充し、しばし雑談）

また失敗した。

なんでなんでを言いながら、時間が過ぎる…

橋本さんと入澤先生が同時に叫ぶ。わかった！！

ついに、原因判明かな？
Sword pluginが動いてなかったみたい。
AtoM側でAtoM worker(Sword pluginがこれを動かしている）が色々やっていて、Archivematicaからの依頼に反応しているが、Swordが動いてなかったので、反応がなかったとのこと。

ということで、conimalのtransferからもう一度チャレンジ！
オット！
また同じエラーが出た！（Pluginの問題ではなかったのかな？どういうこと？機械はいつもこうだから好きじゃない…　ーー；）

それでもめげず、リブートと叫ぶウォンさんの一言で
とりあえず、マシンを再起動して再チャレンジ。

conimalフォンドのuploadに遂に成功！！！！
パチパチ！！！

（これで気持ちよく二次会に行けるぞ。ホホホ）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

次回は？
AtoMに入れたconimalの記述をCSVを利用して追加する作業をする。

現在は記述項目が空白の状態。
CSVをダウンロードすれば、ファイルは取得できるが、
UTFだったり、レガシIDなどCSVファイルを理解する必要がありそう。
次回は、これを一緒にやります！

以上！

METS、OAIS関連参考情報です。

参考資料アップします〜

■国立国会図書館デジタルコレクションのOAIS参照モデルへの準拠状況

国立国会図書館デジタルコレクションのOAIS参照モデルへの準拠状況「近代デジタルライブラリー」からの転換から引用　https://www.jstage.jst.go.jp/article/johokanri/58/9/58_683/_pdf　

これは以前橋本さんが説明してくれたスライドですが、OAISをオープンソースを利用してどう実現するか理解するのにとても役にたちました。わかりやすい。

Blog about MIT Libraries' Digital Archives Workから引用
https://libraries.mit.edu/digital-archives/integrating-tools/

■　これは4月の勉強会でMETSファイルを分析する際に参考にしたものです。

　　オランダではなく、デンマークの人でした。^^;

Eld Zierau, The Royal Library of Denmark

http://www.dpconline.org/docs/miscellaneous/events/856-premismets-zierau-1-1/file から引用