sparql-university

SPARQL 大学クエリータスク

概要

このスキルでは、RDF／Turtle データセットに対する SPARQL クエリーの作成方法を説明します。データを漏れなく分析すること、適切にクエリーを構築すること、そして十分に検証することに重点を置いています。

ワークフロー

ステップ 1：データを完全に取得する

クエリーを作成する前に、ソースデータ全体を確認できる状態にしてください。

重要な作業：

• Turtle（.ttl）ファイルまたは RDF ファイル全体を、途中で切り詰めずに読み取ります
• データが途中で切れているように見える場合は、追加の内容を依頼するか、ページネーションを使用します
• データが完全であることを確認するため、異なるエンティティの数を数えます
• 確認できたすべてのエンティティ型、述語、関係を記録します

検証チェックポイント： 先に進む前に、異なるエンティティの数が想定どおりであることを確認します。

ステップ 2：スキーマを理解する

クエリーを作成する前に、データ構造を整理します。

特定する主な要素：

• データセット内のすべてのエンティティ型（クラス）
• 使用されているすべての述語／プロパティ
• エンティティ間の関係（例：教授 → 学部 → 学生）
• リテラルのデータ型（文字列、日付、整数）
• 命名規則と値の形式

学術データでよく見られるパターン：

• 役職／職名には、特定の接頭辞が使われることがよくあります（例：「Professor of」、「Associate Professor」）
• 日付には、「現在」の状態を判定するための比較ロジックが必要な場合があります
• 地理コードには、ISO 規格（国コード）が使われる場合があります
• 在籍者が複数の学部にまたがることがあります

ステップ 3：条件を分解する

フィルタリング要件を、個別に検証できる条件に分解します。

条件ごとに行うこと：

1. 関連データへの正確な述語パスを特定します
2. 比較の種類（一致、接頭辞一致、所属判定、数値比較）を判断します
3. 条件の解釈におけるエッジケースを考慮します
4. 組み合わせる前に、各条件を個別にテストします

分解の例：

• 「正教授」→ 役職が特定の接頭辞で始まるものをフィルタリングします
• 「EU 加盟国で勤務」→ 国コードを EU 加盟国の一覧と照合します
• 「学生が 10 人を超える学部」→ 学部ごとに学生数を数え、しきい値を適用します

ステップ 4：クエリーを作成する

段階的にクエリーを作成し、各段階で検証します。

作成の手順：

1. 最も制限の厳しいフィルターから始め、結果セットを絞り込みます
2. 一度に 1 つずつフィルターを追加し、中間結果を確認します
3. 必要な SELECT 変数をすべて含めます
4. 集約（GROUP BY、GROUP_CONCAT）は最後に追加します

構文の検証：

• すべてのプレフィックスが宣言されていることを確認します
• FILTER 式が正しく閉じられていることを確認します
• 文字列比較に適切な関数（STRSTARTS、CONTAINS、regex）が使われていることを確認します
• 数値比較でデータ型が正しく処理されることを確認します

出力形式に関する考慮事項：

• 結果を集約する必要があるかどうか（例：複数の値を連結する）を判断します
• 連結した値の並び順と区切り文字を指定します
• フィルタリング条件と出力要件を区別します（例：EU 加盟国で絞り込みつつ、すべての国を出力する）

ステップ 5：検証戦略

既知の想定と照らし合わせてクエリーをテストします。

検証方法：

1. クエリーを実行し、出力結果を確認します
2. 正しさを確認するため、少なくとも 2～3 個のエンティティについてデータを手動でたどります
3. 期待するエンティティが含まれていることと、想定外のエンティティが含まれていないことの両方を確認します
4. 集約値を手作業で数えて検証します

照合チェックリスト：

• 返されたエンティティは手作業での分析と一致していますか？
• 期待するエンティティはすべて結果に含まれていますか？
• 想定外のエンティティが誤って含まれていませんか？
• 集約された件数／値は手作業での検証結果と一致していますか？

よくある落とし穴

データの読み込みが不完全

• 問題： データが途中で切れた状態で作業すると、エンティティが欠落します
• 対策： ファイルの内容が完全であることを必ず確認し、途中で切れている場合は再度読み込みます

クエリーの欠落

• 問題： 長いクエリーは、最後まで書き込まれないことがあります
• 対策： 書き込み後にクエリーファイルを読み返し、内容が完全であることを確認します

条件の誤解

• 問題： フィルター条件と出力要件を混同する
• 予防策： 「X で絞り込む」と「X を出力する」を区別します。両者は異なる場合があります

日付／時刻の境界ケース

• 問題： 境界日の処理を誤る
• 予防策： 比較が包含的か排他的かを明確にし、境界をテストします

集計エラー

• 問題： GROUP BY 句がない、または GROUP_CONCAT の使い方が正しくない
• 予防策： 集計構文がクエリの構造と一致していることを確認します

EU 加盟国の一覧

• 問題： EU 加盟国の国コードの一覧が不完全、または古い
• 予防策： 包括的な一覧を使用します：AT, BE, BG, HR, CY, CZ, DK, EE, FI, FR, DE, GR, HU, IE, IT, LV, LT, LU, MT, NL, PL, PT, RO, SK, SI, ES, SE

エンティティ間の関係

• 問題： 関係をまたぐエンティティの数え間違い（例：学部に所属する学生）
• 予防策： 述語の経路全体をたどり、結合条件を確認します

テスト手順

1. 構文チェック： クエリがエラーなく解析されることを確認します
2. サブセットテスト： 期待される結果がわかっているデータのサブセットで実行します
3. 全件テスト： 完全なデータセットで実行します
4. 手動検証： 結果を2～3件、ソースデータと照合します
5. 境界テスト： フィルターの日付、件数、文字列一致などのエッジケースを確認します

反復アプローチ

最初の結果が期待と一致しない場合：

1. どのフィルター条件が不一致の原因かを特定します
2. 各フィルターを個別にテストします
3. 表示されるはずなのに表示されないエンティティ（偽陰性）を調べます
4. 表示されるべきでないのに表示されるエンティティ（偽陽性）を調べます
5. 調査結果に基づいてフィルターロジックを調整します
6. 調整のたびに再確認します