/
index.html
2370 lines (2280 loc) · 131 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" >
<meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
<title>Content Negotiation by Profile</title>
<link rel="stylesheet" type="text/css" href="extra.css">
</head>
<body class="h-entry" id="respecDocument">
<section id="abstract">
<h2>Abstract</h2>
<p>
This document describes how Internet clients may negotiate for content provided by servers according to
<em>profiles</em>. This is distinct from negotiating by Media Type or Language: a <em>profile</em> may
specify the content of information returned, which may be a subset of the information the responding server has about the requested resource, and may be structured in a specific way to meet interoperability requirements of a community of practice.
</p>
</section>
<section id="sotd">
<!-- The "Status of This Document" section is generated by config.js -->
<section id="FamilyOfDocs">
<h3>Overview of DXWG documents on profiles</h3>
<p>
This document is one from set of documents on profiles, edited by the W3C Dataset Exchange Working Group (DXWG)
and the Internet Engineering Taskforce (IETF). The documents are:
</p>
<ul>
<li>[[PROF]] - the <em>Profiles Vocabulary</em>: an RDF vocabulary that describes profiles and related resources</li>
<li><strong>[PROF-CONNEG] this document, specific guidance on how to negotiate for Internet resource content using profiles</strong></li>
<li>[[PROF-IETF]] - <em>Indicating and Negotiating Profiles in HTTP</em>: an <a href="http://www.ietf.org">IETF</a> <a href="http://www.ietf.org/standards/ids/">Internet-Draft</a> defining HTTP Headers for HTTP content negotiation by profile</li>
<li>The DXWG also plans to provide [[PROF-GUIDANCE]] - <em>Profile Guidance</em>: general recommendations and guidance on profiling.</li>
</ul>
</section>
</section>
<section id="introduction" class="informative">
<h2>Introduction</h2>
<p>
Content delivered by dereferencing Internet identifiers can be negotiated for in different
ways. When using the HTTP protocol [[RFC7230]], a client may set one or more request headers:
</p>
<ul>
<li>an <code>Accept</code> header specifying preferred Media Types which the server may or may not supply</li>
<li>an <code>Accept-Encoding</code> header to request that a specific content encoding system be used</li>
<li>an <code>Accept-Language</code> header to indicate a preferred language</li>
</ul>
<p>
However, clients have not had a
defined way to negotiate for content based on its adherence to an information model - a standard, a <a>specification</a> or
a <a>profile</a>. This document describes how such functionality can be delivered.
</p>
<p>
When online information about a resource adheres to one or more profiles, methods described here allow
clients to request lists of those profiles and request content according to one or more of them, in order of preference.
</p>
<p>
For example, a catalog may offer choices of representations of a dataset's description that conform to different information models, perhaps [[VOID]],
[[VOCAB-DATA-CUBE]] and [[VOCAB-DCAT]]. Furthermore, the [[VOCAB-DCAT]] representation might conform to the
[[DCAT-AP]] profile, the [[GeoDCAT-AP]] profile and perhaps also an organisation-specific profile "MyOrgDCATProfile".
These "narrower" profiles constrains various elements of the dataset's description above and beyond the "broader", more general, specification or profile that they profile.
A request for information about this dataset description's possible representations may
ask for the list of profiles to which conformant representations of it are available, or may ask specifically for a representation conforming to one profile, for example
[[GeoDCAT-AP]]. When no profile or an unsupported profile is requested, a server returns default content,
that is, content conforming to the default profile supported by the server.
</p>
<p>
When selecting a content negotiation mechanism, an Internet client may use the HTTP protocol, but it may also use
other methods for providing instructions to a server. One of potentially many mechanisms is URI Query String
Arguments (<abbr title="Query String Arguments">QSAs</abbr>). QSAs are
useful for humans and machines for situations where negotiation via HTTP is not practical, such
as when manually entering requests into web browsers. This specification provides an abstract model
of content negotiation by profile and presents guidance on the use of two specific methods, HTTP & QSA, that both conform to the abstract model.
</p>
<p>
The HTTP and QSA methods are formally defined in a series of <em>Functional Profiles</em> of the Abstract Model.
While this specification only describes these two Functional Profiles, it is expected
that implementers will want to implement methods, and thus Functional Profiles of the Abstract Model, for other environments, some of which may
not yet be realized – future environments.
</p>
<p>
Implementers will need to ensure that any Functional Profile
they define implements the Abstract Model's functions and can represent alternate representation information as per the Alternate Representations Data Model.
</p>
<p>
While this specification only describes HTTP and QSA methods for content negotiation by profile, it is expected
that implementers will want to implement functionally equivalent methods for other environments, some of which may
not yet be realized; future environments.
</p>
<!--
<p>
Guidance for the creation of <a>profile</a>s is provided in the [[PROF-GUIDANCE]] document created
by the Dataset Exchange Working Group (DXWG).
</p>
-->
<p>
Describing how resources' representations conform to profiles and how profiles and specifications relate to one
another is not part of this specification. Parts of those questions are addressed by the Profiles Vocabulary
[[PROF]], also produced by the DXWG.
</p>
</section>
<section id="conformance">
<p>
For the purpose of compliance, the normative sections of this document are
<a href="#definitions">Section 3</a>,
<a href="#abstractmodel">Section 6</a>,
<a href="#functional-profiles">Section 7</a> and
<a href="#testsuites">Section 8</a>.
</p>
<p class="note">Specifications and Profiles to which the content of resource representations may conform embody their own notions of conformance, which are out of scope for this specification.</p>
<section id="conformance-profiles">
<h3>Profiles for Conformance</h3>
<p>
This specification includes several functional <a>profiles</a> of it that may be conformed to by systems claiming to implement a form of this specification.
These profiles, given in the table below, are identified by URIs and conformance to them by Internet resources should be indicated as per this document (use of
<code>Content-Profile</code> HTTP header).
</p>
<div class="note" title="Different forms of specification and profile">
The <a>profiles</a> identified and described in this section are of a <em>functional</em> <a>specification</a>
since Content Negotiation by Profile describes how systems should behave and it follows that these profiles
are <em>functional</em> profiles. This specification offers test suites (see <a href="#testsuites"></a>) for
assessing the conformance of systems to this functional specification and these functional profiles but does not
address the conformance of resources to the data specifications and data profiles that Content Negotiation by
Profile supplies methods to negotiate about. Such testing is left to the implementers of those data
specifications and data profiles that resources are indicated to conform to.
</div>
<p>
The namespace prefix for the functional profiles used in <a href="#fig-table-profiles"></a>, the table below, is:
</p>
<ul>
<li><code>cnpr</code> → <code>http://www.w3.org/ns/dx/conneg/profile/</code></li>
</ul>
<figure id="fig-table-profiles">
<table>
<thead>
<tr>
<th>URI</th>
<th>Name</th>
<th>Description</th>
<th>Usage Note</th>
</tr>
</thead>
<tbody>
<tr>
<td><code><a href="http://www.w3.org/ns/dx/conneg/profile/http">cnpr:http</a></code></td>
<td>HTTP Headers Functional Profile</td>
<td>For conformance with the functional profile presented in <a href="#http"></a>.</td>
<td>To be used if a resource conforms to the HTTP Headers Functional Profile</td>
</tr>
<tr>
<td><code><span style="white-space: nowrap"><a href="http://www.w3.org/ns/dx/conneg/profile/qsa">cnpr:qsa</a></span></code></td>
<td>QSA Functional Profile</td>
<td>For conformance with the functional profile presented in <a href="#qsa"></a>.</td>
<td>
To be used if a resource conforms to the QSA Functional Profile using the Query String Arguments <code>_profile</code> and <code>_mediatype</code> as per the recommendations
in <a href="#qsa"></a>.
</td>
</tr>
<tr>
<td><code><span style="white-space: nowrap"><a href="http://www.w3.org/ns/dx/conneg/profile/qsa-alt">cnpr:qsa-alt</a></span></code></td>
<td>QSA Alternate Keywords Functional Profile</td>
<td>For conformance with the functional profile presented in <a href="#qsa"></a>.</td>
<td>
To be used if a resource conforms to the QSA Functional Profile but uses alternate keywords for the Query String Arguments <code>_profile</code> and
<code>_mediatype</code>, as allowed by the recommendations in <a href="#qsa"></a>.
</td>
</tr>
<tr>
<td><code><span style="white-space: nowrap"><a href="http://www.w3.org/ns/dx/conneg/profile/rrd">cp:rrd</a></span></code></td>
<td>Resource Representation Description</td>
<td>For conformance with <a href="#getresourcebyprofile"></a>.</td>
<td>
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
<a href="#getresourcebyprofile"></a>.
</td>
</tr>
</tbody>
</table>
<figcaption>
Profiles of this <em>Content Negotiation by Profile</em> specification to be used by resources and systems to indicate conformance to one or more forms
of it.
</figcaption>
</figure>
<p>
If a system wishes to show conformance to this specification, conformance to at least one of the profiles listed in <a href="#fig-table-profiles"></a> MUST be indicated.
</p>
<p>
The namespace used for the above profiles, <code>http://www.w3.org/ns/dx/conneg/profile/</code>, is part of the Dataset Exchange Working Group's reserved W3C namespace,
<code>http://www.w3.org/ns/dx/</code>, which is provisioned for all namespace requirements to do with issues addressed by that Working Group. The <code>/profile/</code> path segment
indicates a register of profile objects which currently contains just the 4 instances above from <a href="#fig-table-profiles"></a>.
</p>
</section>
</section>
<section id="definitions">
<h2>Definitions</h2>
<dl>
<dt><dfn data-lt="specification">specification</dfn></dt>
<dd>
<p>
A basis for comparison; a reference point against which other things can be evaluated.
</p>
<p>
<em>Source: DCMI Metadata Terms [[DCTERMS]]'s definition for a <code><a href="http://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-Standard">Standard</a></code>.</em>
</p>
</dd>
<dt><dfn data-lt="data specification">data specification</dfn></dt>
<dd>
<p>
A <a>specification</a>, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.
</p>
<p><em>Source: deliberations of the DXWG.</em></p>
</dd>
<dt><dfn data-lt="profile">profile</dfn></dt>
<dd>
<p>
A <a>specification</a> that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications.
</p>
<p>
This definition includes what are sometimes called "application profiles", "metadata application
profiles", "data profiles" (when applied to <a>data specifications</a>) or "metadata profiles".
In this document, these are all referred to as just "profiles" and no distinction, in wording, is made
between profiles of different types of specification: data, functional etc.
</p>
<p><em>Source: deliberations of the DXWG.</em></p>
</dd>
<dt><dfn>client</dfn></dt>
<dd>
A program that establishes a connection to a <a>server</a> for the purpose of sending one or more HTTP requests. [[RFC7230]]
</dd>
<dt><dfn>server</dfn></dt>
<dd>
A program that accepts connections in order to service HTTP <a>requests</a> by sending HTTP <a>responses</a>. [[RFC7230]]
</dd>
<dt><dfn>resource</dfn></dt>
<dd>
The entity that is identified by a URI. Familiar examples include an electronic
document, an image, a source of information with a consistent purpose. [[RFC3986]]
</dd>
<dt><dfn>representation</dfn></dt>
<dd>
<p>
An abstraction of the current or desired state of a thing in HTTP communications. [[RFC7230]]
</p>
<p>
In this specification, <em>representations</em> are of <a>resources</a>.
</p>
</dd>
<dt><dfn>metadata</dfn></dt>
<dd>Information that is supplied about a resource. [[RFC3986]]</dd>
<dt><dfn>request</dfn></dt>
<dd>A message sent over the Internet, from a <a>client</a> to a <a>server</a>, for a information about a <a>resource</a>. [[RFC7230]]</dd>
<dt><dfn>response</dfn></dt>
<dd>A message sent over the Internet, from a <a>server</a> to a <a>client</a> answering a <a>request</a> for information about a <a>resource</a>. [[RFC7230]]</dd>
<dt><dfn>token</dfn></dt>
<dd>A short name identifying something. In the context of this document, tokens are sometimes used to identify <a>profiles</a>.</dd>
</dl>
</section>
<section id="motivation" class="informative">
<h2>Motivation</h2>
<p>
In many cases, there are several ways to describe a resource within the scope of a single Media Type.
For instance, XML documents, while conforming to the <code>text/xml</code> Media Type, may adhere to one of
several DTDs or XML Schemas. RDF documents, with a choice of Media Type serializations such as
<code>text/turtle</code>, <code>application/rdf+xml</code> and others, have a large number of vocabularies
(classes and properties) available to use for their content's information model. When a client initiates a request
for an Internet resource, such as an HTTP GET to retrieve a resource's representation, the client and server must have a standardized way to exchange information on how the transmitted resource
will be structured according to DTDs, XML Schema, vocabularies or other standards, specifications or
<a>profiles</a>. When using non-HTTP content negotiation, various methods such as URIs with Query String
Arguments have been implemented previously,
for instance the
<abbr title="Open Archives Initiative - Protocol for Metadata Harvesting">OAI-PMH</abbr> [[OAI-PMH]] and
<abbr title="Open Geospatial Consortium">OGC</abbr>'s
<abbr title="Catalogue Service for the Web">CSW</abbr> [[CSW]] protocols.
</p>
<p>
This document describes an abstract, functions-based, specification for content negotiation by profile and gives both an
HTTP functional profile and two Query String Argument-based functional profiles for the specification's implementation in different environments. The query string
approaches provide both a "fall back" (second, non-HTTP implementation of the abstract specification), as required by the
<a href="https://www.w3.org/2017/dxwg/charter">Dataset Exchange Working Group's Charter</a> (Section 2.3) and also demonstrations functional profiles of the abstract specification that potential functional profile implementers may take as guidance for their implementations.
</p>
<p>
Other query string or REST-based functional profiles and indeed radically different environment's implementation of this abstract specification
are considered possible but are not specified here. In general, existing APIs that support the listing of alternative
profiles for resource representations and retrieval of resource representations to profiles may support and demonstrate conformance to this specification too by implementing its required functionality, as the given functional profiles do.
</p>
</section>
<section id="relatedwork" class="informative">
<h2>Related Work</h2>
<p>
The standardization of the content-negotiation HTTP headers is the purview of the IETF. A first proposal
for an <a href="https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation">Internet Draft
for Indicating and Negotiating Profiles in HTTP</a> [[PROF-IETF]] is available but has not yet been submitted to the IETF. The
current version of the IETF draft (-00) is expected to be completely re-written in parallel work with this document and should
not be seen as anything but work-in-progress until this paragraph is removed from this document.
</p>
<section id="related-http">
<h3>Existing standards for transporting profile information in HTTP headers</h3>
<h4>Using Accept/Content Type together with the profile parameter</h4>
<p>The HTTP Accept and Content-Type header fields [[RFC7231]]
allow a client to specify acceptable Media Types (<code>Accept</code>)
and a server to indicate the Media Type of the response's body (<code>Content-Type</code>).
A Media Type registration can also specify an optional list of Media Type parameters.
Some Media Type registrations (e. g. <code>application/ld+json</code>)
have specified the use of a Media Type parameter "profile"
that could be used to signal the profile that the body of the response conforms to.</p>
<pre id="eg-profile-and-accept" class="example nohighlight" aria-busy="false" aria-live="polite"
title="Using the profile parameter in an Accept header together with the Accept-Profile header">
GET /resource/a HTTP/1.1
Accept: text/turtle;q=0.9;profile="urn:example:profile-1", \
text/turtle;q=0.7;profile="urn:example:profile-2"
--
HTTP/1.1 200 OK
Content-Type: text/turtle;profile="urn:example:profile-2"
</pre>
<p>During 2018, DXWG members had a longer discussion with the <a href="https://www.w3.org/2018/json-ld-wg/">JSON-LD WG</a> at the annual forum TPAC in Lyon, France
and it was concluded that the "profile” parameter in the <code>Accept</code> and <code>Content-Type</code>
headers should be seen to convey profiles that are specific to the Media Type,
such as JSON-LD's "expanded" (<code>http://www.w3.org/ns/json-ld#expanded</code>) or
"flattened" (<code>http://www.w3.org/ns/json-ld#flattened</code>).
In order to signal the use of Media Type-independent profiles,
the http header fields <code>Accept-Profile</code> and <code>Content-Profile</code> are to be used.</p>
<h4>Using a Link header with rel="profile" (RFC 6906)</h4>
<p>The HTTP Link header field [[RFC8288]] relates a web resource (Link Context)
to a target resource (Link Target)
by specifying the relation between the two resources.
One of the relation types is "profile", as defined in [[RFC6906]].
[[RFC6906]] <a data-cite="RFC6906#section-3">defines a profile</a> as
"additional semantics that can be used to process a resource representation […]
that do not alter the basic Media Type semantics"
and specifically states that
"creators and users of profiles MAY define and manage them in a way
that allows them to be used across Media Types".
So the "profile" relation seems like a suitable way
to communicate information about acceptable profiles (requests) and content (responses).</p>
<pre id="eg-link-header-with-profile" class="example nohighlight" aria-busy="false" aria-live="polite"
title="Using a Link header with a profile parameter">
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"
</pre>
<p>There is, however, no possibility to convey quality information (q-values) using the "profile" relation.</p>
<h4>Using the Prefer/Preference-Applied header fields (RFC 7240)</h4>
<p>The http <code>Prefer</code> and <code>Preference-Applied</code> header fields [[RFC7240]]
can be used to convey information about profile preferences.
A client could use the <code>Prefer</code> header to tell the server about
its preference for a resource's representation conforming to a specific profile.
If the server sends a <code>Preference-Applied</code> header field in the response,
the client will know that the preference was honoured.</p>
<pre id="eg-prefer-header-with-profile" class="example nohighlight" aria-busy="false" aria-live="polite"
title="Using a Prefer header with a profile parameter">
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"
</pre>
<p>This approach has two disadvantages.
The first is, as with the <code>Link</code> header,
that there is no possibility to work with q-values.
The second one is that the only way for a server to state
that it ignored the preference indicated by the client
is to omit sending a <code>Preference-Applied</code> header field.
For the client, however, it is not clear
if the <code>Preference-Applied</code> header is absent
because the server did not honour the preference,
or because the server did not understand
the <code>Prefer</code> header.
This could be solved by making it mandatory to send a
<code>Link: rel=profile</code> header when answering a request
with a <code>Prefer: profile=""</code> header in it.
That solution requires that a client evaluates two different headers
to find a response to its request for a specific profile,
which would make client implementation more complicated.</p>
</section>
<section id="related-ark">
<h3>Archival Resource Key (ARK)</h3>
<p>
ARK (Archival Resource Key) [[ARK]] is an identifier scheme
for the persistent identification of information objects.
ARK identifiers can contain an optional qualifier
"that extends the base ARK in order to create a kind of service entry point
into the object named by the NAA [sc. Name Assigning Authority]".
Through a qualifier, any NMA (Name Mapping Authority, a service provider offering ARK resolution)
can supply access to variants of that object.
The set of qualifiers is open and any ARK NAA or NMA can invent its own.
The ARK specification lists versions, languages and formats as examples of qualifiers (§2.5)
and a profile name could be used as a qualifier
to refer to a representation of an information object conforming to that specific profile.
For example, the URI <a href="https://api.istex.fr/ark:/67375/6GQ-MLC8GRWC-5/">https://api.istex.fr/ark:/67375/6GQ-MLC8GRWC-5/</a>
lists XML encodings of metadata for the resource identified by the ARK <code>67375/6GQ-MLC8GRWC-5</code>,
conforming to different XML vocabularies, including "MODS", the Library of Congress'
<a href="https://www.loc.gov/standards/mods/">Metadata Object Description Schema</a>.
</p>
</section>
<section id="related-altviews">
<h3>Linked Data APIs</h3>
<p>
Several Linked Data API tools provide access to different representations of resources, identified by URI, using
Query String Arguments (QSAs). Two examples are the
<a href="http://epimorphics.github.io/elda/current/index.html">ELDA tool by Epimorphics</a>, an
implementation of the <a href="https://github.com/UKGovLD/linked-data-api/blob/wiki/Specification.md">Linked
Data API</a> specification created by the government of the United Kingdom, and <a href="https://pypi.org/project/pyLDAPI/">pyLDAPI</a>, a
Linked Data API implementation by <a href="https://www.csiro.au/">CSIRO</a> in the Python programming language. Both of these tools allow for the
listing of <em>views</em> and <em>formats</em> available for a resource by dereferencing a URL created by
adding the <code>_view=alternates</code> <abbr title='Query String Argument'>QSA</abbr> to the resource URI. The
<em>view</em> named <em>alternates</em> is a special view available for all resources that lists all other views.
</p>
<p>
What these tools call a <em>view</em> is analogous to a <a>profile</a> and a <em>format</em> to an HTTP Media Type.
</p>
<p>
These APIs provide for direct access to resource representations, conforming to a particular view, in a
particular format, or a default view/format if either is unspecified or invalid. For example, using pyLDAPI, the
available views and formats for representations of the address <a href="http://linked.data.gov.au/dataset/gnaf/address/GAACT714845933">GAACT714845933</a>
can by seen by dereferencing <a href="http://linked.data.gov.au/dataset/gnaf/address/GAACT714845933?_view=alternates">http://linked.data.gov.au/dataset/gnaf/address/GAACT714845933<strong>?_view=alternates</strong></a>
and the "ISO19160" <em>view</em> of that Address in the RDF Turtle
<em>format</em>, listed by the Alternates View, is available at <a href="http://linked.data.gov.au/dataset/gnaf/address/GAACT714845933?_view=ISO19160&_format=text/turtle">http://linked.data.gov.au/dataset/gnaf/address/GAACT714845933<strong>?_view=ISO19160&_format=text/turtle</strong></a>.
</p>
</section>
<section id="related-oai-pmh">
<h3>OAI-PMH</h3>
<p>
The Open Archives Initiative Protocol for Metadata Harvesting [[OAI-PMH]] "...provides an
application-independent interoperability framework based on metadata harvesting.". In doing this, OAI-PMH
specifies Query String Argument-based "Protocol Requests and Responses" that allow clients of
<em>Data Providers</em> to: retrieve the metadata <em>formats</em> (analogous profiles, as described in this document) available from a repository
(<code>ListMetadataFormats</code>); retrieve metadata for an identified record (<code>GetRecord</code>),
according to an identified metadata profile (<code>metadataPrefix</code>); perform a number of other repository interrogation tasks; and to
harvest collections of record's metadata, filtered by parameters such as modified date.
</p>
<p>
OAI-PMH requires that representations of all resources in a repository are available according to the same set
of profiles (what it calls <em>formats</em>). It is also entirely XML-based so that profiles, must
all be presented in XML and the content of an XML representation of a resource is presented within an XML
envelope that always identifies the record, the profile, the OAI-PMH method used, the request time and other
common metadata.
</p>
</section>
<section id="related-csw">
<h3>Catalogue Service for the Web (CSW)</h3>
<p>
[[CSW]] is the OGC standard used world-wide by the geospatial community to implement a machine-actionable interface
to catalog services, providing access to metadata about datasets, geospatial services ([[WMS]], [[WFS]], etc.),
as well as other types of resources. Besides supporting common functions such as free-text and faceted search, CSW supports the retrieval of metadata according to a given metadata schema and format, indicated respectively by using <code>outputSchema</code> and <code>outputFormat</code> query parameters. Commonly supported metadata schemas are [[DC11]], and [[ISO-19115]], and the default format is XML. A given CSW instance's supported metadata schemas and formats are described in the service "capabilities" – a machine-readable description of the service interface – that is returned via a <code>GetCapabilities</code> request.
</p>
<p>
Notably, CSW theoretically supports HTTP content negotiation for the metadata format, and the specification defines a conflict resolution mechanism for requests where this information is specified both via HTTP <code>Accept</code> headers and the <code>outputFormat</code> parameter (see Section 6.2 of the <a href="http://docs.opengeospatial.org/is/12-176r7/12-176r7.html">OGC CSW 3.0 specification - HTTP Protocol Binding</a>).
</p>
</section>
</section>
<section id="abstractmodel">
<h2>Abstract Model</h2>
<p>
This section describes a conceptual – abstract – model for content negotiation by profile, independent of any
implementation it within specific environments.
</p>
<p>
Implementations of this Abstract Model for different environments are called <em>Functional <a>Profiles</a></em> and to be a valid functional profile they MUST implement these Abstract Model functions. How they do this will be
environment-specific.
</p>
<p>
Functional Profiles MAY extend upon this Abstract Model with additional features of their own as but these
additions MUST NOT invalidate the functions defined here.
</p>
<p>
A data model for describing the representations of a resource that conform to different profiles is given here
and this model MUST be used by all Functional Profiles. How the data model is realized is left to implementers to
determine. How conformance of implemented data models is demonstrated is not addressed here in detail and only this
guidance is given: implementers SHOULD demonstrate conformance of their Alternate Representations data model
implementations by providing a published mapping between their environment-specific realization of the model and
a concrete realization of the model given in this specification, such as its <a href="#altr-owl">OWL ontology representation</a>.
</p>
<section id="connegbackground">
<h3>Content Negotiation Background</h3>
<p>
All content negotiation takes place between a <a>client</a> and a <a>server</a> over the Internet with the
former requesting a representation of a <a>resource</a> or a <a>resource</a>'s <a>metadata</a> through a
<a>request</a> and receiving it via a <a>response</a>. For any given pair of communicating machines, the
the roles of <a>client</a> and <a>server</a> may be reversed as information is requested back and forth.
</p>
<p>
An Internet <a>resource</a> may have many aspects over which a <a>client</a>/<a>server</a> pair of
agents might negotiate for content. These aspects are to be treated independently so content negotiation for a
resource involving negotiation by profile and any other aspects will not affect each other.
</p>
<!--
<p>
For this reason, other than a directive to maintain independence, no further discussion of
negotiation by profile and the relations to other forms of negotiation are given. Specific functional profiles
might require special handling of profile and other forms of negotiation.
</p>
-->
<p>
In this Abstract Model, we don't assume any specific details about <a>client</a>, <a>server</a>,
<a>resource</a>, <em>metadata</em>, <a>request</a> or <a>response</a> other than those details already
provided in those terms' definitions in <a href="#definitions"></a>.
</p>
</section>
<section id="profileid">
<h3>Profile Identification</h3>
<p>
A <a>client</a> <a>request</a>ing the representation of a <a>resource</a> conforming to a <a>profile</a>
MUST identify the <a>resource</a> by a Uniform Resource Identifier (URI) [[RFC3986]] and MUST
identify the <a>profile</a> either by a URI or a <a>token</a>.
</p>
<div class="issue" data-number="290">
<p>The use of tokens for profile identification
was a controversially discussed topic within the working group
(cf. discussion in <a href="https://github.com/w3c/dxwg/issues/290">#290</a>).</p>
<p>The proponents of tokens stressed the value of short mnemonic identifiers
for human actors using web browsers.
Since browsers usually do not easily allow request headers to be set or modified
the easiest way for human actors to negotiate for profiles
(or any other content dimension)
is to use Query String Arguments (QSAs).
When using QSAs, the profile identifier is put in the query part of the request URI
and since all content in the query part needs to be URL-encoded
this requires that several characters that are common in URIs
(e. g. '<code>:</code>' and '<code>/</code>')
be percent-encoded which is an error-prone process if done manually.
Since tokens are usually restricted to the character group <code>[A-Za-z0-9]</code>,
they have not only the advantage of being shorter than most URIs,
but also that they can be used in the query part of the request URI
without the need to percent-encode any of its characters.
Further, there are several systems already deployed
that build on standards that use tokens for profile identification.</p>
<p>The opponents of tokens questioned the use of tokens from two main angles.
One argument was that while URIs are universally unique,
tokens will introduce non-uniqueness challenges
since there is no universal registry for token/URI mappings
(nor is it likely that there will be one).
The proposed approach that servers publish token/URI mappings for the resources they serve
was seen as unsatisfactory since the scope of that mapping would not be clear:
Would it be valid for a domain, a sub-domain or only for the requested resource?
Following on that, the benefits of such a mapping was generally questioned
on the grounds that machine-driven clients would likely use
http content negotiation with the Accept-Profile and Content-Profile headers
and full profile URIs instead of tokens.
Also, since tokens are not unique,
a client would either need to know a server’s URI/token mappings <em>before</em> using the token
(in which case it could use the URI instead)
or it would need to look it up through the URI/token mapping
(in which case it would need to know the profile URI).
In each case, the client would need to know the profile URI,
which means that tokens do not make client and/or server implementation easier
since in order to conform to the specification
they need to support not only profile URIs but profile tokens, too.</p>
<p>[When this #290 has been resolved, this issue should be turned into a note also saying what the resolution was]</p>
</div>
<p>
If a URI is used for profile identification, it SHOULD be an HTTP
URI that dereferences to a description of the profile. Other kinds or URIs, e. g. URNs MAY also be used andt these may no be capable of dereferencing.
If a token is used, it MUST unambiguously identify the
<a>profile</a> within a <a>request</a>/<a>response</a> pair of messages.
The server MUST declare the context within which the token may be mapped to a URI.
</p>
</section>
<section id="requestsandresonses">
<h3>Requests and Responses</h3>
<p>
There are two main types of <a>request</a> that a <a>client</a> might make of a <a>server</a> regarding
content negotiation by profile. A <a>client</a> wishing to negotiate for content via a profile adhering to this
specification MUST be able to implement these two request types.</p>
<ol>
<li>
<strong>list profiles</strong><br />
a <a>client</a> requests the list of URIs of <a>profile</a>s for which a <a>server</a> is able to deliver
conformant <a>resource</a> <a>representations</a>
</li>
<li>
<strong>get resource by profile</strong>
<br />a <a>client</a> requests a <a>representation</a> of the requested <a>resource</a> represented conforming
to a particular <a>profile</a>
</li>
</ol>
<p>
A <a>server</a> adhering to this specification MUST respond to each request with the following
<a>response</a>s.
</p>
<ol>
<li>
<strong>list profiles</strong><br />
a <a>server</a> responds to a <a>client</a> with the list of URIs of the <a>profiles</a> for which it is able
to deliver conformant <a>resource</a> <a>representations</a>
</li>
<li>
<strong>get resource by profile</strong><br />
a <a>server</a> responds with either a specific <a>profile</a> for a <a>resource</a> conforming to a
requested <a>profile</a> identified by the <a>client</a> or it responds with a default <a>profile</a>
</li>
</ol>
<p>More detailed descriptions of these requests and their responses are given next.</p>
<section id="listprofiles">
<h4>list profiles</h4>
<p>
A <a>client</a> wishes to know for which <a>profile</a>s a <a>server</a> is able to deliver conformant
representations of a <a>resource</a>. The list of profiles may be known either before a <a>request</a> for a
particular <a>resource</a> representation is made or it may only be known after an initial <a>request</a> is
made.
</p>
<p>
The <strong>list profiles</strong> <a>request</a> MUST be either an independent request or part of another
functional profile's request.
</p>
<p>
The <strong>list profiles</strong> <a>request</a> MAY result in a <a>response</a> in one of a
number of formats, provided that the <a>profile</a>s representations of resources
conform to are unambiguously identified either by either a URI or a <a>token</a>. If the latter, it MUST be
mappable to a URI within one particular client/server message pair.
</p>
<p>
A <a>server</a> MUST NOT list <a>profile</a>s that <a>resource</a> representations conform to if
it is unable to deliver those representations when presented with a <strong>get resource by profile</strong>
<a>request</a>.
</p>
<p>
<a href="#eg-list-simple"></a> shows a request/response pair of messages, conforming to the QSA Functional
Profile, where the request is a <em>list profiles</em> request for a particular resource.
</p>
<pre id="eg-list-simple"
class="example nohighlight" aria-busy="false" aria-live="polite"
title="Simple list profiles request & response messages (QSA Functional Profile)">
# A request for all the profiles to which representations of resource a conform
GET /resource/a<strong>?_profile=all</strong> 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 Content-Profile
# header.
HTTP/1.1 200 OK
Content-Type: application/json
Content-Profile: <http://www.w3.org/ns/dx/conneg/profile/qsa>
# This Link header indicates representations ar 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="self"; type="text/html";
profile="http://otherexample.org/profile/x",
<http://example.org/resource/a?_profile=profile-x&_mediatype=text/xml>;
rel="alternate";
type="text/xml";
profile="http://otherexample.org/profile/x",
<http://example.org/resource/a?_profile=profile-y&_mediatype=text/xml>;
rel="alternate";
type="text/xml";
profile="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=text/xml">X, in XML</a></li>
<li><a href="?_profile=profile-y&_mediatype=text/xml">Y, in XML</a></li>
</ul>
</body>
</html>
</pre>
</section>
<section id="getresourcebyprofile">
<h4>get resource by profile</h4>
<p>
The most basic <a>request</a> of content negotiation by profile is for a <a>client</a> to <a>request</a>
a representation of a <a>resource</a> that is claimed to conform to a <a>profile</a>.
</p>
<p>
A <a>client</a> executing a <strong>get resource by profile</strong> <a>request</a> MUST
identify the <a>profile</a> with either a URI or a token mapping unambiguously within a session to a URI.
</p>
<p>
A <a>client</a> executing a <strong>get resource by profile</strong> MAY <a>request</a> a
<a>resource</a> representation conforming to one of any number of <a>profile</a>s with its preference
expressed in a functional profile-specific ordering.
</p>
<p>
The server SHOULD attempt to reply with a profile that best matches the client request. The order of
preference a server MUST follow to determine a best matching profile is: an exact match, followed the
next most specific profile that the resource representation conforms to. Note that resource representations
might conform to more general specifications/other profiles via a hierarchy (i.e. transitively).
</p>
<p>
If a server redirects to another resource it MUST indicate the selected choice of profile from the list
requested by the client and SHOULD indicate a specific narrower profile expected to be returned (if known)
in the redirection request (303 response).
</p>
<div class="note" title="Redirection to another resource">
Since <em>get resource by profile</em> requests are for <a>representations</a> of a <a>resource</a> and resources
for which there are profile-conformant representations may not be information resources, it is important to
note that a server's response may take the form of a redirect to another resource. This is as per the
<a href="https://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html">W3C's recommendations to handle the
so-called 'httpRange-14' issue</a>. An example of a redirecting response is given in <a href="#eg-range14"></a>.
</div>
<p>
A simple request/response message pair with <code>Accept-Profile</code> and <code>Content-Profile</code>
headers included, according to the <a href="#http">HTTP Headers Functional Profile</a>, is shown in
<a href="#eg-simple"></a> and an example with a redirect is shown in <a href="#eg-range14"></a>.
<a href="#eg-narrower-profile-response"></a> shows an HTTP Headers Functional Profile message pair indicating a
narrower profile response than the requested profile.
</p>
<pre id="eg-simple"
class="example nohighlight" aria-busy="false" aria-live="polite"
title="Simple get resource by profile request & response (HTTP Headers Functional Profile)">
# 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
Content-Profile: http://example.org/profile/x
[response body]
</pre>
<pre id="eg-range14"
class="example nohighlight" aria-busy="false" aria-live="polite"
title="Get resource by profile request & response (HTTP Headers Functional Profile) with 303 redirect">
# 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
Content-Profile: http://example.org/profile/x
---
# 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 Content-Profile header
HTTP/1.1 200 OK
[response body]
</pre>
<pre id="eg-narrower-profile-response" class="example nohighlight" aria-busy="false" aria-live="polite"
title="Get resource by profile, narrower profile response (HTTP Headers Functional Profile)">
# 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 lists. Here Profile Y and
# a further profile irrelevant for the client, Profile Z, are
# indicated.
HTTP/1.1 200 OK
[other response headers]
Content-Profile: http://example.org/profile/x, \
http://example.org/profile/y, \
http://example.org/profile/z
[more response headers]
[content conforming to to Profile X, Y & Z]
</pre>
<p>
When a resource is returned that conforms to two or more profiles not within a profile hierarchy
(i.e. none of the multiple profiles the resource conforms to is a profiles of another), the server MUST
indicate all profiles individually within the <code>Content-Profile</code> header as such:
</p>
<p>
<code>Content-Profile: <PROFILE_1>, <PROFILE_2></code>
</p>
<p>
For example, a response from a server that conforms to both [[?GeoDCAT-AP]] and also [[?STATDCAT-AP]], given
that neither profiles the other and thus no single indication of conformance will suffice for both, (note they
both do profile [[?DCAT-AP]], see the <a href="https://www.w3.org/TR/dx-prof/#eg-hierarchy">DCAT-AP Hierarchy
example in [[PROF]]</a>), using profile URIs for [[?GeoDCAT-AP]] and [[?STATDCAT-AP]] could be:
</p>
<p>
<code>Content-Profile: <https://joinup.ec.europa.eu/release/geodcat-ap-v10>, <https://joinup.ec.europa.eu/release/statdcat-ap/101></code>
</p>
</section>
</section>
<section id="altr">
<h3>Alternate Representations Data Model</h3>
<p>
This data model, MUST be used for describing the representations of a resource that conform to different
profiles.
</p>
<p>
An graphical overview of this model is given in <a href="#fig-altr-model"></a>.
</p>
<figure id="fig-altr-model">
<img src="altr.svg" alt="Alternate Profiles data model" style="width:60%" />
<figcaption>
A diagram of the Alternate Profiles data model implemented in OWL [[OWL2-OVERVIEW]].
</figcaption>
</figure>
<p>
Descriptions of alternate representations of resource according to different profiles MAY be presented according
to modelling systems implementing this model, depending
on what is deemed to be relevant to the application profile of this specification that they are created for. For
example, the HTTP Application Profile (<a href="#http"></a>) is limited to text within the constrains of the
HTTP specification's headers structure in [[RFC7230]] and thus syntactic communication of this data model in
that environment must be implemented according to its constraints.
</p>
<p>
Tools for testing the conformance of data instances to some implementations of this data model are given in
<a href="#testsuites"></a>. Suggestions for concrete implementations of, and extensions to, this data model for
use in expected situations are given in <a href="#altr-detail"></a>. Examples of suggested use as per the are
also given in Functional Profiles of this specification are also given in that appendix.
</p>
</section>
</section>
<section id="functional-profiles">
<h2>Functional Profiles</h2>
<p>
This section describes <a>profiles</a> of this <a>specification</a>'s Abstract Model which are implementations of it
in different environments; they are profiles and may be referred to as "functional profiles". These profiles are
formally identified in <a href="#conformance-profiles"></a> and are to be used as conformance targets for specific
implementations of systems within different environments wishing to conform to this specification.
</p>
<p>
This document provides functional profiles for two environments - HTTP & human browser (Query String
Argument functionality) only. For the human browser environment, two functional profiles are presented.
Further functional profiles of this specification MAY be implemented either for other environments and or even for
constrained scenarios within these environments and implementers are encouraged to do this by further profiling this
specification.
</p>
<p class="note" title="Conformance to profiles">
Implementers of Content Negotiation by Profile need not ensure systems conform to multiple functional profiles
of this specification. They need only conform to the functional profile(s) relevant to their environment. In some
cases, for example the Query String Argument-relevant human browser environment, there is a choice of more than
one functional profile. Since all functional profiles of this specification themselves must conform to this specification, by
design, conformance to any functional profile guarantees conformance to the specification.
</p>
<section id="http">
<h3>Hypertext Transfer Protocol Headers</h3>
<p>
An functional profile of the Abstract Model using Hypertext Transfer Protocol (HTTP) headers is presented here.
This implementation is based on HTTP content negotiation and uses <code>Link</code> headers formulated in
particular ways and two new HTTP headers,
<code>Accept-Profile</code> and <code>Content-Profile</code> that are to be defined in an upcoming
Internet-Draft [[PROF-IETF]].
</p>
<div class="note" title="Feature at risk">
<p>
The use of HTTP headers to transport information
about which profiles the response message's content conforms to
is <strong>at risk</strong> pending the IETF standardisation work.
</p>
</div><div class="issue" data-number="678"></div>
<div class="note" title="Issue 678: POST/PUT out of scope">
<p>
POST & PUT methods are considered out-of-scope for this Functional Profile. It is not clear what functions of
the proposed Abstract Model these HTTP methods would implement.
</p>
<p>
<code>Content-Profile</code> headers may be specified in POST & PUT request to communicate the conformance of a
request message's content but the Working Group has no specified requirements for this.
</p>
</div>
<p>
Although servers are free to implement negotiation as they see fit,
if the User Agent sends an <code>Accept-Profile</code> header,
they SHOULD consider representations not conforming to any of the listed profiles
as non-interpretable by the client.
This means that a representation that conforms to a listed profile,
but has a low preference score on other dimensions,
SHOULD be considered as more desired than
a representation with a higher preference score on other dimensions
but that does not conform to any listed profile.
If no <code>Accept-Profile</code> header preference is given,
the profile dimension SHOULD be ignored for negotiation purposes.
Nevertheless, in all cases,
the server's response SHOULD contain a <code>Content-Profile</code> header
listing the URIs of all profiles to which it knows the representation conforms.
</p>
<section id="http-listprofiles">
<h3>list profiles</h3>
<p>
The preferred way to retrieve a list of profiles the server supports for a specific resource
is to issue a <code>GET</code> or <code>HEAD</code> request for that resource.
In either case, a server implementing
content negotiation by profile SHOULD return an HTTP <code>Link</code> header containing information about the
default representation of that resource and information about any alternate representations of that
resource conforming to other profiles. The returned representation will be identified by <code>rel="self"</code>, other representations by
<code>rel="alternate"</code>.
</p>
<p>As an example, consider the resource <code>http://example.org/resource/a</code> available
in the Media Types <code>application/xml</code>, <code>text/html</code> and <code>text/turtle</code>.
The <code>text/html</code> representation has
no profile, whereas the <code>application/xml</code> and <code>text/turtle</code> representations are
both available in the profiles <code>urn:example:profile:x</code> and <code>urn:example:profile:y</code>.
</p>
<p>
Assuming that a request without an <code>Accept-Profile</code> header per default delivers content conforming to
<code>urn:example:profile:x</code>, an HTTP request/response pair would look as per
<a href="#eg-link-headers"></a>.
</p>
<pre id="eg-link-headers" class="example nohighlight" aria-busy="false" aria-live="polite"
title="Server returns a Link header to indicate available profiles">
HEAD /resource/a HTTP/1.1
Accept: text/turtle
[more request headers]
---
HTTP/1.1 200 OK
Content-Type: text/turtle
Content-Profile: urn:example:profile:x
Link:
<http://example.org/resource/a>;
rel="self";
type="text/turtle";
profile="urn:example:profile:x",
<http://example.org/resource/a>;
rel="alternate";
type="text/turtle";
profile="urn:example:profile:y",
<http://example.org/resource/a>;
rel="alternate";
type="application/xml";
profile="urn:example:profile:x",
<http://example.org/resource/a>;
rel="alternate";
type="application/xml";
profile="urn:example:profile:y",
<http://example.org/resource/a>;
rel="alternate";
type="text/html"
[more response headers]
</pre>
<p>
In <a href="#eg-link-headers"></a>, for each of the different Media Type / Profile combinations, the URI of
the resource remains unchanged and it is the <code>Accept</code> and <code>Accept-Profile</code> headers for
Media Type and Profile respectively that alter the returned response.
</p>
<p>
A server MAY use <code>Content-Location</code> HTTP headers to indicate direct links to representations of the
resource according to Media Type / Profile combinations and, if it does so, it may replace the unchanged URI
in the Link header with those direct URIs, as per example <a href=""></a>.
</p>
<pre id="eg-link-headers-loc" class="example nohighlight" aria-busy="false" aria-live="polite"
title="Server returns Link header with Content-Location URIs for some Profiles and Media Types">
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
Content-Profile: <urn:example:profile:x>
Link:
<strong><http://example.org/resource/a.prof1.ttl>;</strong>
rel="self";
type="text/turtle";
profile="urn:example:profile:x",
<http://example.org/resource/a>;
rel="alternate";
type="text/turtle";
profile="urn:example:profile:y",
<strong><http://example.org/resource/a.prof1.xml>;</strong>
rel="alternate";
type="application/xml";
profile="urn:example:profile:x",
<http://example.org/resource/a>;
rel="alternate";
type="application/xml";