OpenCitations メタ: 方法論

著者: （1）アルカンジェロ・マッサリ、オープン学術メタデータ研究センター、ボローニャ大学古典文献学・イタリア研究科、ボローニャ、イタリア {arcangelo.massari@unibo.it} （２）ファビオ・マリアーニ、ロイプハナ大学哲学・芸術科学研究所、ドイツ、リューネブルク {fabio.mariani@leuphana.de} （３）イヴァン・ヘイビ、ボローニャ大学古典文献学・イタリア研究科オープン学術メタデータ研究センター、ボローニャ、イタリアおよびボローニャ大学古典文献学・イタリア研究科デジタル人文学先端研究センター（/DH.arc）{ivan.heibi2@unibo.it} （4）シルヴィオ・ペローニ、ボローニャ大学古典文献学・イタリア研究科オープン学術メタデータ研究センター、ボローニャ、イタリアおよびボローニャ大学古典文献学・イタリア研究科デジタル人文学先端研究センター（/DH.arc）{silvio.peroni@unibo.it} （５）デイビッド・ショットン、オックスフォード大学オックスフォードe-リサーチセンター、オックスフォード、イギリス {david.shotton@opencitations.net}。 リンク一覧 概要と序文 関連事業 方法論 データとサービス 議論 結論、謝辞、参考文献 3. 方法論 OpenCitations Meta は、CSV 形式 (つまり表形式) の入力データから生成されます。この選択は偶然ではありません。OpenCitations によって CSV 形式で公開されるデータ (例: COCI (OpenCitations、2022)) は、より構造化された形式 (つまり JSON Scholix および RDF N-Quads) の同じデータと比較して、より頻繁にダウンロードされることがわかっています。これは、ファイル サイズが小さいこと (N-Quads および Scholix と比較して) と、何よりも人間にとって表形式の方が読みやすいことによるものです。後者は、OpenCitations Meta が入力形式として CSV を採用している主な理由であり、人間のキュレーター活動からの書誌メタデータの将来的なクラウドソーシングを容易にするためです (Heibi ら、2019a)。 OpenCitations Meta の入力テーブルには、OCDM (Daquino 他、2020) の線形化に対応する 11 の列があります。ID、タイトル、著者、編集者、発行日、会場、巻、号、ページ、タイプ、発行者です。各フィールドの構造の詳細については、(Massari & Heibi、2022) を参照してください。 CSV 表形式データが取得されると、データは最初に自動的にキュレーションされ (キュレーター ステップ)、次に OCDM に基づいて RDF に変換されます (クリエーター ステップ)。最後に、キュレーションされた CSV と RDF はファイルとして保存され、対応するトリプルストアが段階的に作成されます。図 2 はワークフローをまとめたものです。 3.1 キュレーター: 重複排除、エンリッチメント、修正 キュレーション プロセスでは、受信したデータの品質を向上させるために、重複排除、エンリッチメント、修正という 3 つの主要なアクションを実行します。 データ重複排除に選択されたアプローチは、厳密に識別子に基づいています。言い換えると、2 つの異なるエンティティは、両方が同じ識別子 (記事の場合は DOI、人物の場合は ORCID、書籍の場合は ISBN、出版場所 (ジャーナルなど) の場合は ISSN) を持つ場合にのみ、同じものとみなされます。 同じ識別子を持つ異なるリソースは、厳密なルールに従ってマージされます。(1) リソースが同じ CSV ファイルの一部である場合、最初に出現した情報が優先されます。ただし、(2) リソースがすでにトリプルストアに記述されている場合は、トリプルストアの情報が優先されます。言い換えると、トリプルストアに格納されている情報は信頼できるとみなされ、CSV ソースからの追加データによってのみ増分されます。 エンティティが重複排除されると、OpenCitations メタ識別子 (OMID) と呼ばれる新しい永続的な内部識別子が割り当てられます。OMID の構造は [entity_type_abbreviation]/[supplier_prefix][sequential_number] です。たとえば、処理された最初のジャーナル記事の OMID は br/0601 です。ここで、br は「書誌リソース」の略語で、060 は書誌リソースが属するデータベース (この場合は OpenCitations Meta) を示すサプライヤー プレフィックスに対応します。最後に、1 は、この OMID が、そのプレフィックスで記録された最初のインデックス書誌リソースを識別することを示します。 より正確には、OpenCitations Meta で使用されるサプライヤー プレフィックスは「06[1-9]*0」です。つまり、「06」の後にゼロを除く任意の数字が続き、最後に「0」が付きます。たとえば、「060」、「0610」、「06230」は OpenCitations Meta で有効なサプライヤー プレフィックスです。 重複排除の対象となり、その後 OMID で識別されるエンティティは、外部識別子 (略称 id)、エージェントの役割 (著者、編集者、発行者など、略称 ar)、責任あるエージェント (個人および組織など、略称 ra)、リソースの具体化 (ページなど、略称 re)、および会場、巻、号 (すべて書誌リソース、略称 br) です。巻と号に OMID があるのは、それらが記事の属性ではなく第一級のオブジェクトとして扱われるためです。これには、たとえば、特定の号内の論文、名前付きジャーナルの巻、または特定の期間内に発行されたジャーナル号を検索できるという利点があります。対照的に、タイトルと日付はエンティティではなくリテラル値として扱われます。 図 3 は重複排除の決定木を示しています。入力エンティティとその識別子が与えられた場合、6 つの結果が考えられます。 エンティティに識別子がない場合、またはトリプルストアに識別子が存在しない場合は、エンティティに対して新しい OMID が作成されます。 エンティティに OMID がなく、その外部識別子の 1 つがすでに他の 1 つのエンティティにのみ関連付けられている場合、2 つのエンティティは結合され、同じものとして扱われます。 CSV 内のエンティティの外部識別子が、これまで別個であったトリプルストア内の 2 つ以上のエンティティを接続し、CSV に OMID が指定されていない場合、自動的に解決できない競合が発生し、手動による介入が必要になります。この競合エンティティに対して新しい OMID が作成されます。たとえば、CSV では、同じジャーナル名が 2 つの識別子 issn:1588-2861 と issn:0138-9130 に関連付けられていますが、トリプルストアには、実際には同じエンティティを参照する 2 つの別々のエンティティのエントリがあり、1 つは識別子 issn:1588-2861、もう 1 つは識別子 issn:0138-9130 です。 CSV 内のエンティティにトリプルストアに存在する OMID があり、他の ID が存在しない場合は、トリプルストアの情報によって CSV 内の情報が上書きされます。トリプルストアは、不足している詳細を追加することによってのみ更新されます。言い換えると、CSV 内のエンティティの OMID を指定することは、OpenCitations Meta 内の既存のエンティティを更新する方法です。 エンティティに既存の OMID があり、追加の識別子が OMID のない他のエンティティ (CSV 内) または同じ OMID を持つ他のエンティティ (CSV またはトリプルストア内) に関連付けられている場合、エンティティは結合されます。さらに、CSV 内の情報はトリプルストアで既に利用可能な情報で上書きされ、CSV に存在する不足している詳細がトリプルストアに追加されます。 最後に、外部識別子がトリプルストア内の異なる OMID を持つ複数のエンティティを接続すると、競合が発生します。この場合、CSV で指定された OMID が優先され、その OMID を持つエンティティのみがマージされます。 これらの一般的なルールを考慮すると、3 つの特定のケースは特に注意が必要です。最初の注目すべき問題は、著者と編集者の順序に関するもので、これは OCDM に従って維持する必要があります。マージが発生した場合、エンティティが最初に作成されたときに記録された順序が後続の順序を上書きし、新しい著者または編集者は既存のリストの末尾に追加されます (図 4 を参照)。 第二に、2 つの書誌リソースを統合するコンテキストでは、識別子を持たない著者または編集者として関与する人物は、名と姓に基づいて区別されます。 最後の重要なケースは、記事、号、巻、会場間の包含関係に関係します。この構造はマージの場合でも保持され、2 つの巻または号は同じ値 (連番 (例: 「巻 1」) または任意の名前 (例: 「Clin_Sect」)) を持つ場合にのみ同じとみなされます。 3.2 キュレーター: エラー防止 すべてのエンティティが OMID を取得すると、データが正規化され、自動的に処理できるエラーが修正されます。すべての識別子は、識別子スキームに基づいてチェックされます。たとえば、ISBN、ISSN、ORCID の構文の正確性は、識別子スキームのドキュメントで提供される特定の式を使用して計算されます。ただし、識別子の意味の正確性は、ORCID と DOI に対してのみ検証され、オープン API を使用して実際の存在を検証します。たとえば、構文的には有効であるが、実際には個人に割り当てられていない ORCID を生成する可能性があるためです。 スペースに使用されるすべての曖昧な文字と代替文字 (例: タブ、ノーブレーク スペース、em スペース) は、スペース (Unicode 文字 U+0020) に変換されます。同様に、ID、ページ、巻、号、著者、編集者内のハイフンの曖昧な文字 (例: ノーブレーク ハイフン、en ダッシュ、マイナス記号) は、ハイフン マイナス (Unicode 文字 U+002D) に変更されます。 書誌リソースのタイトル（「開催地」および「タイトル」の列）に関しては、大文字で始まる単語（「FaBiO」や「CiTO」などの頭字語である可能性が高い）を除き、タイトル内のすべての単語が大文字で始まります。ただし、この例外は、タイトルがすべて大文字の場合は適用されません。個人または組織を問わず、著者および編集者にも同じ規則が適用されます。 日付は、ISO 8601 (YYYYMM-DD) (Wolf & Wicksteed、1997) に基づく形式の有効性と値の両方を考慮して解析されます (例: 2 月 30 日は有効な日付ではありません)。必要に応じて、日付は切り捨てられます。たとえば、日付 2020-02-30 は、指定された日付の日が無効であるため、2020-02 に変換されます。同様に、2020- 27-12 は、月 (つまり日) が無効であるため、2020 に切り捨てられます。年が無効である場合 (例: 9999 より大きい年)、日付は破棄されます。 巻数と号数の訂正は、特筆すべき数多くの規則に基づいています。一般的に、発生する可能性のあるエラーは 6 つのクラスに分類されており、それぞれのクラスに応じて対処されます。 同じフィールドに巻数と号数を入力します (例: 「Vol. 35 N° spécial 1」)。2 つの値は分離され、対応するフィールドに割り当てられます。 プレフィックスエラー（例：「.38」）。プレフィックスは削除されます。 サフィックスエラー（例：“19/”）。サフィックスは削除されます。 エンコード エラー (例: “5â\x80\x926”, “38â39”, “3???4”)。両端の数字のみが保持され、1 つのハイフンで区切られます。したがって、例はそれぞれ “5-6”, “38-39”, “3-4” に修正されます。これは、“â\x80\x92”, “â” および “???” が誤ってエンコードされたハイフンであるためです。 ボリュームは問題として分類されます (例: 「問題」フィールドに「ボリューム 1」)。ボリューム パターンが「問題」フィールドに見つかり、「ボリューム」フィールドが空の場合、コンテンツは「ボリューム」フィールドに移動され、「問題」フィールドは null に設定されます。ただし、「問題」フィールドにボリューム パターンが含まれ、「ボリューム」フィールドに問題パターンが含まれる場合、2 つの値は入れ替わります。 巻として分類される問題（例：「巻」フィールドの「特集 2」）。ケース 5 と同じように扱われますが、役割が逆になります。 我々は、“original series”、“volume”、“vol”、および様々な言語での“volume”という単語（例えば、フランス語の“tome”、トルコ語の“cilt”）を含むパターンを巻とみなしました。例えば、“Original Series”、“Volume 1”、“Vol 71”、“Tome 1”、“Cilt: 1”は巻として分類されます。代わりに、我々は、“issue”、“special issue”、および様々な言語での“issue”という単語（例えば、“horssérie”（フランス語の特別号）や“özel sayı”（トルコ語の特別号））を含むパターンを号とみなしました。例えば、“issue 2”、“special issue 2”、“Special issue 'Urban Morphology”'、“Özel Sayı 5”、“Hors-série 5”は号として分類されます。 最後に、値の形式が無効であり、かつ間違ったフィールドにあるために無効な場合は、まずそのような値が修正され、適切な場合は正しいフィールドに移動されます。 入力データの曖昧さが解消され、強化され、修正されると、新しい CSV ファイルが生成され、保存されます。このファイルは、プロセスの最初の出力を表します (図 2 の 3a)。 3.3 作成者: セマンティックマッピング このフェーズでは、データは OCDM (Daquino et al., 2020) に従って RDF でモデル化されます。このオントロジーは、SPAR オントロジーで定義されたエンティティを再利用して、書誌エンティティ (fabio:Expression)、識別子 (datacite:Identifier)、エージェント ロール (pro:RoleInTime)、責任エージェント (foaf:Agent)、および出版形式の詳細 (fabio:Manifestation) を表します。エージェント ロール (つまり、著者、編集者、または発行者) は、書誌リソースと責任エージェント (つまり、個人または組織) の間のプロキシとして使用されます。このアプローチは、著者の順序など、時間依存およびコンテキスト依存の役割とステータスを定義するのに役立ちます (Peroni et al., 2012)。図 5 は、Graffoo グラフィカル フレームワーク (Falco et al., 2014) を介してさまざまなエンティティ間の関係を示しています。 たとえば、OpenCitations Meta では、OMID omid:br/062601067530 のエンティティのタイトルは Open Access And Online Publishing: A New Frontier In Nursing? (dcterms:title) で、公開日は 2012-07-25 (prism:publicationDate) です。FRBR (Tillett、2005) を使用すると、この記事は最終的に公開されたバージョン、または元の作品の表現 (fabio:Expression) であり、サンプルとしてエンティティ omid:re/06260837633 (frbr:embodiment) があり、これはジャーナル巻の 1905 ～ 1908 ページ (prism:startingPage、prism:endingPage) に対応する印刷出版物です。より正確には、この記事は、開催地 Journal Of Advanced Nursing (fabio:Journal) の巻 (fabio:JournalVolume) 第 68 号に含まれる号 (fabio:JournalIssue) 第 9 号 (fabio:hasSequenceIdentifier) の一部 (frbr:partOf) です。 さらに、人物 (foaf:Agent) Glenn Hunt (foaf:givenName, foaf:familyName) は、この記事 (pro:isDocumentContextFor) のコンテキストにおける最初の著者 (pro:RoleInTime) です。同様に、2 番目の著者は Michelle Cleary (pro:hasNext) です。 最後に、この出版物には、OpenCitations メタ識別子 (OMID) omid:id/062601093630 (datacite:hasIdentifier) があり、これは datacite:Identifier タイプのエンティティです。また、この出版物には外部識別子があり、その識別子スキームとしてデジタル オブジェクト識別子 (DOI) (datacite:usesIdentifierScheme) を使用し、リテラル値「10.1111/j.1365- 2648.2012.06023.x」(literal:hasLiteralValue) を持っています。 マッピングが完了すると、生成された RDF データを保存し (図 2 の 4a)、トリプルストアにアップロードできます (図 2 の 4b)。 3.4 作成者: 来歴と変更の追跡 メタデータの処理に加えて、OpenCitations Meta 内のエンティティの来歴と変更の追跡も非常に重要です。来歴とは、特定のエンティティを作成、削除、変更、またはマージして処理した人物、その操作がいつ実行されたか、主要なソースは何かを記録することです (Gil 他、2010)。この情報を追跡することは、OpenCitations Meta 内のメタデータの信頼性を確保するために不可欠です。実際、Web およびセマンティック Web 上のステートメントの真実性は絶対的なものではなく、情報を処理するすべてのアプリケーションは、そのコンテキストを評価することで整合性を評価する必要があります (Koivunen および Miller、2001)。 ただし、出所情報を保存することに加えて、エンティティの進化を理解するメカニズムは、研究評価演習などの活動を扱う際に重要です。研究評価演習では、修正または誤った指定による変更が、学者、研究グループ、または機関全体の全体的な評価に影響を与える可能性があります。たとえば、機関の名前は時間の経過とともに変更される可能性があり、データベースでのこれらの変更の反映により、「機関の歴史に関する知識がなければ、すべての機関の名前とユニットを特定することが困難になります」(Pranckut˙e、2021)。このシナリオは、データベース内でデータがどのように進化したかを追跡することで防止でき、ユーザーは外部の背景知識にアクセスすることなく、このようなダイナミクスを理解できます。私たちの知る限り、標準 RDF 1.1 の変更と出所を追跡する学術メタデータのセマンティック データベースは他にありません。 OpenCitations が採用している出所メカニズムは、保存されている各エンティティの初期作成スナップショットを記述し、その後にデータの変更、結合、削除の詳細を示す他のスナップショットが続く可能性があり、それぞれにスナップショット番号が付けられています (図 6 にまとめられています)。 セマンティック表現に関しては、来歴モデリング (Sikos & Philp、2020) と RDF での変更追跡 (Pelgrin 他、2021) の問題が学術文献で議論されてきました。現在まで、両方の目的を達成する共通の標準はありません。このため、OpenCitations では、最も広く共有されているアプローチ、つまり名前付きグラフ (Carroll 他、2005)、来歴オントロジー (Lebo 他、2013)、および Dublin Core (Board、2020) を採用しています。 特に、各スナップショットは、prov:wasDerivedFrom 述語を介して前のスナップショットに接続され、prov:specializationOf を介してそれが記述するエンティティにリンクされます。さらに、各スナップショットは、起源メタデータが記述される名前付きグラフに対応します。具体的には、責任エージェント (prov:wasAttributedTo)、プライマリ ソース (prov:hadPrimarySource)、生成時刻 (prov:generatedAtTime)、および追加のスナップショットの生成後の無効化時刻 (prov:invalidatedAtTime) です。各スナップショットは、オプションで、発生した事象の自然言語による記述 (dcterms:description) で表すこともできます。 さらに、OCDM 出所モデルは、OpenCitations オントロジー (Daquino & Peroni、2019) 内で説明されている新しい述語 oco:hasUpdateQuery を追加します。これは、SPARQL UPDATE クエリを介してエンティティの 2 つのバージョン間の差分を表します。図 7 は、Graffoo ダイアグラムを介してモデルを示しています。 セクション 3.1 で説明した重複排除プロセスは、変更追跡メカニズムを適用することで、データセットの現在の状態だけでなく、その履歴全体に対しても実行されます。言い換えると、トリプルストアから削除されたエンティティに識別子を遡ることができる場合、その識別子は削除されたエンティティの OMID に関連付けられます。削除がマージ チェーンによるものである場合、結果のエンティティの OMID が優先されます。タイム トラバーサル クエリ手法の詳細については、(Massari & Peroni、2022) を参照してください。SPAR オントロジーに従ってデータを作成し、変更を追跡するためのプログラミング インターフェイスの詳細については、(Persiani 他、2022) を参照してください。 この論文は、CC 4.0 DEED ライセンスの下で 。 arxiv で公開されています