以前、Hugging Face SpacesとYOLOv5モデル（NDL-DocLデータセットで学習済み）を使った推論アプリの構築を行いました。 今回は上記のアプリを一部変更して、以下の差分に示すように、JSON出力を追加しました。 https://huggingface.co/spaces/nakamura196/yolov5-ndl-layout/commit/4d48b95ce080edd28d68fba2b5b33cc17b9b9ecb#d2h-120906 これにより、以下のノートブックのように、返却結果を利用した処理が可能になりました。 https://github.com/nakamura196/ndl_ocr/blob/main/GradioのAPIを用いた物体検出例.ipynb 他により良い方法があるかと思いますが、参考になりましたら幸いです。
はじめに AWS EC2を用いたVirtuoso RDFストアの構築に関する備忘録です。独自ドメイン設定、HTTPS接続、Snorqlの設置、までを行います。 本記事以外にも、Virtuoso構築に関する有益な記事が多数存在しています。参考にしてください。 https://midoriit.com/2014/04/rdfストア環境構築virtuoso編1.html https://qiita.com/mirkohm/items/30991fec120541888acd https://zenn.dev/ningensei848/articles/virtuoso_on_gcp_faster_with_cos 前提 ACM Certificateは作成済みとします。以下の記事などを参考にしてください。 https://dev.classmethod.jp/articles/specification-elb-setting/#toc-3 EC2 まずEC2のインスタンスを作成します。 Amazon Linuxを選択し、インスタンスタイプはt2.microとしました。 ネットワーク設定については、「セキュリティグループを作成する」を選択し、「HTTPSトラフィックを許可する」と「HTTPトラフィックを許可する」の両方にチェックを入れます（以下の図では、後者にのみチェックが入っている状態ですのでご注意ください）。 インスタンスの状態が「実行中」になったら、画面右上の「接続」ボタンを押して、サーバに接続します。 接続後、以下を実行して、apacheサーバを立ち上げておきます。 sudo yum install httpd -y cd /var/www/html sudo vi index.html <p>test</p> sudo systemctl start httpd sudo systemctl enable httpd ELB作成 「ロードバランシング」の「ターゲットグループ」を選択します。 「Create target group」から、[Basic configuration]で「Instances」を選択して、あとは下図のように設定します。「VPC」は先ほど立ち上げたEC2インスタンスと同じものを選択しています。 「Register targets」の画面において、画面上部でインスタンスを選択して、「Include as pending below」ボタンをクリックします。すると、下図のように、選択したインスタンスが画面下部に移動します。 その後、「Create」ボタンを押します。 次に、「ロードバランサー」から「ロードバランサーの作成」を行います。 「Create Application Load Balancer」を選択し、以下のように「Network mapping」で複数のサブネットを選択します。 次がポイントですが、「Security groups」において、選択済みの「default」を削除して、先にEC2インスタンスの作成時に作成したセキュリティグループ「lanch-wizard-XX」など選択します。 また、「Listeners and routing」は、「HTTPS」を選択して、「Forward to」に先ほど作成したターゲットグループを選択してください。 ...
概要 Virtuoso RDFストアに対して、curlおよびpythonを用いてRDFファイルを登録・削除する方法の備忘録です。 以下を参考にしています。 https://vos.openlinksw.com/owiki/wiki/VOS/VirtRDFInsert#HTTP PUT curl 上記のページの通りです。まず、登録用のサンプルデータとして、myfoaf.rdfを作成します。 <rdf:RDF xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:Person rdf:about="http://www.example.com/people/中村覚"> <foaf:name>中村覚</foaf:name> </foaf:Person> </rdf:RDF> 次に以下のコマンドを実行します。 curl -T ${filename1} ${endpoint}/DAV/home/${user}/rdf_sink/${filename2} -u ${user}:${passwd} 具定例は以下です。 curl -T myfoaf.rdf http://localhost:8890/DAV/home/dba/rdf_sink/myfoaf.rdf -u dba:dba python 実行例は以下です。以下では、rdflibを用いて、RDFファイルの作成から行なっています。またactionをdeleteに設定することで、削除を行うことができます。 import requests from rdflib import Graph, URIRef, Literal from rdflib.namespace import FOAF filename = "myfoaf.rdf" endpoint = "http://locahost:8890" user = "dba" passwd = "dba" action = "create" # action = "delete" ##### # RDFデータの作成 g = Graph() s = URIRef("http://example.org/people/中村覚") name = Literal("中村覚") g.add((s, FOAF.name, name)) # ファイルへの保存 g.serialize(destination=filename, format="xml") data = open(filename,'r', encoding='utf-8') data = data.read().encode() # 登録 url = f"{endpoint}/DAV/home/{user}/rdf_sink/{filename}" if action == "create": response = requests.put(url, data=data, auth=(user, passwd)) elif action == "delete": response = requests.delete(url, auth=(user, passwd)) print(response.status_code) まとめ 他にも方法があると思いますが、参考になりましたら幸いです。 ...
概要 Hugging Face Spacesと、以下の記事で紹介したYOLOv5モデル（NDL-DocLデータセットで学習済み）を使った推論アプリを作成しました。 以下のURLからお試しいただけます。 https://huggingface.co/spaces/nakamura196/yolov5-ndl-layout また以下のURLからソースコードや学習済みモデルをダウンロードすることができます。同様のアプリケーションを開発される際の参考になれば幸いです。 https://huggingface.co/spaces/nakamura196/yolov5-ndl-layout なお、アプリケーションの開発には、以下のSpaceを参考にしています。 https://huggingface.co/spaces/pytorch/YOLOv5 使い方 画像をアップロードするか、Examplesから画像を選択してご利用いただけます。以下のように認識結果を確認することができます。 APIの利用 APIの利用方法に関するノートブックを作成しました。こちらも参考になりましたら幸いです。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/gradioのAPI利用.ipynb
Elasticsearch 上のデータをローカルにダンプするにあたり、elasticsearch-dumpを使用しました。その備忘録です。 https://github.com/elasticsearch-dump/elasticsearch-dump 以下のように、vオプションを使用することで、コンテナ上で作ったファイルがホストの方に残ります。limitオプションなどは任意です。 docker run -v [ホストディレクトリの絶対パス]:[コンテナの絶対パス] --rm -ti elasticdump/elasticsearch-dump --input [ソースとなる Elasticsearch インデックスのエンドポイント] --output=[コンテナの絶対パス]/[出力ファイル名].json --limit 10000 具体的には、以下のような形です。 docker run -v /Users/xxx/dump:/test --rm -ti elasticdump/elasticsearch-dump --input https://xxx.us-east-1.es.amazonaws.com/images --output=test/images.json --limit 10000 参考になりましたら幸いです。
概要 NDL-DocLデータセットとYOLOv5を用いたレイアウト抽出モデルを作成しました。 https://github.com/ndl-lab/layout-dataset https://github.com/ultralytics/yolov5 本モデルは以下のノートブックからお試しいただけます。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/NDL_DocLデータセットとYOLOv5を用いたレイアウト抽出モデル.ipynb 本記事は、上記の学習過程の備忘録です。 データセットの作成 Pascal VOC形式のNDL-DocLデータセットを、YOLO形式に変換します。この方法については、以下の記事を参考にします。Pascal VOC形式からCOCO形式への変換に加えて、COCO形式からYOLO形式への変換を追加しています。 学習 以下のページにカスタムデータの学習方法が記載されています。 https://github.com/ultralytics/yolov5/wiki/Train-Custom-Data 以下のノートブックにも学習方法が記載されています。 https://colab.research.google.com/github/ultralytics/yolov5/blob/master/tutorial.ipynb 入力画像のサイズを1024、バッチサイズを4、エポック数を300に設定した結果、以下のような結果が得られました。なお、データセットをtrain 80%, validation 10%, test 10%に分けています。 推論 上述した通り、以下のノートブックから推論をお試しいただけます。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/NDL_DocLデータセットとYOLOv5を用いたレイアウト抽出モデル.ipynb 以下、推論結果の例です。うまく認識できた例のみを掲載しています。 『源氏物語』(東京大学所蔵) 『源氏物語』(京都大学所蔵) 『源氏物語』(九州大学所蔵) まとめ レイアウト認識の結果を踏まえ、次は行内の文字認識に取り組みたいと思います。
以下のページを参考にしています。 https://stackoverflow.com/questions/67324695/is-there-a-way-to-get-the-id-of-a-google-drive-folder-from-the-path-using-colab 以下のように記述することで、パスからGoogle DriveのフォルダのIDを取得することができます。 # ドライブのマウント from google.colab import drive drive.mount('/content/drive') # koraのインストール !pip install kora from kora.xattr import get_id # 例）マイドライブへのidを取得する path = "/content/drive/MyDrive" fid = get_id(path) print("https://drive.google.com/drive/u/1/folders/{}".format(fid)) 以下のノートブックからもお試しいただけます。参考になりましたら幸いです。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/パスからGoogle_DriveのフォルダのIDを取得.ipynb
NDL Labが公開するNDL-DocLデータセット(資料画像レイアウトデータセット)について、Pascal VOC形式のXMLファイルをCOCO形式のJSONファイルへ変換し、その内容を可視化するノートブックを作成しました。 https://github.com/nakamura196/ndl_ocr/blob/main/NDL_DocLデータセット(資料画像レイアウトデータセット)の変換と可視化.ipynb 上記のノートブックを開き、「ランタイム」 > 「すべてのセルを実行」 を押すことで、変換と可視化を行うことができます。 実行後に作成される「/content/img」フォルダと「/content/dataset_kotenseki.json」ファイルを使用することで、COCO形式のデータが求められる機械学習プログラムに使用することができます。 参考になりましたら幸いです。
概要 以下の記事を参考に、Hugging FaceモデルをAWS Lambdaでホスティングし、サーバーレス推論を行った備忘録です。 https://aws.amazon.com/jp/blogs/compute/hosting-hugging-face-models-on-aws-lambda/ また、Lambdaの関数URLとCloudFrontを用いたAPIの提供までを行います。 Hugging FaceモデルをAWS Lambdaでホスティング 準備 この点については冒頭でも紹介した、以下のドキュメントを参考にしています。 https://aws.amazon.com/jp/blogs/compute/hosting-hugging-face-models-on-aws-lambda/ まず以下のコマンドを実行します。venvという仮想環境を作成していますが、この点は必須ではないはずです。 #Clone the project to your development environment git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git cd zero-administration-inference-with-aws-lambda-for-hugging-face # 仮想環境の作成と有効化 python -m venv venv source venv/bin/activate # Install the required dependencies: pip install -r requirements.txt # Bootstrap the CDK. This command provisions the initial resources needed by the CDK to perform deployments: cdk bootstrap 注意 ドキュメントでは、この後にcdk deployをするように記載されています。その結果、deployすることができ、lambdaのテストも実行できました。しかし、後述するlambdaの関数URLを発行して利用した際に、いくつかエラーが発生しました。そのため、次の修正を行います。 inference/*.py 関数URLから利用する場合、パラメータがqueryStringParametersに格納されるため、そのための処理を追加します。postで利用する場合には、さらに修正が必要です。 以下、sentiment.pyの変更例です。pipelineの引数などを変更することで、自作モデルに基づく推論を行うことも可能です。 ...
概要 二つのテキスト間の差分を抽出するプログラムを作成しました。以下のGoogle Colabからご利用いただけます。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/校異情報の生成.ipynb 有名なサービスとして「difff」がありますが、今回はPythonを用いて実装しています。 https://difff.jp/ テキスト間の差分の算出には、difflib.SequenceMatcherを使用しています。 https://docs.python.org/ja/3/library/difflib.html 使い方 出力方式として、HTMLファイルとTEIファイルの2種類を選ぶことができます。 HTML HTMLファイルの出力結果例は以下です。 XML XMLファイルの出力例は以下です。 <?xml version="1.0" encoding="utf-8"?> <?xml-model href="https://raw.githubusercontent.com/ldasjp8/tei-example/main/tei_all.rng" schematypens="http://relaxng.org/ns/structure/1.0" type="application/xml"?> <TEI xmlns="http://www.tei-c.org/ns/1.0"> <teiHeader> <fileDesc> <titleStmt> <title>Title</title> </titleStmt> <publicationStmt> <p>Publication</p> </publicationStmt> <sourceDesc> <listWit> <witness xml:id="t1">中村式五十音</witness> <witness xml:id="t2">中村式五十音又様</witness> </listWit> </sourceDesc> </fileDesc> </teiHeader> <text> <body> <p>あいうえお <lb/> <app xml:id="a1"> <lem wit="#t1">か</lem> <rdg wit="#t2">こけ</rdg> </app>きく <app xml:id="a2"> <lem wit="#t1">けこ</lem> <rdg wit="#t2">か</rdg> </app> <lb/> さしすせそ <lb/> た <app xml:id="a3"> <lem wit="#t1">ちぬ</lem> <rdg wit="#t2">じづ</rdg> </app>てと <app xml:id="a4"> <lem wit="#t1"/> <rdg wit="#t2"/> </app> </p> </body> </text> </TEI> 工夫した点として、TEI（Text Encoding Initiative）で定められているappタグを用いて出力します。そのため、appタグに対応したツールで可視化を行うことができます。 例えば、以下の「TEI Critical Apparatus Toolbox」を使用してみます。 http://teicat.huma-num.fr/witnesses.php ...
概要 Omeka SおよびOmeka Classicは、デジタルアーカイブ構築および人文（情報）学研究において、とても便利なツールです。 https://omeka.org/ REST APIを標準搭載し、モジュールおよびプラグインの追加などによる高い拡張性を持ちます。またIIIF関連ツール、翻刻支援ツール、時空間情報を取り扱うツールなど、さまざまな既存資産を利用することができます。 一方、サイトの見た目を変更するテーマ開発などについては、PHPおよびOmekaに対する知識が求められ、比較的難易度が高いと（個人的に）感じています。この点について、昨今はバックエンドとフロンドエンドを分離したHeadless CMSという使い方も普及しつつあります。 そこでOmeka ClassicをHeadless CMSとして使用し、Nuxt 3を用いたフロントエンド開発を試みました。Omekaの活用方法の一例として参考になれば幸いです。 Omeka Classicの準備 APIの有効化 以下を参考に、APIの有効化を行います。 https://omeka.org/classic/docs/Admin/Settings/API_Settings/ Access-Control-Allow-Originヘッダーの追加 .htaccessファイルにAccess-Control-Allow-Originヘッダーを追加します。 Header set Access-Control-Allow-Origin "*" # 追加 # Omeka .htaccess: Apache configuration file # This file is required for Omeka to function correctly. # --------------- # # Error Reporting # ... Omeka ClassicのAPI 以下のページにAPIがまとめられています。 https://omeka.readthedocs.io/en/latest/Reference/api/index.html 例えば、以下のようなURLから、アイテムに対する簡易な検索が可能です。（Omeka Classicでは詳細な検索ができないようです。本格的な利用にあたっては、Omeka Sを使用する必要がありそうです。） https://omeka.aws.ldas.jp/api/items?search=被 フロントエンドの開発 今回は勉強を兼ねて、Nuxt 3とVuetify 3を使ってみました。2022-07-08時点において、アプリの完成度は大変低いが、Omeka ClassicをHeadless CMSとして利用し得ることを確認できました。 https://omekac.netlify.app/ まとめ Omeka（SおよびClassic）を用いたシステム開発における一例として、参考になりましたら幸いです。 ...
Mirador 3 による画像比較ツールを作成しました。URLは以下です。 https://ldas-jp.github.io/viewer/input/ またGitHubリポジトリのURLは以下です。 https://github.com/ldas-jp/viewer 以下が入力フォームです。比較する画像のIIIFマニフェストファイルのURLとCanvasのURIを指定します。「例」にあるボタンをクリックすることで、入力例をご確認いただけます。 「開く」ボタンをクリックすると、以下のようにMirador 3が起動します。入力情報に基づく画像比較を行うことができます。 Mirador 3を用いた画像比較にあたり、ご活用いただけますと幸いです。
はじめに 備忘録的な意味合いの強い記事です。わかりにくい点も多々あるかと思いますが、ご容赦ください。 特に以下で紹介されている、IIIF Toolkitが使用するアノテーションエンドポイントの使い方について、参考になりましたら幸いです。 https://github.com/utlib/IiifItems/wiki/The-Mirador-Omeka-Annotator-Endpoint 概要 Omeka ClassicのIIIF Toolkitプラグインは、IIIFマニフェストファイルの読み込みや、画像へのアノテーションを行うことができるとても便利なツールです。 https://zenn.dev/nakamura196/books/2a0aa162dcd0eb/viewer/b37a8c 今回は、Omeka Classicとは独立して作成されたアノテーションデータを持っていることを前提として、それらのアノテーションをOmeka Classicに一括登録する方法を記事にします。 以下のGooble Colabのノートブックを用意しています。参考になりましたら幸いです。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/Omeka_ClassicのIIIF_Toolkitを用いたアノテーションの一括登録方法.ipynb 使い方 事前準備0 上記のノートブックを実行する前に、Omeka ClassicのAPIの有効化、およびAPIキーの発行を行う必要があります。 Omeka ClassicのAPIの有効化 以下に示すように、デフォルトではOFFになっているAPIの有効化を行います。 APIキーの発行 非公開のアイテムについては、APIキーを用いたアクセスが必要になるため、ユーザ毎にAPIキーを発行します。 ノートブックの実行 上記のノートブックに従って、Omeka ClassicのAPIを用いたデータ登録を行います。 結果 以下に示すように、アノテーションが一括登録されていることが確認できます。 まとめ Omeka ClassicのIIIF Toolkitが提供するAPIの扱い方など、参考になりましたら幸いです。
概要 Amazon Lightsailを用いたOmkea Sの構築方法を以下の記事にまとめました。 今回はAmazon Lightsailを用いたOmeka Classicの構築法方について紹介します。Omeka Classicは以下の本で紹介しているように、IIIF Toolkitを用いたアノテーション付与環境の構築などに有用です。 https://zenn.dev/nakamura196/books/2a0aa162dcd0eb Amazon Lightsail インスタンスの作成 以下のページにアクセスします。 https://lightsail.aws.amazon.com/ls/webapp/home/instances そして、以下の「Create Instance」ボタンをクリックします。 「Select a blueprint」において、「LAMP (PHP 7)」を選択します。 「Choose your instance plan」において、インスタンスプランを選択します。今回は最も低価格のプランを選びました。 起動したら、以下のインスタンスのページにアクセスして、「Connect using SSH」ボタンを押します。 以下の画面が表示されます。 Linux ip-172-26-9-30 4.19.0-20-cloud-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. ___ _ _ _ | _ |_) |_ _ _ __ _ _ __ (_) | _ \ | _| ' \/ _` | ' \| | |___/_|\__|_|_|\__,_|_|_|_|_| *** Welcome to the LAMP packaged by Bitnami 7.4.29-0 *** *** Documentation: https://docs.bitnami.com/aws/infrastructure/lamp/ *** *** https://docs.bitnami.com/aws/ *** *** Bitnami Forums: https://community.bitnami.com/ *** bitnami@ip-172-26-9-30:~$ インスタンス内での作業 ファイルの移動 まず、必要なファイルのダウンロードや移動を行います。 ...
概要 NDL OCRについて、これまではルビのテキスト化を行わない設定がデフォルトでした。これに対して、NDLの方々のご協力により、テキスト化を行うか否かを設定できるようにしていただきました。 https://github.com/ndl-lab/ndlocr_cli/ config.yamlの以下をTrueにするとルビのテキスト化機能が動作します。 yield_block_rubi: False また、以下の留意事項があるとのことです。ご利用される際はご注意ください。 必ずしもルビの振られた漢字の箇所で切れるわけではなく、複数箇所のルビがマージされて出力されてしまうことも多い ルビは字のサイズが小さいことから、〓になってしまうことも多い チュートリアル用のノートブックの更新 ルビのテキスト化オプションについて、チュートリアル用のGoogle Colabにも追加しました。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ndl_ocr_v2.ipynb rubyというオプションにチェックを入れると、ルビのテキスト化を行います。デフォルトでは、従来通りFalse（ルビのテキスト化は行わない設定）にしています。 また今回の機能追加に合わせて、PDFを入力とした際の不具合修正や、認識結果の出力方法の変更等を行いました。認識結果を保存したGoogleドライブへのリンクを出力し、リンク先で認識結果を確認する方法に統一しました。 操作方法については、今回の修正内容は含まれていませんが、以下のデモ動画を用意しています。Google Colabの使い方など、参考になりましたら幸いです。 https://youtu.be/46p7ZZSul0o
概要 現在Cultural Japanプロジェクトにおける検索アプリの更新を進めており、多言語データのアグリゲーションを行う必要がありました。本記事では、その方法に関する調査結果の備忘録です。 データ データとしては、以下のように、agential（人物を示す）フィールドに、id、ja、enの値を持つケースを想定します。 { "agential": [ { "ja": "葛飾北斎", "en": "Katsushika, Hokusai", "id": "chname:葛飾北斎" } ] } 上記のデータに対して、idでフィルタリング処理などを行いつつ、言語設定に合わせてjaまたはenの値を表示することを想定します。 理想的には、aggregationの結果として、以下のようなデータを取得したいです。 （jaを指定した場合） { "buckets": [ { "key": "葛飾北斎", "id": "chname:葛飾北斎", "doc_count": 1 } ] } （enを指定した場合） { "buckets": [ { "key": "Katsushika, Hokusai", "id": "chname:葛飾北斎", "doc_count": 1 } ] } 方法1: nested aggregationの利用 以下の記事を参考に、nested aggregationを試します。 https://discuss.elastic.co/t/aggregeations-with-different-keys-and-values-label-and-id/274218 DELETE test PUT test { "mappings": { "properties": { "agential": { "type": "nested", "properties": { "id": { "type": "keyword" }, "ja": { "type": "keyword" }, "en": { "type": "keyword" } } } } } } PUT test/_doc/1 { "agential": [ { "ja": "葛飾北斎", "en": "Katsushika, Hokusai", "id": "chname:葛飾北斎" } ] } GET test/_search { "query": { "bool": { "filter": [ { "nested": { "path": "agential", "query": { "bool": { "filter": [ { "term": { "agential.id": "chname:葛飾北斎" } } ] } } } } ] } }, "_source": [ "agential" ], "aggs": { "agential": { "nested": { "path": "agential" }, "aggs": { "id": { "terms": { "field": "agential.id" } }, "label": { "terms": { "field": "agential.ja" } } } } } } この場合、以下のような結果が返却されます。 ...
Omeka Sでアイテムやメディアの一括登録を行うためのBulk Importモジュールについて、version 3.3.28.0から3.3.33.2において、メディアを登録できない不具合があります。メディアの登録が必要な場合は、とりあえずversion 3.3.27.0以前のモジュールを使用するなど、回避策が必要です。 ただ、本件についてIssueを作成したところ、早速不具合を修正いただきました。 https://gitlab.com/Daniel-KM/Omeka-S-module-BulkImport/-/issues/10 7/1時点ではGitLab上のソースコードのみが修正された状態ですが、近くGitHubのReleasesにも追加されると思います。本モジュールをお使いの際はご注意ください。 なお、GitLabのソースコードからインストールする場合には、こちらのREADMEをご確認ください。具体的には、modulesディレクトリに移動して、以下のようなコマンドを実行します。 $ cd modules/ $ git clone https://gitlab.com/Daniel-KM/Omeka-S-module-BulkImport.git BulkImport Cloning into 'BulkImport'... remote: Enumerating objects: 7580, done. remote: Counting objects: 100% (1627/1627), done. remote: Compressing objects: 100% (746/746), done. remote: Total 7580 (delta 1056), reused 1163 (delta 750), pack-reused 5953 Receiving objects: 100% (7580/7580), 8.08 MiB | 20.02 MiB/s, done. Resolving deltas: 100% (5095/5095), done. $ cd BulkImport/ $ composer install --no-dev Installing dependencies from lock file Verifying lock file contents can be installed on current platform. Package operations: 12 installs, 0 updates, 0 removals - Downloading composer/installers (v2.1.1) - Downloading oomphinc/composer-installers-extender (2.0.1) - Downloading box/spout (v3.3.0) - Downloading codemirror/codemirror (5.65.1) - Downloading flowjs/flow-php-server (v1.0.3) - Downloading flowjs/flow.js (2.14.1) - Downloading hakre/xmlreaderiterator (v0.1.11) - Downloading mikehaertl/php-tmpfile (1.2.1) - Downloading mikehaertl/php-shellcommand (1.6.4) - Downloading mikehaertl/php-pdftk (0.9.2) - Downloading mtdowling/jmespath.php (2.6.1) - Downloading phpoffice/phpword (0.18.3) - Installing composer/installers (v2.1.1): Extracting archive - Installing oomphinc/composer-installers-extender (2.0.1): Extracting archive - Installing box/spout (v3.3.0): Extracting archive - Installing codemirror/codemirror (5.65.1): Extracting archive - Installing flowjs/flow-php-server (v1.0.3): Extracting archive - Installing flowjs/flow.js (2.14.1) - Installing hakre/xmlreaderiterator (v0.1.11): Extracting archive - Installing mikehaertl/php-tmpfile (1.2.1): Extracting archive - Installing mikehaertl/php-shellcommand (1.6.4): Extracting archive - Installing mikehaertl/php-pdftk (0.9.2): Extracting archive - Installing mtdowling/jmespath.php (2.6.1): Extracting archive - Installing phpoffice/phpword (0.18.3): Extracting archive Package box/spout is abandoned, you should avoid using it. No replacement was suggested. Generating autoload files 1 package you are using is looking for funding. Use the `composer fund` command to find out more! BulkImportの利用にあたり、参考になりましたら幸いです。 ...
Google Colabを用いたNDLOCRアプリの使い方の動画を作成しました。参考になりましたら幸いです。 https://youtu.be/46p7ZZSul0o 動画中で使用されているブログは以下です。 なお、「初期セットアップ」の部分は動画をトリミングしています。実際には3~5分程度かかりますので、ご注意ください。
概要 先日、Omeka Sのデータをダウンロードするプログラムを作成しました。 今回は、AWS Copilotを使用して、上記のプログラムを定期的に実行してみます。 AWS Copilotのインストール 以下を参考にしてください。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/AWS_Copilot.html ファイルの準備 任意の場所で、Dockerfile、main.sh、.envの3ファイルを作成します。 Dockerfile FROM python:3 COPY *.sh . CMD sh main.sh main.sh set -e export output_dir=../docs # Omeka Sからデータをダウンロードするプログラム export repo_tool=https://github.com/nakamura196/omekas_backup.git dir_tool=tool dir_dataset=dataset # フォルダが存在したら if [ -d $dir_tool ]; then rm -rf $dir_tool rm -rf $dir_dataset fi # clone git clone --depth 1 $repo_tool $dir_tool git clone --depth 1 $repo_dataset $dir_dataset # requirements.txt cd $dir_tool pip install --upgrade pip pip install -r requirements.txt # 実行 cd src sh main.sh # copy odir=../../$dir_dataset/$subdir mkdir -p $odir cd $odir cp -r ../../$dir_tool/data . cp -r ../../$dir_tool/docs . # git git status git add . git config user.email "$email" git config user.name "$name" git commit -m "update" git push # 後処理 cd ../../ rm -rf $dir_tool rm -rf $dir_dataset .env api_url=https://dev.omeka.org/omeka-s-sandbox/api github_url=https://<個人アクセストークン>@github.com/<ユーザ名>/<リポジトリ名>.git username=nakamura email=nakamura@example.org dirname=dev 以下、説明です。 ...
Omeka Classicのデータをダウンロードするプログラムを作成しました。以下のリポジトリで公開しています。 https://github.com/nakamura196/omekac_backup また、本プログラムの実行例を示すGoogle Colabを作成しました。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/omeka_classic_backup.ipynb 上記のチュートリアルでは、以下のOmeka Classicのサイトを対象に、データのダウンロードを実行します。 https://jinmoncom2017.omeka.net/ 実行後、docsフォルダにapiのダウンロード結果が出力されます。 上記のデータをバックアップ等にご利用いただけます。Omeka Classicを利用される際の参考になりましたら幸いです。