第３回DPFC勉強会,物質・材料研究機構, 2017年7月6日 あらまし：研究データを共有することは今後の研究活動において大きな意味がある。本講演では研究データの共有の役割から始まり、研究データの共有の方法について紹介する。研究データの共有においては、IDとメタデータの共有が重要である。メタデータは適切な共有語彙によって記述されることが期待される。現在、使わている様々な情報の構造化の方法を紹介して、そのなかでどのような共通語彙が適切なのかを考察する。

1. 共通語彙の構築の基本的な考え方と方法
〜研究データのために語彙・スキーマを作るには〜
武田英明
takeda@nii.ac.jp
@takechan2000
http://orcid.org/0000-0002-2909-7163
第３回DPFC勉強会,物質・材料研究機構, 2017年7月6日

2. 今回のトークに関係する私の立場
• 情報共有基盤委員会共通語彙WG主査
（IMI共通語彙基盤）
• 研究データ利活用協議会会長
• Japan Link Center (JaLC)共同運営委員長
• ORCID元理事
• KAKENなどNIIサービスへのアドバイザー的立場
• Semantic Web/Linked Open Dataの研究者

3. ドメイン語彙構築に向けて
• ゴールのイメージづくり
– どんな語彙/スキーマが欲しいのか
• 何につけるのか
• 何に使うのか
• …
– 誰が作り、維持するのか。
• 技術と既存語彙連携の選択
– ゴールに適切なものの選択
• 実装
– 個別の語彙構築
– 語彙データベース
– 語彙構築体制

4. なんで研究データ共有すんの？

5. Researcher before Digital Age
papers
data
research target
Survey Paper working
Research & Writing

6. 0101101110101101111100011110000110101010101111100011110000110101010101110101101111100011110000110
1010101011101011011101011011111000111100001101010101011111000111100001101010101011101011011111000
1111000011010101010111010110111010110111110001111000011010101010111110001111000011010101010111010
1101111100011110000110101010101111110000110101010111111100111000011010101010011010101010000110101
0101
0101101110101101111100011110000110101010101111100011110000110101010101110101101111100011110000110
1010101011101011011101011011111000111100001101010101011111000111100001101010101011101011011111000
1111000011010101010111010110111010110111110001111000011010101010111110001111000011010101010111010
1101111100011110000110101010101111110000110101010111111100111000011010101010011010101010000110101
0101
Researchers now
Data use Data publishing
Research, Writing & Data publishing
papers
data
research target
Survey Paper working

7. 0101101110101101111100011110000110101010101111100011110000110101010101110101101111100011110000110
1010101011101011011101011011111000111100001101010101011111000111100001101010101011101011011111000
1111000011010101010111010110111010110111110001111000011010101010111110001111000011010101010111010
1101111100011110000110101010101111110000110101010111111100111000011010101010011010101010000110101
0101001011011101011011111000111100001101010101011111000111100001101010101011101011011111000111100
0011010101010111010110111010110111110001111000011010101010111110001111000011010101010111010110111
1100011110000110101010101110101101110101101111100011110000110101010101111100011110000110101010101
1101011011111000111100001101010101011111100001101010101111111001110000110101010100110101010100001
1010101010
0101101110101101111100011110000110101010101111100011110000110101010101110101101111100011110000110
1010101011101011011101011011111000111100001101010101011111000111100001101010101011101011011111000
1111000011010101010111010110111010110111110001111000011010101010111110001111000011010101010111010
1101111100011110000110101010101111110000110101010111111100111000011010101010011010101010000110101
01010
0101101110101101111100011110000110101010101111100011110000110101010101110101101111100011110000110
1010101011101011011101011011111000111100001101010101011111000111100001101010101011101011011111000
1111000011010101010111010110111010110111110001111000011010101010111110001111000011010101010111010
1101111100011110000110101010101111110000110101010111111100111000011010101010011010101010000110101
01010
0101101110101101111100011110000110101010101111100011110000110101010101110101101111100011110000110
1010101011101011011101011011111000111100001101010101011111000111100001101010101011101011011111000
1111000011010101010111010110111010110111110001111000011010101010111110001111000011010101010111010
1101111100011110000110101010101111110000110101010111111100111000011010101010011010101010000110101
0101110001111000011010101010111010110111110001111000011010101010111111000011010101011111110011100
001101010101001101010101000011010101010
Researcher in Future
Data
Data use Data publishing
Integration of
papers & data
Data publishing
Research = Data Supply-chain

8. • A scholar is just a library way of making
another library
– Daniel Dennett, “Memes and the Exploitation of
Imagination”, 1990
• A scholar is just a data way of making
another data

9. Data sharing

10. Data Sharing?
or
Data Publication?
or
Open Data?

11. Data Life Cycle
• Data is created, shared, published, and archived
• But, just “published” is not enough, it should be
“openly published” (open data)
Data ShareCreate Publish Archive
Research Phase In Progress Results

12. Open Data
• “A piece of data or content is open if anyone is free
to use, reuse, and redistribute it — subject only, at
most, to the requirement to attribute and/or share-
alike.” http://opendefinition.org/
• Open data is data publication with some open
license
– Open license ensues the above condition

13. Data Life Cycle
• Different tools for different stages of life cycle
– Data sharing: generating, federating, …
– Data publishing: searching, harvesting, …
– Data archiving: migration, …
• The architecture CAN be shared
Data ShareCreate Publish Preserve
Research Phase In Progress Results
Stakeholder
Research Institute
Researcher/R. Group

14. オープンサイエンス対応 － 研究データ基盤
14
• 機関リポジトリ＋分野別リポジトリやデー
タリポジトリとも連携
• 研究者や所属機関、研究プロジェクトの情
報とも関連付けた知識ベースを形成
• 研究者による発見のプロセスをサポート
長期保存対応ストレージ領域
Cold
Storage
Cold
Storage
Cold
Storage
Hot
Storage
Hot
Storage
Hot
Storage
データ公開基盤
メタデータ集約・管理
知識ベースの構築
成果論文 研究データ
機関向け研究データ管理公開・蓄積管理・保存
検索・利用
非公開 共有 公開
• データ管理基盤における簡便な操作で研究
成果の公開が可能
• 図書館員やデータキュレータによる、メタ
データや公開レベル統計情報などの管理機
能の提供
• データ収集装置や解析用計算機とも連携
• 研究遂行中の研究データなどを共同研究者
間やラボ内で共有・管理
• 組織が提供するストレージに接続した利用
が可能
分野別
リポジトリ
海外の
研究データ
公開基盤
DOI ORCIDデータ検索基盤
for Data
for Data
直結
アクセスコントロール
実験データ
収集装置
解析用
計算機
データ管理基盤

15. Architecture of data sharing

16. FAIR Data Principles
• Findable
– F1. (meta)data are assigned a globally unique and eternally persistent identifier.
– F2. data are described with rich metadata.
– F3. (meta)data are registered or indexed in a searchable resource.
– F4. metadata specify the data identifier.
• Accessible
– A1 (meta)data are retrievable by their identifier using a standardized communications
protocol.
– A1.1 the protocol is open, free, and universally implementable.
– A1.2 the protocol allows for an authentication and authorization procedure, where necessary.
– A2 metadata are accessible, even when the data are no longer available.
• Interoperable
– I1. (meta)data use a formal, accessible, shared, and broadly applicable language for
knowledge representation.
– I2. (meta)data use vocabularies that follow FAIR principles.
– I3. (meta)data include qualified references to other (meta)data.
• Re-usable
– R1. meta(data) have a plurality of accurate and relevant attributes.
– R1.1. (meta)data are released with a clear and accessible data usage license.
– R1.2. (meta)data are associated with their provenance.
– R1.3. (meta)data meet domain-relevant community standards.
https://www.force11.org/group/fairgroup/fairprinciples

17. Repository
Architecture of data sharing
Data
Format
Metadata
Metadata Schema
Systematic Integration across the layersInteroperability on each layer
Access Control
Identifier

18. Database, Search, Maintenance
ス Description Language, Schema design, Registry, Interoperability
Continuous Development, Community of PracticeRepository
Architecture of data sharing
Data
Format
Metadata
Metadata Schema
Authentication/authorization/audit, ID federation, securityAccess Control
Organization, systems, ID federationIdentifier
Re-usableFindable InteroperableAccessible

19. Database, Search, Maintenance
ス Description Language, Schema design, Registry, Interoperability
Continuous Development, Community of PracticeRepository
Architecture of data sharing
Data
Format
Metadata
Metadata Schema
Authentication/authorization/audit, ID federation, securityAccess Control
Organization, systems, ID federationIdentifier
DataCite CrossRef JaLC Dublin Core DCAT CKAN Linked Data
Organization Schema System Technology
Coordination and Competition
Dspace Fedora Weko
DOI ORCID FundRef

20. ID (Identifier)

21. Research Activities and Related Entities
Survey
Article Writing
Data
Digital
Articles
Acquiring Data
Publishing Data
Funding agencies
Research
Institutions
affiliated
Projects
Supported
Academic Societies
Digital objects Digital objects
Topics

22. Research Activities and Related Entities
Survey
Article Writing
Data
Digital
Articles
Acquiring Data
Publishing Data
Funding agencies Projects
Research
Institutions
affiliated
Supported
Academic Societies
Digital objects Digital objects
Topics
ID
ID ID
ID
ID ID
ID
ID
IDID
ID

23. Research Activities and Related Entities
Survey
Article Writing
Acquiring Data
Publishing Data
Funding agencies Projects
affiliated
Supported
ID
ID ID
ID
ID ID
ID
ID
IDID
ID
Data
Digital
Articles
Research
Institutions
Academic Societies
Topics

24. Global Infrastructure for Scholarly
Communication
ID
ID ID
ID
ID
ID
ID
ID
IDID
ID
• ID for
– Article
– Data
– Researcher
– Institutions, affiliation
– Funding agency, funded project
– Academic society
– Topic
– …

25. Identifies for research
• A research activity is represented with a
structure of identifies
– Planned and submitted
– Organized and executed
– Concluded and evaluated
ID
ID ID
ID
ID
ID
ID
ID
IDID
ID

26. エンティティの識別子の重要性
• 全てのモノは識別可能でないといけない
• 人間は曖昧な識別子あるいは文脈があれば
識別子なしでも識別可能
• Webにおけては、文脈はないか使えない。
• なので、全てのモノに識別子を与えないとい
けない

27. 識別子のシステム
• 能力は人間の情報処理の基本能力
– 名付け：
• 人の名前、ペットの名前、いろいろなものの名前
• 数が多くなければOK
– システマティックな識別子の必要
• 大量のモノがあるとき
– 電話番号、郵便番号、パスポート番号、製造番号、ISBN
• システマティックな識別子への要求仕様
– 識別子は安定していて持続可能
– 唯一性の保証
– 識別子発行者が信頼でき持続可能

28. Webにおける識別子システム
• これまでの識別子システムの大きな差はない
• 違い
– システムを超えた利用
– 真に電子化
• Webにおける識別子システムへの要求仕様
– 識別子は安定していて持続可能 (モノがなくなっても)
– システムを超えて唯一性の保証
– 識別子に関する記述が手に入ること
• モノ経由では手に入らない！
– 識別子発行者が信頼でき持続可能

29. LODにおける解決法
• Webにおける識別子システムへの要求仕様
– 識別子は安定していて持続可能
• 個別の発行者に依存
– システムを超えて唯一性の保証
• URI
– 識別子に関する記述が手に入ること
• 参照解決可能なURI
– 識別子発行者が信頼でき持続可能
• Webがある限り

30. いつかの例
ISBN(International Standard Book Number)
• 概要
– 商用の書籍への唯一性のある番号付与
– 13 数字
• Prefix: 978 or 979 (EAN codeとの互換性のため)
• Group(言語・国別グループ): 1から5文字
• Publisher code:
• Item number:
• Check num: 1文字
– 管理方法: 2層構造
• National ISBN Agency – Publisher
• 要求仕様との整合性
– 1. (安定したID) たぶん
– 2. (唯一ID) あり、しかしURIではない
– 3. (参照解決可能) ない(amazonが代わり？)
– 4. (信頼できる発行者) あり

31. いくつかの例
DOI (Digital Object Identifier)
• 概要
– 科学に関わるデジタルオブジェクトへの識別子（多くは論文）
– An unfixed string: “prefix/suffix”
• Prefix: 出版社に割り当て
• Suffix: デジタルオブジェクトに割り当て
– 管理: 3層構造
• IDF (International DOI Foundation) – Registration Agency – 出版社
• 要求仕様との整合性
– 1. (安定したID) OK
– 2. (唯一ID) あり、URI
– 3. (参照解決可能) オブジェクトページへの誘導（しかしメタデータではない）
– 4. (信頼できる発行者)OK

32. いくつかの例
Dbpedia (識別子として)
• 概要
– A wikipedia page
– wikipedia pageの名前が識別子
• 手動で管理
– Disambiguation page
– Redirect page
• 要求仕様との整合性
– 1. (安定したID) たぶん（でも消滅、名前変更、内容変更もあり）
– 2. (唯一ID) あり、URI
– 3. (参照解決可能) メタデータ（RDF)
– 4. (信頼できる発行者)たぶん

33. 識別子間の関係
• 複数の識別子システムの共存
– カバー範囲の違い
– 観点の違い
 一つのモノが複数の識別子をもちうる
 異なる識別子システムの識別子間のマッピングが必要
 方法：特殊なプロパティ
 owl:sameAs, (rdfs:seeAlso, skos:exactMatch)
 http://sameas.org
 問題
 どうやって関係を発見するか
 owl:sameAsによる論理的不整合
 メンテナンス

34. 識別子のまとめ
• 識別子はデータ共有/公開のコア
– データの手に入りやすさ Data availability
– データの一貫性 Data inconsistency
– データの相互運用性 Data interoperability
• よい識別子システムを構築することは信頼で
き持続可能なデータ共有/公開をつくることに
つながる

35. スキーマあるいは情報構造化

36. 情報を構造化する
• 多様な情報構造化のレベル
– キーワード、タグ Keywords, tags
• 特徴を示すような自由に選んだ語、語句
– 統制語彙 Controlled vocabulary
• 語、規定された語句の集合
• 例：国名リスト、名称典拠
– 分類 Classification
• エンティティを分類するシステム。多くは階層的。分類は意味を持たないことも
– タキソノミー Taxonomy
• 分類のための階層的用語の体系。上位下位は通常は一般特殊関係
• 例：議会図書館件名標目
– シソーラスThesaurus
• 意味の体系。タキソノミーより多くの関係: (hypersym, hyposym), synonym,
antonym, homonym, holonym, meronym
– スキーマ Scheme
• 個別の概念の構造的な記述を定義
– オントロジー Ontology
• 概念の体系。語句ではなくて概念が要素。もっと多くの関係。概念の定義
分類志向
構造志向
キーワード、
タグ
統制語彙
分類
タキソノミー
シソーラス
オントロジースキーマ

37. 図書館学での例
• 図書館コミュニティは先駆者
• 分類 Classification
– Universal Decimal Classification (UDC)
• 統制語彙 Controlled Vocabulary
– 人名、組織、場所に関する典拠authority
• Library of Congress : 8百万, MADS &SKOS
• British Library: 2.6 百万, foaf & BIO (A vocabulary for biographical
information)
• 国立国会図書館: 1百万, foaf
• Deutsche Nationalbibliothek (DNB, Germany): 1.8 & 1.3百万 (人名 & 組織),
• Virtual International Authority File (VIAF): 4百万
• タキソノミー Taxonomy
– 件名標目 Subject Heading: LC, NDL,
• Library of Congress: MADS &SKOS
• British Library:
• National Diet Library (Japan): 0.1 百万, SKOS
• Deutsche Nationalbibliothek (DNB, Germany): 0.16 百万

40. UDC as Linked DataUDC ELEMENT DEFINITION SKOS TERM UDC
SUBPROPERTY
UDC number (notation) UDC notation is combination of symbols (numerals, signs and letters) that represent a class, its
position in the hierarchy and its relation to other classes. Notation is a language-independent
indexing term that enables mechanical sorting and filing of subjects. Also called 'UDC number'
and 'UDC classmark'
skos:notation ---
class identifier (URI) A unique identifier assigned to each UDC class. It identifies the relationship between a class'
meaning and its notational representation
skos:Concept ---
broader class (URI) Superordinate class: the class hierarchically above the class in question skos:broader ---
caption Verbal description of the class content skos:prefLabel ---
including note Extension of the caption containing verbal examples of the class content (usually a selection of
important terms that do not appear in the subdivision)
skos:note udc:includingN
ote
application note Instructions for number building, further extension and specification of the class skos:note udc:application
Note
scope note Note explaining the extent and the meaning of a UDC class. Used to resolve disambiguation or
to distinguish this class from other similar classes
skos:scopeNot
e
---
examples Examples of combination are used to illustrate UDC class building i.e. complex subject
statements
skos:example ---
see also reference Indication of conceptual relationship between UDC classes from different hierarchies skos:related ---
<skos:Concept rdf:about="http://udcdata.info/025553">
<skos:inScheme rdf:resource="http://udcdata.info/udc-schema"/>
<skos:broader rdf:resource="http://udcdata.info/025461"/>
<skos:notation rdf:datatype="http://udcdata.info/UDCnotation">510
<skos:prefLabel xml:lang="en">Mathematical logic</skos:prefLa
<skos:prefLabel xml:lang="ja">記号論理学</skos:prefLabel>
<skos:related rdf:resource="http://udcdata.info/000016"/>
http://udcdata.info/
69,000 records
40 Languages

41. http://id.loc.gov/authorities/names/n79084664.html<http://id.loc.gov/authorities/names/n79084664>
<http://www.w3.org/1999/02/22-rdf-syntax-
ns#type>
<http://www.loc.gov/mads/rdf/v1#PersonalName
> .
<http://id.loc.gov/authorities/names/n79084664>
<http://www.w3.org/1999/02/22-rdf-syntax-
ns#type>
<http://www.loc.gov/mads/rdf/v1#Authority> .
<http://id.loc.gov/authorities/names/n79084664>
<http://www.loc.gov/mads/rdf/v1#authoritativeLa
bel>
"Natsume, Sōseki, 1867-1916"@en .
<http://id.loc.gov/authorities/names/n79084664>
<http://www.loc.gov/mads/rdf/v1#elementList>
_:bnode7authoritiesnamesn79084664 .
_:bnode7authoritiesnamesn79084664
<http://www.w3.org/1999/02/22-rdf-syntax-
ns#first> _:bnode8authoritiesnamesn79084664 .
_:bnode7authoritiesnamesn79084664
<http://www.w3.org/1999/02/22-rdf-syntax-
ns#rest> _:bnode010 .
_:bnode8authoritiesnamesn79084664
<http://www.w3.org/1999/02/22-rdf-syntax-

42. http://id.loc.gov/authorities/subjects/sh85008180.html

43. http://data.bnf.fr/11932084/intelligence_artificielle/

44. 例：生物種とタクソン
• 概要
– 生物種とタクソンの名前 (kingdom, divison, class, order, family, tribe,
genus)
– 文字列
• 種は二名法
• 領域毎の学界がタクソン名を管理
– E.g., Papilo xuthus (Asian Swallowtail, ナミアゲハ,호랑나비)
• （IDとしてみたときの）要求仕様との整合性
– 1. (安定したID) たぶん（でも消滅、名前変更、内容変更もあり）
– 2. (唯一ID) 概ねあるが、実はそれほどない
– 3. (参照解決可能) ない。
– 4. (信頼できる発行者)たぶん

45. 分類群 Taxon
植物
Plants
藻類
Algae
菌類
Fungi
動物
Animals
ドメイン Domain
界 Kingdom
門 Division/Phylum -phyta -phyta -mycota
亜門 Subdivision/Subphylum -phytina -phytina -mycotina
綱 Class -opsida -phyceae -mycetes
亜綱 Subclass -idae -phycidae -mycetidae
目 Order -ales -ales -ales
亜目 Suborder -ineae -ineae -ineae
上科 Superfamily -acea -acea -acea -oidea
科 Family -aceae -aceae -aceae -idae
亜科 Subfamily -oideae -oideae -oideae -inae
族/連 Tribe -eae -eae -eae -ini
亜族/亜連 Subtribe -inae -inae -inae -ina
属 Genus
亜属 Subgenus
種 Species
亜種 Subspecies

46. CIDOC CRM
(CIDOC object-oriented Conceptual Reference Model)
• 文化遺産(cultural heritage)ドキュメンテーション
で使われる概念を記述するための構造を定義す
るもの
• International Council of Museums (ICOM) ICOM
International Committee for documentation
(CIDOC)
• RDF-based Ontology
– 86 classes, 139 properties
Over 300 page documentation!
• ISO 21127:2006
http://www.cidoc-crm.org/

47. CIDOC CRM
http://www.cidoc-crm.org/

48. 139 properties
http://www.cidoc-crm.org/

49. CIDOC CRM
P102 has title (is title of): E35 Title
P1 is identified by (identifies): E41 Appellation
P137 exemplifies (is exemplified by): E55 Type
P2 has type (is type of): E55 Type
P56 bears feature (is found on): E26 Physical Feature
P59 has section (is located on or within): E53 Place
P65 shows visual item (is shown by): E36 Visual Item
P58 has section definition (defines section): E46 Section Definition
P46 is composed of (forms part of): E18 Physical Thing
P45 consists of (is incorporated in): E57 Material
P57 has number of parts: E60 Number
P128 carries (is carried by): E90 Symbolic Object
P49 has former or current keeper (is former or current keeper of): E39 Actor
P50 has current keeper (is current keeper of): E39 Actor
P51 has former or current owner (is former or current owner of): E39 Actor
P52 has current owner (is current owner of): E39 Actor
P105 right held by (has right on): E39 Actor
P104 is subject to (applies to): E30 Right
P44 has condition (is condition of): E3 Condition State
P53 has former or current location (is former or current location of): E53 Place
P55 has current location (currently holds): E53 Place
E22 Man-Made Object
Subclass of: E19 Physical Object, E24 Physical Man-Made Thing
Superclass of: E84 Information Carrier
Properties
P54 has current permanent location (is current permanent locatio
P62 depicts (is depicted by): E1 CRM Entity
P130 shows features of (features are also found on): E70 Thing
P43 has dimension (is dimension of): E54 Dimension
P44 has condition (is condition of): E3 Condition State
P48 has preferred identifier (is preferred identifier of): E42 Identif
P49 has former or current keeper (is former or current keeper of)
P50 has current keeper (is current keeper of): E39 Actor
P51 has former or current owner (is former or current owner of):
P52 has current owner (is current owner of): E39 Actor
P53 has former or current location (is former or current location o
P55 has current location (currently holds): E53 Place
P56 bears feature (is found on): E26 Physical Feature
P59 has section (is located on or within): E53 Place
P62 depicts (is depicted by): E1 CRM Entity
P105 right held by (has right on): E39 Actor
P54 has current permanent location (is current permanent locatio
P3 has note: E62 String
P101 had as general use (was use of): E55 Type
P103 was intended for (was intention of): E55 Type
http://www.cidoc-crm.org/

52. SWEET Ontologies
• Semantic Web for Earth
and Environmental
Terminology (SWEET)
• Ontologies
– 6,000 concepts
– 200 separate ontologies

55. DataCube
Dimension C
Dimension B
Dimension A
Dimension A2
Dimension B1
Dimension C3
Observation
Measure m1, m2, …
Attribute a1, a2, …
Cube

57. eg:dataset-le1 a qb:DataSet;
rdfs:label "Life expectancy"@en;
rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
qb:structure eg:dsd-le ;
.
eg:o1 a qb:Observation;
qb:dataSet eg:dataset-le1 ;
eg:refArea ex-geo:newport_00pr ;
eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
eg:lifeExpectancy 76.7 ;
.
eg:o2 a qb:Observation;
qb:dataSet eg:dataset-le1 ;
eg:refArea ex-geo:cardiff_00pt ;
eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
eg:lifeExpectancy 78.7 ;
.
eg:o3 a qb:Observation;
qb:dataSet eg:dataset-le1 ;
eg:refArea ex-geo:monmouthshire_00pp ;
eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
eg:lifeExpectancy 76.6 ;
.

58. スキーマ・語彙
• クラス/概念の記述
– オントロジーにおける概念定義
– 関係データベースのテーブルのスキーマ
– オブジェクト指向プログラミングにおけるオブジェクト定義
• セマンティックWebでのクラス定義
– RDFS/OWLによるクラス記述
• RDFS: 簡単なクラス定義
• OWL: 記述論理に基づく
• Linked Dataにおけるクラス定義
– 主にRDFSに基づく (例外: owl:sameAs)
– 簡単な構造 (主にプロパティー値の組)

59. LODのためのスキーマ・語彙
• スキーマ共有の重要性
– 相互運用性
– 汎用アプリケーション
• よく使われるスキーマ
– Dublin Core
– FOAF (Friend-Of-A-Friend)
– SKOS (Simple Knowledge Organization System)

60. Usage of Common Vocabularies
Prefix Namespace Used by
dc http://purl.org/dc/elements/1.1/ 66 (31.88 %)
foaf http://xmlns.com/foaf/0.1/ 55 (26.57 %)
dcterms http://purl.org/dc/terms/ 38 (18.36 %)
skos http://www.w3.org/2004/02/skos/core# 29 (14.01 %)
akt http://www.aktors.org/ontology/portal# 17 (8.21 %)
geo http://www.w3.org/2003/01/geo/wgs84_pos# 14 (6.76 %)
mo http://purl.org/ontology/mo/ 13 (6.28 %)
bibo http://purl.org/ontology/bibo/ 8 (3.86 %)
vcard http://www.w3.org/2006/vcard/ns# 6 (2.90 %)
frbr http://purl.org/vocab/frbr/core# 5 (2.42 %)
sioc http://rdfs.org/sioc/ns# 4 (1.93 %)
LDOW2011 Presentation, Christian Bizer (Freie Universität

61. (Simple) Dublin Core
• 図書館コミュニティから
• DCMI (Dublin Core Metadata
Initiative)による管理
• (Simple) Dublin Core
– たった15要素
– Simple is best
– 値域制約はない
– http://purl.org/dc/elements/1.1/
• 15 elements
– Title
– Creator
– Subject
– Description
– Publisher
– Contributor
– Date
– Type
– Format
– Identifier
– Source
– Language
– Relation
– Coverage
– Rights

62. dc terms
• Qualified Dublin Core
– 定義域と値域
– より精緻な語彙
• simple dcの拡張
Properties abstract , accessRights , accrualMethod , accrualPeriodicity , accrualPolicy , alternative , audience , available , bibliograp
hicCitation ,conformsTo , contributor , coverage , created , creator , date , dateAccepted , dateCopyrighted , dateSubmit
ted , description ,educationLevel , extent , format , hasFormat , hasPart , hasVersion , identifier , instructionalMethod , i
sFormatOf , isPartOf , isReferencedBy ,isReplacedBy , isRequiredBy , issued , isVersionOf , language , license , mediator ,
medium , modified , provenance , publisher , references ,relation , replaces , requires , rights , rightsHolder , source , sp
atial , subject , tableOfContents , temporal , title , type , valid
Properties in the
/elements/1.1/namespace
contributor , coverage , creator , date , description , format , identifier , language , publisher , relation , rights , source , s
ubject , title , type
Vocabulary Encoding Schemes DCMIType , DDC , IMT , LCC , LCSH , MESH , NLM , TGN , UDC
Syntax Encoding Schemes Box , ISO3166 , ISO639-2 , ISO639-3 , Period , Point , RFC1766 , RFC3066 , RFC4646 , RFC5646 , URI , W3CDTF
Classes Agent , AgentClass , BibliographicResource , FileFormat , Frequency , Jurisdiction , LicenseDocument , LinguisticSystem ,
Location ,LocationPeriodOrJurisdiction , MediaType , MediaTypeOrExtent , MethodOfAccrual , MethodOfInstruction , Pe
riodOfTime , PhysicalMedium ,PhysicalResource , Policy , ProvenanceStatement , RightsStatement , SizeOrDuration , Sta
ndard
DCMI Type Vocabulary Collection , Dataset , Event , Image , InteractiveResource , MovingImage , PhysicalObject , Service , Software , Sound , Sti
llImage , Text
Terms related to the DCMI
Abstract Model
memberOf , VocabularyEncodingScheme

63. Dcterms subPropertyOf Domain Range
contributor dc:contributor rdfs:Resource dcterms:Agent
creator
dc:creator,
dcterms:contributor
rdfs:Resource dcterms:Agent
coverage dc:coverage rdfs:Resource
dcterms:LocationPeriodOr
Jurisdiction
spatial
dc:coverage,
dcterms:coverage
rdfs:Resource dcterms:Location
Temporal
dc:coverage,
dcterms:coverage
rdfs:Resource dcterms:PeriodOfTime
Date dc:date rdfs:Resource rdfs:Literal
Available dc:date, dcterms:date rdfs:Resource rdfs:Literal
Created dc:date, dcterms:date rdfs:Resource rdfs:Literal
dateAccepted dc:date, dcterms:date rdfs:Resource rdfs:Literal
dateCopyrighted dc:date, dcterms:date rdfs:Resource rdfs:Literal
dateSubmitted dc:date, dcterms:date rdfs:Resource rdfs:Literal
Issued dc:date, dcterms:date rdfs:Resource rdfs:Literal
Modified dc:date, dcterms:date rdfs:Resource rdfs:Literal
Valid dc:date, dcterms:date rdfs:Resource rdfs:Literal
description dc:description rdfs:Resource rdfs:Resource
Abstract
dc:description,
dcterms:description
rdfs:Resource rdfs:Resource
tableOfContents
dc:description,
dcterms:description
rdfs:Resource rdfs:Resource
format dc:format rdfs:Resource
dcterms:MediaTypeOrExte
nt
extent dc:format, dcterms:format rdfs:Resource dcterms:SizeOrDuration
Medium dc:format, dcterms:format
dcterms:PhysicalR
esource
dcterms:PhysicalMedium
Identifier dc:identifier rdfs:Resource rdfs:Literal
bibliographicCitat
ion
dc:identifier,
dcterms:identifier
dcterms:Bibliograp
hicResource
rdfs:Literal
Language dc:language rdfs:Resource dcterms:LinguisticSystem
Publisher dc:publisher rdfs:Resource dcterms:Agent
Relation dc:relation rdfs:Resource rdfs:Resource
source dc:source, dcterms:relation rdfs:Resource rdfs:Resource
Dcterms subPropertyOf Domain Range
conformsTo dc:relation, dcterms:relation rdfs:Resource dcterms:Standard
hasFormat dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
hasPart dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
hasVersion dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
isFormatOf dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
isPartOf dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
isReferencedBy dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
isReplacedBy dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
isRequiredBy dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
isVersionOf dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
References dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
Replaces dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
Requires dc:relation, dcterms:relation rdfs:Resource rdfs:Resource
Rights dc:rights rdfs:Resource dcterms:RightsStatement
accessRights dc:rights, dcterms:rights rdfs:Resource dcterms:RightsStatement
License dc:rights, dcterms:rights rdfs:Resource dcterms:LicenseDocument
Subject dc:subject rdfs:Resource rdfs:Resource
title dc:title rdfs:Resource rdfs:Resourcerdfs:Literal
alternative dc:title, dcterms:title rdfs:Resource rdfs:Resourcerdfs:Literal
type dc:type rdfs:Resource rdfs:Class
audience rdfs:Resource dcterms:AgentClass
educationLevel dcterms:audience rdfs:Resource dcterms:AgentClass
mediator dcterms:audience rdfs:Resource dcterms:AgentClass
accrualMethod
dcmitype:Collec
tion
dcterms:MethodOfAccrual
accrualPeriodicity
dcmitype:Collec
tion
dcterms:Frequency
accrualPolicy
dcmitype:Collec
tion
dcterms:Policy
instructionalMethod rdfs:Resource dcterms:MethodOfInstructio
provenance rdfs:Resource dcterms:ProvenanceStatem
rightsHolder rdfs:Resource dcterms:Agent
http://dublincore.org/documents/dcmi-terms/

64. The Friend of a Friend (FOAF)
• 人と人の関係のメタデータ
• 自主的なプロジェクト
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<#JW>
a foaf:Person ;
foaf:name "Jimmy Wales" ;
foaf:mbox <mailto:jwales@bomis.com> ;
foaf:homepage <http://www.jimmywales.com/> ;
foaf:nick "Jimbo" ;
foaf:depiction
<http://www.jimmywales.com/aus_img_small.jpg> ;
foaf:interest <http://www.wikimedia.org> ;
foaf:knows [
a foaf:Person ;
foaf:name "Angela Beesley"
] .
<http://www.wikimedia.org>
rdfs:label "Wikipedia" .
Classes:
| Agent | Document | Group | Image | LabelProperty |
OnlineAccount | OnlineChatAccount |
OnlineEcommerceAccount | OnlineGamingAccount |
Organization | Person | PersonalProfileDocument |
Project |
Properties:
| account | accountName | accountServiceHomepage |
age | aimChatID | based_near | birthday | currentProject
| depiction | depicts | dnaChecksum | familyName |
family_name | firstName | focus | fundedBy | geekcode |
gender | givenName | givenname | holdsAccount |
homepage | icqChatID | img | interest | isPrimaryTopicOf
| jabberID | knows | lastName | logo | made | maker |
mbox | mbox_sha1sum | member | membershipClass |
msnChatID | myersBriggs | name | nick | openid | page |
pastProject | phone | plan | primaryTopic | publications |
schoolHomepage | sha1 | skypeID | status | surname |
theme | thumbnail | tipjar | title | topic | topic_interest |

65. SKOS (Simple Knowledge Organization
System)
• タキソノミーに関するメタデータ
– 概念の階層的構造
• 件名標目のようなタキソノミーにために設計
• 上位下位関係はクラス・サブクラス関係とは一致しな
い
• W3C Recommendation 18 August 2009

66. SKOS (Simple Knowledge Organization
System)
• SKOS Core (hierarchical concept structure)
– skos:semanticRelation
– skos:broaderTransitive
– skos:narrowerTransitive
– skos:broader
– skos:narrower
– skos:related
– skos:preflabel
– skos:altlabel
– skos:hiddenlabel
subPropertyOf

67. SKOS (Simple Knowledge Organization
System)
• SKOS Mapping
– skos:mappingRelation
– skos:closeMatch
– skos:exactMatch
– skos:broadMatch
– skos:narrowMatch
– skos:relatedMatch
subPropertyOf

68. 書誌・研究データ用スキーマ
• DOIのRA(Registration Agency)はそれぞれ独
自のメタデータスキーマを定義して、このス
キーマとURLをデータベースに登録する。
– Crossref
– DataCite
– JaLC

69. {
"status": "ok",
"message-type": "work",
"message-version": "1.0.0",
"message": {
"indexed": {
"date-parts": [
[
2017,
5,
24
]
],
"date-time": "2017-05-24T19:35:01Z",
"timestamp": 1495654501696
},
"publisher-location": "Cham",
"reference-count": 0,
"publisher": "Springer International Publishing",
"license": [
{
"URL": "http://www.springer.com/tdm",
"start": {
"date-parts": [
[
2016,
1,
1
]
],
"date-time": "2016-01-01T00:00:00Z",
"timestamp": 1451606400000
},
"delay-in-days": 0,
"content-version": "vor"
}
],
"content-domain": {
"domain": [],
"crossmark-restriction": false
},
"short-container-title": [],
"published-print": {
"date-parts": [
[
2016
]
]
},
"DOI": "10.1007/978-3-319-31676-5_2",
"type": "book-chapter",
"created": {
"date-parts": [
[
2016,
3,
19
]
],
"date-time": "2016-03-19T07:58:58Z",
"timestamp": 1458374338000
},
"page": "23-39",
"source": "Crossref",
"is-referenced-by-count": 0,
"title": [
"RDF Graph Visualization by Interpreting Linked Data as
Knowledge"
],
"prefix": "10.1007",
"author": [
{
"given": "Rathachai",
"family": "Chawuthai",
"affiliation": []
},
{
"given": "Hideaki",
"family": "Takeda",
"affiliation": []
}
],
"member": "297",
"published-online": {
"date-parts": [
[
2016,
3,
20
]
]
},
"container-title": [
"Semantic Technology",
"Lecture Notes in Computer Science"
],
"original-title": [],
"deposited": {
"date-parts": [
[
2016,
3,
19
]
],
"date-time": "2016-03-19T07:59:00Z",
"timestamp": 1458374340000
},
"score": 1.0,
"subtitle": [],
"short-title": [],
"issued": {
"date-parts": [
[
2016
]
]
},
"ISBN": [
"978-3-319-31675-8",
"978-3-319-31676-5"
],
"references-count": 0,
"URL": "http://dx.doi.org/10.1007/978-3-319-3
"relation": null,
"ISSN": [
"0302-9743",
"1611-3349"
],
Crossrefメタデータの例

71. JaLCのメタデータ・スキーマ

72. DataCiteのメタデータ・
スキーマ
http://doi.org/10.5438/0012

73. 行政系の語彙・スキーマ

74. 共通語彙基盤の推進
• 情報を正しく効率的に交換、活用していくためには、人名、住所、物
等、データを体系的、かつ、構造的に定義して行く必要がある。
74
検索
オープンデータ
システム連携
三鷹市立第四小学校
ic:建物_所在
ic:場所_地名
ic:場所_地理識別子
ic:場所_住所
ic:住所_住所
東京都三鷹市下連雀１
丁目２５−１
ic:住所_構造化住所
ic:構造化住所_国
ic:構造化住所_都道府県 東京都
ic:構造化住所_市区町村 三鷹市
ic:構造化住所_町名 下連雀
ic:構造化住所_街区符号 1
ic:構造化住所_住居番号 25
ic:構造化住所_地番 1
ic:構造化住所_方書
ic:方書_方書
ic:方書_ビル名
ic:方書_部屋番号
ic:構造化住所_郵便番号 181-0013
ic:構造化住所_住所ID
ic:構造化住所_住所コード
ic:場所_経緯度座標
ic:経緯度座標系_測地系コード
ic:経緯度座標系_緯度
ic:緯度_度
ic:緯度_分
ic:緯度_秒
ic:経緯度座標系_経度
ic:経度_度
ic:経度_分
ic:経度_秒
ic:場所_UTM座標
ic:UTM座標系_UTM座標
ic:UTM座標系_UTM測地系ID
ic:UTM座標系_東距
ic:UTM座標系_グリッドゾーンID
ic:UTM座標系_グリッドゾーン格子 ID
ic:UTM座標系_北距
ic:場所_MGRS座標
ic:MGRS座標系_MGRS座標
ic:MGRS座標系_MGRS座標格子ID
ic:建物_施設情報
ic:施設_ID
ic:証明_識別ID
ic:証明_証明種類
ic:証明_発行日
ic:証明_失効日
ic:証明_発行者
ic:施設_名称 三鷹市立第四小学校
ic:施設_種別 小学校
ic:施設_商用区分
ic:施設_概要
小・中一貫教育校「連
雀学園」に属する小学
校。
項目名（Type/Sub-properties） 項目名（エントリー名） 英語名 データタイプ データタイプ（英語） cardinality 項目説明 項目説明（英語） サンプル値 Mapping to NIEM Mapping to ISA Joinup
人型 ic:人型 PersonType 人の情報を表現するためのデータ型。 nc:PersonType Person
氏名 ic:人_氏名 PersonName ic:氏名型 ic:PersonNameType 0..1 氏名 Name of a Person - nc:PersonName
性別 ic:人_性別 PersonSex <抽象要素> <abstract element, no type> 0..1 性別 Gender of a Person 1 nc:PersonSex gender
Substitutable Elements: Substitutable Elements:
性別コード ic:人_性別コード + PersonSexCode codes:性別コード型 codes:GenderCodeType 性別コード Gender of a Person 1 nc:PersonSexCode
性別名 ic:人_性別名 + PersonSexText ic:テキスト型 ic:TextType 性別の名称。 Gender of a Person 男 nc:PersonSexText
生年月日 ic:人_生年月日 BirthDate ic:日付型 ic:DateType 0..1 生年月日 Date of Birth of a Person - nc:PersonBirthDate dateOfBirth
死亡年月日 ic:人_死亡年月日 DeathDate ic:日付型 ic:DateType 0..1 死亡年月日 Date of Death of a Person - nc:PersonDeathDate dateOfDeath
現住所 ic:人_現住所 PresentAddress ic:住所型 ic:AddressType 0..1 現住所 - nc:PersonResidenceAssociationTyperesidency
本籍 ic:人_本籍 LegalResidence ic:住所型 ic:AddressType 0..1 本籍 -
国籍 ic:人_国籍 Citizenship <抽象要素> <abstract element, no type> 0..n 国籍
A county that assigns rights, duties, and privileges to a person because of
the birth or naturalization of the person in that country.
- nc:PersonCitizenship citizenship
Substitutable Elements: Substitutable Elements:
国籍名 ic:人_国籍名 + CitizenshipText ic:テキスト型 ic:TextType 国籍の名称。
A county that assigns rights, duties, and privileges to a person because of
the birth or naturalization of the person in that country.
日本国 nc:PersonCitizenshipText
国籍コード ic:人_国籍コード + CitizenshipCode codes:国籍コード型 codes:CitizenshipCodeType 住民基本台帳で利用されている国籍コード。
A county that assigns rights, duties, and privileges to a person because of
the birth or naturalization of the person in that country.
392 nc:PersonCitizenshipFIPS10-4Code
ISO3166Alpha2 ic:人_ISO3166Alpha2 + ISO3166Alpha2 iso_3166:ISO3166Alpha2CodeTypeiso_3166:ISO3166Alpha2CodeType 国名コード。ISO3166Alpha2。2文字コード。
A county that assigns rights, duties, and privileges to a person because of
the birth or naturalization of the person in that country.
nc:PersonCitizenshipISO3166Alpha2Code
ISO3166Alpha3 ic:人_ISO3166Alpha3 + ISO3166Alpha3 iso_3166:ISO3166Alpha3CodeTypeiso_3166:ISO3166Alpha3CodeType 国名コード。ISO3166Alpha3。3文字コード。
A county that assigns rights, duties, and privileges to a person because of
the birth or naturalization of the person in that country.
nc:PersonCitizenshipISO3166Alpha3Code
ISO3166Numeriｃ ic:人_ISO3166Numeriｃ + ISO3166Numeric iso_3166:ISO3166NumeriｃCodeTypeiso_3166:ISO3166NumeriｃCodeType 国名コード。ISO3166Numeric。数字3桁コード。
A county that assigns rights, duties, and privileges to a person because of
the birth or naturalization of the person in that country.
nc:PersonCitizenshipISO3166NumericCode
出生国 ic:人_出生国 BirthCountry ic:場所型 ic:LocationType 0..1 生まれた国。 A location where a person was born. nc:PersonBirthLocation countryOfBirth
出生地 ic:人_出生地 BirthPlace ic:場所型 ic:LocationType 0..1 生まれた場所。 A location where a person was born. nc:PersonBirthLocation placeOfBirth
氏名型 ic:氏名型 PersonNameType 氏名を表現するためのデータ型。 nc:PersonNameType
姓名 ic:氏名_姓名 FullName ic:テキスト型 ic:TextType 0..1 氏名（姓、名）。 Full name of a Person 経済 太郎 nc:PersonFullName fullName
カナ姓名 ic:氏名_カナ姓名 KanaFullName ic:カタカナテキスト型 ic:TextType 0..1 氏名（姓、名）のカナ表記。 Full name in Katakana. ケイザイタロウ
ローマ字姓名 ic:氏名_ローマ字姓名 RomanFullName ic:テキスト型 ic:TextType 0..1 氏名（姓、名）のローマ字表記。 Full name in Roman alphabet. Keizai Taro
姓 ic:氏名_姓 FamilyName ic:テキスト型 ic:TextType 0..1 姓。 Family name of a Person 経済 nc:PersonSurName familyName
カナ姓 ic:氏名_カナ姓 KanaFamilyName ic:カタカナテキスト型 ic:TextType 0..1 姓のカナ表記。 Family name in Katakana. ケイザイ
ローマ字姓 ic:氏名_ローマ字姓 RomanFamilyName ic:テキスト型 ic:TextType 0..1 姓のローマ表記。 Family name in Roman alphabet.
名 ic:氏名_名 GivenName ic:テキスト型 ic:TextType 0..1 名。 Given name of a Person 太郎 nc:PersonGivenName given name
カナ名 ic:氏名_カナ名 KanaGivenName ic:カタカナテキスト型 ic:TextType 0..1 名のカナ表記。 Given name in Katakana. タロウ
ローマ字名 ic:氏名_ローマ字名 RomanGivenName ic:テキスト型 ic:TextType 0..1 名のローマ字表記。 Given name in Roman alphabet.
ミドルネーム ic:氏名_ミドルネーム MiddleName ic:テキスト型 ic:TextType 0..1 ミドルネーム。 Middle name of a person nc:PersonMiddleName alternativeName
カナミドルネーム ic:氏名_カナミドルネーム KanaMiddleName ic:カタカナテキスト型 ic:TextType 0..1 ミドルネームのカナ表記。 Middle name in Katakana.
ローマ字ミドルネーム ic:氏名_ローマ字ミドルネーム RomanMiddleName ic:テキスト型 ic:TextType 0..1 ミドルネームのローマ字表記。 Middle name in Roman alphabet.
旧姓 ic:氏名_旧姓 MaidenName ic:テキスト型 ic:TextType 0..1 旧姓。 Maiden name. nc:PersonMaidenName birthName
カナ旧姓 ic:氏名_カナ旧姓 KanaMaidenName ic:カタカナテキスト型 ic:TextType 0..1 旧姓のカナ表記。 Maiden name in Katakana.
ローマ字旧姓 ic:氏名_ローマ字旧姓 RomanMaidenName ic:テキスト型 ic:TextType 0..1 旧姓のローマ字表記。 Maiden name in Roman alphabet.
語彙（ボキャブラリ）、
情報交換パッケージ（IEP)
Schema.org
検索エンジン大手が整備する
構造化データマークアップの共通仕様
情報交換パッケージに
より、システム間を連携
・高速な情報連携
・設計の効率化
語彙で意味を確認し、情報
交換パッケージから、情報
を抽出
・サービス設計の効率化
・安定した情報連携
語彙間の整理をしておくこ
とで、検索を効果的に実施
・検索の利便性の向上
・効果的な広報の実施
共通語彙基盤は、用語の参照辞書を整備するこ
とで、各種データの同一性の確認を容易にし、そ
の結果として、システム間の連携やオープン
データの活用を容易にできるようにする仕組み。
http://goikiban.ipa.go.jp/
（IMI: Infrastructure for Multi-layer Interoperability）

75. IMI共通語彙とは
• 構造化概念辞書
– 概念辞書
• 概念の表記としての用語
– 各項目は概念であって用語でない。
– 構造化辞書
• 概念は相互につながっていて、その組み合わせ（構造で意味を表現する
人型
氏名
性別
性別コード
生年月日
住所
…
氏名型
種別
姓名
姓
名
…
住所型
種別
表記
郵便番号
都道府県
文字列
文字列
文字列
コード型
文字列
文字列
文字列
文字列
文字列
コード型
種別
値
氏名型
住所型
コードリスト型
文字列
事象型 クラス概念
プロパティ（関係概念）
クラス概念の構造
クラス概念の表記
プロパティの値の範囲

76. 語彙のカテゴリー
• IMI語彙は、共有範囲の広さに応じて３つの
カテゴリーに分類される。
コア語彙
ドメイン語彙
応用語彙
コア語彙
人や組織など、基本となる用
語の集合です。ドメインを問わ
ず共有されます。
ドメイン語彙
特定の分野（ドメイン）に特化し
た用語の集合です。
ドメイン内で共有されます。
応用語彙
特定のデータに特化した用語
の集合です。
共有を前提としません。

77. 情報構造のイメージ
• 施設の情報は、コアのボキャブラリとドメインのボキャブラリ
の組み合わせで表す。
77
病院
建物
診療科
所在（住所）
施設情報
建築物情報
状況
ベッド数
小学校
建物
生徒数
所在（住所）
施設情報
建築物情報
避難所情報コア
ボキャブラリ
ドメイン
ボキャブラリ
イベント
建物
スケジュール
所在（住所）
連絡先

78. コア語彙
78

79. クラス用語の継承
クラス用語の継承の例

80. クラス用語の継承
- プロパティの引継ぎ -
• 継承して作成されたクラス用語は、継承元
のクラス用語のすべてのプロパティを引き
継ぎます。
• 継承したクラス用語では、プロパティを追加
することができます。
法人型
業務組織型
業務組織型で追加され
たプロパティ
組織型のプロパティ
実体型のプロパティ
事物型のプロパティ
業務組織型のプロパ
ティ
組織型のプロパティ
実体型のプロパティ
事物型のプロパティ
法人型で追加されたプ
ロパティ
プロパティを
引継ぐ

81. シリアライズ
IMI語彙
JSON-LD
コンテキスト
RDF
スキーマ
XML
スキーマ
構造化項目名
マッピング仕様
（近日公開予定）
JSON
(JSON-LD)
RDF
XML
CSVなど
の表形式

82. シリアライズ
• IMIの語彙を用いてデータを作成するために
は、具体的なデータ表現形式に適用すること
が必要です。
• これを、シリアライズと呼びます。
• シリアライズ先には、様々な形式を利用する
ことができます。
• 共通語彙基盤では、JSON、RDF、XML、そして
CSVなどへのシリアライズに必要な情報を提
供しています。

83. ひな形群
• DMD（Data Model Description）
– 法人基本情報 DMD@ja
– 法人活動情報 DMD@ja
– 施設 DMD@ja
– 避難施設 DMD@ja
– 設備 DMD@ja
– 医療機関 DMD@ja
– 氏名 DMD@ja
– イベント DMD@ja
– 住所 DMD@ja
– 組織 DMD@ja
– 地物 DMD@ja
• PD
– PD5474(観光施設に関する語彙の検討)
– PD7706(イベントに関する語彙の検討)
– PD2342(法人情報に関する語彙)
– PD1462(子育て関連施設に関する語彙の検討)
• ドキュメント化待ち
– 調達
– 制度（サービス）

84. IMI導入のメリット・デメリット
• メリット
– ユーザ企業、国・自治体
• 独自データによるロックイン回避
• 設計費用の低減
• データ解析の容易化（マッシュアップの容易化）
• 接続性の向上
• 段階的導入など拡張性の向上
– ベンダ企業・開発者
• データ設計の品質向上
• データ設計の迅速化
• 接続性の向上
• 販路の拡大
• デメリット
– ユーザ企業、国・自治体
• 書式変更への現場の理解を得るのが大変な時がある
– ベンダ企業・開発者
• 独自仕様によるロックインがしにくくなる
84

85. 現在どこまでできているのか
準備・検証
•動向調査と試行版の作成
開発・検証
•コア語彙の整備
普及
•法人やイベントなどの事例を軸に展開
•官民データ
2013.2 一次プロジェクト開始
2013.6 IMI1.01
2013.9 二次プロジェクト開始
2014.6 IMI2.0
2014.9 IMI2.1
2015.2 IMI2.2
2015.12 IMI2.3
2017.3 IMI2.4
2017.1 法人インフォーメーション
2017.1 埼玉県オープンデータポータル
2017.6 こども霞が関見学デー

86. 動き始めたＩＭＩ
• 法人インフォメーション
– 法人番号をキーに、政府内の法人関連情報
（基本情報、契約情報、表彰情報、届出情報、
処分情報等）を一元的に公開
• 法人情報データを、共通語彙基盤で整備
• 今後、法人マスターデータや申請書の設計に活
用→民間に展開
• こども霞が関見学デー
– 8月に行われる子供向け体験イベントの情報
を集約して提供
• イベントデータを、共通語彙基盤で整備
• 今後、イベントデータ構造を広く公開（現在もPDで
公開）
• 埼玉県オープンデータカタログ
– 埼玉県下５８自治体のオープンデータのデー
タ項目や構造を共通化
• 10分野を共通語彙基盤で整備
• 他自治体でも類似の取り組みが広がる
86

87. 推進のための体制
ＩＴ戦略本部
（IT総合戦略室）
情報共有基
盤委員会
共通語彙基
盤ＷＧ
利用swg 運用ｓｗｇ 技術ｓｗｇ
文字情報基
盤ＷＧ
87
協力依頼 報告
方針の検討
プロセスの検証
語彙、DMDの検証
普及
•各委員会、WGの設置主体は経
済産業省、事務局はIPA
•各WGの下には、具体的な検討
を行なうSWGを設置。
LOD専門家、XML専門家、
標準化専門家等、
国内トップの陣容
IMIパートナーズ

88. コア語彙の整備方法
• 行政システムやオープンデータなどのニーズを分解し
て「氏名」等のターゲットを選定
– アベイラビリティ以外はほぼ整備
• 既存の様々なデータ表現形態を参照する
• 意味論と抽象化によってモデル化
• スキーマやDMDの整備
• 現実との整合性を保つように表記型等も整備
– 住所は、市町村名や町名、番地等をすべてバラバラにした
いが、既存の表記が1行で書かれるものがあるため「住所
表記」という項目を定義 88

89. ひな形群の整備方法
• 主要な標準やアプリケーションのデータ構造を表で比較
• コア語彙と比較しながらモジュールを組み合わせモデル化
• 導入用のサブセットの整備
• 公開ドラフトとして公開し、意見を募集
• スキーマやDMDの整備
• Referenceモデルなので、利用者は自由に項目を選択し、時
には追加することができる
– IMIの語彙と追加語彙を明確化することでメンテナンス性が向上
する
89

90. オーサライズに関する考え方
• オーサライズ方式
– 専門家によるWGによる素案→公開→デファクトスタンダードとい
う方式
– コアの用語と実装用モデルを並行して開発
– SｔandardではなくReference Modelを提供する
– 世界各国の進め方もほぼ同じ方式
• 米国(NIEM) Core vocabulary + Information Exchange model
• 欧州(ISA) Core vocabulary + Application profile
• 日本(IMI) Core vocabulary + Data Model Description
• 理由
– 変化が速い
– 品質はプロセスと体制で担保
– 導入時のカスタマイズ範囲が大きい
戦略・方針
Model
プロモーション

91. 海外の状況• ヨーロッパ SEMIC
• 米国 NIEM
• 民間 schema.org
91
This particular release
incorporates approximately
280 new elements and 350
new types,
as well as updates to 2,300
existing elements and 230
existing types.
PUBLIC
EVENT

92. Schema.org
• Some highlighted vocabulary
– Creative works: CreativeWork, Book, Movie, MusicRecording, Recipe,
TVSeries ...
– Embedded non-text objects: AudioObject, ImageObject, VideoObject
– Event
– Health and medical types: notes on the health and medical types under
MedicalEntity.
– Organization
– Person
– Place, LocalBusiness, Restaurant ...
– Product, Offer, AggregateOffer
– Review, AggregateRating
– Action

93. Schema.org
• Web検索の高度化のためにYahoo!, Google, Yandex等
が設立。
– Webページに埋め込む/付随させるメタデータの共通化
– 対象領域：Webに出現する事物や事柄、プロセス、トラン
ザクションなど
• 構築体制
– Steering Group
• Oversight, review, approval of new release
– Community Group
• propose, discuss, prepare and review changes to schema.org
• via W3C ML, github
• 構築中のものの公開: webschema.org
– Pending.webschema.org (hosted extensionの場合）

96. schema.org extensions
• Additional schema to schema.org core schema
• Two types of extensions
– Reviewed/Hosted extensions:
• managed and reviewed by schema.org
• http://e1.schema.org for documentation, http://schema.org for namespace
• List
auto.schema.org
bib.schema.org
health-lifesci.schema.org
iot.schema.org
– External extensions: managed by managed and reviewed by other groups
• GS1 Web Vocabulary
• Features
– Add subclasses and/or properties
– Must be consistent to core
– Overlaps among extensions may occur

97. 情報構造化まとめ
• Keywords, tags/Controlled vocabulary
/Classification/Taxonomy
/Thesaurus/Ontology/Schema
– 差異は明確でないし、また重要でない
– より構造化の方向へ
– 要求仕様は識別子システムと同じ
• 安定していて持続可能
• システムを超えて唯一性の保証
• 記述が手に入ること
• 発行者が信頼でき持続可能

98. ドメイン語彙構築に向けて
• ゴールのイメージづくり
– どんな語彙/スキーマが欲しいのか
• 何につけるのか
• 何に使うのか
• …
– 誰が作り、維持するのか。
• 技術と既存語彙連携の選択
– ゴールに適切なものの選択
• 実装
– 個別の語彙構築
– 語彙データベース
– 語彙構築体制

99. まとめ
• ３つの層
– オントロジー/シソーラス/タキソノミー
(Ontology/Thesaurus/Taxonomy)
– スキーマ (Schema)
– 識別子 (Identification)
• トップダウンではない、むしろ今はボトムアップ
• それぞれの層は役割が違う
• しかし、その層の価値だけを追求するのではなく
て、よいつながりを考慮すべき