+
K
注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
learn.palantir.com でも以下の内容をご覧いただけますが、アクセシビリティの観点から、ここに掲載しています。
これまで検討してきた航空オントロジーでは、フライト と 遅延 が別々のオブジェクトタイプとして表現されています。この決定は、遅延情報を各フライトオブジェクトのプロパティとして含めるという少なくとも1つの代替手段を考慮して行われました。以下の画像は、そのトレードオフを示す図です。
これらのトレードオフや設計上の決定はどのように行われるべきか?
オントロジーはデプロイ後に更新することができますが、最初からよく理由付けられたフレームワークを用意しておくことで、Foundryで価値を得るまでの時間を短縮できます。以下の Foundry の記事を確認し、オブジェクトモデルがユースケースの機能要件に応じてどのように作成されるべきかを説明しています。
ここまでで、最適なオントロジーには最適なバックエンドパイプラインが必要であり、それがデータエンジニアがオントロジー開発とメンテナンスのライフサイクルで重要な役割を果たしている理由の1つであることがわかるはずです。このチュートリアルの残りの部分では、このトレーニングのルートで得た経験を使って、オントロジーのオブジェクトタイプとリンクタイプのセットを構築し、改善していきます。