トリプルストアには多くのノードが含まれているため、RESTインターフェースを介してこのデータベースにアクセスできるようにする必要があります。
さて、私の解決策は、すべての名前付き（匿名ではない）ノードがリソースとしてエクスポートされることです。その表現は次のとおりです。
私はポイント番号2に少し気が進まない：これは基本的に着信と発信の両方のトリプルを与えるだろう。
純粋にRDF指向のデータストアのRESTスタイル表現についてどう思いますか？私の見解を共有しますか？共有しない場合、あなたはそれについてどう思いますか？
データが何であるか、およびインターフェースのユーザーがそれを使用して何をしたいかによって異なります。この質問は、SPARQL DESCRIBE クエリ フォームが返すべきものと似ています。(実装によって決定されます。)
私が RDF データで経験した使用例では、1 と 3 を使用して、リソースの空白ノード クロージャを生成します。さらに、ケース 2 用に別のインターフェイスを用意して、リソースの受信アークを返すこともできます。
RDF データセットを REST トラバース可能にする簡単な方法の 1 つは、トラバース可能なすべての要素に URL を使用することです。
たとえば HTTP GET を介して URL にアクセスすると、接続されたノード (プロパティおよび/または逆プロパティとして接続) が結果に表示されます。
より形式的には、返される表現は、リソースの簡潔な限定記述である可能性があります。
（免責事項：これは質問の内容と正確に一致しない場合がありますが、タイトルに対応しています）
RDF データの Rest 表現のトピックについては、概念の順序を逆にする一般的な問題だと思います。私にとって通常は、RDF データを含む Rest ドキュメントのコレクションを持ち、RDF データベースを使用してインデックスを作成し、グローバル クエリを作成することです。
この状況では、好みの方法でリソースを編成できます。
また (ノードの URI をエクスポートされたリソースとして使用するふりをする場合)、リソースの意味について微妙な問題が発生します。ここで提案する残りのリソースは「情報リソース」であり、抽象リソースにすることはできません。 . 情報とメタ情報の間に競合が発生します。
このビューをより詳細に説明する記事をここに公開しました。