OntoGenix: Leveraging Large Language Models for enhanced ontology engineering from datasets
| 項目 | 内容 |
|---|---|
| 論文ID | P36 |
| 区分・分類 | 論文・スキーマ・オントロジー |
| 著者・所属 | Mikel Val-Calvo, Juan Mulero-Hernández, Ginés Almagro-Hernández, Jesualdo Tomás Fernández-Breis（Universidad de Murcia）／Mikel Egaña Aranguren（University of the Basque Country (UPV/EHU)）／Prashant Deshmukh, José Antonio Bernabé-Díaz, Paola Espinoza-Arias, José Luis Sánchez-Fernández, Juergen Mueller（BASF SE）※本文を読めないため OpenAlex の書誌データから転記 |
| 発表先 | Information Processing & Management |
| 発表日 | 2024-12-24 |
| 引用数 | 21（OpenAlex 2026-10-06時点） |
| 言語 | 英語 |
| URL | https://doi.org/10.1016/j.ipm.2024.104042 |
| 取得できず | |
| 読んだ範囲 | 要旨のみ（Highlights と著者公開の GitHub リポジトリ OntoGenix・OntoGenixEvaluation を含む） |
論文タイプ
新技術。CSV データセットから LLM でオントロジーを作るパイプライン OntoGenix を提案し、人手で作ったオントロジーと比べて評価しているため。
研究の目標
- 背景：Knowledge Graph はオントロジーを使って異種データを統合する。ただしオントロジー開発はドメイン専門家とオントロジーエンジニアの共同作業が必要で、資源を食う。企業は、大規模・複雑でエンジニアにとって馴染みのないデータセットから Enterprise Knowledge Graph とオントロジーを作り保守するのに、多くの資源を投じている
- 到達点：データセットからのオントロジー開発を LLM で支援し、オントロジーに基づく KG 生成の自動化を進める。手法はマッピングと RDF データも生成できるが、本論文はオントロジーに絞る
技術的なやり方
要旨にある流れは「データ前処理 → オントロジー計画 → 構築 → エンティティ改善」。これを OntoGenix ツールに実装し、商業活動に関する6データセットに適用した。各段階の中身は GitHub の設計文書から補った（論文本文と同じかは未確認）。
| 段階 | 内容（GitHub 設計文書より） |
|---|---|
| データ前処理 | CSV を読み、一意識別子と URI を生成。列を数値・テキスト・カテゴリに分けて統計を要約し、JSON にする |
| 計画（Prompt Crafter・Plan Sage） | LLM がクラス、サブクラス、object/datatype property（domain・range 付き）、外部語彙へのリンクを高レベル構造として提案する。ユーザーが構造を指示することもできる |
| 構築（OntoBuilder） | OWL オントロジーを Turtle で生成する |
| エンティティ改善 | エンティティ単位でアノテーション、別名ラベル、制約を追加する |
| マッピング（本論文の対象外） | RML マッピングを生成し、エラーを返して自己修復させる |
- LLM：GPT-4（README）
- 評価データ：Airlines Customer Satisfaction、Amazon Ratings、BigBasket Products、Brazilian E-Commerce (Olist)、Consumer Complaint、E-Commerce Data（Kaggle）
- 評価方法（評価リポジトリより）：経験5年以上のエンジニア2名が人手版を3本ずつ作る。OQuaRE（19指標）、OOPS!（41種の落とし穴）、経験10年以上のエンジニアによる定性評価、作業時間の比較で人手版と比べる
結果
要旨には数値がない。要旨の結論：OntoGenix のオントロジーはモデリングに一貫したパターンがあり、使った品質指標の大半で人手版に近い。ただし最も複雑な状況は、人手版のほうがうまく表現している。
以下は評価リポジトリの数値（論文本文と同じかは未確認）。
| 項目 | OntoGenix | 人手 |
|---|---|---|
| OQuaRE で上回った指標 | RFCOnto, NOMOnto, RROnto, ANOnto（内容の豊富さ） | WMCOnto2, DITOnto, PROnto（構造の複雑さ） |
| OOPS! の落とし穴（重大/重要/軽微） | 59（11/22/26） | 38（4/13/21） |
- OQuaRE 19指標のうち、両者が同じスコアの指標はデータセットごとに10〜17個
- OntoGenix の出力から人手版を仕上げると、6データセットすべてで作業時間が短くなった。短縮は26.2〜218.6分（8.2〜58.3%）。修正の手間は1〜5の評価で全件3以下
限界・課題
- 要旨・Highlights：複雑なモデリング状況を捉えるのが苦手
- 評価リポジトリ：schema.org との誤った equivalentClass が多い。同じエンティティを data property と object property の両方にするなどの hallucination がある。クラスと個体の使い分けや表現力の高い公理では人手版に劣る（一方でアノテーションは人手版より多い）
要点
CSV データセットから GPT-4 でオントロジーを計画・構築・改善するパイプライン OntoGenix を提案した。EC など6データセットで人手版と比べると、品質指標の大半は同等でアノテーションは多い。ただし複雑な構造の表現は人手版に劣る。