-
Notifications
You must be signed in to change notification settings - Fork 55
/
index.html
2428 lines (2332 loc) · 134 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 based on
<a>data profiles</a> to which the content conforms. 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>[[?DX-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 the subject of negotiation 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 the profiles 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 further constrain various elements of the dataset's description beyond the more general specification of which they are a profile.
A request for information about possible representations of this dataset's description may
ask for the list of available profiles that are available for the dataset, or may ask specifically for a representation conforming to one specific profile, for example
[[GeoDCAT-AP]]. When no profile or an unsupported profile is requested, a server returns default 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 potential mechanism is URL 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 that conform to the abstract model, HTTP and QSA.
</p>
<p>
The HTTP Header and URL QSA methods are defined as <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 Functional Profiles of the Abstract Model for other environments, including environments that may be realized in the future.
</p>
<p>
Implementers will need to ensure that any Functional Profile
they define implements the Abstract Model's functions and can deliver alternate representation information as per the Alternate Representations Data Model.
</p>
<p>
While this specification only describes HTTP methods for content negotiation by profile via the HTTP Header and URL QSA Functional Profiles, it is expected
that implementers will want to implement functionally equivalent profiles for other environments, some of which may
be not yet 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 resource representations conform to profiles and how profiles and specifications relate to one
+ another is not part of this specification. Some aspects of those questions are addressed by the Profiles Vocabulary
[[?DX-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"></a>,
<a href="#abstractmodel"></a>,
<a href="#functional-profiles"></a> and
<a href="#testsuites"></a>.
Appendices are non-normative.
</p>
<p class="note">Specifications and Profiles to which the content of resource representations may conform will embody their own notions of conformance, which are out of scope for this specification.</p>
</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="https://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="functional specification">functional specification</dfn></dt>
<dd>
<p>
A <a>specification</a>, with human- and/or machine-processable representations,
that defines the behaviour of an application 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>
If the specification profiled is a specialized type of specification, for example a data or a functional
specification, the profile will be of the same sort - a data or functional profile.
</p>
<p>
This Content Negotiation by Profile specification concerns negotiation for data profiles,
and specifies <a href="#functional-profiles-definition">functional profiles</a> for different ways of achieving this.
In this document, most occurrences of the term "profile" refer to "data profile".
</p>
</dd>
<dt><dfn data-lt="data profile">data profile</dfn></dt>
<dd>
<p>
A <a>data specification</a> that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications.
</p>
<p>
This definition includes what are sometimes called "application profiles", "metadata profiles" or "metadata application profiles".
</p>
<p><em>Source: deliberations of the DXWG.</em></p>
</dd>
<dt><dfn data-lt="functional profile">functional profile</dfn></dt>
<dd>
<p>
A <a>functional specification</a> that constrains, extends, combines,
or provides guidance or explanation about the usage of other functional specifications.
</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, methods such as URIs with Query String
Arguments have been previously implemented,
such as 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 Headers 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" (a 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 demonstrates 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 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 the retrieval of resource representations to profiles may also support and demonstrate conformance to this specification by implementing its required functionality, as the functional profiles in this document do.
</p>
</section>
<section id="relatedwork" class="informative">
<h2>Related Work</h2>
<div class="note">
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
be seen as a work-in-progress until this paragraph is removed from this document.
</div>
<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 to which that the body of the response conforms.</p>
<pre id="eg-profile-and-accept" class="example nohighlight" aria-busy="false" aria-live="polite"
title="Using the HTTP Accept header together with a 'profile' parameter">
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, as with the <code>Link</code> header, is
that there is no possibility to work with q-values.
The second 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 honor 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 evaluate 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>data profile</a>
and a <em>format</em> is analogous to an HTTP Media Type.
</p>
<p>
These APIs provide for direct access to resource representations that conform to a particular view, to a
particular format, or to a default view or 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 in 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 to <a>data profiles</a>, 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 entirely XML-based, therefore 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
<a><em>Functional Profiles</em></a>.
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 data 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 over the Internet takes place between a <a>client</a> and a <a>server</a> 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 the requested representation via a <a>response</a>. For any given pair of communicating machines,
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 negotiation by 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 those terms in the definitions section<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>data 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>
<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 and these may not be dereferenceable.
If a token is used, it MUST unambiguously identify the
<a>data 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>data 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> 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 respective
<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>data 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>data 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>data 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>data 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>data profile</a>s to which representations of resources
conform 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>data profile</a>s it is unable to deliver when presented with a <strong>get resource by profile</strong> <a>request</a> specifying that <a>data profile</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 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";
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>data profile</a>.
</p>
<p>
A <a>client</a> executing a <strong>get resource by profile</strong> <a>request</a> MUST
identify the <a>data profile</a> with either a URI or with a token mapping unambiguously to a URI within the session.
</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>data 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 or 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 that 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 responding with a conforming, narrower, profile (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 listed. 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 that are not within the same profile hierarchy
(i.e. the resource conforms to a set of profiles, but some of these are independent, not being specialised
profiles of others in the set), the server SHOULD indicate indicate conformance to each independent profile.
</p>
<p>
For example, using the HTTP Headers Functional Profile, 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</a> in [[?DX-PROF]]), a response 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>
A 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 a resource conforming 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 for which this specification has been created. For
example, the HTTP Application Profile (<a href="#http"></a>) is limited to text within the constraints 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 are
also given in that appendix.
</p>
</section>
<section id="precedence">
<h3>Order of Precedence for Implementation Profiles</h3>
<p>
A service MAY implement multiple <a>functional profile</a>s, including HTTP, QSA and possibly other approaches.
In such cases a client may specify conflicting choices via different mechanisms, for example the common case of
client sending default headers but asking for a specific representation.
The order of precedence defined here determines which mechanism MUST be used.
</p>
<p>
The order of precedence is QSA over HTTP.
This is on the basis that the more precisely a URI points to a resource,
the more likely it is that the agent intends to request that precise resource
irrespective of which HTTP headers are sent with that request.
</p>
<p>
If other potentially conflicting functional profiles of the abstract model are defined, then order of precedence
will need to be established. No specific mechanism is proposed for how this may be declared.
</p>
<div class="issue" data-number="505"></div>
</section>
</section>
<section id="functional-profiles">
<h2>Functional Profiles</h2>
<section id="functional-profiles-definition">
<h3>Functional Profiles of this specification</h3>
<p>
This section illustrates a few <a>functional profiles</a> of this
<a>specification</a>'s <a href="#abstractmodel">Abstract Model</a> for different system environments. They
may be conformed to by systems operating within different environments
wishing to conform to this specification. Conforming to the profiles
illustrated here is not mandatory; conformance to any profile that conforms to the
Abstract Model fulfills conformance to this specification.
</p>
<p>
This specification provides functional profiles of the abstract model for two environments: HTTP Header and human browser (URL Query String
Arguments). It also provides a functional profile that has the single function to respond with which profile(s)
a server response conforms to, and which can be used in multiple environments.
</p>
<div class="issue" data-number="1022"></div>
<p>
For the human browser environment, two functional profiles are presented to demonstrate different modes of use.
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 create additional profiles conforming to this
specification.
</p>
<p class="note" title="Conformance to multiple functional profiles">
The functional profiles provided here are conformant with the Abstract
Model. Systems may implement one or more of the profiles provided in
this document or may develop other functional profiles that conform to
the abstract model. Conformance to one of the profiles provided here
guarantees conformance to the abstract model, but conformance can be
achieved with other functional profiles also. 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.
</p>
<p>
The functional profiles of this specification provided here are listed in <a href="#fig-table-profiles"></a>.
The namespace prefix for them 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>cnpr:http</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">cnpr:qsa</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 URL 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">cnpr:qsa-alt</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 URL 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">cnpr:rrd</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>
The namespace used for the above functional 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 id="http">
<h3>Hypertext Transfer Protocol Headers</h3>
<p>
A 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="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 requests to communicate the conformance of
a request message's content.
</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 and any alternate representations of that
resource including profiles they conform to. The default representation – the one that will be returned when no specific representation is requested –
will be identified by <code>rel="canonical"</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="canonical";
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="canonical";
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";
profile="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]