革新的な金融商品エキスパートBOT
革新的な金融知識アシスタントBOT
-
開発したチャットボットは、最新の金融オントロジー(Financial industry business ontology: FIBO)に基づいて、複雑な金融概念や市場動向をわかりやすく解説します。金融業界のプロフェッショナルも納得の精度と深さを備えています。
1.金融知識BOTの主な特徴
①精度の高い回答: FIBOに基づく体系的で信頼性のある情報を提供
②金融関連知識に特化: 市場動向、投資戦略、デリバティブ、債券、ローンなど、あらゆる金融市場に関する知識をカバー
③簡単操作: チャット形式で質問するだけで、欲しい情報がすぐに手に入る
④詳細な解説: 難しい金融用語や概念も、簡単に理解できるように丁寧に説明
⑤カスタマイズ可能: 企業や個人のニーズに合わせたカスタマイズが可能
LLMのGraph RAG<RETRIEVAL-AUGMENTED GENERATION(検索拡張生成)>にも応用可能
⑦GPT PILOT(Pythagora)(自律型AIプログラミング)にも組込み可能




5.オントロジーを使用することでGPTの回答精度が向上する理由
①体系的な知識の提供
オントロジーは特定のドメインに関する概念とそれらの関係性を体系的に整理したもので、知識の構造化が行われています。これにより、GPTは個々の知識を断片的に扱うのではなく、全体としての構造を体系的に理解し、関連性を持った情報を提供できます。
②明確な概念の定義
オントロジーには各概念の定義や属性が明確に記述されています。これにより、曖昧な表現や誤解を避け、正確で一貫性のある回答を生成できます。例えば、金融オントロジーでは「スワップ」や「デリバティブ」といった専門用語の意味や使い方が明確に定義されています。
③関連情報の効率的な検索
オントロジーを利用することで、関連する情報を効率的に検索し、適切なコンテキストで回答に組み込むことができます。例えば、ある金融商品に関する質問があった場合、その商品に関連する全ての概念や属性を迅速に把握し、包括的な回答を提供できます。
④推論能力の強化
オントロジーには論理的な関係性が含まれており、これを活用することで推論能力が強化されます。たとえば、ある金融取引のリスク評価に関する質問に対して、その取引の構造や関連リスク要因をオントロジーを基に推論し、的確なリスク評価を提供できます。
⑤専門知識の集約
オントロジーは専門家の知識を集約したものであり、その分野に特化した高品質な情報源となります。これにより、GPTは信頼性の高い情報を元に回答を生成でき、誤情報のリスクを減らすことができます。
6.FIBOとは
-
- FIBOの主要な特徴
①標準化された語彙
- FIBOは、金融業界で一般的に使用される用語や概念を標準化します。これにより、異なる組織間やシステム間でのデータの一貫性と互換性が向上します。
②広範なカバレッジ
③柔軟性と拡張性
- FIBOはモジュール構造を採用しており、必要に応じて特定の業務や用途に合わせて拡張やカスタマイズが可能です。
④規制準拠
- FIBOは、多くの国際的および地域的な規制要件に対応するよう設計されており、規制報告やコンプライアンス業務の効率化を支援します。
⑤オープン標準
- FIBOはオープン標準であり、誰でも利用可能です。これにより、広範な採用とコミュニティの参加が促進されています。
7.FIBOの利用例
①アンチマネーロンダリング・クレジットカードの不正利用
- データをさかのぼってトレースすることが容易なためトランザクションから利用者をトレース可能
トランザクションから利用者をトレース可能なため、倒産リスクを計測することが可能
③規制報告
- 国際的および地域的な規制要件に対応するためのデータの標準化と自動化を支援します。
④意思決定支援
- 経営戦略や投資判断に必要な高品質なデータと分析を提供します。
- 顧客分析(360°分析)
FIBOは、金融業界におけるデータ管理と分析の標準を確立することで、効率性、透明性、コンプライアンスを向上させるための強力なツールとなっています。




8.こんなお客様におすすめ
金融機関に最適なソリューション
- 投資銀行: 高度な金融知識を迅速に取得し、顧客対応の質を向上
- 資産運用会社: 市場動向や投資戦略に関する最新情報をリアルタイムで提供
- 商業銀行: 金融商品に関する詳細な情報を迅速に提供し、顧客満足度を向上
- 保険会社: リスク管理や商品開発のための専門知識を即座に取得
- 金融機関のIT部門: 金融知識に基づくシステム開発支援や要件定義の精度向上
9.システム開発の各ステージにおける利用シーン
①要件定義: 金融業界特有の要件を正確に定義し、プロジェクトの初期段階でのミスを削減
- 具体例: 債券取引システムの要件定義において、デュレーション計算やクーポン支払いの詳細な要件を明確化
②設計: 高度な金融ロジックを理解し、効率的かつ正確にシステム設計を行う
- 具体例: 投資戦略シミュレーションシステムの設計において、リスク管理モデルの設計を支援
③開発: FIBOを基盤にしたAIによる自動プログラム生成で、開発速度と品質を向上
- 具体例: デリバティブ取引システムの開発において、オプション価格モデルの自動生成
④テスト: 金融知識に基づくテストケースの生成と実行で、システムの品質を確保
- 具体例: 債券管理システムのテストにおいて、異常値やエッジケースに対するテストケースの生成
⑤導入・運用: 導入後の運用支援として、継続的な知識提供とアップデートを実施
- 具体例: 市場変動に応じた最新情報の提供とシステムの調整支援
10.FIBOを使った回答とそうでない回答の比較
- 質問: 「債券のデュレーションとは何ですか?」
**FIBOを使用しない回答**
- 債券のデュレーションは、債券の価格変動の感度を示す指標です。具体的には、金利が1%変動したときに債券価格がどれくらい変動するかを示します。デュレーションが高いほど、金利変動に対する債券価格の変動も大きくなります。



- https://github.com/edmcouncil/fibohttps://github.com/edmcouncil/fibo
- FIBO Viewer https://spec.edmcouncil.org/fibo/ontology
第12回 FIBOとChatGPTを利用したアプリ開発


第11回 SWAP約定のFIBOへのマッピングをやってみました!
第9回でFIBOの簡易版に関する日本語訳を掲示しましたがやはりわかりにくいのでサマリーしました。
Agreement, Autonomous Agent, Servicce, Commitment等が中心となっていますのでそれらの関係を一つの図にまとめました。
1.FIBO全体サマリー

以上のそれぞれの部品をArrowという作画ツールを使って主な関係をまとめました。FIBOの全体概要がよくわかります。

結局、契約を中心にして、契約者(Autonomous Agent)と契約によって形成されるCommitmentとで構成されているということがわかります。契約の内容はContractual Elementとして詳細が記述され、記述された内容に基づいてコミットメントが定義されることになります。
特定の金融商品に的を絞ってさらに分析を進めました。デリバティブ取引の金利SWAPです。
分析方法は
(1)ProtegeのツールOntoGrafを利用してEntityをたどる

(2)ProtegeのEntityから金利スワップの全体像を把握
たどった結果を全体像が分かるようにExcel上に再現しました。

(3)Arrowを使って簡易モデルを作成
Excelの結果をArrowを使ってFIBOの簡易モデルを作成

(4)実際のSWAP約定を上記(3)で作った簡易モデルにマッピング
Quantlibというオープンソースを利用してSWAP約定を入力するとExcel上で固定サイドと変動サイドのCashflowを生成してくれる。 それからNeo4j上で上記(2)のマッピングを基にCSVデータをNeo4JのFIBOへimport

(5)FIBOにMapping
Neo4Jのontology関数を利用すると簡単にマッピングができます。
以下です。
with [{ neoSchemaElem : "Swap", publicSchemaElem: "swap" },
{ neoSchemaElem : "swap_id",publicSchemaElem:"UniqueSwapIdentifier"},
{ neoSchemaElem : "paying_agent",publicSchemaElem:"SwapPayingParty"},
{ neoSchemaElem : "receiving_agent",publicSchemaElem:"SwapReceivingParty"},
{ neoSchemaElem : "notional_amount",publicSchemaElem:"MonetaryAmount"},
{ neoSchemaElem : "fx_business_center",publicSchemaElem:"BusinessCenter"},
{ neoSchemaElem : "fx_notional_amount",publicSchemaElem:"MonetaryAmount"},
{ neoSchemaElem : "fl_reference_ccy",publicSchemaElem:"CurrencyIdentifier"},
{ neoSchemaElem : "fl_tenor",publicSchemaElem: "CalendarPeriod"},
{ neoSchemaElem : "fl_business_center",publicSchemaElem:"BusinessCenter"},
{ neoSchemaElem : "fl_notional_amount",publicSchemaElem:"MonetaryAmount"},
{ neoSchemaElem : "fl_index_benchmark",publicSchemaElem:"InterestRateBenchmark"}
] as mappings,
"https://spec.edmcouncil.org/fibo/ontology/" AS schx
CALL n10s.nsprefixes.add("schx",schx) YIELD namespace
UNWIND mappings as m
CALL n10s.mapping.add(schx + m.publicSchemaElem,m.neoSchemaElem) YIELD schemaElement
RETURN count(schemaElement) AS mappingsDefined
以下がマッピング結果。


第10回 FIBOからナレッジグラフへ
EDMCから新しい方向性が出されて、今後はOPENFIBOと言ってFIBOをKnowledgeGraphテクノロジーを取り入れて拡張してゆくそうです。
詳細は2020/3/31に実施されたEDMCouncilのWebinerを参照ください。
https://www.youtube.com/watch?v=DmGE8ScJ--8
FIBO自体が概念的にはわかるのですが実際に応用技術として日本ではまだどの金融機関も取り入れておらず実務としてはハードルが高いと思います。
1.実用化が難しい理由:
①オントロジーが日本ではほとんど浸透していない
医療分野では一部利用されていますが金融機関では利用実績がない。
FSAなどの当局が報告様式に応用するなどの動きがないとどの金融機関も取り組みにくい。
②RDBMからデータをインポートするのが複雑
③EDMなどの協議会が勉強会をやっているものの知識の普及が遅れている
ただ、今回のKnowledgeGraphへの方向付けは大変興味深いものがあります。
2.KnowledgeGraphとは?
一言で
GraphDB=Ontology + データ(インスタンス+リレーション)
から
KnowledgeGraph=GraphDB + AI(自然言語認識など)による知識の獲得
です。
これを実現することでサイロ化されたRDBをGraphDbでインテグレートすることが可能です。
また、金融機内のすべての取引や取引先情報を統合化されたナレッジグラフに格納することによって今までリンクされることのなかった情報がいろいろな切り口で検索することが可能となります。
イメージとしては以下です。(例はNeo4J)

すべての取引がリンクされるイメージです。



3.想定される利用方法:
①回転売買などの会計不正の事前検知
・取引先のサプライチェーンが見える化されるのでキャッシュフローとリンクすることで回転売買を把握可能
②リスク管理では
・LiborがX%上昇した際にデフォルトが生じる可能性のある金利スワップ取引先
・取引先のサプライチェーンが見える化されるので、特定取引先の破綻による連鎖倒産リスク等が予知可能
③地域特性に基づいた収益予測
・集中豪雨等による被災地の売上変動のマクロ予測による収益予測
4.既に実用化段階に入っている例
例:
①EY Customer360°

顧客分析としてナレッジグラフを活用する。
データタイプの違いを吸収し、あらゆるデータソースから顧客データを取り込んで、顧客を全方位から理解するためのCustomer 360ソリューションを「銀行の頭脳」にすることが、デジタルトランスフォーメーションの要となる。
https://neo4j.com/blog/transforming-the-enterprise-ai-scale-neo4j/
②THOMSON REUTERS KNOWLEDGE GRAPH FEED CONTENT

Thomson Reutersの金融コンテンツセットのリンクされたデータフィードで、あらかじめ特定された一連の関係を持ち、データセット内およびデータセット間の以前に検出されなかった接続を発見するのに役立つ。

https://www.thomsonreuters.com/en/press-releases/2017/october/thomson-reuters-launches-first-of-its-kind-knowledge-graph-feed.html
③企業業績に影響を与えるリスク要因の分析->サプライチェーンの把握

④NttdataのiTreasure
ナレッジグラフとは言ってませんがサービスの内容からそうであると推察されます。

https://www.nttdata.com/jp/ja/lineup/itreasure/
5.FIBOのKnowledgeGraph
以下資料から抜粋しました。
https://slideplayer.com/slide/13343093/
今後の方向性について説明したものです。
説明者:David Newman
SVP, Head of Knowledge Graph Solutions, Innovation R&D Group, Wells Fargo Bank,
Chair, FIBO Program, EDM Council
①データインフラとしての機能

②AIの有効利用のための役割

③ナレッジのブリッジ


今後のFIBOの進展に期待したいと思います。
第9回 FIBOの簡易モデル Financial Industry Business Data Model(FIB-DM)
FIBOの調査を継続していますが、やはりFIBOはあまりにも巨大で複雑すぎるため実務に適用するのにはかなり煩雑であると考えていました。同じ考えをもって中小の金融機関でも容易に導入できるように簡易モデルを作った人がいました。それがFinancial Industry Business Data Model(FIB-DM)です。
FIB-DMを紹介するPPTがありましたので日本語訳を実施して掲載します。
FIBOの内容理解のお役にたてればと思います。
原文は以下です。
https://fib-dm.com/semantics-for-finance-users/
<日本語訳>
<目次>
- ①ビジネスユーザのための意味体系
- ②ファイナンスユーザーと共にモデルを理解し、範囲を定め、デザインする
- ③基本的な考え方は、すべてのお客様のためのものです
- ④教育の中のこの教訓
- ⑤企業情報アーキテクチャ
- ⑥コンセプトマップの用語は統一されている
- ⑦概念と語彙は、地図とデータモデルとの間の直接的な対応関係を確立する。
- ⑧15つのニーモニック・アイコンと略称
- ⑨それぞれのコンセプトはビジネスの詳細な分類
- ⑩商業とCMの関係は、合意された200以上の名前から生まれています。
- ⑪指定概念に係る関係
- ⑫Conformされたコンセプトマップの完成
- ⑬データモデルとコンセプトマップ
- ⑭究極のスーパータイプが基本コンセプト
- ⑮サブタイプのヒエラルキーは、FIBS分類です。
- ⑯データモデルの関連付けと関連性のあるエンティティの概念図
- ⑰広範なモデルへのアプローチ
- ⑱OntologyとData Modelの階層は同じ
- ⑲概念と語彙は、直接、ontologyグラフに対応します。
- ⑲参考資料のコンセプト名(略称)
- ⑳独立代理人(Autonomous Agent)(AA)
- ㉑Thing in Role(TIR)
- ㉒Reference(参考)
- ㉓アレンジメント(Arrangement) (ARR)
- ㉔所在地(Location ) (LOC)
- ㉕ドキュメント(DOC)
- ㉖サービス
- ㉗Product(PRD)
- ㉘契約(Agreement)(AGR)
- ㉙コミットメントCommitment(COM)
- ㉚契約構成要素(Contractual Element)(CE)
- ㉛Legal Construct(LC)
- ㉜Account(AC)
- ㉝時間(TI)
- ㉞発生事実Occurrence(OCC)
- ㉟企業情報アーキテクチャ
- ㊱参考資料及び関連資料
①ビジネスユーザのための意味体系

②ファイナンスユーザーと共にモデルを理解し、範囲を定め、デザインする

③基本的な考え方は、すべてのお客様のためのものです

④教育の中のこの教訓

⑤企業情報アーキテクチャ

⑥コンセプトマップの用語は統一されている

⑦概念と語彙は、地図とデータモデルとの間の直接的な対応関係を確立する。
⑧15つのニーモニック・アイコンと略称

⑨それぞれのコンセプトはビジネスの詳細な分類

⑩商業とCMの関係は、合意された200以上の名前から生まれています。
⑪指定概念に係る関係
⑫Conformされたコンセプトマップの完成
⑬データモデルとコンセプトマップ

⑭究極のスーパータイプが基本コンセプト

⑮サブタイプのヒエラルキーは、FIBS分類です。

⑯データモデルの関連付けと関連性のあるエンティティの概念図

⑰広範なモデルへのアプローチ

⑱OntologyとData Modelの階層は同じ
⑲概念と語彙は、直接、ontologyグラフに対応します。
⑲参考資料のコンセプト名(略称)

⑳独立代理人(Autonomous Agent)(AA)

㉑Thing in Role(TIR)

㉒Reference(参考)

㉓アレンジメント(Arrangement) (ARR)

㉔所在地(Location ) (LOC)

㉕ドキュメント(DOC)

㉖サービス

㉗Product(PRD)

㉘契約(Agreement)(AGR)

㉙コミットメントCommitment(COM)

㉚契約構成要素(Contractual Element)(CE)

㉛Legal Construct(LC)

㉜Account(AC)

㉝時間(TI)

㉞発生事実Occurrence(OCC)

㉟企業情報アーキテクチャ

㊱参考資料及び関連資料

以上
第8回 オントロジの開発手法
オントロジの開発手法について記述された文献が少ないのですが、以下のマニュアルが秀逸です。
出典
https://protege.stanford.edu/publications/ontology_development/ontology101.pdf
以上は原文ですが HTMLからCromeなら直接翻訳できます。
http://www.ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-noy-mcguinness.html
また、以下、日本語に翻訳してくれた方がいます。
https://88171.net/ontology-development-101
文献はボリュームが多いので以下本来のマニュアル作者がPPTに要約したものを当方で翻訳しました。
原文:https://slideplayer.com/slide/9114500/
- 2 フランスのワインとワインの産地
- 3 概要【目次】
- 4 オントロジーとは
- 5 オントロジーの例
- 6 「オントロジー工学」とは?
- 8 オントロジーを開発する理由
- 9 その他の理由
- 10 オントロジーはしばしばオントロジーの始まりにすぎない
- 12 ワインとワイナリー
- 13 オントロジー-開発プロセス
- 14 オントロジー工学とオブジェクト指向モデリング
- 15 Preliminaries-Tools
- 16 ドメインとスコープの決定
- 17 コンピテンシーの質問
- 18 再利用の検討
- 19 再利用可能なもの
- 20 再利用可能なもの (II)
- 21 重要な用語を列挙する
- 22 用語(term)列挙-ワインオントロジーの例
- 23 クラスとクラス階層の定義
- 24 クラスの継承
- 25 クラスの継承-例
- 26 階層のレベル
- 27 開発モード
- 28 ドキュメント
- 29 クラスのプロパティの定義-スロット
- 30 プロパティ(スロット)
- 31 クラスワイン用のスロット(Protégé-2000内)
- 32 スロットとクラスの継承
- 33 プロパティの制約
- 34 ワインクラスのスロットのファセット
- 35 共通のファセット
- 36 共通ファセット:スロットカーディナリティ
- 37 一般的なファセット:値タイプ
- 38 スロットのドメインと範囲(Range)
- 39 ファセットとクラスの継承
- 40 インスタンスの作成
- 41 インスタンスの作成:例
- 43 より深く
- 44 クラスとクラス階層の定義
- 45 多重継承
- 46 分離(Disjoint)クラス
- 47 クラスサイクルの回避
- 48 クラス階層の兄弟(Sibling)クラス
- 49 完璧な家族サイズ
- 50 完全な家族規模(II)
- 51 単一および複数のクラス名
- 52 クラスとその名前
- 54 スロットに戻る:ドメインと範囲
- 55 スロットに戻る:ドメインと範囲
- 56 ドメインと範囲の定義
- 57 インバーススロット
- 58 インバーススロット(II)
- 59 デフォルト値
- 60 範囲の制限
- 61 範囲の制限(II)
- 62 概要【目次】
- 63 オントロジーとSW言語
- 64 SW言語
- 65 RDFおよびRDFスキーマクラスRDFスキーマ仕様1.0
- 66 RDF(S)の用語とセマンティクス
- 67 RDF(S)のプロパティ制約
- 68 DAML + OIL:クラスとクラス階層
- 69 DAML + OILでクラスを定義するその他の方法
- 70 DAML + OILのプロパティ制約
- 72の オントロジー工学の研究課題
- 73 内容:トップレベルのオントロジー
- 74 コンテンツ:知識獲得
- 75 分析
- 76 評価
- 77 オントロジーメンテナンス
- 78 オントロジー言語
- 79 オントロジー開発ツール
- 80 ここからさらに向かうべきところ?
- 82 クラス階層の推移性
2 フランスのワインとワインの産地
カリフォルニアのワインとワインの産地
今日、シーフードに添えるべきワインはどれですか?
ワインと食べ物の共有されたONTOLOGY
3 概要【目次】
- オントロジーとは何ですか?
- オントロジーを開発する理由
- ステップバイステップ:オントロジーの開発
- さらに深く:一般的な問題と解決策
- セマンティックWeb言語のオントロジー
- オントロジーエンジニアリングの現在の研究課題
4 オントロジーとは
・概念
・プロパティと属性のプロパティ
・プロパティと属性に対する制約
・Individuals (多くの場合、常にではない)
オントロジーは、以下を定義します
・共通の語彙
・共有の理解
5 オントロジーの例
・ウェブ上の分類
Yahoo! カテゴリ
・オンラインショッピングのカタログ
Amazon.com製品カタログ
・ドメイン固有の標準用語
統一医療言語システム(UMLS)
UNSPSC-製品およびサービスの用語
6 「オントロジー工学」とは?
ドメイン内の概念の定義(クラス)
階層内の概念の配置(サブクラス-スーパークラス階層)
クラスが持つことができる属性とプロパティ(スロット)の定義と値の制約の定義
Individuals の定義とスロット値の入力
(スロットはクラスやインスタンスのプロパティを定義するもの)
7 概要【目次】
- オントロジーとは何ですか?
- オントロジーを開発する理由
- ステップバイステップ:オントロジーの開発
- さらに深く:一般的な問題と解決策
- セマンティックWeb言語のオントロジー
- オントロジーエンジニアリングの現在の研究課題
8 オントロジーを開発する理由
①人やエージェントプログラムの間で,
情報の構造の基本的な理解を共有した い
②そのドメインにおける知識の再利用を可能にしたい
③そのドメインにおける前提・仮定を明示したい
④そのドメインの知識と実践的な知識を分離したい
⑤そのドメインの知識を検証したい
9 その他の理由
- ドメインの仮定を明示的に
- ドメインの仮定を変更しやすくする(遺伝知識ベースを考慮)
- レガシーデータを理解および更新しやすくする
- ドメイン知識を運用知識から分離するには
- ドメインと運用知識を別々に再利用する(制約に基づく構成など) )
10 オントロジーはしばしばオントロジーの始まりにすぎない

11 概要【目次】
- オントロジーとは何ですか?
- オントロジーを開発する理由
- ステップバイステップ:オントロジーの開発
- さらに深く:一般的な問題と解決策
- セマンティックWeb言語のオントロジー
- オントロジーエンジニアリングの現在の研究課題
12 ワインとワイナリー

クラスには黒を、インスタンスには赤を使用しています。
13 オントロジー-開発プロセス

このチュートリアルでは、スコープを決定し、列挙項を定義し、クラスを定義し、プロパティを定義し、制約を定義します。インスタンスを作成します
実際-反復プロセス:

14 オントロジー工学とオブジェクト指向モデリング
オントロジーは、
- 世界の構造を反映することが多く、
- 概念の構造に関するものであることが多く、
- 実際の物理的表現は問題ではありません
ObjectOrientedなクラス構造は、
- データの構造を反映し、
- コードは通常、動作(メソッド)について説明します
- データの物理表現(long int、charなど)
15 Preliminaries-Tools
このチュートリアルのすべてのスクリーンショットはProtégé-2000のものです。
- グラフィカルなオントロジー開発ツール
- これは、豊富な知識モデルをサポートするであり、
- オープンソースで自由に利用できます(http://protege.stanford.edu)
その他ツール:
- OntolinguaおよびChimaera
- OntoEdit
- OilEd
16 ドメインとスコープの決定

ドメインとスコープの決定には以下の質問が有効です。
これらの質問に対する回答は、ライフサイクル中に変更される場合があります
17 コンピテンシーの質問
オントロジ開発にあたってはコンピテンシーの質問を検討する事から始めます。
「ワインを選ぶ際に考慮すべきワインの特性は何ですか?」ということから考えると
- ボルドーは赤または白ワインですか?
- カベルネ・ソーヴィニヨンはシーフードとよく合いますか?
- 肉のグリルに最適なワインは何ですか?
- ワインのどの特性が料理の適切さに影響しますか?
- 特定のワインのフレーバーやボディはヴィンテージの年によって変わりますか?
- ナパ・ジンファンデルは何年物がよいか?
これらの質問から判断すると,オントロジーにはワインの様々な特徴,ワ インの種類,ビンテージイヤー ( 良い年 / 悪い年 ) ,合うワインを選ぶ上で 問題となる料理の分類,料理とワインのお薦めの組み合わせを含める必要があることがわかります。
18 再利用の検討

既に開発されている他のオントロジーの再利用の検討をおすすめします。
その理由とは
19 再利用可能なもの
オントロジーライブラリで再利用可能なものは、主に以下がある。
- DAMLオントロジーライブラリ(daml.org/ontologies)
- Ontolinguaオントロジーライブラリ(ksl.stanford.edu/software/ontolingua/)Protégé
- オントロジーライブラリ(stanford.edu/plugins.html)
Upperオントロジー
20 再利用可能なもの (II)
一般的なオントロジー
- UMLS Semantic Net
- GO(Gene Ontology)(geneontology.org)
21 重要な用語を列挙する

- どの用語(term)について議論したい?
- これらの用語の特性は何か?
- 用語をもってして何を言いたいか?
22 用語(term)列挙-ワインオントロジーの例
ワイン、ブドウ、ワイナリー、場所、
ワインの色、ワインのボディ、ワインの風味、砂糖の含有量
白ワイン、赤ワイン、ボルドーワイン
フード、シーフード、魚、肉、野菜、チーズ
23 クラスとクラス階層の定義

クラスは、ドメイン内の概念です
- ワインのクラス
- ワイナリーのクラス
- 赤ワインのクラス
クラスは、類似のプロパティを持つ要素のコレクションです
クラスのインスタンス例:
- 昼食のために使うカリフォルニアワインのグラス
24 クラスの継承
- クラスは通常、分類Taxonomy階層(サブクラス-スーパークラス階層)を構成します。
- クラス階層は通常IS-A階層です。
サブクラスのインスタンスはスーパークラスのインスタンスです。
- クラスを要素のセットと考える場合、サブクラスはサブセットです
25 クラスの継承-例
- リンゴは果物のサブクラス
すべてのリンゴは果物で赤
- ワインはワインのサブクラス
すべての赤ワインはワインです
- キャンティワインは赤ワインのサブクラス
すべてのキャンティワインは赤ワインです
26 階層のレベル

27 開発モード
開発手法としては以下の三種類があります
①トップダウン-最初に最も一般的な概念を定義し、次にそれらを特化-
②ボトムアップ-最も具体的な概念を定義し、より一般的なクラスの整理する
③両者の組み合わせ
-より顕著な概念を最初に定義し、次にそれらを一般化および特化する。
最も一般的な分類で分けることでワインを考えようとしているのであれば,トップダウンのアプローチが使いやすい



28 ドキュメント
クラス(およびスロット)は、通常、ドキュメントで記述します
クラスとスロットのドキュメント化は、コンピューターコードのドキュメント化と同じくらい重要です!
29 クラスのプロパティの定義-スロット

各ワインには色、糖度、生産者などがあります。再利用を検討します。など
30 プロパティ(スロット)
- プロパティの種類
- 「固有の」プロパティ:ワインのフレーバーと色
- 「固有の」プロパティ:ワインの名前と価格
- パーツ:料理の材料
- 他のオブジェクトとの関係:ワインの生産者(ワイナリー)
- シンプルなプロパティ(属性):プリミティブ値(文字列、数字)を含む
- 複雑なプロパティ:他のオブジェクト(ワイナリーインスタンスなど)を含む(または指す)
31 クラスワイン用のスロット(Protégé-2000内)

32 スロットとクラスの継承
- サブクラスはスーパークラスからすべてのスロットを継承します
- ワインに名前とフレーバーがある場合、赤ワインにも名前とフレーバーがあります
- クラスに複数のスーパークラスがある場合、それらはすべてからスロットを継承します
- デザートワインと赤ワイン。前者から「糖度:高」、後者から「色:赤」を継承します
33 プロパティの制約

- プロパティの制約(ファセット)は、スロットに設定できる値のセットを記述または制限します
- ワインの名前は文字列です
- ワイン生産者はワイナリーのインスタンスです
- ワイナリーは特定の場所(ロケーション)にあります
34 ワインクラスのスロットのファセット

35 共通のファセット
- スロットのカーディナリティー – スロットが持つ値
- スロット値のタイプ – スロットが持つ値のタイプ
- 最小値と最大値 – 数値スロットの値の範囲
- デフォルト値 – 明示的に指定されない限りスロットが持つ値
36 共通ファセット:スロットカーディナリティ
- カーディナリティ
- カーディナリティNは、スロットにN値が必要であることを意味します
- 最小カーディナリティ
- 最小カーディナリティ1は、スロットに値が必要であることを意味します(必須)
- 最小カーディナリティ0は、スロットに値がオプショナルであることを意味します(
- 最大カーディナリティー
- 最小カーディナリティ1 はスロットは1つの値を持つことができます(単一値スロット)
- 1より大きい最大カーディナリティーは、スロットが複数の値を持つことができることを意味します(複数値スロット)
37 一般的なファセット:値タイプ
- 文字列:文字列(「シャトーラフィット」)
- 数値:整数またはフロート(15、5)
- ブール値:true / falseフラグ
- 列挙型:許可される値のリスト(高、中、 low)
- 複合型:別のクラスのインスタンス
- インスタンスが属するクラスを指定します
Wineクラスは、Wineryクラスで「生成する」スロットの値の型です
38 スロットのドメインと範囲(Range)
39 ファセットとクラスの継承
- サブクラスはスーパークラスからすべてのスロットを継承します
- サブクラスはファセットをオーバーライドして許容値のリストを「狭める」ことができます
- カーディナリティ範囲を小さくします
- 範囲内のクラスをサブクラスに置き換えます

40 インスタンスの作成

41 インスタンスの作成:例

42 概要【目次】
- オントロジーとは何ですか?
- オントロジーを開発する理由
- ステップバイステップ:オントロジーの開発
- さらに深く:一般的な問題と解決策
- セマンティックWeb言語のオントロジー
- オントロジーエンジニアリングの現在の研究課題
43 より深く

44 クラスとクラス階層の定義
- 覚えておくべきこと:
正しいクラス階層は1つだけではありませんが
いくつかのガイドラインがあります。
- 質問するべきことは
「サブクラスの各インスタンスはスーパークラスのインスタンスですか?」
45 多重継承

- クラスは複数のスーパークラスを持つことができます
- サブクラスはすべての親からスロットとファセットの制限を継承します
- システムが異なれば競合の解決方法も異なります
46 分離(Disjoint)クラス
- 共通のインスタンスを持たないクラスは分離(Disjoint)されます
- 分離(Disjoint)クラスは共通のサブクラスを持つことができません
赤ワイン、白ワイン、ロゼワインは分離される
デザートワインと赤ワインは分離されません

47 クラスサイクルの回避

- 多重継承の危険性:クラス階層のサイクル
- クラスA、B、およびCには同等のインスタンスセットがあります
- 多くの定義により、A、B、およびCは同等です
48 クラス階層の兄弟(Sibling)クラス
- 階層のすべての兄弟は、一般性が同じレベルである必要があります
- 本のセクションおよびサブセクションと比較
-

49 完璧な家族サイズ

- クラスにchildが1人しかいない場合、モデリングの問題が発生する可能性があります。
- もし私たちが持っているレッドブルゴーニュがコートドールだけなら、なぜ下位階層を導入するのでしょうか。
- 箇条書きリストの箇条書きと比較する
50 完全な家族規模(II)

- クラスに12人以上の子供がいる場合、追加のサブカテゴリが必要になる場合があります
- しかし、自然な分類が存在しない場合は、長いリスト(Long list)がより自然になる可能性があります
51 単一および複数のクラス名
- 「ワイン」は一種の「ワイン」ではありません
- ワインはクラスのインスタンスです
- クラス名は、すべて単数形または複数形です
-

52 クラスとその名前
- クラスは名前ではなくドメインの概念を表します
- クラス名は変更できますが、同じ概念を引き続き参照します
- 同じ概念の同義語名は異なるクラスではありません
- 多くのシステムでは、クラスの一部として同義語をリストできます
53 完成したワインの階層

54 スロットに戻る:ドメインと範囲
・スロットのドメインまたは範囲を定義するとき、最も一般的なクラスを見つけます。
・フレーバースロットを検討します
ドメイン:ワイン
・ワイナリーの農産物スロットを検討します:
範囲:赤ワイン、白ワイン、ロゼワイン
範囲:ワイン
55 スロットに戻る:ドメインと範囲

- スロットのドメインまたは範囲を定義する場合、最も一般的なクラスを見つけます。
- フレーバースロットを検討します
ドメイン:ワイン
- ワイナリーの農産物スロットを検討します
範囲:赤ワイン、白ワイン、ロゼワイン
範囲:ワインスロットクラス許容値DOMAINRANGE
56 ドメインと範囲の定義

57 インバーススロット
MakerとProducerはインバーススロットです

58 インバーススロット(II)
- インバーススロットには冗長情報が含まれていますが、
- いずれかの方向の情報の取得を許可します
- 追加検証を有効にします
- 両方向の情報の表示を許可します
- 実際の実装はシステムによって異なります
- 両方の値が保持されますか?
- 逆数値はいつ入力されますか?
- リンクを逆スロットに変更するとどうなりますか?
59 デフォルト値
- デフォルト値-インスタンスの作成時にスロットが取得する値
- デフォルト値は変更可能
- デフォルト値はスロットの一般的な値ですが、必須値ではありません。
- たとえば、ワインのボディーのデフォルト値は“Full”
60 範囲の制限
- オントロジーには、ドメインに関するすべての可能な情報を含めるべきではありません。
- アプリケーションが必要とする以上に特化または一般化する必要はありません。
- クラスのすべての可能なプロパティを含める必要はありません。
- 最も顕著なプロパティのみ
- アプリケーションが必要とするプロパティのみ
61 範囲の制限(II)
- ワイン、食物、およびそれらの組み合わせのオントロジーには、
- ボトルサイズは含まれません
- ラベルの色
- 私の好きな食物およびワイン
- 生物学実験のオントロジーには以下が含まれます
- 生物
- 実験者
- 実験者クラスは実験生物のサブクラスですか?
62 概要【目次】
- オントロジーとは何ですか?
- オントロジーを開発する理由
- ステップバイステップ:オントロジーの開発
- さらに深く:一般的な問題と解決策
- セマンティックWeb言語のオントロジー
- オントロジーエンジニアリングの現在の研究課題
63 オントロジーとSW言語
64 SW言語
言語は以下で異なります
- 構文
- ここでは関係ありません–オントロジーは概念的なものです
- 用語
- クラスコンセプト
- インスタンスオブジェクト
- スロットプロパティ
- 表現力
- 一部の言語で表現できるもの、その他では表現できない
- 意味論
- 同じ文が異なる場合に異なることを意味する場合があります
65 RDFおよびRDFスキーマクラスRDFスキーマ仕様1.0
(http://www.w3.org/TR/2000/CR-rdf-schema-20000327/)

66 RDF(S)の用語とセマンティクス
- クラスとクラス階層
- すべてのクラスはrdfs:Classのインスタンスです
- クラス階層はrdfs:subClassOfによって定義されます
- クラスのインスタンス
- rdf:typeによって定義されます
- プロパティ
- プロパティは1つの場所にあるプロパティ名です
- 別のプロパティ名と同じです(同じネームスペースを想定)
- プロパティも階層を形成します(rdfs:subPropertyOf)
67 RDF(S)のプロパティ制約
- カーディナリティ制約
- 明示的なカーディナリティ制約なし
- プロパティは複数の値を持つことができます
- プロパティの範囲
- プロパティは1つの範囲しか持てません
- プロパティのドメイン
- プロパティは複数のドメインを持つことができます1つのクラス)
- デフォルト値なし
68 DAML + OIL:クラスとクラス階層
- クラス
各クラスは、daml:Classのインスタンスです
- クラス階層
rdfs:subClassOfによって定義されます
- クラスの編成を指定する他の方法
分離(daml:disjointWith)
等価(daml:sameClassAs)
- クラス階層はクラスのプロパティから計算される
69 DAML + OILでクラスを定義するその他の方法
- クラスの連合クラス
- Personはクラスの連合です男性と女性
- プロパティの制限クラス
- Red Thingは色のあるものの集合です:クラスの赤
- 交差クラス
- Red WineはWineとRed Thingの交差点
- クラスの補完
- 肉食動物は草食動物ではないすべての動物です
- 要素の列挙
- Wine Colorクラスには、赤、白、ロゼのインスタンスが含まれます。
70 DAML + OILのプロパティ制約
- カーディナリティ
- 最小、最大、正確なカーディナリティ
- プロパティの範囲
- プロパティの範囲には複数のクラスを含めることができます。
- プロパティの値は各クラスのインスタンスである必要があります。
- プロパティのドメイン–範囲と同じ
- デフォルト値なし
71 概要【目次】
- オントロジーとは何ですか?
- オントロジーを開発する理由
- ステップバイステップ:オントロジーの開発
- さらに深く:一般的な問題と解決策
- セマンティックWeb言語のオントロジー
- オントロジーエンジニアリングの現在の研究課題
72の オントロジー工学の研究課題
- コンテンツ世代
- 分析と評価
- メンテナンス
- オントロジー言語
- ツールの開発
73 内容:トップレベルのオントロジー
74 コンテンツ:知識獲得
- 知識獲得はボトルネックです
- 問題の共有と再利用が問題を軽減します
- しかし、自動化された知識獲得技術が必要です
75 分析
- 分析:意味の一貫性
- プロパティ制約の違反
- クラス階層のサイクル
- 使用されているが定義されていない用語
- 空の間隔を生成する間隔制限(最小>最大)
- 分析:スタイル
- 1つのサブクラスを持つクラス
- 定義なしのクラスおよびスロット
- 制約のないスロット(値タイプ、カーディナリティ)
- 自動分析ツール
- Chimaera(Stanford KSL)
- DAMLバリデーター
76 評価
77 オントロジーメンテナンス
78 オントロジー言語
- 表現力の「正しい」レベルとは何ですか?
- 「正しい」セマンティクスとは何ですか?
- 言語はいつ「多すぎる」と仮定しますか?
79 オントロジー開発ツール
80 ここからさらに向かうべきところ?
Natalya F. Noy and Deborah L. McGuinness(2001)
「オントロジー開発101:最初のオントロジー作成ガイド」http://protege.stanford.edu/publications/ontology_development/o ntology101.html
Farquhar、A.(1997) )。Ontolinguaチュートリアル。
http://ksl-web.stanford.edu/people/axf/tutorial.pdfこのチュートリアル MethodologyGómez-Pérez、A.(1998)からいくつかのアイデアを借りました。
知識の共有と再利用。応用エキスパートシステムのハンドブック。Liebowitz、CRC Pressの編集者。
Uschold、M.およびGruninger、M.(1996)。オントロジー:原則、方法、アプリケーション。ナレッジエンジニアリングレビュー11(2)
82 クラス階層の推移性
is-a関係は推移的です:
BはAのサブクラスです
CはBのサブクラスです
CはAのサブクラスです

ーーーーーーーーーーーーーーーーーーーーー
他の参考文献 (How to build an ontology)
https://slideplayer.com/slide/14695486/




<参考>
別資料で開発に必要なマッピングツールの評価の資料がありました。
https://slideplayer.com/slide/5962119/























