Virtuosoが停止した際の再起動のためのコマンドの備忘録です。誤りなどあるかもしれませんが、参考になりましたら幸いです。 virtuoso-tの確認 which virtuoso-t > /usr/local/bin/virtuoso-t virtuoso.iniの場所の確認 sudo find / -name virtuoso.ini > ... > /usr/local/var/lib/virtuoso/db/virtuoso.ini > ... lckファイルの削除と起動 sudo rm -rf /usr/local/var/lib/virtuoso/db/virtuoso.lck sudo /usr/local/bin/virtuoso-t +configfile /usr/local/var/lib/virtuoso/db/virtuoso.ini
概要 Cultural JapanのRDFストアには、展覧会に関する情報が格納されています。rdf:typeにtype:展覧会を指定する以下のようなクエリを用いて、一覧を取得できます。 PREFIX type: <https://jpsearch.go.jp/term/type/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> select distinct * where { ?s rdf:type type:展覧会; rdfs:label ?label . } https://ld.cultural.jp/snorql/?query=select+distinct+*+where+{ %3Fs+rdf%3Atype+type%3A展覧会%3B +++++++rdfs%3Alabel+%3Flabel+.+ } ++ これらの展覧会の情報を活用するための一例について紹介します。 展覧会の一覧 各展覧会は、jps:temporalやjps:spatialといった値を持っています。（これらは複数の値を持つ場合があります。） https://ld.cultural.jp/data/apmoa-exhib-2021-soga そこで以下のようなクエリにより、展覧会のメタデータを含む、一覧の取得を行うことができます。 PREFIX type: <https://jpsearch.go.jp/term/type/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX schema: <http://schema.org/> PREFIX jps: <https://jpsearch.go.jp/term/property#> select distinct ?s ?label ?access ?image (GROUP_CONCAT(DISTINCT ?spatial_labels; separator="|") AS ?spacial_label) (GROUP_CONCAT(DISTINCT ?temporal_labels; separator="|") AS ?temporal_label) (GROUP_CONCAT(DISTINCT ?jps_temporals; separator="|") AS ?jps_temporal) (GROUP_CONCAT(DISTINCT IF(BOUND(?descriptions), CONCAT(str(?descriptions), IF(lang(?descriptions) != "", CONCAT("@", lang(?descriptions)), "")), ""); separator="|") AS ?description) (COUNT(DISTINCT ?workFeatured) AS ?countOfWorkFeatured) where { ?s rdf:type type:展覧会; rdfs:label ?label . optional { ?s jps:accessInfo/schema:provider/rdfs:label ?access . } optional { ?s schema:spatial/rdfs:label ?spatial_labels . } optional { ?s schema:temporal/rdfs:label ?temporal_labels . } optional { ?s jps:temporal/schema:description ?jps_temporals . } optional { ?s schema:description ?descriptions . } optional { ?s schema:image ?image . } optional {?s schema:workFeatured ?workFeatured } } group by ?s ?label ?spatial_label ?temporal_label ?description ?jps_temporal ?access ?image order by ?s https://ld.cultural.jp/snorql/?query=PREFIX+type%3A+<https%3A%2F%2Fjpsearch.go.jp%2Fterm%2Ftype%2F> PREFIX+rdfs%3A+<http%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23> PREFIX+schema%3A+<http%3A%2F%2Fschema.org%2F> PREFIX+jps%3A+<https%3A%2F%2Fjpsearch.go.jp%2Fterm%2Fproperty%23> select+distinct+ %3Fs+%3Flabel+%3Faccess+%3Fimage (GROUP_CONCAT(DISTINCT+%3Fspatial_labels%3B+separator%3D"|")+AS+%3Fspacial_label) (GROUP_CONCAT(DISTINCT+%3Ftemporal_labels%3B+separator%3D"|")+AS+%3Ftemporal_label) (GROUP_CONCAT(DISTINCT+%3Fjps_temporals%3B+separator%3D"|")+AS+%3Fjps_temporal) (GROUP_CONCAT(DISTINCT+IF(BOUND(%3Fdescriptions)%2C+CONCAT(str(%3Fdescriptions)%2C+IF(lang(%3Fdescriptions)+!%3D+""%2C+CONCAT("%40"%2C+lang(%3Fdescriptions))%2C+""))%2C+"")%3B+separator%3D"|")+AS+%3Fdescription) (COUNT(DISTINCT+%3FworkFeatured)+AS+%3FcountOfWorkFeatured) where+{ %3Fs+rdf%3Atype+type%3A展覧会%3B +++++++rdfs%3Alabel+%3Flabel+.+ ++ optional+{+%3Fs+jps%3AaccessInfo%2Fschema%3Aprovider%2Frdfs%3Alabel+%3Faccess+.++} ++optional+{+%3Fs+schema%3Aspatial%2Frdfs%3Alabel+%3Fspatial_labels+.+} ++++optional+{+%3Fs+schema%3Atemporal%2Frdfs%3Alabel+%3Ftemporal_labels+.+} ++++optional+{+%3Fs+jps%3Atemporal%2Fschema%3Adescription+%3Fjps_temporals+.+} ++++optional+{+%3Fs+schema%3Adescription+%3Fdescriptions+.+} ++++++optional+{+%3Fs+schema%3Aimage+%3Fimage+.+} ++optional+{%3Fs+schema%3AworkFeatured+%3FworkFeatured+} } group+by+%3Fs+%3Flabel+%3Fspatial_label+%3Ftemporal_label+%3Fdescription+%3Fjps_temporal+%3Faccess+%3Fimage order+by+%3Fs ...
概要 レイヤーのスライドショーを行うMirador3プラグインを開発しました。 https://youtu.be/r1ShHGqCs24 以下の記事にある通り、以前、Mirador2のカスタマイズにより実現しました。以下では「起絵図」のIIIF実装を試みています。 https://nakamura196.hatenablog.com/entry/2020/08/14/073700 今回はMirador3のプラグインとして開発を試みました。 リポジトリ https://github.com/nakamura196/mirador-layer-slideshow-plugin デモサイト https://nakamura196.github.io/mirador-layer-slideshow-plugin/ まとめ 改善の余地が多々ありますが、参考になりましたら幸いです。
概要 ALTO (Analyzed Layout and Text Object) XMLについて、GPT-4に問い合わせた結果を共有します。 https://www.loc.gov/standards/alto/ 必須項目 ALTO (Analyzed Layout and Text Object) XMLは、OCR生成テキストとそのレイアウトを表現するためのXMLスキーマです。その構造は非常に柔軟で、多くの要素と属性が存在しますが、必須の要素は限られています。 最も単純な形式のALTO XMLは、以下のような階層構造を持ちます： <alto>: ルート要素です。ALTO XMLスキーマのバージョンを示す@xmlns属性と@xmlns:xsi属性を持つ必要があります。また、<Description>と<Layout>という二つの子要素を持つ必要があります。 <Description>: ファイルのメタデータを含みます。この要素自体に必須の子要素はありませんが、通常、<MeasurementUnit>, <sourceImageInformation>や<OCRProcessing>などの子要素を含むでしょう。 <Layout>: ファイルの物理的なレイアウトを表現します。これは<Page>という子要素を1つ以上含む必要があります。 <Page>: 一つのページを表現します。この要素は@IDと@WIDTHと@HEIGHTという三つの必須属性を持つべきです。また、<PrintSpace>という子要素を1つ持つことができます。 上記の要素はALTO XMLの最も基本的な構造を表現していますが、テキストの内容やそのレイアウトを詳細に表現するためには、さらに多くの要素と属性を使用することが可能です。例えば、<PrintSpace>, <TextBlock>, <TextLine>, <String>などの要素を使用することで、テキストの物理的な配置や内容を詳細に表現することができます。それぞれの要素や属性の詳細については、ALTO XMLスキーマのドキュメンテーションを参照してください。 OCRProcessing要素 OCRProcessing要素は、ALTO XML内の<Description>エレメント内で使用されます。この要素は、特定のOCRプロセスに関する情報を格納します。それは以下のサブ要素を持つことができます： ocrProcessingStep: OCR処理の各ステップを記述します。この要素は processingDateTime, processingAgency, processingSoftware, processingStepSettings, processingStepDescriptionといった属性を持つことができます。 以下に、OCRProcessingエレメントの使用例を示します： <Description> ... <OCRProcessing ID="OCR1"> <ocrProcessingStep> <processingDateTime>2023-08-01T00:00:00</processingDateTime> <processingAgency>Agency Name</processingAgency> <processingSoftware> <softwareCreator>Software Creator Name</softwareCreator> <softwareName>Software Name</softwareName> <softwareVersion>Software Version</softwareVersion> </processingSoftware> <processingStepSettings>Settings</processingStepSettings> <processingStepDescription>Description of the processing step</processingStepDescription> </ocrProcessingStep> </OCRProcessing> ... </Description> ここで、processingDateTimeはOCR処理が行われた日時を表し、processingAgencyはその処理を行った機関名を表します。processingSoftwareはOCR処理に使用されたソフトウェアに関する情報を含み、processingStepSettingsとprocessingStepDescriptionはそれぞれ設定と処理手順の説明を提供します。 ...
Nuxt3でURLクエリの変更をwatchで監視しようと思い、以下のように書いてみましたが、URLクエリが変更されても、watchは機能しませんでした。 <script lang="ts" setup> const route = useRoute() watch( route, () => { console.log(route['query']) } ) </script> そこで、以下の記事を参考にさせていただきました。 https://qiita.com/YumaInaura/items/9c86ed91d56402e816db 以下のような記述に変更することで、URLクエリに合わせて、watchが機能しました。 <script lang="ts" setup> const route = useRoute() watch( () => route.query, () => { console.log(route['query']) } ) </script> 色々とわかっていない点が多いですが、他の方の参考になりましたら幸いです。
概要 CETEIceanとNuxt3を使ったサンプルリポジトリを作成しました。 https://github.com/TEIC/CETEIcean 以下のissueを参考にさせていただきました。 https://github.com/TEIC/CETEIcean/issues/27 以下で紹介されているスクリプトでは、CETEIceanのv1.8.0では動作しなかったため、CETEIceanのv1.8.0とNuxt3で動作する最小限のリポジトリを作成しました。 デモページ https://nakamura196.github.io/ceteicean-nuxt3 ソースコード https://github.com/nakamura196/ceteicean-nuxt3 主なファイル https://github.com/nakamura196/ceteicean-nuxt3/blob/main/app.vue まとめ 参考になりましたら幸いです。またCETEIceanを開発してくださっている方々に感謝いたします。
Apache Solrのフィールドがどのようにインデックスされているか確認する方法のメモです。 Schema APIを使う SolrのSchema APIを使って、特定のフィールドがどのように定義されているかを確認できます。下記は特定のフィールドに対するリクエストの例です。 http://localhost:8983/solr/{core_name}/schema/fields/{field_name} このURLにブラウザからアクセスしたり、curlコマンドなどを使ってGETリクエストを送ると、特定のフィールドに関する情報がJSON形式で返されます。その中にはそのフィールドがどのようにインデックスされているかに関する情報も含まれます。 Solr管理UIを使う Solrが提供している管理UIからもフィールドがどのようにインデックスされているかを確認できます。 Solrの管理UI (http://localhost:8983/solr) をブラウザで開きます。 左側のメニューから「Core Selector」を選択し、該当のコアを選びます。 コアを選択したら、メニューから「Schema Browser」を選択します。 「Schema Browser」ページでフィールド名を選択すれば、そのフィールドがどのようにインデックスされているかに関する詳細情報が表示されます。 この2つの方法で、Solrに格納されているフィールドがどのようにインデックスされているかを確認できます。どちらの方法も、フィールドがどのような型で定義されているか、どのようなオプションが設定されているかなど、フィールドの定義に関する詳細な情報を提供します。
概要 Omeka Sに登録したメディア（画像など）に対して、転写や翻訳を可能にするモジュール「Scripto」について紹介します。 https://omeka.org/s/modules/Scripto/ インストール 本モジュール自体のインストールは、他の通常のモジュールと同じです。 一方、本モジュールのインストールに加えて、mediawikiをセットアップする必要があります。 Omeka Sが動作している環境であれば、mediawikiのセットアップに必要な環境も揃っているはずですので、以下のコマンドなどにより、mediawikiのダウンロードやセットアップを行います。 wget https://releases.wikimedia.org/mediawiki/1.40/mediawiki-1.40.0.zip unzip mediawiki-1.40.0.zip mv mediawiki-1.40.0 /home/bitnami/htdocs/mediawiki セットアップの環境後、例えば以下のようなURLから、mediawikiのAPIのURLにアクセスできます。 https://omekas.aws.ldas.jp/mediawiki/api.php 上記のURLをScriptoモジュールの有効後に表示される設定画面に反映します。 アイテムセットの作成 本モジュールの利用にあたっては、transcribeの対象とするアイテムを含むアイテムセットを指定する必要があります。 今回は、以下のアイテムセットを例に使用します。 https://omekas.aws.ldas.jp/omeka4/s/bootstrap/item-set/9 プロジェクトの追加 管理画面右下のモジュールに「Scripto」が追加されます。そのリンクから以下のダッシュボードを開き、プロジェクトを作成します。 タイトルとアイテムセット、および転写したテキストをインポートするためのプロパティを指定します。本モジュールでは、プロジェクトにおいて転写内容が承認されるまではアイテムのメタデータとして記録されず、転写内容が承認され、プロジェクトにおいて後述するコンテンツのインポートを実行後、ここで指定したプロパティの値として登録されます。 右上のActionsボタンからSync projectを選択する。 以下のように、アイテムが登録されます。 サイトに追加 転写のプロジェクトは独立したページが用意されます。そのため、当該ページにアクセスするため、Omeka Sの公開サイトのナビゲーションなどにプロジェクトへのリンクを設置します。 プロジェクトの公開ページ プロジェクトは以下のような公開ページを提供します。 各メディアは、以下のような編集画面を持ちます。画面左にメディアが表示され、画面右にエディタが表示されます。また承認済みか、完了済みか、等のフラグを持ちます。 https://omekas.aws.ldas.jp/omeka4/scripto/s/default/1/1/8/10/edit 管理画面では、更新履歴等が閲覧できます。 各アイテムの編集履歴も閲覧できます。 データはmediawikiに保存されます。 https://omekas.aws.ldas.jp/mediawiki/index.php?title=1:8:10 管理画面においても、以下のように登録したテキストデータを確認できます。 インポート 状態がApprovedになったメディアについては、「Import content」から、mediawikiから、Omeka Sのメタデータとして登録できます。 結果、以下のように、テキストデータがメタデータとして登録されます。 まとめ プロジェクトごとに、以下のようにReviewer等を設定することができます。 他にも様々な機能が提供されていますので、柔軟にプロジェクトの設定を変更することができそうです。Omeka Sを用いた転写・翻訳等を行う際の参考になりましら幸いです。
概要 IIIF Presentation APIを追加するIiifPresentationモジュールを試しましたので、その備忘録です。 https://omeka.org/s/modules/IiifPresentation/ なお、簡単に試した限りでは、以下のIIIF Serverモジュールが提供する機能と大きな違いはないように思いました。 https://omeka.org/s/modules/IiifServer/ 違いとして、今回のモジュールはOmeka Teamによって開発されたモジュールであり、さらに細かな設定をせずに利用できる点が利点として考えられました。 インストール 通常のモジュールのインストール手順と同じです。 使い方 アイテムIDが8であるリソースを対象に、本モジュールが提供する機能を試してみます。 以下がベースのURLです。 https://omekas.aws.ldas.jp/omeka4/ 以下のURLにアクセスすると、IIIF manifestを取得できます。 https://omekas.aws.ldas.jp/omeka4/iiif-presentation/3/item/8/manifest 次に、以下のURLにアクセスすると、Miradorのビューアへリダイレクトされます。 https://omekas.aws.ldas.jp/omeka4/iiif-presentation/3/item/8 その他、複数のアイテムIDやアイテムセットのIDを指定することで、IIIFコレクションの取得や閲覧が可能なようです。詳細については、以下をご確認ください。 https://omeka.org/s/docs/user-manual/modules/iiifpresentation/ まとめ IIIFモジュールやビューアに関するモジュール（MiradorやUniversal Viewer）をインストールせずに、本モジュールのみでマニフェストの生成とビューアによる閲覧を実現できる点は有効だと思いました。 一方、カスタマイズ性はIIIFモジュールなどのほうが優れているように思われますので、用途に応じて使い分けるのがよさそうに思いました。 他の方の参考になりましたら幸いです。
概要 2023/07/20時点において、まだベータ版のようですが、Omeka Sで変更履歴を記録するモジュール「Omeka-S-module-HistoryLog」を試す機会がありましたので、備忘録です。 https://github.com/Daniel-KM/Omeka-S-module-HistoryLog インストール 以下に記載がありますが、事前にGenericモジュールをインストールする必要がある場合があります。 https://github.com/Daniel-KM/Omeka-S-module-HistoryLog#installation その他は通常のモジュールのインストール手順と同じです。インストール後、モジュール一覧に以下のように表示されます。 使い方 例えば、特定のアイテムのタイトルを以下のように更新してみます。 保存すると、画面の右下に「History Log」という項目が表示され、最終更新日と更新イベントへのリンクが表示されます。 リンクをクリックすると、変更イベントの一覧が表示され、いつ・誰が・どのような更新を行なったかを確認できます。 まとめ StrapiやDrupalなどのCMSでは標準的な機能ですが、変更履歴を記録できるようになると、さらに便利になるように思います。 まだ開発中のモジュールのため、ご利用される際は注意が必要ですが、参考になりましたら幸いです。
概要 Omeka Classic IIIF Toolkitで使用されているMiradorを2.7にアップデートしました。以下のページでソースコードをご確認いただけます。 https://github.com/nakamura196/IiifItems また、以下のURLから、zipファイルをダウンロードできます。 https://github.com/nakamura196/IiifItems/releases/download/1.1.1/IiifItems-1.1.1.zip できるようになること Mirador 2.7を使用することにより、IIIFのImage APIに非対応の画像でもビューアに表示することが可能になります。これにより、一般に公開されている画像に対しても、Miradorを用いたアノテーションの付与および管理が可能になります。 この利点を活かして、画像のURLを含むCSVファイルを用意して、Omeka Classicに登録する以下の記事を執筆しています。 まとめ Omeka Classic IIIF Toolkitの利用にあたり、参考になりましたら幸いです。 なお、Omeka Classic IIIF Toolkitを開発してくださったトロント大学図書館の方々に感謝いたします。
概要 Omeka Classic IIIF Toolkitにデータを一括登録する方法を説明します。Omeka Classic IIIF Toolkitのセットアップについては、以下を参考にしてください。 また、以下の記事の内容を発展させ、excelデータを入力データとして、より簡便に使用できるようにしたものです。 excelファイルの準備 以下のようなexcelファイルを準備します。 https://github.com/nakamura196/000_tools/blob/main/data/sample.xlsx 「collection」「item」「annotation」の3つのシートを用意します。 collection manifest_uri https://d1fasenpql7fi9.cloudfront.net/v1/manifest/3437686.json item title canvas_uri width height image_url manifest_uri 校異源氏物語. 巻一 [4] https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/4 6890 4706 https://www.dl.ndl.go.jp/api/iiif/3437686/R0000004/full/full/0/default.jpg https://d1fasenpql7fi9.cloudfront.net/v1/manifest/3437686.json 校異源氏物語. 巻一 [4] https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 6890 4706 https://www.dl.ndl.go.jp/api/iiif/3437686/R0000005/full/full/0/default.jpg https://d1fasenpql7fi9.cloudfront.net/v1/manifest/3437686.json annotation chars x y w h canvas_uri tag 3125 4898 4008 241 79 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/4 序 2910 868 147 140 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/4 913.36 たH 2228 226 586 156 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/4 或は撮影して、 897 3517 83 434 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/4 一 810 3528 30 17 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/4 序 6018 1055 65 65 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 二 6025 3535 49 39 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 殆んどあらゆる現存貴重資料に及び、 5889 707 86 1090 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 一字をも忽にしない細緻な〓究は、 5889 1837 86 1012 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 フイルム等 5501 3614 76 323 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 大島雅太郞氏· 916 3491 89 436 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 序 807 1048 65 61 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 三 815 3517 61 57 https://www.dl.ndl.go.jp/api/iiif/3437686/canvas/5 python 以下のライブラリをインストールします。 ...
概要 Mirador3のプラグインとして、ウインドウをコピーするプラグインを作成しました。 なお本機能は以下のプラグインですでに提供されているものです。 https://github.com/ProjectMirador/mirador-plugin-demos そのため、本プラグインはプラグインの開発手順を学ぶために作成しています。そのような観点で、本プラグインが参考になりましたら幸いです。 画面例は以下です。 ソースコードは以下です。 https://github.com/nakamura196/mirador-copy-window-plugin デモサイトは以下です。 https://nakamura196.github.io/mirador-copy-window-plugin/ 開発メモ 本プラグインの開発にあたり、まず以下のリポジトリをcloneし、変更を加えていきました。 https://github.com/ProjectMirador/mirador-dl-plugin src/index.js まず以下のファイルについて、miradorDownloadをMiradorCopyWindowに書き換えました。 https://github.com/nakamura196/mirador-copy-window-plugin/blob/main/src/index.js src/MiradorCopyWindow.js 以下のファイルが主に編集するファイルです。 https://github.com/nakamura196/mirador-copy-window-plugin/blob/main/src/MiradorCopyWindow.js 本ファイルは、まず以下のファイルの内容をコピーしました。 https://github.com/ProjectMirador/mirador-plugin-demos/blob/master/src/plugins/copy-window.js まず末尾の以下の記述から説明します。 export default { target: 'WindowTopMenu', mode: 'add', component: CopyWindowComponent, mapDispatchToProps: mapDispatchToProps, mapStateToProps: mapStateToProps, } targetとmode targetはコンポーネントを設置する場所を指定します。またmodeはコンポーネントの追加方法を指定します。modeについては、addやwrapという選択肢があるようでした。 以下、targetの値の例です。 WindowTopMenu 各ウインドウ上部のメニューの部分です。 WorkspaceControlPanelButtons ワークスペースのパネル部分です。 AnnotationSettings アノテーションの設定画面です。 最後のAnnotationSettingsおよびmodeにwrapが指定されているプラグインとして、以下のMiradorのアノテーション付与モジュールがありました。 https://github.com/ProjectMirador/mirador-annotations/blob/master/src/plugins/miradorAnnotationPlugin.js mapDispatchToPropsとmapStateToProps これがはじめ理解しづらかった（そしてまだ適切に説明できるほど理解できていない）のですが、propsに渡すdispathとstateを定めた変数を指定します。 dispatchについては、以下の変数を与えてます。 const mapDispatchToProps = (dispatch, { windowId }) => ({ copyWindow: () => dispatch(copyWindowAction(windowId)), }); copyWindowActionの具体的な内容は以下です。既存のwindowを取得して（1）、不要な変数を削除した上でwindowをコピーして(2)、それをaddWindow（3）しています。 const copyWindowAction = (windowId) => (dispatch, getState) => { const window = getState().windows[windowId]; // 1 const cleanedWindow = omit(window, [ 'id', 'companionWindowIds', 'thumbnailNavigationId', ]); // 2 dispatch(mirador.actions.addWindow(cleanedWindow)); // 3 }; stateについては、以下の変数を与えています。以下の例は少し特殊で、stateをすべてpropsに渡す設定となっています。他のプラグインでは、必要な値のみをstateから抽出して、propsに渡しているようでした。 const mapStateToProps = (state) => ({ state: state, }); 実際、本プラグインでは、mapStateToPropsでpropsに渡された値は使用されていないため、この記述はなくてもよいはずです。そのため、以下でもmapStateToPropsの記述は省略しています。 https://github.com/nakamura196/mirador-copy-window-plugin/blob/main/src/MiradorCopyWindow.js component 最後にcomponentです。以下のように、コンポーネントで表示する内容を記述しています。 ...
概要 wikibase.cloudでQuickStatementsを試してみましたので、その備忘録です。 以下の記事を参考にさせていただきました。 https://qiita.com/higa4/items/10affb47215def42d8e0 追加 上記の記事の通り、csvファイルをインポートしています。 ところが、以下のようなエラーが発生しました。 原因は、独自に立てたwikibaseインスタンスに、必要なプロパティが未登録だったことが原因でした。 Property [[Property:P1814|P1814]] not found WikibaseSyncなどを使って、事前に（特にwikidataと同じIDの）プロパティを登録しておく必要があることがわかりました。 そのため、ラベルに関する情報のみを登録する以下のようなデータを登録してみました。 qid,Lja,Len,Dja,Den,qal1545 ,タイトル,title,""""説明,desc,1 結果、以下のようにデータの新規登録ができました。 更新 次のコマンドで、上記で登録したQ59の更新を試みました。 qid,Lja,Len,Dja,Den,qal1545 Q59,変更後のタイトル,updated title,""""変更後の説明,updated desc,1 結果、以下のように、いずれの値も更新することができました。 まとめ ほんの一例ですが、QuickStatementsを試してみました。APIでの登録例を以下の記事で紹介していますが、CSVによる登録はユーザフレンドリーな機能だと感じました。 他の方の参考になりましたら幸いです。
概要 以下のWikibaseSyncを試す機会がありましたので、その備忘録です。 https://github.com/the-qa-company/WikibaseSync 以下の論文で、上記のツールを知りました。 https://doi.org/10.11517/jsaisigtwo.2022.SWO-056_04 インストール ソースコードや関連ライブラリをインストールします。 !get clone https://github.com/the-qa-company/WikibaseSync cd WikibaseSync !pip install -r requirements.txt Bot Accountの作成 事前に用意したWikibaseにアクセスし、「Special pages」から、「Bot passwords」をクリックします。 以下の画面で、「Bot name」を入力します。 次の画面で、以下の3つにチェックを入れます。 Give him the follwing rights: “High-volume editing”, “Edit existing pages” and “Create, edit, and move pages” 結果、以下のようなメッセージが表示され、パスワードを取得することができます。 The bot password for bot name "WikidataUpdater" of user "Nakamura" was created. The new password to log in with Nakamura@WikidataUpdater is xxxxxxxxxxxxxx. Please record this for future reference. (For old bots which require the login name to be the same as the eventual username, you can also use Nakamura as username and WikidataUpdater@xxxxxxxxxxxxxx as password.) Return to Special:BotPasswords. そして、以下の説明にしたがって、インストールしたソースコードの設定ファイルに、上記のBotに関する情報を入力します。 ...
概要 wikibaseのapiをpythonクライアントから使用する機会がありましたので、その備忘録です。 以下のライプラリを使用しました。 https://wikibase-api.readthedocs.io/en/latest/index.html インストール 以下でインストールします。 !pip install wikibase-api Read 今回は、以下のwikibaseインスタンスに対して処理を行います。 https://nakamura196.wikibase.cloud/ from wikibase_api import Wikibase api_url = "https://nakamura196.wikibase.cloud/w/api.php" wb = Wikibase(api_url=api_url) r = wb.entity.get("Q1") print(r) 上記により、Q1に関する情報を取得することができました。 Create 認証情報の取得 アイテムの作成などを行う際には、以下のどちらかの方法で認証を行う必要がありました。 Authentication using OAuth Authentication with a user account 後者はBot passwordsを作成する方法で、以下の記事でも作成方法を紹介しています。 今回は前者の方法を試します。 「Special pages」の「OAuth consumer registration」を選択します。 「Request a token for a new OAuth 1.0a consumer.」と「Request a token for a new OAuth 2.0 client.」の2つの作成方法がありますが、前者を選択します。 項目を埋めていきます。 今回はテストのため、すべての項目にチェックを入れました。 結果、以下のようなページが表示され、認証情報を取得できます。 実行 .envファイルを作成します。 consumer_key=xxx consumer_secret=yyy access_token=zzz access_secret=aaa load_dotenvを使って認証情報をロードして、設定します。 ...
概要 Dataverseを試す機会がありましたので、その備忘録です。以下のデモ環境を使用します。 https://demo.dataverse.org/ アカウント作成 Sign Upからアカウントを作成します。 Dataverseの作成 Dataverseを作成してみます。 以下のようなDataverseを作成しました。 https://demo.dataverse.org/dataverse/nakamura196 Datasetの作成 Add Dataから、データセットを作成します。 以下が登録画面です。 以下が登録結果の画面です。 URLは以下になっており、自動的に付与されるDOIをシステム内の識別子として利用しているようでした。 https://demo.dataverse.org/dataset.xhtml?persistentId=doi:10.70122/FK2/HBXQPZ Whole Tale Access Datasetボタンのオプションに、Whole Taleというものがありました。 アカウントを作成して、Compute EnvironmentをJupyter Notebookに設定してみます。 Acknowledge allボタンを押します。 結果、以下のようなJupyter Notebookの環境が作成されました。 Pythonを使って、ダウンロードした画像を表示してみます。 上記のように、データセットやソースコードに対する動作確認や検証もシームレスに実行できるようでした。 Widgets 以下の「Thumbnails + Widgets」を押してみます。 以下の「Widgets」タブを表示してみます。 上記のコードを埋め込んでみると、以下に示すように、データセットに関する情報を埋め込み表示することができました。 https://codepen.io/satoru196/pen/NWEMvEV?editors=1000 API Pythonのライブラリを使ってみます。 https://pydataverse.readthedocs.io/en/latest/ ライブラリをインストールします。 !pip install pyDataverse データのダウンロード 以下のページを参考にしました。 https://pydataverse.readthedocs.io/en/latest/user/basic-usage.html#download-and-save-a-dataset-to-disk from pyDataverse.api import NativeApi, DataAccessApi from pyDataverse.models import Dataverse base_url = 'https://demo.dataverse.org' api = NativeApi(base_url) data_api = DataAccessApi(base_url) DOI = "doi:10.70122/FK2/HBXQPZ" dataset = api.get_dataset(DOI) files_list = dataset.json()['data']['latestVersion']['files'] for file in files_list: filename = file["dataFile"]["filename"] file_id = file["dataFile"]["id"] print("File name {}, id {}".format(filename, file_id)) response = data_api.get_datafile(file_id) with open(filename, "wb") as f: f.write(response.content) データセットの作成（demo.dataverse.orgでは権限がありませんでした。） demo.dataverse.orgでは権限がありませんでしたが、実施した内容をメモします。 ...
概要 wikibase.cloudを使ってみる機会がありましたので、その備忘録です。 ドキュメント 以下にマニュアルがありました。 https://www.mediawiki.org/wiki/Wikibase/Wikibase.cloud インスタンスの作成 はじめに独自ドメインを設定してみましたが、うまくいきませんでした。以下、記録だけ残します。以後、独自ドメインを諦めて、nakamura196.wikibase.cloudを使用しています。 失敗 独自のドメインを割り当てられるようでしたので、wikibase.aws.ldas.jpを入力しました。 Route 53で以下のような設定を行いました。 テーマの変更 以下のSet Skinで見た目を変更することができました。 Vector Modern Timeless データを作成してみる デフォルトで作成されるユーザでログインすると、以下の画面に遷移しました。 Satoru Itemを作成してみました。 以下のように作成されました。 プロパティ プロパティnameを作成してみます。 アイテムへのStatementsの追加 作成したプロパティ（P1）を使って、アイテム（Q1）にStatementsを追加してみます。 Query Service クエリサービスも問題なく動作しました。 タイムラインを用いた可視化例です。 #defaultView:Timeline select * where { ?s wikibase:timestamp ?o . } 棒グラフの表示例です。 #defaultView:BarChart select ?name (count(?name) as ?count) where { ?s <https://nakamura196.wikibase.cloud/prop/direct/P1> ?name . } group by ?name ...
概要 Amazon EC2に立てたVirtuosoのヘルスチェックを行う機会がありましたので、その備忘録です。 具体的には、何らかの不具合で、Virtuoso（https://xxx.zzz/sparql など）がエラーを返すようになってしまった際、その内容をメールで通知します。 方法 以下の記事で、Amazon EC2にVirtuoso RDFストアを構築する方法を紹介しています。 上記では、ELBを使用しています。上記の記事から1点だけ変更を行う必要があります。Health check pathを/に設定していますが、この部分をSPARQLエンドポイントへのパス（例えば/sparql）に変更します。 その後、以下の記事を参考に、CloudWatchやAmazon SNSの設定を行いました。 https://dev.classmethod.jp/articles/elb-healthcheck-monitoring-by-cloudwatch-alarm/ 結果 以下のようにモニタリングを行うことができるようになりました。 またアラート発生時には、以下のようなメールが届くようになりました。 You are receiving this email because your Amazon CloudWatch Alarm "virtuoso-unhealthyhostcount-alarm" in the US East (N. Virginia) region has entered the ALARM state, because "Threshold Crossed: no datapoints were received for 5 periods and 5 missing datapoints were treated as [Breaching]." at "Friday 14 July, 2023 08:05:30 UTC". View this alarm in the AWS Management Console: https://us-east-1.console.aws.amazon.com/cloudwatch/deeplink.js?region=us-east-1#alarmsV2:alarm/virtuoso-unhealthyhostcount-alarm Alarm Details: - Name: virtuoso-unhealthyhostcount-alarm - State Change: OK -> ALARM - Reason for State Change: Threshold Crossed: no datapoints were received for 5 periods and 5 missing datapoints were treated as [Breaching]. - Timestamp: Friday 14 July, 2023 08:05:30 UTC - AWS Account: xxxxxxxxxxxxxx - Alarm Arn: arn:aws:cloudwatch:us-east-1:xxxxxxxxxxxxxx:alarm:virtuoso-unhealthyhostcount-alarm Threshold: - The alarm is in the ALARM state when the metric is GreaterThanOrEqualToThreshold 1.0 for at least 5 of the last 5 period(s) of 60 seconds. Monitored Metric: - MetricNamespace: AWS/ApplicationELB - MetricName: UnHealthyHostCount - Dimensions: [TargetGroup = targetgroup/virtuoso] [AvailabilityZone = us-east-1a] [LoadBalancer = app/virtuoso/yyyyyyyyyyyyyyy] - Period: 60 seconds - Statistic: Minimum - Unit: not specified - TreatMissingData: breaching State Change Actions: - OK: - ALARM: [arn:aws:sns:us-east-1:xxxxxxxxxxxxxx:Default_CloudWatch_Alarms_Topic] - INSUFFICIENT_DATA: まとめ 同様の環境でVirtuosoを運用されている際の参考になりましたら幸いです。 ...
MUIのDialogコンポーネントにおいてonBackdropClickを使用したところ、以下の警告が発生しました。 Warning: Failed prop type: The prop `onBackdropClick` of `ForwardRef(Dialog)` is deprecated. Use the onClose prop with the `reason` argument to handle the `backdropClick` events. 警告メッセージは、Dialogコンポーネントの非推奨のprop onBackdropClickに関するものです。これは、このpropがあなたのコードのどこかで使用されているが、もはやサポートされていないか、使用が推奨されていないことを意味します。警告は代わりにonClose propを使用するように提案しています。 これを解決する方法は以下の通りです： 以前は、コードに以下のようなものがあったかもしれません： <Dialog open={isOpen} onBackdropClick={handleBackdropClick} > { /* ダイアログの内容 */ } </Dialog> 警告に従って、これをonClose propを使用するように更新する必要があります： <Dialog open={isOpen} onClose={(event, reason) => { if (reason === 'backdropClick') { handleBackdropClick(); } }} > { /* ダイアログの内容 */ } </Dialog> 上記のコードでは、onClose propは関数を取り、eventとreasonという2つの引数を受け取ります。reasonは’backdropClick’、’escapeKeyDown’、またはundefinedになる可能性があります。reasonが’backdropClick’かどうかをチェックすることで、ユーザーがダイアログボックスの外側をクリックしたときに関数handleBackdropClick()を実行できます。 以上のようにコードを更新すると、警告は表示されなくなりました。 ...