概要 vue3とbabylon.jsの双方向のやりとりを行うプログラムを試作しました。以下のリンク先で内容をご確認いただけます。 https://youtube.com/shorts/BIdj-3T2_z8 デモサイト https://nakamura196.github.io/nuxt3-babylonjs/9 ソースコード https://github.com/nakamura196/nuxt3-babylonjs/blob/main/pages/9/index.vue まとめ 参考になりましたら幸いです。
概要 Hugging Face Spaceを用いたNDL古典籍OCRのウェブアプリを作成しました。以下でお試しいただけます。画像アップロードして、1分程度すると、OCR結果のテキストとJSONデータが表示されます。 https://huggingface.co/spaces/nakamura196/ndl_kotenseki_ocr 本アプリの作成にあたっては、以下の記事を参考にさせていただきました。 https://qiita.com/relu/items/e882e23a9bd07243211b 使い分け NDL古典籍OCRを試す環境として、Google Colabを用いたチュートリアルを別途用意しています。 上記では無料でGPUを使用することができるため、高速なOCR処理が可能です。一方、ノートブックの初回起動時に、関連するライブラリやモデルのダウンロードを行うため、4分程度のセットアップ時間がかかってしまう点等に課題があります。 一方、今回Hugging Face Spaceを用いた作成したアプリケーションでは、72時間連続して使用されない（2023年2月時点）限り、OCR処理を即座に実行することが可能です。さらに、Web APIによる利用も可能といった点が挙げられます。（APIによる利用については後述します。）ただし、無料枠ではGPUが使用できないため、1画像あたり1分程度の処理時間がかかる点が課題です。（有料枠でGPUを使用することもできます。） APIによる利用 APIによる利用例を試すことができるノートブックを用意しました。504 Gateway Time-outというエラーが発生してしまう場合もありますが、参考になりましたら幸いです。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/GradioのAPIを用いたNDL古典籍OCRの例.ipynb まとめ NDL古典籍OCRの精度（≠速度）を試してみる場合など参考になりましたら幸いです。
概要 NDL古典籍OCRをAmazon EC2のCPU環境で実行してみましたので、その備忘録です。高額になりがちなGPU環境を用意せずに実行できる点が利点ですが、1画像あたり30秒から1分程度の時間がかかりますので、ご注意ください。 本環境の構築にあたり、以下の記事を参考にしています。 https://qiita.com/relu/items/e882e23a9bd07243211b インスタンス クイックスタートのUbuntuを選択します。 インスタンスタイプについえは、t2.medium以上をおすすめします。それより小さいインスタンスだと、エラーが発生しました。 サーバ内での設定 sshでログインし、以下を実行します。 sudo apt-get update && sudo apt-get upgrade -y sudo apt -y install build-essential sudo apt -y install libgl1-mesa-dev libglib2.0-0 sudo apt -y install unzip sudo apt install -y python3-pip sudo apt install -y python3.10-venv python3 -m venv app source app/bin/activate pip install --upgrade pip git clone https://github.com/ndl-lab/ndlkotenocr_cli.git cd ndlkotenocr_cli vi requirements.txt requirements.txtを開き、scikit-imageのバージョンを除く。また、torchとtorchvisionを追加する。 click lmdb==1.2.1 natsort==7.1.1 nltk==3.6.6 numpy==1.22.4 albumentations==1.2.1 opencv-python==4.6.0.66 protobuf==3.19.6 pyyaml scikit-image # scikit-image==0.16.2 scipy==1.7.3 lightgbm==3.3.2 transformers==4.19.1 pandas==1.3.5 mmcls==0.23.1 mmdet==2.25.0 datasets==2.2.1 jiwer==2.3.0 wheel torch torchvision 引き続き以下を実行する。 ...
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で簡単に抽出することができます。あなたのプロジェクトに適した方法を選んでください。
概要 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": "!悪党$" # 「悪党で終わらない」 } ] } ただし、上記のクエリは完全ではなく、「悪党と悪党」といった値を持つものも除外してしまう点に注意が必要です。 まとめ 誤った理解をしている点もありそうですが、参考になりましたら幸いです。
概要 これまで、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だけを公開する方が、はるかに良い方法です。 ...
概要 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 以下、ログイン後に実行 ...
概要 ジャパンサーチでは、ジャパンサーチ内で使われている画面の構成要素を、部品としてジャパンサーチ以外のウェブサイトでも利用できる機能であるウェブパーツを提供しています。 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となっているリソースにアクセスしてみます。 ...
Nuxt3のSSRをVercelでホスティングする機会がありましたので、その備忘録です。 ビルド設定について、以下のように、Output Directoryを.output/serverに設定する必要がありました。 またCORSを有効化するにあたり、以下の記事が参考になりました。 https://vercel.com/guides/how-to-enable-cors 具体的には、プロジェクトのルートに以下のフォルダを置くことで対応できました。 { "headers": [ { "source": "/api/(.*)", "headers": [ { "key": "Access-Control-Allow-Credentials", "value": "true" }, { "key": "Access-Control-Allow-Origin", "value": "*" }, { "key": "Access-Control-Allow-Methods", "value": "GET,OPTIONS,PATCH,DELETE,POST,PUT" }, { "key": "Access-Control-Allow-Headers", "value": "X-CSRF-Token, X-Requested-With, Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version" } ] } ] } 間違った記述もあるかもしれませんが、参考になりましたら幸いです。
Babylon.jsとNuxt3とVuetifyを組み合わせて使用する機会がありましたので、その備忘録です。 構築したサイトは以下でご確認いただけます。 https://nakamura196.github.io/nuxt3-babylonjs/ ソースコードは以下です。 https://github.com/nakamura196/nuxt3-babylonjs 今回の組み合わせでアプリを開発される際の参考になりましたら幸いです。
概要 IIIF Presentation Validatorは、その名の通り、IIIFプレゼンテーションAPIの検証を行うためのツールです。 https://presentation-validator.iiif.io/ 以下の記事で、その使い方を説明しています。 今回、以下の記事で紹介するIIIF Presentation API v3に対応したマニフェストファイルの作成にあたり、ローカル環境での検証が必要になりました。 そこで、本ツールのローカル環境へのインストールを行いましたので、その備忘録です。 インストールの方法 以下に説明がありますが、Step oneを実行するとうまくいきませんでした。（こちらのIssueも上がっていました。） https://github.com/IIIF/presentation-validator#local-installation そこで少し方法を変えて、以下のように実行することで、ローカル環境でうまく実行できました。 git clone https://github.com/IIIF/presentation-validator.git cd presentation-validator pip install -r requirements.txt python iiif-presentation-validator.py 上記により、localhost:8080 で本ツールが起動します。 ローカル環境のマニフェストファイルの検証方法 （よりよい方法があるかもしれませんが…） 検証したいマニフェストファイルを格納したディレクトリで、ローカルサーバを起動します。例えば、以下のように実行します。 python -m http.server これにより、localhost:8000 でローカルサーバが起動しますので、http://localhost:8000/manifest.jsonといったURLでマニフェストファイルにアクセスできます。 このURLを以下のようにツールに登録することで、マニフェストファイルの検証が可能です。 エラー等が生じた場合には、マニフェストファイルを編集して、再度上記の「Go!」ボタンをクリックすることで、再度検証することができます。 その他 以下のようなURLにアクセスすることによっても検証を行うことができます。この場合、検証結果はjsonで返却されます。 http://localhost:8080/validate?version=3.0&url=http://localhost:8000/manifest.json { "okay": 1, "warnings": [ ], "error": "", "errorList": [ { "title": "Resolve Error", "detail": "The manifest id (https://dl.ndl.go.jp/api/iiif/2585098/R0000003/full/full/0/default.jpg) should be the same as the URL it is published at (http://localhost:8000/manifest.json).", "description": "", "path": "/id", "context": "{ 'id': '...'}" } ], "url": "http://localhost:8000/manifest.json" } まとめ IIIFマニフェストファイルを検証する際の参考になりましたら幸いです。 ...