種のチェックリストを発行する最適な方法

バージョン 2.1

cover art stilt

文書管理

Version Description Date of release Author(s)

1.0

Release Version

1 April 2011

David Remsen

1.11

Minor editorial changes

28 April 2011

David Remsen

2.0

Transferred to wiki, major changes

30 March 2017

Kyle Braak

2.1

Transferred to AsciiDoctor

24 May 2021

Matthew Blissett

推奨される引用

GBIF (2017) Best Practices in Publishing Species Checklists, version 2.1. Copenhagen: GBIF Secretariat. https://ipt.gbif.org/manual/ja/ipt/3.0/best-practices-checklists

カバーアート製作: Gregory Basco, Black-necked stilt, Himantopus mexicanus

Introduction

このガイドでは、分類学的チェックリスト情報を標準的な方法で共有するための手段として、ダーウィンコア・アーカイブ (DwC-A) フォーマットの活用方法について詳しく説明します。また、ダーウィンコア・アーカイブフォーマットの特定のコンポーネントと、コア分類学データクラスをサポートする拡張機能に焦点を当て、共有データの価値を最大化するためにこれらのコンポーネントを最適に利用する方法について推奨事項を説明します。本書はダーウィンコア・アーカイブフォーマットの詳細な概要を提供するものではなく、ダーウィンコア・アーカイブ ハウツーガイドを参照してください。

DwC-Aフォーマットとここで説明する特定のプロファイルは、国際的に認められ批准された、分類学データ共有のためのデータ交換フォーマットです。すべてのデータ交換基準は、一方では技術的な範囲と能力、他方では社会的な受け入れと取り込みのバランスを取る必要があります。シンプルなソリューションでは、使いやすさを優先して、適用範囲や複雑さが犠牲になります。非常に複雑なフォーマットは、あらゆる種類のデータを表現するためのより完全なソリューションを提供しますが、単純さを犠牲にして、サポートするソフトウェアと専門知識を必要とします。ダーウィンコア・アーカイブフォーマットは、この両端の中間的な位置づけにあります。分類学的チェックリストの主要な要素に焦点を当て、このコア構造にリンクさせることで、より充実したデータタイプのセットを可能にします。アーカイブに含まれるデータは、基本的な構造化テキストファイルに慣れている多くの生物学者やデータ管理者が容易に理解し、使用することができます。比較的簡単に作成・利用でき、分類学的データリソースを構成する重要な要素の多くをサポートする国際基準を提供することにより、GBIFは、チェックリストの作成者と管理者に、データを共有する標準的なアプローチを提供し、その後の引用と彼らの仕事の認識への共通のアプローチを促進することを期待しています。また、標準的な形式は、関連性と実用性を高めます。

対象範囲

「種チェックリスト」と分類学の「カタログ」という用語は、重複する範囲の分類学的リソースを指す場合があります。これらの製品はすべて、暗黙的または明示的に分類を参照する学名のセットを含んでいます。このようなリストに含まれる名前のセットは、分類群、地理的地域、または移入種のようなテーマによって、あるいはその3つの組み合わせによって制約されることがあります。詳細な順に、以下のリソースタイプ[1]が含まれます。

  1. 名前リスト - 分類学上の状態を明示しない、単純な種名のリストです。ただし、一般に認められている分類名で構成されていることが示唆されています。このようなリストは総じて、地域的またはテーマ的な文脈に含まれる一連の分類群を区別することを意図しています。

  2. 命名リスト(命名者) - 名目分類を含む名称のリストで、それぞれの命名規約で規定された命名行為を表す科学名称の公開用例の登録簿を意味します。これらの行為の多くは、新しい学名の「原記載」ですが、他に修正、レクトタイプ化および各コードで規定されるその他の行為が含まれる場合があります。シノニムは分類学上の概念としてこれらのリストに含まれるのではなく、(植物学者にとって)新たに確立された組み合わせがバシオニムにリンクされ、命名法上のシノニムとなる場合にのみ含まれます。

  3. 分類学的チェックリスト - 分類学的状態を明示し、シノニムとして扱われる名前を含めることで、命名リストを拡張したリストです。このカテゴリの単純な分類学的リストは、シノニムの根拠に関する具体的な詳細を提供しません。分類群は、多くの場合、分類体系に整理されています。また、「分類目録」という用語は、この分類やその他の分類の例を指す場合(特にその資料が検証済みの出版物や分類学的地位の詳細を含んでいる場合)に使用されることがあります。

  4. 注釈付きチェックリスト - このカテゴリは、一般名、脅威の状態、分布、基本的な記述情報などの他のデータタイプ(注釈)を、シノニムのコアチェックリストに追加することによって、分類学的チェックリストを拡張します。注釈の種類が、詳細な診断説明や図解、分子データ、標本など、分類群を効果的に定義、または限定するのに十分な詳細を提供する場合、その注釈付きリストは以下に定義する2つのカテゴリーのいずれかに分類される可能性があります。

  5. 植物相または動物相のリスト - これらは通常、特定の地域の詳細な種の説明を提供する書籍です。詳細には、注釈付きチェックリストに含まれる多くのデータタイプが含まれますが、詳細な説明や図版、標本参照など、必ずしもグローバルではない地域の範囲内で分類群を明確に定義(限定)するような特定のデータタイプを含むことがあります。

  6. モノグラフ - モノグラフは、世界規模で特定の分類群についてしばしば書籍として出版される詳細な種の説明です。モノグラフには詳細な命名法、同義性、分類群の詳細が含まれ、本文の説明や図版、調査した標本の詳細、調査した文献の書誌などが含まれます。

ダーウィンコア・アーカイブフォーマットとGBIFチェックリスト拡張機能は、これらすべてのチェックリストデータタイプの中の主要なデータ要素の交換をサポートしています。具体的にどの程度カバーしているかは、個々のリソースに大きく依存します。この文書では、上記のリソースカテゴリーのいずれか、またはすべてを指す一般的な用語として、広義に「チェックリスト」という用語を使用します。特定のカテゴリータイプは、特定のリソースを参照する場合に使用します。

ダーウィンコア・アーカイブ形式

ダーウィンコア・アーカイブ(DwC-A)は、ダーウィンコアの用語を利用して、チェックリストデータを自己完結型の単一データセットとして作成する情報学データ規格です。アーカイブ内のファイルの集まりが自己完結型のデータセットを形成し、単一の圧縮(ZipまたはGzip)ファイルとして提供することができます。データセットは、記述的なメタデータ文書と、1つまたは複数のデータファイルのセットで構成されています。DwC-Aの詳細については、ダーウィンコア・アーカイブハウツーガイドを参照してください。

チェックリストのメタデータ

GBIFのネットワークを通じてチェックリストデータを公開するためには、データセットの出所と範囲を文書化することが必要です。データセットに関する文書は「リソースメタデータ」と呼ばれ、利用者がデータセットの使用に適しているかどうかを評価できるようにします。データセットの文書には、リストの範囲と意図された機能、編集に使われた方法論と資源、作成と管理に関わった個人と機関が記述されています。メタデータはダーウィンコア・アーカイブでXML文書として共有されます。GBIFはEcological Metadata Languageに基づいて、種のチェックリストのためのメタデータプロファ イルを提供します。ハウツーガイドでは、この形式を使用して種のチェックリストを記述するためのすべてのオプションについて説明しています。GBIFメタデータプロファイル - ハウツーガイドを参照してください。

チェックリストデータ

ダーウィンコアアーカイブ形式は、種のチェックリストを公開するための構造的な枠組みを提供します。ダーウィンコアアーカイブは、標準的なカンマまたはタブ区切り形式の1つまたは複数のテキストファイルで構成されています。ファイルは、基本的なチェックリスト要素(種リスト、分類、同義語)を含む1つの*コアファイル*を、関連するデータ型(一般名など)を記述する多数の「拡張子」で囲んだ星のような方法で論理的に配置されています。コアと拡張機能のレコード間のリンクは、分類群ID(taxonID)データエレメントを使用して行われます。このようにして、1 つのコア分類群レコードに対して多くの拡張レコードを存在させることができます。この「スタースキーマ」は、種のチェックリストに共通する多くの種類の注釈をサポートする、シンプルなリレーショナルデータモデルを提供します。

dwc a checklist
Figure 1. ダーウィンコア・アーカイブデータファイルの「スタースキーマ」での表示

データファイルのフォーマットに関する推奨事項

理解を容易にするために、このガイドの用語*フィールド*を使用して、ユーザーデータがマップされる分類学的公開プロファイルのダーウィンコア用語セットを参照する場合があります。 たとえば、ダーウィンコアの用語である学名を参照する場合は、*dwc:scientificNameフィールド*の使用を参照します。

  • カスタムフィールド区切り文字と引用符の代わりに、タブまたはカンマ区切り値を使用することをお勧めします。

  • 注意して、見積もりと一致させてください。

  • テキストファイルをUTF-8でエンコードしてください。

  • データフィールドのすべての改行を必ず置き換えてください。つまり、\r \n`または\r\n`を単純なスペースに置き換えるか、$$`のような2文字を使用して\r`を置き換え、改行を保持する場合は改行を省略してください。 。 もう1つのオプションは、改行をHTMLの`<br>`タグに置き換えることです。

  • nullを空の文字列としてエンコードします。つまり、2つの区切り文字、\N`または\NULL`の間に文字はありませんが、他のテキストシーケンスはありません。

学名の共有

ダーウィンコアは、学名を共有するためのいくつかの方法に対応しています。以下の通りです。

A. 学名フィールドに連結される

学名

Gerardia paupercula var. borealis (Pennell) Deam

*dwc:scientificName*フィールドには、著者を含む分類群の完全な学名が格納されます。このフィールドは、名前が構成要素に分割されている場合でも(下記C.のように)常にデータが入力されている必要があります。名前の部分と著者名の部分をきれいに分離できないデータベースでは、連結された名前文字列全体に対してこのフィールドを使用する必要があります。これはハイブリッド式、*sensu strictu*名、オートニム、その他の非自明な二項対立に必要となる場合があります。このフィールドは一般的に*dwc:taxonRank*フィールドと組み合わせて、上位分類を含む完全な分類リストの学名部分を格納するために使用されます。

B. 名前部分と著作権部分の分離

学名 学名著者名

Gerardia paupercula var. borealis

(Pennell) Deam

データベースによっては、学名を名前の部分と著者の部分に分けているものもあります。この場合、*dwc:scientificName*と*dwc:scientificNameAuthorship*フィールドを使用する必要があります。

C. ネームパーツに分類

属名 種形容語 分類階級 亜種エピテーゼ 学名の著者

Gerardia

paupercula

var.

borealis

(Pennell) Deam

ダーウィンコアは、学名を構成要素に分離するための一連の用語を提供しています。データベースによっては、このようにパースされたコンポーネントで種のリストを保存しているものもあります。この場合、この形式でのデータ共有はオプションになる可能性があります。しかし、その場合、追加で完全な名前を部分から構成し、*dwc:scientificName*フィールドで共有することを強くお勧めします(上記セクションAのように)。上の表では、ダーウィンコアの用語である*dwc:subgenus*は表示されていませんが、追加の名前の構成要素を表していることに注意してください。

属人的なマーカー

可能であれば、原著者・原典著者との混同を避けるため、学名の一部に属名ランク記号を付けてください。例えば、「Ageratina subgen. Apoda R.M.King & H.Rob.」は、「Ageratina (Apoda) R.M.King & H.Rob.」よりも優先されます。これは後者の*Apoda*が亜属として解釈される可能性や、原種著者と解釈される可能性があるからです。

分類の公開

ダーウィンコアでは、分類や分類学的階層を公開するために、正規化と非正規化という2つの基本的なオプションが用意されています。これらの2つのオプションは、ほとんどの分類がデータベースで管理される主な手段を説明します。

正規化された分類(親/子)

ベースでは「親子関係」または「隣接リスト」と呼ばれることもあります。正規化された分類階層では、各分類項目は1つの行で表されます。これには、分類における種とすべての上位分類群が含まれます。各行には、少なくとも以下のコンポーネントデータ要素があります。

  • 現在の分類を参照する*dwc:taxonID*。持っている識別子を何でも使うことができます

  • 現在の分類群の*dwc:scientificName*。例:「Panthera tigris(パンテーラ・ティグリス)」

  • 参照する分類群の*dwc:taxonRank*。例:「種」

  • dwc:parentNameUsageIDに格納されている、直系の親タクソンのタクソン識別子への参照です。以下の例では、レコード7の「Panthera tigris (Linnaeus)」の親はレコード6の「Panthera」属です。

以下に、単一種であるトラ "Panthera tigris" の分類例を示します。階層構造の最上位は親を持たないので、親識別子は空欄でなければならないことに注意してください。この場合、*dwc:scientificName*は名前を保存するための共通のフィールドを提供しますが、名前の一通りのオプションは上記「学名の共有」で説明されていることに注意してください。

taxonID taxonRank scientificName parentNameUsageID

1

Animalia

2

Chordata

1

3

Mammalia

2

4

Carnivora

3

5

Felidae

4

6

Panthera

5

7

Panthera tigris (Linnaeus)

6

メリット

  • 効率性 - 正規化された分類は、階層内の各分類群に対して1つのリファレンスを保存します。

  • 参照整合性 - 各分類群の構成要素には、その直属の親を明示的に参照する明確な識別子があります。分類学上の階層が完全であり、適切に形成されていることを簡単に確認できます。

  • 拡張性 - すべての分類群は、個別の分類群識別子で識別されます。このため、種の記録と同様に拡張子を使用することで、高次の分類群をより豊かに記録することができます。

デメリット

  • 利便性 - 正規化された分類は、生の表形式で見た場合、分類階層の直感的なビューを提供しません。多くの生物学者は、効率は悪いものの視覚的に直感的な、以下に説明する非正規化形式で分類を管理しています。非正規化された分類を正規化された形式に変換することは、手作業で行うには困難です。

*dwc:parentNameUsageID*はデータセット内の既存のレコードを指している必要があります。レコードとして存在しない上位分類群識別子を指定することはできません。

非正規化されたクラス分類

この形式は、表計算ソフトで種の情報を管理している人なら誰でも知っているものです。非正規化分類では、データテーブルの各行が種のような末端の分類群の1つを参照し、親分類群の完全なセットを列として、各親分類群に対して1つずつ参照します。

この形式は、ダーウィンコア・アーカイブを使用した分類学データの共有には推奨されませんが、多くの種のリストで一般的に使用されているため、GBIFはこの形式をサポートしています。この方法でデータを共有する場合、以下を行うことを強く推奨します。

  1. 各上位分類群の列は完全に入力されている。以下のPlantaeの例のように、空欄は避けてください。

  2. リストの分類学的整合性を確保してください。例えば、共通の属に属する2つの種が同じ科を共有していることを確認します。同義語が別の行に含まれている場合、その分類が受け入れた分類子の分類と一致することを確認してください。

taxonID kingdom phylum class order family scientificName

1001

Animalia

Chordata

Mammalia

Carnivora

Felidae

Panthera tigris

1002

Animalia

Chordata

Mammalia

Carnivora

Felidae

Panthera leo

1003

Animalia

Arthropoda

Insecta

Hymenoptera

Apidae

Apis mellifera

1004

Plantae

 — 

 — 

 — 

Poales

Poa annularis

メリット

  • 可読性 - このフォーマットの第一の利点は、読みやすく、列を読むだけで分類学上の階層を評価できることである。

  • 利便性 - 表計算アプリケーションや多くの関連データベースでは、この構造を簡単に実装して、階層的なデータを保存することができます。

デメリット

  • 参照整合性が損なわれる可能性が高い - 高次分類群がフォーマット内で繰り返されるため、2 つの同じ分類群のスペルが異なる可能性が高くなります。このフォーマットでは、他の同様のリスクも発生する可能性があります。たとえば、同じ分類群(上記「Felidae」など)の 2 つのインスタンスが異なる親に割り当てられる可能性があり、その結果、階層的な整合性が損なわれる可能性があります。

  • 上位分類群の詳細がない - このフォーマットにおいて上位分類群は、独立した分類群レコードとしてではなく、種のプロパティとして扱われます。したがって、このフォーマットでは、コアファイルでも拡張ファイルでも、上位分類のプロパティを共有することができません。

その他の分類に関する推奨事項

  • 基本的な種リストであっても、すべての記録に王国と命名コードの参照を含めるようにしてください。

  • 非正規化された分類のための最小限の分類として、Kingdom, Phylum, Familyを含めるようにしてください。

  • データセット全体で同じであれば,用語と値の静的マッピングを使用することを検討してください。グローバルな値のマッピングの詳細については、ダーウィンコア・アーカイブ:ハウツーガイドを参照してください。

公開にあたって推奨されない分類フォーマット

以下の例は、プロファイルに適合しますが、GBIFが推奨・対応しない(つまり、GBIFパーサーがこれらのケースを適切に扱えない)データ構成を示すものです。

  1. この例では、参照する分類子を、分類子の値を含む最後の列として識別しています。

    taxonID kingdom phylum class order family scientificName

    997

    Animalia

    998

    Animalia

    Chordata

    999

    Animalia

    Chordata

    Mammalia

    1000

    Animalia

    Chordata

    Mammalia

    Carnivora

    1001

    Animalia

    Chordata

    Mammalia

    Carnivora

    Felidae

    1002

    Animalia

    Chordata

    Mammalia

    Carnivora

    Felidae

    Panthera tigris

    1003

    Animalia

    Chordata

    Mammalia

    Carnivora

    Felidae

    Panthera tigris

  2. この例は、上記と似ていますが、上位分類群名を一度だけ記録することで、整合性エラーを減らそうとするものです。

    taxonID kingdom phylum class order family scientificName

    997

    Animalia

    998

    Chordata

    999

    Mammalia

    1000

    Carnivora

    1001

    Felidae

    1002

    Panthera tigris

    1003

    Panthera leo

これらの構成でデータを公開することは避けてください。

シノニムの公開

ダーウィンコア・アーカイブは、種のチェックリストにおけるシノニムの公開をサポートしています。シノニムは、コアデータファイルの別の記録として公開されます。シノニムは dwc:acceptedNameUsageID フィールドを使用して、受け入れ分類子レコードを参照します。このフィールドには、受理された分類群レコードを表す dwc:taxonID が含まれます。以下の単純化した例では、最初のレコードが採用された分類群名を表し、レコード2と3がシノニムです。

taxonID scientificName acceptedNameID taxonomicStatus nomenclaturalStatus

1

Coeligena helianthea (Lesson 1838)

1

accepted

2

Ornismya helianthea Lesson 1838

1

Homotypic synonym

3

Helianthea helianthea (Lesson 1838) J. Gould 1848

1

Homotypic synonym

4

Helianthea typica Bonaparte 1850

1

Heterotypic synonym

nomen dubium

5

Helianthea porphyrogaster Mulsant 1876

1

Heterotypic synonym

nomen dubium

6

Coeligena helianthea tamai Berlioz & Phelps 1953

1

Heterotypic synonym

nomen dubium

A synonym record is recommended to contain a distinct dwc:taxonID. It must not use the same dwc:taxonID as the accepted taxon record. The simplest representation of synonymy is as provided in the example above where synonyms are listed as distinct records and ‘point’ to the accepted taxon record using the dwc:acceptedNameUsageID. This simple synonymy supports the publication of basic taxonomic checklists with synonym details limited to the core taxon class elements. The dwc:taxonomicStatus field affirms the status of the record. A recommended vocabulary for this field is available. Additional nomenclatural details that may also support the rationale behind the synonymy may be included using the dwc:nomenclaturalStatus field and supporting vocabulary.

各シノニムレコードに一意の dwc:taxonID が含まれるようにし、チェックリストの注釈の共有をサポートするために利用可能な拡張機能を利用することで、詳細なシノニムをサポートすることができます。これは、GBIFチェックリスト拡張機能でサポートされている1つ以上の書誌レコード、標本レコード、およびその他のデータタイプを、コアデータファイル内の1つのシノニムレコードにリンクすることを可能するものです。シノニムレコードに*dwc:taxonID*が提供されていない場合、拡張機能はコアファイルのタクソンレコードへのリンクを提供するために*dwc:taxonID*に依存するので使用することができません。以下の簡単な例では、リファレンス拡張機能を使用してシノニムの書誌情報を提供するために、2つのファイル(表として表現)を使用することを説明しています。この例では、共有される*dwc:taxonID*が強調表示されています。

Taxon.txt データファイル

taxonID scientificName acceptedNameUsageID taxonomicStatus

1

Coeligena helianthea

1

accepted

2

Ornismya helianthea

1

synonym

3

Helianthea helianthea

1

synonym

References.txt データファイル

taxonID Bibliographic citation

2

Schmidt, O. 1870. Grundzüge einer Spongien-Fauna des atlantischen Gebietes. (Wilhelm Engelmann: Leipzig): iii-iv, 1-88, pls I-VI.

2

Laubenfels, M.W. De 1942. Porifera from Greenland and Baffinland collected by Capt. Robert A. Bartlett. Journal of the Washington Academy of Sciences 32(9): 263-269.

シノニムに関するその他の注意事項

  • *dwc:acceptedNameUsageID*は、データセット内の既存のレコードを指し示している必要があります。レコードとして存在しない受け入れ分類名を示すことは無効です。

  • 分類を表すために使われる*dwc:higherTaxonID*と、レコードの分類学的状態を表すために使われる*dwc:acceptedNameUsageID*を混同しないようにしてください。

  • シノニムを「連鎖」させないでください。シノニムは*dwc:acceptedNameUsageID*を介してのみ、受理された分類群レコードを指すべきです。他のシノニムを指すべきではありません。

命名法上のシノニム

コアデータファイルでは、*dwc:originalNameUsageID*フィールドを使用することで*命名法上のシノニム*がサポートされています。このフィールドは、その名称の元の分類子を示す行を参照します。このレコードは、*dwc:namePublishedIn*フィールドに、その名前が最初に確立された出版物を参照する書誌的引用を提供することが推奨されます。

taxonID scientificName originalNameID namePublishedIn

1

Tetrao afer Müller 1778

1

J. Syst. Nat 7:31

2

Pternistes afer (Müller 1778)

1

3

Francolinus afer afer (Müller 1778)

1

命名法上の同義語と分類学上の同義語は、同じ分類群記録で指定することができます。

*dwc:originalNameUsageID*は、データセット内の既存のレコードを指していなければなりません。レコードとして存在しない、受け付けられた分類群を指すことは無効です。

pro parteシノニム

同じ名前が複数の分類群に対してシノニムとなる場合や、分類群名とシノニムの両方を兼ねている場合があります。これらは、例えば、一連の型が複数の分類群に分割されるような、分割や周縁化によって生じます。pro parteシノニムを共有するために推奨される方法を例に挙げます。この例では、*Vireo solitarius*は認められた分類名であり、*Vireo cassinii*と*Vireo plumbeus*の両方のシノニムにも含まれています。シノニムの場合、*dwc:acceptedNameUsageID*フィールドで連結され、パイプ文字("|")で区切られた受入分類群参照で1つのレコードとして表現されます。

taxonID scientificName acceptedNameUsageID taxonomicStatus

1

Vireo solitarius

1

accepted

2

Vireo cassinii

2

accepted

3

Vireo plumbeus

3

accepted

4

Vireo solitarius

2|3

pro-parte

IPTユーザーは、IPT内の各ソースファイルに対して、複数値のデリミタを定義する必要があります。追加のガイダンスについては、IPTユーザーマニュアルのソースデータのセクションを参照してください。

引用と帰属

分類学上のチェックリストは多くの場合、それを編集する個人や機関の知的、財政的な努力の結晶です。チェックリストの中には、同じ原典から派生したものや、他の原典を参照し、テーマ別、地域別、分類別の新しい見解を作り出しているものもあります。したがって、これらの出典を適切に表示することは優先されるべきです。

DwC-A 形式では、適切な引用と帰属を行うためのさまざまなオプションと推奨事項を提供しています。この範囲は、リソースのメタデータの一部を形成するグローバルな引用と帰属の情報から、レコードレベルのデータ要素に至るまで広がっています。これらのオプションは、複数レベルの帰属の提供をサポートします。

メタデータの引用と帰属

GBIFメタデータプロファイルは、引用と帰属に貢献するリソースレベルのデータ要素をサポートし、チェックリストの範囲と出所の詳細な記述を可能にします。すべてのメタデータ要素への完全な参照リストは、この文書の範囲を超えており、利用可能ですが、特定の引用と帰属に関連する要素は以下のとおりです。

  • 知的財産権 - メタデータプロファイルには、リソースの権利管理に関する声明、またはクリエイティブ・コモンズ・ライセンスなど、そのような情報を提供するサービスへの参照が含まれます。また、データセットの意図された使用と目的を記述する要素も含まれます。

  • 個人と機関 - メタデータプロファイルは、データセットに関連するあらゆる個人、組織、機関を記述することができます。これらのエージェントは、データセットに関連するさまざまな役割を与えられ、各リソースへの URL を含むことができます。このセクションではチェックリストに貢献した個人と機関を記述し、リンクするための一つの方法を紹介します。

  • ソースURL - ソースのホームページへのリンクです。

  • プロジェクト情報 - チェックリストが特定のプロジェクト(「The Catalogue of Life」など)にリンクされている場合、そのプロジェクトを詳細に説明するためのフィールドがあります。

  • 引用 - この要素では、チェックリストの発行者が、チェックリストのデータを使用する際にどのように引用するかを正確に指定できます。(例:“Appeltans W, Bouchet P, Boxshall GA, Fauchald K, Gordon DP, Hoeksema BW, Poore GCB, van Soest RWM, Stöhr S, Walter TC, Costello MJ. (eds) (2011). World Register of Marine Species. Accessed at http://www.marinespecies.org on 2011-02-22.”

  • 書誌情報 - 出典の完全な書誌情報を記述し、メタデータ文書に含めることができます。

データレベルの引用と帰属

メタデータ文書に記録されている帰属・引用情報は、データセット内の全データレコードに共通するものです。場合によっては、個々のレコードに至るまでさらに細かい情報が必要なこともあります。このような場合、引用と帰属の情報を指定するために使用することが推奨されるレコードレベルの用語があります。

  • dwc:nameAccordingTo : この用語は、そのレコードの権威ある分類学的参照として機能する個人または引用を特定するために使用することができます。(例:“Erpenbeck, D.; Van Soest, R.W.M. 2002. Family Halichondriidae Gray, 1867. Pp. 787-816. In Hooper, J. N. A. & Van Soest, R. W. M. (ed.) Systema Porifera. A guide to the classification of sponges.”)

  • dwc:nameAccordingToID : 前述のnameAccordingToの参照を返す一意の識別子(例えばURLなど)です。

  • dwc:datasetName : レコードが外部データセットから派生している場合、このデータセットをテキスト文字列として引用することができます。(例:"World Register of Marine Species, cited on 12 April 2011")

  • dwc:datasetID : データセットを参照する識別子で、解決可能であることが望ましいです。

  • dc:source : ソースウェブページへのリンク

使用例1 - 複数の寄与するデータセットからなるチェックリスト(例:Catalogue of Life、PESI、WoRMS)

分類学的データセットは複数の貢献するソースの複合体である場合があり、集合的なリソース自体に加えて、それぞれのソースを認識する必要があります。このような例はたくさんあります。そのような集団的努力の中で最も大きなものは、おそらくCatalogue of Life Annual Checklistでしょう。これは、世界中のすべての生物種の完全なリストを提供することを目的としています。このチェックリスト自体は、主要な分類群を表す個々のデータセットで構成されています。これらのリソースはそれぞれ、専門家のサブネットワークからの貢献で構成されています。

他には、Fauna Europaea、European Register of Marine Species、Euro+Med PlantBase などのデータセットから構成される Pan-European Species list の例があります。The World Register of Marine Speciesもそのようなネットワークの一つです。

このようなリソースの出典を効率的に文書化するために推奨される方法は、以下の通りです。

  1. このメタデータ文書は、適切な引用、代理人、権利、および上記で特定されたその他の要素を提供する、(the Catalogue of Life, the The World Register of Marine Speciesなどの)集合的なリソース自体を表す単一のメタデータ文書が作成されます。この文書のファイル名は、ダーウィンコア・アーカイブ記述子ファイルである meta.xml を参照しています。これにより、ドキュメントとDwC-Aデータセット全体がリンクされます。推奨される最良の方法は、このファイルがGBIFメタデータプロファイルを使用し、EML.xmlという名前になることです。この場合、メタデータ記述子XMLは以下のようになります。

    <archive xmlns="http://rs.tdwg.org/dwc/text/" metadata="eml.xml">
  2. 各コンポーネントデータセットについて、追加のメタデータドキュメントを作成し、アーカイブに含めることができます。これにより、各サブコンポーネントデータセットは、「親」データセットと同様に、推奨される引用や貢献した個人など、完全に文書化されます。これらのデータセットはコレクション全体を文書化するものではないので、meta.xml記述子ファイルでは参照されません。代わりに、*dwc:datasetID*という語彙を使って、個々のデータレコードから参照されます。メタデータのドキュメントがアーカイブ自体に含まれている場合、*dwc:datasetID*はドキュメントのファイル名と等しくなります。あるいは、URLやその他の一意で解決可能な識別子を参照することもできます。あまり推奨されませんが、構造化されたメタデータドキュメントとは対照的に、データセットを説明するシンプルなウェブページへのURLを追加する方法もあります。

  3. レコードレベルで個人を引用し、第3レベルの引用を提供するには、*dwc:nameAccordingTo*フィールドを使用することが推奨されます。その他のレコードレベルの用語は上記で説明しています。

使用例2 - 1つまたは複数の信頼できるソースから導き出されたチェックリスト

この使用例における種のチェックリストは、特定の目的のために編集されますが、その基本的な分類学的構造は、*オーソリティファイル*として機能する1つ以上の外部分類学チェックリストに由来しています。新しい編集物には、新しいリストの焦点に適用される基本的なソースレコードへの追加注釈が含まれることがあります。たとえば、Fauna Europaea や Catalogue of Life などのデータベースから作成したヨーロッパ各国の種のチェックリストは、原則として、ある国の完全なリストをその国の範囲のサブセットとして提供します。国のリストは、国の脅威の状態やその他の関心のある特性など、地域の詳細を追加することができ、その結果、新しいデータセットが作成されます。この場合、レコードレベルでの帰属と、元データセットとの関連付けを提供できることが重要です。そのために推奨される手段は以下の通りです。

  1. 新しい派生リソースそのものを表す 1 つのメタデータ文書が作成されます(例:National Checklist of the Netherlands)。参照されるデータセットは、このメタデータ文書で引用することができます。

    1. コントリビューターの役割を持つ機関として完全に記述され、ソースのWebサイトへのリンクがあります。

    2. 引用されたデータセットが、推奨される形式で書誌事項欄に引用されていること。

  2. データファイルでは、レコードレベルでの追加的な帰属や関連付けを行うことができます。これには以下のようなものがあります。

    1. *dwc:datasetName*でデータセット名を参照すしていること。

    2. *dwc:datasetID*でデータセットをID(URLなど)で参照し、データセットのホームページへリンクできます。

    3. *dc:source*を使用して、参照するデータセットウェブサイトの対応する種のページへのリンクを提供できます。

      1. *dc:source*が派生データベースのURLを指すために予約されている場合でも、代替識別子拡張機能を使用してソースデータベースへのリンクを追加することができます。

    4. もしソースデータセットが、リストで参照されている分類群に対してグローバルにユニークな識別子を提供している場合、それを派生データセットの*taxonID*として使用することができます。これにより、ソース分類群への明確なリンクが確保されます。

    5. *dwc:nameAccordingTo*または*dwc:nameAccordingToID*を使って、対応するソースレコードのタクソン定義を引用またはURLとして参照します。

方言名(地方名)の共有

分類学的チェックリストの分類群に関連する方言名データの共有に対応しています。方言名は、Vernacular Names extensionを使用した、別の関連ファイルとして共有されます。この拡張子は、地域的および形態的な修飾子を含む、方言名の使用方法を説明するための豊富なプロパティセットをサポートしています。

myristica fragrans

もしソースデータセットが、リストで参照されている分類群に対してグローバルにユニークな識別子を提供している場合、それを派生データセットの*taxonID*として使用することができます。このようにすることで、元の分類群との明確なリンクが確保され、非常におすすめです。さらに、方言名のレコードには、方言名で使用されている言語を特定する言語参照を付けることが推奨されます。言語情報の共有には、ISO 693 言語コード を使用するのが最良の方法です。地方名は地域ごとに異なる用途を持つことがあり、これは*dwc:locality*要素、またはより正確でないレベルでは *dwc:country*を使って指定することができる。国名は、ISO 3166 国名コードがあれば、それを利用することが推奨されます。

種の解説を共有する

分類群に関連する記述情報の共有に対応しています。説明文データは、Taxon Description extensionを用いて、関連する別のファイルとして共有されます。記述データは個別の記述タイプに割り当てることができ、拡張機能でデータを公開すると、1 つの分類群に複数の記述レコードをリンクすることができ、分類群ごとに比較的豊富なデータセットをサポートします。説明情報を記述するために、description type vocabularyを使用することが推奨されます。

複数行の説明

説明情報は、単一段落のテキストブロックに限定する必要があります。 改行を含む複数の段落は、ダーウィンコア・アーカイブとして出力される結果のテキストファイルの整合性を維持するために、回避するか、慎重に管理する必要があります。 テキストファイルとして機能する複数行のデータフィールドでは、複数行のフィールド内で使用される改行とは異なるレコード区切り文字(通常は改行文字)が必要です。 1つのフィールドで複数行をサポートするための最良の方法は、改行文字を、データが解析および使用されるときにユーザーが適切な改行に置き換えることができる非改行文字または文字セットに置き換えることです。 1つのオプションは、HTMLブレークタグ`<br>`を使用することです。

種の分布を共有する

配布データの共有がサポートされています。 配布データは、Species Distribution extensionを使用して、別個の関連ファイルとして共有されます。 これにより、分類群ごとに複数の配布レコードを公開できます。 分布拡張は、国または地域の分布の説明を指定するために使用されるだけでなく、分類群の脅威ステータス、導入されているかどうか、ネイティブなど、およびその他のプロパティに関する参照された分布の認定も対応します。 特定の定義された領域に関連付けられています。

明確に地域を指定するための推奨される最良の方法は、*dwc:localityID*要素で公開される解決可能な、またはよく知られた地域識別子を介することです。

*dwc:country*要素を使用する場合は、ISO 3166 国名コードを使用することをお勧めします。

リファレンスを共有する

書誌引用の共有がサポートされています。 書誌データは、リファレンス拡張を使用して別個の関連ファイルとして共有されます。リファレンス拡張は、モノグラフおよび注釈付きチェックリストでのシノニム情報の共有に使用するために推奨および設計されています。 解析された引用の共有をサポートしているため、*dwc:namePublishedIn*などのコアデータファイル内の引用を保存するデータ要素の一部よりも詳細な引用形式を提供します。 この拡張機能は、リファレンスタイプ語彙プロパティを介した参照の分類学的および命名上の修飾をサポートします。これは、リファレンスタイプ語彙とともに使用すると、分類群に関連する一連の参照を区別するために使用できます。

タイプ情報の共有

タイプと標本に関する情報の共有がサポートされています。これらのデータは、タイプと標本の拡張を使用して、別個の関連ファイルとして共有されます。タイプ標本、タイプ種、属に関する基本情報の共有をサポートします。

リンクと識別子の共有

Alternate Identifier Extensionを使用して、関連する外部リソースへの複数のリンクを共有および説明することができます。 これにより、データ発行者は、解決可能な識別子を介してソースデータベースまたはドキュメントにリンクを埋め込むことができます。 おそらくWebページとより機械可読なWebサービス応答の両方にリンクする複数の識別子が、単一の分類群に提供される場合があります。 識別子が解決可能である場合にユーザーが応答情報を解釈する方法を知ることができるように、各レコードにフォーマットを含めることをお勧めします。 これは通常、このフィールドに*MIME type*(または*MIME type*)を含めることによって行われます。 メディアタイプの完全なリストは、こちらから入手できます。

種のページへの動的リンクの作成

多くの場合、ソースデータベースへのリンクは一般的な形式に従い、URLで使用される識別子番号または分類群名のみが異なります。これにより、冗長で肥大化した拡張子ファイルが生成される可能性があります。ダーウィンコア・アーカイブ形式は、URLテンプレートを定義するためのより効率的な方法をサポートします。これは、一度だけ定義する必要があり、変数をテンプレートに埋め込むことができるため、データ内の分類群ごとにURLのセットを繰り返し繰り返す必要がありません。これは、ダーウィンコア・アーカイブのXMLメタファイルコンポーネントを介して行われます。リファレンス拡張機能は使用しません。これには、XMLメタファイルを編集する必要があり、XMLにある程度精通している必要があります。GBIFは、ダーウィンコアメタファイルへの完全なガイドを提供します

メタファイルは、WebページまたはWebサービス呼び出しを参照する可能性のあるメタファイル内の変数の作成をサポートします。この変数はURLに埋め込まれ、URLのパラメーターの1つとして分類群識別子または分類群名を含めることができます。公開されたデータの任意の列は、中括弧「{}」でインデックス番号を囲むことによって参照できます。コアデータファイルの分類群識別子は、変数「{id}」を介して参照することもできます。次の例は、これらの機能を示しています。

  1. 統合分類情報システム(ITIS)は、分類シリアル番号(TSN)を使用して、Webサイトの分類ページへのリンクを提供します。

    コアデータファイルがITIS TSNシステムを使用して公開されている場合、次の構文を使用して、リンクを作成し、コアデータ標準の「識別子」用語に関連付けることができます。

    <field default="http://www.itis.gov/servlet/SingleRpt/SingleRpt?search_topic=TSN&search_value={id}" term="http://purl.org/dc/terms/identifier"/>

    ここで、元の数値は変数`{id}`に置き換えられます。この値はコアIDから取得されます。

  2. The 2010 Catalogue of Life Annual Checklistには、同様の識別子が記載されています。また、URLとしてエンコードできる名前ベースの検索もサポートしています。例えば、

    http://www.catalogueoflife.org/annual-checklist/2010/search/all/key/Struthio+camelus/match/1

    学名「Struthio camelus」をURLに埋め込みます。完全な科学名の組み合わせは、ダーウィンコア語彙「scientificName」を使用してコアデータファイルで公開できます。この用語がコアデータファイルの12番目の列を表すと仮定すると、構文を使用できます。

    <field default="http://www.catalogueoflife.org/annual-checklist/2010/search/all/key/{12}/match/1" term="http://purl.org/dc/terms/identifier"/>

    ここで、`{12}`は、URLで置き換えられる12番目の列の値を表します。

GBIFチェックリスト拡張

チェックリストのコアデータファイルには、分類群の記録が含まれています。 分類群レコードを説明するために使用できる一連の用語は、分類群(コア)拡張機能によって定義されます。

各分類群レコードは、拡張ファイル内の1つ以上のレコードで拡張できます。各拡張レコードを説明するために使用できる一連の用語は、その拡張によって定義されます。

以下は、分類群レコードに関する追加情報を提供するために使用できる拡張機能の完全なリストです。

分類群(コア)拡張

最新版発行日:2022-02-02

この一連の用語を使用して、分類、シノニム、その他の重要な要素を含む種のチェックリストの基本的な情報を提供します。このリストの各行は、受け入れられた名前またはシノニムのいずれかの分類群名を表します。このクラスの用語は、分類情報を表すためのさまざまなメソッドをサポートしています。分類は、界、門、綱などの列と「スプレッドシートスタイル」で共有することも、直接の親のIDを含むフィールドを持つ各分類群行と「データベーススタイル」で共有することもできます。表には、受け入れ可能な用語の完全なリストが含まれていることに注意してください。チェックリストを共有するための最小要件は、種のリストと同じくらい小さいですが、付随するIDを強くお勧めします。この用語のリストを使用して、共有するデータに最適な用語を特定します。用語名に躊躇しないでください。説明を読んで、関連する用語を見つけてください。

通俗名の拡張

最新版発行日:2015-02-13

この拡張機能は、コアデータファイル内の分類群にリンクされている一般的な(一般的な)名前に関連する情報を共有する手段を提供します。複数の固有名は、*taxonID*を介して同じ分類群にリンクできます。

リファレンス拡張

最新版発行日:2015-02-13

この拡張機能を使用して、コアデータファイル内の分類群に関連する1つ以上の書誌リファレンスを記述します。タイプフィールドを使用して、リファレンスを修飾します。この拡張機能は、参照される同義チェックリストの共有をサポートします。

種の説明の拡張

最新版発行日:2022-02-02

この拡張機能は、ある分類群の1つまたは複数の分布リファレンスに関する情報を共有するために使用します。同じ分類群に対して、1つまたは複数の産地記録をリンクすることができます。例えば、複数の地域、地方、国が記載されている場合があります。この拡張機能を使用して、ある分類群に対する脅威の状態、季節的な分布の変化、および特定の地域におけるある分類群に関連するその他の特性を記述します。

種の解説を共有する

最新版発行日:2015-02-13

この拡張機能を使用して、タクソンの説明テキストを提供します。これは通常、データベースに格納されるような、レコードごとに一段落という形式です。説明文は、例えば形態保存や繁殖などに関する説明であることを示すために、 タイプで修飾することができます。複数の記述がある場合、記述ファイルには複数のレコードが存在することになります。

代替識別子

最新版発行日:2015-02-13

この拡張子は、その分類群に関する情報への識別子やリンクが複数ある場合に使用します。ソースデータベースは、例えばウェブページ、ウェブサービス、およびLSID、DOIなどの解決可能な識別子を通じて、ソースデータレコードへのアクセスを提供することができます。

タイプと標本数の拡張機能

最新版発行日:2015-02-13

コア分類群にリンクされた1つまたは複数の標本またはタイプリファレンスに関連するデータを共有するには、この拡張機能を使用します。

リソース関係拡張機能

最新版発行日:2022-02-02

この拡張機能は、コアタクソンが他の分類群(ソースリスト内またはレコードに含まれる)と持っている1つ以上の関係を記述するために使用されます。例えば、コア種リストに記載されているハチが受粉する植物種のリスト(1種につき1レコード)を提供するために利用することができます。


1. These categories and descriptions are derived directly from “Hyam . R., Standardisation of Data Exchange in the Pan-European Species-directories Infrastructure (PESI) Deliverable D 4.1”