基于配置文件的内容协商

초록

이 문서는 인터넷 클라이언트가 서버에서 제공하는 콘텐츠에 대해, 해당 콘텐츠가 준수하는 데이터 프로파일을 기반으로 어떻게 협상할 수 있는지 설명한다. 이는 미디어 유형이나 언어에 의한 협상과는 다르다. 프로파일은 반환되는 정보의 내용을 지정할 수 있으며, 이는 응답 서버가 요청된 리소스에 대해 보유한 정보의 하위 집합일 수 있고, 실무 공동체의 상호운용성 요구사항을 충족하기 위해 특정한 방식으로 구조화될 수 있다.

접두사	네임스페이스
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#

이 섹션은 비규범적이다.

참고

콘텐츠 협상 HTTP 헤더의 표준화는 IETF의 관할 사항이다. HTTP에서 프로파일을 표시하고 협상하기 위한 Internet Draft [PROF-IETF]의 첫 번째 제안이 제공되어 있지만 아직 IETF에 제출되지는 않았다. IETF 초안의 현재 버전(-00)은 이 문서와 병행되는 작업에서 완전히 다시 작성될 것으로 예상되며, 이 문단이 이 문서에서 제거될 때까지는 진행 중인 작업으로 보아야 한다.

HTTP Accept 및 Content-Type 헤더 필드 [RFC9110]는 클라이언트가 허용 가능한 미디어 유형(Accept)을 지정하고, 서버가 응답 본문의 미디어 유형(Content-Type)을 나타낼 수 있게 한다. 미디어 유형 등록은 선택적인 미디어 유형 매개변수 목록도 지정할 수 있다. 일부 미디어 유형 등록(예: application/ld+json)은 응답 본문이 준수하는 프로파일을 알리는 데 사용할 수 있는 "profile"이라는 미디어 유형 매개변수의 사용을 지정한 바 있다.

예제 1: HTTP Accept 헤더를 'profile' 매개변수와 함께 사용하기

GET /resource/a HTTP/1.1
Accept: application/ld+json;q=0.9;profile="urn:example:profile-1", \
        application/ld+json;q=0.7;profile="urn:example:profile-2"

--

HTTP/1.1 200 OK
Content-Type: application/ld+json;profile="urn:example:profile-2"

2018년에 DXWG 구성원들은 프랑스 리옹에서 열린 연례 포럼 TPAC에서 JSON-LD WG와 더 긴 논의를 진행했으며, Accept 및 Content-Type 헤더의 "profile” 매개변수는 JSON-LD의 "expanded"(http://www.w3.org/ns/json-ld#expanded) 또는 "flattened"(http://www.w3.org/ns/json-ld#flattened)와 같이 미디어 유형에 특화된 프로파일을 전달하는 것으로 보아야 한다는 결론을 내렸다. 미디어 유형과 독립적인 프로파일의 사용을 알리기 위해서는 HTTP 헤더 필드 Accept-Profile 및 Link: <...>; rel="profile"을 사용해야 한다.

HTTP Link 헤더 필드 [RFC8288]는 두 리소스 간의 관계를 지정함으로써 웹 리소스(Link Context)를 대상 리소스(Link Target)와 연결한다. 관계 유형 중 하나는 [RFC6906]에 정의된 "profile"이다. [RFC6906]은 프로파일을 정의하기를 "기본 미디어 유형 의미론을 변경하지 않으면서 리소스 표현을 처리하는 데 사용할 수 있는 추가 의미론 […]"이라고 하며, 구체적으로 "프로파일의 작성자와 사용자는 이를 미디어 유형 전반에서 사용할 수 있도록 하는 방식으로 정의하고 관리할 수 있다(MAY)"고 명시한다. 따라서 "profile" 관계는 허용 가능한 프로파일(요청) 및 콘텐츠(응답)에 관한 정보를 전달하는 적절한 방법처럼 보인다.

예제 2: profile 매개변수가 있는 Link 헤더 사용하기

HEAD /resource/a HTTP/1.1
Accept: text/turtle;q=0.9,application/rdf+xml;q=0.5
Link: <http://example.com/profile/x>; rel="profile"

--

HTTP/1.1 200 OK
Content-Type: text/turtle
Link: <http://example.com/profile/x>; rel="profile"

"profile" 관계는 서버가 응답 본문의 프로파일을 나타내는 데 사용할 수 있다. 그러나 요청에서 "profile" 관계를 사용해 품질 정보(q-value)를 전달할 가능성은 없다.

HTTP Prefer 및 Preference-Applied 헤더 필드 [RFC7240]는 프로파일 선호도에 관한 정보를 전달하는 데 사용할 수 있다. 클라이언트는 Prefer 헤더를 사용하여 특정 프로파일을 준수하는 리소스 표현에 대한 선호를 서버에 알릴 수 있다. 서버가 응답에서 Preference-Applied 헤더 필드를 보내면, 클라이언트는 그 선호가 존중되었음을 알 수 있다.

예제 3: profile 매개변수가 있는 Prefer 헤더 사용하기

GET /resource/a HTTP/1.1
Accept: text/turtle
Prefer: profile="urn:example:schema"

--

HTTP/1.1 200 OK
Content-Type: text/turtle
Preference-Applied: profile="urn:example:schema"

이 접근 방식에는 두 가지 단점이 있다. 첫째, Link 헤더의 경우와 마찬가지로 요청 헤더에서 q-value를 사용할 가능성이 없다. 둘째, 클라이언트가 표시한 선호를 서버가 무시했다는 것을 서버가 나타낼 수 있는 유일한 방법은 Preference-Applied 헤더 필드를 보내지 않는 것이다. 그러나 클라이언트 입장에서는 Preference-Applied 헤더가 없을 때, 서버가 그 선호를 존중하지 않았기 때문인지, 아니면 서버가 Prefer 헤더를 이해하지 못했기 때문인지 명확하지 않다. 이는 Prefer: profile="" 헤더가 포함된 요청에 응답할 때 Link: rel=profile 헤더를 반드시 보내도록 함으로써 해결할 수 있다. 그러나 이 해결책은 클라이언트가 특정 프로파일 요청에 대한 응답을 찾기 위해 두 개의 서로 다른 헤더를 평가해야 하므로, 클라이언트 구현을 더 복잡하게 만들 것이다. 더 나아가 [RFC7240]은 구현자가 콘텐츠 협상을 위해 Prefer 헤더 메커니즘을 사용하지 말 것("SHOULD NOT")을 명시적으로 권고한다.

이 섹션은 특정 환경에서의 어떤 구현과도 독립적인, 프로파일 기반 콘텐츠 협상을 위한 개념적, 즉 추상적인 모델을 설명한다.

서로 다른 환경을 위한 이 추상 모델의 구현을 기능 프로파일이라고 한다. 유효한 기능 프로파일이 되려면 이들은 이러한 추상 모델 기능을 구현해야 한다(MUST). 이를 어떻게 수행하는지는 환경별로 달라진다.

기능 프로파일은 자신만의 추가 기능으로 이 추상 모델을 확장할 수 있다(MAY). 다만 이러한 추가 사항은 여기서 정의된 기능을 무효화해서는 안 된다(MUST NOT).

서로 다른 데이터 프로파일을 준수하는 리소스의 표현을 설명하기 위한 데이터 모델이 여기에 제시되어 있으며, 이 모델은 모든 기능 프로파일에서 사용되어야 한다(MUST). 데이터 모델이 어떻게 실현되는지는 구현자가 결정하도록 남겨 둔다. 구현된 데이터 모델의 적합성을 어떻게 입증하는지는 여기서 자세히 다루지 않으며, 다음 지침만 제공한다. 구현자는 자신의 대체 표현 데이터 모델 구현의 적합성을, 해당 모델의 환경별 실현과 이 명세에서 제공하는 모델의 구체적 실현, 예를 들어 OWL 온톨로지 표현 사이의 공개된 매핑을 제공함으로써 입증하는 것이 좋다(SHOULD).

인터넷을 통한 모든 콘텐츠 협상은 클라이언트와 서버 사이에서 이루어진다. 전자는 요청을 통해 리소스 또는 리소스의 메타데이터 표현을 요청하고, 응답을 통해 요청한 표현을 받는다. 통신하는 특정 기계 쌍의 경우, 정보가 오가며 요청되는 과정에서 클라이언트와 서버의 역할이 서로 바뀔 수 있다.

인터넷 리소스에는 클라이언트/서버 에이전트 쌍이 콘텐츠에 대해 협상할 수 있는 여러 측면이 있을 수 있다. 이러한 측면은 독립적으로 취급되어야 하므로, 프로파일에 의한 협상과 그 밖의 어떤 측면에 의한 협상을 포함하는 리소스의 콘텐츠 협상은 서로 영향을 주지 않는다.

이 추상 모델에서는 클라이언트, 서버, 리소스, 메타데이터, 요청 또는 응답에 대해, 정의 섹션3. 정의에서 이미 제공된 세부 사항 외에는 어떤 구체적인 세부 사항도 가정하지 않는다.

데이터 프로파일을 준수하는 리소스의 표현을 요청하는 클라이언트는 리소스를 Uniform Resource Identifier(URI) [RFC3986]로 식별해야 하며(MUST), 프로파일은 URI 또는 토큰으로 식별해야 한다(MUST).

프로파일 식별에 URI가 사용되는 경우, 이는 프로파일 설명으로 역참조되는 HTTP URI인 것이 좋다(SHOULD). 다른 종류의 URI, 예를 들어 URN도 사용할 수 있으며(MAY), 이들은 역참조 가능하지 않을 수 있다. 토큰이 사용되는 경우, 이는 요청/응답 메시지 쌍 안에서 데이터 프로파일을 명확하게 식별해야 한다(MUST). 서버는 토큰이 URI에 매핑될 수 있는 맥락을 선언해야 한다(MUST).

프로파일 기반 콘텐츠 협상과 관련하여 클라이언트가 서버에 할 수 있는 요청에는 두 가지 주요 유형이 있다. 이 명세를 따르는 프로파일을 통해 콘텐츠를 협상하려는 클라이언트는 이 두 요청 유형을 구현할 수 있어야 한다(MUST).

프로파일 목록
클라이언트는 서버가 적합한 리소스 표현을 전달할 수 있는 데이터 프로파일들의 URI 목록을 요청한다.
프로파일별 리소스 가져오기
클라이언트는 특정 프로파일을 준수하는, 요청된 리소스의 표현을 요청한다.

이 명세를 따르는 서버는 각 요청에 대해 다음과 같은 각각의 응답으로 응답해야 한다(MUST).

프로파일 목록
서버는 클라이언트에게, 자신이 적합한 리소스 표현을 전달할 수 있는 데이터 프로파일들의 URI 목록으로 응답한다.
프로파일별 리소스 가져오기
서버는 클라이언트가 식별한 요청된 프로파일을 준수하는 리소스의 특정 데이터 프로파일로 응답하거나, 기본 데이터 프로파일로 응답한다.

이러한 요청과 그 응답에 대한 더 자세한 설명은 다음에 제시된다.

클라이언트는 서버가 어떤 데이터 프로파일에 대해 리소스의 적합한 표현을 전달할 수 있는지 알고자 한다. 프로파일 목록은 특정 리소스 표현에 대한 요청이 이루어지기 전에 알려져 있을 수도 있고, 최초 요청이 이루어진 뒤에야 알려질 수도 있다.

프로파일 목록 요청은 독립적인 요청이거나 다른 기능 프로파일 요청의 일부여야 한다(MUST).

프로파일 목록 요청은 여러 형식 중 하나의 응답으로 이어질 수 있다(MAY). 다만 리소스의 표현이 준수하는 데이터 프로파일들은 URI 또는 토큰 중 하나로 명확하게 식별되어야 한다. 후자의 경우, 하나의 특정 클라이언트/서버 메시지 쌍 안에서 URI에 매핑 가능해야 한다(MUST).

서버는 특정 데이터 프로파일을 지정하는 프로파일별 리소스 가져오기 요청이 제시되었을 때 전달할 수 없는 데이터 프로파일을 목록에 포함해서는 안 된다(MUST NOT).

예제 4는 QSA 기능 프로파일을 준수하는 요청/응답 메시지 쌍을 보여주며, 여기서 요청은 특정 리소스에 대한 프로파일 목록 요청이다.

예제 4: 단순 프로파일 목록 요청 및 응답 메시지(QSA 기능 프로파일)

# A request for all the profiles to which representations of resource a conform
GET /resource/a?_profile=alt HTTP/1.1

---

# The server returns a list of profiles both in its HTTP response header and also
# in the response body (HTML). Note that the action of returning the response message
# conforms to the QSA Functional Profile and this is indicated with the Link header
# combined with the "profile" relation
HTTP/1.1 200 OK
Content-Type: text/html
Link: <http://www.w3.org/ns/dx/connegp/profile/qsa>; rel="profile"
# This Link header indicates representations are available that conform to Profile X
# & Y and that the Profile X-conformant representations are available in HTML
# & XML Media Types.
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>Profiles for Resource A</title>
  </head>
  <body>
    <h1>Profiles available for Resource X</h1>
    <ul>
      <li><a href="?_profile=profile-x&_mediatype=text/html">X, in HTML</a></li>
      <li><a href="?_profile=profile-x&_mediatype=application/xml">X, in XML</a></li>
      <li><a href="?_profile=profile-y&_mediatype=application/xml">Y, in XML</a></li>
    </ul>
  </body>
</html>

프로파일 기반 콘텐츠 협상의 가장 기본적인 요청은 클라이언트가 데이터 프로파일을 준수한다고 주장되는 리소스의 표현을 요청하는 것이다.

프로파일별 리소스 가져오기 요청을 실행하는 클라이언트는 데이터 프로파일을 URI 또는 세션 내에서 URI에 명확하게 매핑되는 토큰으로 식별해야 한다(MUST).

프로파일별 리소스 가져오기를 실행하는 클라이언트는 기능 프로파일별 순서 지정으로 선호도를 표현하여, 여러 데이터 프로파일 중 하나를 준수하는 리소스 표현을 요청할 수 있다(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 헤더 기능 프로파일)

# A request for resource a according to Profile x is made
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

---

# The server returns a representation of Resource a conforming with Profile x
HTTP/1.1 200 OK
Link: <http://example.org/profile/x>; rel="profile"

[response body]

예제 6: 303 리디렉션이 있는 프로파일별 리소스 가져오기 요청 및 응답(HTTP 헤더 기능 프로파일)

# A request for a non-information resource a according to Profile x is made
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

---

# The server returns a 303 Redirect to another URI identifying an information
# resource that then returns the requested resource representation. The redirecting
# server indicates the profile to which the redirected to resource representation
# conforms
HTTP/1.1 303 See Other
Location: http://example.org/info-resource/b
Link: <http://example.org/profile/x>; rel="profile"

---

# The client now requests the indicated information resource. Note that the
# Accept-Profile header is no longer needed since the original response has
# catered for that in the redirect response
GET /info-resource/b HTTP/1.1

---

# The final server response with the information resource. Note that this
# response does not include the profile-indicating Link rel="profile" header
HTTP/1.1 200 OK

[response body]

예제 7: 더 좁은 적합 프로파일로 응답하는 프로파일별 리소스 가져오기(HTTP 헤더 기능 프로파일)

# A request for Resource A whose representation conforms
# to Profile X is made

GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>
[more request headers]

---

# The server is able to respond with a representation of
# Resource a according to Profile Y which it knows is a
# profile of Profile X

# The server responds with the list of profiles that it knows
# the resource representations conforms to ensuring that the
# requested profile, Profile X, is listed. Here Profile Y and
# a further profile irrelevant for the client, Profile Z, are
# indicated.

HTTP/1.1 200 OK
[other response headers]
Link: <http://example.org/profile/x>; rel="profile", \
      <http://example.org/profile/y>; rel="profile", \
      <http://example.org/profile/z>; rel="profile"
[more response headers]

[content conforming to to Profile X, Y & Z]

동일한 프로파일 계층 안에 있지 않은 둘 이상의 프로파일을 준수하는 리소스가 반환되는 경우 (즉, 리소스가 일련의 프로파일을 준수하지만 그중 일부는 독립적이며, 해당 집합의 다른 프로파일을 특수화한 프로파일이 아닌 경우), 서버는 각 독립 프로파일에 대한 적합성을 표시하는 것이 좋다(SHOULD).

예를 들어 HTTP 헤더 기능 프로파일을 사용할 때, [GeoDCAT-AP]와 [STATDCAT-AP]를 모두 준수하는 서버의 응답에서, 어느 프로파일도 다른 프로파일을 프로파일링하지 않으므로 둘 모두에 충분한 단일 적합성 표시가 없다고 할 때 (둘 모두 [DCAT-AP]를 프로파일링한다는 점에 유의한다. [DX-PROF]의 DCAT-AP 계층 예제 참조), [GeoDCAT-AP]와 [STATDCAT-AP]에 대한 프로파일 URI를 사용하는 응답은 다음과 같을 수 있다.

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]로 구현된 Alternate Profiles 데이터 모델의 다이어그램.

서로 다른 프로파일을 준수하는 리소스의 대체 표현에 대한 설명은, 이 명세가 만들어진 애플리케이션 프로파일에 관련성이 있다고 판단되는 것에 따라, 이 모델을 구현하는 모델링 시스템에 따라 제시될 수 있다(MAY). 예를 들어 HTTP 애플리케이션 프로파일(8.2 Hypertext Transfer Protocol 헤더)은 [RFC9110]의 HTTP 명세 헤더 구조 제약 안의 텍스트로 제한되므로, 해당 환경에서 이 데이터 모델의 구문적 전달은 그 제약에 따라 구현되어야 한다.

이 데이터 모델의 일부 구현에 대한 데이터 인스턴스의 적합성을 테스트하기 위한 도구는 10. 테스트 모음에 제시되어 있다. 예상되는 상황에서 사용하기 위한 이 데이터 모델의 구체적 구현 및 확장에 대한 제안은 A.4 대체 표현 데이터 모델 - 세부 사항에 제시되어 있다. 제안된 사용 예도 해당 부록에 제시되어 있다.

서비스는 HTTP, QSA 및 그 밖의 가능한 접근 방식을 포함하여 여러 기능 프로파일을 구현할 수 있다(MAY). 이러한 경우 클라이언트는 서로 다른 메커니즘을 통해 충돌하는 선택을 지정할 수 있다. 예를 들어 클라이언트가 기본 헤더를 보내면서도 특정 표현을 요청하는 일반적인 경우가 그렇다. 여기서 정의하는 우선순위는 어떤 메커니즘을 사용해야 하는지 결정한다(MUST).

우선순위는 QSA가 HTTP보다 앞선다. 이는 URI가 리소스를 더 정확하게 가리킬수록, 그 요청과 함께 어떤 HTTP 헤더가 전송되었는지와 관계없이 에이전트가 바로 그 정확한 리소스를 요청하려는 의도를 가질 가능성이 더 높다는 근거에 따른 것이다.

추상 모델의 다른 잠재적으로 충돌하는 기능 프로파일이 정의된다면, 우선순위를 설정해야 할 것이다. 이를 선언하는 방법에 대해서는 구체적인 메커니즘을 제안하지 않는다.

Issue 505

이 섹션은 서로 다른 시스템 환경을 위한 이 명세의 추상 모델에 대한 기능 프로파일을 정의한다. 다른 프로파일도 정의될 수 있으며, 추상 모델을 준수하는 모든 프로파일에 대한 적합성은 이 명세에 대한 적합성을 충족한다.

이 명세는 두 환경, 즉 HTTP 헤더와 사람용 브라우저(URL 쿼리 문자열 인수)를 위한 추상 모델의 기능 프로파일을 제공한다.

또한 Resource Representation Description (cnpr:rrd) 프로파일은 서버가 GetResource 요청에 대한 서버 응답이 어떤 프로파일(들)을 준수하는지 나타낼 것임을 선언하는 데 사용될 수 있다.

사람용 브라우저 환경에 대해서는 서로 다른 사용 방식을 보여주기 위해 두 가지 기능 프로파일이 제시된다. 이 명세의 추가 기능 프로파일은 다른 환경을 위해서나, 이러한 환경 안의 제한된 시나리오를 위해서도 구현될 수 있으며(MAY), 구현자는 이 명세를 준수하는 추가 프로파일을 만들도록 권장된다.

여기서 미리 정의된 이 명세의 기능 프로파일은 그림 2에 나열되어 있다. 이들에 대한 네임스페이스 접두사는 다음과 같다.

cnpr → http://www.w3.org/ns/dx/connegp/profile/

URI	이름	설명	사용 참고
`cnpr:http`	HTTP 헤더 기능 프로파일	8.2 Hypertext Transfer Protocol 헤더에 제시된 기능 프로파일에 대한 적합성을 위한 것.	리소스가 HTTP 헤더 기능 프로파일을 준수하는 경우 사용
`cnpr:qsa`	QSA 기능 프로파일	8.3 URL 쿼리 문자열 인수에 제시된 기능 프로파일에 대한 적합성을 위한 것.	리소스가 8.3 URL 쿼리 문자열 인수의 권고에 따라 쿼리 문자열 인수 `_profile` 및 `_mediatype`을 사용하는 URL QSA 기능 프로파일을 준수하는 경우 사용.
`cnpr:qsa-alt`	QSA 대체 키워드 기능 프로파일	8.3 URL 쿼리 문자열 인수에 제시된 기능 프로파일에 대한 적합성을 위한 것.	리소스가 URL QSA 기능 프로파일을 준수하지만, 8.3 URL 쿼리 문자열 인수의 권고에서 허용한 대로 쿼리 문자열 인수 `_profile` 및 `_mediatype`에 대체 키워드를 사용하는 경우 사용.
`cnpr:rrd`	리소스 표현 설명	7.3.2 프로파일별 리소스 가져오기에 대한 적합성을 위한 것.	7.3.2 프로파일별 리소스 가져오기의 추상 명세에 따라, 리소스 표현이 자신이 준수하는 프로파일(들)을 나타낼 수 있는 경우 사용.

그림 2 리소스와 시스템이 Content Negotiation by Profile 명세의 하나 이상의 형식에 대한 적합성을 나타내기 위해 사용하는 프로파일.

위 기능 프로파일에 사용되는 네임스페이스 http://www.w3.org/ns/dx/connegp/profile/는 Dataset Exchange Working Group이 예약한 W3C 네임스페이스 http://www.w3.org/ns/dx/의 일부이며, 이 작업 그룹이 다루는 문제와 관련된 모든 네임스페이스 요구사항을 위해 마련된 것이다. /profile/ 경로 세그먼트는 현재 그림 2의 위 4개 인스턴스만 포함하는 프로파일 객체 등록부를 나타낸다.

Hypertext Transfer Protocol(HTTP) 헤더를 사용하는 추상 모델의 기능 프로파일을 여기서 제시한다. 이 구현은 HTTP 콘텐츠 협상을 기반으로 하며, 특정 방식으로 작성된 Link 헤더와 예정된 Internet-Draft [PROF-IETF]에서 정의될 새로운 HTTP 헤더 Accept-Profile을 사용한다.

참고: POST/PUT은 범위 밖

POST 및 PUT 메서드는 이 기능 프로파일의 범위 밖으로 간주된다. 이러한 HTTP 메서드가 제안된 추상 모델의 어떤 기능을 구현하게 될지는 명확하지 않다.

요청 메시지 콘텐츠의 적합성을 전달하기 위해 POST 및 PUT 요청에 rel="profile"이 있는 Link 헤더를 지정할 수 있다.

서버는 원하는 방식으로 자유롭게 협상을 구현할 수 있지만, User Agent가 Accept-Profile 헤더를 보내는 경우, 나열된 어떤 프로파일도 준수하지 않는 표현은 클라이언트가 해석할 수 없는 것으로 간주하는 것이 좋다(SHOULD). 이는 나열된 프로파일을 준수하지만 다른 차원에서 낮은 선호 점수를 가진 표현이, 다른 차원에서 더 높은 선호 점수를 가지지만 나열된 어떤 프로파일도 준수하지 않는 표현보다 더 선호되는 것으로 간주되는 것이 좋다는 뜻이다(SHOULD). Accept-Profile 헤더 선호가 주어지지 않은 경우, 프로파일 차원은 협상 목적상 무시되는 것이 좋다(SHOULD). 그럼에도 모든 경우에 서버의 응답은 자신이 그 표현이 준수한다고 알고 있는 모든 프로파일의 URI를 나열하는 rel="profile"이 있는 Link 헤더를 포함하는 것이 좋다(SHOULD).

서버가 특정 리소스에 대해 지원하는 프로파일 목록을 검색하는 선호 방식은 해당 리소스에 대해 GET 또는 HEAD 요청을 보내는 것이다. 어느 경우든, 프로파일 기반 콘텐츠 협상을 구현하는 서버는 그 리소스의 기본 표현과 모든 대체 표현에 관한 정보, 그리고 그 표현들이 준수하는 프로파일을 포함하는 HTTP Link 헤더를 반환하는 것이 좋다(SHOULD). 기본 표현, 즉 특정 표현이 요청되지 않았을 때 반환될 표현은 rel="canonical"로 식별하는 것이 좋고(SHOULD), 다른 표현은 rel="alternate"로 식별하는 것이 좋다.

예로, 미디어 유형 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: 서버가 사용 가능한 프로파일을 나타내기 위해 Link 헤더를 반환

HEAD /resource/a HTTP/1.1
Accept: text/turtle
[more request headers]

---

HTTP/1.1 200 OK
Content-Type: text/turtle
# This Link header indicates which profile this response conforms to
Link: <urn:example:profile:x>; rel="profile"
# This Link header lists all available profiles
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/a>;
          rel="alternate";
          type="application/xml";
          formats="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/html"
[more response headers]

예제 8에서 서로 다른 미디어 유형/프로파일 조합 각각에 대해 리소스의 URI는 변경되지 않으며, 반환되는 응답을 바꾸는 것은 각각 미디어 유형과 프로파일에 대한 Accept 및 Accept-Profile 헤더이다.

서버는 미디어 유형/프로파일 조합에 따른 리소스 표현으로의 직접 링크를 나타내기 위해 Content-Location HTTP 헤더를 사용할 수 있으며(MAY), 그렇게 하는 경우 예제 와 같이 Link 헤더의 변경되지 않은 URI를 이러한 직접 URI로 대체할 수 있다.

예제 9: 서버가 일부 프로파일 및 미디어 유형에 대해 Content-Location URI가 있는 Link 헤더를 반환

HEAD /resource/a HTTP/1.1
Accept: text/turtle
[more request headers]

---

HTTP/1.1 200 OK
Content-Type: text/turtle
Content-Location: http://example.org/resource/a.prof1.ttl
Link: <urn:example:profile:x>; rel="profile"
Link:
  <http://example.org/resource/a.prof1.ttl>;
          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.prof1.xml>;
          rel="alternate";
          type="application/xml";
          formats="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          formats="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/html"
[more response headers]

[In the Link header, Content-Location URIs are only used as context
URIs for resources conforming to profile urn:example:profile:x]

기능 프로파일 구현은 추상 모델의 기능을 구현하는 것에 더해, 대체 표현 데이터 모델에 따라 대체 표현 정보를 전달할 수 있도록 해야 한다. 이 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 헤더 기능 프로파일은 Alternate Profiles Data Model에 따라 리소스의 대체 데이터 프로파일을 전달할 수 있으며, 아래 그림 3은 헤더 구성요소를 데이터 모델의 OWL 온톨로지 표현에 매핑한다. 이 표현은 데이터 모델의 구체적이고 형식적인 실현이다. 이 매핑은 7. 추상 모델의 지시에 따라 제시된다. 그 지시는 "구현자는 자신의 대체 표현 데이터 모델 구현의 적합성을, 해당 모델의 환경별 실현과 이 명세에서 제공하는 모델의 구체적 실현, 예를 들어 OWL 온톨로지 표현 사이의 공개된 매핑을 제공함으로써 입증하는 것이 좋다(SHOULD)"는 것이다.

대체 표현 데이터 모델 요소	Link 헤더 요소
`rdfs:Resource`	링크 컨텍스트 URI가 rdfs:Resource의 인스턴스를 나타낸다
`altr:Representation`	링크 대상 URI가 altr:Representation 인스턴스를 나타낸다
`dcterms:Standard`	존재하는 경우, `profile`의 대상 속성이 dcterms:Standard 인스턴스의 URI를 나타낸다
`dcterms:conformsTo`	링크 대상 URI와 대상 속성 `profile` URI 사이의 암묵적 관계
`altr:hasRepresentation`	`alternate`의 관계 유형이 주어진 경우, 링크 컨텍스트 URI와 링크 대상 URI 사이의 암묵적 관계
`altr:hasDefaultRepresentation`	`canonical`의 관계 유형이 주어진 경우, 링크 컨텍스트 URI와 링크 대상 URI 사이의 암묵적 관계

그림 3 대체 표현 정보를 전달하는 HTTP Link 헤더 내부 요소를, Alternate Profiles Data Model의 OWL 온톨로지 표현에서 식별된 요소에 매핑한 것.

예제 10: HTTP Link 헤더를 Alternate Profiles Data Model에 매핑

# Link headers from previous example with one altered to show Blank Node v.
# absolute URIs for altr:Representation class instance
# (<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 headers above represented in Alternate Profiles Data Model
# as an OWL ontology
<http://example.org/resource/a>
    altr:hasDefaultRepresentation [
        dcterms:format "text/turtle" ;
        dcterms:conformsTo <urn:example:profile:x> ;
    ] ;
    altr:hasRepresentation [
        dcterms:format "text/turtle" ;
        dcterms:conformsTo <urn:example:profile:y> ;
    ] ,
    [
        dcterms:format "application/xml" ;
        dcterms:conformsTo <urn:example:profile:x> ;
    ] ,
    <http://example.org/resource/different> ,
    [
        dcterms:format "text/html" ;
    ] 
.

<http://example.org/resource/different>
    dcterms:format "application/xml" ;
    dcterms:conformsTo <urn:example:profile:y> .

HTTP 서버가 클라이언트가 토큰을 통해 프로파일을 식별할 수 있게 하려는 경우, URI를 통한 프로파일 식별의 필수 요구사항에 더해, 서버는 지원하는 각 토큰이 어떤 프로파일 URI에 해당하는지 나타내는 것이 좋다(SHOULD). 이 명세의 HTTP 헤더 기능 프로파일을 구현할 때, 서버는 응답 안의 각 profile URI/token 쌍에 대해 Link 헤더([RFC8288])를 포함해야 한다(MUST). 각 Link 헤더는 "http://www.w3.org/ns/dx/prof/Profile"을 Link Target으로 사용해야 하며(MUST), 다음 Target Attribute를 포함해야 한다(MUST).

대상 속성	대상 속성 값
`rel`	`"type"`
`token`	`anchor` 속성의 프로파일 URI에 매핑되는 토큰
`anchor`	`token` 속성의 토큰에 매핑되는 프로파일의 프로파일 URI

토큰/URI 매핑을 전달하는 데 사용되는 Link 헤더의 예는 예제 11에 제시되어 있다.

예제 11: 프로파일 URI를 토큰에 연결하기 위해 Link 속성 ''token'' 사용

# The profile URI in the "anchor" element is linked to the token "igsn-r1"

# Further, the relation "type" is used to inform
# that the anchor resource is of type "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 헤더

# The Profile with URI urn:example:profile:marc21-dnb is mapped to the token "dnb"
# and the Profile with URI http://example.org/profiles/marc21-loc is mapped to the token "loc"

HEAD /resource/a HTTP/1.1
Accept: text/turtle
[more request headers]

---

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"
[more response headers]

특정 프로파일을 준수하는 리소스 표현 가져오기는 해당 리소스에 대해 HTTP GET 요청을 보내고 원하는 프로파일 URI를 Accept-Profile 헤더에 지정하여 수행한다.

프로파일 기반 콘텐츠 협상을 구현하는 서버는 반환된 프로파일을 나타내는 rel="profile"이 있는 Link 헤더를 포함한 HTTP 응답 헤더로 응답해야 한다(MUST).

요청과 응답의 URI는 모두 꺾쇠괄호 '<' 및 '>'로 둘러싸야 한다(MUST).

허용 가능한 프로파일 URI의 범위를 제공할 수 있으며(MAY), 제공되는 경우 콤마로 구분하거나 별도의 Accept-Profile 헤더에 넣어야 한다(MUST).

선호도는 클라이언트가 URI와 세미콜론 ';'으로 구분된 품질 표시자(q-value)를 순서 지정 메커니즘으로 사용하여 나타낼 수 있다(MAY). q-value가 있는 URI(이 경우 URN)의 예는 <urn:example:profile:x>;q=1.0,이며, 여기서 URI는 <urn:example:profile:x>이고 q-value는 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
[more request headers]

---

HTTP/1.1 200 OK
Content-Type: text/turtle
Link: <urn:example:profile:x>; rel="profile"
[more response headers]

콘텐츠 협상을 수행하고 리소스 표현을 반환한 뒤에는, 서버가 8.2.1 프로파일 목록에 따라 다른 미디어 유형으로 인코딩되고 다른 프로파일을 준수하는 대체 리소스의 가용성을 나타내는 Link 헤더도 포함하는 것이 권장된다(RECOMMENDED).

HTTP 헤더 기능 프로파일의 프로파일 협상 방식은 완전 자동화된 프로파일 기반 콘텐츠 협상을 가능하게 하지만, 이 명세의 동기가 된 사용 사례에는 사람이 실행 가능한 협상도 포함되어 있었다. 또한 6. 관련 작업에서 설명한 것처럼, 이전 및 기존 시스템들은 이미 여러 수단을 통해 사람이 실행 가능한 프로파일 기반 콘텐츠 협상을 허용하고 있다.

사람이 실행 가능한 프로파일 기반 콘텐츠 협상을 허용하고, 기존 시스템과 유사한 메커니즘이 이 명세의 추상 모델의 모든 측면을 어떻게 충족할 수 있는지 보여주기 위해, 이 섹션은 추상 모델의 쿼리 문자열 인수(QSA) 기능 프로파일을 보여준다. 이 기능 프로파일은 추상 모델의 모든 필수 기능을 지원한다는 점에서 HTTP 헤더 기능 프로파일과 기능적으로 동등하지만, HTTP 또는 다른 어떤 기능 프로파일과도 상호 배타적이지 않다. 이 명세의 구현은 여러 환경에서 또는 같은 환경 안에서 다른 방식으로 프로파일 기반 콘텐츠 협상 기능을 구현하기 위해 이 명세의 여러 기능 프로파일에 적합할 수 있다.

독립적인 IETF 문서 [PROF-IETF]의 대상이기도 한 HTTP 헤더 기능 프로파일과 달리, QSA 기능 프로파일은 여기서 완전히 지정된다. 이 QSA 접근 방식의 두 형식이 제시된다. 첫 번째는 고정 키워드 "QSA Functional Profile"이고, 두 번째는 서버가 원하는 어떤 키워드든 구현할 수 있는 "QSA Alternate Keywords Functional Profile"이다. 이러한 다양한 기능 프로파일은 모두 8.1 이 명세의 기능 프로파일에서 식별된다.

참고

시스템이 이러한 기능 프로파일 중 하나 또는 여러 개에 적합함은 A.3 기능 프로파일에 대한 시스템 적합성 입증에 따라 입증될 수 있다. 이 명세에 설명된 기능 프로파일 중 하나 이상에 대한 적합성을 시스템, 예를 들어 서버가 반드시 나타내야 하는 것은 아니라는 점에 유의한다. 모든 시스템이 그렇게 하지는 않을 수 있기 때문이다. 시스템은 서비스 카탈로그의 주석 달린 항목과 같은 여러 방식으로 기능 프로파일에 대한 적합성을 보여줄 수도 있다.

쿼리 문자열은 지정된 매개변수에 값을 할당하는 URL의 일부이다. QSA는 사람이 웹 브라우저 안에서, 그리고 다른 클라이언트/서버 상황에서 서버에 추가 정보를 전달하기 위해 흔히 사용된다. 쿼리 문자열 키/값 쌍은 물음표 기호 ?로 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을 식별하기 위해 토큰이 사용되지만, 해당 토큰은 하나의 특정 클라이언트/서버 세션 안에서 URI에 매핑 가능해야 하며(MUST), 이를 위한 메커니즘은 아래에 설명되어 있다.

이러한 URI에는 추가 QSA를 사용하거나 다른 기법(예: HTTP 헤더)을 사용하여 콘텐츠 협상의 추가 측면을 포함할 수 있지만(MAY), 포함하는 경우에도 프로파일 기반 콘텐츠 협상 요청의 동작을 변경해서는 안 된다(MUST NOT). 허용 가능한 포함을 보여주기 위해, 예제 14의 URI를 사용하는 클라이언트가 요청 콘텐츠를 Turtle [TURTLE] 명세에 따라 RDF로 직렬화하도록 선호를 나타내고자 한다면, 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 키 명명 요구사항으로 구별되는 두 가지 서로 다른 기능 프로파일이 포함되어 있다. 두 프로파일은 "QSA Functional Profile"과 "QSA Alternate Keywords Functional Profile"이며, 전자는 후자의 프로파일이다. 이는 전자가 이 명세의 필수 기능을 달성하는 방법에 대해 더 엄격한 적합성 규칙("더 좁은" 규칙)을 포함하기 때문이다. 이러한 기능 프로파일은 8.1 이 명세의 기능 프로파일에서 식별되고 정의된다.

"QSA Functional Profile"을 준수하려면, 프로파일 토큰 또는 URI를 나타내기 위해 QSA 키 _profile을 사용해야 하며(MUST), 리소스 표현의 미디어 유형을 나타내기 위해 키 _mediatype을 사용하는 것이 좋다(SHOULD).

"QSA Alternate Keywords Functional Profile" 프로파일을 준수하는 경우, [RFC3986]의 명세 안에서 허용되는 어떤 키 값이든 원하는 프로파일을 나타내는 데 사용할 수 있다(MAY). 그러나 이 기능 프로파일을 준수하는 서버는 아래 8.3.4 QSA 키 탐색에서 자세히 설명한 것처럼, 사용되는 값을 클라이언트가 발견할 수 있게 하는 메커니즘도 제공해야 한다(MUST).

"QSA Functional Profile"에 대한 적합성을 위해, 클라이언트가 프로파일 목록 요청을 할 수 있도록 서버는 _profile QSA 키를 지원하는 것이 좋다(SHOULD). 이 요청에는 예약된 토큰 alt를 사용하는 것이 좋으며(SHOULD), 예를 들면 _profile=alt이다.

"QSA Alternate Keywords Functional Profile"에 대한 적합성을 위해서는 _view=alternates와 같은 다른 키/값 쌍을 사용할 수 있지만(MAY), 이 경우 구현하는 서버는 8.3.4 QSA 키 탐색에 따라 그 키를 발견할 수단을 제공해야 한다(MUST).

프로파일 목록 요청에 대한 서버의 응답은 해당 리소스의 표현을 지원하는 모든 프로파일 목록과, 선택적으로 그 표현에 대해 지원되는 미디어 유형도 제시하는 것이 좋다(SHOULD).

서버는 HTTP 헤더 기능 프로파일에 따라(Link 헤더 사용) 응답의 HTTP 헤더에 대체 프로파일 정보를 표현하는 것이 좋으며(SHOULD), 리소스의 기본 프로파일 표현 대신 응답 본문에 그 정보를 표현할 수도 있다(MAY). 이 본문 콘텐츠 허용은 사람이 더 낮은 수준의 HTTP 정보를 볼 필요 없이 웹 브라우저에서 리소스에 대한 대체 프로파일 적합 표현 선택지를 쉽게 읽을 수 있게 하기 위한 것이다.

서버가 HTTP 본문에 대체 프로파일 정보를 제공하는 경우, 서버는 아래 프로파일별 리소스 가져오기 기능에 사용되는 것과 동일한 미디어 유형 협상 방법을 사용하여 클라이언트가 응답의 특정 미디어 유형을 협상할 수 있도록 허용할 수 있다(MAY).

리소스의 대체 프로파일 표현을 HTTP 헤더 콘텐츠뿐 아니라 JSON 형식의 HTTP 본문 콘텐츠로도 전달하도록 하는 예제 요청은 예제 16과 같을 수 있다.

예제 16: HTTP 헤더와 본문 응답 모두를 사용하여 QSA로 '프로파일 목록' 요청

GET /resource/a?_profile=alt&_mediatype=application/json HTTP/1.1

---

# The response shows that representations of the resource can be delivered according
# to two profiles identified by the tokens profile-x & profile-y
# and that profile-x-conformant representations are available in XML & JSON
# where as profile-y-conformant representations are only available in XML

# The content in the JSON body of the response is equivalent to that of the Link header
# and can easily be mapped to the Alternate Representations Data Model, just as the Link
# information is in Figure 3.

# Both the Link header and the JSON body include profile URI/token mappings

HTTP/1.1 200 OK
Content-Type: application/json
Link: <http://www.w3.org/ns/dx/connegp/profile/qsa>; rel="profile",
      <http://example.org/resource/a?_profile=profile-x&_mediatype=application/json>;
          rel="canonical";
          type="application/json";
          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"

{
    "resource": "http://example.org/resource/a",
    "profiles": [
        {
            "token": "profile-x",
            "uri": "http://otherexample.org/profile/x",
            "media_types": ["application/json", "application/xml"]
        },
        {
            "token": "profile-y",
            "uri": "http://otherexample.org/profile/y",
            "media_types": ["application/xml"]
        }
    ]
}

QSA 기능 프로파일에 따라 이 명세를 구현하는 경우, 구현은 대체 표현 데이터 모델에 따라 대체 표현 정보를 전달해야 한다(MUST). HTTP 헤더 기능 프로파일에 따라 HTTP Link 헤더를 사용해 그렇게 할 수도 있고(MAY), 다른 접근 방식을 사용할 수도 있다(MAY).

[RFC8288] (Web Linking)의 서론에서 언급한 것처럼, HTML 및 일부 다른 데이터 모델은 "잘 정의된 링크 개념"을 가지고 있으므로, QSA 구현자는 HTTP 본문 콘텐츠를 통해, 아마도 HTML 또는 다른 데이터 모델/형식으로 대체 표현 데이터 모델 정보의 전달을 구현할 수 있다(MAY). 이는 QSA 구현을 사용하는 사람 클라이언트 사용자가 웹 브라우저나 다운로드 가능한 파일 안에서 이를 볼 수 있게 해 도움을 줄 수 있다.

예제 10의 Link 헤더 정보에 대한 가능한 HTML 표현은 아래 예제 17에 제시되어 있다. 위의 예제 16은 대체 표현 데이터 모델에 따른 Link 헤더 정보의 가능한 JSON 형식 표현을 제공한다는 점에 유의한다.

예제 17: 이전 예제의 Link 헤더 정보에 대한 HTML 표현

# Link headers from previous example with one altered to show Blank Node v.
# absolute URIs for altp:Representation class instance
# (<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 headers above represented HTML, assuming the Alternate Profile's rdfs:Resource
# is known from the request that generated this response and not given in the HTML
# content
<h3>Alternate Representations</h3>
<table>
  <thead>
    <tr>
      <th>Link to Representation</th>
      <th>Profile</th>
      <th>Media Type</th>
      <th>Is Default?</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>yes</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">No Profile, 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 프로파일 식별에 따라, 모든 프로파일은 URI로 식별되어야 한다(MUST). URI는 보편적으로 고유하므로 식별자 중복을 피하기 위한 등록이 필요하지 않기 때문이다. 그러나 이 명세의 두 QSA 기능 프로파일 중 하나를 준수하는 시스템은, 클라이언트/서버 상호작용 중 프로파일을 식별하기 위해 URI를 사용하는 대신, 등록되지 않았고 보편적으로 고유하지 않은 토큰을 사용하여 프로파일을 식별할 수 있다(MAY). 다만 그렇게 하는 경우, 클라이언트가 프로파일 토큰/URI 매핑을 발견할 수 있는 방법을 제공해야 한다(MUST).

프로파일 URI에 대한 토큰을 클라이언트가 사용할 수 있게 하려는 QSA 서버는 8.2.1.2 토큰 매핑의 HTTP 헤더 기능 프로파일에 제공된 지침을 따르는 것이 좋다(SHOULD).

QSA 기반 프로파일 협상이 이루어지는 리소스 URL은 어떤 QSA 기반 시스템에서도 다른 리소스 URI의 QSA 값 자체가 되지 않는 것이 좋다(SHOULD NOT). 이러한 메커니즘은 내부적으로 사용될 수 있고 레거시 시스템이 프로파일 협상에 사용하지만, 이러한 QSA 프로파일에 대한 적합성을 더 알아보기 쉽게 하기 위해 클라이언트에게는 숨기는 것이 가장 좋다. 예제 18은 이를 보여준다.

예제 18: 리소스 URL 자체는 다른 URL의 매개변수가 되지 않는 것이 좋음

For the representation of Resource X, according to Profile Y, in Media Type Z:

Rather than:
GET /single/endpoint \
            ?resource=http://example.org/resource/X \
            &_profile=Y \
            &_mediatype=Z HTTP/1.1

Use:
GET /resource/X?_profile=Y&_mediatype=Z HTTP/1.1

이 명세의 "QSA Functional Profile" 프로파일을 준수하려면, 서버는 클라이언트가 _profile 쿼리 문자열로 식별하는 프로파일에 따라 리소스를 요청할 수 있도록 허용해야 한다(MUST). 프로파일을 식별하는 데 토큰 또는 URI를 사용할 수 있으므로, 서버는 둘 중 하나를 수락해야 한다(MUST). 서버는 인코딩된 URI와 인코딩되지 않은 URI를 모두 수락할 수 있지만(MAY), 둘 중 하나만 수락할 수도 있다(MAY). URI는 꺾쇠괄호 '<' 및 '>'로 둘러싸야 한다(MUST).

이 명세의 "QSA Alternate Keywords Functional Profile" 프로파일을 준수하려면, 서버는 클라이언트가 서버 구현자가 선택한 키로 식별하는 프로파일에 따라 리소스를 요청할 수 있도록 허용해야 하지만(MUST), 서버는 8.3.4 QSA 키 탐색에 따라 그 키를 발견할 수단도 제공해야 한다(MUST).

프로파일별 리소스 가져오기를 구현하는 QSA 서버는 클라이언트가 여러 프로파일 중 하나에 따른 리소스 표현에 대한 선호를 나타낼 수 있도록 허용하는 것이 좋다(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 Alternate Keywords Functional Profile" 프로파일에 대한 적합성을 주장하는 서버에만 관련된다.

"QSA Alternate Keywords Functional Profile"에 대한 적합성을 주장하는 서버는 클라이언트가 "QSA Functional Profile"의 _profile 대신 사용되는 QSA 키와, 어떤 키/값 조합으로든 구현되어야 하는 _profile=alt에 해당하는 것을 발견할 수 있게 하는 방법을 구현해야 한다(MUST). 이를 통해 서버에 대한 지식이 거의 없는 클라이언트도 프로파일 목록 및 프로파일별 리소스 가져오기 요청을 만드는 방법을 발견할 수 있다.

서버는 미디어 유형 및 기타 콘텐츠 협상 차원을 나타내는 데 사용되는 QSA 키도 클라이언트가 발견할 수 있도록 허용하는 것이 좋다(SHOULD).

"QSA Alternate Keywords Functional Profile"이 지원되는 리소스에 대한 어떤 요청에 응답하는 서버도, HTTP 기능 프로파일에 따라 대체 프로파일 및 미디어 유형을 나타내는 HTTP 헤더를 포함하는 것이 좋다(SHOULD). 서버는 대신 또는 추가로 같은 정보를 나타내는 HTTP 본문 콘텐츠를 제공할 수 있다(MAY). 그렇게 하는 경우, 이러한 정보는 URI 요청에 대한 기본 응답, 즉 QSA 없이 이루어진 요청에 대한 응답에 존재하는 것이 좋다(SHOULD). 일련의 예제 요청은 예제 19에 제시되어 있다.

예제 19: QSA 키 탐색을 위한 예제 요청 및 응답

# A client makes a request for Resource A not knowing if any Content
# Negotiation by Profile is supported. It supplies an Accept-Profile
# header just in case. For extra efficiency, the client could have
# made a HEAD request instead of a GET

GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

# The server does not understand the HTTP Get Resource By Profile
# request (doesn't support the HTTP Headers Functional Profile) but is
# able to supply an HTTP Link header indicating alternate resource
# representations. It can be seen from the Link header that keys other
# than _profile & _mediatype are in use - view & format - thus this is
# QSA Alt, not a QSA Functional Profile-conformant system

# The resource representations available conform to profile-x & profile-y.
# The profile-x-conformant representation is available in HTML & Turtle,
# the profile-y-conformant representation is available only in 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"

# Note that here the server does not directly indicate the profile served
# (there is no Link header with rel="profile" present) but this can be inferred
# by the link header with rel="canonical"

위 예제 19의 Link 헤더는 프로파일 목록 요청이 전달하는 모든 정보를 전달하지만, 웹 브라우저에서는 직접 보이지 않는다. 예제 16은 프로파일을 나열하는 동등한 Link 헤더와 HTTP 본문 정보를 포함하는 요청/응답 쌍을 보여주며, 후자는 브라우저에서 볼 수 있다. 그러나 이 요청을 작성하는 클라이언트는 서버의 기본 리소스 표현이 아니라 이 응답을 트리거하는 데 QSA 키/값 쌍 _profile=alt가 사용된다는 것을 알아야 한다.

"QSA Alternate Keywords Functional Profile"을 준수할 때 프로파일 목록에 어떤 QSA 키/값 쌍이 사용되는지를 클라이언트에게 전달하기 위해, 서버는 위의 프로파일 목록 전달 방법을 따라, 리소스의 한 표현이 URI http://www.w3.org/ns/dx/conneg/altr로 식별되는 Alternate Profiles Data Model을 준수하는 것으로 제공된다는 점을 나타내는 것이 좋다(SHOULD). 이는 예제 20에서 보여주며, 이는 예제 19의 확장이다.

예제 20: Alternate Profiles Data Model 적합 응답을 보여주는 이전 예제의 확장

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"

[default response content]

예제 20은 리소스 /resource/a에 대해 7.4 대체 표현 데이터 모델에서 정의된 Alternate Profiles Data Model을 식별하는 URI인 http://www.w3.org/ns/dx/connegp/altr 명세/프로파일을 준수하는 표현이 존재한다는 것을 보여준다.

이 예제는 또한 QSA view=altrep를 사용하여 Alternate Profiles Data Model 적합 응답에 대한 요청을 작성할 수 있음을 보여준다. 따라서 http://example.org/resource/a?view=altrep를 역참조하면 /resource/a의 기본 표현이 아니라, 예제 20의 Link 헤더 콘텐츠와 동등한 콘텐츠도 산출하는 응답이 생성된다.

이 명세의 기능 프로파일에 대한 적합성 입증을 위해 충족해야 하는 요구사항은 기능 프로파일별로 아래에 제시되어 있다.

이 명세에 대한 적합성을 테스트하거나 입증하는 시스템은 여기 제시된 요구사항 ID를 참조하여 수행하는 것이 좋다. 예를 들어 QSA 기능 프로파일에 대한 적합성을 입증할 때, 요구사항 텍스트가 리소스 표현이 준수하는 프로파일은 토큰으로 표시되며, 이 토큰은 쿼리 문자열 인수로 리소스의 URI에 추가되어야 한다(MUST).인 요구사항 R.2.1.a를 충족해야 하며, 서버의 해당 요구사항 구현은 입증 가능해야 한다.

R.1.1.a: 8.2.1 프로파일 목록에서:
프로파일 기반 콘텐츠 협상을 구현하는 서버는 그 리소스의 기본 표현과 모든 대체 표현에 관한 정보, 그리고 그 표현들이 준수하는 프로파일을 포함하는 HTTP Link 헤더를 반환하는 것이 좋다(SHOULD).
R.1.1.b: 8.2.1 프로파일 목록에서:
기본 표현, 즉 특정 표현이 요청되지 않았을 때 반환될 표현은 rel="canonical"로 식별하는 것이 좋고(SHOULD), 다른 표현은 rel="alternate"로 식별하는 것이 좋다.
R.1.2.a: 8.2.2 프로파일별 리소스 가져오기에서:
프로파일 기반 콘텐츠 협상을 구현하는 서버는 반환된 프로파일을 나타내는 rel="profile"이 있는 Link 헤더를 포함한 HTTP 응답 헤더로 응답해야 한다(MUST).
R.1.2.b: 8.2.2 프로파일별 리소스 가져오기에서:
Accept-Profile 헤더에서 참조되는 URI는 꺾쇠괄호 '<' 및 '>'로 둘러싸야 한다(MUST).
R.1.2.c: 8.2.2 프로파일별 리소스 가져오기에서:
허용 가능한 프로파일 URI의 범위를 제공할 수 있으며(MAY), 제공되는 경우 콤마로 구분하거나 별도의 Accept-Profile 헤더에 넣어야 한다(MUST).
R.1.2.d: 8.2.2 프로파일별 리소스 가져오기에서:
선호도는 클라이언트가 URI와 세미콜론 ';'으로 구분된 품질 표시자(q-value)를 순서 지정 메커니즘으로 사용하여 나타낼 수 있다(MAY). q-value가 있는 URI(이 경우 URN)의 예는 <urn:example:profile:x>;q=1.0,이며, 여기서 URI는 <urn:example:profile:x>이고 q-value는 q=1.0이다.

R.2.1.a: 8.3.1.1 QSA URI 설명에서:
리소스 표현이 준수하는 프로파일은 토큰으로 표시되며, 이 토큰은 쿼리 문자열 인수로 리소스의 URI에 추가되어야 한다(MUST).
R.2.1.b: 8.3.2.3 리소스 URL에서:
QSA 기반 프로파일 협상이 이루어지는 리소스 URL은 어떤 QSA 기반 시스템에서도 다른 리소스 URI의 QSA 값 자체가 되지 않는 것이 좋다(SHOULD NOT).
R.2.1.c: 8.3.1.1 QSA URI 설명에서:
[그] 토큰은 하나의 특정 클라이언트/서버 세션 안에서 URI에 매핑 가능해야 한다(MUST).
R.2.1.d: 8.3.1.1 QSA URI 설명에서:
이러한 URI에는 추가 QSA를 사용하거나 다른 기법(예: HTTP 헤더)을 사용하여 콘텐츠 협상의 추가 측면을 포함할 수 있지만(MAY), 포함하는 경우에도 프로파일 기반 콘텐츠 협상 요청의 동작을 변경해서는 안 된다(MUST NOT).
R.2.2.a: 8.3.1.2 키 명명에서:
"QSA Functional Profile"을 준수하려면, 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 프로파일 목록에서:
서버는 HTTP 헤더 기능 프로파일에 따라(Link 헤더 사용) 응답의 HTTP 헤더에 대체 프로파일 정보를 표현하는 것이 좋다(SHOULD).
R.2.3.d: 8.3.2 프로파일 목록에서:
[서버는] 리소스의 기본 프로파일 표현 대신 응답 본문에 그 정보를 표현할 수도 있다(MAY).
R.2.3.e: 8.3.2 프로파일 목록에서:
서버가 HTTP 본문에 대체 프로파일 정보를 제공하는 경우, 서버는 프로파일별 리소스 가져오기 기능에 사용되는 것과 동일한 미디어 유형 협상 방법을 사용하여 클라이언트가 응답의 특정 미디어 유형을 협상할 수 있도록 허용할 수 있다(MAY).
R.2.4.a: 8.3.2.1 QSA 대체 표현 데이터 모델 구현에서:
QSA 기능 프로파일에 따라 이 명세를 구현하는 경우, 구현은 대체 표현 데이터 모델에 따라 대체 표현 정보를 전달해야 한다(MUST).
R.2.4.b: 8.3.2.1 QSA 대체 표현 데이터 모델 구현에서:
HTTP 헤더 기능 프로파일에 따라 HTTP Link 헤더를 사용해 그렇게 할 수도 있고(MAY), 다른 접근 방식을 사용할 수도 있다(MAY).
R.2.4.c: 8.3.2.1 QSA 대체 표현 데이터 모델 구현에서:
HTTP 본문 콘텐츠를 통해, 아마도 HTML 또는 다른 데이터 모델/형식으로 그렇게 할 수 있다.

R.3.1.a: 8.3.1.1 QSA URI 설명에서:
리소스 표현에 대해 요청된 프로파일은 [하나의] 토큰으로 표시되며, 이 토큰은 쿼리 문자열 인수로 리소스의 URI에 추가되어야 한다(MUST).
R.3.1.b: 8.3.2.3 리소스 URL에서:
QSA 기반 프로파일 협상이 이루어지는 리소스 URL은 어떤 QSA 기반 시스템에서도 다른 리소스 URI의 QSA 값 자체가 되지 않는 것이 좋다(SHOULD NOT).
R.3.1.c: 8.3.1.1 QSA URI 설명에서:
[그] 토큰은 하나의 특정 클라이언트/서버 세션 안에서 [프로파일] URI에 매핑 가능해야 한다(MUST).
R.3.1.d: 8.3.1.1 QSA URI 설명에서:
이러한 URI에는 추가 QSA를 사용하거나 다른 기법(예: HTTP 헤더)을 사용하여 콘텐츠 협상의 추가 측면을 포함할 수 있지만(MAY), 포함하는 경우에도 프로파일 기반 콘텐츠 협상 요청의 동작을 변경해서는 안 된다(MUST NOT).
R.3.2.a: 8.3.1.2 키 명명에서:
프로파일 토큰을 나타내기 위해 QSA 키를 사용해야 한다(MUST).
R.3.2.b: 8.3.4 QSA 키 탐색에서:
[서버는] 클라이언트가 "QSA Functional Profile"의 _profile 대신 사용되는 QSA 키를 발견할 수 있게 하는 방법을 구현해야 한다(MUST).
R.3.2.c: 8.3.1.2 키 명명에서:
리소스 표현의 미디어 유형을 나타내기 위해 QSA 키를 사용하는 것이 좋다(SHOULD).
R.3.2.d: 8.3.4 QSA 키 탐색에서:
리소스 표현의 미디어 유형을 나타내는 QSA 키가 구현된 경우, 서버는 클라이언트가 "QSA Functional Profile"의 _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 Functional Profile"의 _profile=alt 대신 사용되는 QSA 키/값 쌍을 발견할 수 있게 하는 방법을 구현해야 한다(MUST).
R.3.3.c: 8.3.2 프로파일 목록에서:
프로파일 목록 요청에 대한 서버의 응답은 해당 리소스의 표현을 지원하는 모든 프로파일 목록과, 선택적으로 그 표현에 대해 지원되는 미디어 유형도 제시하는 것이 좋다(SHOULD).
R.3.3.d: 8.3.2 프로파일 목록에서:
서버는 HTTP 헤더 기능 프로파일에 따라(Link 헤더 사용) 응답의 HTTP 헤더에 대체 프로파일 정보를 표현하는 것이 좋다(SHOULD).
R.3.3.e: 8.3.2 프로파일 목록에서:
[서버는] 리소스의 기본 프로파일 표현 대신 응답 본문에 그 정보를 표현할 수도 있다(MAY).
R.3.3.f: 8.3.2 프로파일 목록에서:
서버가 HTTP 본문에 대체 프로파일 정보를 제공하는 경우, 서버는 프로파일별 리소스 가져오기 기능에 사용되는 것과 동일한 미디어 유형 협상 방법을 사용하여 클라이언트가 응답의 특정 미디어 유형을 협상할 수 있도록 허용할 수 있다(MAY).
R.3.4.a: 8.3.2.1 QSA 대체 표현 데이터 모델 구현에서:
QSA 기능 프로파일에 따라 이 명세를 구현하는 경우, 구현은 대체 표현 데이터 모델에 따라 대체 표현 정보를 전달해야 한다(MUST).
R.3.4.b: 8.3.2.1 QSA 대체 표현 데이터 모델 구현에서:
HTTP 헤더 기능 프로파일에 따라 HTTP Link 헤더를 사용해 그렇게 할 수도 있고(MAY), 다른 접근 방식을 사용할 수도 있다(MAY).
R.3.4.c: 8.3.2.1 QSA 대체 표현 데이터 모델 구현에서:
[그렇게 하는 것은] HTTP 본문 콘텐츠를 통해, 아마도 HTML 또는 다른 데이터 모델/형식으로 가능하다.

이 명세에는 8.1 이 명세의 기능 프로파일에서 식별되고 말로 설명된 여러 개의 서로 다른 기능 프로파일이 포함되어 있다. 이 부록은 Profiles Vocabulary [DX-PROF]에 따라 이러한 기능 프로파일과 그들 사이의 관계에 대한 설명을 제시한다.

코드 목록 1의 RDF(turtle 구문) 코드는 Content Negotiation by Profile을 dcterms:Standard로 정의하며, [DX-PROF]에서의 그 정의는 이 문서의 명세 정의와 일치한다. 이 문서는 동작을 설명하므로 이 명세는 기능 명세임에 유의한다. 그런 다음 그 4개의 프로파일은 일반적인 PROF 모델링에 따라 prof:Profiles라고 불린다. 이 4개의 기능 프로파일은 계층으로 제시되며, 프로파일은 표준을 직접 프로파일링하거나, QSA Functional Profile의 경우처럼 다시 표준을 프로파일링하는 다른 프로파일을 프로파일링한다. 이는 코드 목록 아래의 그림 4에도 그래픽으로 표시되어 있다.

코드 목록 1에 제시된 코드는 RDF 파일 profiles.ttl로도 제공된다.

QSA Functional Profile 프로파일이 QSA Alternate Keywords Functional Profile 프로파일을 프로파일링하는 것으로 모델링된 이유는, QSA Functional Profile 프로파일이 QSA Alternate Keywords Functional Profile보다 Content Negotiation by Profile의 더 제약된 '더 좁은' 명세이며, QSA Functional Profile 프로파일에 적합한 것은 필연적으로 QSA Alternate Keywords Functional Profile 프로파일에도 적합하게 되기 때문이다. 따라서 이는 무언가의 프로파일이 된다는 것의 의미에 대한 [DX-PROF] 정의를 충족한다.

코드 목록 1: Profiles Vocabulary를 사용하여, 8.1 이 명세의 기능 프로파일에 나열된 대로 이 명세와 그 프로파일을 설명한 것.

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 "W3C Recommendation (a standard) for Content Negotiation by Profile"@en . cnpr:http a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ; rdfs:label "HTTP Headers Functional Profile" ; rdfs:comment "For conformance with the functional profile of Content Negotiation by Profile presented in § 7.2 Hypertext Transfer Protocol Headers."@en ; skos:scopeNote "To be used if a resource conforms to the HTTP Headers functional profile"@en . cnpr:qsa a prof:Profile ; prof:isProfileOf cnpr:qsa-alt ; rdfs:label "QSA Functional Profile"@en ; rdfs:comment "For conformance with the functional profile of Content Negotiation by Profile presented in § 7.3 URL Query String Arguments."@en ; skos:scopeNote "To be used if a resource conforms to the QSA Functional Profile using the Query String Arguments _profile and _mediatype as per the recommendations in § 7.3 URL Query String Arguments."@en . cnpr:qsa-alt a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ; rdfs:label "QSA Alternate Keywords Functional Profile" ; rdfs:comment "For conformance with the functional profile of Content Negotiation by Profile presented in § 7.3 URL Query String Arguments."@en ; skos:scopeNote "To be used if a resource conforms to the QSA Functional Profile but uses alternate keywords for the Query String Arguments _profile and _mediatype, as allowed by the recommendations in § 7.3 URL Query String Arguments."@en . cnpr:rrd a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ; rdfs:label "Resource Representation Description Profile"@en ; rdfs:comment "For conformance with Content Negotiation by Profile § 6.3.2 get resource by profile."@en ; skos:scopeNote "To be used if a resource representation is able to indicate which profile(s) it conforms to, in its appropriate functional profile, as per the abstract specification in § 6.3.2 get resource by profile."@en .

그림 4 [[PROF] profiles 계층에 표시된 이 Content Negotiation by Profile 표준의 명세와 프로파일.

8.1 이 명세의 기능 프로파일에 제시된 이 명세의 기능 프로파일 식별과, 이 부록에서 Profiles Vocabulary [DX-PROF]를 사용해 설명된 그 관계를 통해, 시스템은 [DX-PROF] 메커니즘을 사용하여 이 명세 또는 그 기능 프로파일 중 어느 것에 대한 적합성도 보여줄 수 있다. 이는 [DCTERMS] 술어 dcterms:conformsTo를 사용하여 수행된다. 예를 들어 URI <http://example.org/system/a>로 식별되는 시스템이 URI <SPEC_OR_PROFILE_URI>로 식별되는 명세 또는 기능 프로파일에 적합하다고 주장하려면 다음과 같이 할 수 있다.

<http://example.com/system/a> dcterms:conformsTo <SPEC_OR_PROFILE_URI> .

<SPEC_OR_PROFILE_URI>는 이 명세의 URI인 https://www.w3.org/TR/dx-connegp/일 수 있지만, 가장 좋은 경우에는 8.1 이 명세의 기능 프로파일에 나열된 프로파일 URI 중 하나나 다른 기능 프로파일의 URI가 될 것이다. 기능 프로파일 URI는 명세 전체보다 범위가 더 좁기 때문에, 이를 인용하면 무엇에 적합한지 훨씬 더 명확하기 때문이다.

여러 적합성 대상, 즉 이 명세나 그 기능 프로파일에 대한 적합성을 주장하려는 시스템은 dcterms:conformsTo를 여러 번 사용하여 그렇게 할 수 있다.

코드 목록 2의 코드는 [VOCAB-DCAT-2]를 사용하여 문서화되고, 예제 49와 같은 그 예제의 일부를 차용한 가상의 웹 서비스를 보여준다. 여기에는 [VOCAB-DCAT-2] 및 [DX-PROF]에 따라 사용되는 술어 dcterms:conformsTo가 포함되어 있다. 여기서는 QSA Alternate Keywords Functional Profile 프로파일에 대한 적합성을 주장하며, 이는 8.1 이 명세의 기능 프로파일에 따라 식별된 URI http://www.w3.org/ns/dx/connegp/profile/qsa-alt로 표시된다.

코드 목록 2: 이 명세의 QSA Alternate Keywords Functional Profile에 대한 적합성을 주장하는 웹 서비스 예

<http://example.com/service/xx> a dcat:DataService ; dcterms:title "Web Service XX" ; dcterms:description "A dummy Web Service claiming conformance to a profile of the Content Negotiation by Profile specification also annotated with other DCAT-2 recommended properties."@en ; # URI for the QSA Alternate Keywords Functional Profile dcterms:conformsTo <http://www.w3.org/ns/dx/connegp/profile/qsa-alt> ; # it's a public service dcterms:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> # where the service actually is, online dcat:endpointURL <http://example.com/service/v2/xx> ; # a human- and machine-readable documentation endpoint for the service using the # Swagger UI system dcat:endpointDescription <http://example.com/service/v2/xx/swagger> ;

7.4 대체 표현 데이터 모델은 어떤 구체적인 모델링 시스템에도 구현되지 않은 추상 모델을 제시한다. 이 부록은 OWL [OWL2-OVERVIEW]로 이 모델을 구현한 것과, 특정 시나리오에서 사용하도록 제안되는 모델 확장을 모두 제시한다.

7.4 대체 표현 데이터 모델에 있는 데이터 모델의 Web Ontology Language [OWL2-OVERVIEW] 구현은 아래 코드 목록 3에 제시되어 있다. 이는 파일 altr.ttl로도 제공된다.

코드 목록 3: OWL 온톨로지로서의 Alternate Profiles Data Model

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 """This ontology allows for the description of representations of Internet resources. Representations may conform to prof:Profile instances and may have the format of a particular dcterms:MediaType."""@en ; 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 "conforms to" ; dcterms:source dcterms:conformsTo ; skos:scopeNote "Use this property to indicate a dcterms:Standard that a altr:Representation conforms to." ; . altr:hasRepresentation a owl:ObjectProperty ; rdfs:label "has representation" ; skos:definition "Indicates a Representation of a Resource."@en ; rdfs:domain rdfs:Resource ; rdfs:range altr:Representation ; skos:scopeNote "Use this property to indicate a the HTTP-delivered representation of a resource." ; . altr:hasDefaultRepresentation a owl:ObjectProperty ; rdfs:label "has default representation" ; skos:definition "Indicates the default Representation of a Resource."@en ; rdfs:domain altr:Representation ; rdfs:subPropertyOf altr:hasRepresentation ; skos:scopeNote "Use this property to indicate the default HTTP-delivered representation of a resource that is obtained when no further instructions are given to a server to obtain a resource's representation other than the identification (URI) of the resource" ; . rdfs:Resource a owl:Class ; rdfs:label "Resource" ; skos:definition "The class resource, everything."@en ; dcterms:source "http://www.w3.org/2000/01/rdf-schema#Resource" ; skos:scopeNote "In the context of the Alternative Profiles Ontology, rdfs:Resource instances are used to identify Internet resources, that is items identified by a URI." ; . altr:Representation a owl:Class ; rdfs:label "Representation" ; skos:definition "An abstraction of the current or desired state of a thing in HTTP communications."@en ; dcterms:source <https://httpwg.org/specs/rfc7230.html> ; rdfs:isDefinedBy <http://www.w3.org/ns/dx/connegp/altr> ; skos:scopeNote "Use this class to indicate instances of representations of resources" ; . dcterms:Standard a owl:Class ; rdfs:label "Standard" ; skos:definition "A basis for comparison; a reference point against which other things can be evaluated."@en ; dcterms:source "http://purl.org/dc/terms/Standard" ; skos:scopeNote "In the context of the Alternative Profiles Ontology, use this class to indicate instances of information models that representations of resources can conform to." ; .

Alternate Profiles Data Model은 프로파일 기반 콘텐츠 협상 상황에서 유용한 추가 정보를 포함하도록 확장될 수 있다. 명백히 유용한 확장 중 하나는 콘텐츠 협상의 다른 차원, 특히 미디어 유형에 관한 정보를 포함하는 것이다. 코드 목록 4는 코드 목록 4의 OWL로 표현된 것처럼 데이터 모델에 추가될 수 있는 미디어 유형 표시에 대한 Dublin Core Term의 [DCTERMS] dcterms:format 속성과 dcterms:MediaType 클래스의 RDF 정의를 포함한다. 예제 22는 예제 23의 콘텐츠에 이어서 이 확장 모델의 사용 예를 제공한다.

코드 목록 4: 미디어 유형 표현을 처리하기 위한, 이 명세의 Alternate Profiles Data Model에 대한 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 "The file format, physical medium, or dimensions of the resource."@en ; dcterms:source dcterms:format ; rdfs:range dcterms:MediaType ; skos:scopeNote "Use this property to indicate an IANA Media Type of a resource's representation " . ex:defaultFormat a owl:DataTypeProperty ; rdfs:label "default format" ; skos:definition "Indicates the default Representation of a Resource for the specified Standard."@en ; rdfs:domain rdfs:range xsd:boolean ; skos:scopeNote "Use this property to indicate which of more than one resource representations that conforms to a profile is the default for get resource by profile requests." . dcterms:MediaType a owl:Class ; rdfs:label "Media Type" ; skos:definition "A file format or physical medium."@en ; dcterms:source "http://purl.org/dc/terms/MediaType" ; skos:scopeNote "In the context of this mode, use this class to indicate the IANA Media Type of a resource's representation." .

예제 22: 미디어 유형 정보를 보여주는 RDF(turtle)에서의 Alternative Profiles 데이터 모델 확장 구현

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#>

# This Resource A has 5 Representations, the 3rd of which is the default.
# Some of the Representations conform to the same Standard but are formatted
# according to different Media Types. Some Representations contain no Media
# Type information.
<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> .

# This representation is the default for the set of representations
# that conform to <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" .

Alternative Profiles Data Model의 OWL 구현을 준수하여 생성된 RDF 데이터의 예제 인스턴스는 예제 23에 제시되어 있으며, 이어서 동일한 콘텐츠가 여러 형식으로 예제 24에 표시되어 있다.

예제 23: RDF(turtle)에서의 Alternative Profiles Data Model 구현

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#>

# This Resource A has 3 Representations, the 3rd of which is the default
<http://example.org/resource/a>
    a rdfs:Resource ;
    rdfs:label "Resources A" ;
    altr:hasRepresentation :rep-1 , :rep-2 , :rep-3 ;
    altr:hasDefaultRepresentation :rep-3 .

# Each Representation and the Standard each conforms to, 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> .

예제 24: 이전 예제 콘텐츠의 다중 형식 구현

# The content of the previous example expressed as in an HTTP Link header
# as per the HTTP Application Profile of this Specification with the
# default Representation indicated by the use of rel="canonical". Note the
# Representations are seen, one per Link result comma-separated, identified
# only by the combination of the Resource URI, the URI of the Standard to
# which they conform and the rel attribute - they do not have individual
# identifiers
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"

---

# The content of the previous example expressed as in table form
# such as could potentially be expressed in the HTML body of an HTTP
# response. The Resource URIs include Query String Arguments that,
# when specified, allow the individual Representations to be returned,
# as per the QSA Application Profile below.
---------------------------------------------------------------------------------------
| Shortened Resource URI                | URI of profile conformed to       | Default |
---------------------------------------------------------------------------------------
| 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 | Yes     |
---------------------------------------------------------------------------------------

DCAT [VOCAB-DCAT-2] dcat:Dataset은 dcat:DataService를 통해 접근 가능할 수 있으며, 해당 서비스는 이 명세의 하나 이상의 기능 프로파일을 지원할 수 있다. 이 경우 코드 목록 5에 예시된 것처럼, 서비스가 관련 기능 프로파일을 참조할 때 술어 dcterms:conformsTo를 사용하여 지원을 선언하는 것이 좋다.

DCAT 2는 데이터 서비스가 자신이 접근을 제공하는 데이터셋의 개별 데이터 항목을 식별자로 접근할 수 있게 하는지 지정하는 표준적 방법을 제공하지 않으므로, 이 예제는 전체로 배포되는 데이터셋과 관련된다는 점에 유의한다. 그럼에도 dcterms:conformsTo의 사용은 개별 항목에 접근하는 메커니즘을 선언하는 데이터 서비스에도 적용될 수 있다. 이 메커니즘은 dcat:endpointDescription을 통해 식별될 수 있다.

Issue 1146

코드 목록 5: Content Negotiation by Profile을 지원하는 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/> # A Dataset has a Distribution :aDataset dcat:distribution :aDatasetDistribution . # A data profile that the Distribution conforms to ex:someDataProfile a prof:Profile ; # profile details . # A Distribution that can be accessed by a DataService that support Content # Negotiation by Profile. The Distribution's content conforms to the Profile above :aDatasetDistribution a dcat:Distribution ; dcterms:conformsTo ex:someDataProfile ; dcat:accessService ex:connegDataAccessService . # The Service used to access the Dataset's Distribution. The Service itself conforms # to two functional profiles of Content Negotiation by Profile 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> ; # Declare that the Dataset may be invoked by URI, its id, using Content # Negotiation by Profile dcat:endPointURL :aDataset .

프로파일 기반 콘텐츠 협상

초록

이 문서의 상태

프로파일에 관한 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 API

6.4 OAI-PMH

6.5 Catalogue Service for the 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.1.1 HTTP 대체 표현 데이터 모델 구현

8.2.1.2 토큰 매핑

8.2.2 프로파일별 리소스 가져오기

8.3 URL 쿼리 문자열 인수

8.3.1 QSA 기능 프로파일 설명

8.3.1.1 QSA URI 설명

8.3.1.2 키 명명

8.3.2 프로파일 목록

8.3.2.1 QSA 대체 표현 데이터 모델 구현

8.3.2.2 토큰 매핑

8.3.2.3 리소스 URL

8.3.3 프로파일별 리소스 가져오기

8.3.4 QSA 키 탐색

9. Link 속성

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 Content Negotiation by Profile에 대한 DCAT Distributions 지원 설명

B. 참고문헌

B.1 규범 참고문헌

B.2 정보 참고문헌