ISO23950による分散クリアリングハウスのための地理情報プロファイルインテック・ウェブ・アンド・ゲノム・インフォマティクス㈱技術部ADR 石田茂 2015/9/30 W&G 1 内容  はじめに  Z39.50とは  地理情報メタデータとZ39.50 -FGDCの取り組み‐  国内地理情報標準メタデータへのクリアリングハウス適用  まとめ 2015/9/30 W&G 2 背景  HW/SWの低価格化 →GIS導入の促進  インターネットの普及 →地理情報の流通促進  電子化されない地図データ  システム毎に異なるデータ仕様  類似データの重複整備 2015/9/30 W&G 3 GIS関係省庁の取り組み  現1府12省庁をメンバーとするGIS関係省庁連絡会議  地理情報のクリアリングハウス（情報所在案内）を平成11～13年度の前半に整備する（「国土空間データ基盤標準及び整備計画」（平成11年3月））  経済産業省、国土交通省、総務省の連携のもと、モデル地区で事業実施 2015/9/30 W&G 4 経済産業省の今年度調査事業  「平成12年度情報システム標準化推進事業（地理情報システム標準化等推進事業）」（（財）データベース振興センターへ委託）  地理情報メタデータを対象とするクリアリング調査委員会設立  ISO23950、FGDC GEO Profile国内仕様の検討、ならびに実証実験 2015/9/30 W&G 5 Z39.50とは  ネットワークベースの情報検索プロトコル – OSI参照モデル第７層 - ASN.1、BER – サーバ/クライアント型  ANSI/NISO Z39.50-1995 (ISO 23950:1998) – NISO - National Information Standards Organization – ISO - International Standards Organization  米国議会図書館にMaintenance Agency設置 – Ray Denenberg がまとめ役 2015/9/30 W&G 6 ZIG - Z39.50 Implementors Group  Z39.50システムの開発者グループ  改正、修正、問題認識ならびに提起等を議論  実装者合意を作成  ５ヶ月に一度の会合（北米、EU、ワシントンDC）  コンセンサス主導の作業方針 2015/9/30 W&G 7 開発経緯  1978-82 – 初期の開発/調査研究  1982-83 – Linked Systems Project Protocol  1983-84 – ANSI Z39に提出.Z39.50-1984.承認投票に失敗  1984-87 – 開発継続  1988 – NISOに再提出。Z39.50-1988として承認  1979-89 – Z39 SC D 2015/9/30 W&G 8 開発経緯  1984-91 – ISO SR → ISO 10162/10163 Search & Retrieve (1993)  1990 – ZIG（実装者グループ）設立  1989-90 – Z39.50 Maintenance Agency設立  1992 – Z39.50-1992 (version 2)  1990-95 – version 3開発  1995 – Z39.50-1995  1998 – ISO 23950 2015/9/30 W&G 9 目的  クライアント・サーバシステム間で情報検索の相互連携性を確保する – ベンダー間の相互連携 • 様々なDBとユーザIF – 組織間の相互連携 • 様々な図書フォーマット – ユーザグループ間の相互連携 • 公共図書館と大学図書館 • 様々なコミュニティにおける図書館 – コミュニティ間の相互連携 • 図書館、出版社、 DBサービス、美術・博物館等 2015/9/30 W&G 10 どのように使用するか？  抽象化DB – 標準化されたアクセスポイント • 属性集合 – 標準化された検索式 – 標準化された返戻形式 • スキーマ • 選択可能なレコード構文 • 返戻時にレコードの選択が可能 – レコード内容に左右されない検索処理 2015/9/30 W&G 11 どのように使用するか？  抽象化されたDBは、実際のDBのフロントエンドとして実装される。 Z39.50クライアントアプリ機能 2015/9/30 Z39.50サーバ Z39.50 クライアント Z39.50 サーバ W&G DB 12 補足機能  走査  永続的検索結果集合  定期的検索実行  蔵書注文  DB更新  仕様導出、発動 2015/9/30 W&G 13 相互連携にみる特徴  DB毎に異なる機能 – アクセスポイント等の属性集合、実装特徴  DB毎に異なる情報形式 – US MARC, UNIMARC, SUTRS, GRS-1 – 所蔵情報の内包、分離 2015/9/30 W&G 14 Profile  標準仕様の使用方法に関する合意規定 – – – – – – 2015/9/30 どのアクセスポイントが有効？どの属性が有効？レコード構文には何が指定できる？どの（補足）機能が一般に利用できる？どのオプションが利用できる？特定分野向けのデータは許容される？ W&G 15 Profile例  ATS-1 – Author, Title, Subject – 初期の図書向け簡易仕様 (廃止）  GILS – 行政情報所在案内サービス – 汎用的な情報所在案内サービスの参照モデル 2015/9/30 W&G 16 Profile例  CIMI – 美術館情報をコンピュータ上で交換するためのコンソーシアムが作成 – テキスト以外に画像情報も検索対象とする  CIP – Catalogue Interoperability Protocol – 国際的な地球観測衛星委員会が作成 – 地理空間情報の検索にも利用される 2015/9/30 W&G 17 Profile例  GEO – 地理空間情報を対象  STAS – 科学工学向け属性集合を規定 – 正確にはProfileではない 2015/9/30 W&G 18 Z39.50の難点  複雑なプロトコル  難解な用語  元はISO/OSI規格に準拠 – TCP/IP上で実装 – 難解な理論ベースのプロトコル – 様々な抽象化レベル 2015/9/30 W&G 19 Z39.50の難点  機能的に収斂した製品が未だ無い – 今後、MozillaのRDF実装が該当？  適切な専門化が極少数  製品の長期的なサイクルを考慮  標準化の前に仕様上の十分な探索がされていない  広く普及させることで困難な問題点を解決！ 2015/9/30 W&G 20 実装と連携の現実  Z39.50は幾つかのレベルで相互連携を許容する、情報検索の複雑な標準仕様である。  真の相互連携システムの実現には、多くの知識と実証作業が必要となる。 2015/9/30 W&G 21 Z39.50の適用方法  サーバ（Target）  ゲートウェイ  クライアント（Origin） 2015/9/30 W&G 22 サーバ（Target）  抽象化DBを実装 Z39.50サーバ  特殊な開発作業  ツールキットのカスタマイズ  サーバモジュールの準備  DBコンフィグレーション Z39.50 サーバ DB – 実際のDBを抽象化DBとしてどのように表現するか？ 2015/9/30 W&G 23 ゲートウェイ  IFに二つの顔を持つ  Z39.50サーバに対して、Z39.50クライアントとして通信する顔  一般的なクライアントと通信する顔 – クライアントプロトコルにはHTML, Telnet, Z39.50… 2015/9/30 W&G 24 Webゲートウェイ Z39.50サーバ Webブラウザ HTTP サーバ 2015/9/30 ビジネス Z39.50 ロジッククライアント W&G 25 横断的ゲートウェイ Z39.50サーバ Z39.50 クライアント Z39.50クライアント Z39.50サーバ Z39.50 サーバビジネス Z39.50 ロジッククライアント Z39.50 クライアント 2015/9/30 W&G Z39.50サーバ 26 高度なゲートウェイ  複数のZ39.50サーバと接続する – 並列検索 – 連続検索 – 検索結果のマージ  両方のIFに様々なプロトコルに対応する – SQL, LDAP, HTML, DNS… 2015/9/30 W&G 27 高度なゲートウェイ Z39.50サーバ Z39.50クライアント Z39.50 サーバ Z39.50 クライアント Webブラウザ SQLサーバ HTTP サーバ専用システム 2015/9/30 ビジネス SQL ロジッククライアント専用プロトコルサーバ LDAP クライアント W&G LDAPサーバ 28 クライアント（Origin）  グラフィカルなユーザIFのプロトコル処理部 – ユーザから複雑さは隠されている – 拡張コンフィグレーションの必要性 – 同時に複数のサーバに接続する場合あり Z39.50クライアントアプリ機能 Z39.50 クライアント 2015/9/30 W&G 29 市場動向  統合システム – 図書館システム • 海外の主要なシステムは全てZ39.50機能をもつ • 専用クライアントあるいはWebゲートウェイ • 小規模システムにもZ39.50を採用するものあり • 多くのシステムはVersion 2 を採用する – INNOPAC等の米国製システムに多い 2015/9/30 W&G 30 市場動向  スタンドアロン製品  ツールキットレベル製品  システムインテグレーション・コンサルタント – – – – – – 2015/9/30 Crossnet (UK) Fretwell-Downing (UK) Indexdata (Denmark) Sunstone (Sweden) Blueangel Technologies (US) Finsiel (Italy) W&G 31 市場動向（国内）メーカ/ 主な機能サービスベンダー NACSIS-ELS/ NII 国立情報学研究所 INNOPAC/ Innovative Interface Inc. 日本IBM LibCruiser Pro/ NTT東日本 Server Web G/W ○ (NII内) ○ (NII内) ○ ○ ○ ○ ○ ○ Gateway-CAT/ 丸善 Proxy ○ ○ ○ (丸善経由) (丸善内) JOIS with STN/ JST 科学技術振興事業団 ○ (JST内) ○ (JST内) ○ InfoLib-Global Finder/ 日商岩井インフォコム ○ ○ SiteSearch/ OCLC, 紀伊国屋 ○ ○ ERL/ Silver Platter, 紀伊国屋 ○ ○ Ovid/ Ovid Technologies Inc, ユサコ ○ ○ 2015/9/30 Telnet G/W 日本語 ○ 検索エンジン外部連携採用機関大学系図書館（多数）早稲田大学東京工業大学、図書館情報大学、神戸大学 OpenText RLG Zephyer Server ○ 大学系図書館（多数） CAS Server ○ ○ OpenText ○ W&G 32 Z39.50はどのように機能するか? 2015/9/30 W&G 33 初期化機能  初期化サービス – Z-アソシエーションの確立クライアント初期化要求サーバ Version、ID/パスワード、オプション、メッセージサイズ、実装情報初期化応答結果、Version、オプション、メッセージサイズ、実装情報 2015/9/30 W&G 34 初期化機能 – 使用可能なサービスとオプションを交渉する • クライアントは“初期化要求”内のリストで様々なサービスを要求する • サーバは自身の機能・能力と比較調整し、可能なサービスならびにオプションを初期化応答でクライアントに返す 2015/9/30 W&G 35 検索機能  検索サービスクライアント検索要求検索式タイプ、検索式、DB, 結果集合名サーバ検索応答ヒット件数、返戻レコード件数、ステータス情報、（レコード） 2015/9/30 W&G 36 返戻機能  返戻サービスクライアント返戻要求レコード件数、開始順位、結果集合名サーバ返戻応答レコード件数、ステータス、（レコード） 2015/9/30 W&G 37 返戻機能  セグメントサービス – レコードを“セグメント”することで、初期化時に設定したメッセージサイズよりも大きいレコードを転送することができる – 二つのレベル • Level 1: 一つのセグメントに複数のレコードを格納 • Level 2: 一つのレコードを細分化して各セグメントに格納 2015/9/30 W&G 38 検索結果集合削除機能  削除サービスクライアントサーバ削除要求結果集合リスト削除応答ステータス 2015/9/30 W&G 39 アクセス制御機能  アクセス制御サービスクライアントサーバ要求（一般）アクセス制御要求セキュリティ申請アクセス制御応答セキュリティ申請応答応答（一般） 2015/9/30 W&G 40 課金・リソース制御機能  リソース制御サービス  トリガリソース制御サービス  リソース報告サービス – リソースの使用を制御、報告する複雑な機能 – 主に課金情報を作成するために使用される 2015/9/30 W&G 41 ソート機能  ソートサービスクライアントソート要求ソート対象の結果集合、ソート済結果集合、ソート方式サーバソート応答ステータス 2015/9/30 W&G 42 走査機能  走査サービスクライアントサーバ走査要求 DB、単語リスト、開始位置、単語数、(ステップサイズ) 走査応答ステータス、単語数、(単語) 2015/9/30 W&G 43 拡張サービス機能  拡張サービス – – – – – – 永続的検索結果集合永続的検索式定期的検索実行蔵書注文 DB更新仕様導出、発動  タスクパッケージ – 拡張サービス要求を作成、修正、削除 2015/9/30 W&G 44 説明機能  説明サービス – サーバ情報のアクセス手段を提供する • • • • • 2015/9/30 DB アクセスポイント検索言語要素集合 ... W&G 45 終了処理  完了サービス – Z-アソシエーションを終了する 2015/9/30 W&G 46 属性集合  使用可能な、ドメイン固有の抽象化されたアクセスポイント  BIB-1  STAS 2015/9/30 W&G 47 転送プロトコル  TCP/IP （通常） – TCP予約ポート番号210  ISO OSI – 現在、殆ど使用されていない 2015/9/30 W&G 48 BER  基本符号化規則 – Basic Encoding Rules – 転送データの符号化方式 – 可読形式のコードではない • コンピュータのみ解釈可能 型  長さ 値 2015/9/30 W&G 49 ASN.1  抽象構文記法１ – Abstract Syntax Notation 1  データ型を定義する記述言語 – 実装方式とは独立した表現形式 Permissions ::= SEQUENCE OF SEQUENCE{ userId [1] IMPLICIT InternationalString, allowableFunctions [2] IMPLICIT SEQUENCE OF INTEGER{ delete (1), modifyContents (2), modifyPermissions (3), present (4), invoke 2015/9/30 W&G (5)}} 50 APDU  Application Protocol Data Unit – 要求と応答を含むデータパッケージ InitializeRequest ::= SEQUENCE{ referenceId protocolVersion options preferredMessageSize exceptionalRecordSize idAuthentication implementationId implementationName implementationVersion userInformationField otherInfo 2015/9/30 ReferenceId OPTIONAL, ProtocolVersion, Options, [5] IMPLICIT INTEGER, [6] IMPLICIT INTEGER, [7] ANY OPTIONAL, -- see note below [110] IMPLICIT InternationalString OPTIONAL, [111] IMPLICIT InternationalString OPTIONAL, [112] IMPLICIT InternationalString OPTIONAL, [11] EXTERNAL OPTIONAL, OtherInformation OPTIONAL} --Note: -- For idAuthentication, the type ANY is retained -- for compatibility with earlier versions. -- For interoperability, the following is recommended: -IdAuthentication [7] CHOICE{ -open VisibleString, -idPass SEQUENCE { -groupId [0] IMPLICIT InternationalString OPTIONAL, -userId [1] IMPLICIT InternationalString OPTIONAL, -password [2] IMPLICIT InternationalString OPTIONAL }, -anonymous NULL, -other EXTERNAL -- May use access control formats for 'other'. See Appendix 7 ACC. W&G 51 検索式  検索式タイプ – Type-0: 二者間の専用タイプ – Type-1: RPN (標準） – Type-2: ISO 8777 – Type-100: Z39.58 – Type-101: 拡張RPN (v 2) – Type 102: Ranked List query • 重み付け検索 • Relevance Feedback（関連検索） 2015/9/30 W&G 52 Type-1検索式  構成要素 – AND,OR,NOT論理演算子と連携した一つ以上のオペランド – オペランドは二項関係の再帰表現を構成する – オペランドは７つの要素から構成される 2015/9/30 W&G 53 Type-1オペランド  0. Term – 検索語  1.Use Attributes – アクセスポイント  2.Relation Attributes – 各アクセスポイントにおけるTermとデータの関係 – ＜、＝、接辞処理等 2015/9/30 W&G 54 Type-1オペランド  3.Position Attributes – Termのアクセスポイント中の位置 – フィールドの先頭、サブフィールドの先頭等  4.Structure Attributes – Termの扱い方 – フレーズ、単語、日付、正規化名称等 2015/9/30 W&G 55 Type-1オペランド  5.Truncation Attributes – 短絡形等の適用方法 – 左側短絡、左右短絡、短絡なし、正規表現  6.Completeness Attributes – Termが照合される対象 – サブフィールドの一部、サブフィールド全体、フィールド全体 2015/9/30 W&G 56 検索式の例 AND George Alec Effinger Islam 1:1003 1:1035 2:3 2:3 3:1 3:3 4:1 4:101 5:100 5:100 6:1 6:2 2015/9/30 W&G 57 検索結果集合  デフォルト結果集合  名前付き結果集合  永続的結果集合 2015/9/30 W&G 58 DBスキーマ  抽象化DBのレイアウトを定義  要素（返戻時の抽象化された項目） – 要素仕様 – 要素集合名 2015/9/30 W&G 59 タグ  要素または部分構造に一意にラベル付ける識別子 schemaIdentifier datatype: OBJECT IDENTIFIER 2015/9/30 W&G 60 タグ集合  特定のデータ構造のための識別子の集合 1.schemaIdentifier datatype: OBJECT IDENTIFIER 2.elementsOrdered datatype: BOOLEAN 3.elementOrdering datatype: INTEGER 4.defaultTagType datatype: INTEGER 2015/9/30 W&G 61 構成仕様  返戻したいデータ構造の一部分（あるいは全体）を指示する方法 2015/9/30 W&G 62 地理情報メタデータとZ39.50 ‐FGDCの取り組み‐  1994年の大統領令12906号国土空間データ基盤の整備と流通を規定  FGDCは地理情報メタデータの相互流通をクリアリングハウスにより促進させる →Z39.50 GEO Profile策定 2015/9/30 W&G 63 FGDCが支援するクリアリングハウスの活動  デジタル空間データの提供機関がインターネット上に独立にサーバを稼動させる →分散型クリアリングハウス  検索と返戻手順を共通化（ISO23950)  Webゲートウェイのユーザインタフェース  最小コスト、重複投資せずデジタル空間データを共同整備する→データ収集活動と研究活動の両面に貢献する 2015/9/30 W&G 64 参加が求められる機関  政府を基盤とした調整 – 州政府の組織が、州の機関、連邦政府機関、地方政府やその他の機関の間の調整努力を先導する。  地域コンソーシアム – （州の境界線内あるいは境界線を跨いで）地域に持続する関心を持つ機関が、共有データを開発するためのコンソーシアムを構成する。  特殊プロジェクト – 地理的地域に共通な関心を有する問題が存在する場合、ある期間がその問題に対処するための共有データ開発を目的とした提携関係を期間限定で構築することがある。 2015/9/30 W&G 65 活動の構成  クリアリングハウスの維持、更新のための戦略ならびに概念を改善する。  規格を草案化し、改訂し、承認する。  データの質を実証するための方針を策定する。  データ管理手順を確立する。  必要な技術開発を支援する。  クリアリングハウスについて参加者を教育する。 2015/9/30 W&G 66 国、州、地域レベルの取り組み  規格の推奨  資金援助やその他の資源の確認  提携の推奨  規格の導入  パイロットプロジェクトの開始  手順や技術の試験および実施  論争および対立の解決 2015/9/30 W&G 67 アクセス可能なデータ  デジタル空間データセット – 市販されるデータ製品の最小構成 – 各データセットに継承される汎用的なメタデータを含む →メタデータが独立した地理情報の特徴の下に保守されることが求められる。  米国ではメタデータの再利用OK 2015/9/30 W&G 68 クリアリングハウスの相互連携  FGDCはメタデータの蓄積、検索環境に分散連携形態を選択（高いスケーラビリティ）  FGDC方針に沿う商用ベンダー – Compusult http://www.fgdctoolkit.com/ – Blue Angel Technologies http://www.blueangeltech.com/ – Crossnet Systems http://roadrunner.crxnet.com/  北米に6つのWebゲートウェイ設置 – 各Webゲートウェイと複数のクリアリングハウスサーバが連携（横断検索・返戻） 2015/9/30 W&G 69 国内地理情報標準メタデータへのクリアリングハウス適用  FGDCは米国メタデータ標準仕様CSDGM – Z39.50 GEO Profile – 加州、欧州、豪州、南アフリカ等に導入  JIS X 0806（Z39.50):1999 (1999.1.20制定） – JIS X 0806準拠の地理情報クリアリングハウスの仕様採用の必要性の根拠（工業標準化法第67条） – 国及び都道府県、政令指定都市の国際標準規格に基づく調達規定（WTO政府調達協定第6条第2項）  今年度調査事業に向けて 2015/9/30 W&G 70 調査課題  国内向け地理情報プロファイル(GEO-J Profile)案の策定  策定されたGEO-J Profile案に基づき、モデル地区が保有     する地理情報メタデータの収集、編集、加工 Z39.50を採用したクリアリングハウスの構築モデル地区で収集されたメタデータのクリアリングハウスへの蓄積当該クリアリングハウスの実験的運用、成果の評価モデル地区の地方公共団体職員による、当該クリアリングハウスの実験的利用、成果の評価 2015/9/30 W&G 71 GEO-J Profile案  FGDC GEO Profile V2.2参考  国内地理情報標準との整合性確保  必要十分な仕様を検討 2015/9/30 W&G 72 検討課題  国内地理情報標準（ISO19115CD準拠）で策定されるメタデータ形式JMP1.1への配慮  JMP1.1を考慮した必要十分なメタデータ項目の構成  JMP1.1を考慮した必要十分な検索項目  JMP1.1を考慮した必要十分な返戻形式 2015/9/30 W&G 73 作成方針  メタデータ形式には国内標準に位置付けられる JMP1.1を採用する。  メタデータ内にメタデータのDTD（XML)の参照を記述する。  GEO Profileで定義される検索項目の内、必須とされるAnnex B.2の検索項目を尊重する。  ISO19115CD2 Annex Eで推奨される検索項目を検討する。  返戻形式XML,HTML,SUTRSはJMP1.1準拠とする。  国土交通省国土地理院のWebゲートウェイとの接続性を考慮する。 2015/9/30 W&G 74 国際的な地理情報メタデータ形式の現状  FGDC CSDGM – 公式リリース  ISO19115CD準拠 – ISに向けて作業中 2015/9/30 W&G 75 ISO19115CDの動向  CD Final Text – 2001年1月末までレビュー – DISに向けた作業  DIS成立後、FGDCはGEO Profileの改訂を検討  JMPについても国際的な相互連携を確保するために、改訂の検討が求められる。  GEO-J Profile案も改訂が必要になる。 2015/9/30 W&G 76 実証実験システム  GEO-J Profile案を適用するクリアリングハウスサーバ  GEO-J Profile案を適用するクリアリングハウスWebゲートウェイ 2015/9/30 W&G 77 クリアリングハウスサーバの機能要件  DB作成機能 – JMP1.1で規定されるXML形式メタデータを扱えること – DB作成条件の変更に柔軟に対応できること – 文字列型、数値型、日付型の検索機能を有すること – 項目別ならびに全文の検索機能を有すること  GEO-J Profile案に規定されるZ39.50機能に対応すること – Init,Search,Present,Closeの各機能に対応すること – 属性集合に対応すること – XML,HTML,SUTRSの各レコード構文に対応すること – B,S,F,Aの各要素集合名に対応すること – 複数DBの同時検索機能に対応すること  Shift-JIS,JIS,EUCの日本語文字コード系に対応すること  サーバ運用時の接続情報をロギングすること 2015/9/30 W&G 78 クリアリングハウス Webゲートウェイの機能要件  GEO-J Profile案に規定されるZ39.50機能に対応すること – Init,Search,Present,Closeの各機能に対応すること – 属性集合に対応すること – XML,HTML,SUTRSの各レコード構文に対応すること – B,S,F,Aの各要素集合名に対応すること – 複数DBの同時検索機能に対応すること  Shift-JIS,JIS,EUCの日本語文字コード系に対応すること  Webゲートウェイ運用時の接続情報をロギングすること 2015/9/30 W&G 79 機能・データ連携図システム管理実証実験システム新規構築分 Webブラウザクリアリングハウスサーバ稼動状況問い合わせ H TT P クリアリングハウスWeb ゲートウェイクリアリングハウスサーバ×2 Webサーバ内部リクエスト処理部 GISメタデータ検索部内部プロトコル Webサーバ Z39.50クライアント処理部日本語形態素解析辞書 Z 39 .5 0 Z39.50サーバ処理部データベース作成 GEO-J プロファイルクリアリングハウスサーバ登録、環境、認証DB Z39.50 GIS 検索履歴DB メタデータ検索DB ログDB 認証DB 2015/9/30 W&G ログDB GISメタデータ (GEO-J準拠) GIS画像データ環境DB 80 実証実験環境 Z39.50によるＧＩＳｸﾘｱﾘﾝｸﾞｼｽﾃﾑ構成図＜２サイトによるモデル地区実証実験＞モデル地区大分県豊中市臼杵市ﾌﾞﾗｳｻﾞﾌﾞﾗｳｻﾞ Z39.50サイト２ Z39.50サイト１ HTTP HTTP Webｻｰﾊﾞデータチェック HTTP Web-Z39.50GW インターネット Z39.50 ＤＢ投入 Z39.50 Z39.50ﾒﾀﾃﾞｰﾀｻｰﾊﾞ2 Z39.50ﾒﾀﾃﾞｰﾀｻｰﾊﾞ1 copy DB1 ＧＩＳクリアリングシステム XML HTML SUTRS GRS-1 ﾊｰﾄﾞｳｪｱ（新規） DB2 （富山）（東京）既存システム（検証用） XML HTML SUTRS GRS-1 ﾊｰﾄﾞｳｪｱ（既設 GISｸﾘｱﾘﾝｸﾞｼｽﾃﾑ copy or direct access ﾌﾞﾗｳｻﾞ 2015/9/30 W&G 81 データ格納件数 2015/9/30 地域名メタデータ格納件数画像データ件数大分県 62 18 臼杵市 92 72 豊中市 1958 848 W&G 82 サイト別DB構成 2015/9/30 地域名 DB名富山大分県 oita 臼杵市 usuki ○ 豊中市 toyonaka ○ 東京 ○ W&G 83 プロトコル機能別アクセス件数 2015/9/30 プロトコル機能件数 Z39.50 Search（検索）リクエスト 3,467 Z39.50 Scan（走査）リクエスト 2,380 Z39.50 Present（返戻）リクエスト 2,094 HTTPリクエスト（画像取得） 1,671 W&G 84 検索入力画面(1) 2015/9/30 W&G 85 検索入力画面(2) 2015/9/30 W&G 86 検索式入力 2015/9/30 W&G 87 検索結果一覧 2015/9/30 W&G 88 検索結果メタデータ 2015/9/30 W&G 89 索引語入力 2015/9/30 W&G 90 索引語走査結果一覧 2015/9/30 W&G 91 評価  システム側評価 – 分散環境下における処理効率と負荷変化 – GEO-J Profile案の属性集合レベルの検索機能の確認  ユーザ側評価 – 分散環境下を意識しない検索環境 – 3地区の地方公共団体職員への調査票に基づくアンケート調査、システム部門情報責任者を対象としたヒアリング調査 2015/9/30 W&G 92 システム側評価  DB作成時間はメタデータ件数との比例よりも大きく推移した。転置インデックスのソート・マージ処理の負担が影響と考えられる。  クリアリングハウスサーバ・Webゲートウェイの応答特性は同時接続数に概ね比例に推移した。稼働環境はPCUNIXで、サーバプロセスは接続要求に応じてforkされる。  検索式の入れ子の段数と処理時間には明確な相関は見出せていない。メタで－多数が約2,000件程度と比較的少数であったためと思われる。  Webゲートウェイの応答は、背後に接続するサーバとのネットワーク的な距離の増大に伴い、サーバの処理特性が見かけ上小さくなっていく。 2015/9/30 W&G 93 ユーザ側評価  クリアリングハウスの有効性 – 有効性は肯定的でも積極的な利用は無い。啓蒙活動により積極的な利用を図る。  運用形態 – 運用コストやメタデータの修正・更新が困難。空間データの庁内流通や作成コスト削減、運用コストの準備とクリアリングハウス構築支援策を講じる。  ユーザインタフェースへの不満 – 検索機能の説明が不十分であり、検索結果の表示も工夫が足りない。タグを日本語表記し、表形式で表示する等他、メタデータ内容を説明する機能が必要。 2015/9/30 W&G 94 ユーザ側評価  ユーザインタフェースの改良 – 使いやすいユーザインタフェースであれば利用頻度が拡大する可能性あり。各種オンラインヘルプ機能が必要。  メタデータのメンテナンス用ツール整備 – 容易にメタデータの登録、修正及び更新が可能なメンテナンス用ツールの整備が必要。  クリアリングハウス整備の推進と運用整備 – 行政の連続性を踏まえ、特に県下市町村が所有する空間データ流通が必要であることから、広く地方公共団体のクリアリングハウスの推進を図ることでデータの流通性を確保し、自治体独自で運用可能な支援が必要。 2015/9/30 W&G 95 ユーザ側評価  GISポータルサイト – 民間データを含め広範囲なデータの収集とGISポータルサイトとなる情報やリンクを整備。  サムネイル表示 – 検索結果に日本語表記やサムネイルの表示など一層の利便性を高める。 2015/9/30 W&G 96 まとめ  クリアリング調査事業の実施 – – – – – Z39.50 GEO Profileの国内向け仕様の在り方の検討 GEO-J Profile案作成メタデータ・画像データの収集・分析実証実験システムの構築運用・評価  使いやすいユーザインタフェースであること 2015/9/30 W&G 97 まとめ  行政の専門家中心の利用から、一般職員や民間向けの有用な業務ツールとして位置付けられる。  他地方公共団体の空間データの検索ニーズが3 割を超えるなど、クリアリングハウス整備のニーズは高い。 – 本格的な横断型クリアリングハウスの早急な整備が必要。 2015/9/30 W&G 98 まとめ  地理情報クリアリングハウスへのZ39.50の採用が政府全体の方針となる。 – 「経済構造の変革と創造のための行動計画（第3回フォローアップ）-新たな経済成長に向けての新行動計画-」（平成12年12月1日閣議決定） 2015/9/30 W&G 99 クリアリング調査委員会  GIS関係省庁、専門家、大学、各企業からなるクリアリング調査委員会を（財）データベース振興センター内に設置。 2015/9/30 W&G 100 モデル地区と調査実施企業  大分県、臼杵市、豊中市  国際航業㈱  神鋼リサーチ㈱  ㈱NTTデータ  W&G㈱ 2015/9/30 W&G 101 質疑応答 2015/9/30 W&G 102