Comments
Description
Transcript
仕様書 「文字情報基盤データベースの構築」
仕様書 「文字情報基盤データベースの構築」 仕様書目次 1. 概要.................................................. 1 2. 文字情報基盤データベース構築に係る要件 ................ 7 3. Web API 仕様 ........................................ 18 4. 簡易検索 UI .......................................... 23 5. データ構造と構築 ..................................... 26 6. システム試験／システム検証 ........................... 28 7. 作業に係る要件 ....................................... 29 8. 保守要件 ............................................. 31 9. その他の留意事項 ..................................... 31 別 別紙 1 データ構成仕様 別紙 2 RDF データ項目仕様 別紙 3 共通基盤システム構成 紙 1. 概要 1.1. 背景 独立行政法人情報処理推進機構（以下「IPA」という。 ）は、IT 戦略本部による検討体制の下、 経済産業省とともに「文字情報基盤整備事業」を推進しており、その成果物として住民基本台帳ネ ットワークシステム統一文字と戸籍統一文字の全ての漢字を包含した約 6 万の漢字文字図形（以下 「MJ 文字図形」という。 ）を収容した文字フォント（IPAmj 明朝フォント、図 1 IPAmj 明朝フ ォント）及び文字に関する各種情報を収録した文字情報一覧表（MJ 文字情報一覧表）等を 2011 年 10 月から公開している1。 2012 年 7 月 4 日の高度情報通信ネットワーク社会推進本部決定「電子行政オープンデータ戦略 2」で、以下の基本原則が示された。 ① 政府自ら積極的に公共データを公開すること ② 機械判読可能な形式で公開すること ③ 営利目的、非営利目的を問わず活用促進すること ④ 取組可能な公共データから速やかに公開等の具体的な取組に着手し、成果を確実に蓄積して いくこと また、2013 年 6 月 14 日の閣議決定「世界最先端 IT 国家創造宣言3」では、そのⅢ.3.(1)節「利 便性の高い電子行政サービスの提供」に、「文字の標準化・共通化に関しては、今後整備する情報 システムにおいては、国際標準に適合した文字情報基盤を活用することを原則とする」との方針が 示された。 これらの決定を受け、IPA で整備した文字情報基盤に係る情報を、行政システムの構築や運用の ための活用、さらには民間からの活用を視野に入れ、「オープンデータ」にふさわしい、機械判読 可能で再利用性の高い形で提供することが急務となった。 IPAmj明朝フォントVer.002.02の符号化状況 戸籍統一（漢字のみ） (55,270文字) 住基統一(漢字のみ） （19,563文字) 非漢字 （2,014図形/1,684文字） 縦書用文字、リガチャを含む 文字情報基盤漢字 (58,814文字) 24,210文字 1,684文字 ISO/IEC 10646UCS BMP (全65,536文字） (Universal coded Character Set) 26,237文字 2,275文字 6,092文字 CJK統合漢字拡張B,C,D (全47,000文字) IVD 約3700文字 約500文字 拡張Eは、2014度中に 規格が発行される予定 CJK統合漢字拡張E (全5,768文字) IVS追加 (IVD登録) 現在は 符号化対象外 約1900 文字 CJK統合漢字拡張F (国際提案中) 2014度中にUCS(+IVS)で 扱うことができる予定 図 1 IPAmj 明朝フォント 1.2. 1 2 3 本事業の目的 本事業は、文字情報基盤で整備した文字に係る様々な情報（以下「文字情報」という。 ）を電子行 http://mojikiban.ipa.go.jp http://www.kantei.go.jp/jp/singi/it2/pdf/120704_siryou2.pdf http://www.kantei.go.jp/jp/singi/it2/kettei/pdf/20130614/siryou1.pdf 1 政オープンデータ戦略の趣旨に沿い、機械判読可能な形式で公開するためのデータベースを構築す ることを目的とする。 データベースは、IPA の運用する「共通基盤システム」(「2.3 共通基盤システムに係る要件」参 照）の上で稼働させることとし、ハードウェアの新規調達は行わない。 「文字情報」の例 ・文字のメタ情報 –文字コード（JIS 符号、ISO/IEC 10646 符号、住民基本台帳ネットワークシステム統一文字 コード、戸籍統一文字番号、その他） –漢字施策との関係（常用漢字、人名漢字等） –文字の構造を示す情報 –読み、画数、有名辞書の検字番号 ・文字と文字を多様な観点からリンク付け –字形の類似性 –字の起源、意味などの共通性・類似性 –大きさの異なる文字集合間での縮退対応への活用を目的とした関係性 （MJ 文字図形集合→文字図形集合→文字集合間での縮退対応への活用を目的とした関係性） 1.3. 本事業で実施する業務 IPA では、文字に係る各種情報を、行政機関、地方公共団体、民間企業、個人等に安定的・継続 的に公開するとともに、これら利用者から意見・質問等を収集するため、本事業によって構築され た文字情報基盤データベースを活用し、主として以下の業務を行うこととする。 ① 文字情報の管理業務 ・ 継続的に整備される文字情報の登録・維持管理 ② 文字情報の公開業務 ・ 利用者への Web API やダウンロード等を通じた文字情報の公開 ・ 公開システムの維持管理 ③ 利用者支援 ・ 文字情報の簡易検索 ・ 文字情報を利用するための Web API の公開 ④ 統計情報等の収集 ・ 文字情報の検索実績等に関する統計情報の収集 ・ 利用者からの意見等の収集 1.4. 用語の定義 本仕様書で使用する主要な用語の定義は以下のとおりとする。 No. 1 用語 文字図形 定義 ISO/IEC TR 15285“An operational model for characters and glyph”でいうところの“glyph”のこと。 一般には「字体」と呼ばれることがある。 2 包摂 JIS X 0213 において、複数の文字図形に対して同一の面区点位置を 与えること。 3 統合 ISO/IEC 10646 において、複数の文字図形に対して同一の符号位置 を与えること。 2 No. 用語 定義 4 RDF （Resource Description Framework） REST 情報の意味を明確にする表記法として World Wide Web Consortium 5 （W3C）で規格化された表現形式のこと。 Web API の実現方法の一つである。HTTP を利用して複数のソフト ウェア間での連携を実現する手法のこと。 簡易な XML と HTTP インタフェースの組合せにより Web サービス を実現することができる。SOAP のような標準規格の Web サービス ではなく、HTTP プロトコル規格の主要著者の一人である Roy Fielding が彼の博士論文で提唱した、World Wide Web のような公 開された情報を利用するためのアーキテクチャスタイルである。 6 SPARQL W3C にて標準化が行われている、RDF で記述されたデータを検 索・操作するためのクエリ言語のこと。 7 8 9 SPARQL エン SPARQL を利用したデータ操作機能をインターネット上で提供して ドポイント いる場所のこと。 Web API （Application Program Interface） サーバ等が提供するサービスをインターネット経由で利用できるイ IPA MJ 文字 MJ 文字情報一覧表に格納された情報を、Web ブラウザから簡易に 情報検索シス 検索し、閲覧できるシステムのこと。 http://mojikiban.ipa.go.jp/search/ テム（簡易 ンタフェースのこと。 版） 10 文字情報基盤 文字情報基盤整備事業で整備した成果物のこと。 IPAmj 明朝フォントや MJ 文字情報一覧表から構成される。 11 12 IPAmj 明朝フ 文字情報基盤整備事業で整備した TrueType ベースの OpenType フ ォント MJ 文字情報 ォーマットによるフォントのこと。 http://mojikiban.ipa.go.jp/1300.html 文字情報基盤整備事業で整備した文字情報の一覧表のこと。 一覧表 文字情報基盤漢字に付けられた固有名（MJ 文字図形名）、住基ネッ ト統一文字コード、戸籍統一文字番号、国際符号化文字集合、JIS コード等との対応関係、各種属性情報、主要な漢字字典を典拠とす る参考情報等が一覧表として記載されている。 http://mojikiban.ipa.go.jp/1311.html 13 共通基盤シス IPA が運営するシステムインフラで、仮想化技術等を利用し、サー テム バハードウェアの統合・運用の共通化等を実現したシステムであ る。 1.5. 参照すべき資料 本事業の提示を行うに当たって参照すべき資料については以下の URL を参照のこと。 ① 閣議決定「世界最先端 IT 国家創造宣言」 http://www.kantei.go.jp/jp/singi/it2/kettei/pdf/20130614/siryou1.pdf 3 ② 電子行政推進に関する基本方針 http://www.kantei.go.jp/jp/singi/it2/pdf/110803_denshi.pdf ③ 電子行政オープンデータ戦略 http://www.kantei.go.jp/jp/singi/it2/denshigyousei.html ④ 経済産業省報道発表「行政機関向け文字情報基盤の公開について」 http://www.meti.go.jp/press/2011/10/20111026003/20111026003.html ⑤ 文字情報基盤整備事業の Web ページで公開している全資料（フォント、文字情報一覧 表、委員会資料、報告書、文字情報検索システム、概念設計書等） http://mojikiban.ipa.go.jp/ ⑥ 文字情報基盤構築に関する研究開発事業 調査報告書（平成 23 年 3 月） http://mojikiban.ipa.go.jp/2515.html ⑦ 総務省外字の実態調査に係る調査報告書等 http://www.soumu.go.jp/main_sosiki/jichi_gyousei/c-gyousei/lgcloud/02kiban07_03000021.html ⑧ 地域情報プラットフォーム http://www.applic.or.jp/2011/tech/ ⑨ 常用漢字表（平成 22 年内閣告示第 2 号） http://www.bunka.go.jp/kokugo_nihongo/kokujikunrei_h221130.html ⑩ 戸籍法施行規則（昭和 22 年 12 月 29 日司法省令第 94 号、最終改正：平成 25 年 1 月 25 日法務省令第 1 号） http://law.e-gov.go.jp/ より検索 ⑪ 法務省告示第五百八十二号「在留カード等に係る漢字氏名の表記等に関する告示」 http://www.immi-moj.go.jp/topics/pdf/honbun.pdf ⑫ 平成一六年一〇月一四日民一第二八四二号民事局長通達、誤字俗字・正字一覧表（平 成 22 年 11 月改正） ⑬ 平二年一〇月二〇日民二第五二〇二号通知別表、正字・俗字等対照表（平成 22 年 11 月改正） ⑭ 辞書（字書）類は以下の版数のものを使用すること 新大字典（講談社） ：普及版 大字源（角川書店） ：再版 大漢和辞典（大修館書店） ：修訂第二版 日本語漢字辞典（新潮社） ： 五刷 1.6. 作業内容 本事業で実施する作業内容を以下の表 1 に示す。 4 表 1 作業内容 No. 1 作業 内容 プロジェクト管理 プロジェクトを管理／実行する部門、また別に第三者の立場 で判断するプロジェクトの管理グループを体制の中に含める こと。 2 データの構造設計と整 「別紙 2 RDF データ項目仕様」に対し、運用を考慮したデ 備 ータ構造の検討を行い設計する。 設計したデータ構造に対し、現有データ及び 5.2 で指示す る作業により得られるデータを入れ込み整備する。 3 システムの設計と構築 上記 No.2 で設計／整備した文字情報データに以下の 3 機能 等を含めた文字情報基盤データベースが、IPA の共通基盤シ ステム上で効率的に動作するように、基本設計、詳細設計を 行い、システムを構築する。 ・WebAPI の整備 ・簡易検索 UI の整備 ・利用状況や要望等の収集／分析 4 システム試験 構築した文字情報基盤データベースに対し、共通基盤システ ムと同等な環境で、単体テスト、結合テスト、総合テスト、 システムテスト等必要なシステム試験を実施する。 5 システム検証 完成した文字情報基盤データベースに対し、利用者使用の観 点からシステム検証を行い、本システムの活用促進／利便性 向上に向けた報告書をまとめる。 1.7. スケジュール 本事業で実施する作業スケジュールは以下のとおりとする。なお、詳細については契約後に、IPA と協議して確定すること。 年度 月 6 7 8 9 2014年度 10 11 12 1 2 3 4 5 6 7 8 2015年度 9 10 11 1 2 3 仮運用期間 プロジェクト管理 データの構造設計と整備、システムの設計と構築 12 システム検証作業 システ ム試験 中間納入 1.8. 納入 IPA IPA 検収作業 検収作業 納入物件に係る要件 納入物件に係る要件を以下に示す。 (1) 納入物件 以下に示す納入物件は、記録媒体（CD-R、 DVD-R、 BD-R）等に格納して IPA に納入 すること。文書類のファイル形式は「7.3 作業及び作業環境等に係る要件」で記載した形 式とすること。計画書と報告書については、検収用に紙媒体１部も併せて提出すること。 5 ① 中間納入物 (a) プロジェクト管理（表 1 の 1 項参照）に係る物件 – プロジェクト計画書（7.2 作業管理に係る要件 参照）とその中間状況報告書 (b) データの構造設計と整備（表 1 の 2 項参照）に係る物件 – データ – データ構造設計書 – データ構築作業報告書 – データ検証報告書 (c) システムの設計と構築（表 1 の 3 項、4 項参照）に係る物件 – システム設計書 – システム試験計画書 試験の内容と方法、スケジュールが記載された計画書 ② 最終納入物 (a) プロジェクト管理（表 1 の 1 項参照）に係る物件 – プロジェクト計画書と結果報告書（共に最終版） (b) データの構造設計と整備（表 1 の 2 項参照）に係る物件 – データ（最終版） データそのものは納入する仮想マシンイメージの中にも含めること – データ構造設計書（最終版） – データ構築作業報告書（最終版） – データ検証報告書（最終版） (c) システムの設計と構築（表 1 の 3 項参照）に係る物件 – システム設計書（最終版） – 本事業で新規に開発したソフトウェアのソースコード – 本システムの動作と運用のために必要となる環境一式（OS、 DBMS、ミドル ウェア、言語処理系、ライブラリ、言語実行用 VM 等） （以後、このような、 本事業において新規に開発されたものを除くプロダクトで、納入物件が本仕 様の要件を満たす動作を継続するために不可欠なソフトウェア類を、 「件外プ ロダクト」という。 ） – 稼働する仮想マシンイメージ（共通基盤システム向け）データを含む – 運用手順書（管理者向け） – 利用説明書（WebAPI） – 操作説明書（簡易検索 UI 等） (d) システム試験（表 1 の 4 項参照）に係る物件 – システム試験結果報告書（試験仕様編、品質管理報告編も含む） 試験方法などが記載された試験仕様書と、それに基づき実施した試験の結果 報告書。 (e) システム検証（表 1 の 5 項参照）に係る物件 – システム検証報告書 完成したシステムに対し、利用者使用の観点から検証を行い本システムの活 用促進／利便性向上のための提言をまとめた報告書 (2) 納入期限 中間：2015 年 2 月 27 日（金） 6 最終：2016 年 2 月 29 日（月） (3) 納入場所 独立行政法人情報処理推進機構 技術本部国際標準推進センター企画グループ （東京都文京区本駒込 2-28-8 文京グリーンコートセンターオフィス 16 階） (4) 検収条件 納入物件については本仕様書に記載した要件の全てを満たしていること。 「別紙 2 RDF データ項目仕様」に示すデータ項目の検収条件は、以下で条件付けた割合 で判定する。基準に満たない場合には不合格とするが、その際に請負者へ通知する内容に ついては、全ての不適合箇所を指摘することはせず、一部の例を提示するのみとする。 中間納入：抜取り検査により、以下の条件が全て満たされていること。 データに不足（cardinality に不足がある等）のある項目の割合が 20%以内 データに誤り（誤った値が格納されている等）のある項目の割合が 10%以内 最終納入：抜取り検査により、以下の条件が全て満たされていること。 データに不足（cardinality に不足がある等）のある項目の割合が 10%以内 データに誤り（誤った値が格納されている等）のある項目の割合が 5%以内 2. 文字情報基盤データベース構築に係る要件 文字情報基盤データベースの構築の要件として、以下の内容を満たすこと。 ① 2.4 に示す利用イメージを考慮し、利用者の要求を十分に組み入れた設計とする。 ② データの電子的再利用性、並びに利用者が目的に応じた多様な情報を引き出せる、RDF に よるデータ記述とその検索用 WebAPI 及び簡易検索用 UI を備えること。 ③ IPA 職員によるデータベース運用管理及びデータの管理（更新、アクセス管理、バージョ ン管理等）を行うための機能を備えること。 ④ IPA の運用する共通基盤システム上で運用され、所要の性能を達成すること。 7 図 2 サービス関連図 2.1. 文字情報基盤データベースの概要 文字情報の公開に当たっては、 「電子行政オープンデータ戦略」（2012 年 7 月 4 日 高度情報通信 ネットワーク社会推進戦略本部決定）の方針に合致するように、利用者側の情報システムによる電 子的再利用が容易となる方式を追求する。 IPA が文字情報の公開元となり、利用者側が、公開される文字情報を活用、あるいは再公開する サーバを自主的に構築・運用できる、図 3 に示すような基本構成とする。 また、文字情報については、利用者による検索実績の統計情報の分析や文字情報の追加・修正要 求といった利用者からの要望が確認できる構成とする。 なお、図 3 は論理的概念図であり、具体的構成は今回の設計作業の中で具現化されるものとする。 8 図 3 想定するアーキテクチャ構成 図 3 において、マスタ DB に最新バージョンとして確定した文字情報データを登録・維持する IPA 内部向けサーバを「管理システム」 、管理システムが管理する文字情報データを外部へ公開する 公開元のサーバを「公開システム」とする。 公開システムは、文字情報の検索・取得のための API を備え、REST による文字情報や文字図形 の取得や SPARQL による柔軟な検索が利用者側が可能となる。SPARQL による検索を提供するた め、公開システムは SPARQL エンドポイントとしての役割を果たす。また、公開システムは、公開 システムが保持する文字情報データを、Web ブラウザを用いて容易に検索、閲覧するため簡易検索 サービス（以下「簡易検索 UI」という。）を提供する。簡易検索 UI は、現在 IPA が提供している 「IPA MJ 文字情報検索システム（1.4 用語の定義を参照）」に相当する機能を提供するものである。 2.2. 文字情報基盤データベースの機能等に関する要件 文字情報基盤データベースは、負荷分散とマスタ DB 保護のため、少なくとも管理システムと公 開システムに分割された 2 サーバ以上の構成とすること。 これらのサーバは IPA 共通基盤システム上の仮想マシンで動作する。 管理システムでは、 「維持管理システム」と「統計情報分析システム」の最低二つの機能が稼働す る。 公開システムでは、 「簡易検索 UI」と「WebAPI」 、 「問い合わせシステム」の最低三つの機能が稼 働する。今回の開発では、公開システムの並列化は行わないが、将来、負荷が増大した場合に備え、 公開に係る部分を容易に並列化できるよう、スケーラビリティに配慮した構成とすること。 9 (1) 管理システムに係る要件 管理システムは、外部ネットワークからはアクセス不可とし、IPA 内のネットワーク及び公開 システムとだけ通信できることとする。 ① 維持管理システム – 文字情報データ（マスタ）の検索、更新、追加、削除、バージョン管理を行うため、少なく とも以下の機能を備えること。 SPARQL UPDATE Web ブラウザによる簡易データインポート機能 (JSON/XML/CSV) – 文字情報データ（マスタ）の更新処理に対し、データ破損などの対策に向けた二重化/ロール バック機能などの仕組みを有すること。 ② 統計情報分析システム – WebAPI によって収集される文字情報データのアクセスログについて、定期的に分析処理を 行い、管理者向けに文字ごとのアクセス状況等のレポートを作成する機能を持つこと。 – 上記管理者向けレポートは Web ブラウザ向け画面表示用インタフェース及び印刷用フォー ム作成機能を備えること。 – 問い合わせシステムで入力される問い合わせ情報について、管理者向けに要望事項等を整理 し格納する機能と、それを検索し Web ブラウザで表示する機能、及び問い合わせ内容／件数 等を定期的・自動的にレポーティングする機能を備えること。 (2) 公開システムに係る要件 外部ネットワークと接続し各機能システムを利用者に提供する。 ① WebAPI（仕様詳細は「3.Web API 仕様」を参照のこと） – 文字情報データのコピーを保有する。 – SPARQL クエリ、REST のリクエストを受け付ける。 – リクエストに応じて文字情報データの検索を行い、結果を返す。 – 文字検索の傾向などの文字情報データへのアクセスログを採取する。 ② 簡易検索 UI（仕様詳細は「4.簡易検索 UI」を参照のこと） – 文字情報利用者に対して文字情報の簡易検索 UI を提供する。 – 簡易検索 UI は、上記①WebAPI を通して文字情報データへアクセスするインタフェースで あり、同 UI 向けに、文字情報に係る個別のデータベースを別途設けることがあってはなら ない。同 UI の検索のために必要となる全てのデータは、上記①WebAPI を通して得られる よう、システム及びデータを構成することが求められる。 ③ 問い合わせシステム – 利用者からの追加、更新、要望事項等を受け付ける、利用者向け UI を備えること。UI は簡 易検索 UI と一体化して構成される。 – 利用者からの問い合わせ情報は、WebAPI での文字情報データへのアクセスログと合わせて 管理システム側へ適宜コピーされ、統計情報分析システムで処理される。 2.3. 共通基盤システムに係る要件 (1) 共通基盤システムの稼働要件 10 「2.2 文字情報基盤データベースの機能等に関する要件」を満たす環境は IPA が運営する共通 基盤システムの仮想マシン上に構築し、稼働できること。仮想マシンの稼働要件を以下に示す（詳 細は別紙 3 を参照のこと） 。 仮想化基盤 ： VMware ESXi 5.0 update 3 仮想マシン（1 台当たり） ： CPU コア数 ： 1 / 2 / 4 （vCPU） （選択可能） メモリ ： 2 / 4 / 8 （GB） （選択可能） ディスク ： 基本 70GB(システム領域)、追加でデータ領域を 50GB 単位で増設可 ゲスト OS ： Windows Server 2008 R2 Standard（64bit） Red Hat Enterprise Linux 6.2（64bit） CentOS 6.2（64bit） (2) 仮想マシンイメージの作成要件 構築した文字情報基盤データベースは仮想マシンイメージとして納入すること。当該仮想マシ ンイメージには本システムが稼働するために必要なもの全て（OS、データベース、データベース 稼働に必要なミドルウェア等）及びデータを含むこと。 仮想マシンイメージは、次のいずれかの VMware 製品上で作成されること。 ・ VMware Workstation 5.x、6.x、7.x、及び 8.x ・ VMware Fusion 12.x、3.x、及び 4.x ・ VMware Player 2.x 及び 3.x ・ VMware Server 2.x 2.4. (1) 利用イメージ 文字情報を Linked Open Data（LOD）として利用する。 文字情報基盤データベースで提供している文字情報を、オープンデータとしてインターネット 上で公開する他の情報源のデータとリンクさせて利用する。 (2) 文字情報を画面で検索する。 利用者が、文字情報基盤データベースを直接検索することで、必要とする文字情報を表示／確 認できる。 (3) 利用のシステムから文字情報基盤データベースを利用できる。 利用のシステムから、WebAPI を通じて文字情報基盤データベースに登録されている文字情報 を、検索など絞り込みをした上でダウンロードして利用できる。 (4) 文字情報を一括取得して利用する。 文字情報の利用者が、文字情報を一括取得し、データベースのミラーサーバを構築運用するこ とを可能とする。取得した文字情報をそのまま利用する場合、あるいは利用者側で独自の文字情 報を付加するなどの加工を行った上で利用する場合も想定する。 (5) 文字情報基盤データベース及び文字情報に関するリクエストを受け取る。 文字情報基盤データベースの利用者からの、公開された文字情報の追加・修正などの文字情報 に関するリクエストを受け取ることができる。 2.5. 業務フロー 各業務について想定する業務フローを、以下に記載する。 なお、この業務フローは実施イメージの一例であり、フローの検証を行った上で IPA と協議し、 決定すること。 11 文字情報基盤データベースが提供するサービスに関わるアクターを表 2 アクター定義に示す。 表 2 アクター定義 項番 アクター 概要 1 文字情報利用者 文字情報基盤データベースの一般利用者。 2 文字情報利用シス 文字情報基盤データベースを利用するシステム。 テム 3 文字情報管理者 文字情報基盤データベースに登録する文字情報の維持管理を行う担当 者。 4 システム管理者 文字情報基盤データベースのシステム管理を行う担当者。 5 文字情報責任者 文字情報基盤データベースへの文字情報の登録、変更について責任を 持って承認行為を行う担当者又は組織。 6 公開システム 公開関連サービスを実現するための文字情報基盤データベースにおけ る概念的な活動単位。 7 維持管理システム 文字情報のマスタデータの維持管理及びシステム全体の維持管理を実 現するための文字情報基盤データベースにおける概念的な活動単位。 (1) 文字情報の管理業務 文字情報の管理業務では、文字情報基盤データベースに登録されている文字情報（各種属性情報、 フォント）のメンテナンス（登録・変更・削除）と検索を行う。 文字情報のメンテナンスと検索の業務フローを以下に示す。 ① 文字情報のメンテナンスと検索 A) 文字情報管理者は、文字情報のメンテナンスを行う。 文字情報管理者は、メンテナンスした文字情報を維持管理システムに仮登録する。 B) 維持管理システムでは、受け付けた情報を承認前の情報として文字情報データ（マスタ）に 仮登録する。 C) 文字情報管理者は、維持管理システムに仮登録した内容を文字情報責任者に申請する。 D) 文字情報責任者は、申請された内容を審査し、問題がなければ承認する。 E) 文字情報管理者は、申請の承認を受けた文字情報を正式に維持管理システムに反映する。 F) 維持管理システムでは、仮情報として登録されていた文字情報を正式な情報としてデータベ ースに登録する。 G) 文字情報管理者は、文字情報のバージョン更新を行う。この際に、情報の公開日時を指定す る。 H) 文字情報管理者は、維持管理システムに登録されている文字情報の検索を行う。 I) 維持管理システムは、文字情報データ（マスタ）に登録されている文字情報を取得して表示 する。 以上をまとめて図示（イメージ図）したものを図 4 に示す。 12 維持管理システム 文字情報管理者 文字情報責任者 (1)文字情報のメンテナンス(登録・変更・削除)と検索 B.文字情報 (仮) 登録・変更・削除 A.文字情報 登録・変更・削除 C.文字情報 (申請) 登録・変更・削除 F.文字情報 (正式) 登録・変更・削除 D.文字情報 (承認) 登録・変更・削除 E.文字情報 (反映) G.バージョン更新 I.文字情報 (表示) H.文字情報 (検索) 凡例 作業名 作業名 人が実施する作業 人がシステムを使って 実施する作業 作業名 システムが 実施する作業 開始点 終了点 処理の流れ 分岐/合流 図 4 文字情報の管理業務フロー (2) 文字情報の公開業務 文字情報の公開業務では、文字情報基盤データベースに登録されている文字情報を WebAPI でサー ビス利用者向けに公開する。 ① 文字情報の公開 文字情報を公開するときの業務フローを以下に示す。 A) 文字情報利用システムは、Web API を利用して文字情報の取得要求をする。 B) 公開システムでは、指定された条件に応じて文字情報を送信する。 C) 文字情報利用システムは、公開システムが送信した文字情報を受信する。 ② 文字情報の更新確認 文字情報利用システムが文字情報の更新確認を行い、更新情報を取得するときの業務フロー を以下に示す。 A) 文字情報利用システムから文字情報が更新されていないかどうかの問い合わせを行う。 13 この問い合わせには文字情報基盤データベースで提供する Web API を利用する。 B) 公開システムは、指定された条件に応じて文字情報の更新情報を取得する。 C) 文字情報利用システムは、文字情報の更新情報を受信する。 以上①~②をまとめて図示（イメージ図）したものを図 5 に示す。 文字情報利用システム 公開システム (1)文字情報の公開 B.文字情報取得 A.文字情報取得要求 C.文字情報受信 (2)文字情報の更新確認 A.文字情報 更新確認要求 B.文字情報更新確認 C.文字情報 更新確認受信 凡例 作業名 作業名 人が実施する作業 人がシステムを使って 実施する作業 作業名 システムが 実施する作業 開始点 終了点 処理の流れ 図 5 文字情報の公開業務フロー (3) 利用者意見、要望と検索実績の収集業務 サービス利用者からの文字情報基盤データベースへの意見、要望を収集する。 ① 利用者意見、要望の収集 文字情報利用者からの意見、要望を収集する業務フローを以下に示す。 14 分岐/合流 A) 文字情報利用者は、画面上で意見、要望を入力する。 B) 公開システムでは、意見、要望を受信し、問い合わせ情報データとして登録する。 ② 検索実績の収集 検索実績を収集し、統計情報を集計する業務フローを以下に示す。 A) 公開システムでは、検索実績をアクセスログとして収集する。 B) 公開システムでは、収集したアクセスログを基に統計処理を行い、統計情報を集計する。 以上①～②のフローをまとめて図示（イメージ図）したものを図 6 に示す。 文字情報利用者 公開システム (1)利用者意見・要望の収集 B.利用者意見・要望受付 A.利用者意見･要望 (2)検索実績の収集 A.検索実績収集 B.統計情報集計 凡例 作業名 作業名 人が実施する作業 人がシステムを使って 実施する作業 作業名 システムが 実施する作業 開始点 終了点 処理の流れ 分岐/合流 図 6 利用者意見、要望と検索実績の収集業務フロー (4) システム管理業務 システム管理業務では、文字情報基盤データベースで提供するサービスとは直接関係しない、本シ 15 ステムのメンテナンス作業を行う。 システム管理業務として実施する管理者権限管理の業務フローを示す。 ① 管理者権限管理 文字情報の管理業務を実施可能な文字情報管理者のアカウント管理を行う。業務フローを以 下に示す。 A) システム管理者は、文字情報管理者のアカウント管理操作を行う。 B) 管理システムでは、文字情報管理者の認証情報を登録する。 ② バックアップ取得 文字情報基盤データベースの文字情報データ（マスタ）のバックアップを取得する。 管理者権限管理のフローを図示（イメージ図）したものを図 ７ に示す。 管理システム システム管理者 (1)管理者権限管理 B.文字情報管理者 認証情報更新 A.文字情報管理者 追加・変更・削除 凡例 作業名 人が実施する作業 人がシステムを使って 実施する作業 図 ７ 2.6. (1) 作業名 作業名 システムが 実施する作業 開始点 終了点 処理の流れ 分岐/合流 管理者権限管理業務フロー システム機能に係る要件 システムとネットワーク構成の要件 文字情報の公開サービスで転送するデータサイズは、全件公開 1 回当たり数百 MB と想定す る。ただし、全件公開の実行頻度は低いため、定常的に数百 MB 規模のデータ転送が必要になる ことは考えない。 文字情報の検索サービスで転送するデータサイズは、1 回当たり数百 KB 程度と想定する。 今後、サービス利用者の増加に伴い、公開システムについてはサービストラフィックを制御す ることが可能なアーキテクチャを検討し、提示すること。 （トラフィックの流量制御やシステムの 分散化など） 16 (2) ソフトウェアの要件 文字情報基盤データベースを実装するためのソフトウェア要件を表 3 に示す。 表 3 ソフトウェア要件一覧 項番 要件 区分 1 RDF/XML 形式のデータを扱えること 必須 2 SPARQL 仕様4に準拠した処理が行えること 必須 3 Named Graphs5に対応していること 推奨 登録するデータ（トリプル）の数は 500 万件程度を想定し、本システムに係る性能面が問題とな らないようなソフトウェアを選定し、設計を行うこと。 OSS 製品を使用する場合、納品時点でサポートが終了している製品は、使用してはならない。 アプリケーションサーバ、RDF フレームワーク、DBMS は論理的に分離した構成とし、将来の 拡張性も考慮すること。 (3) 画面要件 ① 画面設計に当たっては、利用者の利便性、視認性を考慮した画面設計を行うこと。 ② 選択結果の確定や、機能・サービスの切替え等、直感的で容易に操作できる画面デザインと すること。 ③ 画面デザインは、パワーポイント等で作成し、IPA に提示し、承認を得ること。 ④ 一般利用者向け簡易検索UI及び問い合わせシステムUIについては、異なる種類の端末 （PC、タブレット等）からのアクセスを想定し、Webブラウザ依存性を極力少ないものと すること。 (4) システムの中立性要件 ① 特定のベンダに依存した構成を避け、可能な限りオープンな技術を採用してシステム構築す ること。本件納品後において、本件請負者以外の者でも本システムのメンテナンスを行える 構成とすることは必須である。 ② ハードウェア、ソフトウェアともに、可能な限り特定の製品に依存しないこと。 (5) セキュリティ要件 設計・開発前にセキュリティ対策をIPAに提示し、承認を得てから作業を行うこと。 ・本システムに含まれる件外プロダクトには納入時点での最新のセキュリティパッチを適用 し、納入後5年間はセキュリティパッチ等に適用可能であること。 ・セキュア・プログラミング講座に即した設計・開発であること。 ◇IPA セキュア・プログラミング講座 http://www.ipa.go.jp/security/awareness/vendor/programmingv2/index.html ◇IPA 安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html 4 5 http://www.w3.org/TR/sparql11-query/ http://www.w3.org/2004/03/trix/ 17 2.7. 規模性能要件 (1) 規模要件 利用者数 ・ 同時に 50 人以上が簡易検索 UI を操作できること。 ・ 同時に WebAPI を 50 以上並列処理できること。 (2) 性能要件 以下の性能要件を満たすこと。 ・ インターネットから簡易検索 UI へアクセスした利用者が、各種操作を行った際、ストレ スを感じないレベルの表示・応答性能を有すること。 ・ 公開システムにアクセスして、各種操作を行った際、ストレスを感じないレベルの操作性 能を有すること。 3. Web API 仕様 最低限提供しなければならない必須 WebAPI 項目一覧を表 4 に示す。 表 4 必須 Web API 項目一覧 項番 1 サービス 提供機能 種別 文字情報の検索 文字情報データに登録されている文字情報について SPARQ SPARQL クエリを用いた柔軟な検索を行い、検索結果 L を取得する。 2 文字情報の取得 文字情報データに登録されている文字情報の全部又は REST 一部を取得する。 3 MJ 文字図形の取得 文字情報データに登録されている MJ 文字図形イメー REST ジファイルを取得する。 4 文字情報の更新確認 文字情報データに登録されている文字情報の更新有無 REST を確認する。 以下、 各必須 WebAPI 項目に対する必須パラメータ項目とデフォルト値及び応答内容を提示する。 なお、必須パラメータに対するデフォルト値は、設定ファイル等により変更が可能となる機能を設 けること。 3.1. 必須 WebAPI 項目 (1) 文字情報の検索（SPARQL クエリ）機能 文字情報の検索（SPARQL クエリ）機能は、文字情報データに格納された RDF 形式のトリ プルを柔軟に検索できるようにするための機能である。 検索結果のフォーマットを指定できるものとする。 また、RDF ストアでは問い合わせ時点では、検索終了までの時間・検索結果のサイズについ 18 て、事前予測ができないため、次の二つの条件を指定することができるものとする。 ● 問い合わせの有効時間（検索処理が終了しない場合には、タイムアウトする。 ） ● 検索結果データの最大サイズ A) リクエスト URL（例） http://db.mojikiban.ipa.go.jp/sparql B) プロトコル/メソッド HTTP POST C) 事前指定パラメータ コネクションを張る時点で送出すべき情報を事前指定パラメータという。事前指定パラメ ータは、クエリ文本体、検索結果フォーマット及び問い合わせの有効時間を指定できるこ とを必須とする。必須パラメータ項目を表 5 に示す。 表 5 文字情報の検索（SPARQL クエリ）機能インタフェース必須パラメータ項目 項番 パラメータ項目名 1 SPARQL クエリ 説明 検索クエリのクエリ文を指定する。 例：query デフォルト値 ： なし 2 検索結果フォーマット 検索クエリの結果を以下の形式で指定する。 SPARQL Query Results XML Format (Second Edition) SPARQL 1.1 Query Results JSON Format SPARQL 1.1 Query Results CSV and TSV Formats RDF/XML TTL/TEXT デフォルト値 ： なし 3 タイムアウト時間 問い合わせの有効時間を指定する。 例：ttl デフォルト値 ： 1000msec 4 データサイズ 検索結果データの最大サイズを指定する。 例：size デフォルト値 ： 1MByte D) 応答内容 クエリ結果は、指定された検索結果フォーマットで返す。タイムアウト時間内に検索が終 了しなかった場合には、検索が終了しなかった旨の応答を返す。 (2) 文字情報の取得機能 文字情報の取得機能は、文字情報データに登録されている文字情報を一括的に取得するため の機能である。取得の範囲として、次の三つが指定可能な REST インタフェースを提供する。 ● 文字情報の全件取得 ● 文字情報の部分取得 ● 文字情報の差分取得 19 指定されたパラメータ条件に基づいて、文字情報データの文字情報を取得し、該当する MJ 文字図形名の結果として返す。 A) リクエスト URL（例） http://db.mojikiban.ipa.go.jp/get?[パラメータ] B) プロトコル/メソッド HTTP GET C) パラメータ 部分取得、差分取得を実現するための条件をパラメータで指定することができる。必須パ ラメータ項目を表 6 に示す。 表 6 文字情報の取得機能インタフェースの必須パラメータ項目 項番 パラメータ項目名 1 MJ 文字図形名 例：MJGlyphName 説明 部分取得を行う際に、対象とする MJ 文字図形名を指定す る。範囲指定を可能とする。 デフォルト値：全 MJ 文字図形名を指定できる値 2 基準日時 差分取得の基準とする日時を指定する。 例：date デフォルト値：2011 年 5 月 17 日（Ver.000.01 の公開前 日） 3 応答形式 例：filetype 取得する文字情報の応答データのファイルフォーマット形 式を指定する。なお、ファイルフォーマットは、RDF、 JSON から指定可能なものとする。 デフォルト値：RDF D) 応答内容 各パラメータ項目に合致する MJ 文字図形名の文字情報を取得し、パラメータ項目「応答 形式」で指定されるファイルフォーマット形式で応答する。 各パラメータ項目に対する値が指定されない場合は、デフォルト値を用いるものとする。 E) API 利用例 ● 応答形式 RDF で、全件取得を実行する場合 http://db.mojikiban.ipa.go.jp/get ● 応答形式 RDF で、MJ 文字図形名 MJ000001～MJ010000 の部分取得を実行する場合 http://db.mojikiban.ipa.go.jp/get?MJGlyphName =MJ000001-MJ010000 ● 応答形式 JSON で、基準日時 2012-01-01 以降の更新情報の差分取得を実行する場合 http://db.mojikiban.ipa.go.jp/get?date=1328022000000&filetype=JSON (3) MJ 文字図形の取得機能 MJ 文字図形の取得機能は、MJ 文字図形名に対応する文字図形のイメージファイル（画像 ファイル）を取得する機能である。次の条件を指定可能な REST インタフェースで提供す 20 る。 ● MJ 文字図形名（一つ又は範囲指定） ● イメージファイルのフォーマット（PNG、又は SVG） 条件に該当する MJ 文字図形のイメージファイルを、指定のフォーマットで結果として返す。 A) リクエスト URL（例） http://glyph.mojikiban.ipa.go.jp/[パラメータ] B) プロトコル/メソッド HTTP GET C) パラメータ MJ 文字図形名及びイメージファイルのフォーマットを指定するための条件をパラメータ で指定できるものとする。必須パラメータ項目を表 7 に示す。 表 7 MJ 文字図形の取得機能インタフェース必須パラメータ項目 項番 パラメータ項目名 1 MJ 文字図形名 例：MJGlyphName 説明 取得する MJ 文字図形イメージファイルの MJ 文字図形名 を指定する。範囲指定を可能とする。 デフォルト値：MJ000001 2 応答形式 例：format 取得する MJ 文字図形のイメージファイルのフォーマット を指定する。 イメージファイルのフォーマットには、PNG、SVG を指 定可能とする。 デフォルト値：PNG D) 応答内容 指定した MJ 文字図形名が一つとなる場合には、応答形式で指定されたフォーマットで、 複数の場合は、更にまとめて ZIP 圧縮を行ってイメージファイルを返す。 対応するイメージファイルのフォーマットが存在しない場合には、当該ファイルが存在し ない旨のメッセージを送出する。 各パラメータ項目に対する値が指定されない場合は、デフォルト値を用いるものとする。 E) ● ● API 利用例 ファイル形式 PNG で、MJ000001 の取得を実行する場合 http://glyph.mojikiban.ipa.go.jp/MJ000001?format=PNG フォーマット形式 SVG で、MJ000001～MJ010000 の取得を実行する場合 http://glyph.mojikiban.ipa.go.jp/MJ000001-MJ010000?format=SVG (4) 文字情報の更新確認機能 文字情報の更新確認機能は、文字情報データに登録されている文字情報が、基準日時以降に 更新されているか否かを確認するための機能である。次の条件を指定可能な REST インタフェ 21 ースを提供する。 ● 更新の有無を確認する基準日時 ● 対象とする MJ 文字図形名の範囲 指定された範囲の MJ 文字図形名について、基準日時以降の更新の有無を確認する。 A) リクエスト URL http://db.mojikiban.ipa.go.jp/checkupdate?[パラメータ] B) プロトコル/メソッド HTTP GET C) パラメータ 基準日時と対象となる MJ 文字図形名の範囲指定をパラメータで実現できるようにする。 必須パラメータ項目を表 8 に示す。 表 8 文字情報の更新確認機能インタフェースの必須パラメータ項目 項番 1 パラメータ項目名 説明 基準日時 更新有無を確認する基準となる日時を指定する。 例：date デフォルト値：2011 年 5 月 18 日（Ver.000.01 公開日） 2 MJ 文字図形名 例：MJGlyphName 部分確認を行う際に、対象とする MJ 文字図形名を指定す る。範囲指定を可能とする。 デフォルト値：全 MJ 文字図形名を指定できる値 D) 応答内容 更新があった MJ 文字図形名については「有」、更新がなかった MJ 文字図形名については 「無」を返す。 各パラメータ項目に対する値が指定されない場合は、デフォルト値を用いるものとする。 E) API 利用例 ● 全 MJ 文字図形名について、2012 年 1 月 1 日以降に更新されているか否かを確認す ● る。 http://db.mojikiban.ipa.go.jp/checkupdate?date=1328022000000 MJ000001～MJ001000 の範囲の MJ 文字図形名について、2012 年 1 月 1 日以降に更 新されているか否かを確認する。 http://db.mojikiban.ipa.go.jp/checkupdate?date=1328022000000&MJGlyphNam e=MJ000001-MJ001000 3.2. 留意事項 負荷の高い API 要求については、通信帯域を絞り、輻輳を防止する。 SPARQL クエリは、処理が長時間となる場合があり事前に推定できないため、管理システムを通 じ、トラフィック量の最大値とデフォルト値を設定可能とする。 その他パラメータのデフォルト値については、管理システムを通して管理者が任意に設定できる よう構成すること。 22 4. 簡易検索 UI 4.1. 基本構成 (1) 全体構成 簡易検索 UI は、利用者に対してはグラフィカルな UI を提供し、そこで入力された検索指示に より WebAPI を通じて文字情報データを検索し、得られた結果をグラフィカルに利用者へ提供す るインタフェースを実現するものである。 MVC（Model View Controller）モデルとして構成を捉えた場合、その全てを公開システムに 置くのではなく、ユーザの操作に係る V、C 部分は Java スクリプト等を活用することによって 極力利用者の PC 側（クライアントサイド）に置くことを原則とする。 サーバサイドとクライアントサイドは、JSON 又は XML により、データのみを送受信するこ ととする。 あわせて、 「問い合わせシステム」に係る UI を、一体化して構成すること。 (2) サーバサイド 必要機能 クライアントサイドへ、本システムの動作に必要となるスクリプト等を伝送する機能 クライアントサイドからの検索要求を、WebAPI を通じて文字情報データへ伝える機能 検索結果をクライアントサイトへ伝送する機能 留意点 データは、 「文字情報データ」（図 3 参照）及びそこから WebAPI で取得するもののみを 使用し、本簡易検索 UI 実現のために独自のデータベースを個別に構築し、使用してはな らない。検索において不足するデータがある場合、検索効率を上げるために別の構造のデ ータを必要とする場合等においては、文字情報データに当該データを追加構築するか、あ るいは文字情報データから自動的に検索データを生成するプログラムを構築し、併せて納 入するものとする。 (3) クライアントサイド 必要機能 HTML、CSS、JavaScript 等を用いた描画機能 利用者の検索操作を受け入れ、サーバサイドへ伝える機能 留意点 Adobe Flash 等、ベンダ依存性の高いソフトウェアは使用しないものとする。また、利用 者の Web ブラウザに対して新たなプラグイン等のインストールを求めるアプリケーショ ンは使用しないものとする。 4.2. ユーザインタフェース仕様 (1) 提供する検索方法 A) 基本検索 利用者が、画数、読み、部首等、表 9 に示す項目を指定した検索 B) コード検索 利用者が表 9 に示すような各種コードを指定した検索 C) 要素図形検索 利用者が MJ 文字図形に含まれる要素図形（別紙 2 （RDF データ項目仕様）項番 28）を指 23 定した検索 D) SPARQL クエリ検索 利用者が直接 SPARQL クエリを指定する検索 上記 A)～D)の検索方法を提供し、これらを組み合わせた AND 検索、OR 検索、NOT 検索、及びこ れらを順次適用する絞り込み検索を行えること。 検索に当たっては、ヒットした結果の数の表示、候補となっている文字図形の表示などを検索過程 において適宜ダイナミックに行い、検索の利便性向上を図ることが求められる。 表 9 検索パラメータ 検索法 検索対象とするデータ項目 （）内は別紙 2 （RDF データ項目仕様）の項番 基本検索 常用漢字（項番 10） 戸籍法上の人名漢字（項番 34） 音読み（項番 23） 訓読み（項番 24） 総画数（項番 25） 康煕部首・部首内画数（項番 26） JIS X 0213 水準（項番 30） コード検索 MJ 文字図形名 平成明朝グリフ名（項番 3） 戸籍統一文字番号（項番 4） 住基ネット統一コード（項番 6） 入管正字コード（項番 7） 登記統一文字番号（項番 9） 対応する JIS X 0213 面区点位置（項番 11） 対応する JIS X 0212 区点位置（項番 13） 対応する UCS（項番 14） 大漢和辞典 検字番号（項番 20） 日本語漢字辞典 検字番号（項番 19） 新大字典 検字番号（項番 21） 大字源 検字番号（項番 22） (2) 検索結果の表示 検索された結果として、文字図形イメージ、文字図形名、文字の基本的メタ情報を、現在 IPA が提供 している簡易検索サービスと同等の範囲の情報をデフォルトとして適切にフォーマッティングして表 示する機能を有すること。さらに、表示するメタ情報を利用者が追加指定できる手段を有すること。 (3) 簡易検索 UI の利用の流れ 利用者が、実際に簡易検索 UI を操作する際の遷移シーケンスを図 8 に示す。 ① 利用者は、基本検索、コード検索、要素図形検索又は SPARQL クエリ検索を選択し、Web ブ ラウザに表示される検索条件を入力する。 ② 簡易検索 UI は、検索条件に従って SPARQL クエリを生成し、検索結果のデータを利用者の Web ブラウザに返す。 ③ 利用者は、検索結果のデータから、各 MJ 文字図形名の文字情報の詳細を閲覧でき、さらに、 24 絞り込み検索の操作ができる。絞り込み検索を行った場合、①に戻る。 図 8 簡易検索 UI 機能遷移シーケンス 4.3. 各画面における要件 (1) 基本検索、コード検索に係る画面要件 康煕部首番号（別紙 2 RDF データ項目仕様の項番 26）による検索には、康煕部首を読みや 画数等によりソートするなど工夫し、利用者が康煕部首を字形で探して、選択できるペイン を設けること。 常用漢字（別紙 2 RDF データ項目仕様の項番 10）と戸籍法上の人名用漢字（同項番 34）、 JIS X 0213 水準（同項番 30）については、チェックボックス等により指定可能なものとし、 利用者が簡易に選択できるようにすること。 なお、このような便宜を図るための機能を、UI 側のプログラム上に作り込むことは極力避けるよ う配慮すること。 また、例えば JIS 水準のチェックボックスを表示する処理においては、まず文字情報データに当 たって、どのような「水準」が文字情報データ上に記録されているかを確認した上で、その結果に 従ってダイナミックにチェックボックスを作り出す、というように、文字情報データを「主」とす る設計とすることが求められる。 (2) 要素図形検索に係る画面要件 読み、画数、康熙部首番号により要素図形を検索できるペインを設けること。 25 検索に用いる要素図形を字形で選択できるペインを設けること。 各要素間の AND・OR 条件を視覚的に選択できること。 (3) SPARQL クエリ検索画面要件 SPARQL クエリには、利用者がテキストを直接入力する形式として、テキストエリアなど編 集しやすい画面を設けること。 利用者が入力する SPARQL クエリについて、バリデーションを実施し、Web ブラウザ画面 上で、シンタックスエラーがある場合は、エラーをハイライトすること。 4.4. 問い合わせシステム 利用者が、IPA に対して質問等を入力するための UI を備える。同 UI には簡易検索画面の入口 画面に設けられたリンクから誘導される。 問い合わせシステム UI には、質問等の任意テキストを入力できる入力窓を設けるとともに、後 に IPA から回答等を行う際に利用するため、利用者が任意でメールアドレス等を入力できる入力窓 を設ける。 任意書き込み欄については、管理システムにおける情報整理を容易にするため、書き込み内容に ついて、 「質問」 「意見」 「苦情」 「感想」など、簡単な分類をチェックボックスなどにより利用者が 簡易に指定できるインタフェースを設ける。 メールアドレスの入力窓においては、個人情報の利用条件について適切な表示を行うとともに、 そこへの同意を求めるインタフェースを設けるものとする。 ここで入力された情報は管理システムへ送信され（図 3） 、IPA 担当者の閲覧に供するものとす る。 5. データ構造と構築 5.1. 内部データ構造 文字情報データは、別紙 2 （RDF データ項目仕様）に示す項目について、その項目名と値とを 保持するものとする。なお、本仕様書（別紙などを含む）で示した RDF データ項目仕様は、本デー タベースが、データとしてどのような内容を備えるかを示したものであり、実際の物理的／論理的 構造を示したものではない。実際の構造は、処理効率を十分配慮して設計することが求められる。 例えば、 「値」が等しく、かつ、その本質的意味が等価であるようなデータが複数ある場合には、そ れらを物理的には一つの実体として記録して参照するように構成する等の工夫が求められる。 別紙 2 （RDF データ項目仕様）の欄名の説明は以下のとおりである。 ① 項番 項目の番号を示す（この番号は仕様書の理解を助けるためのものであり、実際に構築されるデ ータベースに、このとおりの番号を持たせる必要はない）。 ② 主語（Subject） ③ Subject に対応するデータのデータ形式 アプリケーションが RDF トリプルの主語を処理して取り出せる必要がある値のデータ形式。 主語のノードタイプ（URI、リテラル、空白ノード等）や RDF グラフの具体的構造を指定する ものではない。 ④ 述語（Predicate） ⑤ Cardinality 一つの Subject に対し、 当該項目の値の取り得る数を示したものであり、RDF 表現においては、 26 弧の本数に対応する。 ⑥ Object に対応するデータのデータ形式 アプリケーションが RDF トリプルの目的語を処理して取り出せる必要がある値のデータ形式。 目的語のノードタイプ（URI、リテラル、空白ノード等）や RDF グラフの具体的構造を指定す るものではない。 ⑦ 公開 データベースとして保持している情報に対し、検索等の結果として一般向けに公開するかしな いかを指定するフラグであり、当該トリプルに付随させて記録されるものとする。ここに「非 公開」とマークされた情報については、管理システム上のデータには格納されるが、公開シス テム上へは移行しない。別紙２の「公開」欄には、そのフラグの納品時の初期値を示してある。 ⑧ 備考 Object の出所についての説明、又は補足となる情報を示した。 5.2. データの構築 別紙 2 RDF データ項目仕様の各項目について、表中の備考欄に「参照先」が示してあるものに ついては、その情報を基に RDF 構造へ収容する。 （以下、「Object 値とする」の意味は、Object が リテラルである場合にはその値、リンクである場合には参照先の値とする、の意味である。） それ以外については、以下の方式によりデータを構築するものとする。 ① JIS X 0213 に追加された時期（項番 31） JIS X 0213「7 ビット及び 8 ビットの 2 バイト情報交換用符号化拡張漢字集合」において、面 区点位置を Subject とし当該符号位置が JIS 規格書に追加された西暦年を Object 値とする。 データは別途供与する。 ② JIS X 0213 の例示図形が変更された時期（項番 32） JIS X 0213「7 ビット及び 8 ビットの 2 バイト情報交換用符号化拡張漢字集合」において、面 区点位置を Subject とし、当該符号位置の例示字形が変更された西暦年を Object 値とする。デ ータは別途供与する。 ③ 人名/同一字種（項番 35） 戸籍法施行規則（1.5 参照すべき資料 ⑩参照）別表第二の一に同定6できるものとして見出さ れた MJ 文字図形名を Subject とし、それに対して、同表において「－」によって関連付けら れる文字図形があった場合の当該文字図形に同定できる MJ 文字図形名を Object 値とする。 ④ 人名/対応する常用漢字（項番 36） 戸籍法施行規則（1.5 参照すべき資料 ⑩参照）別表第二の二に同定できるものとして見出され た MJ 文字図形名を Subject とし、その文字図形に対して、同表において参考として括弧内に 示された文字図形があった場合、当該文字図形に同定できる MJ 文字図形名を Object 値とす る。 ⑤ 常用/許容字体（項番 37） 「常用漢字表」（1.5 参照すべき資料 ⑨参照）において、漢字欄に記された文字と同定できる ものとして見出された MJ 文字図形名を Subject とし、鉤括弧［］を添えて記載された文字（許 同定の基準は、外字の実態調査に係る調査報告書等（総務省,2012 年 3 月）の包摂基準書 http://www.soumu.go.jp/main_content/000157024.pdf に準拠し、同基準書における「字形一致」と「デザイン差」に相当するものを、 「同定」できるもの 6 とする。 27 容字体）に、同定する。MJ 文字図形名を Object 値とする。 ⑥ 常用/康煕字典体（項番 38） 「常用漢字表」（1.5 参照すべき資料 ⑨参照）において、漢字欄に記された文字と同定できる ものとして見出された MJ 文字図形名を Subject とし、丸括弧（）を添えて記載された文字（康 煕字体）に同定する。MJ 文字図形名を Object 値とする。 ⑦ 要素図形（項番 28） 別紙 1（データ構成仕様）の「1．要素図形リスト作成仕様」に従って、 「要素図形」のリストを 作成する。 ⑧ 辞書データ処理仕様（項番 42～45） 別紙 1（データ構成仕様）の「2. 辞書データ処理仕様」に従って、各々の辞書に対して関連字 情報を整理する。 ⑨ 関連字の作成（項番 51、51P） 別紙 1（データ構成仕様）の「3．関連字の作成仕様」に従って作成する。 また、IVS（別紙 2 （RDF データ項目仕様）の項番 18）については、2014 年夏を目処に約 3,700 文字図形分が新たに確定する予定であり、また、UCS（別紙 2 （RDF データ項目仕様）の項番 14、 17）約 500 文字分については、2014 年度中を目途に ISO/IEC 10646:2014 の発行により新たに確定 する予定であることから、これらについては、確定後の値をデータ化することが求められる。 データ構築作業のうち、文字図形の同定作業など、目視による判断を伴う部分については、独立し た複数チームで同一作業を行い、その結果を比較して検討する等、精度向上を考慮した手順を構築し て作業を行うことが求められる。 6. システム試験／システム検証 6.1. システム試験 本システムの開発工程においてシステム試験を行い、発見された問題について対応し解消するこ と。ただし、システム試験では、下記の点について考慮すること。 システム試験計画を立案し、本番稼働前に適切な試験を実施すること。 システム試験計画書は中間納入物として納入し、内容についてIPAと整合すること。 セキュリティ問題に対する十分なテストを行い、安全性（機密性、完全性、可用性）につい て確認すること。 「2.3共通基盤システムに係る要件」で示す環境と同等の動作環境において、開発した本シス テムを実データを含めて動作させ、機能、性能、セキュリティ面を含めて、使用可能な状態 が保たれているか、十分に確認すること。 本システムの性能に関する問題については、「2.7規模性能要件」に準拠すること。 下記のテストを実施すること。また、必要に応じて、その他のテストも実施すること。 なお、個々の試験項目の結果は納入不要であるが、試験の状況については試験結果報告書の 中に記載すること。 詳細設計に基づく単体テスト 基本設計に基づく結合テスト 要件定義に基づく総合テスト 要件定義に基づくシステムテスト 要件定義に基づく受入テスト システム試験の試験方法や試験仕様書に基づき実施した試験結果をまとめた試験結果報告書 を作成すること。試験結果報告書には、品質保証責任者の氏名、品質を保証するに足る品質 28 管理方法、品質向上状況、定量的な検査結果が含まれていること。 IPAによる受入テストについて、2週間の期間を設けること。また、納入に際しては、受入テ ストの指摘事項が改善されていること。 IPAでは共通基盤システムで動作させるに当たって、ペネトレーションテストを実施する。 テストには、請負者内で納入時と同内容であるとの評価を受けたシステムを対象とする。ペ ネトレーションテストで発見された問題には全て対応し、テストに合格すること。セキュリ ティテストは、システムからインターネットに公開されるインタフェース部分（Web API、 簡易検索UI、問い合わせシステム）を一般公開した場合を想定して実施する。 テストの結果、大きな不具合があると判断された場合には、別途協議するものとする。 Web API については、ユーザーエージェントに依存することがないようにすること。 6.2. システム検証 完成したシステムに対し、 「電子行政オープンデータ戦略」 「世界最先端 IT 国家創造宣言」などの 文字情報基盤データベース構築の主旨に沿い、また、利用者使用の観点から総合的な検証を行い、 本システムの将来にわたった活用促進／利便性向上に向けた報告書をシステム検証報告書として まとめる。 7. 作業に係る要件 7.1. 作業体制に係る要件 ① データ構築作業においては、外部有識者、実施担当者を含めた 10 名以内（IPA 関係者、事務局を 除く）の検討会を組織し、作業計画段階、構築の中間段階、検証段階の各段階において、少なくと も 1 回以上、計 5 回以上の検討会を開催し、作業計画、作業体制、作業内容について確認を行う こと。なお、検討会メンバは、契約後に IPA と協議の上で決定するものとする。 ② 文字図形の同定など、データ構築において目視による判断を伴う部分については、独立した複数 チームで同一作業を行って結果を比較するなど、精度向上を考慮した体制を構築すること。 ③ Web API の策定に関し、IPA 担当者と打ち合わせを持ち内容について確認を行うこと。 ④ システムの詳細設計段階においては、IPA 関係者と十分に情報共有し、内容について確認し合う こと。 ⑤ 実施担当者に、データベースに係る以下の要件を満たす要員を含めること。構築経験については、 具体的に実績を提示すること。 (ア) RDF 規格に係る十分な知識を有し、また、説明することができる。 (イ) RDF を扱うデータベースの設計及び構築の経験を有する。 (ウ) SPARQL に対する十分な知識を有し、また、説明することができる。 (エ) SPARQL を扱うデータベースの設計及び構築の経験を有する。 (オ) LOD に対する十分な知識を有し、また、説明することができる。 (カ) LOD に係るシステムの設計及び構築の経験を有する。 (キ) XML データモデルによるデータベース設計及び構築の経験を有する。 ⑥ 実施担当者に、文字に係る以下の要件を満たす要員を含めること。 (ア) 符号化文字集合に係る以下の規格 A) ISO/IEC 10646(UCS)規格、 B) JIS X 0213 及び JIS X 0208 に対する十分な知識を有する。特に、文字の統合・包摂に係る考え方、IDS の考え方に精通 し、説明できる。 29 (イ) Unicode consortium の IVD に対する十分な知識、特にグリフィックサブセットの考え方、 コレクション間の関係に精通し、説明できる。 (ウ) 日本政府の漢字施策について十分な知識を有し、説明できるとともに、参照すべき資料を示 すことができる。 (エ) 地方自治体における文字運用の実態について、制度的状況、技術的状況、及び実務的状況に 関する知識を有する。 ⑦ その他の知識に関し、以下の要件を満たす要員を含めること。 (ア) Web API に係る技術的知見・知識を有する。 ⑧ その他 (ア) 実施担当者又はアドバイザーに、辞書編集の経験者等、文字の属性情報に係る知見・知識を 有する者を含めること。 (イ) 実施担当者又はアドバイザーに、 「電子行政オープンデータ戦略」 「世界最先端 IT 国家創造宣 言」を理解し、その内容を正しく説明できる知識を有する者を含めること。 (ウ) 実施責任者及び実施担当者は、IPA 担当者と十分な意思疎通が図れること。 (エ) 品質評価計画の立案、検証及び品質改善策の検討と実施を独立して管理する、などの体制を 確保すること。 (オ) 作業体制に変更が生じる場合、その旨を IPA に報告し、承認を得ること。 7.2. 作業管理に係る要件 作業管理に係る要件は以下のとおりとする。 「1.6 作業内容 No.1 プロジェクト管理」で示すとおり、第三者の立場で判断できるプロジェ クトの管理組織を体制の中に含めること。 （開発担当者との兼務は避けること） 作業工程ごとに WBS ディクショナリにより、作業内容、作業担当者（全ての担当者名。組織 名や役割名のみは不可） 、成果物、レビュー方法、リスク、開始・終了条件を明確にすること。 EVM チャートや進捗状況報告書を作成の上、IPA 担当者に定期的に作業状況を報告すること。 本システム開発の過程で、進捗管理、情報共有のため、IPA 担当者と原則 1 回／週の会議を設 定、実施すること。 （対面の会議とするか、TEL 会議や資料報告のみとするかは、その時の状 況により判断する） ステークホルダー全体に配慮したコミュニケーション計画書を作成すること。 実施すべき会議については、内容、出席者、開催頻度、提示情報、必要フォーム等を定義し、 それらを利用して開催すること。 PMBOK（the project management body of knowledge/プロジェクトマネジメント知識体系） 等に基づき、IPA と合意（契約後 1 ヶ月以内）したプロジェクト計画に従って作業を実施する こと。 実施責任者は PMBOK によるプロジェクト管理経験を有していること。 プロジェクト計画書作成については、PMBOK の仕様に従い、最低限下記を盛り込むこと。 ① 実施体制 ② 会議体 ③ コミュニケーション計画 ④ 工程計画 ⑤ 工程管理計画 ⑥ ドキュメント一覧 ⑦ 品質保証計画 30 ⑧ セキュリティ計画 ⑨ 前提条件、制約条件及びリスク分析 請負者は、全ての作業において、IPA が提供した業務上の情報を細心の注意をもって管理し、 第三者に開示又は漏洩しないこと。また、そのために必要な措置を講じること。 IPA 及び請負者は、相互に本契約の履行過程において知り得た相手方の機密を他に漏洩せず、 また本契約の目的の範囲を超えて利用しないものとする。但し、IPA が、法令等、官公署の要 求、その他公益的見地に基づいて、必要最小限の範囲で開示する場合を除く。 7.3. 作業及び作業環境等に係る要件 作業及び作業環境等に係る要件は以下のとおりとする。 本システムの開発作業については、請負者が用意する場所にて実施すること。 本システムの開発に必要な機器等は、請負者が用意すること。 開発に使用する機器等については、ウイルス対策、セキュリティホール対策等、十分なセキュ リティ対策が実施されていること。 7.1 で指定する外部との検討会、7.2 で指定する IPA との会議を開催した際には、開催後 7 営 業日以内にその議事録を作成し、IPA の承認を得ること。 IPA へ提出又は納入する文書類は、テキスト形式あるいは Microsoft® Office 2010、Apache OpenOffice™ 4.0、一太郎 2014 徹のいずれかによって読み込み、表示、編集、印刷可能であ るファイル形式とする。 文書類は日本語で作成し、図表等は本文中に挿入すること（ただし、固有名詞や文献参照等に 外国語表記を用いることは可能） 。 文書類の用語・用法の不統一、誤字脱字、論理的矛盾など内容の本質に直接関わりのない間違 いについては、IPA へ提出以前に、品質管理体制により、請負者の責任において修正すること。 8. 保守要件 納入成果物についての保守に関する要件は以下のとおりとする。 納入物に係る問題で、運用手順書等により判別がつかない事象や、障害等が発生した場合 は、IPAの要請に応じて説明、質問応答等無償にて協力すること。 9. その他の留意事項 IPA との請負契約においては、件外プロダクトを除く納入物件に係る知的財産権は IPA に帰 属する。特に、データについては、クリエイティブ・コモンズライセンスを適用して公開でき るよう考慮すること。 件外プロダクトを含め、納入物件には、他者の知的所有権への配慮がなされていること。 件外プロダクトの利用権ついては、IPA が無期限に有するものとすること。OSS においては、 ライセンスの組み合わせを含め、当該ソフトウェアのライセンスに示された利用条件に合致し た使い方となっていること。 件外プロダクトを含め、納入物となるシステム全体について最終納入から 5 年間の動作を保証 （運用の継続に不可欠なセキュリティパッチ等の適用を含む）すること。 本仕様書に記載されていない事項について疑義が生じた場合、双方協議の上、対応について決 定するものとする。 以上 31