プロンプトとスコープ
RDFデータグラフとSHACLシェイプグラフから編集可能なフォームを生成するレンダラーを設計してください。フォーカスノードとルートシェイプの選択、プロパティ制約の集約、ウィジェットの選択、多言語ラベルの解決、および説明可能なバリデーションの維持をどのように行いますか？
この質問は、2026年5月26日に公開されたW3C First Public Working Draft of SHACL 1.2 User Interfacesに対応しています。これは、SHACLシェイプと制約を使用してRDFリソースの表示および編集インターフェースを生成し、コンポーネント、ラベル解決、レイアウトのヒント、ウィジェットのスコアリングに関する処理モデルを備えています。ドラフトは変更される可能性があるため、仕様の境界とプロダクトの実装判断を区別してください。
面接官が評価するポイント
面接官は、シェイプグラフ、データグラフ、フォーカスノード、ノードシェイプ間の明確なデータフロー、1つのパスに対する複数のプロパティシェイプの正確な集約、および決定論的で拡張可能なウィジェット選択を評価します。言語フォールバック、説明可能な失敗、キャッシュの無効化、認可、トランザクション境界を網羅してください。優れた回答では、ドラフトが視覚的なスタイリング、送信プロトコル、完全なバリデーションワークフロー、アクセシビリティ要件を定義していないことを指摘し、アプリケーションがそれらの要素を提供する必要があることに言及します。
回答前の明確化のための質問
- データグラフとシェイプグラフのみが提供されるのか、それとも呼び出し元がフォーカスノードとルートノードシェイプも提供するのか？
- これは表示、編集、クエリのどのモードか？1つのフォーカスノードが複数のシェイプにマッチすることはあるか？
- ウィジェットカタログの所有者は誰か、またテナントがスコアリンググラフを拡張できるか？
- 優先言語およびフォールバック言語は何か、またラベルが存在しない場合のローカル名ルールは何か？
- 保存には、アトミックトランザクション、排他制御、認可、および独立したSHACLバリデーションが必要か？
30秒の回答フレームワーク
「システムを入力パース、シェイプインデックス作成、コンポーネント生成、ウィジェット選択、ラベル解決、バリデーション表示、送信アダプターに分割します。レンダラーにはデータグラフ、シェイプグラフ、フォーカスノード、ノードシェイプが必要です。後ろの2つが欠落している場合、アプリケーションは自動選択を実行し、不確実性を明示します。プロパティコンポーネントはフォーカスノードとプロパティパスごとに制約を集約し、明示的な宣言、accept matcher、スコアリングを通じてウィジェットを選択します。すべての決定はそのルールとスコアを記録し、ラベルはユーザーの言語フォールバックに従います。レンダリングは仕様の関心事であり、ストレージ、認可、トランザクション、スタイリングはアプリケーションに属します。」
ステップごとの詳細解説
1. 入力と実行モードの確定
データグラフ、シェイプグラフ、フォーカスノード、ノードシェイプを明示的な入力とします。4つすべてが揃っている場合は手動モードを意味します。フォーカスノードまたはノードシェイプが欠落している場合は自動モードがトリガーされ、結果が診断情報に出力されます。表示と編集はシェイプ解決を共有できますが、エディターにはダーティ状態、アンドゥ、排他制御ポリシーも必要です。
2. シェイプとパスのインデックス構築
ノードシェイプ、プロパティシェイプ、ターゲット、プロパティパス、制約コンポーネントを事前処理します。インデックスキーには、シェイプIRI、フォーカスノード、パスを含める必要があります。ある制約が別の制約を暗黙的に上書きしないよう、プロバナンス（来歴）と重大度を保持しながら、同一のフォーカスノードとパスに対する複数のプロパティシェイプを集約します。
3. ノードおよびプロパティコンポーネントの生成
ノードコンポーネントはフォーカスノードを表し、プロパティコンポーネントは1つのパスに対するマージされた制約を表します。シェイプからフィールドセットを導出し、グループ化、順序付け、ロール、条件付きシェイプを適用します。複雑なパスの編集セマンティクスを保持します。パスを安全に1つのフィールドにマッピングできない場合は、読み取り専用ビューアにダウングレードするか、明示的なプロダクト編集戦略を要求します。
4. 決定論的なウィジェットの選択
明示的に宣言されたウィジェットとそのaccept matcherを最初に確認します。拒否された場合は、スコアリング関数を呼び出し、スコアリンググラフから候補を収集し、安定したスコア、優先度、IRI順序でタイブレークを行います。スコアリングの入力には、フォーカスノード、データグラフ、シェイプグラフ、プロパティシェイプ、スコアリンググラフが含まれます。必須入力の欠落や不正なスコアインスタンスがある場合は、推測されたウィジェットではなく、構造化されたエラーを生成する必要があります。
explicit widget -> accept matcher -> score candidates -> stable tie-break
-> label resolution -> component tree -> validation messages5. 言語とラベルの解決
ラベル解決では、シェイプグラフ、データグラフ、アプリケーション環境、ユーザー設定を考慮します。優先言語を最初に選択し、設定されたフォールバック順序に従います。適切なラベルがない場合は、IRIローカル名またはプロダクトで定義された安全なプレースホルダーを使用します。フィールドラベル、列挙値、バリデーションメッセージは単一の言語コンテキストを共有し、診断のために選択されたソースを記録する必要があります。
6. バリデーションと永続化を適切な境界に維持
SHACL UIドラフトはウィジェットの生成と処理を記述していますが、送信プロトコル、ストレージトランザクション、完全なエラー処理、認可モデルは定義していません。アプリケーションは送信前後に独立したバリデーターを呼び出し、フォーカスノード、パス、制約コンポーネント、メッセージのプロバナンスを表示する必要があります。同時編集の上書きを避けるためにバージョニングまたは条件付き書き込みを使用し、失敗時にはユーザーの編集状態と構造化された再試行結果を保持します。
7. 可観測性、キャッシング、セキュリティの追加
シェイプの変更により、コンポーネントとウィジェットのキャッシュが無効化されます。キャッシュキーには、シェイプバージョン、データグラフバージョン、言語、認可コンテキストを含める必要があります。信頼できないRDFがスクリプトや安全でないリンクにならないよう、リモートIRI、HTMLリッチテキスト、オートコンプリートソースを制限します。機密性の高いグラフ全体をログに記録することなく、シェイプ選択、ウィジェットの決定、バリデーションレイテンシ、ダウングレード理由をログに記録します。
高品質な回答例
レンダラーの入力をデータグラフ、シェイプグラフ、フォーカスノード、ノードシェイプの4つと定義します。後ろの2つが存在しない場合、呼び出し元が自動選択を実行し、説明可能な決定を返します。事前処理によりノードシェイプ、プロパティシェイプ、パスにインデックスを付け、各フォーカスノードとパスのペアに対する制約をプロバナンスとともに集約します。コンポーネントツリーを構築した後、ウィジェット選択では候補をスコアリングする前に明示的なウィジェットとaccept matcherをチェックし、安定したスコア、優先度、IRI順序でタイブレークを解決します。ラベル解決では、シェイプグラフ、データグラフ、環境全体でユーザーの優先言語とフォールバック言語を使用し、安全なローカル名へのフォールバックを備えます。すべての決定はそのルールソースを記録し、バリデーション結果にはフォーカスノード、パス、制約IDが保持されます。永続化、認可、同時実行制御、トランザクションは、ドラフト対象外のスタイリング、送信プロトコル、アクセシビリティ要件と同様にアプリケーション層に留まります。これにより、アダプター層がドラフトとともに進化できるようにしながら、実装間で一貫したフォームが実現されます。
よくある間違い
- SHACL UIを完全なローコードプラットフォームとして扱う → スコープが広すぎる → レンダリング、バリデーション、永続化、認可を分離する。
- 最初のプロパティシェイプのみを取得する → 制約が暗黙的に消滅する → プロバナンスを保持してフォーカスノードとパスごとに集約する。
- ランダムまたは走査順でウィジェットを選択する → 同一の入力が異なる形でレンダリングされる → スコアリング、優先度、安定したタイブレークを定義する。
rdfs:labelのみを読み取る → 言語フォールバックが失敗する → 言語解決を実装し、ソースを記録する。- RDFテキストをHTMLとしてレンダリングする → スクリプトインジェクションのリスク → 信頼できない値をエスケープし、ビューアの機能を制限する。
- 書き込み成功後にフォームを閉じる → 同時実行やバリデーションの失敗で編集内容が失われる → 条件付き書き込みを使用し、失敗状態を保持する。
フォローアップ質問と回答
フォーカスノードが複数のルートシェイプにマッチした場合はどうしますか？
アプリケーションに明示的なセレクターまたはビジネス優先度を提供させます。レンダラーは、ルールが十分に決定論的である場合にのみ自動選択し、理由とともに候補を返す必要があります。走査順序はビジネスルールではありません。
同一スコアのウィジェット間のタイブレークはどのように行いますか？
まず明示的なacceptルールとプロダクトの優先度を比較し、次に安定したウィジェットIRIまたは登録順序を使用します。デプロイによってインターフェースが暗黙的に変更されないよう、タイブレークポリシーをバージョニングします。
なぜレンダラー内でRDFを永続化しないのですか？
レンダラーは編集状態を保持できますが、送信プロトコル、トランザクション、認可、競合解決はアプリケーションのデータ層に属します。分離することで再利用が可能になり、サーバーが信頼できない入力を再検証できるようになります。
複雑なプロパティパスを入力フィールドにマッピングできない場合はどうしますか？
パスと値を読み取り専用で表示し、編集戦略が存在しないことを明記します。プロダクトが安全な読み取り/書き込み変換と競合ポリシーを提供した後にのみ編集を有効にします。書き込み可能に見えるが永続化できないフィールドを公開してはなりません。
実装間の一貫性をどのようにテストしますか？
データグラフ、シェイプグラフ、言語設定、スコアリンググラフを固定し、コンポーネントツリー、ラベルソース、ウィジェットIRI、順序付け、エラークラスをアサートします。適合性テストとダウングレードパスに対するプロパティレベルの回帰テストケースを追加します。