アーキテクチャ·プラグインを実現する

メタデータアーキテクチャおよびプロファイル

メタデータアーキテクチャ記述：

  1. メタデータアーキテクチャ内の要素の名前、記述、および任意の値コードリスト

  2. メタデータパターンの要素のメタデータ文書(構造)におけるレイアウト方式

  3. メタデータ文書中の要素と内容に対する制約

  4. メタデータアーキテクチャ要素の使用方法に関する文書

  5. メタデータ文書およびメタデータテンプレートの例を示す.

  6. メタデータ文書と他のメタデータアーキテクチャとの間で相互に変換するためのスクリプト

メタデータモデルは、通常、メタデータ標準の実現である。

メタデータプロファイルは，特定のコミュニティのニーズに適応するためにメタデータモデルの改編である.メタデータプロファイルは、メタデータモードのすべてのコンポーネントを含むが、これらのコンポーネントを拡張、制限、または再定義することができる。

メタデータアーキテクチャまたはプロファイルを実現する

メタデータモードやプロファイルを実現する方式には様々な種類がある.本節では，https：//github.com/geonetwork/schema-pluginsやhttps：//github.com/metadata 101上でメタデータアーキテクチャを実現する方式について述べる.

各メタデータパターンは，ファイルシステム木として実現されるMavenモジュールである.ツリーのルートは、略語形式のメタデータアーキテクチャの名前である。ミドル·メタデータ·アーキテクチャの基本コンポーネント src/main/plugin/<schema_id> フォルダ，レイアウトは以下のとおりである.

  1. loc この情報はローカル化された3文字ごとの言語コードのサブディレクトリディレクトリであり，内容はXML文書(labels.xml，codelists.xml)にある.例えば： loc/eng/codelists.xml メタデータ要素を記述する英語コードリスト。

  2. パターン 名前のディレクトリとファイル schema.xsd XSD階層構造の単一入口点に提供する.例えば： schema/gmd/gmd.xsd

  3. Schematron ディレクトリは，ISO Schematron言語を用いて実現されたメタデータ文書中の要素やコンテンツに制約を持つ.

  4. docs ディレクトリには、メタデータアーキテクチャ要素をどのように使用するかに関する文書が含まれている。

  5. sample-data ディレクトリには，例示的なメタデータ文書が含まれている.

  6. 転換する. ディレクトリには，メタデータ文書を他のアーキテクチャと相互変換するXSLTが含まれている.

次節では，これらのディレクトリやファイル内容に関するより多くの情報を提供する.

参考

Https：//github.com/geonnetwork/schema-pluginsまたはhttps：//github.com/metadata 101上のいくつかのアーキテクチャは、GeoNetworkアーキテクチャプラグインとして実現されているので、上記よりも多くの情報を含む。

アーキテクチャプラグイン

GeoNetworkで使用可能なパターンプラグインは，スタイル表，XMLパターン記述(XSD)とGeoNetworkインデックス，XMLメタデータレコードからの内容を編集するために必要な他の情報を含むディレクトリである.

GeoNetworkで利用するためには，シナリオリストを手動で置くことができる. schema_plugins GeoNetworkデータディレクトリのサブディレクトリ.いくつかのモードでは、WEB−INF/libフォルダに追加のJARファイルを追加すべきである。デフォルトの地理的ネットワークデータディレクトリの位置は INSTALL_DIR/web/geonetwork/WEB-INF/data それがそうです。

これらのアーキテクチャの内容はGeoNetwork初期化期間中に解析を行う.有効であれば，GeoNetwork起動時に利用可能である.

アーキテクチャディレクトリのzipアーカイブを作成し，管理メニューの機能の1つを用いてGeoNetworkにアップロードすれば，GeoNetworkにアーキテクチャを動的に追加することも可能である.

  1. サーバファイルパス(ファイルセレクタを用いて指定)

  2. HTTP URL(例えば、Http：//ome host/ome directory/iso 19139.mjp.zip)

  3. ISO 19115/19139メタデータレコードに付加されたオンラインリソースとして

アップロードされたアーキテクチャも schema_plugins GeoNetworkデータディレクトリのサブディレクトリ.

参考

ここではテンプレートモジュールhttps：//github.com/geonnetwork/schema-plugins/tree/Development/iso 19139.xyzを提供しており，良い例である.

地理的ネットワークプログラムの内容

実装後，GeoNetworkモデルは1つのディレクトリである.

サブディレクトリは src/main/plugin/<schema_id> ：

  • パターン ：(1) 任意選択. )メタデータパターンを含む公式XSDのディレクトリ。モードがDTDによって記述されている場合、このディレクトリは任意である。DTDで記述されたアーキテクチャはGeoNetworkで編集できないことに注意されたい.

  • Schematron ：(1) 任意選択. )は、コンテンツ条件をチェックするためのアーキテクチャのディレクトリを含む。

  • docs ：(1) 任意選択. )パターンに関する文書

  • index-fields ：(1) 強制的である. )メタデータレコードに必要なXSLTディレクトリ。

  • loc ：(1) 強制的である. )局所化情報ディレクトリ：タグ、コードリスト、またはパターン固有の文字列。例。 loc/eng/codelists.xml

  • 転換する. ：(1) 強制的である. )メタデータをアーキテクチャからアーキテクチャに変換するか、またはアーキテクチャのXSLTディレクトリに変換する。これは、メタデータを他のモードに変換したり、メタデータを他のモードやフォーマットからそのモードに変換したりすることができる。例。 convert/oai_dc.xsl

  • 布図. ：(1) バージョン3.xは必須項目です )エディタ内にメタデータを提示するための構成を含む。

  • プログラムをフォーマットする. ：(1) バージョン3.xオプション )は、GroovyまたはXSLTフォーマットプログラムを用いてメタデータを表す構成を含む。

  • 提示する. ：(1) 2.x版は必須項目 )ビューア/エディタでメタデータを表すためのXSLTを含む。

  • present/csw ：(1) 強制的である. )CSWの短い要約、要約、および完全記録要求に応答するためのXSLTを含む。

  • 行程を決める. ：(1) 任意選択. )メタデータ提案機構によりメタデータ要素を処理するためのXSLTを含む(参照 suggest.xsl (下記参照)。

  • sample-data ：(1) 任意選択. )このアーキテクチャのサンプルメタデータ。メタデータ例は、MEFフォーマットを使用するので、例は、サムネイルまたは閲覧グラフィックおよびオンラインリソースを有することができる。

  • テンプレート ：(1) 任意選択. )このアーキテクチャのテンプレートおよびサブモードメタデータレコードのディレクトリを含む。テンプレートメタデータレコードは、一般に、特定の目的のための要素(およびコンテンツ)のセットを有するメタデータレコードである。例。Iso 19139.mcpアーキテクチャには、アーキテクチャの強制要素および予期されるコンテンツの例を有する‘Minimum Element’テンプレートがある。

以下のような表を示すことができる。

  • extract-date-modified.xsl ：(1) 強制的である. )メタデータレコードから修正日を抽出します。

  • extract-gml.xsl ：(1) 強制的である. )メタデータレコードからGML GeometryCollection要素として空間範囲を抽出する。

  • extract-thumbnails.xsl ：(1) 任意選択. )メタデータレコードからブラウジンググラフ/サムネイルを抽出する。

  • extract-uuid.xsl ：(1) 強制的である. )メタデータレコードのUUIDを抽出する。

  • extract-relations.xsl ：(1) 任意選択. )メタデータレコードの関連リソース(例えば、オンラインリソース，サムネイル).

  • set-thumbnail.xsl ：(1) 任意選択. )メタデータレコード内のブラウジンググラフィックス/サムネイルを設定します。

  • set-uuid.xsl ：(1) 任意選択. )メタデータレコードのUUIDを設定します。

  • suggest.xsl ：(1) 任意選択. )メタデータアドバイスサービスによって実行されるXSLT。XSLTは，メタデータレコードの異なる要素に登録して実行可能なプロセスを含む.例えば。内容をコンマで区切られたキーワードセグメントを複数のキーワードセグメントに展開する.参照してください メタデータの内容改善に関する提案 もっと情報があります。

  • unset-thumbnail.xsl ：(1) 任意選択. )ブラウジンググラフ/サムネイルをメタデータレコードから削除します。

  • update-child-from-parent-info.xsl ：(1) 任意選択. )XSLTは、親レコードから更新された子レコードのどの要素を指定する。メタデータレコード間の階層関係を管理するために用いられる.

  • update-fixed-info.xsl ：(1) 任意選択. )メタデータレコード中の“固定”コンテンツをXSLT更新します。

以下の構成ファイルが表示される場合があります。

  • oasis-catalog.xml ：(1) 任意選択. )このモードに適用される任意のマッピングを記述するオアシスディレクトリ、例えば。URLは、schemaLocationsのようなローカルコピーにマッピングされる。Http：//www.isoc 211.org/2005/gmd/gmd.xsdにマッピング schema/gmd/gmd.xsd それがそうです。OASISディレクトリで使用されるパス名のそのファイルに対する位置，すなわちパターンディレクトリである.

  • schema.xsd ：(1) 任意選択. )このメタデータアーキテクチャで使用されるXSDを含むXMLアーキテクチャディレクトリファイル。アーキテクチャがDTDを使用する場合、このファイルは存在すべきではない。GeoNetworkではDTDを用いたアーキテクチャにおけるメタデータレコードを編集することはできない.

  • schema-conversions.xml ：(1) 任意選択. )このアーキテクチャに属するレコードに適用可能な変換器を記述するXML文書。このモードに属するメタデータレコードが検索結果に表示される場合、情報は、これらの変換をユーザが選択するためのオプションとして表示するために使用される。

  • schema-ident.xml ：(1) 強制的である. )パターン名、識別子、バージョン番号、およびそのパターンに属するメタデータレコードをどのように識別するかに関する詳細情報を含むXML文書。この文書は以下の位置でXMLアーキテクチャ定義を持つ. INSTALL_DIR/web/geonetwork/xml/validation/schemaPlugins/schema-ident.xsd これは，ロードモード時に検証するために用いられる.

  • schema-substitutes.xml ：(1) 任意選択. )XMLファイルは、特定の要素の代替として使用することができる要素セットを再定義する。

  • schema-suggestions.xml ：(1) 任意選択. )複雑な要素のどのサブ要素をエディタ内で自動的に展開するかをエディタに伝えるXMLファイル。

はい。 index-fields フォルダには、以下のファイルが必要です。

  • default.xsl ：(1) 強制的である. )インデックスLucene内のメタデータは、コンテンツを記録します。GeoNetworkがメタデータの記録内容をインデックスするためのLucene文書を作成する.

  • language-default.xsl ：(1) 任意選択. )多言語メタデータをインデックス化するために必要な

これらのコンポーネント中の各コンポーネントが何であるかと何が必要なのかの理解を支援するために，GeoNetworkのためのschemaPluginをどのように構築するかを示すステップ例を提供する.

調製する.

GeoNetworkのためのモードプラグインを作成するためには、ソースコードを見る必要があります。

git clone --recursive https://github.com/geonetwork/core-geonetwork

次に、例を含むモード·プラグイン·リポジトリを表示することができます：

git clone --recursive https://github.com/geonetwork/schema-plugins

ここに表示されている例を使用するためには、schemas Mavenモジュールのサブディレクトリに新しいモード·プラグインを作成する必要があります(参照 source file schemas )である。♪the iso19139.xyz モードプラグインのリポジトリからのプラグインは良いスタートかもしれません。

作成後、アプリケーションの構築に新しいプラグインを登録する必要があります。そのためには

<module>iso19139.xyz</module>

<resource>
   <directory>${project.basedir}/../schemas/iso19139.xyz/src/main/plugin</directory>
   <targetPath>${basedir}/src/main/webapp/WEB-INF/data/config/schema_plugins</targetPath>
 </resource>

  • プラグインがJavaカスタムを実現する場合、依存項を登録することもできます(参照 source file web/pom.xml )：

<dependency>
  <groupId>${project.groupId}</groupId>
  <artifactId>schema-iso19139.xyz</artifactId>
  <version>${project.version}</version>
</dependency>

例-ISO 19115/19139海洋コミュニティの概要(Mcp)

海洋群落概況は海洋共同体のためのISO 19115/19139概況である。このプロファイルは、ISO 19115メタデータ規格を拡張し、ISO 19139に記載されたISO 19115のXMLで実現された拡張を用いて実現される。ISO 19115メタデータ規格およびそのXML実現ISO 19139は、ISO配信チャネルを介して取得することができる。

海洋コミュニティの概要の文書はhttp：//www.aodc.gov.au/files/MarineCommunityProfilev 1.4.pdf上で見つけることができる。海洋コミュニティ概要XMLモデルとして定義された実現は，https：//www.seegrid.csiro.au/wiki/AppSchemas/MetadataProfilesに記述された方法に基づく.XMLパターン定義(XSD)はURL http：//Bluenet 3.antcrc.utas.edu.au/mcp-1.4に位置する.

XMLパターン定義を見ると、プロファイルは、基本ISO 19139規格にいくつかの新しい要素が追加されている。したがって，GeoNetworkのためのプラグイン海洋コミュニティ概要モデルを定義する基本思想は，GeoNetworkが提供する基本ISO 19139モデルをできるだけ多く用いて定義することである.

次に，MCPを実現するGeoNetworkプラグインモデルの各コンポーネントをどのように作成するかについて基本ステップで説明する.

Schema-ident.xmlファイルの作成

現在，我々は，アーキテクチャを識別し，そのアーキテクチャに属するメタデータ記録に必要な情報を提供する必要がある.MCPのschema-ident.xmlファイルは以下の通りです。

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://geonetwork-opensource.org/schemas/schema-ident"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <name>iso19139.mcp</name>
  <id>19c9a2b2-dddb-11df-9df4-001c2346de4c</id>
  <version>1.5</version>
  <schemaLocation>
    http://bluenet3.antcrc.utas.edu.au/mcp
    http://bluenet3.antcrc.utas.edu.au/mcp-1.5-experimental/schema.xsd
    http://www.isotc211.org/2005/gmd
    http://www.isotc211.org/2005/gmd/gmd.xsd
    http://www.isotc211.org/2005/srv
    http://schemas.opengis.net/iso/19139/20060504/srv/srv.xsd
  </schemaLocation>
  <autodetect xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp"
              xmlns:gmd="http://www.isotc211.org/2005/gmd"
              xmlns:gco="http://www.isotc211.org/2005/gco">
    <elements>
      <gmd:metadataStandardName>
        <gco:CharacterString>
          Australian Marine Community Profile of ISO 19115:2005/19139|
          Marine Community Profile of ISO 19115:2005/19139
        </gco:CharacterString>
      </gmd:metadataStandardName>
      <gmd:metadataStandardVersion>
        <gco:CharacterString>
          1.5-experimental|
          MCP:BlueNet V1.5-experimental|
          MCP:BlueNet V1.5
        </gco:CharacterString>
      </gmd:metadataStandardVersion>
    </elements>
  </autodetect>
</schema>

各要素は以下のとおりである.

  • name GeoNetworkでは、スキームの名前を識別するために使用されます。モードがGeoNetworkの基本パターンに追加されたプロファイルであれば，そのパターンを<base_schema_name>.<Namespace_of_profile>と名付けるのが通例である.

  • id -アーキテクチャの一意の識別子。

  • バージョン -アーキテクチャのバージョン番号。GeoNetworkには複数のバージョンのアーキテクチャが存在することができる.

  • SchemaLocation ペアのセットであり、ペアの第1のメンバは名前空間URIであり、第2のメンバはXSDの公式URLである。この要素の内容は，GeoNetworkが示すどのメタデータレコードのルート要素にもschemaLocation/noNamespaceSchemaLocation属性として付加される(このような属性が存在しなければ).公式のschemaLocation/noNamespaceSchemaLocationが必要であれば(例えば、ListMetadataFormats OAI要求に応答する).

  • 自動検出 ·このアーキテクチャに属する任意のメタデータレコードに存在しなければならない要素または属性(コンテンツ付き)を含む。GeoNetworkが未知のアーキテクチャのメタデータレコードを受信すれば，アーキテクチャ検出の間にこのオプションを用いる.

  • フィルター.フィルター -オプションで、ユーザ権限に応じたアプリケーションを含むカスタムフィルタ

このファイルを作成すると、使用中のXMLアーキテクチャ定義(XSD)を使用して手動で検証することができます INSTALL_DIR/web/geonetwork/xml/validation/schemaPlugins/schema-ident.xsd それがそうです。このXSDは、アーキテクチャをロードする際にこのファイルを検証するためにも使用されます。Schema-ident.xml検証に失敗した場合，アーキテクチャはロードされない.

自動検出に関する詳細情報

GeoNetworkが記録が属するメタデータパターンを認識する必要がある場合には，schema-ident.xmlの自動検出部を用いることができる.

本節で評価順に用いることができる5つのルールは，

1.プロパティ -文書内で1つまたは複数の属性および/または名前空間を検索するステップと。一例は、新しい名前空間下の任意の要素をgmd：IdentificationInfo/gmd：md_dataIdentifyに追加するISO 19115/19139のプロファイルである。このプロファイルに属するレコードを検出するためには、schema-ident.xmlファイル中の自動検出部分を以下に示すことができる。

<autodetect xmlns:cmar="http://www.marine.csiro.au/schemas/cmar.xsd">
  <!-- catch all cmar records that have the cmar vocab element -->
  <attributes cmar:vocab="http://www.marine.csiro.au/vocabs/projectCodes.xml"/>
</autodetect>

属性自動検出に関する他のポイント：

  • 複数の属性を指定することができる-すべての属性は一致しなければならず，レコードをこのアーキテクチャに属すると認識することができる.

  • 属性に名前空間がある場合は，autodeetect要素上またはschema-ident.xml文書中のある位置で名前空間を指定すべきである.

2.要素 -ドキュメント内で1つ以上の要素を検索します。一例の用例は、前の例schema-ident.xmlファイルに表示された用例である：

<autodetect xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp"
            xmlns:gmd="http://www.isotc211.org/2005/gmd"
            xmlns:gco="http://www.isotc211.org/2005/gco">
  <elements>
    <gmd:metadataStandardName>
      <gco:CharacterString>
        Australian Marine Community Profile of ISO 19115:2005/19139|
        Marine Community Profile of ISO 19115:2005/19139
      </gco:CharacterString>
    </gmd:metadataStandardName>
    <gmd:metadataStandardVersion>
      <gco:CharacterString>
        1.5-experimental|
        MCP:BlueNet V1.5-experimental|
        MCP:BlueNet V1.5
      </gco:CharacterString>
    </gmd:metadataStandardVersion>
  </elements>
</autodetect>

要素の自動検出に関する他のポイントは

  • 複数の要素、例えば、指定することができる。以上のように，metadataStandardNameとmetadataStandardVersion-はすべてマッチしなければならず，レコードをこのアーキテクチャに属すると認識することができる.

  • 要素に複数の値を指定することができる。例えば。以上のように，gmd：metadataStandardVersionにマッチするものが見つかる. 1.5-experimental OR MCP:BlueNet V1.5-experimental OR MCP:BlueNet V1.5 -ここでは、縦線または縦線文字‘|’分離オプションを使用します。正規表現を用いることもできる.

  • 要素に名前空間がある場合、名前空間はautodetect要素上で指定されるべきであるか、またはschema−ident.xml文書内のある位置で、それらの要素を使用する前に指定されるべきである−例えば。上のコードでは，内容を混乱させないように，autodetect要素に名前空間宣言がある.

3.根要素 -ドキュメントのルート要素は一致しなければなりません。一例は、EML-GBIFモード用の用例である。このアーキテクチャに属する文書はつねにルート要素eml：emlを持つので，このアーキテクチャの自動検出部分は：

<autodetect xmlns:eml="eml://ecoinformatics.org/eml-2.1.1">
  <elements type="root">
    <eml:eml/>
  </elements>
</autodetect>

根元素の自動検出に関する他のポイント：

  • 複数の要素−セット内の記録されたルート要素に一致する任意の要素が一致することを指定することができる。

  • 要素に名前空間がある場合、名前空間は、それらの要素を使用する前に、自動的に検出された要素上またはschema−ident.xml文書内のある位置で指定されなければならない−例えば。以上と同様に，明確にするためにautodetect要素に名前空間宣言がある.

4.名前空間 -ドキュメント内で1つ以上の名前空間を検索します。一例は、csw：Recordパターン用の用例である。Csw：Recordアーキテクチャに属するレコードは、3つの可能なルート要素を有することができる：csw：Record、csw：SummaryRecord、およびcsw：BriefRecordであるが、マルチ要素ルート自動検出を使用するのではなく、汎用的なcsw名前空間を使用して自動検出を行うことができる：

<autodetect>
  <namespaces xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"/>
</autodetect>

名前空間の自動検出に関する他のポイント：

  • 複数の名前空間を指定することができる-すべての名前空間が存在しなければならず，レコードはこのアーキテクチャに属すると識別される.

  • プレフィックスは無視される.レコードに見つかった名前空間URIがNamespaces自動検出要素で指定された名前空間URIと一致すると，名前空間マッチングが発生する.

5.デフォルトモード -これは、インストールされたモードのいずれにも一致しないレコードの障害保護規定です。デフォルトアーキテクチャの値は、appandler構成で指定されています INSTALL_DIR/web/geonetwork/WEB-INF/config.xml プロファイル、または自動検出動作を呼び出す指定されたデフォルト値(例えば、あるメタデータレコードを一括ロードしたユーザから解析した値).柔軟性と正確性の理由から、インストールされたモードの自動検出情報を用いて記録を検出することが好ましい。デフォルトモードは、特定のモードに記録を割り当てる“すべてのキャプチャ”方法のみである。中のconfig要素 INSTALL_DIR/web/geonetwork/WEB-INF/config.xml 以下に示す.

<appHandler class="org.fao.geonet.Geonetwork">
  .....
  <param name="preferredSchema" value="iso19139" />
  .....
</appHandler>

自動検出評価に関する詳細情報

自動検出のルール評価は以下のとおりである.

for-each autodetect rule type in ( 'attributes/namespaces', 'elements',
                                   'namespaces', 'root element' )
  for-each schema
    if schema has autodetect rule type then
      check rule for a match
      if match add to list of previous matches
    end if
  end for-each

  if more than one match throw 'SCHEMA RULE CONFLICT EXCEPTION'
  if one match then set matched = first match and break loop
end for-each

if no match then
  if namespaces of record and default schema overlap then
    set match = default schema
  else throw 'NO SCHEMA MATCHES EXCEPTION'
end if

return matched schema

例えば、以下の自動検出要素を有する3つのモードiso 19139.mcp、iso 19139.mcp-1.4、iso 19139.mcp-cmarがあると仮定する。

iso19139.mcp-1.4:

<autodetect xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp"
            xmlns:gmd="http://www.isotc211.org/2005/gmd"
            xmlns:gco="http://www.isotc211.org/2005/gco">
  <elements>
    <gmd:metadataStandardName>
      <gco:CharacterString>
        Australian Marine Community Profile of ISO 19115:2005/19139
      </gco:CharacterString>
    </gmd:metadataStandardName>
    <gmd:metadataStandardVersion>
      <gco:CharacterString>MCP:BlueNet V1.4</gco:CharacterString>
    </gmd:metadataStandardVersion>
  </elements>
</autodetect>

iso19139.mcp-cmar:

<autodetect>
    <attributes xmlns:mcp-cmar="http://www.marine.csiro.au/schemas/mcp-cmar">
</autodetect>

Iso 19139.mcp：

<autodetect xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp">
  <elements type="root">
    <mcp:MD_Metadata/>
  </elements>
</autodetect>

自動検出処理が行われているレコード(例えば、導入時)は以下の項目に照らして検査を行う.

  • Iso 19139.mcp-cmarまず、“Attributes”(属性)ルールがあるからです。

  • そしてiso 19139.mcp-1.4‘Elements’ルールがあるからです

  • そして最後にiso 19139.mcpと照合すると、“根元素”のルールがあるからです。

この処理アルゴリズムの背後にある思想は、基本パターンが“ルート要素”ルール(または“名前空間”ルールを制御することが困難)を使用し、プロファイルが“属性”または“要素”のようなより細かいまたはより具体的なルールを使用することである。

フィルターに関するより多くの情報

ディレクトリ·コンテンツ構成に基づいてダウンロードおよび動的に動作する機能を追加することを目標としています。具体的には、異なる意味を持つ可能性があります。

  • モード(例えば、ダウンロードするファイルのURLはDublin CoreとISO 19139の同じ位置ではない)

  • 記録コーディング規則(例えば、ダウンロードは、アップロードされたファイルだけではなく、WFSリンクとすることができる)。

各操作タイプのフィルタ配置は，フィルタ部分のschema-ident.xmlで定義される.

フィルタ定義：

  • 操作(AccessManagerにおけるcanEdit，canDownload，canDynamicメソッドとのマッチング)

  • フィルタリングする要素を選択するためのXPath

  • 置換された要素の任意の要素定義を置換する(一致項が見つかった場合、この要素属性またはサブ要素を挿入する)。このオプションは、削除されたプリミティブをハイライト表示するために使用されます。

<filters>
  <!-- Filter element having withheld nilReason for user who can not edit -->
  <filter xpath="*//*[@gco:nilReason='withheld']"
          ifNotOperation="editing">
    <keepMarkedElement gco:nilReason="withheld"/>
  </filter>
  <!-- Filter element having protocol download for user who can not download -->
  <filter xpath="*//gmd:onLine[*/gmd:protocol/gco:CharacterString = 'WWW:DOWNLOAD-1.0-http--download']"
          ifNotOperation="download"/>
  <!-- Filter element having protocol WMS for user who can not dynamic -->
  <filter xpath="*//gmd:onLine[starts-with(*/gmd:protocol/gco:CharacterString, 'OGC:WMS')]"
          ifNotOperation="dynamic"/>
</filters>

ユーザ権限に応じてXMLSerializerにフィルタを適用する.

Schema-ident.xmlを設定した後、MCP用の新しいGeoNetworkプラグインモデルは、：

schema-ident.xml

Schema-Conversions.xmlファイルの作成

このファイル記述は、アーキテクチャに属するメタデータレコードの変換器に適用することができる。変換器ごとにGeoNetwork(Jeeves)サービスとして手動で定義しなければならず，そのサービスを呼び出して特定のメタデータレコードを異なるアーキテクチャに変換することができる.MCPのschema-Conversions.xmlファイルは以下の通りです。

<conversions>
   <converter name="xml_iso19139.mcp"
              nsUri="http://bluenet3.antcrc.utas.edu.au/mcp"
              schemaLocation="http://bluenet3.antcrc.utas.edu.au/mcp-1.5-experimental/schema.xsd"
              xslt="xml_iso19139.mcp.xsl"/>
   <converter name="xml_iso19139.mcp-1.4"
              nsUri="http://bluenet3.antcrc.utas.edu.au/mcp"
              schemaLocation="http://bluenet3.antcrc.utas.edu.au/mcp/schema.xsd"
              xslt="xml_iso19139.mcp-1.4.xsl"/>
   <converter name="xml_iso19139.mcpTooai_dc"
              nsUri="http://www.openarchives.org/OAI/2.0/"
              schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc.xsd"
              xslt="oai_dc.xsl"/>
   <converter name="xml_iso19139.mcpTorifcs"
              nsUri="http://ands.org.au/standards/rif-cs/registryObjects"
              schemaLocation="http://services.ands.org.au/home/orca/schemata/registryObjects.xsd"
              xslt="rif.xsl"/>
</conversions>

各変換器は、以下の属性を有する。

  • name -コンバータの名前。これはGeoNetwork(Jeeves)サービスのサービス名であり，唯一であるべきである(サービス名の前にXML_<SCHEMA_NAME>を加えることはその名前を一意にする良い方法である).

  • NsURI −変換器によって生成されたアーキテクチャの主な名前空間。例えば。Xml_iso 19139.mcpTorifcsは、メタデータレコードをiso 19139.mcpからRIFCSモードに変換する。RIFCSメタデータモードにおけるメタデータレコードは、マスター名空間URI http：//ands.org.au/Standards/rif−cs/registryObjectsを有する。

  • SchemaLocation -nsURIに対応するXMLアーキテクチャ定義(XSD)の位置(URL)。

  • xslt -変換を実際に実行するXSLTの名前。このXSLTは，パターンプラグインのConvertサブディレクトリに位置すべきである.

Schema-Conversions.xmlを設定した後、我々の新しいMCP用GeoNetworkプラグインアーキテクチャは、：

**

Schema-Conversions.xml schema-ident.xml

アーキテクチャディレクトリとschema.xsdファイルの作成

GeoNetworkエディタと検証関数はschema.xsdコンポーネントを用いる.

GeoNetworkのエディタは，メタデータ文書中の要素を正しくソートするだけでなく，メタデータ文書以外の任意の要素を作成するオプションを提供するXSDを用いてフォームを構築する.この方法の背後にある考えは二重だ。まず，エディタはXMLパターン定義ルールを用いて，ユーザが構造的に誤った文書を作成しないように支援することができる.必須要素や要素の順序付けが足りないことは正しくない。次に，同じエディタコードをXSDを定義したXMLメタデータ文書のいずれにも用いることができる.

自分のメタデータパターンを定義している場合、XSD言語を使用してXMLパターン文書を作成することができます。このような言語の要素はhttp：//www.w 3 School s.com/schema/で見つけることができ，プリシラ·ウォルムスリーの最終XML Schema(Prentice Hall，2002)のような教科書を参照することもできる.GeoNetworkのXMLパターン解析コードはほとんどのXSD言語を理解できるが，再定義，Any，anyAttributeは除く(後の2言語は特殊な場合に扱うことができるにもかかわらず).

海洋公益プロファイルの場合、基本的に基礎標準ISO 19115/19139の拡張を定義した。これらの拡張は、ISO 19139で定義されたタイプでXSD拡張機構を使用して定義される。以下のコードセグメントは、revisionDateと呼ばれる新しい要素を追加するために、海洋コミュニティプロファイルがgmdをどのように拡張するかを示す：MD_METADATA要素：

<xs:schema targetNamespace="http://bluenet3.antcrc.utas.edu.au/mcp"
           xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp">

  <xs:element name="MD_Metadata" substitutionGroup="gmd:MD_Metadata"
                                 type="mcp:MD_Metadata_Type"/>

  <xs:complexType name="MD_Metadata_Type">
    <xs:annotation>
      <xs:documentation>
       Extends the metadata element to include revisionDate
      </xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="gmd:MD_Metadata_Type">
        <xs:sequence>
          <xs:element name="revisionDate" type="gco:Date_PropertyType"
                      minOccurs="0"/>
        </xs:sequence>
        <xs:attribute ref="gco:isoType" use="required"
                      fixed="gmd:MD_Metadata"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

簡単に言うと、私たちは、GMD：MD_METADATA_Typeの拡張であるmcp：mcp_METADATA_Typeの新しい要素mcp：md_METADATAを定義します。拡張により、新しいタイプは古いタイプのすべての要素を含み、新しい要素mcp：revisionDateを含むという意味です。強制属性(gco：isotype)は、mcp：MD_METADATAにも付加され、拡張された要素の名前(GMD：MD_METADATA)に固定値が設定されています。

このようにプロファイルを定義することにより，下位のISO 19139モードを修正する必要はない.したがって，MCPのモードディレクトリは基本的に拡張と基本ISO 19139モードからなる。1つの可能なディレクトリ構造は以下のとおりである.

extensions gco gmd gml gmx gsr gss gts resources srv xlink

拡張ディレクトリは、単一のファイルmcpExtensions.xsdを含み、このファイルは、GMD名前空間を導入します。残りのディレクトリはISO 19139基本アーキテクチャである。

Schema.xsdファイルはGeoNetworkが検索したファイルであり，mcpExtensions.xsdファイルと基本ISO 19139モードの一部として導入されていない他の名前空間を導入する.以下に示す.

<xs:schema targetNamespace="http://bluenet3.antcrc.utas.edu.au/mcp"
           elementFormDefault="qualified"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:mcp="http://bluenet3.antcrc.utas.edu.au/mcp"
        xmlns:gmd="http://www.isotc211.org/2005/gmd"
        xmlns:gmx="http://www.isotc211.org/2005/gmx"
        xmlns:srv="http://www.isotc211.org/2005/srv">
  <xs:include schemaLocation="schema/extensions/mcpExtensions.xsd"/>
  <!-- this is a logical place to include any additional schemas that are
       related to ISO19139 including ISO19119 -->
  <xs:import namespace="http://www.isotc211.org/2005/srv"
             schemaLocation="schema/srv/srv.xsd"/>
  <xs:import namespace="http://www.isotc211.org/2005/gmx"
             schemaLocation="schema/gmx/gmx.xsd"/>
</xs:schema>

この段階では，MCPに対する新しいGeoNetworkプラグイン方式が含まれる.

schema-conversions.xml  schema-ident.xml  schema.xsd  schema

抽出を作成しています...XSLTS

GeoNetworkは，メタデータレコードから特定の情報を抽出し，メタデータアーキテクチャとは独立した汎用簡略化XML構造に変換する必要がある.XSLTは，JavaコードのXPathとは異なり，XMLを処理して汎用的で簡略化されたXML構造を返すために用いられる.

私たちが作成する3つのxsltは：

  • extract-date-modified.xsl このXSLTは、メタデータレコードを処理し、最後にメタデータレコードを修正した日付を抽出する。MCPの場合、この情報は、mcp：MD_METADATAのサブ要素であるmcp：revisionDate要素に保存される。MCPのためにこの名前を作成する最も簡単な方法は、iso 19139モードからExtract-Date-Modified.xslをコピーし、MCP名空間に適応するように修正し、gmd：datestampの代わりにmcp：revisionDateを使用することである。

  • extract-gml.xsl +このXSLTは、メタデータレコードを処理し、GML GeometryCollection要素として空間範囲を抽出します。GMLはGeoToolsに渡されて空間インデックス(shapefileや空間データベース)に挿入される.ISO 19115/19139およびプロファイルの場合、このタスクは、(境界ブロックを除いて)空間範囲がメタデータレコードにおいてgmlとして符号化されるので、非常に容易である。同様に、MCPのためにそれを作成する最も簡単な方法は、iso 19139モードからExtract-gml.xsdをコピーし、MCP名空間に適応するように修正することである。

MCPメタデータレコードにおける境界ブロックセグメントの例は以下のとおりである。

<gmd:extent>
  <gmd:EX_Extent>
    <gmd:geographicElement>
      <gmd:EX_GeographicBoundingBox>
        <gmd:westBoundLongitude>
          <gco:Decimal>112.9</gco:Decimal>
        </gmd:westBoundLongitude>
        <gmd:eastBoundLongitude>
          <gco:Decimal>153.64</gco:Decimal>
        </gmd:eastBoundLongitude>
        <gmd:southBoundLatitude>
          <gco:Decimal>-43.8</gco:Decimal>
        </gmd:southBoundLatitude>
        <gmd:northBoundLatitude>
          <gco:Decimal>-9.0</gco:Decimal>
        </gmd:northBoundLatitude>
      </gmd:EX_GeographicBoundingBox>
    </gmd:geographicElement>
  </gmd:EX_Extent>
</gmd:extent>

このXMLを含むメタデータレコードに対してExtract-gml.xslを実行すると：

<gml:GeometryCollection xmlns:gml="http://www.opengis.net/gml">
  <gml:Polygon>
    <gml:exterior>
      <gml:LinearRing>
        <gml:coordinates>
          112.9,-9.0, 153.64,-9.0, 153.64,-43.8, 112.9,-43.8, 112.9,-9.0
        </gml:coordinates>
      </gml:LinearRing>
    </gml:exterior>
  </gml:Polygon>
</gml:GeometryCollection>

メタデータレコードに複数の領域がある場合、それらはこのgml：GeometryCollection要素にも現れるべきである。

GMLに関するより多くの情報を知るためには，Lake，Burggraf，Trineic，Rae，“GML地理マークアップ言語，地理ネットワークの基礎”，Wley，2004年を参照されたい.

最後に，予測について説明する.MCPレコード中の境界ポリゴンは，EPSG：4326以外の投影に位置することができる。空間範囲をShapefileや空間データベースに書き込む場合，GeoNetworkはGeoToolsが既知(GeoToolsが理解する形で符号化)のすべての投影をEPSG：4326に変換する.

  • extract-uuid.xsl -このXSLTは、メタデータレコードを処理し、レコードの識別子を抽出する。MCPおよび基本ISO規格の場合、この情報は、mcp：MD_METADATAのサブ要素であるgmd：fileIdentifier要素に保存される。

これらのxsltは、パターン内のメタデータレコード上で実行することによってテストすることができる。Saxon XSLTプロセッサを使用する必要があります。例えば：

java -jar INSTALL_DIR/web/geonetwork/WEB-INF/lib/saxon-9.1.0.8b-patch.jar
     -s testmcp.xml -o output.xml extract-gml.xsl

この段階では，MCPに対する新しいGeoNetworkプラグイン方式が含まれる.

extract-date-modified.xsl  extract-gml.xsd   extract-uuid.xsl
schema-conversions.xml  schema-ident.xml  schema.xsd  schema

Locディレクトリでローカル化された文字列を作成する

Locディレクトリはこのアーキテクチャに特定された局所化文字列を含み，サブディレクトリ中の言語略語順に配列される.

あなたがアーキテクチャを使用することを望む任意の言語でネイティブ文字列を提供しなければなりません。

このパターンの局所化された文字列は、プレゼンテーションxsltsおよびschematronエラーメッセージで使用することができる。プレゼンテーションxsltsについて：

  • 制御された語彙表フィールドのコードリストは、例えば、loc/<language_abbreimal>/codelists.xmlにあるべきである。 loc/eng/codelists.xml

  • XML要素名をより理解しやすい/代替句で置き換えるタグ文字列およびスクロール支援文字列は、例えば、loc/<language_abbreumation>/labels.xmlに配置されるべきである。 loc/eng/labels.xml それがそうです。

  • 他のすべての局所化文字列は、例えば、loc/<language_abbreumation>/string s.xmlに位置しなければならない。 loc/eng/strings.xml

McpはISO 19115/19139のプロファイルであり，プロファイルのGeoNetwork命名約束に従っているため，mcp固有やカバーしたいタグやコードリストのみを含める必要があることに注意されたい.他のタグおよびコードリストは、基本モードISO 19139から検索される。

Codelists.xmlに関するもっと多くの情報

通常、コードリストは、http：//www.isoc 211.org/2005/gmd/Identification.xsdのiso 19139モードにおけるGMD：MD_TopicCategoryCodeからのコードリスト：など、メタデータパターンXSDにおけるエニュメリストから生成される。

<xs:element name="MD_TopicCategoryCode" type="gmd:MD_TopicCategoryCode_Type"/>

<xs:simpleType name="MD_TopicCategoryCode_Type">
   <xs:restriction base="xs:string">
     <xs:enumeration value="farming"/>
     <xs:enumeration value="biota"/>
     <xs:enumeration value="boundaries"/>
     <xs:enumeration value="climatologyMeteorologyAtmosphere"/>
     <xs:enumeration value="economy"/>
     <xs:enumeration value="elevation"/>
     <xs:enumeration value="environment"/>
     <xs:enumeration value="geoscientificInformation"/>
     <xs:enumeration value="health"/>
     <xs:enumeration value="imageryBaseMapsEarthCover"/>
     <xs:enumeration value="intelligenceMilitary"/>
     <xs:enumeration value="inlandWaters"/>
     <xs:enumeration value="location"/>
     <xs:enumeration value="oceans"/>
     <xs:enumeration value="planningCadastre"/>
     <xs:enumeration value="society"/>
     <xs:enumeration value="structure"/>
     <xs:enumeration value="transportation"/>
     <xs:enumeration value="utilitiesCommunication"/>
   </xs:restriction>
 </xs:simpleType>

以下は、要素のために手動で作成されたcodelists.xmlエントリの一部です。

<codelist name="gmd:MD_TopicCategoryCode">
  <entry>
    <code>farming</code>
    <label>Farming</label>
    <description>Rearing of animals and/or cultivation of plants. Examples: agriculture,
      irrigation, aquaculture, plantations, herding, pests and diseases affecting crops and
      livestock</description>
  </entry>
  <!-- - - - - - - - - - - - - - - - - - - - - - - - - -->
  <entry>
    <code>biota</code>
    <label>Biota</label>
    <description>Flora and/or fauna in natural environment. Examples: wildlife, vegetation,
      biological sciences, ecology, wilderness, sealife, wetlands, habitat</description>
  </entry>
  <!-- - - - - - - - - - - - - - - - - - - - - - - - - -->
  <entry>
    <code>boundaries</code>
    <label>Boundaries</label>
    <description>Legal land descriptions. Examples: political and administrative
    boundaries</description>
  </entry>

  .....

</codelist>

Xmlファイルは、code要素を介してXSD内の列挙値を局所化タグおよび記述にマッピングします。

Codelists.xmlの局所化コピーは、例えば、XSLTSを表すXPath上で利用可能である。/root/gui/schemas/iso 19139/codelist(iso 19139アーキテクチャに適しています)。

XSLT metadata.xslは、XSLTが使用するテンプレートを表すすべてのメタデータパターンを含み、エディタで選択リスト/プルダウンメニューを作成し、メタデータビューアにコードおよび記述を表示する担当です。

Iso 19139モードは、ディレクトリ/語彙ファイル(http：//www.isoc 211.org/2005/Resources/Codelist/gmxCodelists.xml)においてXSD外部で管理されている追加コードリストを有する。これらのコードリストもcodelists.xmlファイルに追加されており、プロファイル内でそれらを局所化し、カバーすることができ、メタデータレコードを見る際により有用な情報を提供するための拡張記述を含む。

ISO 19139コードリストをプロファイルで使用するためには、使用するコードリストを指すためのテンプレートを追加することができます。

<xsl:template mode="mode-iso19139.xyz" match="*[*/@codeList]">
  <xsl:param name="schema" select="$schema" required="no"/>
  <xsl:param name="labels" select="$labels" required="no"/>

  <xsl:apply-templates mode="mode-iso19139" select=".">
    <xsl:with-param name="schema" select="$schema"/>
    <xsl:with-param name="labels" select="$labels"/>
    <xsl:with-param name="codelists" select="$codelists"/><!-- Will be the profile codelist -->
  </xsl:apply-templates>
</xsl:template>

いくつかのISO 19139コードリストを上書きするためには、xyzプロファイルにコードリストが定義されているかどうかを確認することができ、そうでない場合には、ISO 19139コードリストを使用することができる：

<!-- check iso19139.xyz first, then fall back to iso19139 -->
<xsl:variable name="listOfValues" as="node()">
  <xsl:variable name="profileCodeList" as="node()" select="gn-fn-metadata:getCodeListValues($schema, name(*[@codeListValue]), $codelists, .)"/>
  <xsl:choose>
    <xsl:when test="count($profileCodeList/*) = 0"> <!-- do iso19139 -->
      <xsl:copy-of select="gn-fn-metadata:getCodeListValues('iso19139', name(*[@codeListValue]), $iso19139codelists, .)"/>
    </xsl:when>
    <xsl:otherwise>
      <xsl:copy-of select="$profileCodeList"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:variable>

Iso 19139モードは、このモードに固有であるので、xsltにコードリストを処理するための追加テンプレートを有することを表す。これらは，本マニュアルの後にXSLTを示す節について議論する.

Labels.xmlに関するより多くの情報

Labels.xmlの局所化コピー、例えば、XSLTSを表すXPath上に提供することができる。/root/gui/schemas/iso 19139/labels(iso 19139アーキテクチャに適しています)。

♪the labels.xml ファイルはまた、自由テキストフィールドのためのヘルプ値を提供するために、以下のプル/選択リストの形態で使用されてもよい。例えば：

<element name="gmd:credit" id="27.0">
  <label>Credit</label>
  <description>Recognition of those who contributed to the resource(s)</description>
  <helper>
    <option value="University of Tasmania">UTAS</option>
    <option value="University of Queensland">UQ</option>
  </helper>
</element>

これにより、エディタ(XSLT metadata.xslを介して)がプルダウン/選択メニューにクレジットフィールドを表示し、その横に以下のヘルパーオプションを以下に示すようになります。

../_images/editor-helper.png

String s.xmlに関するもっと多くの情報

現地化されたコピーです strings.xml XSLTSを表すXPath上で利用可能であり、例えば。/root/gui/schemas/iso 19139/string(iso 19139アーキテクチャに適しています)。

ローカル化文字列を追加すると，MCP用の新しいGeoNetworkプラグインモデルは以下のようになる.

extract-date-modified.xsl  extract-gml.xsd  extract-uuid.xsl
loc  present  schema-conversions.xml  schema-ident.xml  schema.xsd
schema

フォーマットプログラムを使用してプレゼンテーションを作成する

バージョン 3.0 で追加.

参考

3.x版のフォーマットプログラム部分TODOを参照されたい

カスタムエディタ.

バージョン 3.0 で追加.

参考

バージョン3.xのエディタ構成部分TODOを参照してください

現在のディレクトリでプレゼンテーションXSLTを作成する

バージョン 3.0.0 で非推奨.

各メタデータアーキテクチャは、アーキテクチャに属するメタデータレコードを表示して編集することが可能なXSLTを含むべきである。これらのXSLTは present カタログです。

XSLT包含/導入階層で用いるためには，これらのXSLTは命名規則：METADATA-<schema-name>.xslに従う必要がある.したがって、例えば、iso 19139モードの表現XSLTは metadata-iso19139.xsl それがそうです。MCPでは，我々のパターン名はiso 19139.mcpであるため，XSLTを表すことを表す. metadata-iso19193.mcp.xsl それがそうです。

XSLTに含まれるXSLTを表す任意のXSLTも現在のディレクトリに含まれるべきである(これは明確な約束である-それは強制的ではない，パターンのoASIS-Catalog.xmlにおいてinclude/import URLを他の位置にマッピングすることができるので).

プレゼンテーションXSLTはいくつかのXSLTテンプレートを持たなければならない：

  • ♪the main テンプレートは，METADATA-<schema-name>と名付けなければならない.Iso 19139のMCPプロファイルの場合、メインテンプレートは以下のようになる(METADATA-iso 19139.mjp.xslより)：

<xsl:template name="metadata-iso19139.mcp">
  <xsl:param name="schema"/>
  <xsl:param name="edit" select="false()"/>
  <xsl:param name="embedded"/>

  <xsl:apply-templates mode="iso19139" select="." >
    <xsl:with-param name="schema" select="$schema"/>
    <xsl:with-param name="edit"   select="$edit"/>
    <xsl:with-param name="embedded" select="$embedded" />
  </xsl:apply-templates>
</xsl:template>

このテンプレートを分析しています：

  1. 名前=“METADATA-iso 19139.mcp”は、metadata.xsl：elementEP内のプライマリ·エレメント処理テンプレートによって使用されます。主なメタデータサービスshowとeditは，それぞれJavaサービスから渡されたメタデータレコードを用いてMETADATA-show.xslとMETADATA-edit.xslを呼び出す.これら2つのXSLTはいずれもmetadata.xsl中のelementEPテンプレートを根要素に適用することでメタデータ記録を扱う.ElementEPテンプレートは、モード名iso 19139.mcpを使用してこのメインモードテンプレートを呼び出します。

  2. このマスターテンプレートのタスクは、モード名または基本パターン名(本例ではiso 19139)に一致するパターン名宣言のテンプレートを使用して、メタデータレコードのすべての要素を処理するように構成される。このモード処理は、このアーキテクチャまたは基本アーキテクチャ内のメタデータ要素を処理することが意図されたテンプレートのみを適用することを保証するためである。これは，ほとんどのプロファイルが基本アーキテクチャ内の要素を変更したり，少量の要素を追加したりするためである.したがって、プロファイル内のメタデータ要素の多くは、基本アーキテクチャモードで処理することができる。本節以降では，基本アーキテクチャにおける要素をどのようにカバーするかの処理を見る.

  • A タブを完成させる テンプレートは，<schema-name>CompleteTabと名付けなければならない.このテンプレートは、エディタ/ビューア画面の左側フレームに“Default”(またはシンプルモード)および“XML View”タブ以外のすべてのタブを表示します。以下にMCPの例を示す.

<xsl:template name="iso19139.mcpCompleteTab">
  <xsl:param name="tabLink"/>

  <xsl:call-template name="displayTab"> <!-- non existent tab - by profile -->
    <xsl:with-param name="tab"     select="''"/>
    <xsl:with-param name="text"    select="/root/gui/strings/byGroup"/>
    <xsl:with-param name="tabLink" select="''"/>
  </xsl:call-template>

  <xsl:call-template name="displayTab">
    <xsl:with-param name="tab"     select="'mcpMinimum'"/>
    <xsl:with-param name="text"    select="/root/gui/strings/iso19139.mcp/mcpMinimum"/>
    <xsl:with-param name="indent"  select="'&#xA0;&#xA0;&#xA0;'"/>
    <xsl:with-param name="tabLink" select="$tabLink"/>
  </xsl:call-template>

  <xsl:call-template name="displayTab">
    <xsl:with-param name="tab"     select="'mcpCore'"/>
    <xsl:with-param name="text"    select="/root/gui/strings/iso19139.mcp/mcpCore"/>
    <xsl:with-param name="indent"  select="'&#xA0;&#xA0;&#xA0;'"/>
    <xsl:with-param name="tabLink" select="$tabLink"/>
  </xsl:call-template>

  <xsl:call-template name="displayTab">
    <xsl:with-param name="tab"     select="'complete'"/>
    <xsl:with-param name="text"    select="/root/gui/strings/iso19139.mcp/mcpAll"/>
    <xsl:with-param name="indent"  select="'&#xA0;&#xA0;&#xA0;'"/>
    <xsl:with-param name="tabLink" select="$tabLink"/>
  </xsl:call-template>

  ...... (same as for iso19139CompleteTab in
 GEONETWORK_DATA_DIR/schema_plugins/iso19139/present/
 metadata-iso19139.xsl) ......

</xsl:template>

このテンプレートは，中名“tab”(“Default”と“XML View”タブも付加された)のテンプレートから呼び出される INSTALL_DIR/web/geonetwork/xsl/metadata-tab-utils.xsl アーキテクチャ名を使用します。XSLTはまた、“displayTab”テンプレートのコードを含む。

“mcpMinimum”，“mcpCore”，“Complete”などはタブの名前である.現在またはアクティブタブの名前は、XSLTが利用可能であることを表すすべてのグローバル変数“currTab”に格納されています。ルート処理オプションカードには，特定のオプションカードがアクティブ状態にあるときにどのような内容を表示するかを決定するロジックが含まれているはずである.

  • A 根元素. “処理中”タブ。オプションカードは、メタデータレコードのルート要素と一致しなければならない。例えば、iso 19139モードの場合：

<xsl:template mode="iso19139" match="gmd:MD_Metadata">
  <xsl:param name="schema"/>
  <xsl:param name="edit"/>
  <xsl:param name="embedded"/>

  <xsl:choose>

  <!-- metadata tab -->
  <xsl:when test="$currTab='metadata'">
    <xsl:call-template name="iso19139Metadata">
      <xsl:with-param name="schema" select="$schema"/>
      <xsl:with-param name="edit"   select="$edit"/>
    </xsl:call-template>
  </xsl:when>

  <!-- identification tab -->
  <xsl:when test="$currTab='identification'">
    <xsl:apply-templates mode="elementEP" select="gmd:identificationInfo|geonet:child[string(@name)='identificationInfo']">
      <xsl:with-param name="schema" select="$schema"/>
      <xsl:with-param name="edit"   select="$edit"/>
    </xsl:apply-templates>
  </xsl:when>

  .........

</xsl:template>

このテンプレートは、基本的に非常に長い“Choose”文であり、現在定義されているタブ(グローバル変数currTabにおける)の値をテストするための“When”節を有する。各“WHEN”節は、オプションカード定義に対応するメタデータ要素セット(上の“IDENTIFY”タブの“When”節に示すように)をそのまま“elementEP”を用いて表示するか、タブ定義に対応するメタデータ要素セットを名前テンプレート(上の“METADATA”オプションカードのように)で表示する。MCPの場合、我々のテンプレートは、iso 19139に対する上記のテンプレートと同様であり、一致する点は“mcp：MD_METADATA”である(また、処理モードが異なる場合がある−より詳細については、以下の“プロファイルの代替XSLT設計”の節を参照されたい)。

  • A 簡略化する. テンプレートは，<schema-name>Briefと名付けなければならない.このテンプレートは，メタデータレコードを処理し，その中からフォーマットとは無関係なメタデータ要約を抽出し，検索結果を表示するなどの目的で用いられる.以下は、EML-GBIFモードの一例である(かなり短いので！)：

<xsl:template match="eml-gbifBrief">
 <xsl:for-each select="/metadata/*[1]">
  <metadata>
    <title><xsl:value-of select="normalize-space(dataset/title[1])"/></title>
    <abstract><xsl:value-of select="dataset/abstract"/></abstract>

    <xsl:for-each select="dataset/keywordSet/keyword">
      <xsl:copy-of select="."/>
    </xsl:for-each>

    <geoBox>
        <westBL><xsl:value-of select="dataset/coverage/geographicCoverage/boundingCoordinates/westBoundingCoordinate"/></westBL>
        <eastBL><xsl:value-of select="dataset/coverage/geographicCoverage/boundingCoordinates/eastBoundingCoordinate"/></eastBL>
        <southBL><xsl:value-of select="dataset/coverage/geographicCoverage/boundingCoordinates/southBoundingCoordinate"/></southBL>
        <northBL><xsl:value-of select="dataset/coverage/geographicCoverage/boundingCoordinates/northBoundingCoordinate"/></northBL>
    </geoBox>
    <xsl:copy-of select="geonet:info"/>
  </metadata>
 </xsl:for-each>
</xsl:template>

このテンプレートを分析しています：

  1. このテンプレートは、METADATA-utils.xslのmode=“Brief”テンプレートによって作成されたEML-gbiBrief要素に一致する。メタデータレコードは、/METADATA XPathの最初のサブレベルとなる。

  2. 次に、メタデータ要素を処理して平面XML構造を生成し、search-Results-xhtml.xslは、この構造を使用して、検索されたメタデータレコードの要約を表示する。

同様に，既存パターンのプロファイルに対しては，やや異なる方法を用いることは意味があり，プロファイルはテンプレートを繰り返す必要がない.以下にMETADATA-iso 19139.mcp.xslの例を示す.

<xsl:template match="iso19139.mcpBrief">
  <metadata>
    <xsl:for-each select="/metadata/*[1]">
      <!-- call iso19139 brief -->
      <xsl:call-template name="iso19139-brief"/>
      <!-- now brief elements for mcp specific elements -->
      <xsl:call-template name="iso19139.mcp-brief"/>
    </xsl:for-each>
  </metadata>
</xsl:template>

このテンプレートは、基本iso 19139モードと、プロファイルに特定された要素を処理する短いテンプレートとの間で処理される。ここで仮定すると

  1. 基本アーキテクチャは、構成ファイルがそれを呼び出すことができるように、<METADATA>要素をその短い処理の残りの部分から分離しています。

  2. プロファイルは、共通要素を処理するために基本アーキテクチャによって使用され得る等価要素を指すリンク、例えば、リンクを含む。ISO 19139の場合、プロファイル内の要素は、gco：isotype属性を有し、これらの属性は、基本要素の名前を与え、“gmd：MD_DataIdentify|*のようなXPathマッチングで使用することができる。 [@gco:isoType='gmd:MD_DataIdentification'] “と。

  • アーキテクチャ固有の要素に一致するテンプレート。以下は、EML−GBIFモードからの例である。

<!-- keywords are processed to add thesaurus name in brackets afterwards
     in view mode -->

<xsl:template mode="eml-gbif" match="keywordSet">
  <xsl:param name="schema"/>
  <xsl:param name="edit"/>

  <xsl:choose>
    <xsl:when test="$edit=false()">
      <xsl:variable name="keyword">
        <xsl:for-each select="keyword">
          <xsl:if test="position() &gt; 1">,  </xsl:if>
          <xsl:value-of select="."/>
        </xsl:for-each>
        <xsl:if test="keywordThesaurus">
          <xsl:text> (</xsl:text>
          <xsl:value-of select="keywordThesaurus"/>
          <xsl:text>)</xsl:text>
        </xsl:if>
      </xsl:variable>
      <xsl:apply-templates mode="simpleElement" select=".">
        <xsl:with-param name="schema" select="$schema"/>
        <xsl:with-param name="edit"   select="$edit"/>
        <xsl:with-param name="text"    select="$keyword"/>
      </xsl:apply-templates>
    </xsl:when>
    <xsl:otherwise>
      <xsl:apply-templates mode="complexElement" select=".">
        <xsl:with-param name="schema" select="$schema"/>
        <xsl:with-param name="edit"   select="$edit"/>
      </xsl:apply-templates>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

このテンプレートを分析しています：

  1. 表示モードでは，集合中の各キーワードはコンマで区切られた文字列に接続されており，辞書名は末尾の括弧に位置する

  2. 編集モードでは，キーワードSetは複雑な要素ieとして扱われる.ユーザは、コンテンツおよび単一のシソーラス名を有する単一のキーワード要素を追加することができる。

  3. これは、メタデータレコード内の要素に対して実行可能な処理タイプの一例である。

プロファイルについては，要素のテンプレートは同じように定義することができ，テンプレートは基本アーキテクチャのパターンで処理されるだけである.以下の例は、mcp：revisionDate要素を処理するためのテンプレートの最初の行を示す。

<xsl:template mode="iso19139" match="mcp:revisionDate">
   <xsl:param name="schema"/>
   <xsl:param name="edit"/>

   <xsl:choose>
     <xsl:when test="$edit=true()">
       <xsl:apply-templates mode="simpleElement" select=".">
         <xsl:with-param name="schema"  select="$schema"/>
         <xsl:with-param name="edit"   select="$edit"/>

   ......

プロファイルのテンプレートが基本モードのテンプレートを上書きしようとする場合、優先度属性が高い数字に設定されたプロファイルの表示XSLTにテンプレートを定義し、XPath条件は、プロファイルのためにのみテンプレートを処理することを保証する(=たとえば，MCPでは，METADATA-iso 19139.mcp.xslにテンプレートを定義することで，METADATA-iso 19139.xsl中のgmd：ex_Geography icBordingBoxの処理を上書きすることができる.

<xsl:template mode="iso19139" match="gmd:EX_GeographicBoundingBox[starts-with(//geonet:info/schema,'iso19139.mcp')]" priority="3">

......

最後に、プロファイルは、基本アーキテクチャ内のいくつかの既存のコードリストを拡張することもできる。これらの拡張コードリストは，ローカル化されたcodelists.xmlに保存されるべきである.例えば、iso 19139では、これらのコードリストは、一般に以下の要素に追加される。

<gmd:role>
  <gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="custodian">custodian</gmd:CI_RoleCode>
</gmd:role>

これらの要素を処理するテンプレートは、iso 19139プレゼンテーションxsltにある。 GEONETWORK_DATA_DIR/schema_plugins/iso19139/present/metadata-iso19139.xsl それがそうです。これらのテンプレートは、要素の名前(例えば、GMD：CI_RoleCode)とコードリストXPath(例えば、/root/gui/schemas/iso 19139/codelists)は、編集時に選択リスト/プルダウンメニューを構築し、表示時に完全な記述を表示します。“iso 19139 Codelist”というテンプレートの近くのテンプレートを表示します。これらのテンプレートは、任意のプロファイルの拡張コードリストを処理することができる。

  • 属性codeListを有するサブ要素と一致する任意の要素

  • コードリストXPathではアーキテクチャ名を使用する

  • プロファイルコードリストに必要なコードリストがない場合は、基本iso 19139モードに戻る。

しかし，局所化コードリストが必要でなければ，直接 gmxCodelists.xml ファイルです。実は、これがMCPが採用した解決策だ。♪the gmxCodelists.xml ファイルはMCPのプレゼンテーションXSLTに含まれ，次の文を用いる.

<xsl:variable name="codelistsmcp"
              select="document('../schema/resources/Codelist/gmxCodelists.xml')"/>

コードリスト処理テンプレートにサインする metadata-iso19139.mcp.xsl これがどのように機能しているのか見てみましょう

プロファイルの別のXSLT設計

すべての強力な言語の中で、特定の目標を達成する方法は1つ以上だ。この代わりにXSLT設計はプロファイルを処理するために用いられる.代替案の背後にある考え方は，GeoNetwork XSLTの以下の観察に基づいている.

  1. すべての要素は最初にモードが“elementEP”であるアプリケーションテンプレートで処理される.

  2. テンプレート“elementEP”(参照) INSTALL_DIR/web/geonetwork/xsl/metadata.xsl )最終呼び出し main アーキテクチャ/プロファイルのテンプレート。

  3. プライマリ·テンプレートは、最初にプロファイルに固有のパターンで要素を処理することができ、これが成功しない場合(すなわち、テンプレートマッチングがないため，HTML要素が返されていない)は，その要素を基本パターンのパターンで処理する.

この設計の利点は，基本アーキテクチャ中の要素をカバーするテンプレートが優先度属性やアーキテクチャ名のXPath条件チェックを必要としないことである.

以下は、基本アーキテクチャiso 19139のMCP(iso 19139.mcp)の例である。

  • ♪the main テンプレート、名前を付けなければなりません：METADATA-iso 19139.mcp.xsl：

<!-- main template - the way into processing iso19139.mcp -->
<xsl:template name="metadata-iso19139.mcp">
  <xsl:param name="schema"/>
  <xsl:param name="edit" select="false()"/>
  <xsl:param name="embedded"/>

    <!-- process in profile mode first -->
    <xsl:variable name="mcpElements">
      <xsl:apply-templates mode="iso19139.mcp" select="." >
        <xsl:with-param name="schema" select="$schema"/>
        <xsl:with-param name="edit"   select="$edit"/>
        <xsl:with-param name="embedded" select="$embedded" />
      </xsl:apply-templates>
    </xsl:variable>

    <xsl:choose>

      <!-- if we got a match in profile mode then show it -->
      <xsl:when test="count($mcpElements/*)>0">
        <xsl:copy-of select="$mcpElements"/>
      </xsl:when>

      <!-- otherwise process in base iso19139 mode -->
      <xsl:otherwise>
        <xsl:apply-templates mode="iso19139" select="." >
          <xsl:with-param name="schema" select="$schema"/>
          <xsl:with-param name="edit"   select="$edit"/>
          <xsl:with-param name="embedded" select="$embedded" />
        </xsl:apply-templates>
      </xsl:otherwise>
    </xsl:choose>
</xsl:template>

このテンプレートを分析しています：

  1. 名前=“METADATA-iso 19139.mcp”は、metadata.xsl：elementEP内のプライマリ·エレメント処理テンプレートによって使用されます。主なメタデータサービスshowとeditは，それぞれJavaサービスから渡されたメタデータレコードを用いてMETADATA-show.xslとMETADATA-edit.xslを呼び出す.これら2つのXSLTはいずれもmetadata.xsl中のelementEPテンプレートを根要素に適用することでメタデータ記録を扱う.ElementEPは、アーキテクチャ名を使用して適切なメインアーキテクチャテンプレートを呼び出す。

  2. このメインテンプレートのタスクは、メタデータプロファイルのすべての要素を処理するように設定される。処理は2つのパターンの1つで行われる.まず、この要素をプロファイルモード(iso 19139.mcp)で処理する。適合項が見つかれば，HTML要素を返して出力文書にコピーする.HTML要素が返されていない場合、要素は、基本モードモードiso 19139で処理される。

  • プロファイル固有の要素に一致するテンプレートのパターンはiso 19139.mcp：

<xsl:template mode="iso19139.mcp" match="mcp:taxonomicElement">
  <xsl:param name="schema"/>
  <xsl:param name="edit"/>

  .....
</xsl:template>

  • 基本アーキテクチャ内の要素をカバーするテンプレートは、プロファイルモードiso 19139.mcpで処理されます。

<xsl:template mode="iso19139.mcp" match="gmd:keyword">
  <xsl:param name="schema"/>
  <xsl:param name="edit"/>

  .....
</xsl:template>

プロファイルのテンプレートタイトルがオリジナル設計で使用されている設計よりも簡単であることに気づきましたか？優先度属性もパターンXPath条件も必要ではないが，我々が使用しているパターンは基本パターンとは異なるためである.

  • 2つのモードでの処理をサポートするためには、以下に示すように、プロファイルモードiso 19139.mcpに空テンプレートを追加する必要があります。

<xsl:template mode="iso19139.mcp" match="*|@*"/>

このテンプレートは、プロファイルパターンiso 19139.mcpに特定のテンプレートのすべての要素を一致させません。これらの要素は、空テンプレートが何も返さないので、基本アーキテクチャモードiso 19139で処理される(上記の主要テンプレート議論を参照)。

オリジナル設計におけるタブなどに関する議論の残りは代替設計に適用されており，ここでは繰り返さない.

CSWプレゼンテーションXSLTS

CSWサーバには複数の出力モードで記録を提供することが要求される.GeoNetworkがサポートしている2つは：

  • ogc -http：//www.opengis.net/cat/csw/2.0.2-ダブリンコアデリバティブ

  • iso -Isostc 211.org/2005 gmd-iso 19115/19139

From each of these output schemas, a brief, summary or full element set can be requested.

これらの出力パターンと要素集合はGeoNetworkでXSLTとして実現され，‘Present’リストの‘csw’サブディレクトリに格納される.OGC出力モードXSLTはOGC-Brief.xsl，OGC-Summary，OGC-full.xslとして実現される.ISO出力モードXSLTはiso-Brief.xsl，iso-Summary.xsl，iso-full.xslとして実現される.

MCPのためにこれらのXSLTを作成するためには、基本モードiso 19139からCSW表現XSLTをコピーして修正することが望ましい。

プレゼンテーションXSLTSを作成した後、私たちの新しいMCP地理ネットワークプラグインアーキテクチャには：

extract-date-modified.xsl  extract-gml.xsd  extract-uuid.xsl
loc  present  schema-conversions.xml  schema-ident.xml  schema.xsd
schema

Index-fields.xslのインデックスメタデータレコードの内容の作成

このXSLTはメタデータレコード中の要素内容をインデックスする.このXSLTの本質は，メタデータレコードから要素を選択し，それらをLuceneインデックスフィールド名にマッピングすることである.GeoNetworkで用いられているLuceneインデックスフィールド名は以下のとおりである.

Luceneインデックスフィールド名

説明する.

要約.要約

メタデータの概要

どんなものでも

すべてのメタデータ要素からのコンテンツ(自由テキスト用)

期日を変更する

メタデータ記録の日付を修正する

作成日

メタデータレコードの作成日

分母.分母

データ解析における目盛り分母

ダウンロード

メタデータレコードにはダウンロード可能なリソースが付加されていますか？(0または1)

デジタル化する

メタデータレコードはデジタル形式で配布/利用可能ですか？(0または1)

東BL

東枠経度

キーワード

メタデータキーワード

メタデータ標準名

メタデータ標準名

北BL

北枠緯度

操作が開く

サービス動作を記述するデータセットのメタデータレコードのUUID

組織名.

連絡先情報に記載されている組織名

ParentUuid

親メタデータレコードのUUID

紙.紙

メタデータレコードは紙形式で配布/提供されていますか？(0または1)

協議

オンライン資源アクセスプロトコル

発表日.

資源発表日

南BL

南境界枠緯度

Spatialグラフィックス表現タイプ

ベクトル、グリッドなど

臨時拡張開始

時制範囲の開始

一時拡張終了

時制範囲終了

タイトル

メタデータタイトル

主題猫

メタデータ主題カテゴリ

タイプ

メタデータ階層階層レベル(未知であればデータセットであるべき)

西部BL

西枠経度

例えば、以下は、メタデータ要素mcp：revisionDateとLuceneインデックスフィールドchangeDateとの間で作成されるマッピング：

<xsl:for-each select="mcp:revisionDate/*">
  <Field name="changeDate" string="{string(.)}" store="true" index="true"/>
</xsl:for-each>

私たちは新しいXML文書を作成していることに注意してください。本稿では，プロファイル中のField要素をGeoNetworkで読み込み，インデックス用のLucene文書オブジェクトを作成する(GeoNetworkソースコード中のSearchManagerクラスを参照).

なお，mcpはISO 19115/19139のプロファイルであるため，修正した方がよい. index-fields.xsl MCPの名前空間と付加要素を処理することができます

この段階では，MCPに対する新しいGeoNetworkプラグイン方式が含まれる.

extract-date-modified.xsl  extract-gml.xsd  extract-uuid.xsl
index-fields.xsl  loc  present  schema-conversions.xml  schema-ident.xml
schema.xsd  schema

サンプル·データ·ディレクトリの作成

これは簡単なカタログです。このディレクトリには、インスタンスメタデータ付きMEFファイルが格納されています。彼らが1つあることを確認して .mef 接尾辞。

MEFファイルは、メタデータ、サムネイル、ファイルベースのオンラインリソース、および記述内容を含むINFOファイルの圧縮アーカイブである。本マニュアルの次節では、MEFファイルの内容をより詳細に検討します。

このディレクトリ内のサンプルデータは、管理メニューを用いてディレクトリに追加されてもよい。

この段階では，MCPに対する新しいGeoNetworkプラグイン方式が含まれる.

extract-date-modified.xsl  extract-gml.xsd  extract-uuid.xsl
index-fields.xsl  loc  present  sample-data schema-ident.xml  schema.xsd
schema

MCP条件を記述するためのモードの作成

SchematronはGeoNetworkで用いられている2段階検証過程の一部として，メタデータ記録中の条件と内容を検査するためのルールである.

Schematronルールは、前に署名されたschematronsディレクトリから作成されます-参照されたい 調製する. 上です。

1つの例示的なルールは

<!-- anzlic/trunk/gml/3.2.0/gmd/spatialRepresentation.xsd-->
<!-- TEST 12 -->
<sch:pattern>
  <sch:title>$loc/strings/M30</sch:title>
  <sch:rule context="//gmd:MD_Georectified">
    <sch:let name="cpd" value="(gmd:checkPointAvailability/gco:Boolean='1' or gmd:checkPointAvailability/gco:Boolean='true') and
      (not(gmd:checkPointDescription) or count(gmd:checkPointDescription[@gco:nilReason='missing'])>0)"/>
    <sch:assert
      test="$cpd = false()"
      >$loc/strings/alert.M30</sch:assert>
    <sch:report
      test="$cpd = false()"
      >$loc/strings/report.M30</sch:report>
  </sch:rule>
</sch:pattern>

多くのGeoNetworkと同様に，このルールの出力は異なる言語にローカル化できる.対応する局所化文字列は：

<strings>

  .....

  <M30>[ISOFTDS19139:2005-TableA1-Row15] - Check point description required if available</M30>

  .....

  <alert.M30><div>'checkPointDescription' is mandatory if 'checkPointAvailability' = 1 or true.</div></alert.M30>

  .....

  <report.M30>Check point description documented.</report.M30>

  .....

</strings>

Schematronsディレクトリにschematron規則を追加する手順：

  1. あなたの計画規則を“規則”に入れてください。命名情報は‘schematron-ules-<Suffix>.sch’であり，例えば schematron-rules-iso-mcp.sch それがそうです。規則が断言した局所化文字列を“Rules/loc/<language_prefix>”に入れる.

Schematronルールはアーキテクチャをロードする際にコンパイルされる.

この段階では，MCPに対する新しいGeoNetworkプラグイン方式が含まれる.

extract-date-modified.xsl  extract-gml.xsd  extract-uuid.xsl
index-fields.xsl  loc  present  sample-data  schema-conversions.xml
schema-ident.xml  schema.xsd  schema  schematron/schematron-rules-iso-mcp.sch

MCPメタデータの作成および編集に必要なコンポーネントの追加

我々はこれまでに，GeoNetwork認識，MCPメタデータ記録の確認，検証に必要なすべてのコンポーネントを追加してきた.現在、MCPメタデータレコードを作成して編集するために必要な残りのコンポーネントを追加します。

MCPメタデータレコード中の様々な要素コンテンツを設定したXSLTから開始する.

Set-uuid.xslの作成

  • set-uuid.xsl このXSLTは、メタデータレコードのUUIDをパラメータとし、メタデータレコードの対応する要素に書き込む。MCPでは，この要素は基本ISOモード(GeoNetworkではiso 19139と呼ぶ)と同様，すなわちgmd：fileIdentifierである.しかし，MCPはルート要素に異なる名前空間を用いるため，このXSLTを修正する必要がある.

サムネイルXSLTの抽出、設定、およびキャンセル設定の作成

メタデータレコードにサムネイルや図形リンクを閲覧することができる場合には，GeoNetworkサムネイル編集インタフェースを利用できるようにXSLTを付加してその情報を抽出，設定，キャンセルする必要がある.

このインタフェースをサポートする3つのXSLTは：

  • extract-thumbnails.xsl +このXSLTは、メタデータレコードからサムネイル/ブラウジング図形を抽出し、すべてのメタデータアーキテクチャに対して同じ汎用XMLに変換します。これらの要素はGeoNetworkが理解できる内容を含む必要がある.以下は、iso 19139サムネイルインタフェースの予期される例である(MCPに対してこの要求を繰り返す)。

<gmd:graphicOverview>
  <gmd:MD_BrowseGraphic>
    <gmd:fileName>
      <gco:CharacterString>bluenet_s.png</gco:CharacterString>
    </gmd:fileName>
    <gmd:fileDescription>
      <gco:CharacterString>thumbnail</gco:CharacterString>
    </gmd:fileDescription>
    <gmd:fileType>
      <gco:CharacterString>png</gco:CharacterString>
    </gmd:fileType>
  </gmd:MD_BrowseGraphic>
</gmd:graphicOverview>
<gmd:graphicOverview>
  <gmd:MD_BrowseGraphic>
    <gmd:fileName>
      <gco:CharacterString>bluenet.png</gco:CharacterString>
    </gmd:fileName>
    <gmd:fileDescription>
      <gco:CharacterString>large_thumbnail</gco:CharacterString>
    </gmd:fileDescription>
    <gmd:fileType>
      <gco:CharacterString>png</gco:CharacterString>
    </gmd:fileType>
  </gmd:MD_BrowseGraphic>
</gmd:graphicOverview>

いつ？ extract-thumbnails.xsl 実行時には，この情報に基づいて以下のような小型XML階層を作成する.

<thumbnail>
  <large>
    bluenet.png
  </large>
  <small>
    bluenet_s.png
  </small>
</thumbnail>

  • set-thumbnail.xsl -このXSLTの役割は、Extract-thhumbnails.xslとは逆である。GeoNetworkで用いられている簡略化された汎用XML構造を用いてサイズサムネイルを記述し，それらを表すメタデータ記録要素を作成する.これは、メタデータレコード内の既存の要素を保持する必要があり、正しい位置で新しい要素を作成する必要があるので、Extract−thhumbnails.xslよりもやや複雑なXSLTである。

  • unset-thumbnail.xsl -このXSLTは、特定のサムネイルを記述するメタデータ記録要素を使用して削除する。メタデータレコードの残りの要素は保持される.

McpはISO 19115/19139のプロファイルであるため、これらのXSLTを作成する最も簡単な方法は、iso 19139モードからそれらをコピーし、mcpに必要な名前空間変更に適応するように修正することである。

更新を作成しています--XSLTS

  • update-child-from-parent-info.xsl ·子レコードが親レコードから子レコードにコンテンツをコピーする必要がある場合、このXSLTが実行される。これはXSLTであり、いくつかの要素の内容を変更することができ、残りの要素は変化しないように維持することができる。このXSLTの動作は、親レコードのどの要素がサブレコードの要素を更新するために使用されるかに依存する。

  • update-fixed-info.xsl このXSLTは、メタデータレコード内のいくつかの要素およびコンテンツを修復するために、編集後に実行される。MCPの場合、私たちはいくつかの要素と内容を“ハード接続”するためにいくつかの行動を取りたい。そのため，XSLTは以下の処理論理を用いる.

if the element is one that we want to process then
  add a template with a match condition for that element and process it
else copy the element to output

Mcpはiso 19115/19139のプロファイルであるため、このxsltを作成する最も簡単な方法は、iso 19139モードからupdate-fix-info.xslをコピーし、mcpに必要な名前空間変更に適応し、所望の処理を含むように修正することです。

MCP処理の簡単な例の1つは、gmd：metadataStandardNameおよびgmd：metadataStandardVersion要素がMCPとして識別されたことを保証するために必要なコンテンツを保証することである。そのため，以下のように2つのテンプレートを追加することができる.

<xsl:template match="gmd:metadataStandardName" priority="10">
  <xsl:copy>
    <gco:CharacterString>Australian Marine Community Profile of ISO 19115:2005/19139</gco:CharacterString>
  </xsl:copy>
</xsl:template>

<xsl:template match="gmd:metadataStandardVersion" priority="10">
  <xsl:copy>
    <gco:CharacterString>MCP:BlueNet V1.5</gco:CharacterString>
  </xsl:copy>
</xsl:template>

加工者 update-fixed-info.xsl 使用できる 自動修復 “システム構成”メニューのチェックボックス。デフォルトでは、それは有効状態にあります。

いくつかの重要な課題を処理しています upgrade-fixed-info.xsl ：

  • 添付ファイルのメタデータを有するURL(例えば、Iso 19139には“ダウンロード用ファイル”が含まれているOnlineResources)

  • 日付スタンプ/改訂日の設定

  • コードリストURLは、オンラインISOコードリストディレクトリを指すように設定されています。

  • デフォルト空間参照系属性を空間範囲に追加する

MCPに必要な特定のタスク update-fixed-info.xsl メタデータUUIDに設定されたmetadata.showサービスを指すURLを自動的に作成します。これは、iso 19139によって提供されるupdate-fix-info.xslをいくつか変更する必要がある。特に：

  • メタデータレコードには親要素が存在しない可能性がある

  • メタデータ実点URLのオンラインリソース要素の処理は、オンラインリソース要素の他の処理に干渉してはならない

これを実現するために必要な各ステップと必要な意思決定をXSLT言語で記述するよりも，見てみたほうがよい. update-fixed-info.xsl Iso 19139.mcpディレクトリに存在するMCPアーキテクチャは、上のポイントを参照してください。

テンプレートディレクトリの作成

これは簡単なカタログです。テンプレートとして用いるXMLメタデータはこのディレクトリに格納される.彼らが1つあることを確認して .xml 接尾辞。このディレクトリのテンプレートは、管理メニューを使用してディレクトリに追加することができます。

エディタアクション：schema-suggestions.xmlとschema-substitutes.xmlを追加

  • schema-suggestions.xml -GeoNetwork高度エディタのエディタ·フォームを構築する際のデフォルト動作は、メタデータレコードに存在しない要素を未展開要素として表示することです。これらの要素をレコードに追加するためには、ユーザは、要素名の横の‘+’アイコンをクリックしなければなりません。これは、特に、いくつかのメタデータ基準に他のメタデータ基準の要素がネストされている場合(すなわち、複雑な要素)。Schema-suggestions.xmlファイルにより、エディタによって自動的に展開されるべき要素を指定することができます。ISO 19115/19139規格におけるオンラインリソース情報が一例である。以下のXMLを追加すると schema-suggestions.xml ファイル：

<field name="gmd:CI_OnlineResource">
  <suggest name="gmd:protocol"/>
  <suggest name="gmd:name"/>
  <suggest name="gmd:description"/>
</field>

このようにする効果は、インラインリソース要素が展開されると、プロトコルの入力フィールド(プルダウン/選択リスト)、名前、および記述がエディタ内に自動的に現れることである。

同様に構築されています schema-suggestions.xml MCPのファイルは schema-suggestions.xml Iso 19139モード用ファイル。

  • schema-substitutes.xml -前のことを思い出して アーキテクチャディレクトリとschema.xsdファイルの作成 節では、基本ISO 19115/19139モードを拡張するための方法は、拡張基本タイプを使用して、拡張された基本タイプを使用して新しい要素を定義し、新しい要素が基本要素を置換することを可能にすることであることを指摘する。したがって、例えば、MCPでは、知識共有および他の共有タイプの許可情報を含む新しいリソース制約要素を追加することが望ましい。これは、MD_CONSTRAINTSタイプを拡張し、gmd：md_constraintsの代わりにmcp：md_commons要素を定義する必要がある。以下のXSDコード片はこれを示している.

<xs:complexType name="MD_CommonsConstraints_Type">
  <xs:annotation>
    <xs:documentation>
      Add MD_Commons as an extension of gmd:MD_Constraints_Type
    </xs:documentation>
  </xs:annotation>
  <xs:complexContent>
    <xs:extension base="gmd:MD_Constraints_Type">
      <xs:sequence minOccurs="0">
        <xs:element name="jurisdictionLink" type="gmd:URL_PropertyType" minOccurs="1"/>
        <xs:element name="licenseLink" type="gmd:URL_PropertyType" minOccurs="1"/>
        <xs:element name="imageLink" type="gmd:URL_PropertyType" minOccurs="1"/>
        <xs:element name="licenseName" type="gco:CharacterString_PropertyType" minOccurs="1"/>
        <xs:element name="attributionConstraints" type="gco:CharacterString_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element name="derivativeConstraints" type="gco:CharacterString_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element name="commercialUseConstraints" type="gco:CharacterString_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element name="collectiveWorksConstraints" type="gco:CharacterString_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element name="otherConstraints" type="gco:CharacterString_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute ref="mcp:commonsType" use="required"/>
      <xs:attribute ref="gco:isoType" use="required" fixed="gmd:MD_Constraints"/>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

<xs:element name="MD_Commons" substitutionGroup="gmd:MD_Constraints" type="mcp:MD_CommonsConstraints_Type"/>

MCPレコードに対して，メタデータ文書に‘Resource Constraints’を追加すると，GeoNetworkエディタはGMD：MD_CONSTRAINTS置換グループ中の要素オプションを表示する.Mcp：md_commonsが含まれます。

../_images/Editor-Constraints-Choices.png

同様のプロセスによって、MD_CONSTRAINTSの代替として、他の2つの要素(現在、MD_COMMONSをサポートするために使用されることが放棄されている)も追加されていることに留意されたい。使用が推奨されていない要素を削除し、オプションをLegal、Security、Commonsに制限するなど、このメニューに表示されているオプションを制約する必要がある場合には、schema-substitutes.xmlファイル中の以下のXMLによって実現することができる。

<field name="gmd:MD_Constraints">
  <substitute name="gmd:MD_LegalConstraints"/>
  <substitute name="gmd:MD_SecurityConstraints"/>
  <substitute name="mcp:MD_Commons"/>
</field>

この変更の結果を以下に示す.

../_images/Editor-Constraints-Choices-Modified.png

同様に，MCPのためにschema-substitues.xmlファイルを構築する際の良い起点は，iso 19139パターンのschema-substitues.xmlファイルである.

メタデータレコードの他のアーキテクチャへの変換をサポートするためのコンポーネントを追加する

変換ディレクトリの作成

新しいGeoNetworkプラグインモードがメタデータレコードを即時に他のモードに変換することをサポートしていれば，変換ディレクトリを作成して適切なXSLTを埋め込むべきである.

OAIPMH変換のサポート

GeoNetworkにおけるOAIPMHサーバは，GeoNetworkで知られている任意のパターンからメタデータ記録を転送することができる.メタデータレコードをこのパターンに変換するXSLTが存在すれば，GeoNetworkが未知のパターンを提供するように配置することも可能である.ファイル.ファイル INSTALL_DIR/web/geonetwork/WEB-INF/config-oai-prefixes.xml XSLTから生成可能なパターン(OAIではプレフィックスと呼ぶ)を記述する.このファイルの内容の簡単な例を以下に示す。

<schemas>
  <schema prefix="oai_dc" nsUrl="http://www.openarchives.org/OAI/2.0/"
          schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc.xsd"/>
</schemas>

上に表示されたプレフィックスOAI_DCの場合、プレフィックスを有するモード変換器 oai_dc 存在しています schema-conversions.xml ファイルは、このシナリオに属するレコードが変換され、OAIPMH要求に含まれる。 oai_dc 接頭辞。参照してください Schema-Conversions.xmlファイルの作成 もっと情報があります。

MCPに対するOAI_DCサポートを追加するためには、最も簡単な方法は、iso 19139モードの変換ディレクトリからOAI_dc.xslをコピーし、異なる名前空間およびMCPの追加要素を処理するために修正し、追加することである。 schema-conversions.xml MCPのファイルです。