記事一覧

Nuxt.jsとNext.jsは、どちらもJavaScriptのフレームワークで、Vue.jsとReact.jsの上に構築されています。それぞれのフレームワークには独自の利点がありますが、Nuxt.jsがNext.jsに比べて優れているとされる点をいくつか挙げます。 1. Vue.jsの利点: Nuxt.jsはVue.jsをベースとしているため、Vue.jsの利点を引き継いでいます。Vue.jsは、コンポーネントの構造がシンプルで、学習曲線が緩やかであることが評価されています。 2. ディレクトリベースのルーティング: Nuxt.jsは、ディレクトリ構造を使ってルーティングを自動生成します。これにより、開発者はルーティング設定を手動で行う必要がなくなり、開発効率が向上します。 3. Vuexの統合: Nuxt.jsでは、Vuex（Vue.jsの状態管理ライブラリ）がデフォルトで統合されています。これにより、状態管理が容易になります。 4. ミドルウェアのサポート: Nuxt.jsでは、ミドルウェアを利用してルートやページにカスタムロジックを追加できます。これにより、開発者はアプリケーションの振る舞いを簡単にカスタマイズできます。 5. モジュールシステム: Nuxt.jsにはモジュールシステムがあり、コミュニティで開発された機能を簡単に追加できます。これにより、開発者はアプリケーションの拡張性を向上させることができます。 ただし、どちらのフレームワークが優れているかは、プロジェクトの要件や開発者のスキルセット、好みによって異なります。Next.jsもReact.jsのエコシステムやサーバーサイドレンダリング(SSR)、静的サイト生成(SSG)などの機能を持っており、多くの開発者に支持されています。最終的には、どちらのフレームワークがプロジェクトに適しているかを慎重に検討することが重要です。

canonical URLとは、同じコンテンツを指す異なるURLが存在する場合に、その中から1つの「正規」なURLを選ぶことです。これは検索エンジンがコンテンツの重複を防ぎ、ウェブページの検索順位に悪影響を与えることなく、ウェブページの重要度を正確に評価できるようにするために使用されます。 例えば、以下のようなURLがあったとします。 1. http://example.com/page 2. http://www.example.com/page 3. https://example.com/page 4. https://www.example.com/page これらのURLはすべて同じコンテンツを指しているとしても、検索エンジンはそれらを異なるページとして扱うことがあります。canonical URLは、HTMLの`

はじめに 以前に以下の記事を執筆しましたが、GPT-4による解説の方が有用でしたので紹介します。 完全不一致検索を JavaScript で実装する方法 Fuse.js は、クライアントサイドで動作する軽量なファジーサーチライブラリです。ただし、今回の目的である完全不一致検索 には向いていません。代わりに、JavaScript の Array メソッドを使って簡単に実装できます。 完全不一致検索の例 次の例では、filter メソッドを使って完全不一致検索を行います。 const data = [ { title: 'Example Title 1', content: 'This is an example content for the first item.', }, { title: 'Example Title 2', content: 'This is an example content for the second item.', }, // ... 他のデータ ]; const searchTerm = 'Example Title 1'; const results = data.filter( (item) => item.title !== searchTerm && item.content !== searchTerm ); console.log(results); この例では、data 配列から searchTerm と完全に一致しない要素をフィルタリングしています。title と content の両方が searchTerm と一致しない場合、要素が結果の配列に含まれます。 このように、JavaScript のネイティブな Array メソッドを使って完全不一致検索を実装できます。 ...

TEI/XMLファイルからrespStmtのnameの値を抽出する方法: PythonでBeautifulSoupとElementTreeを使ったアプローチ この記事では、PythonのBeautifulSoupとElementTreeを使って、TEI/XMLファイルからrespStmtのnameの値を抽出する方法を紹介します。 方法1: ElementTreeを使う まず、Pythonの標準ライブラリであるxml.etree.ElementTreeを使って、respStmtのnameの値を抽出します。 import xml.etree.ElementTree as ET # XMLファイルを読み込む tree = ET.parse('your_file.xml') root = tree.getroot() # 名前空間を定義 ns = {'tei': 'http://www.tei-c.org/ns/1.0'} # respStmtのnameの値を抽出 name = root.find('.//tei:respStmt/tei:name', ns) # nameのテキストを表示 if name is not None: print(name.text) else: print("nameタグが見つかりませんでした。") 方法2: BeautifulSoupを使う 次に、BeautifulSoupを使って、respStmtのnameの値を抽出します。まず、beautifulsoup4とlxmlライブラリがインストールされていることを確認してください。インストールされていない場合は、以下のコマンドでインストールできます。 pip install beautifulsoup4 lxml 以下のコードで、BeautifulSoupを使ってrespStmtのnameの値を抽出できます。 from bs4 import BeautifulSoup # XMLファイルを読み込む with open('your_file.xml', 'r', encoding='utf-8') as file: content = file.read() # BeautifulSoupオブジェクトを作成 soup = BeautifulSoup(content, 'lxml-xml') # respStmtのnameの値を抽出 name = soup.find('respStmt').find('name') # nameのテキストを表示 if name: print(name.text) else: print("nameタグが見つかりませんでした。") どちらの方法でも、respStmtのnameの値をPythonで簡単に抽出することができます。あなたのプロジェクトに適した方法を選んでください。

Omeka ClassicとOmeka S: 機能と違いの比較（GPT-4による解説） 対象ユーザー: Omeka Classic: 主に個人や小規模な組織がデジタルコレクションを公開する目的。 Omeka S: 中から大規模な組織や複数のプロジェクトを同時に扱うことができるように設計。 サイト管理: Omeka Classic: 1つのインスタンスで1つのウェブサイトを作成。 Omeka S: 1つのインスタンスで複数のウェブサイトを作成・管理。 データ共有: Omeka Classic: 基本的には独立したサイトを作成。 Omeka S: データの再利用や共有を容易にするため、リンクトデータとセマンティックウェブ技術に対応。 拡張機能: Omeka Classic: プラグインをサポート。 Omeka S: モジュールをサポート。※Omeka ClassicのプラグインはOmeka Sのモジュールと互換性がない。 コミュニティサポート: Omeka Classic: 豊富なサポート資料やオンラインコミュニティが存在。 Omeka S: 比較的新しいプラットフォームで、まだそれほど多くの資料やサポートがないが、急速に成長中。 選択をする際には、プロジェクトの規模やニーズ、技術的なスキル、利用可能なリソースなどを考慮して、どちらのプラットフォームが適切かを判断することが重要です。この解説はGPT-4によって作成されました。 質問一覧 Omeka ClassicとOmeka Sの違いを教えてください。 上記の説明をマークダウン形式に変換してください。 上記の記事にタイトルをつけてください。 GPT-4を用いたことを追加してください。 私が行った質問の一覧をマークダウンで作成してください。 続き zenn.devに投稿するにあたり、複数のトピックを提案してください。 zenn.devへの投稿にあたり、以下のようなトピックを提案します。 Omekaプラットフォーム入門: Omeka ClassicとOmeka Sの基本概念やインストール方法を紹介。 Omeka ClassicとOmeka Sの拡張機能比較: 両プラットフォームで利用できるプラグインとモジュールの比較と使い方。 Omekaを利用したデジタルアーカイブ構築: Omeka ClassicまたはOmeka Sを用いてデジタルアーカイブを作成する方法。 Omeka ClassicからOmeka Sへの移行ガイド: データの移行や再設定が必要な部分について説明。 リンクトデータとセマンティックウェブの活用: Omeka Sでリンクトデータやセマンティックウェブ技術を活用する方法とメリット。 デジタルヒューマニティーズとOmeka: デジタルヒューマニティーズ分野でのOmekaの活用事例や可能性について説明。 Omekaプロジェクトのベストプラクティス: 成功したOmekaプロジェクトの共通点やベストプラクティスについて解説。 オープンソース文化遺産管理ソフトウェアの比較: Omeka以外のオープンソース文化遺産管理ソフトウェア（例: CollectiveAccess, DSpace）との比較。 より技術ブログに適した端的なキーワードを最大5つ教えてください。 技術ブログに適した端的なキーワードは以下の通りです。 ...

概要 Omeka Sにおいて、非公開リソースに対する閲覧権限を持つユーザを作成する必要がありましたので、その備忘録です。 Omeka Sのユーザ権限 Omeka Sでは複数のユーザ権限が用意されています。具体的には、以下のページで紹介されています。 https://omeka.org/s/docs/user-manual/admin/users/#users 以下、日本語訳をまとめましたので、参考になりましたら幸いです。 英語 日本語 Global Administrator full installation privileges. グローバル管理者 完全なインストール権限 Supervisor robust site and content privileges. Supervisor 堅牢なサイトおよびコンテンツ権限 Editor (Content Expert) full privileges for content creation. 編集者 コンテンツ制作のための完全な権限 Reviewer robust content privileges but can only delete own content. レビュアー 強力なコンテンツ権限を持っているが、自分のコンテンツを削除することしかできない。 Author create own content. 著者 自分のコンテンツを作成することができます。 Researcher search and read privileges only. 研究者 検索と読み込みの権限のみ 非公開リソースへのアクセス： View Private Resourcesモジュール 上記の表において、Researcher（研究者）は検索と読み込みの権限しか持たないため、非公開リソースのレビュー等を依頼する際に使用し得る権限の一つです。（加えて、Guestモジュール等を使用することで、権限を追加することもできます。） しかしデフォルト設定では、Author（著者）およびResearcher（研究者）は非公開リソースへのアクセス権限を持っていません。 ...

概要 Custom Ontologyは、LOV、schema.org、W3Cといった標準的なオントロジーが利用できないときに、独自の語彙を追加することができるモジュールです。以下で使用方法を紹介しています。 https://nakamura196.hatenablog.com/entry/2021/07/24/235050 上記の記事では語彙の作成までを扱っていますが、既存の語彙の更新方法については扱っていませんでした。本記事では、既存の語彙の更新方法について説明します。 語彙の作成 例として、以下の語彙を作成します。 https://omekas.aws.ldas.jp/omeka4/ns/myprefix/ 上記にアクセスすると、以下のttlファイルがダウンロードされます。今回、myprefix:mySpecificPropertyという独自のプロパティを追加しています。 @prefix dcterms: <http://purl.org/dc/terms/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> . @prefix o: <http://omeka.org/s/vocabs/o#> . @prefix myprefix: <https://omekas.aws.ldas.jp/omeka4/ns/myprefix/> . <https://omekas.aws.ldas.jp/omeka4/ns/myprefix/> a owl:Ontology ; dcterms:title "My label" ; dcterms:description "A specific ontology for my documents." . myprefix:mySpecificProperty a rdf:Property ; rdfs:label "My specific property" ; rdfs:comment "A property to use for my specific documents." ; rdfs:domain o:Resource ; vs:term_status "experimental" . 語彙の更新 今回、myprefix:mySpecificPropertyのラベルを私のプロパティに変更してみます。 ...

Nuxt 3でLeaflet Marker Clusterを試す機会がありました。実装例は以下です。 https://nuxt3-demo-nine.vercel.app/map-cluster 本実装にあたり、以下のページを参考にさせていただきました。 https://codesandbox.io/s/ns238 ソースコードは以下です。 https://github.com/nakamura196/nuxt3-demo 2023年3月時点においては、POC（Proof of Concept）の段階のようです。参考になりましたら幸いです。

概要 Pythonでパッケージを作成する際、nbdevを使用しています。 https://nbdev.fast.ai/ nbdevは以下のように説明されています。 Write, test, document, and distribute software packages and technical articles — all in one place, your notebook. （機械翻訳） ソフトウェア パッケージや技術記事の作成、テスト、文書化、配布をすべて 1 か所のノートブックで行います。 本記事では、nbdevを使用する際の備忘録です。 インストール 以下のチュートリアルのページが参考になります。 https://nbdev.fast.ai/tutorials/tutorial.html 以下、かいつまんで流れを説明します。 関連するツールをインストールした後、GitHubリポジトリを作成し、クローンした先で以下を実行します。 nbdev_new その後、以下も実行しておきます。 nbdev_install_hooks そしてnbsフォルダの中の00_core.ipynbなどを編集して、本ノートブックの最後のセルにある以下を実行します。 import nbdev; nbdev.nbdev_export() その結果、Pythonモジュールが自動的に作成されます。 パッケージをインストールする 同一フォルダ内 以下を実行します。 pip install -e '.[dev]' 別のフォルダから 一例ですが、絶対パスを指定してインストールします。 例： /Users/hogehoge/tei_xml_tools の場合 pip install -e /Users/hogehoge/tei_xml_tools -eオプションを付けることで、開発中にパッケージに加えられた変更をすぐに使用できます。 ライブラリの使用 以下のように%を使用することで、開発中の内容を反映することができました。 # %load_ext autoreload %reload_ext autoreload %autoreload 2 from tei_xml_tools.core import * まとめ その他、ドキュメントのプレビューやpypiにアップロードを行うためのコマンドも提供されています。機会があれば、nbdevの使い方全般についても記事にしたいと思います。

概要 Fuse.jsはJavascript製の検索エンジンです。 https://fusejs.io/ フロントエンドのみで完結するアプリを作成する際の検索エンジンとして重宝しています。 今回、Fuse.jsを用いた完全不一致検索を実現するにあたり、クエリを工夫する必要があったため、その備忘録です。 高度な検索 Fuse.jsでは、完全・部分一致、部分不一致など、多様な検索が可能です。以下のページに記載があります。 https://fusejs.io/examples.html#extended-search また、以下の記事で日本語訳が公開されています。 https://qiita.com/Sashimimochi/items/4972b3dc333c6e5fb866#より高度な検索 ただし、完全不一致検索については、クエリを工夫する必要がありました。 完全不一致検索 例えば、labelというフィールドに「悪党」という文字列を持たない検索は、以下のようなクエリで部分的に実現できました。「悪党で始まらない」または「悪党で終わらない」を検索しています。 { "$or": [ { "label": "!^悪党" # 「悪党で始まらない」 }, { "label": "!悪党$" # 「悪党で終わらない」 } ] } ただし、上記のクエリは完全ではなく、「悪党と悪党」といった値を持つものも除外してしまう点に注意が必要です。 まとめ 誤った理解をしている点もありそうですが、参考になりましたら幸いです。

概要 Omeka Sへのメタデータ（アイテム）と画像（メディア）等の一括登録を行うためのモジュール「Bulk Import」の使い方について、以前に以下の記事を作成しました。 https://nakamura196.hatenablog.com/entry/2021/07/28/080952 ただし、Omeka Sやモジュールのアップデートにより、2023年３月時点では、一部挙動が異なる点があります。そこで本記事では、詳細な説明は上記の記事に譲りつつ、アイテムセットからメディアの登録までの一連の流れを再度紹介します。 モジュールのインストール 関連モジュールのインストール まず、以下の2つのモジュール「Log」と「Generic」をインストールしてください。 https://github.com/Daniel-KM/Omeka-S-module-Log https://github.com/Daniel-KM/Omeka-S-module-Generic （オプショナル）ログの設定 Logモジュールのインストール後に、以下のようなアラートが表示されます。config/local.config.phpの設定を変更しておくことで、Bulk Importを使用する際のエラー内容などを確認することができて便利です。 具体的には、/config/local.config.phpについて、logをtrueに設定します。 return [ 'logger' => [ 'log' => true, //ここをtrueに変更する 'priority' => \Laminas\Log\Logger::NOTICE, ], 'http_client' => [ 'sslcapath' => null, 'sslcafile' => null, ], ... ] この設定を行うことにより、後述する一括登録の際に、以下のようなログが表示されます。特に、意図したとおりに一括登録できない場合に、その原因を調べる上で参考になります。 Bulk Importのインストール 以下のリポジトリからインストールしてください。 https://github.com/Daniel-KM/Omeka-S-module-BulkImport インストール後に以下のような設定画面が表示されますが、とりあえずそのままで構いません。 アイテムセットの登録 まず、アイテムセットの登録を行います。インポートの画面から、以下の「CSV - Item sets」を選択します。 サンプルデータとして、以下のcsvファイルをダウンロードしてください。 https://github.com/omeka-j/Omeka-S-module-BulkImport-Sample-Data/blob/main/item_set.csv ダウンロードしたファイルを選択します。 次の画面では、いろいろな設定項目がありますが、とりあえずデフォルトのままでOKです。 登録が完了すると、以下のように、タイトル（dcterms:title）とIdentifier（dcterms:identifier）が登録されます。 アイテムの登録 次に、アイテムの登録を行います。以下のcsvファイルを使用します。 ...

概要 これまで、Google Cloud PlatformやGoogle Colabを用いたNDL OCR及びNDL古典籍OCRのチュートリアルを作成してきました。 今回は、Amazon SageMaker Studioを用いたNDL古典籍OCRの実行方法について説明します。なお、今回の方法では、実行の際に費用が発生しますのでご注意ください。 Amazon SageMaker Studioの説明は以下です。 https://aws.amazon.com/jp/sagemaker/studio/ ドメインの設定など ドメインの設定などは以下の記事などを参考にしてください。 https://dev.classmethod.jp/articles/how-to-walk-around-amazon-sagemaker-studio-new-ui/ 今回は以下のように作成済みのユーザープロファイルから「起動」→「Studio」を選択したところから説明します。 Studioでの操作 ノートブックの起動方法はいくつかありますが、ここでは、「File」→「New」→「Notebook」で起動してみます。 その後、以下のようなダイアログが表示されるため、今回は「ml.g4dn.xlarge」を選択します。 !nvidia-smiを実行すると、Tesla T4が表示されます。 ノートブックの実行 以下のファイルをノートブックをダウンロードし、SageMakerにアップロードしてください。 https://github.com/nakamura196/ndl_ocr/blob/main/sagemaker_ndl_kotenseki_ocr.ipynb ノートブックの作成にあたっては、@blue0620さんのノートブックを参考にしています。 https://github.com/blue0620/NDLkotenOCR-GoogleColabVersion/blob/main/NDLkotensekiOCR_googlecolabversion.ipynb 上記からの大きな差分として、まず、以下を実行しています。これらを行わないと、ライブラリのインストール時に、error: command 'gcc' failed with exit status 1といったエラーが発生します。 !apt update !apt -y install build-essential !apt -y install libgl1-mesa-dev libglib2.0-0 以下のように、OCR処理が実行されます。 インスタンスの削除 実行後は、忘れずにインスタンスの削除を行います。例えば、画面左部の「Running Terminals and Kernels」から「Running Instances」にあるインスタンスをシャットダウンします。 まとめ Amazon SageMaker Studioを用いたNDL古典籍OCRの実行方法について説明しました。

概要 以下のように、Babylon.jsでクリックしたmeshの名前を取得する方法を調査しました。 以下のチュートリアルを参考にしました。 https://doc.babylonjs.com/communityExtensions/Babylon.js+ExternalLibraries/BabylonJS_and_Vue/BabylonJS_and_Vue_2#passing-data-from-babylonjs-to-vue-using-callbacks デモページは以下です。 https://nakamura196.github.io/nuxt3-babylonjs/8/ ページのソースコードは以下です。 https://github.com/nakamura196/nuxt3-babylonjs/blob/main/pages/8/index.vue 実装方法 以下の箇所で、createSceneにcallback変数を渡しています。fpsCallbackの名前は修正したほうがよいかもしれません。 https://github.com/nakamura196/nuxt3-babylonjs/blob/5c33d2e6bcd1681df17f3f12fea3cd68fc645157/components/Scene8.vue#L10-L13 そして、createScene関数において、onPointerDownの結果を渡すようにしています。 https://github.com/nakamura196/nuxt3-babylonjs/blob/5c33d2e6bcd1681df17f3f12fea3cd68fc645157/scenes/Scene8.js#L44-L49 まとめ よりよい実装方法があるかもしれませんが、参考になりましたら幸いです。

概要 以前、Babylon.jsとNuxt3を組み合わせたリポジトリを作成しました。 一方、Babylon.jsでVueを使用するチュートリアルが以下で公開されています。 https://doc.babylonjs.com/communityExtensions/Babylon.js+ExternalLibraries/BabylonJS_and_Vue 今回は、上記サイトにある以下のチュートリアルをNuxt3で実装しました。 https://doc.babylonjs.com/communityExtensions/Babylon.js+ExternalLibraries/BabylonJS_and_Vue/BabylonJS_and_Vue_2 デモサイトは以下です。 https://nakamura196.github.io/nuxt3-babylonjs/ ソースコードは以下です。 https://github.com/nakamura196/nuxt3-babylonjs チュートリアル Passing data from BabylonJS to Vue using callbacks （日本語訳）これは、最も冗長ですが、最も安全で、最も拡張性と再利用性のあるアプローチです。基本的には、BabylonJSのシーンコードでメソッドを作成し、それに応じてエクスポートすることで、Vueコンポーネントにインポートし、それぞれを呼び出すことができるようになります。 https://nakamura196.github.io/nuxt3-babylonjs/third/ Passing data from BabylonJS to Vue using an exposed Engine object （日本語訳）ここでの大きな変更は、createSceneメソッドがEngineとSceneオブジェクトを返すことで、それらがVueコンポーネントに公開され、コンポーネントが直接それらにアクセスできるようになったことです。この2つのオブジェクトは、後でアクセスできるようにVueコンポーネントに保存されます。その直後に、FPSの値を1秒ごとに親のApp.vueコンポーネントに送信するインターバルを作成します。BabylonJS EngineのオブジェクトからFPSの値を直接Vueコンポーネントに取り込みます。 Sending data from Vue to BabylonJS with loose coupling and without exposing the BabylonJS objects to Vue （日本語訳）すでに書いたように、アクセスや操作が必要なものすべてに、メソッドを作成するだけです。（中略）BabylonJSのシーンファイルを修正し、これらのメソッドをエクスポートして、Vueコンポーネントでインポートできるようにします。 https://nakamura196.github.io/nuxt3-babylonjs/4/ Sending data from Vue to BabylonJS and vice versa with an exposed BabylonJS Vector3 object （日本語訳）この例では、公開されたBabylonJSのオブジェクトを使った通信を紹介します。最後のメソッドでは、EngineとSceneオブジェクトを公開します。公開できるのは、ごくわずかです。例えば、Scene全体を公開するよりも、Vector3だけを公開する方が、はるかに良い方法です。 ...

以下に記載がありました。 https://archivesspace.github.io/tech-docs/administration/unix_daemon.html 具体的には、以下のように実行すれば良いようです。 cd /home/ubuntu/archivesspace/ ./archivesspace.sh start

概要 ArchivesSpaceは、アーカイブ、マニュスクリプト、デジタルオブジェクトを管理し、Webアクセスを提供するためのオープンソースのアーカイブス情報管理アプリケーションです。 https://archivesspace.org/ このArchivesSpaceをAmazon Lightsailに立てる機会がありましたので、その備忘録です。 以下のページにインストール方法が記載されています。 https://archivesspace.github.io/tech-docs/readme_implement.html インスタンス Ubuntu 20.04 LTSを選択しました。 以下のような記載がありましたが、2GBのメモリでは動作が重たかったため、4GBを選択しました。 At least 1024 MB RAM allocated to the application; at least 2 GB for optimal performance. インストール まず、ArchivesSpaceをダウンロードします。 cd /home/ubuntu/ sudo apt-get -y update sudo apt-get -y upgrade いったん確認が求められます。 sudo apt-get -y install openjdk-11-jdk # ダウンロード wget https://github.com/archivesspace/archivesspace/releases/download/v3.3.1/archivesspace-v3.3.1.zip -O /home/ubuntu/archivesspace-v3.3.1.zip # unzipのインストール sudo apt -y install unzip # 展開 unzip /home/ubuntu/archivesspace-v3.3.1.zip Solrのインストール cd /home/ubuntu/ # ダウンロード wget -O solr.tgz https://www.apache.org/dyn/closer.lua/lucene/solr/8.11.2/solr-8.11.2.tgz?action=download -O /home/ubuntu/solr-8.11.2.tgz tar zxf /home/ubuntu/solr-8.11.2.tgz cd /home/ubuntu/solr-8.11.2 # confフォルダの作成 mkdir -p /home/ubuntu/solr-8.11.2/server/solr/configsets/archivesspace/conf/ cp /home/ubuntu/archivesspace/solr/* /home/ubuntu/solr-8.11.2/server/solr/configsets/archivesspace/conf/ cd /home/ubuntu/solr-8.11.2 # コアの作成 bin/solr start bin/solr create -c archivesspace -d archivesspace MySQLのインストール sudo apt install -y mysql-server mysql-client sudo service mysql status sudo mysql -uroot 以下、ログイン後に実行 ...

Archivematicaによって作成するAIPには、README.htmlファイルが含まれています。本ファイルをDeepLで翻訳（一部を人手で修正）しました。誤りも多く含まれているかと思いますが、参考になりましたら幸いです。 アーカイブマティカのAIP構造 このReadmeファイルでは、Archivematicaが生成するArchival Information Package（AIP）の基本的な構造について説明しています。 頭字語 AIP = アーカイバルインフォメーションパッケージ METS = メタデータのエンコードと送信の標準規格 OAIS = Open Archival Information System（オープン・アーカイブ・インフォメーション・システム) PDI = 保存記述情報（Preservation Description Information) PREMIS = 保存メタデータ実装ストラテジー UUID = ユニークユニバーサル識別子 はじめに Archivematica は、多様なデジタルコンテンツを取り込み、長期保存のためのAIPを作成するために設計されたオープンソースのツール群です。一度作成されたAIPは、Archivematicaに依存することなく、標準的なファイルブラウザで開くことができます。AIPのコンセプトは、ISO 14721:2012 Reference Model for an Open Archival Information System (OAIS) に由来し、「コンテンツ情報と関連する保存記述情報（PDI）からなり、OAIS内に保存される情報パッケージ」として定義されています。 コンテンツ情報 Archivematica AIPでは、コンテンツ情報は、主に最初に取り込まれたデジタルオブジェクトと、時間の経過とともにフォーマットが陳腐化するリスクを軽減するために作成されたオブジェクトの保存バージョンで構成されています。保存版は通常、元のオブジェクトと同じファイル名ですが、ファイル拡張子が異なり、ファイル名にUUIDが付加されています。たとえば、BBhelmet.aiという名前の元のファイルに対して、保存版の名前はBBhelmet-e3a3988d-8149-49ea-adc5-c255fb68d4f9.pdfである場合があります。 最初に取り込まれたデジタルオブジェクトと保存バージョンは、AIPのobjectsディレクトリに配置されます。もしこれらのサブディレクトリがオリジナルの転送に含まれていたり、SIPの配置中に追加された場合は、objectsディレクトリにネストしたサブディレクトリが存在します。objectsディレクトリには、submissionDocumentationフォルダーとmetadataフォルダーも含まれます。submissionDocumentationフォルダには、ドナー契約や譲渡書などの文書（AIPに含まれている場合）、およびAIPの作成元となった元の譲渡の内容を記録するMETSファイルが含まれます。metadataフォルダには、オリジナルの転送ファイルに含まれるメタデータファイルや、処理中に生成されたOCRテキストファイルが保存されます。 保存説明情報(PDI) Archivematica AIPのPDIは、METS XMLファイルに記録されています。METSは米国議会図書館によって管理されており、その定義は「World Wide Web ConsortiumのXMLスキーマ言語を使用して表現された、デジタルライブラリ内のオブジェクトに関する記述的、管理的、構造的メタデータをエンコードするための標準」です。Archivematica AIPでは、METSファイル名は、METSという名前にUUIDファイル拡張子とXMLファイル拡張子で構成されています。例えば、METS.0ad8cdab-dbbf-4863-8a4d-9a675c227216.xmlのようなファイル名です。METS ファイルは通常、以下の標準 METS セクションで構成されています。 mets:metsHdr (METSヘッダー)：METSファイルに関する基本的な情報。 mets:dmdSec（記述的メタデータ・セクション）：デジタル・オブジェクトについての記述的メタデータ。 mets:amdSec (管理メタデータセクション): デジタルオブジェクトに関する技術的および出所情報。 mets:fileSec (ファイルセクション): デジタルオブジェクトのリストとAIPにおける役割の表示（オリジナル、保存、メタデータ、提出書類、ライセンスなど）。 mets:structMap（構造マップ）：デジタル・オブジェクトの物理的または論理的な順序付け。すべてのAIP METSファイルには、デフォルトの物理的structMapが含まれ、AIPの構造に応じて、物理的または論理的な追加のstructMapを含むことができます。 METS amdSecの技術的および出所情報は、PREMISメタデータとして記録されます。PREMISは米国議会図書館の規格でもあり、「デジタル・オブジェクトの保存を支援し、その長期的な有用性を確保するためのメタデータの国際標準」と説明されている。PREMISエンティティは、METSファイルの中で以下のようにラップされています。 ...

概要 「ArchivematicaのAPIを試す」のArchivematica APi編です。（別に、「Storage Service API」があります。） https://www.archivematica.org/en/docs/archivematica-1.13/dev-manual/api/api-reference-archivematica/#api-reference-archivematica 今回は、以下の「Transfer」を試します。 https://www.archivematica.org/en/docs/archivematica-1.13/dev-manual/api/api-reference-archivematica/#transfer 使い方 以下のノートブックでお試しいただけます。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ArchivematicaのAPIを使ってみる.ipynb 以下のような記述が必要でした。ロケーションのUUIDは、ストレージサービスから確認しました。 ## サーバの設定 endpoint = "http://<ドメイン>:81/api" username = "<ユーザ名>" api_key = "<APIキー>" location_uuid = "<ロケーションのUUID>" ## Transferの設定 name = "mc_api_transfer" type = "standard" accession = "2023-1234" paths = ["files/movie_test"] row_ids = [""] ## base64へエンコード import base64 paths_encoded = [] for path in paths: path_encoded = base64.b64encode(f"{location_uuid}:{path}".encode()).decode() paths_encoded.append(path_encoded) ## POST import requests data = { "name": name, "type": type, "accession": accession, "paths[]": paths_encoded, "row_ids[]": row_ids } headers = {'Authorization': f'ApiKey {username}:{api_key}'} response = requests.post(f'{endpoint}/transfer/start_transfer/', headers=headers, data=data) まとめ 今回はStart transferのみを試しましたが、各操作に対するAPIが提供されており、色々なシステム連携ができそうでした。 ...

概要 ジャパンサーチでは、ジャパンサーチ内で使われている画面の構成要素を、部品としてジャパンサーチ以外のウェブサイトでも利用できる機能であるウェブパーツを提供しています。 https://jpsearch.go.jp/static/developer/webparts/ja.html 今回、Next.jsで本機能を使用する機会がありましたので、その備忘録です。 使用例 以下のページでご確認いただけます。 https://jps-2023-next.vercel.app/jps ソースコード 以下で公開しています。 https://github.com/nakamura196/jps_2023_next 以下のように、Scriptタグを使ってjsファイルを読み込むことで、うまく表示させることができました。 <Layout> <Script src="https://jpsearch.go.jp/assets/js/wp.bundle.js"></Script> <Container sx={{ my: 5, }} > <p> 東京大学「総合図書館バーチャルミュージアム」を改変して作成しています。 </p> <div className="jps" data-lang="ja" data-cur={data}></div> </Container> </Layout> まとめ ジャパンサーチのウェブパーツを同様の環境でお使いになられる際の参考になりましたら幸いです。

概要 ArchivematicaのStorage Service APIについては、以下のページに記載があります。このAPIをいくつか使ってみましたので、その備忘録です。 https://www.archivematica.org/en/docs/archivematica-1.13/dev-manual/api/api-reference-storage-service/ 以下、ベーシック認証が求められた場合には、以下の情報をお使いください。 ユーザ名：demo パスワード：Nd4Ev3XJ PACKAGE A package is a bundle of one or more files transferred from an external service; for example, a package may be an AIP, a backlogged transfer, or a DIP. Each package is stored in a location. 以下のURLからAIPやDIPの一覧を確認することができます。デフォルトではXML形式のデータが返却されましたが、format=jsonを与えることで、JSON形式のデータをダウンロードできました。 http://18.215.157.75:8001/api/v2/file/?format=json { "meta": { "limit": 20, "next": null, "offset": 0, "previous": null, "total_count": 2 }, "objects": [ { "current_full_path": "/var/archivematica/sharedDirectory/www/AIPsStore/8dfd/b901/9cb1/44be/bfde/e872/15df/9813/test-8dfdb901-9cb1-44be-bfde-e87215df9813.7z", "current_location": "/api/v2/location/b9661f20-63fa-4843-98aa-05f8c6228c1e/", "current_path": "8dfd/b901/9cb1/44be/bfde/e872/15df/9813/test-8dfdb901-9cb1-44be-bfde-e87215df9813.7z", "encrypted": false, "misc_attributes": { }, "origin_pipeline": "/api/v2/pipeline/e395113a-2885-4163-bf5a-a2786dad948e/", "package_type": "AIP", "related_packages": [ "/api/v2/file/65f81712-399b-4edb-a1a7-1b841a738fc1/" ], "replicas": [ ], "replicated_package": null, "resource_uri": "/api/v2/file/8dfdb901-9cb1-44be-bfde-e87215df9813/", "size": 61495776, "status": "UPLOADED", "uuid": "8dfdb901-9cb1-44be-bfde-e87215df9813" }, { "current_full_path": "/var/archivematica/sharedDirectory/www/DIPsStore/65f8/1712/399b/4edb/a1a7/1b84/1a73/8fc1/test-8dfdb901-9cb1-44be-bfde-e87215df9813", "current_location": "/api/v2/location/f403aa21-749c-4d93-b71e-b95635d8ce14/", "current_path": "65f8/1712/399b/4edb/a1a7/1b84/1a73/8fc1/test-8dfdb901-9cb1-44be-bfde-e87215df9813", "encrypted": false, "misc_attributes": { }, "origin_pipeline": "/api/v2/pipeline/e395113a-2885-4163-bf5a-a2786dad948e/", "package_type": "DIP", "related_packages": [ "/api/v2/file/8dfdb901-9cb1-44be-bfde-e87215df9813/" ], "replicas": [ ], "replicated_package": null, "resource_uri": "/api/v2/file/65f81712-399b-4edb-a1a7-1b841a738fc1/", "size": 30175868, "status": "UPLOADED", "uuid": "65f81712-399b-4edb-a1a7-1b841a738fc1" } ] } package_typeがAIPとなっているリソースにアクセスしてみます。 ...