付録 A — 調査方法と範囲

本レポートには「対応が確認できなかった」という否定的な主張が複数ある。 これは不在の証明であり、本質的に弱い。何をどこまで調べたのかを開示して、 読者が確度を判断し追試できるようにする。

A.1 出典の階層

階層 内容 扱い
Tier 1 ASF 公式（incubator.apache.org, lists.apache.org, cwiki, dist.apache.org）、仕様リポジトリ 事実認定の根拠とする
Tier 2 プロジェクト広報（ossie.apache.org） ASF インフラ上だが PPMC 自身の広報文。主張として扱う
Tier 3 ベンダーブログ、業界メディア 事実関係は Tier 1 で裏を取る。単独では根拠としない

A.2 ベンダーの実装状況をどう調べたか

「参加している」と「実装している」を区別することを最優先に置いた。 参加表明・プレスリリース・パートナー一覧への掲載は、いずれも実装の証拠ではない。

判定は次の順序で行った。

  1. 製品ドキュメントに OSI / Ossie の記載があるか
  2. 記載がある場合、それが export / import のどちらか、 GA か preview か、対応する仕様バージョンは何か
  3. apache/ossie への貢献があるか（コミット作者のメールドメイン、Issue/PR）

A.2.1 網羅的に走査した3社

ドキュメント全体を機械的に取得して検索したため、否定の確度が比較的高い。

製品 走査対象 規模 OSI 関連のヒット
Atlan docs.atlan.com サイトマップ全 URL 2,815 URL 0件（4件は誤検出）
Alation docs.alation.com/en/latest/searchindex.js（Sphinx 検索インデックス全体） 3.0 MB 0件（2件は “dossier” の部分一致）
Select Star docs.selectstar.com/llms-full.txt（ドキュメント全文） 408 KB 0件

検索語は osi / ossie / open semantic interchange / interchange。 Alation は2026年のリリースノート3本（528 KB / 323 KB / 534 KB）も個別に確認した。 Select Star は llms.txt、changelog.md、features/semantic-models.md、 および 2.5 MB の過去 changelog も確認した。

参照した主な URL は本節の表と、第5章の各脚注に示したとおりである。

A.2.2 関連ページを個別に確認した5社

こちらは網羅的走査を行っていない。関連が見込まれるページと リリースノートを個別に参照したにとどまるため、否定の確度は上記3社より低い。

ベンダー 参照した文献
Snowflake semantic views overview / feature releases 2026 / Tableau TDS 対応の release note / converters/snowflake
Databricks metric views / metric views YAML reference
Dremio Dremio Cloud changelog（2025-11-12 〜 2026-07-14 の範囲）/ self-serve semantic layer / Dremio ブログ
Cube semantic layer sync
Salesforce / Tableau Salesforce semantic layer guide / Tableau Semantics / converters/salesforce

いずれもアクセス日は 2026-07-19。

A.2.3 Superset SIP-182 の確認手段

Superset については「マージ済みだが未リリース」「OSI 対応ではない」という 2つの判断をしている。根拠は以下のとおり。

マージ済みであること

  • Issue #35003（SIP-182） が 2026-06-22 に completed としてクローズされている
  • 関連 PR 約26本（#37815 セマンティック層拡張、#37816 モデル/DAO、 #37817 Explore 統合、#38370 API、#38376 UI、#40475 ダッシュボードフィルタ、 最終は #42093、2026-07-15）が master にマージ済み

未リリースであること

  • superset/semantic_layers/ が 6.2 リリースブランチに存在しない （GitHub API でパスを問い合わせて 404）
  • アプリの最新タグは 6.1.0（2026-05-01）で、その config.py に SEMANTIC_LAYERS フラグが存在しない
  • master の superset/config.py では "SEMANTIC_LAYERS": False に # @lifecycle: development の注記が付く
  • CHANGELOG/6.1.0.md にセマンティック層関連の項目がない

OSI 対応ではないこと

  • apache/superset に対する ossie / open semantic interchange の コード検索がいずれも 0 件
  • OSI の語は散文中に1度、セマンティック層の一例として名前が挙がるのみ
  • apache/ossie の converters/ に Superset 向けのものがなく、 Superset に言及する Issue もない

Preset（Superset の商用提供元）の表明

  • パートナーページに “We’re working to ensure Preset and Apache Superset™ can both export and import semantic definitions in the OSI format.”（Preset と Apache Superset の双方が OSI 形式でセマンティック定義を export / import できるよう取り組んでいる）とある。 未来形で、日付の記載はない
  • Preset のセマンティック層ドキュメントは 自社のデータセットとメトリクスを説明しており、OSI への言及はない

いずれもアクセス日 2026-07-19。和訳は筆者による。

A.2.4 リポジトリ側の確認

apache/ossie について次を確認した。

  • 全コミットの作者メールドメイン（API を5ページ分、計500件まで取得）
  • Issue / PR の全文検索（repo:apache/ossie+<vendor>）
  • converters/ 配下のディレクトリ構成と各コンバータが対象とする仕様バージョン
  • GitHub Releases、タグ一覧

A.3 否定的結論の限界

以下は本レポートの主張の弱点として明示しておく。

  • NDA 下のプライベートプレビューは公開情報に現れない。 非公開で実装が進んでいる可能性は排除できない
  • ドキュメントに書かれていないだけで機能が存在することはありうる。 特に API 経由の未文書化エンドポイント
  • 網羅走査した3社についても、検索インデックスやサイトマップが ドキュメント全体を反映していない可能性がある
  • 調査は 2026-07-19 の一時点のスナップショットである。 実際、dbt Core 1.12 の GA（2026-07-16）と expression_language.md の追加（2026-07-15）は調査の数日前であり、 もう数日早く調べていれば違う結論になっていた箇所がある

A.4 再調査時の注意

同種の調査を行う場合、以下の落とし穴に注意されたい。

  • 未認証の GitHub API は偽陰性を生む。 api.github.com/search/code は 未認証で 401 を返し、org-repos エンドポイントはレート制限にかかる。 どちらも「結果ゼロ」に見えるため、認証済みの gh コマンドを使うこと
  • SEO 記事と製品ドキュメントは食い違うことがある。 本調査では、ある製品の SEO 記事が現在形で OSI 対応を謳う一方、 同社の製品ドキュメントには記載がないという事例に遭遇した（チャプター 6）
  • 社名を冠したディレクトリ名は所属を意味しない。 converters/orionbelt は BlackRock ではなく独立開発者の OBML、 converters/polaris はベンダー製品ではなく Apache Polaris である

A.5 動作確認の手順

次の順序で実施した。

  1. 仕様を一次読解し、基礎文書として固定する（チャプター 4）
  2. 基礎から検証計画を導く。 各項目について、主張・手順・裏付けとなる観測・ 反証となる観測を事前に定める
  3. 計画に沿って動作確認する。計画外の観測は増やさない
  4. 実装に投入する文書は、必ず公式バリデータを通してから使う

4 の理由を補足する。仕様に適合しない文書を実装に読ませた場合、 実装がそれをどう扱おうと「実装の性質」としては解釈できない。 仕様準拠を先に保証しておかないと、観測されたものが 仕様由来か実装由来かを切り分けられなくなる。

2 で反証条件を先に定めるのは、結論ありきの検証を避けるためである。 各項目の主張・反証条件・結果は第6章（チャプター 7）に示し、 実行結果の生データはリポジトリの docs/results/ に出力される。

環境は Docker で固定し、仕様リポジトリはコミットを固定（07be0176）、 検証コンテナは外部ネットワークから切り離して実行した。 再現手順は 付録 B にある。