概要
この文書は、インターネットクライアントが、コンテンツの適合先である
データ
プロファイル に基づいて、サーバーから提供されるコンテンツをネゴシエートする方法を説明する。これは、メディアタイプや言語によるネゴシエーションとは異なる。
プロファイル は、
返される情報の内容を指定でき、その情報は、応答するサーバーが要求されたリソースについて
持つ情報の一部である場合があり、実務コミュニティの相互運用性
要件を満たすために特定の方法で構造化される場合がある。
この文書のステータス
この節は、この
文書の公開時点におけるステータスを説明する。現在のW3C
公開物の一覧と、この技術レポートの最新版は、
W3C 標準と草案の
索引
この文書は、Dataset Exchange Working
Group により、
勧告
トラック を用いる
作業草案として公開された。
作業草案としての公開は、
W3C およびそのメンバーによる承認を意味しない。
これは草案文書であり、いつでも他の文書により更新、置換、または廃止される可能性がある。
この文書を、進行中の作業以外のものとして引用することは適切ではない。
この文書は、
W3C
特許
ポリシーW3C は、
グループの成果物に関連して行われた
特許開示の公開一覧
を維持している。そのページには、
特許を開示するための手順も含まれている。個人が実際に
認識している特許について、その特許が
必須請求項
を含むと信じる場合、その個人は
W3C 特許ポリシー第6節
この文書は、
2025年8月18日のW3C プロセス文書
に準拠する。
この文書は、W3C Dataset Exchange Working Group (DXWG)
およびInternet Engineering Taskforce (IETF)により編集された、プロファイルに関する一連の文書の1つである。
DXWG文書は次のとおりである。
[DX-PROF Profiles Vocabulary :
プロファイルと関連リソースを記述するRDF語彙
[PROF-CONNEG] この文書。プロファイルを用いてインターネットリソースの
コンテンツをネゴシエートする方法に関する具体的な指針 DXWGは、[PROF-GUIDANCE Profile
Guidance : プロファイリングに関する一般的な推奨事項と指針も提供する予定である。
次の文書は、IETFの管理のもとで維持されており、この文書の技術的
基盤を確立するが、DXWGの範囲には含まれない。
[PROF-IETF Indicating, Discovering, Negotiating, and Writing Profiled Representations : プロファイルによるHTTP
コンテンツネゴシエーションのためのHTTPヘッダーを定義する、IETF のInternet-Draft
目次
概要 この文書のステータス
プロファイルに関するDXWG文書の
概要
1. はじめに2. 適合性3. 定義4. 名前空間5. 動機6. 関連作業
6.1 HTTPヘッダーで
プロファイル情報を転送する既存の標準
6.1.1 Accept/Content Typeをprofile
パラメーターと併用する6.1.2
rel="profile"を持つLinkヘッダーを使用する (RFC 6906)6.1.3 Prefer/Preference-Appliedヘッダーフィールドを使用する (RFC
7240)
6.2 Archival
Resource Key (ARK)6.3 Linked
Data API6.4 OAI-PMH 6.5 Web用カタログ
サービス (CSW )
7. 抽象モデル
7.1 コンテンツ
ネゴシエーションの背景7.2 プロファイル
識別7.3
リクエストとレスポンス
7.3.1
プロファイル一覧7.3.2
プロファイルによるリソース取得
7.4 代替
表現データモデル7.5 実装プロファイルの
優先順位
8. 機能
プロファイル
8.1
この仕様の機能プロファイル8.2 Hypertext Transfer
Protocolヘッダー
8.2.1
プロファイル一覧8.2.2 プロファイルによるリソース取得
8.3 URLクエリ文字列
引数
8.3.1
QSA 機能プロファイルの
説明8.3.2
プロファイル一覧8.3.3 プロファイルによるリソース取得8.3.4
QSA キー発見
9. リンク
属性
9.1
トークン
10. テストスイート11.
実装12.
謝辞13. 変更点
13.1
前回草案からの変更点13.2
リスクのある機能
14. セキュリティ
とプライバシーA. 付録
A.1 項目別
要件
A.1.1 HTTPヘッダー機能プロファイルA.1.2
クエリ文字列引数機能プロファイルA.1.3 クエリ文字列引数代替キーワード機能
プロファイル
A.2
この仕様の機能プロファイルに関する
Profiles Vocabulary記述A.3 機能プロファイルへのシステム適合性の実証A.4 代替
表現データモデル - 詳細
A.4.1
実装A.4.2
拡張A.4.3 モデル利用の例
A.5
プロファイルによるコンテンツネゴシエーションをDCAT Distributionがサポートすることの記述
B. 参考文献
B.1
規範的参考文献B.2
参考情報文献
仕様
比較のための基礎。他のものを評価できる基準点。
出典: DCMI Metadata Terms [DCTERMS Standard
データ仕様
特定の文脈で使用されるデータの内容と構造を定義する、
人間および/または機械で処理可能な表現を持つ
仕様 。
出典: DXWGの審議。
機能仕様
特定の文脈におけるアプリケーションの振る舞いを定義する、
人間および/または機械で処理可能な表現を持つ
仕様 。
出典: DXWGの審議。
プロファイル
他の仕様の使用について制約、拡張、結合、または指針や説明を提供する
仕様 。
プロファイル化される仕様が、たとえばデータ仕様や機能
仕様のような特殊な種類の仕様である場合、そのプロファイルも同じ種類、
すなわちデータプロファイルまたは機能プロファイルになる。
このプロファイルによるコンテンツネゴシエーション仕様は、
データプロファイルのためのネゴシエーションを扱い、
これを実現するさまざまな方法について機能プロファイル を指定する。
この文書では、「profile」という用語のほとんどの出現は「data profile」を指す。
データプロファイル
他のデータ仕様の使用について制約、拡張、結合、または指針や説明を提供する
データ仕様 。
この定義には、「アプリケーションプロファイル」、「メタデータプロファイル」または
「メタデータアプリケーションプロファイル」と呼ばれることがあるものが含まれる。
出典: DXWGの審議。
機能プロファイル
他の機能仕様の使用について制約、
拡張、結合、または指針や説明を提供する
機能仕様 。
出典: DXWGの審議。
クライアント
1つ以上のHTTPリクエストを送信する目的で、サーバー への接続を確立するプログラム。
[RFC9110
サーバー
HTTPレスポンス を送信して
HTTPリクエスト に応答するために、
接続を受け入れるプログラム。[RFC9110
リソース
URIによって識別される実体。よく知られた例には、電子
文書、画像、一貫した目的を持つ情報源が含まれる。[RFC3986
表現
HTTP通信における、あるものの現在または望ましい状態の抽象化。[RFC9110
この仕様では、表現 はリソース のものである。
メタデータ リソースについて提供される情報。[RFC3986
リクエスト インターネット上で、クライアント からサーバー へ、
リソース に関する情報を求めて送信されるメッセージ。
[RFC9110
レスポンス インターネット上で、サーバー からクライアント へ、
リソース に関する情報のリクエスト に回答するために送信されるメッセージ。
[RFC9110
トークン 何かを識別する短い名前。この文書の文脈では、トークンは
プロファイル を識別するために使用されることがある。
この仕様で使用される名前空間と接頭辞の完全な集合を次の表に示す。
接頭辞
名前空間
altr
http://www.w3.org/ns/dx/connegp/altr#
dcat
http://www.w3.org/ns/dcat#
dcterms
http://purl.org/dc/terms/
ex
http://example.com/
owl
http://www.w3.org/2002/07/owl#
prof
http://www.w3.org/ns/dx/prof/
rdfs
http://www.w3.org/2000/01/rdf-schema#
sdo
https://schema.org/
skos
http://www.w3.org/2004/02/skos/core#
xsd
http://www.w3.org/2001/XMLSchema#
この節は、特定の環境での実装には依存しない、プロファイルによるコンテンツネゴシエーションの概念的な
― 抽象的な ― モデルを説明する。
異なる環境向けのこの抽象モデルの実装は、
機能プロファイル MUST である。
これをどのように行うかは環境固有である。
機能プロファイルは、独自の追加機能によってこの抽象モデルを拡張MAY であるが、
これらの追加はここで定義される関数を無効にしてMUST NOT である。
異なるデータプロファイルに準拠するリソースの表現を記述するためのデータモデルを
ここに示し、
このモデルはすべての機能プロファイルで使用MUST である。データモデルをどのように
実現するかは実装者の判断に委ねられる。実装されたデータモデルの適合性をどのように実証するかは、
ここでは詳細には扱わず、次の
指針のみを示す。実装者は、モデルの環境固有の実現と、
この仕様で与えられるモデルの具体的な実現、たとえばそのOWL
オントロジー表現 との間の公開されたマッピングを提供することにより、自らの代替
表現データモデル
実装の適合性を実証SHOULD である。
データプロファイル に準拠するリソース の表現を
要求 するクライアント は、
リソース をUniform Resource Identifier (URI)
[RFC3986 MUST であり、
プロファイル をURIまたはトークン のいずれかによって識別MUST である。
プロファイル識別にURIが使用される場合、それはプロファイルの記述へ逆参照されるHTTP URIである
べきである。
他の種類のURI、たとえばURNも使用MAY であり、これらは逆参照可能でない場合がある。
トークンが使用される場合、それはリクエスト /レスポンス のメッセージペア内で
データプロファイル を明確に識別MUST である。
サーバーは、トークンをURIにマッピングできる文脈を宣言MUST である。
プロファイルによるコンテンツネゴシエーションに関して、クライアント がサーバー に対して行い得る
リクエスト には、主に2つの型がある。この
仕様に従うプロファイルを通じてコンテンツをネゴシエートしたいクライアント は、これら2つのリクエスト型を実装できMUST である。
プロファイル一覧 クライアント は、サーバー が準拠する
リソース の表現 を配信できる
データプロファイル のURI一覧を要求する
プロファイルによるリソース取得
クライアント は、特定のプロファイル に準拠する、
要求されたリソース の表現 を要求する
この仕様に従うサーバー は、
各リクエストに対して、それぞれ次の
レスポンス で応答MUST である。
プロファイル一覧 サーバー は、準拠するリソース の表現 を配信できる
データプロファイル のURI一覧で
クライアント に応答する
プロファイルによるリソース取得 サーバー は、クライアント によって識別された
要求されたプロファイル に準拠する
リソース の特定のデータプロファイル 、または既定のデータプロファイル で応答する
これらのリクエストとそのレスポンスのより詳細な説明を次に示す。
クライアント は、サーバー がリソース の準拠する表現を配信できる
データプロファイル を知りたい。
プロファイル一覧は、特定のリソース 表現に対するリクエスト が行われる前に既知である場合もあれば、
初期リクエスト が
行われた後にのみ既知になる場合もある。
プロファイル一覧 リクエスト は、独立したリクエストであるか、別の
機能プロファイルのリクエストの一部でMUST ある。
プロファイル一覧 リクエスト は、リソースの表現が準拠する
データプロファイル がURIまたはトークン のいずれかによって
明確に識別されるなら、いくつかの形式のうちの1つによるレスポンス をもたらしMAY である。
後者の場合、それは1つの特定のクライアント/サーバーメッセージペア内でURIに
マッピング可能でMUST ある。
サーバー は、そのデータプロファイル を指定する
プロファイルによるリソース取得 リクエスト が提示されたときに配信できない
データプロファイル を一覧に含めてMUST NOT である。
例 4 は、
リクエストが特定のリソースに対するプロファイル一覧 リクエストである場合の、
QSA 機能プロファイルに準拠する
メッセージのリクエスト/レスポンスペアを示す。
例 4 :
単純なプロファイル一覧リクエストおよびレスポンスメッセージ (QSA機能
プロファイル)
# resource aの表現が準拠するすべてのプロファイルに対するリクエスト
GET /resource/a?_profile=alt HTTP/1.1
---
# サーバーはHTTPレスポンスヘッダーとレスポンス本文 (HTML) の両方で
# プロファイル一覧を返す。レスポンスメッセージを返す動作は
# QSA機能プロファイルに準拠しており、これは「profile」関係と組み合わせた
# Linkヘッダーによって示されることに注意。
HTTP/1.1 200 OK
Content-Type: text/html
Link: <http://www.w3.org/ns/dx/connegp/profile/qsa>; rel="profile"
# このLinkヘッダーは、Profile XおよびYに準拠する表現が利用可能であり、
# Profile X準拠の表現がHTMLおよびXMLメディアタイプで利用可能であることを示す。
Link:
<http://example.org/resource/a?_profile=profile-x&_mediatype=text/html>;
rel="canonical"; type="text/html";
formats="http://otherexample.org/profile/x",
<http://example.org/resource/a?_profile=profile-x&_mediatype=application/xml>;
rel="alternate";
type="application/xml";
formats="http://otherexample.org/profile/x",
<http://example.org/resource/a?_profile=profile-y&_mediatype=application/xml>;
rel="alternate";
type="application/xml";
formats="http://otherexample.org/profile/y"
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Resource Aのプロファイル</title>
</head>
<body>
<h1>Resource Xで利用可能なプロファイル</h1>
<ul>
<li><a href="?_profile=profile-x&_mediatype=text/html">X、HTML形式</a></li>
<li><a href="?_profile=profile-x&_mediatype=application/xml">X、XML形式</a></li>
<li><a href="?_profile=profile-y&_mediatype=application/xml">Y、XML形式</a></li>
</ul>
</body>
</html>
プロファイルによるコンテンツネゴシエーションの最も基本的なリクエスト は、クライアント がデータプロファイル に準拠すると主張される
リソース の表現を要求 することである。
プロファイルによるリソース取得 リクエスト を実行するクライアント は、
データプロファイル をURI、またはセッション内でURIに明確にマッピングされるトークンのいずれかによって
識別MUST である。
プロファイルによるリソース取得 を実行するクライアント は、
機能プロファイル固有の順序で表現された選好により、任意の数の
データプロファイル のうちの1つに準拠する
リソース 表現を要求 MAY である。
サーバーは、クライアントリクエストに最もよく一致するプロファイルで応答するよう試みるSHOULD である。
最もよく一致するプロファイルを決定するためにサーバーが従うMUST 優先順位は、
完全一致、その次にリソース表現が準拠する次に最も具体的なプロファイルである。
リソース表現は、階層を通じて (すなわち推移的に) より一般的な仕様や他のプロファイルに
準拠する場合があることに注意。
[RFC9110 HEADメソッドが使用される場合、レスポンスは、
本文が空でMUST である点を除き、ヘッダーおよびステータスコードを含めて
GETメソッドの場合と同じであるべきである。
レスポンスコンテンツの生成中にのみ値が決定されるヘッダーは、
省略MAY であることに注意することが重要である。
サーバーが別のリソースへリダイレクトする場合、クライアントにより要求された一覧から選択された
プロファイルの選択を示しMUST 、リダイレクトリクエスト (303レスポンス) において返されることが期待される
具体的なより狭いプロファイルを (既知であれば) 示すSHOULD である。
注記 :
別のリソースへのリダイレクト
プロファイルによるリソース取得 リクエストは
リソース の
表現 に対するものであり、
プロファイル準拠の表現を持つリソースが情報リソースではない場合があるため、サーバーのレスポンスが
別のリソースへのリダイレクトの形を取り得ることに注意することが重要である。これは、
いわゆる「httpRange-14」問題を扱うための
W3C の推奨事項に従うものである。
リダイレクトするレスポンスの例は
例 6 に示す。
HTTPヘッダー機能プロファイル に従って、
Accept-Profileおよび
Link: rel="profile"
ヘッダーを含む単純なリクエスト/レスポンスメッセージペアを
例 5 に示し、リダイレクトを伴う例を
例 6 に示す。
例 7 は、
要求されたプロファイルよりも狭いプロファイルのレスポンスを示すHTTP
ヘッダー機能プロファイルのメッセージペアを示す。
例 5 :
単純なプロファイルによるリソース取得リクエストおよびレスポンス (HTTPヘッダー機能
プロファイル)
# Profile xに従ったresource aへのリクエストが行われる
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>
---
# サーバーはProfile xに準拠するResource aの表現を返す
HTTP/1.1 200 OK
Link: <http://example.org/profile/x>; rel="profile"
[レスポンス本文]
例 6 :
303リダイレクトを伴うプロファイルによるリソース取得リクエストおよびレスポンス (HTTPヘッダー機能
プロファイル)
# Profile xに従った非情報リソースaへのリクエストが行われる
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>
---
# サーバーは、要求されたリソース表現を返す情報リソースを識別する
# 別のURIへの303 Redirectを返す。リダイレクトする
# サーバーは、リダイレクト先リソース表現が準拠するプロファイルを示す
HTTP/1.1 303 See Other
Location: http://example.org/info-resource/b
Link: <http://example.org/profile/x>; rel="profile"
---
# クライアントは今度は示された情報リソースを要求する。
# 元のレスポンスがリダイレクトレスポンスでそれを処理しているため、
# Accept-Profileヘッダーはもはや不要であることに注意
GET /info-resource/b HTTP/1.1
---
# 情報リソースを伴う最終的なサーバーレスポンス。この
# レスポンスにはプロファイルを示すLink rel="profile"ヘッダーが含まれないことに注意
HTTP/1.1 200 OK
[レスポンス本文]
例 7 : 準拠する、より狭いプロファイルで応答するプロファイルによるリソース取得
(HTTPヘッダー機能プロファイル)
# Profile Xに準拠する表現を持つResource Aへの
# リクエストが行われる
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>
[その他のリクエストヘッダー]
---
# サーバーは、Profile Xのプロファイルであることを知っている
# Profile Yに従って、Resource aの表現で応答できる
# サーバーは、リソース表現が準拠することを知っている
# プロファイルの一覧で応答し、要求されたプロファイルであるProfile Xが
# 一覧に含まれることを保証する。ここではProfile Yと、
# クライアントには無関係な追加プロファイルであるProfile Zが示される。
HTTP/1.1 200 OK
[その他のレスポンスヘッダー]
Link: <http://example.org/profile/x>; rel="profile", \
<http://example.org/profile/y>; rel="profile", \
<http://example.org/profile/z>; rel="profile"
[その他のレスポンスヘッダー]
[Profile X、YおよびZに準拠するコンテンツ]
同じプロファイル階層内にない2つ以上のプロファイルに準拠するリソースが返される場合
(すなわち、リソースはプロファイル集合に準拠するが、そのうちの一部は独立しており、
集合内の他のプロファイルの特殊化されたプロファイルではない場合)、サーバーは各独立プロファイルへの
準拠を示すSHOULD である。
たとえば、HTTPヘッダー機能プロファイルを使用する場合、
[GeoDCAT-AP STATDCAT-AP DCAT-AP DX-PROF DCAT-AP階層
例 を参照)、[GeoDCAT-AP STATDCAT-AP
Link: <https://joinup.ec.europa.eu/release/geodcat-ap-v10>; rel="profile", <https://joinup.ec.europa.eu/release/statdcat-ap/101>; rel="profile"
このデータモデルは、異なるプロファイルに準拠するリソースの表現を記述するために使用MUST である。
このモデルの図による概要を、図
1 に示す。
図 1
OWL [OWL2-OVERVIEW
異なるプロファイルに準拠するリソースの代替表現の記述は、このモデルを実装する
モデリングシステムに従って提示MAY であり、
これは、この仕様が作成されたアプリケーションプロファイルに関連すると見なされるものに依存する。たとえば、
HTTPアプリケーションプロファイル (8.2
Hypertext Transfer ProtocolヘッダーRFC9110
このデータモデルのいくつかの実装に対するデータインスタンスの適合性をテストするためのツールは、
10. テストスイートA.4
代替表現データモデル - 詳細
サービスは、HTTP、QSA 、および場合によってはその他のアプローチを含む、複数の機能
プロファイル を実装MAY である。
そのような場合、クライアントは、たとえば既定のヘッダーを送信しつつ特定の表現を要求するという一般的な場合のように、
異なる機構を通じて競合する選択を指定することがある。
ここで定義される優先順位は、どの機構を使用MUST であるかを決定する。
優先順位は、HTTPよりもQSA を優先する。
これは、URIがより正確にリソースを指すほど、
そのリクエストでどのHTTPヘッダーが送信されるかにかかわらず、
エージェントがその正確なリソースを要求する意図を持つ可能性が高いという根拠に基づく。
抽象モデルの他の潜在的に競合する機能プロファイルが定義される場合、
優先順位を確立する必要がある。
これをどのように宣言するかについて、特定の機構は提案されていない。
この節は、異なるシステム環境向けに、この
仕様 の抽象モデル の
機能プロファイル を定義する。その他のプロファイルも定義され得る。
抽象モデルに準拠する任意のプロファイルへの適合は、この仕様への適合を満たす。
この仕様は、HTTPヘッダーおよび人間のブラウザー(URLクエリ文字列
引数)という2つの環境向けに、抽象モデルの機能プロファイルを提供する。
さらに、Resource Representation Description
(cnpr:rrd
人間のブラウザー環境については、異なる使用モードを示すために2つの機能プロファイルを提示する。
この仕様のさらなる機能プロファイルは、他の環境向け、またはこれらの環境内の
制約されたシナリオ向けに実装MAY であり、実装者はこの
仕様に準拠する追加のプロファイルを作成することが推奨される。
ここで事前定義されるこの仕様の機能プロファイルは、図
2 に一覧表示される。
それらの名前空間接頭辞は次のとおりである。
cnpr → http://www.w3.org/ns/dx/connegp/profile/
図 2
リソースおよびシステムが、その1つ以上の形式への適合を示すために使用する、
このContent Negotiation by Profile 仕様のプロファイル。
上記の機能プロファイルに使用される名前空間
http://www.w3.org/ns/dx/connegp/profile/は、Dataset Exchange Working Groupの
予約済みW3C 名前空間
http://www.w3.org/ns/dx/の一部であり、そのWorking Groupが扱う課題に関する
すべての名前空間要件のために用意されている。/profile/パスセグメントは、
現在図
2 の上記4つのインスタンスのみを含むプロファイルオブジェクトの登録簿を示す。
Hypertext Transfer Protocol (HTTP)ヘッダーを使用する抽象モデルの機能プロファイルをここに提示する。
この実装はHTTPコンテンツネゴシエーションに基づき、特定の方法で構成された
Linkヘッダーと、今後の
Internet-Draft [PROF-IETF Accept-Profileを使用する。
注記 : POST/PUTは
範囲外
POSTおよびPUTメソッドは、この機能プロファイルの範囲外と考えられる。
これらのHTTPメソッドが、提案された抽象モデルのどの関数を実装するのかは明確ではない。
リクエストメッセージのコンテンツの適合性を伝達するために、rel="profile"を持つ
LinkヘッダーをPOSTおよびPUT
リクエストで指定してもよい。
サーバーは適切と考える方法で自由にネゴシエーションを実装できるが、
User AgentがAccept-Profileヘッダーを送信する場合、
サーバーは、列挙されたどのプロファイルにも準拠しない表現を、
クライアントが解釈できないものと見なすSHOULD である。
これは、列挙されたプロファイルに準拠するが、
他の次元で低い選好スコアを持つ表現は、
他の次元でより高い選好スコアを持つが列挙されたどのプロファイルにも準拠しない
表現よりも望ましいものと見なすSHOULD であることを意味する。
Accept-Profileヘッダーによる選好が与えられない場合、
プロファイル次元はネゴシエーション目的では無視するSHOULD である。
それにもかかわらず、すべての場合において、
サーバーのレスポンスは、表現が準拠するとサーバーが知っているすべてのプロファイルのURIを列挙する
rel="profile"を持つLinkヘッダーを
含むSHOULD である。
特定のリソースについてサーバーがサポートするプロファイル一覧を取得する好ましい方法は、
そのリソースに対してGETまたはHEADリクエストを発行することである。
どちらの場合でも、プロファイルによるコンテンツネゴシエーションを実装するサーバーは、
そのリソースの既定表現および任意の代替表現に関する情報を、それらが準拠するプロファイルを含めて含む
HTTP Linkヘッダーを返すSHOULD である。
既定表現、すなわち特定の表現が要求されない場合に返されるものは、
rel="canonical"によって識別し、その他の表現は
rel="alternate"によって識別するSHOULD である。
例として、メディアタイプapplication/xml、text/htmlおよび
text/turtleで利用可能なリソースhttp://example.org/resource/aを考える。
text/html表現にはプロファイルがないが、
application/xmlおよびtext/turtle表現は、
いずれもプロファイルurn:example:profile:xおよび
urn:example:profile:yで利用可能である。
Accept-Profileヘッダーを伴わないリクエストが既定で
urn:example:profile:xに準拠するコンテンツを配信すると仮定すると、
HTTPリクエスト/レスポンスペアは例 8 のようになる。
例 8 では、異なる
メディアタイプ/プロファイルの組み合わせごとに、
リソースのURIは変更されず、返されるレスポンスを変更するのは、
それぞれメディアタイプおよびプロファイルのためのAcceptおよびAccept-Profile
ヘッダーである。
サーバーは、メディアタイプ/プロファイルの組み合わせに従ったリソースの表現への直接リンクを示すために、
Content-Location HTTPヘッダーを使用MAY であり、
その場合は、Linkヘッダー内の変更されないURIを、例
機能プロファイル実装は、抽象モデルの関数を実装することに加えて、
代替表現データモデルに従って代替表現情報を提供できることを保証する必要がある。
このHTTPヘッダー機能プロファイルでは、これを行うために選択された仕組みは、
以下に説明するように、[RFC8288 Linkヘッダーである。
HTTP Linkは、[RFC8288
リンクコンテキスト 、リンクターゲット 、リンク関係型 、および
任意でターゲット属性 。
リンクコンテキスト は、Linkヘッダーが配信される対象のリソースである。
関係型 はrel属性キー名で与えられ、リンクターゲット はURIであり、その他の任意の
ターゲット属性 には、profile属性キー名で与えられるprofile が含まれ得る。
例 9 では、
リンクコンテキスト resource/aへのリクエストに対して返されるLinkヘッダーの最初の部分は、
次の部分を持つ。
リンクターゲット - <http://example.org/resource/a.prof1.ttl>関係型 - rel="canonical"ターゲット属性 - type="text/turtle"および
formats="urn:example:profile:x"
これらのLink HTTPヘッダー部分を使用することで、このHTTPヘッダー機能プロファイルは、
代替プロファイルデータ
モデル に従ってリソースの代替データプロファイルを伝達できる。
そして下記の図
3 は、ヘッダー部分をデータモデルのOWLオントロジー 表現へ対応付ける。
これは、その具体的かつ形式的な実現である。この対応付けは、7.
抽象モデルSHOULD である」に従って提示される。
HTTPサーバー が、URIによるプロファイル の必須識別に加えて、
クライアント がトークン を介して
プロファイル を識別できるようにしたい場合、
サーバー は、サポートされる各トークンについて、それがどのプロファイルURIに対応するかを
示すSHOULD である。
この仕様のHTTPヘッダー機能プロファイルを実装する場合、
サーバーはレスポンス内に、各profile URI/tokenペアについて
Linkヘッダー([RFC8288 MUST である。
各LinkヘッダーはLink Target
"http://www.w3.org/ns/dx/prof/Profile"を使用MUST であり、
次のTarget Attributeを含めMUST である。
ターゲット属性
ターゲット属性値
rel"type"
tokenanchor属性内のプロファイルURIに対応付けられるトークン
anchortoken属性内のトークンに対応付けられるプロファイルのプロファイルURI
トークン/URI対応付けを伝達するために使用されるLinkヘッダーの例を、
例 11 に示す。
例 11 :
Link属性「token」を使用してプロファイルURIをトークンに結び付ける
# "anchor"要素内のプロファイルURIは、トークン"igsn-r1"に結び付けられる
# さらに、関係"type"は、anchorリソースが"dcterms:Standard"型であることを
# 通知するために使用される
Link: <http://www.w3.org/ns/dx/prof/Profile>;
rel="type";
token="igsn-r1";
anchor=<http://schema.igsn.org/description/1.0>
サーバーは、トークン/URI対応付けと並んで、たとえば代替表現データモデルのコンテンツなど、
さらに多くの属性をLinkヘッダーに追加MAY である。
例
12 は、複数の属性を持つLinkヘッダーのトークンを示す。
例 12 : 'token'パラメーターを使用したプロファイルURI/トークン対応付けを持つHTTPヘッダー
# URI urn:example:profile:marc21-dnbを持つProfileはトークン"dnb"に対応付けられ、
# URI http://example.org/profiles/marc21-locを持つProfileはトークン"loc"に対応付けられる
HEAD /resource/a HTTP/1.1
Accept: text/turtle
[その他のリクエストヘッダー]
---
HTTP/1.1 200 OK
Content-Type: text/turtle
Content-Location: http://example.org/resource/a.profx.ttl
Link: <urn:example:profile:x>; rel="profile"
Link:
<http://www.w3.org/ns/dx/prof/Profile>; rel="type"; token="dnb"; anchor=<urn:example:profile:marc21-dnb>,
<http://www.w3.org/ns/dx/prof/Profile>; rel="type"; token="loc"; anchor=<http://example.org/profiles/marc21-loc>,
<http://example.org/resource/a.profdnb.ttl>; rel="canonical"; type="text/turtle"; formats="urn:example:profile:marc21-dnb",
<http://example.org/resource/a.profloc.ttl>; rel="alternate"; type="text/turtle"; formats="http://example.org/profiles/marc21-loc",
<http://example.org/resource/a.profdnb.xml>; rel="alternate"; type="application/xml"; formats="urn:example:profile:marc21-dnb",
<http://example.org/resource/a.profloc.xml>; rel="alternate"; type="application/xml"; formats="http://example.org/profiles/marc21-loc",
<http://example.org/resource/a.html>; rel="alternate"; type="text/html"
[その他のレスポンスヘッダー]
特定のプロファイルに準拠するリソース表現の取得は、
リソースに対してHTTP GETリクエストを発行し、
望ましいプロファイルURIをAccept-Profileヘッダーで指定することで行われる。
プロファイルによるコンテンツネゴシエーションを実装するサーバーは、
返されたプロファイルを示すrel="profile"を持つ
Linkヘッダーを含むHTTPレスポンスヘッダーで応答MUST である。
リクエストおよびレスポンス内のURIは、いずれも山括弧
'<'および'>'で囲まれMUST である。
受け入れ可能なプロファイルURIの範囲を提供MAY であり、提供される場合、
それらはコンマで区切られるか、別々のAccept-Profileヘッダー内に
置かれMUST である。
選好は、クライアントにより品質指標(q値)を順序付け機構として使用して示しMAY であり、
URIからセミコロン「;」で区切られる。q値を持つURI(この場合はURN)の例は
<urn:example:profile:x>;q=1.0,であり、URIは
<urn:example:profile:x>、q値はq=1.0である。
例 13 は、
リソース/resource/aに対する単純なリクエストを示す。このリクエストは、
URI(この例ではURN)urn:example:profile:xおよび
urn:example:profile:yで識別されるプロファイルに従う表現への選好を持ち、
'q'値は前者へのより高い選好を示す。サーバーによって返されるレスポンスは、
rel="profile"を持つLink HTTPヘッダーにその識別子を含めることで、
urn:example:profile:xへの適合を示す。
例 13 :
HTTPヘッダーを使用して特定のプロファイルに準拠するリソース表現を要求する
GET /resource/a HTTP/1.1
Accept: text/turtle;q=0.8, application/xml;q=0.5
Accept-Profile: <urn:example:profile:x>;q=1.0,<urn:example:profile:y>;q=0.6
[その他のリクエストヘッダー]
---
HTTP/1.1 200 OK
Content-Type: text/turtle
Link: <urn:example:profile:x>; rel="profile"
[その他のレスポンスヘッダー]
コンテンツネゴシエーションを実行してリソース表現を返した後、サーバーは、
8.2.1 プロファイル一覧RECOMMENDED である。
HTTPヘッダー機能プロファイルのプロファイルネゴシエーション手法は、プロファイルによる完全に自動化された
コンテンツネゴシエーションを可能にするが、
この仕様の動機となるユースケースには、人間が操作可能なネゴシエーションも含まれていた。
また、6. 関連作業
人間が操作可能なプロファイルによるコンテンツネゴシエーションを可能にするとともに、
既存システムに類似した仕組みがこの仕様の抽象モデルのすべての側面をどのように満たし得るかを示すために、
この節は抽象モデルのクエリ文字列引数(QSA )機能プロファイルを示す。
この機能プロファイルは、抽象モデルのすべての必須関数がサポートされるという点で
HTTPヘッダー機能プロファイルと機能的に同等であるが、
HTTPまたはその他の機能プロファイルと相互排他的ではない。
この仕様の実装は、複数の環境または同じ環境内の異なる方法で
プロファイルによるコンテンツネゴシエーション機能を実装するために、
複数の機能プロファイルに適合してもよい。
独立したIETF文書
[PROF-IETF QSA 機能プロファイルはここで完全に指定される。
このQSA 手法には2つの形式が提示される。
1つ目は固定キーワードの「QSA 機能プロファイル」であり、
2つ目はサーバーが任意のキーワードを実装できる
「QSA 代替キーワード機能プロファイル」である。
これらのさまざまな機能プロファイルは、
8.1
この仕様の機能プロファイル
注記
システムがこれらの機能プロファイルのいずれか1つ、または複数に適合することは、
A.3
機能プロファイルへのシステム適合性の実証に従って実証され得る。
すべてのシステムがそうするわけではないため、システム、おそらくサーバーが、
この仕様で説明される1つ以上の機能プロファイルへの適合を示すことは必須ではないことに注意。
システムは、サービスカタログ内の注釈付きエントリーなど、複数の方法で
機能プロファイルへの適合を示してもよい。
クエリ文字列は、指定されたパラメーターに値を割り当てるURLの一部である。
QSA は、Webブラウザー内で人間により、またその他の
クライアント /サーバー 状況で、
サーバー に追加情報を配信するために一般的に使用される。
クエリ文字列のキー/値ペアは、URIのスキーム、オーソリティ、およびパスから
疑問符記号?で区切られ、等号記号
=で結合されたキー/値ペアで構成され、各キー/値ペアはアンパサンド記号
&で互いに区切られる。これは
[RFC3986
QSA を使用して実装されたプロファイルによるコンテンツネゴシエーションを伴う
リソース要求URIの例を、例 14 に示す。
例 14 :
QSAを使用して実装されたプロファイルによるコンテンツネゴシエーションを伴う
リソース要求URIの例
http://example.com/path/to/resource/a?_profile=prof-01
例 14 では、
リソース表現について要求されたプロファイルはトークンprof-01によって示され、
これはクエリ文字列引数としてリソースのURIに追加されMUST である。
この仕様の7.3.1 プロファイル
一覧トークン がプロファイル
prof-01の識別に使用されるが、そのトークンは1つの特定の
クライアント/サーバーセッション内でURIにマッピング可能でMUST であり、
そのための仕組みを以下に説明する。
追加のQSA またはその他の手法(たとえばHTTPヘッダー)の使用により、
コンテンツネゴシエーションの追加の側面をそのようなURIに含めMAY であるが、
含める場合、それらはプロファイルによるコンテンツネゴシエーションのためのリクエストの動作を
変更してMUST
NOT である。許容される包含を示すために、
例 14 のURIを使用するクライアントが、
リクエストのコンテンツをRDFとして、Turtle [TURTLE IANAメディアタイプ一覧 のトークンである
text/turtleを使用し、
URI構成要件 [RFC3986 例 15 のようにURIを構成できる。
例 15 :
プロファイルおよびメディアタイプによるコンテンツネゴシエーションを伴う
QSA URIの例
http://example.com/path/to/resource/a?_profile=prof-01&_mediatype=text/turtle
注記 :
URLの最大長
クエリ文字列引数が重要な情報を伝達するためにURI(またはURL)を使用する場合、実装者は、
URI/URLを使用する
QSA を含む要求URI全体の総長が長さ制限を超えないようにすべきである。
[
RFC9110 ]の
§4.1 は、
送信者および受信者が少なくとも8,000オクテットのリクエスト行をサポートすることを推奨している。
しかし、一部のクライアントおよびサーバー実装は2,000文字を超えるURLを受け入れられない。
たとえば、SitemapプロトコルではURLに2,048文字の長さ制限がある。
URL長に関連する問題についてのより長い議論については、
stackoverflowのこの質問 を参照。
この仕様には、クエリ文字列引数を使用する人間クライアント向けに、
QSA キー命名要件によって区別される2つの異なる機能プロファイルが含まれる。
2つのプロファイルは「QSA 機能プロファイル」と
「QSA 代替キーワード機能プロファイル」であり、
前者は後者のプロファイルである。これは、前者がこの仕様の必須機能を実現する方法について、
より厳格な適合規則(「より狭い」規則)を含むためである。
これらの機能プロファイルは、
8.1
この仕様の機能プロファイル
「QSA 機能プロファイル」に準拠するためには、
QSA キー_profileを
プロファイルトークンまたはURIを示すために使用MUST であり、キー_mediatypeはリソース表現のメディア
タイプを示すために使用SHOULD である。
「QSA 代替
キーワード機能プロファイル」に準拠する場合、[RFC3986 MAY である。
ただし、この機能プロファイルに準拠するサーバーは、以下の
8.3.4 QSA キー発見MUST である。
「QSA 機能プロファイル」への適合のため、
_profile QSA キーは、
クライアント がプロファイル一覧 リクエスト を行えるようにするために、
サーバー により
サポートされるSHOULD である。この
リクエストでは、予約済みトークンaltを使用するSHOULD である。
例: _profile=alt。
「QSA 代替キーワード機能
プロファイル」への適合のためには、_view=alternatesなどの他のキー/値ペアを使用MAY である。
ただし、その場合、実装するサーバーは
8.3.4 QSA キー発見MUST である。
プロファイル一覧 リクエスト に対する
サーバー のレスポンス は、
そのリソースの表現についてサポートするすべてのプロファイルの一覧、および任意でそれらの表現に対応する
サポートされるメディアタイプを提示することであるSHOULD 。
サーバーは、HTTPヘッダー機能プロファイルに従い(Linkヘッダーを使用して)、
レスポンス のHTTPヘッダー内に代替プロファイル情報を表現する
SHOULD であり、リソースの既定プロファイル表現の代わりに、
レスポンス本文内にもその情報を表現MAY である。
この本文コンテンツの許可は、人間が低レベルのHTTP情報を表示する必要なく、
Webブラウザーでリソースの代替プロファイル準拠表現の選択肢を容易に読めるようにするためである。
サーバーがHTTP本文内に代替プロファイル情報を提供する場合、
サーバーは、以下のプロファイルによるリソース取得 関数で使用されるものと同じ
メディアタイプネゴシエーション方法を使用して、
クライアントがレスポンスの特定のメディアタイプについてネゴシエートすることを許可MAY である。
HTTP本文コンテンツおよびHTTPヘッダーコンテンツとしてJSON形式で配信される
リソース の代替プロファイル表現に対するリクエスト の例は、
例 16 のようになる。
QSA 機能プロファイルに従うこの仕様の実装は、
代替表現データモデルに従ってその代替表現情報を伝達MUST である。
それらは、HTTPヘッダー機能プロファイルに従ってHTTP Linkヘッダーを使用して
そうしてもMAY よく、また他のアプローチを使用してもMAY よい。
[RFC8288 Web Linking )の導入で述べられているように、
HTMLおよびその他のいくつかのデータモデルには「明確に定義されたリンクの概念」があるため、
QSA 実装者は、HTMLまたは他のデータモデル/形式で、
おそらくHTTP本文コンテンツを介して代替表現データモデル情報の伝達を実装MAY である。
これは、QSA 実装の人間のクライアント
利用者にとって、Webブラウザー内またはダウンロード可能なファイル内で可視になることにより役立つ場合がある。
例 10 の
Linkヘッダー情報の潜在的なHTML表現を、
以下の例 17 に示す。
上記の例 16 は、
代替表現データモデルに従ったLinkヘッダー情報の潜在的なJSON形式表現を示していることに注意。
例 17 :
前の例のLinkヘッダー情報のHTML表現
# 前の例のLinkヘッダーのうち1つを変更し、altp:Representationクラスインスタンスについて
# 空白ノードと絶対URIの違いを示す
# (<http://example.org/resource/a>; → <http://example.org/resource/different>;)
Link:
<http://example.org/resource/a>;
rel="canonical";
type="text/turtle";
formats="urn:example:profile:x",
<http://example.org/resource/a>;
rel="alternate";
type="text/turtle";
formats="urn:example:profile:y",
<http://example.org/resource/a>;
rel="alternate";
type="application/xml";
formats="urn:example:profile:x",
<http://example.org/resource/different>;
rel="alternate";
type="application/xml";
formats="urn:example:profile:y",
<http://example.org/resource/a>;
rel="alternate";
type="text/html"
# 上記のLinkヘッダーをHTMLで表現したもの。
# Alternate Profileのrdfs:Resourceは、このレスポンスを生成したリクエストから既知であり、
# HTMLコンテンツ内では与えられないと仮定する
<h3>代替表現</h3>
<table>
<thead>
<tr>
<th>表現へのリンク</th>
<th>プロファイル</th>
<th>メディアタイプ</th>
<th>既定か？</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="?_profile=x">Profile X、RDF</a></td>
<td><code>urn:example:profile:x</code></td>
<td><a href="https://w3id.org/mediatype/text/turtle">RDF (turtle)</a></td>
<td>はい</td>
</tr>
<tr>
<td><a href="?_profile=y&_mediatype=text/turtle">Profile Y、RDF</a></td>
<td><code>urn:example:profile:y</code></td>
<td><a href="https://w3id.org/mediatype/text/turtle">RDF (turtle)</a></td>
<td>-</td>
</tr>
<tr>
<td><a href="?_profile=x&_mediatype=application/xml">Profile X、XML</a></td>
<td><code>urn:example:profile:x</code></td>
<td><a href="https://w3id.org/mediatype/application/xml">XML</a></td>
<td>-</td>
</tr>
<tr>
<td><a href="http://example.org/resource/different?_mediatype=application/xml">Profile Y、XML</a></td>
<td><code>urn:example:profile:y</code></td>
<td><a href="https://w3id.org/mediatype/application/xml">XML</a></td>
<td>-</td>
</tr>
<tr>
<td><a href="?_mediatype=text/html">プロファイルなし、HTML</a></td>
<td>-</td>
<td><a href="https://w3id.org/mediatype/text/html">HTML</a></td>
<td>-</td>
</tr>
</tbody>
</table>
現在、メディアタイプによるHTTPコンテンツネゴシエーションの慣例では、
text/htmlやapplication/ld+jsonなどのメディアタイプにトークンを使用し、
そのトークンはIANAのメディアタイプ一覧 に登録されている。
プロファイルによるコンテンツネゴシエーションシステムの実装者は、メディアタイプ識別子にはその一覧のトークンを使用し、
他のコンテンツネゴシエーション次元(言語など)の識別子についてはHTTP
コンテンツネゴシエーションのベストプラクティスに従うSHOULD である。
注記 :
メディアタイプでのURI
使用
IANAのトークンに基づいてメディアタイプのURIを作成した取り組みがいくつか存在する。
たとえば
conneg.info である。これらのURIはメディアタイプを示すために使用できる。
プロファイルの中央登録簿を作成する提案はない。これは、確立される可能性の高いプロファイルの数と、
プロファイルがコミュニティ固有の性質を持つ可能性が高いこと
(個々のコミュニティは、自身の必要に応じたプロファイルを作成し、それらは広く関連するものではない)を考えると、
長期的には持続不可能であると、これらの著者が考えているためである。
7.2 プロファイル
識別MUST である。
URIは普遍的に一意であり、識別子の重複を避けるための登録を必要としないためである。
ただし、この仕様のQSA 機能プロファイルのいずれかに準拠するシステムは、
クライアント/サーバー相互作用中にプロファイルを識別するためにURIを使用する代わりに、
未登録で普遍的には一意でないトークンを使用してプロファイルを識別MAY である。
しかし、その場合、クライアントがプロファイルトークン/URI対応付けを発見する方法を提供
MUST である。
プロファイルURI用のトークンをクライアントに利用可能にしたいQSA サーバーは、
8.2.1.2
トークン対応付けSHOULD である。
QSA ベースのプロファイルネゴシエーションが行われるリソースURLは、
どのQSA ベースのシステムにおいても、他のリソースURIの
QSA 値そのものになるべきではないSHOULD NOT 。
そのような仕組みは内部的に使用される場合があり、従来システムではプロファイルネゴシエーションに使用されるが、
これらのQSA プロファイルへの適合をより認識しやすくするために、
クライアント からは隠すのが望ましい。
例 18 はこれを示す。
例 18 : リソースURLは、それ自体が他のURLのパラメーターであるべきではない
Media Type Zで、Profile Yに従うResource Xの表現について:
次の代わりに:
GET /single/endpoint \
?resource=http://example.org/resource/X \
&_profile=Y \
&_mediatype=Z HTTP/1.1
次を使用する:
GET /resource/X?_profile=Y&_mediatype=Z HTTP/1.1
この仕様の「QSA 機能プロファイル」プロファイルに適合するために、
サーバー は、
クライアントが_profileクエリ文字列で識別するプロファイルに従って
リソースを要求できるようにしMUST である。
プロファイルの識別にはトークン またはURIのいずれかを使用できるため、
サーバーはどちらも受け入れMUST である。サーバーは符号化されたURIと符号化されていないURIの両方を受け入れ
MAY であるが、一方のみを受け入れMAY でもある。
URIは山括弧'<'および'>'で囲まれMUST である。
この仕様の「QSA 代替キーワード
機能プロファイル」プロファイルに適合するために、
サーバー は、
サーバー実装者が選択したキーで識別するプロファイルに従って、
クライアントがリソースを要求できるようにしMUST である。
ただし、その場合、サーバーは
8.3.4 QSA キー発見MUST である。
プロファイルによるリソース取得 を実装するQSA
サーバー は、
複数のプロファイルのうち任意の1つに従うリソース表現への選好をクライアントが示せるようにする
SHOULD である。そのようなリクエストは、プロファイルを識別するために使用される
QSA キー/値ペアの値の中に、
プロファイル識別子(URIまたはトークン)の順序付き一覧を含めることによって
プロファイル選好を示しMUST である。
たとえば、リソース表現について、profile-z、次に
http://example.org/profile/y、最後に
profile-xの順で選好するクライアントは、次のようなリクエストを行うことができる。
GET /resource/a?_profile=profile-z,<http://example.org/profile/y>,profile-x
サーバーは、レスポンス内にrel="profile"を持つ
Link HTTPヘッダーを含めることにより、実際に返されたプロファイルを示し
MUST であり、返されたプロファイルを他の方法でも示し
MAY である。サーバーはプロファイルを識別するエスケープ済みURIをサポートする
SHOULD であり、エスケープされていないURI、またはその両方もサポートMAY である。
リソース表現について複数のメディアタイプ形式を実装するサーバーは、
同様の方法でクライアントがそれらの選好順序を指定できるようにするSHOULD である。
この関数は、この仕様の「QSA 代替キーワード
機能プロファイル」プロファイルへの適合を主張するサーバーにのみ関連する。
「QSA 代替
キーワード機能プロファイル」への適合を主張するサーバーは、
「QSA 機能プロファイル」の_profileの代わりに使用される
QSA キーと、
任意のキー/値の組み合わせによって実装されることが求められる_profile=altの同等物を、
クライアントが発見できるようにする方法を実装MUST である。
これにより、サーバーについてほとんど知らないクライアントが、
プロファイル一覧 およびプロファイルによるリソース取得 リクエストの作成方法を発見できる。
サーバーは、メディアタイプおよびその他のコンテンツネゴシエーション次元を示すために使用される
QSA キーもクライアントが発見できるようにする
SHOULD である。
「QSA 代替キーワード機能プロファイル」がサポートされるリソースへの任意のリクエストに応答するサーバーは、
HTTP機能プロファイルに従って、代替プロファイルおよびメディアタイプを示すHTTPヘッダーを含める
SHOULD である。
その代わりに、またはそれに加えて、同じ情報を示すHTTP本文コンテンツを提供
MAY である。そうする場合、そのような情報はURIリクエストに対する既定レスポンス、
すなわちQSA を伴わないリクエストへのレスポンス内に存在する
SHOULD である。
一連のリクエスト例を例 19 に示す。
例 19 : QSAキー発見のためのリクエストおよびレスポンスの例
# クライアントはContent Negotiation by Profileがサポートされているかどうかを知らずに
# Resource Aへのリクエストを行う。念のためAccept-Profile
# ヘッダーを提供する。効率を高めるため、クライアントはGETの代わりに
# HEADリクエストを行うこともできた
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>
# サーバーはHTTP Get Resource By Profileリクエストを理解しない
# (HTTPヘッダー機能プロファイルをサポートしない)が、
# 代替リソース表現を示すHTTP Linkヘッダーを提供できる。
# Linkヘッダーから、_profileおよび_mediatype以外のキー、
# viewおよびformatが使用されていることが分かる。したがって、これは
# QSA機能プロファイル準拠システムではなくQSA Altである。
# 利用可能なリソース表現はprofile-xおよびprofile-yに準拠する。
# profile-x準拠表現はHTMLおよびTurtleで利用可能であり、
# profile-y準拠表現はXMLでのみ利用可能である。
HTTP/1.1 200 OK
Link:
<http://example.org/resource/a?view=profile-x&format=text/html>;
rel="canonical";
type="text/html";
formats="http://otherexample.org/profile/x",
<http://example.org/resource/a?view=profile-x&format=text/turtle>;
rel="alternate";
type="text/turtle";
formats="http://otherexample.org/profile/x",
<http://example.org/resource/a?view=profile-y&format=application/xml>;
rel="alternate";
type="application/xml";
formats="http://otherexample.org/profile/y"
# ここでは、サーバーが提供されたプロファイルを直接示していない
# (rel="profile"を持つLinkヘッダーは存在しない)が、
# rel="canonical"を持つLinkヘッダーから推論できることに注意
上記の例 19 のLinkヘッダーは、
プロファイル一覧 リクエストが行うすべての情報を伝達するが、
Webブラウザーでは直接見えない。例 16 は、
プロファイルを一覧表示する同等のLinkヘッダーおよびHTTP本文情報を含む
リクエスト/レスポンスペアを示している。後者はブラウザーで可視であるが、
このリクエストを構成するクライアントは、サーバーの既定リソース表現ではなく、
このレスポンスを起動するためにQSA キー/値ペア
_profile=altが使用されることを知っていることに依存している。
「QSA 代替
キーワード機能プロファイル」に適合する場合、プロファイル一覧 に使用される
QSA キー/値ペアをクライアントに伝達するために、
サーバーは、上記のプロファイル一覧 通信の方法に従い、
リソースの表現がURI
http://www.w3.org/ns/dx/conneg/altrによって識別される
代替プロファイルデータモデルに準拠して利用可能であることを示す
SHOULD である。これは、
例 20 で示されており、
例 19 への拡張である。
例 20 : 代替プロファイルデータモデル準拠レスポンスを示す前の例の拡張
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>
--
HTTP/1.1 200 OK
Link:
<http://example.org/resource/a?view=profile-x&format=text/html>;
rel="canonical";
type="application/html";
formats="http://otherexample.org/profile/x",
<http://example.org/resource/a?view=profile-x&format=text/turtle>;
rel="alternate";
type="text/turtle";
formats="http://otherexample.org/profile/x",
<http://example.org/resource/a?view=profile-y&format=application/xml>;
rel="alternate";
type="application/xml";
formats="http://otherexample.org/profile/y"
<http://example.org/resource/a?view=altrep&format=application/ld+json>;
rel="alternate";
type="application/ld+json";
formats="http://www.w3.org/ns/dx/connegp/altr"
[既定レスポンスコンテンツ]
例 20 は、
リソース/resource/aについて、
7.4 代替
表現データモデルhttp://www.w3.org/ns/dx/connegp/altrという仕様/プロファイルに準拠する表現が存在することを示す。
この例はまた、QSA view=altrepを使用して、
代替プロファイルデータモデル準拠レスポンスへのリクエストを構成できることも示している。
したがって、http://example.org/resource/a?view=altrep
を逆参照すると、/resource/aの既定表現ではなく、
例 20 のLink
ヘッダーコンテンツと同等のコンテンツも生成するレスポンスが生成される。
Linkヘッダーフィールド内で使用される場合、
属性tokenは、
anchor属性で与えられる完全なプロファイルURIの代替として
クライアントが使用MAY できる
トークン を指定するために用いられる。
プロファイルURIの代替としてトークンを使用することは、
既定では現在のリソース
(すなわち現在のリクエストURIによって識別されるリソース)に限定されることに注意すべきである。
サーバーはこれについてより広いスコープを使用MAY であるが、
サーバー文書が他の何らかの手段で明示的に別の指示を与えない限り、
クライアントはそれに依存すべきではない。
profile属性の値のABNFはtoken / quoted-stringであり、
ここで「token」および「quoted-string」は
[RFC9110 第5.6節
で定義されるとおりである。[RFC8288 第3節 で定義される
link-param値の規則が適用される。
例 21 : Link属性「token」を使用してプロファイルURIをトークンに結び付ける
# "anchor"要素内のプロファイルURIは、トークン"igsn-r1"に結び付けられる
# さらに、関係"type"は、anchorリソースが"dcterms:Standard"型であることを
# 通知するために使用される
Link: <http://www.w3.org/ns/dx/prof/Profile>;
rel="type";
token="igsn-r1";
anchor=<http://schema.igsn.org/description/1.0>
この仕様における機能プロファイルへの適合性の実証のために満たす必要がある要件を、
機能プロファイルごとに以下に示す。
この仕様への適合性をテストまたは実証するシステムは、ここで与えられる
要件IDを参照して行うべきである。たとえば、QSA 機能
プロファイルR.2.1.a と、その要件本文
リソース表現が準拠するプロファイルは、リソースのURIに
クエリ文字列引数として追加MUST であるトークンによって示される。
を満たさなければならず、その要件に対するサーバーの実装は実証可能でなければならない。
R.2.1.a
8.3.1.1 QSA URIの説明MUST であるトークンによって示される。
R.2.1.b
8.3.2.3 リソース
URLQSA ベースのプロファイルネゴシエーションが行われるリソースURLは、
どのQSA ベースのシステムにおいても、
他のリソースURIのQSA 値そのものになるべきではない
SHOULD NOT 。
R.2.1.c
8.3.1.1 QSA URIの説明MUST である。
R.2.1.d
8.3.1.1 QSA URIの説明QSA またはその他の手法(たとえばHTTPヘッダー)の使用により、
コンテンツネゴシエーションの追加の側面をそのようなURIに含めMAY であるが、
含める場合、それらはプロファイルによるコンテンツネゴシエーションのためのリクエストの動作を
変更してMUST NOT である。
R.2.2.a
8.3.1.2 キー
命名QSA 機能プロファイル」に準拠するためには、
QSA キー_profileを、
プロファイルトークンを示すために使用MUST である。
R.2.2.b
8.3.1.2 キー
命名_mediatypeは、リソース表現のメディアタイプを示すために使用
SHOULD である。
R.2.2.c
8.3.2.2 トークン
対応付けIANAのメディアタイプ一覧 に登録されたトークンは、
メディアタイプ識別子のためのトークンとして使用SHOULD である。
R.2.3.a
8.3.2 プロファイル
一覧QSA キー/値ペア_profile=altは、
クライアントがプロファイル一覧 リクエストを行えるように、
サーバーによりサポートされるSHOULD である。
R.2.3.b
8.3.2 プロファイル
一覧プロファイル一覧 リクエストに対するサーバーのレスポンスは、
そのリソースの表現についてサポートするすべてのプロファイルの一覧、
および任意でそれらの表現に対応するサポートされるメディアタイプを提示することである
SHOULD 。
R.2.3.c
8.3.2 プロファイル
一覧SHOULD である。
R.2.3.d
8.3.2 プロファイル
一覧MAY である。
R.2.3.e
8.3.2 プロファイル
一覧プロファイルによるリソース取得 関数で使用されるものと同じ
メディアタイプネゴシエーション方法を使用して、
クライアントがレスポンスの特定のメディアタイプについてネゴシエートすることを許可
MAY である。
R.2.4.a
8.3.2.1 QSA 代替表現データモデル
実装QSA 機能プロファイルに従うこの仕様の実装は、
代替表現データモデルに従ってその代替表現情報を伝達
MUST である。
R.2.4.b
8.3.2.1 QSA 代替表現データモデル
実装MAY よく、また他のアプローチを使用しても
MAY よい。
R.2.4.c
8.3.2.1 QSA 代替表現データモデル
実装
R.3.1.a
8.3.1.1 QSA URIの説明MUST である[1つの]トークンによって示される。
R.3.1.b
8.3.2.3 リソース
URLQSA ベースのプロファイルネゴシエーションが行われるリソースURLは、
どのQSA ベースのシステムにおいても、
他のリソースURIのQSA 値そのものになるべきではない
SHOULD NOT 。
R.3.1.c
8.3.1.1 QSA URIの説明MUST である。
R.3.1.d
8.3.1.1 QSA URIの説明QSA またはその他の手法(たとえばHTTPヘッダー)の使用により、
コンテンツネゴシエーションの追加の側面をそのようなURIに含めMAY であるが、
含める場合、それらはプロファイルによるコンテンツネゴシエーションのためのリクエストの動作を
変更してMUST NOT である。
R.3.2.a
8.3.1.2 キー
命名QSA キーを使用
MUST である。
R.3.2.b
8.3.4 QSA キー発見QSA 機能プロファイル」の_profileの代わりに使用される
QSA キーをクライアントが発見できるようにする方法を実装
MUST である。
R.3.2.c
8.3.1.2 キー
命名QSA キーを使用
SHOULD である。
R.3.2.d
8.3.4 QSA キー発見QSA キーが実装される場合、
サーバーは、「QSA 機能プロファイル」の
_mediatypeの代わりに使用されるQSA キーを
クライアントが発見できるようにする方法を実装MUST である。
R.3.2.e
8.3.2.2 トークン
対応付けIANAのメディアタイプ一覧 に登録されたトークンは、
メディアタイプ識別子のためのトークンとして使用SHOULD である。
R.3.3.a
8.3.2 プロファイル
一覧xがサーバーにとっての_profile相当、yが
サーバーにとってのalt相当であるQSA
キー/値ペアx=yは、クライアントがプロファイル一覧 リクエストを行えるように、
サーバーによりサポートされるSHOULD である。
R.3.2.b
8.3.4 QSA キー発見QSA 機能プロファイル」の_profile=altの代わりに使用される
QSA キー/値ペアをクライアントが発見できるようにする方法を実装
MUST である。
R.3.3.c
8.3.2 プロファイル
一覧プロファイル一覧 リクエストに対するサーバーのレスポンスは、
そのリソースの表現についてサポートするすべてのプロファイルの一覧、
および任意でそれらの表現に対応するサポートされるメディアタイプを提示することである
SHOULD 。
R.3.3.d
8.3.2 プロファイル
一覧SHOULD である。
R.3.3.e
8.3.2 プロファイル
一覧MAY である。
R.3.3.f
8.3.2 プロファイル
一覧プロファイルによるリソース取得 関数で使用されるものと同じ
メディアタイプネゴシエーション方法を使用して、
クライアントがレスポンスの特定のメディアタイプについてネゴシエートすることを許可
MAY である。
R.3.4.a
8.3.2.1 QSA 代替表現データモデル
実装QSA 機能プロファイルに従うこの仕様の実装は、
代替表現データモデルに従ってその代替表現情報を伝達
MUST である。
R.3.4.b
8.3.2.1 QSA 代替表現データモデル
実装MAY よく、また他のアプローチを使用しても
MAY よい。
R.3.4.c
8.3.2.1 QSA 代替表現データモデル
実装
この仕様には、8.1 この仕様の機能
プロファイル機能プロファイル が含まれる。
この付録は、Profiles Vocabulary [DX-PROF
コードリスト1 のRDF(turtle構文)コードは、
Content
Negotiation
by
Profile をdcterms:Standard DX-PROF 仕様 の定義と一致する。この
文書は振る舞いを記述しているため、この仕様は機能
仕様 であることに注意。したがって、その4つのプロファイルは、
通常のPROFモデリングに従い
prof:Profiles QSA
機能プロファイル図
4 でも図示される。
コードリスト1 に提示されるコードは、RDFファイル
profiles.ttl としても利用可能である。
QSA 機能プロファイルQSA 代替キーワード
機能プロファイルQSA
機能プロファイルQSA 代替キーワード機能プロファイルContent Negotiation by Profile の、より制約された「より狭い」
仕様であり、QSA 機能
プロファイルQSA 代替キーワード機能プロファイルDX-PROF
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX prof: <http://www.w3.org/ns/dx/prof/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX cnpr: <http://www.w3.org/ns/dx/connegp/profile/>
<https://www.w3.org/TR/dx-connegp/> a dcterms:Standard ;
rdfs:label "Content Negotiation by Profile" ;
rdfs:comment "Content Negotiation by Profileのための
W3C 勧告(標準)"@ja .
cnpr:http a prof:Profile ;
prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ;
rdfs:label "HTTPヘッダー機能プロファイル" ;
rdfs:comment "§ 7.2 Hypertext Transfer Protocol Headersで提示されるContent Negotiation by
Profileの機能プロファイルへの適合のため。"@ja ;
skos:scopeNote "リソースがHTTPヘッダー機能プロファイルに準拠する場合に使用する"@ja .
cnpr:qsa a prof:Profile ;
prof:isProfileOf cnpr:qsa-alt ;
rdfs:label "
QSA 機能プロファイル"@ja ;
rdfs:comment "§ 7.3 URL Query String Argumentsで提示されるContent Negotiation by
Profileの機能プロファイルへの適合のため。"@ja ;
skos:scopeNote "§ 7.3 URL Query String Argumentsの推奨に従い、
Query String Arguments _profileおよび_mediatypeを使用する
QSA
機能プロファイルにリソースが準拠する場合に使用する。"@ja .
cnpr:qsa-alt a prof:Profile ;
prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ;
rdfs:label "
QSA 代替キーワード機能プロファイル" ;
rdfs:comment "§ 7.3 URL Query String Argumentsで提示されるContent Negotiation by
Profileの機能プロファイルへの適合のため。"@ja ;
skos:scopeNote "リソースが
QSA 機能プロファイルに準拠するが、
§ 7.3 URL Query String Argumentsの推奨によって許可されるように、
Query String Arguments _profileおよび_mediatypeに代替キーワードを使用する場合に使用する。"@ja .
cnpr:rrd a prof:Profile ;
prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ;
rdfs:label "リソース表現記述プロファイル"@ja ;
rdfs:comment "Content Negotiation by Profile § 6.3.2 get
resource by profileへの適合のため。"@ja ;
skos:scopeNote "リソース表現が、適切な機能プロファイル内で、
§ 6.3.2 get resource by profileの抽象仕様に従い、
どのプロファイルに準拠するかを示せる場合に使用する。"@ja .
図 4
[[PROF]プロファイル階層に示された、このContent Negotiation by Profile標準の仕様およびプロファイル。
7.4 代替表現データモデルOWL2-OVERVIEW
7.4
代替表現データモデルOWL2-OVERVIEW コードリスト3 に示す。
これはファイルaltr.ttl としても利用可能である。
コードリスト3 : OWLオントロジーとしての代替プロファイルデータモデル
PREFIX altr: <http://www.w3.org/ns/dx/connegp/altr#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX sdo: <https://schema.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
<http://www.w3.org/ns/dx/connegp/altr>
a owl:Ontology ;
rdfs:label "Alternative Profiles Ontology" ;
rdfs:comment """このオントロジーは、インターネットリソースの表現の記述を可能にする。
表現はprof:Profileインスタンスに準拠する場合があり、特定の
dcterms:MediaTypeの形式を持つ場合がある。"""@ja ;
dcterms:created "2019-08-07"^^xsd:date ;
dcterms:modified "2024-02-07"^^xsd:date ;
dcterms:creator [
a sdo:Person ;
sdo:affiliation <https://kurrawong.ai> ;
sdo:email <mailto:nick@kurrawong.ai> ;
sdo:identifier <http://orcid.org/0000-0002-8742-7730> ;
sdo:name "Nicholas J. Car" ;
] ;
.
<https://kurrawong.ai>
a sdo:Organization ;
sdo:name "KurrawongAI" ;
sdo:url "https://kurrawong.ai"^^xsd:anyURI ;
.
dcterms:conformsTo
a owl:ObjectProperty ;
rdfs:label "準拠先" ;
dcterms:source dcterms:conformsTo ;
skos:scopeNote "このプロパティを使用して、altr:Representationが準拠するdcterms:Standardを示す。" ;
.
altr:hasRepresentation
a owl:ObjectProperty ;
rdfs:label "表現を持つ" ;
skos:definition "ResourceのRepresentationを示す。"@ja ;
rdfs:domain rdfs:Resource ;
rdfs:range altr:Representation ;
skos:scopeNote "このプロパティを使用して、リソースのHTTP配信表現を示す。" ;
.
altr:hasDefaultRepresentation
a owl:ObjectProperty ;
rdfs:label "既定表現を持つ" ;
skos:definition "Resourceの既定Representationを示す。"@ja ;
rdfs:domain altr:Representation ;
rdfs:subPropertyOf altr:hasRepresentation ;
skos:scopeNote "このプロパティを使用して、リソースの識別(URI)以外に、サーバーにリソース表現の取得のための
追加指示が与えられないときに取得される、リソースの既定HTTP配信表現を示す。" ;
.
rdfs:Resource
a owl:Class ;
rdfs:label "Resource" ;
skos:definition "クラスresource、すべてのもの。"@ja ;
dcterms:source "http://www.w3.org/2000/01/rdf-schema#Resource" ;
skos:scopeNote "Alternative Profiles Ontologyの文脈では、rdfs:Resourceインスタンスは、
インターネットリソース、すなわちURIで識別される項目を識別するために使用される。" ;
.
altr:Representation
a owl:Class ;
rdfs:label "Representation" ;
skos:definition "HTTP通信における、あるものの現在または望ましい状態の抽象化。"@ja ;
dcterms:source <https://httpwg.org/specs/rfc7230.html> ;
rdfs:isDefinedBy <http://www.w3.org/ns/dx/connegp/altr> ;
skos:scopeNote "このクラスを使用して、リソースの表現のインスタンスを示す。" ;
.
dcterms:Standard
a owl:Class ;
rdfs:label "Standard" ;
skos:definition "比較のための基礎。他のものを評価できる基準点。"@ja ;
dcterms:source "http://purl.org/dc/terms/Standard" ;
skos:scopeNote "Alternative Profiles Ontologyの文脈では、このクラスを使用して、
リソースの表現が準拠できる情報モデルのインスタンスを示す。" ;
.
代替プロファイルデータモデル は、プロファイルによるコンテンツネゴシエーション状況で有用な
追加情報を含めるように拡張できる。
明らかに有用な拡張の1つは、コンテンツネゴシエーションの他の次元、特にメディアタイプに関する
情報を含めることである。コードリスト4 には、データモデルに追加できるメディアタイプ表示のための、
Dublin Core Termの[DCTERMS dcterms:formatプロパティおよび
dcterms:MediaTypeクラスのRDF定義が含まれる。
これはコードリスト4 でOWLとして表現される。
例 22 は、
例 23 の内容に続いて、
この拡張モデルの使用例を示す。
コードリスト4 : メディアタイプ表現に対応するための、
この仕様の代替プロファイルデータモデルに対するOWLでの推奨拡張
PREFIX ex: <http://example.org/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
dcterms:format
a owl:ObjectProperty ;
rdfs:label "format" ;
skos:definition "リソースのファイル形式、物理媒体、または寸法。"@ja ;
dcterms:source dcterms:format ;
rdfs:range dcterms:MediaType ;
skos:scopeNote "このプロパティを使用して、リソースの表現のIANAメディアタイプを示す。" .
ex:defaultFormat
a owl:DataTypeProperty ;
rdfs:label "default format" ;
skos:definition "指定されたStandardについて、Resourceの既定Representationを示す。"@ja ;
rdfs:domain
rdfs:range xsd:boolean ;
skos:scopeNote "このプロパティを使用して、プロファイルに準拠する複数のリソース表現のうち、
get resource by profileリクエストの既定であるものを示す。" .
dcterms:MediaType
a owl:Class ;
rdfs:label "Media Type" ;
skos:definition "ファイル形式または物理媒体。"@ja ;
dcterms:source "http://purl.org/dc/terms/MediaType" ;
skos:scopeNote "このモデルの文脈では、このクラスを使用して、
リソースの表現のIANAメディアタイプを示す。" .
例 22 :
メディアタイプ情報を示す、RDF(turtle)における代替プロファイルデータモデルの拡張実装
PREFIX altr: <http://www.w3.org/ns/dx/connegp/altr#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
# このResource Aには5つのRepresentationがあり、そのうち3番目が既定である。
# 一部のRepresentationは同じStandardに準拠するが、
# 異なるMedia Typeに従って形式化されている。一部のRepresentationには
# Media Type情報が含まれない。
<http://example.org/resource/a>
a rdfs:Resource ;
rdfs:label "Resources A" ;
altr:hasRepresentation :rep-1 , :rep-2 , :rep-3 , :rep-4 , :rep-5 ;
altr:hasDefaultRepresentation :rep-3 .
:rep-1
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/x> ;
dcterms:format "application/xml" .
:rep-2
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/y> .
# この表現は、<http://otherexample.org/profile/z>に準拠する
# 表現集合の既定である。
:rep-3
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/z> .
dcterms:format "text/html" ;
ex:isProfilesDefault "true" .
:rep-4
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/z> ;
dcterms:format "text/turtle" .
:rep-5
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/z> ;
dcterms:format "application/ld+json" .
代替プロファイルデータモデルのOWL実装に準拠して作成されたRDFデータのインスタンス例を
例 23 に示し、
続いて同じ内容を複数形式で示すものを
例 24 に示す。
例 23 :
RDF(turtle)における代替プロファイルデータモデルの実装
PREFIX altr: <http://www.w3.org/ns/dx/connegp/altr#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
# このResource Aには3つのRepresentationがあり、そのうち3番目が既定である
<http://example.org/resource/a>
a rdfs:Resource ;
rdfs:label "Resources A" ;
altr:hasRepresentation :rep-1 , :rep-2 , :rep-3 ;
altr:hasDefaultRepresentation :rep-3 .
# 各Representationと、それぞれが準拠するStandard、X、YおよびZ
:rep-1
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/x> .
:rep-2
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/y> .
:rep-3
a altr:Representation ;
dcterms:conformsTo <http://otherexample.org/profile/z> .
# 前の例の内容を、この仕様のHTTPアプリケーションプロファイルに従って
# HTTP Linkヘッダー内に表現したもの。
# 既定Representationはrel="canonical"の使用によって示される。
# Representationは、コンマ区切りのLink結果ごとに1つずつ見られ、
# Resource URI、それが準拠するStandardのURI、およびrel属性の組み合わせのみによって
# 識別されることに注意。個別の識別子は持たない。
Link:
<http://example.org/resource/a>;
rel="alternate";
formats="http://otherexample.org/profile/x",
<http://example.org/resource/a>;
rel="alternate";
formats="http://otherexample.org/profile/y",
<http://example.org/resource/a>;
rel="canonical";
formats="http://otherexample.org/profile/z"
---
# 前の例の内容を、HTTPレスポンスのHTML本文内で
# 表現される可能性があるような表形式で表現したもの。
# Resource URIにはQuery String Argumentsが含まれ、
# 指定された場合、下記のQSAアプリケーションプロファイルに従って
# 個々のRepresentationを返すことができる。
---------------------------------------------------------------------------------------
| 短縮されたResource URI | 準拠するprofileのURI | 既定 |
---------------------------------------------------------------------------------------
| http://.../resource/a?_profile=prof-x | http://otherexample.org/profile/x | |
| http://.../resource/a?_profile=prof-y | http://otherexample.org/profile/y | |
| http://.../resource/a?_profile=prof-z | http://otherexample.org/profile/z | はい |
---------------------------------------------------------------------------------------
DCAT [VOCAB-DCAT-2 dcat:Datasetはdcat:DataServiceを介してアクセス可能な場合があり、
そのサービスはこの仕様の1つ以上の機能プロファイルをサポートする場合がある。この場合、サポートは、
コードリスト5 に示すように、
述語dcterms:conformsToを使用して、サービスが関連する機能プロファイルを参照することにより
宣言されるべきである。
DCAT 2は、データサービスがアクセスを提供するデータセット内の個々のデータ項目を、
識別子によってアクセスできるようにするかどうかを指定する標準的手段を提供しないため、
この例は全体として配布されるデータセットに関するものであることに注意。
それでもなお、dcterms:conformsToの使用は、
個々の項目にアクセスする仕組みを宣言するデータサービスにも適用される。
この仕組みはdcat:endpointDescriptionを介して識別される場合がある。
コードリスト5 : プロファイルによるコンテンツネゴシエーションをサポートするDCAT
Data
Serviceの記述
PREFIX ex: <http://example.org#>
PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX prof: <http://www.w3.org/ns/dx/prof/>
# DatasetはDistributionを持つ
:aDataset dcat:distribution :aDatasetDistribution .
# Distributionが準拠するデータプロファイル
ex:someDataProfile
a prof:Profile ;
# profile詳細
.
# Content Negotiation by ProfileをサポートするDataServiceによってアクセスできるDistribution。
# Distributionのコンテンツは上記のProfileに準拠する
:aDatasetDistribution
a dcat:Distribution ;
dcterms:conformsTo ex:someDataProfile ;
dcat:accessService ex:connegDataAccessService .
# DatasetのDistributionにアクセスするために使用されるService。
# Service自体はContent Negotiation by Profileの2つの機能プロファイルに準拠する
ex:connegDataAccessService
a dcat:DataService ;
dcterms:conformsTo
<http://www.w3.org/ns/dx/connegp/profile/http> ,
<http://www.w3.org/ns/dx/connegp/profile/qsa> ;
# Datasetが、Content Negotiation by Profileを使用して、そのidであるURIによって
# 呼び出され得ることを宣言する
dcat:endPointURL :aDataset .
↑
