資料 0

第 4 回共通語彙基盤ワーキンググループ
日時：2016 年 2 月 26 日（火）16:00～18:00
場所：経済産業省 別館 11 階 1115 室＜議事次第＞
1

開会

2

共通語彙基盤に関する政府等の取り組み状況

3

共通語彙基盤事業進捗状況報告42016 年度方針について

5

その他

6

閉会

＜配布資料＞
資料０

議事次第

資料０-１ 委員名簿
資料０-２ 席次表
資料１

共通語彙基盤に関する政府の取り組み

資料２

共通語彙基盤(IMI)事業進捗状況

資料３

相互運用性 SWG 設置の提言案

資料４

共通語彙基盤(IMI)事業方針

参考資料１

コア語彙 2.3 リリースノート

参考資料２

Guidelines for mapping core data models

参考資料３

ツール「表から RDF」のご紹介

資料 0-1

第4回

共通語彙基盤ワーキンググループ 委員名簿
2016 年 2 月 26 日

委員長
武田 英明

国立情報学研究所情報学プリンシプル研究系 教授

委員
越塚 登

東京大学大学院情報学環 教授

坂下 哲也

一般財団法人日本情報経済社会推進協会(JIPDEC)

電子情報利活用研究部

部長
菅又 久直

国連 CEFACT 日本委員会 サプライチェーン情報基盤研究会 事務局長

深見 嘉明

立教大学 大学院ビジネスデザイン研究科 特任准教授

武藤 俊一

一般財団法人全国地域情報化推進協会企画部 担当部長

オブザーバー
内閣官房社会保障改革担当室
内閣官房情報通信技術（IT）総合戦略室
内閣府政策統括官(防災担当)付
総務省行政管理局行政情報システム企画課
総務省情報流通行政局情報流通振興課
国土交通省総合政策局情報政策課
国土地理院企画部企画調整課
国立国会図書館電子情報部電子情報サービス課

事務局
村上 智信

経済産業省情報プロジェクト室

平本 健二

経済産業省情報プロジェクト室

松田 圭介

経済産業省情報プロジェクト室

田代 秀一

独立行政法人情報処理推進機構（IPA）

共通語彙基盤に関する政府の取り組み

資料１

世界最先端IT国家創造宣言（改定）のフォローアップ
平成27年6月30日 閣議決定

 工程表に従い、情報連携用語彙データベースベータ版の整備とサイトの整備を実施。
 オープンデータの活用のために各種情報提供を実施。
公共データの民間開放（オープンデータ）の推進

利便性の高い電子行政サービスの提供【短期（～2016 年度）】
・経済産業省は、国際的な連携を踏まえた情報連携用語彙データベース（基本語彙の定義等をまとめたデータベース）に関して、2014 年度に開発したパイロットシステムの地方公共団体における適用評価等を踏まえつつ2015 年度までに本格版を開発・実証する。総務省及び経済産業省で成果を連携しつつ実証を進め、実証成果は
データカタログでも活用する。【内閣官房、総務省、経済産業省】
・ 2020 年に東京オリンピック・パラリンピック競技大会が開催され、観光、防災等の地
域の情報のニーズが高まると考えられることなどから、公共団体が保有する公共
データについて、情報流通連携基盤共通API 及び情報連携用語彙データベースの開発・実証、公共クラウドの構築や成功事例の整理等により、オープンデータ化を支援する。【内閣官房・総務省・経済産業省・関係府省】【中長期（2017 年度～2021年度）】
オープンデータに係る基盤の維持管理を行うとともに、普及を図る。【内閣官房、総務
省、経済産業省】【短期（～2015 年度）】
・ 経済産業省において、国際的な連携を踏まえた情報連携用語彙データベー
ス（基本語彙の定義等をまとめたデータベース）に関して、2014 年度に開発した評価版の地方自治体における適用評価等を踏まえつつ、2015 年度までに本格版を開発・実証する。
【中期（2016 年度～2018 年度）・長期（2019 年度～2021 年度）】
・ 電子行政分野におけるオープンな利用環境整備に向けたアクションプランを踏まえ、用語の共通化基盤に関しての推進を行う。また、電子行政分野におけるデータ等の共通化・相互運用性確保について、企画立案・維持管理を継続的に行うことができるようにするための機能（日本版NIST）の整備について検討し、必要な措置を行う。【内閣官房、経済産業省及び関係府省庁】※電子行政分野におけるオープンな利用環境整備に向けたアクションプラン（平成26年4月25日ＣＩＯ連絡会議決定）も同様記載 1

現在の取り組み状況
 共通語彙基盤の整備が進んできたことから、各所で先行プロジェクトが開始している。
 内閣官房 自治体向けオープンデータ用語彙の開発、実装• 自治体の先進モデルとして、共通語彙基盤ベースの語彙を組み込んだカタログシステムの整備
 内閣官房・経済産業省
 法人用語彙の検討• 法人用語彙を政府全体に展開するための導入策の検討
 経済産業省（＋情報処理推進機構）
 コア語彙の開発、運用• 住所、氏名等のコア語彙の開発及び運用
 法人用語彙の実装• 法人ポータルサイト（仮称）での共通語彙基盤の導入
 CivicTech向けオープンデータ用語彙の開発• CivicTechでのニーズのある語彙の開発。（子育て支援施設等）
 国際調整• 米国、欧州の行政語彙との整合性調整
 農林水産省
 農作物語彙、農作業語彙の検討• 農作物や農作業など農業システムの基盤となる語彙の検討
 総務省
 統計局LoD検討• 統計局データのLoD化に伴う検討
2

法人ポータルサイトでの共通語彙基盤導入の取り組み

3法人ポータルでは府省内にあるデータを連係させることが必要 これまでの府省内のデータは、担当課毎にフォーマットを作り作成
 そのため、データをまとめるためには、変換作業が必要。
 データの内容も、株式会社と記述したり、（株）と省略する等、未統一で使いにくかった。

法人ポータルのためにデータのフォーマットをきれいにすると言うより、日常の業務を楽にするという観点からも、共通的なフォーマットを使うのは有効

表彰対象

賞名

地域

受賞者

・・・

東京

受賞日

賞名

地域
関東

受賞企業

本社住所

フォーマット統一すると・複数ファイルを統合した表が作れる・管理簿を作る時に検討が簡単
・管理簿の項目に抜けがない
・検索が容易4

ic:実体法人ポータルのデータ構造
 「電子行政分野におけるオープンな利用環境整備に向けたアクションプラン」
が推進する共通語彙基盤（データの交換基盤）に準拠したデータ構造
 国際的な整合性も考慮してデータが設計されている。

【凡例】
Ａ
Ｂ

Ｃ

クラスＡは
プロパティＢ、Ｃを持つ
ic:住所型

ic:組織型Ａ
ＢはＡの拡張（ＢはＡのプロパティを全て備える）
Ｂ

Ａ

ID
名称
略称アルファベット
通称 ic:組織型
活動状況
概要
連絡先

関連組織
地物
住所
代表者
設立日
備考

Ｂ

ID
種別
表記
郵便番号
住所コード
国
国コード
都道府県
都道府県コード
市区町村
区

市区町村コード
町名
丁目
番地補足
番地
号
ビル名
ビル番号
部屋番号
方書

ic:業務組織型
ＡはＢを参照（Ａのプロパティにて参照する値としてＢをとる）

事業種目
事業年度開始日

構成員数
代理人

ic:法人型
組織種別位置
組織種別

資本金
従業員数

コア語彙
経済産業省
法人関連情報語彙

hj:法人基本情報型

hj:法人情報型
法人基本情報法人活動情報

更新日時
有効期間
公表組織
システム名
システムID
キー情報
英語名称
業種コード
目的
事業内容
営業エリア
関係者

データの拡張性が高い

株主
決算日
売上高
流動資産
固定資産
繰延資産
流動負債
固定負債
株主資本
資本剰余金
利益剰余金
新株予約権

hj:住所型
丁目番地等

hj:株主型
所有者

株式保有数
所有比率

hj:法人活動情報型
認定日
名称
部門
区分
地域
認定先区分

hj:補助金型・支出元府省・支出元会計区分
・公益法人の区分・国所管、都道府県所管の区分
・点検結果
・継続支出の有無

hj:表彰型

・事業規模

対象
理由
金額
状況
期間
備考

hj:備考型種別

hj:資格・認定型

・届出先（主務大臣）
・提出先（都道府県知事等）
・届出者情報・事業所情報・店舗情報
・金融機関属性内容

hj:調達型・支出元府省・契約担当官等の情報
・予定価格
・落札率
・応札・応募者数

5※当該項目は実装上、法人活動情報の「備考」に格納

既に持っているデータの扱い オプション１
データの列の変更だけを行う

–
A

B

A

D

B

C

C

・・・

D

原データ
変換後データ・・・

法人ポータルへ オプション2–

元の独自データテンプレートを法人ポータルの書式に変えてしまう（独自項目の追加も可能）

A

B

C

D

・・・

原データ

法人ポータルへ オプション３–

元の独自データテンプレートを法人ポータルの書式に変えて、更に、APIで公開

6

データフォーマット例
 様々なデータを、法人活動の派生系で定義することで、データの組み合わせをしやすくしている。
法人活動（行政活動）表彰
認定日
表彰日
名称
表彰名
部門
表彰部門
区分
受賞区分
地域
地域
認定元
表彰元
認定先
表彰先
認定先区分
表彰先区分
対象
表彰対象
理由
理由
金額
状況
期間（開始日）期間（終了日）

資格・認定
認定日
資格名
認定部門
認定クラス
地域
認定元
認定先
対象物
理由
認定状況
有効期間開始日
有効期間終了日

補助金
認定日

調達
入札公告日

補助金名

認定部門
認定クラス
地域
交付元
交付先

対象物
理由
金額
執行状況
期間開始日
期間終了日

調達機関
落札者

検査
検査日
検査名
部門

処分等
決定日
処分名

地域
検査機関
検査対象者

地域
処分決定者

調達件名及び数量 対象物
理由
落札価格
状況
落札決定日
開始日
終了日
品目分類番号
調達方式
契約方式
随意契約理由
指名業者名
落札方式
予定価格
結果

対象
理由
執行状況
処分期間開始日
処分期間終了日

7

法人ポータルへのデータ提供の流れ
 各担当部局のデータは、法人ポータル用のデータ形式に変換した上で登録を行う。
 データ変換作業はあるが、統合して活用することで、各担当部局も他のデータを見ることが可能になったり、幅広く情報を公開することができる等のメリットの方が大きい 法人ポータル対応を機に、データの管理方式の見直しを図ることができる。
各部局でバラバラなデータ
○○大賞
優秀賞
関東地域
○○株式会社○○測定器
連絡先●●優秀企業関東地域○○株式会社
連絡先●●認定企業○○株式会社
認定理由
連絡先

登録データ形式（例）

変換

表彰日
表彰名
表彰部門
受賞区分
地域
表彰元
表彰先
法人番号
法人名
法人本社住所
対象事業所住所
表彰先区分
表彰対象
理由

送付

法人ポータルサイト

将来はAPI※データの変換は表の列の入れ替えだけなので簡単な作業でできます。（データ登録タイミン
グや周期は、担当部局が判断。）※法人ポータルを機に、「上記形式＋独自情報」と内部管理書式を変えると内部活用でも便利になります。

誰でも一元的に情報入手が可能89

体験学習データでの共通語彙基盤導入の試行

全体構成
 各組織が独自で出していた情報を一元的に提供–

デジタルの時代だからこそ、デジタルの力でリアルの世界を充実
国土交通省
全国の見学施設農林水産省
全国農林漁業体験スポット一覧
全国工場見学・市場見学一覧

IMI
体験イベントテンプレート

IMI
体験イベントテンプレート
概要版

関東農政局
食・農業体験受入れ施設一覧
環境省
探そう自然体験東京都
伝統工芸品見学・体験工房
神奈川県
体験・学習プログラム、
体験学習
横浜市
横浜「学習・体験」ガイド
Google、
日本物流団体連合会物流見学ネットワーク
等

11現在のデータ提供形式
 各組織で独自書式で情報を提供
環境省：探そう自然体験
農林水産省：全国工場見学・市場見学一覧

農林水産省：全国農林漁業体験スポット一覧

国土交通省：全国の見学施設

12共通語彙基盤を活用した集約データイメージ データ項目が多くなるので、入力支援ツールが望まれる

13データ項目が揃うのでデータ操作が容易
 産業分類毎に色分けするなど、様々な活用が可能

緑は一次産業
赤は二次産業青は三次産業
紫は伝統工芸
黄緑は自然
橙色は行政
茶は修行

14

データ統一の手順と実施に当たってのポイント
 データは元々表などで管理されているので、変換は容易
1.
2.
3.
4.

公開用テンプレートを何にするか決める（IMIを推奨）
原課から元データを表形式でもらう
列のデータ内容が合うものを「切り取り」「貼り付け（挿入）」で張り付ける
元データが細かくてテンプレートに入りきらないものは、備考や自由記述欄に貼り付ける。
（省略してもよい）

データ変換のポイント– 既に持っているデータ項目だけでよく、無理に項目を埋める必要はない– 空欄が多くても、気にしない– 詳細情報は元のデータを参照してもらえばよいと思って気楽に取り組むことが重要

15

資料２

共通語彙基盤(IMI)事業進捗状況
2015年度

情報処理推進機構

1

検討体制
IT総合戦略本部
新戦略推進
専門調査会
電子行政
分科会

パーソナルデータに関する検討会
防災・減災
分科会

・・・

協力依頼

各府省CIO
連絡会議

電子行政オープン
データ実務者会議

政府情報システム
刷新等WG

塗りつぶし部分は関連する会議体

報告

経済産業省から

情報共有基盤推進委員会
委員長
有識者
関係団体
オブザーバ

須藤修（東京大学情報学環長）
武田英明（共通語彙基盤WG座長）、林史典（文字情報基盤WG座長）
JISA（ソフト業界）、JEITA（ハード業界）
内閣官房（IT総合戦略室、社会保障改革担当室）、総務省（行政管理局）

が事務局業務を受託
IPA

共通語彙基盤WG

文字情報基盤WG＜実施内容＞• 情報連携用語彙基盤DBの構築• APIカタログの整備• 情報連携用ツールの整備＜実施内容＞• 導入ガイドの作成• 文字情報DBの構築• フォント整備• 標準化の実施【主査】武田英明 (NII教授)【関係省庁】（課長級）
IT室、社保室、内閣府防災、総務省、国交省、国会図書館

コア語彙
検討運用

コア語彙
検討技術

SWG

SWG

• 各委員会、WGの設置主体は経済産業省、事務局はIPA• 各WGの下には、具体的な検討を行なうSWGを設置。

【主査】林 史典(聖徳大学教授)【関係省庁】(課長級)
IT室、総務省、法務、省

文字情報
検討SWG

文字情報基
盤データ
ベース検討
SWG

文字情報
基盤運用
検討SWG

2

「コア語彙」の開発状況
コア語彙2.3 では、法人ポータル、農林水産分野の語彙整備など省庁における実利用現場、自治体からのフィードバックを元に語彙の拡充を行った。
さらに、英語による表記や説明を追加したコア語彙2.3.1 を近日公開予定。

2014/9コア
語彙2.1

2015/2
コア語彙検討
会
内容の精
査
オープン

2015/12
コア語彙検討
会

コア

コア

利便性の向
上

語彙
2.2

コア語彙検討会

語彙2.3

省庁における
実利用からのフィードバック

データへ
の適応性
の向上

2016/2（予定）英語による表記及び説明を追
加

コア
語彙
2.3.1

schema.org

海外語彙関連機関※詳細な訪問先の情報は参考資
料を参照

NIEM
EC ISA
W3C 他••【海外連携】ISA Core Vocabulary とのマッピングを作成
日本の寄稿をもとに語彙間のマッピングガイド
ラインが作成され、ISAから公開されている。

3

コア語彙SWG実施状況
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

2015/4/17 運用
2015/6/12 運用
2015/7/17 運用
2015/8/28 運用
2015/9/18 運用
2015/10/7 運用
2015/11/9 運用
2015/12/9 運用
2016/1/19 運用
2016/2/12 運用
2015/3/27 技術
2015/4/10 技術
2015/4/24 技術
2015/5/15 技術
2015/5/22 技術
2015/6/5
技術2015/6/19 技術
2015/6/26 技術
2015/7/10 技術
2015/7/24 技術
2015/8/7
技術2015/8/21 技術
2015/9/8
技術2015/9/29 技術
2015/10/9 技術
2015/10/23 技術
2015/11/13 技術
2015/11/20 技術
2015/12/22 技術
2016/1/8
技術
2016/1/22 技術
2016/2/16 技術

コードリスト整備の優先順位、農水語彙のサポート体制など
語彙関連イベント実施について
METI側事業(農水等)の状況、ドメイン語彙について
IMI共通語彙基盤の課題整理、IMIへの適合(ロゴプラム)について
METI側事業(農水等)の状況、IMIロゴの必要性などについて
METI側事業(農水、法人ポータル等)の状況、IMIロゴ
METI側事業(農水、法人ポータル等)の状況、IMIロゴ
METI側事業(法人ポータル等)の状況、４月以降のイベント実施について
ドメイン語彙（法人ポータル、農業語彙）、語彙利用ツールについて
ドメイン語彙運用に向けて検討
データ交換用XMLスキーマ、データテンプレートの仕様
マッピングテーブル、英語資料、コア語彙2.21進捗確認、RDFにおける追加制限についてマッピングテーブル及び文書の確認マッピング再評価
語彙データベース機能検討
ISAへのレスポンス、コア語彙2.2.1についてコア語彙の単位表記について
コア語彙の単位表記について
コードリストの扱いについて
コードリストの扱いについて
コードリストの扱いについて
コードリストの扱いについて
コア語彙2.3、コードリストについて
コア語彙2.3について
コア語彙2.3について
コア語彙2.3について
コア語彙2.3について
コア語彙2.3について
コア語彙2.3の英語表記について
コア語彙2.3の英語表記について
コア語彙2.3.1の確認
コア語彙2.3.1の最終確認とコア語彙2.4に向けての課題整理

4

ツールの公開 （2015年7月14日）
自治体職員や自治体のシステムやデータマネージメントを請負う技術者を対象とした共通語彙基盤を用いたデータの作成を支援するツール○新たにデータ構造を設計することなく、共有されているデータ構造を利用することで、簡単に構造化されたデータを作成することができる。
○データ構造を作成する場合であっても、表の各項目をコア語彙の用語に関係付けるだけで行うことができ、RDFやXML等の技術に詳しい必要はない。
○このツールにより下記のことを行うことができる。
•
•
•
•
•

コア語彙を用いたデータ構造を新規に作成
表形式データを元にデータ構造を作成
表形式のデータをコア語彙を用いたデータに変換
データ構造の公開と共有
データクレンジング

名称

表形式データ
名称

所在地

種別

データ構造設計者

所在地

住所

表記

データ構造の共有
施設

データ作成者（データ構造利用者）「表からRDF」

種別

名称

表記

5

地方説明会の開催
 自治体オープンデータ推進協議会共催イベント••

2015年6月22日 大阪
武田英明氏 共通語彙基盤コア語彙2（Ver2.2)の紹介

 情報の価値を最大化する「共通語彙基盤」セミナー〜“つながる”データ “つながる”システム〜• 「共通語彙基盤」の進捗報告と今後に向けた展開
日時• 先進自治体での事例を交えて、どのようにして「データ」を活用していくか、 7月14日
9月3日「表からRDF」のデモを交えつつ説明• 北海道森町 山形 巧哉氏（札幌会場）
森町のオープンデータの現状と対応策→ 自治体現場での活用の参考になったと好評

9月4日
9月11日
9月17日

場所

参加者

福岡
仙台
札幌
大阪
新潟

約60名
約40名
約40名
約40名
約60名

6

共通語彙基盤事業説明会（福岡・仙台・札幌・大阪・新潟）の参加者の業種（アンケート結果より）説明会（福岡・仙台・札幌・大阪・新潟）の参加者の業種
0

10

20

30

40

情報処理・サービス

50

60
54

ソフトウェア製造業

28

自治体

27

その他

Q1.1 業種（複数選択有り）
情報処理・サービス
ソフトウェア製造業
自治体
その他
学校・研究所
官公庁
ハードウェア製造業
コンピュータ関連販売業
学生
通信・運搬・公共サービス
デザイン・広告業
医療・バイオ関係
金融・証券・保険・不動産
建設業
商社・卸業・小売業
報道・出版業合計

22

学校・研究所

15

官公庁

11

ハードウェア製造業

5

コンピュータ関連販売業

4

学生

3

通信・運搬・公共サービス

3

デザイン・広告業

3

医療・バイオ関係

1

金融・証券・保険・不動産

1

建設業

1

商社・卸業・小売業

1

54
28
27
22
15
11
5
4
3
3
3
1
1
1
1
0
179

7

ロゴ、キャラクターの制定
2015年12月公開
 経済産業省が委託事業により二次利用も含めた著作権の譲渡を前程として公募
 商標登録申請をIPAにて準備中

ロゴ

キャラクター

シンプルなフォルムの中に「先進性」「プロフェッショナル
性」「グローバル感」が感じられます。
「Ｍ」の一部が重なることで、人と人のコミュニケーションを連想させ、国際会議の場でも文化の壁を越えた親しみやす
さ、わかりやすさを感じられます。

ゴリラをモチーフにしたキャラクターで名前は「ゴイラ」です。
ゴリラと語彙を組み合わせたネーミングです。
目と鼻がIMIの形になっています。丸い三色のお腹は、コア語
彙、ドメイン共通語彙、ドメイン固有語彙を表しています。

8

情報連携用基本語彙データベースの構築

9

ISO TC204（Intelligent Transport System)の動き• 車両間、車両と公的情報との連携などのため、メタデータやデータ構造の標準化の必要性を認識• TC204/WG1が、規格に出てくるデータ交換について情報の収集と整理を開始• 2015年10月に開催されたTC204会議で語彙基盤を紹介– 今後の連携可能性を検討開始
10産業競争力懇談会（ＣＯＣＮ）での検討
個人情報管理の新しい枠組み作りにあたって、語彙の標準化が重要

11
産業競争力懇談会 「IoT時代におけるプライバシーとイノベーションの両立」報告書より

データマネジメント2016で講演（予定）12欧州との関係• 欧州委員会主催SEMIC会議（ラトビア)の基
調講演で、共通語彙基盤を紹介(2015年5月)• 欧州各国、米国、日本が参加する
Community of Practice on Core Data
Models で、各語彙のマッピングについて検討。
– Guidelines for mapping core data models のドラフトを作成中• 欧州委員会主催 ISA to ISA2会議（ブリュッセル）で共通語彙基盤を紹介(2016年3月）
13

共通語彙基盤を活用する自治体が増加中• オープンデータの公開にあたり、コア語
彙を用いる自治体– 北海道森町、北海道⼋雲町、⻑野県須坂市など• オープンデータに関わる業務委託等において、共通語彙基盤を要件とする自治体– 大阪市、宮城県など• その他、自治体内部での情報共有のための利用や、各自治体の広報誌のデータへの適用などの検討が進められている。

14

LinkData.org にみる共通語彙基盤の活用事例
LinkData.org (オープンデータの作成・公開を行うサイト)では、４０を超える
共通語彙基盤を活用したリソース（自治体によるオープンデータ、オープン
データを活用したアプリケーションなど）が登録されている。
60

2.2 リリース

2.3 リリース

50
40
30
20
10
0

LinkData.org

IMI活用リソースの登録数

15

ツール「表からRDF」の活用状況
活用状況• 自治体職員、大学関係者、システムインテグレータ等、２３名がデータ構造の作成・登録に必要なユーザー登録を行っている• ユーザー登録者内訳は、自治体職員１３名、他１０名

16

資料３
2016 年*月**日
政府情報システム刷新等ワーキンググループ
相互運用性検討サブワーキンググループ
設置の提言
情報共有基盤推進委員会
行政サービスの相互運用性確保は、利用者視点のサービス構築や効率的で迅速なサービス構築に必須の条件である。そのため、経済産業省は関係府省の参加により情報共有基盤推進委員会を設置し、文字情報基盤と共通語彙基盤の整備を図ってきた。これらの項目は、電子行政分野におけるオープンな利用環境整備に向けたアクションプランの中でも中核的な推進項目とされている。
これまでは、基盤構築の技術的検討が中心であったため経済産業省および情報処理推進機構で検討を行ってきたが、文字情報基盤は国税庁の法人番号付与システムで活用され、共通語彙基盤は、法人ポータル（仮称）、で活用され農林水産省で検討行われているなど政府内での導入フェーズに入ってきている。他
府省からの導入等についての問合せも増えてきていることから、政府内での検討のフェーズに入ってきていることから、政府情報システム刷新等ワーキンググループの下に相互運用性検討サブワーキンググループを設置し、相互運用性に関する検討を強化するとともに、各府省担当者が導入経験や課題の共有を図る場を設置することを提言する。
提言内容
・電子行政刷新ワーキンググループ相互運用性検討サブワーキンググループの設置。
・サブワーキンググループ参加者は、データ基盤の構築等、相互運用性の向上に興味のある府省担当者。
・開催頻度は四半期から半期に１回程度の開催とする。
・事務局は、内閣官房情報通信技術（IT）総合戦略室が経済産業省および情報処
理推進機構の支援を受けて行う。
以上

参考
これまでの体制
IT総合戦略本部• 戦略実現のため、専門家による委員会とワーキンググループを組織
電子行政
分科会

各府省CIO
連絡会議

パーソナルデータに関する検討会

新戦略推進
専門調査会

防災・減災
分科会

電子行政オープン
データ実務者会議

政府情報システム
刷新等WG

・・・

協力依頼

塗りつぶし部分は関連する会議体

報告

公共データwg

情報共有基盤推進委員会
委員長
有識者
関係団体
オブザーバ

共通語彙基盤WG

文字情報基盤WG＜実施内容＞• 情報連携用語彙基盤DBの構築• APIカタログの整備• 情報連携用ツールの整備＜実施内容＞• 導入ガイドの作成• 文字情報DBの構築• フォント整備• 標準化の実施

オープンデータ視点での検討• 各委員会、WGの設置主体は経済産業省、事務局はIPA• 各WGの下には、具体的な検討を行なうSWGを設置。

須藤修（東京大学情報学環長）
武田英明（共通語彙基盤WG座長）、林史典（文字情報基盤WG座長）
JISA（ソフト業界）、JEITA（ハード業界）
内閣官房（IT総合戦略室、社会保障改革担当室）、総務省（行政管理局）【主査】武田英明 (NII教授)【関係省庁】（課長級）
IT室、社保室、内閣府防災、総務省、国交省、国会図書館

情報セキュリティ
政策会議【主査】林 史典(聖徳大学教授)【関係省庁】(課長級)
IT室、総務省、法務、省

今後の体制
IT総合戦略本部
新戦略推進専門調査会
電子行政分科会
戦略等の推進管理等を行うため

基盤
BPR
Web
ガバナンス
体制

電子行政オープンデータ実務者会議

ｅガバメント閣僚会議
行政のＩＴ化と業務改革の同時・一体的改革を機動的かつ強力に進め ること

国・地方ＩＴ化・ＢＰ
Ｒ推進チーム

電子行政 オープンデータ戦略に基づく施策に関する調査及び検討

オープンデータ
データカタログ
Webサイト利用規約

各府省ＣＩＯ連絡会議
関係行政機関相互の緊密な連携の下、政府全体として情報化推進体制を確立し、行政の情報化等を一層推進することにより、国民の利便性の向上を図るとともに、行政運営の簡素化、効率化、信頼性及び透明性の向上に資するため、

政府情報システム刷新等ＷＧ
実務的な観点から検討、連絡調整等を行うため

調達
運用・保守
共通PF

ＳＷＧ
相互運用性検討SWGを追加設置(政府内の検討の場)

情報共有基盤
推進委員会
共通語彙
基盤WG

文字情報
基盤WG

ＷＧ

資料４

共通語彙基盤(IMI)事業方針
2016年度

情報処理推進機構

1

共通語彙基盤2016年度案
2016年度

2017年度
春

イベント

秋
6月

セミナー

法人ポータル（METI）
統計データLOS提供（統計局）
自治体での活用状況（森町、金沢区等）の報告と、語彙基盤説明

アイディア
ソン

試験運用されたデータベース・ツールについて活用法の討論（アイディアソン）、活用アプリのコンテスト等を実施

アプリコン
テスト

語彙データベースユーザ支援ツールの構築
試験運用

情報連携用語彙データベースの構築
国際 公開物

SEMIC

CoP

CoP

ITS

コア語彙
version up

IMI活用ガイドライン

新規委員会・作業部会

IMI技術SWG （API等技術的検討）
IMI運用SWG （運用ポリシ策定、ロゴ運用管理）
IMI応用SWG （活用分野の拡大）
コア語彙検討SWG
共通語彙基盤WG（武田委員長）
情報共有基盤推進委員会（須藤委員長）

2

情報連携用基本語彙
データベースの構築

3

共通語彙基盤の全体イメージ

4

共通語彙基盤構築事業スケジュール
共通語彙基盤
全体スケジュール

2015年度3
語彙基盤WG

4

5

6

2016年度
9
10 11

12

1

2

▼中間報告

3

4

5

6

2017年度
7
8

承認

10

11

▼成果
報告

報告

承認

納入▼

検
収

結合
テス ト
期間

9

▼中間報告

報告
中間納入▼

テスト▼

契約▼

ペネトレーション

承認

WebAPI
仕様▼

語彙
データベース

検収試行期間／システム検証作業

1

2

▲納入

検
収

▲イベント

試行期間／システム検証作業
▲イベント

▲中間納入

▲契約

語彙
データベース
ユーザー支援
ツール

8

▼方針確認

報告

語彙
データベース7

ユーザー支援ツール
検収5

語彙ＤＢと支援ツールの全体イメージ

6

語彙データベース開発プロジェクト
項目

システム開発

内容
•
•
•
•
•

ポータル構築（メニュー、お知らせ、事例紹介）
名前空間の整備（語彙、コード・ID）
データベースの構築（意味/根拠、オントロジー）
レポジトリの構築（DMD、語彙、コード・ID）
管理機能（ユーザー管理、ログ採取）•

公開中のIEP(情報交換パッケージ)に必要な情報を加え、DMDとして整備する
コア語彙に関する以下のデータを、自治体や政府機関関係者などの利用者および利用シーンを想定した上で収集整理する。情報の範囲や内容の妥当性の確認等のため、委員会を設置し意見を求める。
 意味・根拠データ、オントロジーデータ
 コード、コードリスト、ID型、ID体系•

コンテンツ整備

ドメイン語彙
運用検討

システム検証•特定の業務領域で用いられるドメイン語彙の運用方法について、
有識者による委員会を設置し検討を行う。

•

仮運用を行い、別途実施される「支援ツール」と接続し試用運用を行う。
仮運用中、上記ツール関係者、コア語彙関係者及び受注者自身などによりシステムの検証を行い、将来の活用促進に向けた提言
を報告書としてまとめる。
7•

システム開発（機能ブロック図）
ポータル
ユーザーインターフェース
トップページメニュー

Web API

レポジトリ・名前空間
DMDサービス

おしらせ・新着
DMD API
DMDツール• DMDの検索・取得• DMDの雛形作成・登録• DMDを用いたデータ変換
ざ

語彙ツール

•
•
•
•
•
•

語彙の一括取得
語彙の検証・登録
用語の検索・取得
用語の意味・根拠の検索
コード・IDの検索・取得
コード・IDの作成・検証・登録

DMDの登録・検索
取得・管理

DMDレポジトリ

語彙サービス
語彙API

語彙
レポジトリ

コード・ID API

コード・ID
レポジトリ

意味・根
拠
データ
ベース

オントロ
ジー
データベー
ス

意見交換システム
ドキュメント
事例紹介ページ

ユーザー管理サービス
ユーザー管理API

ユーザー管理データベース

関連情報ページ• 管理コンソール

システム管理機能• サーバー管理• ログ管理ログデータベース• ポータルコンテンツの管理

8

DMD(DataModelDescription)
構造化したデータ項目のスキーマや項目の値の制限、項目の内容を説明したドキュメントなど、データ項目を共有するために必要な情報をひとまとめにしたパッケージ。機械向けの情報と人間向けの情報の双方を持つ。

ドキュメント例

DMDヘッダー XML版スキーマ例

9

語彙データベース
ユーザ支援ツールの開発

10ユーザー支援ツール開発プロジェクト
項目

ツール開発
（DMDツール）

内容◆DMD検索ツール•
ID、名前、概要、作成者、キーワード等による絞り込み検索•
一覧表示、グラフ構造ビュー、表形式ビュー• データ変換◆DMDエディタ•
構造化データの設計支援•
スキーマの生成、ドキュメントの自動生成◆DMDビューワ
•構造化データをグラフ表示

ツール開発（語彙作成支援ツール）•

コア語彙やドメイン語彙の作成者向けのツール• 概念の整理の支援機能• 概念の可視化（グラフ、表形式、集合）• 登録用テンプレート

ライブラリ開発•

外部ツールから共通語彙基盤DBを使いやすくするためのライブラ
リを整備。

•
•

自治体/省庁、利用事例紹介
IMIの認知度向上のためのイベント（検討中） DMDコンテスト
 アプリコンテスト

イベントの実施

11

ユーザー支援ツール活用イメージ

自治体システム
データ作成者

DMD
ツール

語彙作成
支援ツール

DMDによる
データ変換機能

ライブ
ラリ
RUBY
JAVA ?
C# ?

構造化
データ

コア語彙

Web
API

ドメイン語彙
ドメイン語彙
ドメイン語彙

DMD

コード・ID
コード・ID
コード・ID

語彙データベース

12

DMDエディタ(動作イメージ)
Step.1 CSVをインポート

Step.2 クラスを選択

Step.3 プロパティを追加

Step.4 プロパティにデータを入力

13

DMD(DataModelDescription)
構造化したデータ項目のスキーマや項目の値の制限、項目の内容を説明したドキュメントなど、データ項目を共有するために必要な情報をひとまとめにしたパッケージ。機械向けの情報と人間向けの情報の双方を持つ。

ドキュメント例

DMDヘッダー XML版スキーマ例

14参考資料１

コア語彙 2.3 リリースノート
コア語彙 2.2 からの変更点

独立行政法人情報処理推進機構
2015 年 12 月 11 日

1. はじめに2015 年 2 月 3 日に公開したコア語彙 2.2 に対する各方面からのご意見を踏まえ、データ表現の容易性や汎用性の向上のため、以下の変更を行いました。

2. 用語の変更
概要

2.1.

本バージョンは、マイナーバージョンアップであり、基本的にコア語彙を利用して作成された既存のデータと互換性があります。
主な変更点：
 「単位コード」を新たに導入するなど、重量や面積などの数量の単位をより容易に表現できるようになりました。


単位は、量の種別に関わらず「単位コード」を利用するようになりました。



コードが存在しないような単位のために「単位表記」プロパティが追加されました。

 「期間」と「スケジュール」が統合され、「期間」を「スケジュール」として利用できるようになりました。この変更にともない、下記の変更が行われました。
「スケジュール」は「期間スケジュール」に項目名が変更されました。



データ型が「スケジュール」となっていたプロパティは、データ型が「期間スケジュール」に変更されました。



継承が「スケジュール」となっていたクラス用語の継承が「期間スケジュール」に変更されました。

 クラス用語の追加、クラス用語へのプロパティの追加などの拡張を行い、コア語彙を用いてより広い範囲のデータを表現できるようになりました。
 コア語彙をより汎用的に利用できるようにするため、クラス用語、プロパティ用語の変更を行いました。

クラス用語の追加

2.2.

下記の４つクラス用語が追加されました。

単位コード
識別子:
ic:単位コード型
継承:
ic:コード型
説明:
コードを表現するためのクラス用語
プロパティ:
識別子

項目名

値型

回数

説明

ic:量種別量種別

xsd:string

0..1

量の種別

ic:乗数

乗数

xsd:double

0..1

基本単位に対する変換乗数

土地
識別子:
ic:土地型継承:
ic:地物型
説明:
施設や建物など、参照対象となる地物を表すためのクラス用語
プロパティ:
識別子

項目名

値型

回数

説明

ic:種別

種別

xsd:string

0..1

識別するための ID

ic:種別コード

種別コード

ic:コード型

0..n

概要説明。100 文字以内

ic:面積

面積

ic:面積型

0..n

土地の面積

活動
識別子:
ic:活動型
継承:
ic:事物型
説明:
イベントを表現するためのクラス用語
プロパティ:
識別子 項目名
ic:ID

ID

値型

回数

説明

ic:ID 型

0..n

イベントを識別するための ID

ic:種別 種別

xsd:string

0..n

イベント内容の種別

ic:名称 名称

ic:名称型

0..n

イベントの名称

ic:関与 関与

ic:関与型

0..n

イベントに関連する組織

ic:場所 場所

ic:場所型

0..n

イベントの開催場所

ic:日時 日時

ic:日時型

0..n

イベントの期間

ic:期間 期間

ic:スケジュール型

0..n

イベントの期間

ic:説明 説明

xsd:string

0..n

イベントへの連絡方法

関与
識別子:
ic:関与型
継承:
ic:事物型
説明:
関係する人や組織を表現するためのクラス用語
プロパティ:
識別子
ic:役割

項目名
役割

値型

関与者

説明

xsd:string 0..1 人や組織の位置づけや役割

ic:役割コード 役割コード ic:コード
ic:関与者

回数0..1 人や組織の位置づけや役割のコード

ic:実体型 0..n 関係する人や組織2.3.

プロパティの追加

下記の表のように、多くのクラス用語にプロパティを追加しました。下記の表では、追加されたプロパティのみを記載しています。

コード
項目名

データ型

回数

説明

表記

xsd:string

0..n

コードの値に対応する概念の表記

上位コード

ic:コード型

0..n

このコードの上位のコード

下位コード

ic:コード型

0..n

このコードの下位のコード

関連コード

ic:コード型

0..n

このコードに関連するコード

組織
項目名

データ型

回数

説明

活動

活動型

0..n

組織の活動

関連人員

ic:人数型0..n

関連する人員の人数（従業員数な
ど）

地物
項目名
関与

データ型
関与型

回数

説明

0..n

地物に関連する組織や人

金額
項目名
乗数

データ型
xsd:double

回数
0..1

説明
金額の値に対する変換乗数

状況
項目名

データ型

回数

説明

関与

関与型

0..n

状況に関連する組織や人説明

xsd:string

0..1

状況の説明

期間

ic:期間スケジュール型 0..n

状況の期間

日時
項目名
表記

データ型

回数

説明

xsd:string

0..1

日時の任意の表記

項目名

データ型

回数

説明

表記

xsd:string

0..1

日付の任意の表記

項目名

データ型

回数

説明

単位

単位コード型

0..1

単位を表すコード

単位表記

xsd:string

0..1

単位の文字列による表現（助数詞など）

項目名

データ型

回数

説明

単位

単位コード型

0..1

単位を表すコード

単位表記

xsd:string

0..1

単位の文字列による表現（助数詞など）

項目名

データ型

回数

説明

単位

単位コード型

0..1

単位を表すコード

単位表記

xsd:string

0..1

単位の文字列による表現（助数詞など）

項目名

データ型

回数

説明

単位

単位コード型

0..1

単位を表すコード

単位表記

xsd:string

0..1

単位の文字列による表現（助数詞など）

日付

数量

容量

面積

重量

長さ
項目名

データ型

回数

説明

単位

単位コード型

0..1

単位を表すコード

単位表記

xsd:string

0..1

単位の文字列による表現（助数詞など）

その他の変更2.4.

 プロパティ用語「時間」のデータ型を「数量型」に変更しました。「アクセス」及び「アクセス区間」の２つのクラス用語が「時間」プロパティを利用しています。

利用が推奨されない用語及びプロパティ

2.5.

コア語彙 2.2 の用語のうち下記の用語及びプロパティは、コア語彙 2.3 では、より利用しやすいものへと変更されています。これらの用語及びプロパティは互換性のためにコア語彙 2.3 においても残されています。将来の版では削除される可能性がありますので、これらの用語を利用することは推奨いたしません。
http://imi.ipa.go.jp/ns/core/2 より参照される XML スキーマには、これらの用語は含まれていません。これらの用語を使用しなくてはならない場合は、https://imi.ipa.go.jp/ から
ダウンロード可能な schema_xsd.zip の中の、core23bc.xsd を XML スキーマとして参照してください。


利用が推奨されないクラス用語
「測定値」（クラス用語「数量」を使用してください。）

「時間」（クラス用語「数量」を使用してください。
）

利用が推奨されないプロパティ
「業務組織」の「構成員数」（「組織」の「関連人員」プロパティを使用してくだ
さい。
）



「法人」の「従業員数」（「組織」の「関連人員」プロパティを使用してください。
）

「数量」の「数量単位」（「単位コード」プロパティを使用してください。
）

「容量」の「容量単位」（「単位コード」プロパティを使用してください。
）

「面積」の「面積単位」（「単位コード」プロパティを使用してください。
）

「重量」の「重量単位」（「単位コード」プロパティを使用してください。
）

「長さ」の「長さ単位」（「単位コード」プロパティを使用してください。
）

「状況」の「関係者」（「関与」プロパティを使用してください。
）

「状況」の「詳細」（「説明」プロパティを使用してください。）

参考資料２
日米欧で作成中のドラフト

SC118DI07171
Guidelines for mapping core data models

Guidelines for mapping core data models

Document Metadata
Property

Value

Date

2015-10-19

StatusFor acceptance

Version

0.08

Authors

Alexandru Droscariu – PwC EU Services

Reviewed by

Nikolaos Loutas – PwC EU Services
Susanne Wigard, European Commission

Approved byThis document was prepared for the ISA Programme by:
PwC EU Services
Disclaimer:
The views expressed in this report are purely those of the authors and may not, inany circumstances, be interpreted as stating an official position of the European
Commission.
The European Commission does not guarantee the accuracy of the information
included in this study, nor does it accept any responsibility for any use thereof.
Reference herein to any specific products, specifications, process, or service bytrade name, trademark, manufacturer, or otherwise, does not necessarily
constitute or imply its endorsement, recommendation, or favouring by theEuropean Commission.
All care has been taken by the author to ensure that s/he has obtained, where
necessary, permission to use any parts of manuscripts including illustrations,maps, and graphs, on which intellectual property rights already exist from thetitular holder(s) of such rights or from her/his or their legal representative.

Page 2

Guidelines for mapping core data models

Table of Contents
1

INTRODUCTION ............................................................................................................................ 42

KEY FACTS ABOUT MAPPINGS ...................................................................................................... 5
2.1
2.2

3

MAPPING CONCEPTUAL DATA MODELS .................................................................................................... 5
MAPPING RELATIONS ........................................................................................................................... 6
Exact match .......................................................................................................................... 7
Close match .......................................................................................................................... 7
Related match....................................................................................................................... 7
Narrow match ....................................................................................................................... 8
Broad match ......................................................................................................................... 9

STEPS TO CREATE MAPPINGS...................................................................................................... 10
3.1

3.2
3.3

CONCEPTUAL LEVEL MAPPINGS ............................................................................................................ 10
Example for “Has exact match” .......................................................................................... 10
Example for “Has close match” .......................................................................................... 11
Example for “Has related match” ....................................................................................... 11
Example for “Has narrow match” ....................................................................................... 12
Example for “Broad match” ................................................................................................ 12
SYNTAX LEVEL MAPPINGS .................................................................................................................... 13
SPECIAL CASES .................................................................................................................................. 14
Composite mapping ............................................................................................................ 16
Partial mapping .................................................................................................................. 16
Conditional mapping .......................................................................................................... 17
Partial and conditional mapping ........................................................................................ 18

Page 3

Guidelines for mapping core data models

1

INTRODUCTION

The current document complements the guidelines for creating mappings between
the Core Vocabularies and other data models initiatives, which are documented in
the “Handbook for using the Core Vocabularies” 1 (henceforth referred to as “thehandbook”).
The objective is to support the effort of developing data model mappings. To do so,
we provide a few examples of cases that are likely to happen when creating mappings,
and which we encountered while mapping the Core Vocabularies with other data
models, such as the Swedish Company data model, NIEM 3.0, KoSIT – XÖV, OSLO,
and etc. We explain how we selected the mapping relations in these special cases.
During the development of the mappings, we followed the method described in thehandbook and we documented the mappings in a specially crafted spreadsheet. The
mappings are published on the Core Data Model Mapping Directory (CDMMD) 2.
The current document is structured as follows. It first provides an introduction into
the work of mapping data models explaining the needs behind. It continues with an
overview of the structure of conceptual data models, the mapping relations, and thebasic rules to apply the mapping relations. The document provides a description of
the steps to apply mapping relations, and it closes providing several special cases
from the experience of mapping the Core Vocabularies with the Swedish Company
data model. We sprinkled the document with examples to highlight the reasoning
behind applying the mapping relations.

1

2

https://joinup.ec.europa.eu/site/core_vocabularies/Core_Vocabularies_user_handbook/Handbook-forusing-the-Core-Vocabularies_v0.50.pdf
http://mapping.semic.eu
Page 4

Guidelines for mapping core data models

2

KEY FACTS ABOUT MAPPINGSThe handbook provides two reasons for creating mappings between data models:•

For documenting purposes, when the mappings at the conceptual level offer
an entry point to domain experts to understand the mapped data models;•

For reconciliation of data sources, when mappings are used to extract basic
information from conformant data models.

The syntax level mapping is a necessary input for the implementation of procedures
for reconciliation of data sources. The conceptual level mapping supports the syntax
level mapping. Therefore, conceptual level mapping is a prerequisite for syntax levelmapping.
Mappings should be created between elements of two distinct data models only when
the links are inherent in the meaning of the linked elements 3.
The mapping relations between the elements of two data models are independent of
the syntax used to describe/represent the two data models.
Data reconciliation can be done without loss of meaning only between elements thathave an exact match relationship. For the elements that have a broad or narrow
relationship, the reconciliation can be done from the more specific element to themore generic element. Reconciling elements that have a close relationship involves
the risk of losing meaning.

2.1 Mapping conceptual data models
Conceptual level mappings are developed between conceptual data models. The
structure of a conceptual data model is composed of classes which describe real or
abstract things such as buildings, people, organisations or services performed by alegal entity. Classes are composed of properties and/or associations. The difference
between a property and an association is the type of values that may be assigned. A
property (e.g. PersonFamilyName is a property of the Person class of the ISA Core
Vocabularies) takes a singular value of a specific data type. An association (e.g.
PersonAddress is an association of the Person class of the ISA Core Vocabularies)
takes an instance of another class. The conceptual model does not specify how
properties and associations are technically represented. For example, an association
may refer to another object with some kind of identifier (e.g. a URI in RDF) or may
embed the whole object (e.g. nesting in XML).
When developing conceptual level mappings, we refer to classes, properties andassociations, generally, as elements. To decide the mapping relation to map twoelements, consider the following aspects:•

3

Map classes to classes, properties to properties, and associations to
associations.

http://www.w3.org/TR/skos-reference/#mapping
Page 5

Guidelines for mapping core data models•

Consider the meaning of the two elements, regardless of:o

The data structure or the properties used to describe the two elements.

o

The way each of the two elements are identified (e.g. “BE” VS“http://data.europa.eu/languages/BE” for the language code).

oThe way the two elements encode literals (e.g. “1990-06-09” VS“09/06/1990” for the birthdate).

2.2 Mapping relations
The mapping relations used for the conceptual level mappings are borrowed fromSKOS 4: exact, close, related, narrow, and broad match.
The handbook offers a comprehensive description of the mapping relations and theirapplication. This chapter provides a summary explaining the meaning of the mapping
relations, and how they should be applied.
The mapping relations are defined in terms of the set of subjects covered by theelements 5 . The figure below, extracted from the handbook, provides a graphicalrepresentation of the mapping relations.

Figure 1 - Mapping relations: defined in terms of the set of subjects covered by the elements

The following examples will be further explained in chapter 3.

45

http://www.w3.org/TR/skos-reference
https://joinup.ec.europa.eu/site/core_vocabularies/Core_Vocabularies_user_handbook/Handbook-forusing-the-Core-Vocabularies_v0.50.pdf
Page 6

Guidelines for mapping core data models

Exact match
We say that “A has an exact match B” if the set of subjects of A is equal to the set of
subjects of B. The definitions of A and B are equivalent.
Facts that are expressed for elements (classes, properties, or relationships) with anexact match relationship can be converted in both directions between data models
without loss of meaning.
For example:Coreelement

Vocabularies

LegalEntity

Mapping relation

Swedish Company data
model

Has exact match

Juridisk person

Close match
We say that “A has a close match B” if the set of subjects of A is mostly equal to theset of subjects of B. The number of subjects of A not included in B, and vice-versa,
is negligible.
Elements with a close match relationship can be converted in both directions between
data models with a minimal loss of meaning for some individuals.
For example:Coreelement

Vocabularies

AddressLocatorName

Mapping relation

Swedishmodel

Company

Has close match

belägenhetsadressgårdsadressområde

data

Description:
The locator name is a proper
noun applied to the realworld entity identified by thelocator. The locator namecould be the name of theproperty or complex, of thebuilding or part of thebuilding, or it could be thename of a room inside abuilding. [INSPIRE]
The key difference between alocator designator and alocator name is that thelatter is a proper name and isunlikely to include digits.

Description:"Farm Address area" can beused to specify the locationor to preserve historicalnames. "Farm Address area"
should be used where there
are
names
of
farms,
collections of buildings or asingle house that is listed ona general map and wherethese names are used in theaddress today.

Related match
We say that “A has a related match B” if there is a meaningful intersection between
the subjects of A and the subjects of B.
Page 7

Guidelines for mapping core data models

Elements with a related match relationship can only be converted with considerable
error. Conversion is not advised. Such mappings can still be valuable to makesemantic conflicts between data models better visible.
For example:Coreelement

Vocabularies

AgentPlaysRole

Mapping relation

Swedishmodel

Company

Has related match

Relation till person
Relationtill(relationship to
Role)

data

personperson =Description:
Relationships
betweenpersons are necessary todefine the person. Here is forexample information on who
are the representatives oflegal entities. It is also
through this information thatthe address of a CEO can belinkedtothelimitedcompany he/she represents.

Description:
A public service in which theagent plays a role.

For example: a natural
person authorized to sign forthe legal entity.

Narrow match
We say that “A has a narrow match B” if the set of subjects of A is a superset of theset of subjects of B. The definition of A generalizes the definition of B.
Facts that are expressed for elements (classes, properties, or relationships) with anarrow/broad match relationship can only be converted into only the direction of themore general data model element.
For example:Coreelement

Vocabularies

LegalEntityLocation

Mapping relation

Swedishmodel

Has narrow match

Säte

Companydata

Description:

Description:

AssertingtheLocation
relationship implies only thatthe legal entity has someconnection to a location intime or space. It does not

The city in Sweden where theBoard (of the legal entity)
will meet and where thegeneral meeting is to be
held.
Page 8

Guidelines for mapping core data models

imply that the legal entity isnecessarily at that location
at the time when theassertion is made.

Broad match
We say that “A has a broad match B” if B has a narrow match A.
For example:
Core Vocabularies element

Mapping relation

Swedish Company data
model

LegalEntityRegisteredAddress

Has broad match

Postadress

Description:
In almost all jurisdictions, legal
entities must register a postal
address. This may or may not be
the actual address at which thelegal entity does its business - itis commonly the address of theirlawyer or accountant - but it is
the address to which formal
communications can be sent.

Description:
The postal address of aLegalentity,naturalperson or workplace.

Page 9

Guidelines for mapping core data models

3

STEPS TO CREATE MAPPINGS

3.1 Conceptual level mappings
To formally define the mapping relations, we need to distinguish between an element
and its subjects, i.e., the real-world things that are represented by the instances ofthe element.
An element of a data model is a class, a property, or an association. Classes are
realised as instances (individuals) representing a real-world physical or conceptual
thing. Classes are used to express facts about the generic characteristics of anindividual instance. Properties or associations are used to construct facts about
individuals.
To map data model A to data model B, one should proceed following the steps below:
For each element in A, find an element in B for which, potentially, there can be a relationship.
Understand the definitions of the two elements to be mapped, and use your best intuition
to find how the two sets of facts described by each of the two elements intersect:
1. If the two sets are equal, there is an exact match relation between the two elements;
2. If the two sets are not equal but they intersect,
2.1. Analyse the hierarchy between the two sets, and decide if broad or narrow match
can be used:
2.1.1. If the set of facts described by the element in A includes the set of facts
described by the element in B, then the element in A has a narrow matchthe element in B;
2.1.2. Similarly, if the set of facts described by the element in A is included in theset of facts described by the element in B, then the element in A has a broad
match the element in B;
2.2. If it the set of facts described by the element in A does not include or is not includedin the set of facts described by the element in B, decide if the intersection between
the two sets is significant:2.2.1. If the intersection is significant, the element in A has close match theelement in B;
2.2.2. If the intersection is not significant, the element in A has related matchthe element in B;
3. If the two sets do not intersect, the element in A has no match in B.
4. Provide an explanation every time when there is a special case of matching between thetwo elements, to support the development of syntax mappings and the implementationof data reconciliation procedures.

The following chapters provide some example to showcase the steps above for eachof the mapping relations.

Example for “Has exact match”
We choose the element Address (an address representing a location) from the Core
Vocabularies and the element Postadress (contact option that unambiguously
defines an actual area for mail delivery, usually linked with an indication of theaddressee or recipient, and in some cases a particular address source) from theSwedish Company data model.
We then apply the mapping algorithm:
Page 10

Guidelines for mapping core data models

1. The two elements describe the same set of facts, and therefore Address has
exact match Postadress.

Example for “Has close match”
We choose the element AddressLocatorName (the locator name is a proper noun
applied to the real world entity identified by the locator. The locator name could be
the name of the property or complex, of the building or part of the building, or it
could be the name of a room inside a building. [INSPIRE] The key difference between
a locator designator and a locator name is that the latter is a proper name and isunlikely to include digits.) in the Core Vocabularies and the element
belägenhetsadress gårdsadressområde ("Farm Address area" can be used to
specify the location or to preserve historical names. "Farm Address area" should be
used where there are names of farms, collections of buildings or a single house thatis listed on a general map and where these names are used in the address today) in
the Swedish Company data model.
We then apply the mapping algorithm:
1. The two elements describe different concepts: AddressLocatorName could be
the name of a building, room inside of a building, while belägenhetsadressgårdsadressområde describes farms or collections of buildings. Therefore, theset of facts described by the two elements are not equal.
2. The two elements describe similar facts: names of properties, buildings,
collections of buildings. Therefore, there is an intersection.
2.1. There is no hierarchy between the two sets of facts, as
AddressLocatorName can be the name of a room inside of a building, while
the belägenhetsadress gårdsadressområde refers only to the entire
buildings.
2.2. The two sets of facts described by AddressLocatorName andbelägenhetsadress gårdsadressområde can be considered as significant.
Therefore, AddressLocatorName has close match belägenhetsadressgårdsadressområde.

Example for “Has related match”
We choose the element AgentPlaysRole (a public service in which the agent plays
a role.) from the Core Vocabularies and the element Relation till person (translated
as relationship to person, or role, and described as: relationships between persons
are necessary to define the person. The “Relation till person” provides for example
information on who are the representatives of legal entities. It is also through thisinformation that the address of a CEO can be linked to the limited company he/she
represents. For example: a natural person authorized to sign for the legal entity)from the Swedish Company data model.
From the definitions of the two elements, we understand that (1) the
AgentPlaysRole describes the relationship between an agent which can be either anatural person, or an organisation and a public service for which this agent plays arole, and (2) the Relation till person describes the relationship between two
persons (natural persons or organisations).
Page 11

Guidelines for mapping core data models

We then apply the mapping algorithm:
1. It is obvious that the two elements describe sets of facts which are not equal.
2. There is an intersection between the two sets of facts, as both elements candescribe roles played by persons.
2.1. There is no hierarchy between the two sets of facts, as AgentPlaysRole
describes a public service in which the agent (organisation or natural person)plays a role, while Relation till person refers to the relationship between
two persons (physical or juridical).
2.2. Decide if the intersection between the two sets of facts described by the twoelements is significant:2.2.1. While the AgentPlaysRole describes a public role played by a person
or an organisation the, Relation till person describes the relationship(both public or private) between two persons. Therefore, the intersection
is not significant.
2.2.2. Therefore, AgentPlaysRole has related match Relation till person.

Example for “Has narrow match”
We choose LegalEntityLocation (asserting the Location relationship implies onlythat the legal entity has some connection to a location in time or space. It does not
imply that the legal entity is necessarily at that location at the time when theassertion is made) from the Core Vocabularies and Säte (the city in Sweden where
the Board (of the legal entity) will meet and where the general meeting is to be held)from the Swedish Company data model.
We then apply the mapping algorithm:
1. Obviously the two sets of facts described by LegalEntityLocation and Säte are
not equal.
2. Given the fact that LegalEntityLocation can describe cities, we can say that thetwo sets of facts intersect.
2.1. While the LegalEntityLocation describes a location which can be a city, the
Säte always describes a city as a location. Therefore, there is a hierarchy
between the two elements.
2.1.1. The set of facts described by Säte is always a set of cities wheregeneral meetings of companies are to be held. The set of facts describedby LegalEntityLocation are locations related somehow with the legal
entity. Therefore, the set of facts described by the LegalEntityLocation
can include the set of facts described by Säte (a Säte is always aLegalEntityLocation, but not every LegalEntityLocation is a Säte).
LegalEntityLocation has narrow match Säte.

Example for “Broad match”
We choose LegalEntityRegisteredAddress (in almost all jurisdictions, legal entities
must register a postal address. This may or may not be the actual address at which
the legal entity does its business - it is commonly the address of their lawyer orPage 12

Guidelines for mapping core data models

accountant - but it is the address to which formal communications can be sent) fromthe Core Vocabularies and Postadress (the postal address of a Legal entity, natural
person or workplace) from the Swedish Company data model.
We then apply the mapping algorithm:
1. The set of facts described by LegalEntityRegisteredAddress and Postadress
are not equal as Postadress can describe as well the address of natural persons
or workplaces, while LegalEntityRegisteredAddress describes the postal
address of legal entities.
2. Obviously, the set of facts described by the two concepts intersect.
2.1. The set of facts described by the LegalEntityRegisteredAddress always
describes the postal address of legal entities, while Postadress describes thepostal address not only for legal entities, but also for natural persons. Thereis a hierarchy.
2.1.1. The set of facts described by LegalEntityRegisteredAddress can’t
include the set of facts described by Postadress.
2.1.2. The set of facts described by LegalEntityRegisteredAddress can be
included in the set of facts described by Postadress (every
LegalEntityRegisteredAddress is a Postadress, but not every
Postadress is a LegalEntityRegisteredAddress). Therefore,
LegalEntityRegisteredAddress has broad match Postadress.

3.2 Syntax level mappings
The syntax level mappings enable the exchange of information between IT systems
that model semantically similar concepts, represented either with the same (e.g.
XML), or with different data formats (e.g. XML and RDF). The representation of thesyntax level mappings depends on the data formats of the source and target systemsof the data transfer procedure. For example, XSL will be the choice to express syntax
level mappings between a source representing its data as XML and a target
representing its data as XML or RDF.
The existence of conceptual level mappings is a prerequisite to create syntax levelmappings. When developing syntax level mappings, one should look not only at the
mappings relations but at the descriptions provided together with the mapping
relations. There can be information that further supports the development of syntax
level mappings and the implementation of business logic to allow data manipulation
at run time. For example, all the values of the attributes of the Postadress concept
in the Swedish Company data model could be concatenated so that they can betransferred to the Address.FullAddress of the Core Location Vocabulary, despite
the fact that at the concept level mapping the Address.FullAddress has no matchwithin the Swedish Company data model. Another example is the transfer of data
from
Identitetsbeteckningför
person.id-beteckningtoPerson.PersonDateOfBirth of the Core Person Vocabulary. It would be possible todevelop a rule at the syntax level mapping which tests for the value of id-beteckning
typ for an instance of Identitetsbeteckning för person, and when this value would
be equal to personnummer, extract the first 6 to 8 characters from the value ofPage 13

Guidelines for mapping core data models

Identitetsbeteckning för person.id-beteckning and transfer the result into the
Person.PersonDateOfBirth.
The following steps should be performed to develop syntax level mappings:
1. Choose the representation of the syntax mapping based
representations of the of the source and destination data models;

on

the

2. Follow the mappings at the conceptual level and implement transformation
rules which will receive as input the elements in the source data model andwill produce as outputs the mapped elements in the destination data model.
The transformation rules should implement the business logic described in the
spreadsheet listing the mapping relations.
There are various tools 6 available for the development of transformations between
many standard formats, including XML, RDF, JSON, etc.
XSLT 7 is a language to process and transform XML documents into other formats
such as RDF, JSON, etc.
Openrefine 8 offers powerful functionalities for developing data reconciliation rules for
multiple data formats.
The Core Data Model Mapping Directory (CDMMD) 9 publishes conceptual levelmappings between ISA Core Vocabularies and other data models such as NIEM 3.0 10,
Stelselcatalogus 11, KoSIT - XÖV 12, Swedish Company data model 13, etc.

3.3 Special cases
While creating mappings between elements of the ISA Core Vocabularies 14 and data
models from national initiatives, a few special situations have been encountered that
require a less intuitive approach for choosing the appropriate relationship. We noticed
in several cases that a high degree of subjectivity can be introduced by the one whochooses the relationships. As higher the degree of subjectivity, as higher to potential
for less consistent, core data models alignment.

6

http://www.w3.org/wiki/ConverterToRdf

7

http://www.w3.org/TR/xslt

8

http://openrefine.org/

9

http://mapping.semic.eu/

10

https://www.niem.gov/technical/Pages/version-3.aspx

11

www.stelselcatalogus.nl

12

http://www.xoev.de/de/produkte

13

http://uppgiftskrav.bolagsverket.se/gu

14

https://joinup.ec.europa.eu/asset/core_vocabularies/description

Page 14

Guidelines for mapping core data models

The special cases which are described in the following tables, were encountered while
mapping the Core Vocabularies with the Swedish Company data model 15. They are
however generic enough and it is very likely to come across them in other contexts
as well.
In each of the special situations, together with the selected mapping relation, adescription is provided to explain the reasoning behind the chosen solution. The
mapping relations and the description should provide enough information to support
the development of syntax level mappings, and the implementation of data
reconciliation procedures.
Several special cases have been identified:
1. Composite mapping. This special case deals with elements from one data
model (destination) for which a formula can be applied, and the result would
match exactly an element in the source data model. For example, the periodof time element in the Core Vocabularies matches exactly with the calculateddifference between start date and end date from the Swedish Company data
model.
2. Partial mapping. This case deals with elements of one data model (source)which can be composed by a combination of elements within the destination
data model. For example, the full address element from the Core Vocabularies
is a combination of multiple elements from the Swedish Company data model(more details, in the following chapters).
3. Conditional mapping. This special case deals with the elements of one data
model (source) which match elements of the destination data model only
when certain conditions are met. For example, the identifier of a legalorganisation in the Core Vocabularies matches the identifier of a “person” in
the Swedish Company data model, only for the instances of “person” which
are legal organisations. The Swedish Company data model uses the “person”
class to denote physical persons and juridical persons. The difference is madeby the value of the property “type of person” which can take one of two values.
4. Partial and conditional mapping. This case is a combination of bothsituations described above. For example, the birth date in the Core
Vocabularies matches exactly the first 6-8 digits extracted from the value ofthe identifier of a person in the Swedish Company data model, only when thetype of person equals with “physical person”; otherwise, the type of person
would identify a legal organisation.
The examples described in the next sections are structured as follows:
1. The column “Concepts of ISA Core Vocabularies”: lists the concepts which
potentially match one or a combination of concepts of the Swedish Company
data model;

15

http://uppgiftskrav.bolagsverket.se/gu/ConceptModel/288841c9-624f-47bb-a007-9dbd21f2675b.htm
Page 15

Guidelines for mapping core data models

2. The column “Potentially match concepts of the Swedish Company data
model”: lists the concepts of the Swedish Company data model that
potentially match the concepts of the ISA Core Vocabularies;
3. The column “Explanation”: describes how the concepts could be matched, andwhat the chosen relation was. A similar description is made available in the
spreadsheet documenting the mappings. This description should support thedevelopment of the syntax level mappings and the implementation of data
reconciliation procedures;
4. The column “The selected mapping relation”: lists the conceptual mapping
relation that was finally chosen and documented in the spreadsheet.

Composite mapping
Composite mapping describes the context in which several elements in thedestination data model can be combined according to a set of business rules (aformula can be applied) and the result matches exactly one element in the source
data model.
The existence of such context, does imply that each distinct element in thedestination data model will match another element in the source data model.
Concepts of
ISA
Core
Vocabularies

PeriodOfTime
Is defined as“An interval oftime that is
namedordefined by its
start and end
dates”.

Potentiallymatch
concepts of
the Swedish
Company
data modelNamnpå
fysisk person
namn.
namn giltigt
frånDefined
as
“name
valid
from”
Namn
på
fysisk person
namn.
namn giltigt
tillDefined
as
“name
valid
to”

Explanation

The selected
mapping relation

The set of facts described by the
PeriodOfTime
potentiallymatches the set of fats describedby the calculated difference
between, generally, a start date
and an end date. The start and end
date are properties for several of
the existing concepts in the
Swedish Company data modelsuch as namn giltigt från andnamn giltigt till.

PeriodOfTime
Has no match

Partial mapping
Partial mapping describes the context in which one element of a data model (source)
matches (no necessarily exactly) a combination of several elements in the destination
data model.

Page 16

Guidelines for mapping core data models

Concepts of
ISA
Core
Vocabularies

Address.
AddressPOB
ox

Potentiallymatch
concepts of
the Swedish
Company data
model

Postadress.
utdelningsadr
ess2

Address.
AddressFullA
ddressPostadress

Explanation

A certain sequence of charactersas part of the value of
utdelningsadress2 determines
the post box value, according toSS 61 34 01.
The set of facts described by the
AddressPOBox and the set offacts
describedbytheutdelningsadress2 will neverintersect.
The
concept
AddressFullAdress matches a
combination of attributes of the
Postadress (such as postort,
postnummer,
and
land)
concept.
But
theAddressFullAddress does notmatch close enough one single
attributeofPostadress.
Therefore, the set of facts
described
bytheAddressFullAddress does notintersect with the set of facts
described
by
any
of
the
attributes of Postadress.

The selected
mapping relation

Address.
AddressPOBox
Has no match

Address.
AddressFullAddre
ss
Has no match

Conditional mapping
Conditional mapping describes the context in which the meaning of a certain element(let’s call it EL1) in one data model depends on the value of another element (EL2)in the same data model. In such context, EL1 matches exactly one element in the
mapped data model only when EL2 has certain values.

Person.
PersonIdenti
fier

Potentiallymatch
concepts of
the Swedish
Company data
model
Identitetsbete
ckningför
personIs defined as“Aformallyissued

Is defined as “aunique identifierthat identifies a

Concepts of
ISA
Core
Vocabularies

Explanation

The selected
mapping relation

PersonIdentifier
matchesexactly
Identitetsbeteckningför
persononly
if
idbeteckning typ, which is apropertyoftheIdentitetsbeteckningför
person
has
the
value

PersonIdentifierHas broad match
Identitetsbeteckning för person

Page 17

Guidelines for mapping core data models

identifierforthe person”

particularperson”

LegalEntity.
LegalEntityL
egalIdentifier
Is defined as“The identifier
given to thelegal entity by
the authority
with which it isregistered”

Identitetsbete
ckningför
personPersonnummer. Therefore, theset of facts described by the
PersonIdentifier is equal to theset of facts described by the
Identitetsbeteckningför
person only in certain conditions.
Thus, we can say that the concept
Identitetsbeteckningför
person is more generic than
PersonIdentifier.
Similarly with the case above, thetwo concepts match, only if idbeteckning typ has one of thevaluesorganisationsnummer,
samordningsnummer, or GDnummer.
Therefore,
Identitetsbeteckningför
person is a generalisation of
LegalEntityLegalIdentifier.

LegalEntityLegal
IdentifierHas broad match
Identitetsbeteckning för person

Partial and conditional mapping
Partial and conditional mapping describes a context in which the meaning of a certain
element (EL1) in one data model depends on the value of another element (EL2) inthe same data model, but EL1 matches partially one element in the destination data
model. EL1 matches partially one element in the destination data model, means thata business rule can be applied on the value of EL1 and the result matches the elementin the destination data model.
Concepts of
ISA
Core
Vocabularies

Person.
PersonDateO
fBirthDefinedas“The date on
which
the
personwasborn”

Potentiallymatch
concepts of
the Swedish
Company data
model

The selected
mapping relation

Explanation

PersonDateOfBirth matches idbeteckning
only
if
idbeteckning typ has the value:
personnummer.
Identitetsbete
ckningför
person.
id-beteckning

When id-beteckning typ has thevalue: personnummer, then thefirst 6 or 8 digits of the value of
id-beteckning represent thedate of birth, which will be
encodedwiththeformat:yymmdd-nnnn.
Therefore,
described

the

set
by

of

Person.
PersonDateOfBirth
Has no match

facts
the
Page 18

Guidelines for mapping core data models

PersonDateOfBirthneverintersect with the set of facts
described by the id-beteckning.

Mapping relations in special cases
In all the examples of special cases described in the previous chapters, we observedthat the mapping relations do not always express the fact that by applying additional
logic to the mapping relations, we could further describe that a transfer of data ispossible between two IT systems implementing the two mapped data models. For
example, in the case of composite matching, we conclude that the PeriodOfTime
has no match in the Swedish company data model as the set of facts described by
the PeriodOfTime does not intersect with a set of facts described by any concept in
the Swedish Company data model. However, the difference between the existing
properties namn giltigt från and namn giltigt till is an exact match of the
PeriodOfTime. It could be interesting to express this kind of match. It could beinteresting to further enrich the set of mapping relations so that logic could be used
to express the relation between concepts.

Page 19

参考資料３

ツール「表からRDF」のご紹介

https://imi.ipa.go.jp/tools/0051/

1

データはあるが、どのような形式で公開するのが良いだろうか？

名前

所在地

既存のデータ構
造は変更できない

住所

氏名

データは公開しているが、十分に活用されているだろうか？

お名前

現住所

既存のシステムは変更できない。

名前

所在地

2

3

既存のデータを変更せず、コア語彙にマッピング！！
既存のデータを変更せずに地域を越えてオープンデータ
の有効活用

ic:氏名
ic:住所

名前

所在地

ic:氏名
ic:住所

お名前

現住所

既存のシステムやデータ構造を変更することなく、組織を越えて確実で円滑なデータ交換
ic:氏名
ic:住所
氏名

住所

ic:氏名
ic:住所
名前

所在地

4

データ構造の共有構造や項⽬名が異なるが、意味的に共通のデータは多い
多くの⼈が最初からデータ構造を作成するのは効率的でないだけでなく、たくさんの異なる構造ができてしまう。
 データ構造を共有して利⽤することで時間とコストを節約
•
•

場所
施設名

名称
所在地
ic:名称
ic:住所

ic:名称
ic:住所

住所
名前

なまえ
ばしょ
ic:名称
ic:住所

ic:名称
ic:住所

データ構造の検索・利⽤・カスタマイズ
5

住所などを定型化•

住所を⾃動的に分解・定型化することで、さらに使いやすいデータに

お名前

ic:⽒名

現住所

ic:住所
ic:都道府県
ic:市区町村
：
：

6

DEMO
https://imi.ipa.go.jp/tools/0051/
7

データ構造の共有
名前

所在地

名前

所在地

おところ

なまえ

そのまま利用作成
プロジェクトプロジェクト

データ構造
ic:氏名
ic:住所

データ構造
ic:氏名
ic:住所

マッピング

マッピング

「名前」 -> ic:氏名「所在地」 -> ic:住所「おところ」 -> ic:住所「なまえ」 -> ic:氏名マッピングを変更して利用8910

ツールを使⽤するにはまずはアクセス！
https://imi.ipa.go.jp/tools/0051/

11

ありがとうございました。

12