ドキュメントの検索
karat

+

K

APIリファレンス ↗
8. [Builder] オントロジーデータパイプライン6 - オントロジー設計における考慮点
Feedback

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

6 - オントロジー設計における考慮点

これまでに見てきた航空オントロジーでは、フライト遅延は別々のオブジェクトタイプとして表現されています。この決定は、少なくとも1つの代替案を考慮に入れて行われました:各フライトオブジェクトのプロパティとして遅延情報を含めるというものです。以下の画像は、このトレードオフを示した図です。

これらのトレードオフと設計決定はどのように行われるべきでしょうか?

📚 推薦文献 (~10 分読む)

オントロジーはデプロイ後に更新することができますが、理論的にしっかりとしたフレームワークから始めると、Foundryで価値を引き出すまでの時間を短縮できます。次のFoundryの記事をレビューし、オブジェクトモデルがユースケースの機能要件に対してどのように作成されるべきかを説明しています。

これまでに、最適なオントロジーは最適なバックエンドパイプラインを必要とすることが明らかになっているはずです。これは、オントロジーの開発とメンテナンスのライフサイクルでデータエンジニアが非常に重要である理由の1つです。このチュートリアルの残りの部分では、このトレーニングのルートでの経験を活かして、オントロジーのオブジェクトタイプとリンクタイプのセットを構築し、改善します。