idnits 2.17.1
draft-ietf-httpapi-linkset-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== There is 1 instance of lines with non-ascii characters in the document.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 17 characters in excess of 72.
== There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (6 October 2021) is 932 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4287' is defined on line 1230, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942)
-- Obsolete informational reference (is this intentional?): RFC 5988
(Obsoleted by RFC 8288)
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. Wilde
3 Internet-Draft Axway
4 Intended status: Informational H. Van de Sompel
5 Expires: 9 April 2022 Data Archiving and Networked Services
6 6 October 2021
8 Linkset: Media Types and a Link Relation Type for Link Sets
9 draft-ietf-httpapi-linkset-04
11 Abstract
13 This specification defines two formats and respective media types for
14 representing sets of links as stand-alone documents. One format is
15 JSON-based, the other aligned with the format for representing links
16 in the HTTP "Link" header field. This specification also introduces
17 a link relation type to support discovery of sets of links.
19 Note to Readers
21 Please discuss this draft on the "Building Blocks for HTTP APIs"
22 mailing list (https://www.ietf.org/mailman/listinfo/httpapi).
24 Online access to all versions and files is available on GitHub
25 (https://github.com/ietf-wg-httpapi/linkset).
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at https://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on 9 April 2022.
44 Copyright Notice
46 Copyright (c) 2021 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents (https://trustee.ietf.org/
51 license-info) in effect on the date of publication of this document.
52 Please review these documents carefully, as they describe your rights
53 and restrictions with respect to this document. Code Components
54 extracted from this document must include Simplified BSD License text
55 as described in Section 4.e of the Trust Legal Provisions and are
56 provided without warranty as described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. Use Cases and Motivation . . . . . . . . . . . . . . . . . . 3
63 3.1. Third-Party Links . . . . . . . . . . . . . . . . . . . . 4
64 3.2. Challenges Writing to HTTP Link Header Field . . . . . . 5
65 3.3. Large Number of Links . . . . . . . . . . . . . . . . . . 5
66 4. Document Formats for Sets of Links . . . . . . . . . . . . . 5
67 4.1. HTTP Link Document Format: application/linkset . . . . . 6
68 4.2. JSON Document Format: application/linkset+json . . . . . 7
69 4.2.1. Set of Links . . . . . . . . . . . . . . . . . . . . 7
70 4.2.2. Link Context Object . . . . . . . . . . . . . . . . . 8
71 4.2.3. Link Target Object . . . . . . . . . . . . . . . . . 8
72 4.2.4. Link Target Attributes . . . . . . . . . . . . . . . 10
73 4.2.5. JSON Extensibility . . . . . . . . . . . . . . . . . 14
74 5. The "profile" paramter for media types to Represent Sets of
75 Links . . . . . . . . . . . . . . . . . . . . . . . . . . 15
76 6. The "linkset" Relation Type for Linking to a Set of Links . . 15
77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
78 7.1. Set of Links Provided as application/linkset . . . . . . 16
79 7.2. Set of Links Provided as application/linkset+json . . . . 17
80 7.3. Discovering a Link Set via the "linkset" Link Relation
81 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 19
82 7.4. Link Set Profiles . . . . . . . . . . . . . . . . . . . . 20
83 7.4.1. Using a "profile" Attribute with a "linkset" Link . . 20
84 7.4.2. Using a "profile" Parameter with a Link Set Media
85 Type . . . . . . . . . . . . . . . . . . . . . . . . 21
86 7.4.3. Using a Link with a "profile" Link Relation Type . . 21
87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
88 8.1. Link Relation Type: linkset . . . . . . . . . . . . . . . 22
89 8.2. Media Type: application/linkset . . . . . . . . . . . . . 23
90 8.3. Media Type: application/linkset+json . . . . . . . . . . 24
91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
92 10. Normative References . . . . . . . . . . . . . . . . . . . . 25
93 11. Informative References . . . . . . . . . . . . . . . . . . . 27
94 Appendix A. JSON-LD Context . . . . . . . . . . . . . . . . . . 27
95 Appendix B. Implementation Status . . . . . . . . . . . . . . . 32
96 B.1. GS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
97 B.2. FAIR Signposting Profile . . . . . . . . . . . . . . . . 33
98 B.3. Open Journal Systems (OJS) . . . . . . . . . . . . . . . 33
99 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33
100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
102 1. Introduction
104 Resources on the Web often use typed Web Links [RFC8288], either
105 embedded in resource representations, for example using the
106 element for HTML documents, or conveyed in the HTTP "Link" header
107 field for documents of any media type. In some cases, however,
108 providing links in this manner is impractical or impossible and
109 delivering a set of links as a stand-alone document is preferable.
111 Therefore, this specification defines two document formats that
112 serialize Web Links and their attributes. One serializes links in
113 the same format as used in HTTP the Link header field, and the other
114 as a JSON object. It also defines associated media types to
115 represent sets of links and the "linkset" relation type that supports
116 discovery of any resource that conveys a set of links as a stand-
117 alone document.
119 2. Terminology
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
123 "OPTIONAL" in this document are to be interpreted as described in BCP
124 14 [RFC2119] [RFC8174] when, and only when, they appear in all
125 capitals, as shown here.
127 This specification uses the terms "link context" and "link target" as
128 defined in [RFC8288].
130 In the examples provided in this document, links in the HTTP "Link"
131 header field are shown on separate lines in order to improve
132 readability. Note, however, that as per Section 5.5 of
133 [I-D.ietf-httpbis-semantics], line breaks are deprecated in values
134 for HTTP fields; only whitespaces and tabs are supported as
135 separators.
137 3. Use Cases and Motivation
139 The following sections describe uses cases in which providing links
140 by means of a standalone document instead of in an HTTP "Link" header
141 field or as links embedded in the resource representation is
142 advantageous or necessary.
144 For all scenarios, links could be provided by means of a stand-alone
145 document that is formatted according to the JSON-based serialization,
146 the serialization aligned with the HTTP "Link" field format, or both.
147 The former serialization is motivated by the widespread use of JSON
148 and related tools, which suggests that handling sets of links
149 expressed as JSON documents should be attractive to developers. The
150 latter serialization is provided for compatibility with the existing
151 serialization used in the HTTP "Link" field and to allow reuse of
152 tools created to handle it.
154 It is important to keep in mind that when providing links by means of
155 a standalone representation, other links can still be provided using
156 other approaches, i.e. it is possible combine various mechanisms to
157 convey links.
159 3.1. Third-Party Links
161 In some cases it is useful that links pertaining to a resource are
162 provided by a server other than the one that hosts the resource. For
163 example, this allows:
165 * Providing links in which the resource is involved not just as link
166 context but also as link target.
168 * Providing links pertaining to the resource that the server hosting
169 that resource is not aware of.
171 * External management of links pertaining to the resource in a
172 special-purpose link management service.
174 In such cases, links pertaining to a resource can be provided by
175 another, specific resource. That specific resource may be managed by
176 the same or by another custodian as the resource to which the links
177 pertain. For clients intent on consuming links provided in that
178 manner, it would be beneficial if the following conditions were met:
180 * Links are provided in a document that uses a well-defined media
181 type.
183 * The resource to which the provided links pertain is able to link
184 to the resource that provides these links using a well-known link
185 relation type.
187 These requirements are addressed in this specification through the
188 definition of two media types and a link relation type, respectively.
190 3.2. Challenges Writing to HTTP Link Header Field
192 In some cases, it is not straightforward to write links to the HTTP
193 "Link" header field from an application. This can, for example, be
194 the case because not all required link information is available to
195 the application or because the application does not have the
196 capability to directly write HTTP fields. In such cases, providing
197 links by means of a standalone document can be a solution. Making
198 the resource that provides these links discoverable can be achieved
199 by means of a typed link.
201 3.3. Large Number of Links
203 When conveying links in an HTTP "Link" header field, it is possible
204 for the size of the HTTP response fields to become unpredictable.
205 This can be the case when links are determined dynamically dependent
206 on a range of contextual factors. It is possible to statically
207 configure a web server to correctly handle large HTTP response fields
208 by specifying an upper bound for their size. But when the number of
209 links is unpredictable, estimating a reliable upper bound is
210 challenging.
212 Section 15 of HTTP [I-D.ietf-httpbis-semantics] defines error codes
213 related to excess communication by the user agent ("413 Request
214 Entity Too Large" and "414 Request-URI Too Long"), but no specific
215 error codes are defined to indicate that response field content
216 exceeds the upper bound that can be handled by the server, and thus
217 it has been truncated. As a result, applications take counter
218 measures aimed at controlling the size of the HTTP "Link" header
219 field, for example by limiting the links they provide to those with
220 select relation types, thereby limiting the value of the HTTP "Link"
221 header field to clients. Providing links by means of a standalone
222 document overcomes challenges related to the unpredictable nature of
223 the size of HTTP "Link" header fields.
225 4. Document Formats for Sets of Links
227 This section specifies two document formats to convey a set of links.
228 Both are based on the abstract model specified in Section 2 of Web
229 Linking [RFC8288] that defines a link as consisting of a "link
230 context", a "link relation type", a "link target", and optional
231 "target attributes":
233 * The format defined in Section 4.1 is near identical to the field
234 value of the HTTP "Link" header field as specified in Web Linking
235 Section 3 of [RFC8288].
237 * The format defined in Section 4.2 is based on JSON [RFC8259].
239 Note that Section 3.3 of [RFC8288] deprecates the "rev" construct
240 that was provided by [RFC5988] as a means to express links with a
241 directionality that is the inverse of direct links that use the "rel"
242 construct. In both serializations for link sets defined here,
243 inverse links may be represented as direct links using the "rel"
244 construct and by switching the position of the resources involved in
245 the link.
247 4.1. HTTP Link Document Format: application/linkset
249 This document format is near identical to the field value of the HTTP
250 "Link" header field as defined in Section 3 of [RFC8288], more
251 specifically by its ABNF production rule for "Link" and subsequent
252 ones. It differs only from the format for field values of the HTTP
253 "Link" header in that not only spaces and horizontal tabs are allowed
254 as seperators but also new line characters as a means to improve
255 usability. The use of non-ASCII characters in the field value of the
256 HTTP "Link" Header field is not interoperable.
258 The assigned media type for this format is "application/linkset".
260 When converting an "application/linkset" document to a field value
261 for the HTTP "Link" header, new line characters SHOULD be removed in
262 order to comply with Section 5.5 of [I-D.ietf-httpbis-semantics].
264 In order to support use cases where "application/linkset" documents
265 are re-used outside the context of an HTTP interaction, it is
266 RECOMMENDED to make them self-contained by adhering to the following
267 guidelines:
269 * For every link provided in the set of links, explicitly provide
270 the link context using the "anchor" attribute.
272 * For link context ("anchor" attribute) and link target ("href"
273 attribute), use URI References that are not relative references
274 (as defined in Section 4.1 of [RFC3986]).
276 If these recommendations are not followed, interpretation of links in
277 "application/linkset" documents will depend on which URI is used as
278 context.
280 It should be noted that the "application/linkset" format specified
281 here is different than the "application/link-format" format specified
282 in [RFC6690] in that the former fully matches the field value of the
283 HTTP "Link" header field as defined in Section 3 of [RFC8288],
284 whereas the latter introduces constraints on that definition to meet
285 requirements for Constrained RESTful Environments.
287 4.2. JSON Document Format: application/linkset+json
289 This document format uses JSON [RFC8259] as the syntax to represent a
290 set of links. The set of links follows the abstract model defined by
291 Web Linking Section 2 of [RFC8288].
293 The assigned media type for this format is "application/
294 linkset+json".
296 In order to support use cases where "application/linkset+json"
297 documents are re-used outside the context of an HTTP interaction, it
298 is RECOMMENDED to make them self-contained by adhering to the
299 following guidelines:
301 * For every link provided in the set of links, explicitly provide
302 the link context using the "anchor" member.
304 * For link context ("anchor" member) and link target ("href"
305 member), use URI References that are not relative references (as
306 defined in Section 4.1 of [RFC3986]).
308 If these recommendations are not followed, interpretation of
309 "application/linkset+json" will depend on which URI is used as
310 context URI.
312 The "application/linkset+json" serialization is designed such that it
313 can directly be used as the content of a JSON-LD serialization by
314 adding an appropriate context. Appendix A shows an example of a
315 possible context that, when added to a JSON serialization, allows it
316 to be interpreted as RDF.
318 4.2.1. Set of Links
320 In the JSON representation of a set of links:
322 * A set of links is represented as a JSON object which MUST have
323 "linkset" as its sole member.
325 * The "linkset" member is an array in which a distinct JSON object -
326 the "link context object" (see Section 4.2.2) - is used to
327 represent links that have the same link context.
329 * Even if there is only one link context object, it MUST be wrapped
330 in an array.
332 4.2.2. Link Context Object
334 In the JSON representation one or more links that have the same link
335 context are represented by a JSON object, the link context object. A
336 link context object adheres to the following rules:
338 * Each link context object MAY have an "anchor" member with a value
339 that represents the link context. If present, this value MUST be
340 a URI Reference and SHOULD NOT be a relative reference as per
341 Section 4.1 of [RFC3986].
343 * For each distinct relation type that the link context has with
344 link targets, a link context object MUST have an additional
345 member. This member is an array in which a distinct JSON object -
346 the "link target object" (see Section 4.2.3) - MUST be used for
347 each link target for which the relationship with the link context
348 (value of the encompassing anchor member) applies. The name of
349 this member expresses the relation type of the link as follows:
351 - For registered relation types (Section 2.1.1 of [RFC8288]), the
352 name of this member is the registered name of the relation
353 type.
355 - For extension relation types (Section 2.1.2 of [RFC8288]), the
356 name of this member is the URI that uniquely represents the
357 relation type.
359 * Even if there is only one link target object it MUST be wrapped in
360 an array.
362 4.2.3. Link Target Object
364 In the JSON representation a link target is represented by a JSON
365 object, the link target object. A link target object adheres to the
366 following rules:
368 * Each link target object MUST have an "href" member with a value
369 that represents the link target. This value MUST be a URI
370 Reference and SHOULD NOT be a relative reference as per
371 Section 4.1 of [RFC3986]. Cases where the href member is present,
372 but no value is provided for it (i.e. the resource providing the
373 set of links is the target of the link in the link target object)
374 MUST be handled by providing an "href" member with an empty string
375 ("href": "").
377 * In many cases, a link target is further qualified by target
378 attributes. Various types of attributes exist and they are
379 conveyed as additional members of the link target object as
380 detailed in Section 4.2.4.
382 The following example of a JSON-serialized set of links represents
383 one link with its core components: link context, link relation type,
384 and link target.
386 {
387 "linkset":
388 [
389 { "anchor": "http://example.net/bar",
390 "next": [
391 {"href": "http://example.com/foo"}
392 ]
393 }
394 ]
395 }
397 Figure 1
399 The following example of a JSON-serialized set of links represents
400 two links that share link context and relation type but have
401 different link targets.
403 {
404 "linkset":
405 [
406 { "anchor": "http://example.net/bar",
407 "item": [
408 {"href": "http://example.com/foo1"},
409 {"href": "http://example.com/foo2"}
410 ]
411 }
412 ]
413 }
415 Figure 2
417 The following example shows a set of links that represents two links,
418 each with a different link context, link target, and relation type.
419 One relation type is registered, the other is an extension relation
420 type.
422 {
423 "linkset":
424 [
425 { "anchor": "http://example.net/bar",
426 "next": [
427 {"href": "http://example.com/foo1"}
428 ]
429 },
430 { "anchor": "http://example.net/boo",
431 "http://example.com/relations/baz" : [
432 {"href": "http://example.com/foo2"}
433 ]
434 }
435 ]
436 }
438 Figure 3
440 4.2.4. Link Target Attributes
442 A link may be further qualified by target attributes as defined by
443 Section 2 of Web Linking [RFC8288]. Three types of attributes exist:
445 * Serialisation-defined attributes described in Section 3.4.1 of Web
446 Linking [RFC8288].
448 * Extension attributes defined and used by communities as allowed by
449 Section 3.4.2 of [RFC8288].
451 * Internationalized versions of the "title" attribute defined by
452 [RFC8288] and of extension attributes allowed by Section 3.4 of
453 [RFC8288].
455 The handling of these different types of attributes is described in
456 the sections below.
458 4.2.4.1. Target Attributes Defined by Web Linking
460 Section 3.4.1 of [RFC8288] defines the following target attributes
461 that may be used to annotate links: "hreflang", "media", "title",
462 "title*", and "type"; these target attributes follow different
463 occurrence and value patterns. In the JSON representation, these
464 attributes MUST be conveyed as additional members of the link target
465 object as follows:
467 * "hreflang": The optional and repeatable "hreflang" target
468 attribute MUST be represented by an array (even if there only is
469 one value to be represented), and each value in that array MUST be
470 a string - representing one value of the "hreflang" target
471 attribute for a link - which follows the same model as in the
472 [RFC8288] syntax.
474 * "media": The optional and not repeatable "media" target attribute
475 MUST be represented by a "media" member in the link target object,
476 and its value MUST be a string that follows the same model as in
477 the [RFC8288] syntax.
479 * "type": The optional and not repeatable "type" target attribute
480 MUST be represented by a "type" member in the link target object,
481 and its value MUST be a string that follows the same model as in
482 the [RFC8288] syntax.
484 * "title": The optional and not repeatable "title" target attribute
485 MUST be represented by a "title" member in the link target object,
486 and its value MUST be a string that follows the same model as in
487 the [RFC8288] syntax.
489 * "title*": The optional and not repeatable "title*" target
490 attribute is motivated by character encoding and language issues
491 and follows the model defined in [RFC8187]. The details of the
492 JSON representation that applies to title* are described in
493 Section 4.2.4.2.
495 The following example illustrates how the repeatable "hreflang" and
496 the not repeatable "type" target attributes are represented in a link
497 target object.
499 {
500 "linkset":
501 [
502 { "anchor": "http://example.net/bar",
503 "next": [
504 {"href": "http://example.com/foo",
505 "type": "text/html",
506 "hreflang": [ "en" , "de" ]
507 }
508 ]
509 }
510 ]
511 }
513 Figure 4
515 4.2.4.2. Internationalized Target Attributes
517 In addition to the target attributes described in Section 4.2.4.1,
518 Section 3.4 of [RFC8288] also supports attributes that follow the
519 content model of [RFC8187]. In [RFC8288], these target attributes
520 are recognizable by the use of a trailing asterisk in the attribute
521 name, such as "title*". The content model of [RFC8187] uses a
522 string-based microsyntax that represents the character encoding, an
523 optional language tag, and the escaped attribute value encoded
524 according to the specified character encoding.
526 The JSON serialization for these target attributes MUST be as
527 follows:
529 * An internationalized target attribute is represented as a member
530 of the link context object with the same name (including the *) of
531 the attribute.
533 * The character encoding information as prescribed by [RFC8187] is
534 not preserved; instead, the content of the internationalized
535 attribute is represented in the character encoding used for the
536 JSON set of links.
538 * The value of the internationalized target attribute is an array
539 that contains one or more JSON objects. The name of one member of
540 such JSON object is "value" and its value is the actual content
541 (in its unescaped version) of the internationalized target
542 attribute, i.e. the value of the attribute from which the encoding
543 and language information are removed. The name of another,
544 optional, member of such JSON object is "language" and its value
545 is the language tag [RFC5646] for the language in which the
546 attribute content is conveyed.
548 The following example illustrates how the "title*" target attribute
549 defined by Section 3.4.1 of [RFC8288] is represented in a link target
550 object.
552 {
553 "linkset":
554 [
555 { "anchor": "http://example.net/bar",
556 "next": [
557 {"href": "http://example.com/foo",
558 "type": "text/html",
559 "hreflang": [ "en" , "de" ],
560 "title": "Next chapter",
561 "title*": [ { "value": "nächstes Kapitel" ,
562 "language" : "de" } ]
563 }
564 ]
565 }
566 ]
567 }
569 Figure 5
571 The above example assumes that the German title contains an umlaut
572 character (in the native syntax it would be encoded as title*=UTF-
573 8'de'n%c3%a4chstes%20Kapitel), which gets encoded in its unescaped
574 form in the JSON representation. Implementations MUST properly
575 decode/encode internationalized target attributes that follow the
576 model of [RFC8187] when transcoding between the "application/linkset"
577 and the "application/linkset+json" formats.
579 4.2.4.3. Extension Target Attributes
581 Extension target attributes are attributes that are not defined by
582 Section 3.4.1 of [RFC8288] (as listed in Section 4.2.4.1), but are
583 nevertheless used to qualify links. They can be defined by
584 communities in any way deemed necessary, and it is up to them to make
585 sure their usage is understood by target applications. However,
586 lacking standardization, there is no interoperable understanding of
587 these extension attributes. One important consequence is that their
588 cardinality is unknown to generic applications. Therefore, in the
589 JSON serialization, all extension target attributes are treated as
590 repeatable.
592 The JSON serialization for these target attributes MUST be as
593 follows:
595 * An extension target attribute is represented as a member of the
596 link context object with the same name of the attribute, including
597 the * if applicable.
599 * The value of an extension attribute MUST be represented by an
600 array, even if there only is one value to be represented.
602 * If the extension target attribute does not have a name with a
603 trailing asterisk, then each value in that array MUST be a string
604 that represents one value of the attribute.
606 * If the extension attribute has a name with a trailing asterisk (it
607 follows the content model of [RFC8187]), then each value in that
608 array MUST be a JSON object. The value of each such JSON object
609 MUST be structured as described in Section 4.2.4.2.
611 The example shows a link target object with three extension target
612 attributes. The value for each extension target attribute is an
613 array. The two first are regular extension target attributes, with
614 the first one ("foo") having only one value and the second one
615 ("bar") having two. The last extension target attribute ("baz*")
616 follows the naming rule of [RFC8187] and therefore is encoded
617 according to the serialization described in Section 4.2.4.2.
619 {
620 "linkset":
621 [
622 { "anchor": "http://example.net/bar",
623 "next": [
624 { "href": "http://example.com/foo",
625 "type": "text/html",
626 "foo": [ "foovalue" ],
627 "bar": [ "barone", "bartwo" ],
628 "baz*": [ { "value": "bazvalue" ,
629 "language" : "en" } ]
630 }
631 ]
632 }
633 ]
634 }
636 Figure 6
638 4.2.5. JSON Extensibility
640 The Web linking model ([RFC8288]) provides for the use of extension
641 target attributes as discussed in Section 4.2.4.3. Extensions based
642 on the JSON syntax (such as additional members of the linkset member
643 that are not defined in this specification) SHOULD NOT be used. In
644 case they are used nevertheless, they MUST NOT change the semantics
645 of the JSON members defined in this specification. Agents that
646 consume JSON linkset documents MUST ignore such extensions.
648 This limitation of the JSON format allows to unambiguously round trip
649 between links provided in the HTTP "Link" header field, sets of links
650 serialized according to the "application/linkset" format, and sets of
651 links serialized according to the "application/linkset+json" format.
653 5. The "profile" paramter for media types to Represent Sets of Links
655 As a means to convey specific constraints or conventions (as per
656 [RFC6906]) that apply to a link set document, the "profile"
657 parrameter MAY be used in conjunction with the media types
658 "application/linkset" and "application/linkset+json" detailed in
659 Section 4.1 and Section 4.2, respectively. For example, the
660 parrameter could be used to indicate that a link set uses a specific,
661 limited set of link relation types.
663 The value of the "profile" parrameter MUST be a non-empty list of
664 space-separated URIs, each of which identifies specific constraints
665 or conventions that apply to the link set document. Profile URIs MAY
666 be registered in the IANA Profile URI Registry in the manner
667 specified by [RFC7284].
669 The presence of a "profile" parameter in conjunction with the
670 "application/linkset" and "application/linkset+json" media types does
671 not change the semantics of a link set. As such, clients with and
672 without knowledge of profile URIs can use the same representation.
674 Section 7.4.2 shows an example of using the "profile" parameter in
675 conjunction with the "application/linkset+json" media type.
677 6. The "linkset" Relation Type for Linking to a Set of Links
679 The target of a link with the "linkset" relation type provides a set
680 of links, including links in which the resource that is the link
681 context participates.
683 A link with the "linkset" relation type MAY be provided in the header
684 field and/or the body of a resource's representation. It may also be
685 discovered by other means, such as through client-side information.
687 A resource MAY provide more than one link with a "linkset" relation
688 type. Multiple such links can refer to the same set of links
689 expressed using different media types, or to different sets of links,
690 potentially provided by different third-party services.
692 A user agent that follows a "linkset" link MUST be aware that the set
693 of links provided by the resource that is the target of the link can
694 contain links in which the resource that is the context of the link
695 does not participate; it MAY decide to ignore those links.
697 A user agent that follows a "linkset" link and obtains links for
698 which anchors and targets are expressed as relative references (as
699 per Section 4.1 of [RFC3986]) MUST determine what the context is for
700 these links; it SHOULD ignore links for which it is unable to
701 unambiguously make that determination.
703 As a means to convey specific constraints or conventions (as per
704 [RFC6906]) that apply to a link set document, the "profile" attribute
705 MAY be used in conjunction with the "linkset" link relation type.
706 For example, the attribute could be used to indicate that a link set
707 uses a specific, limited set of link relation types. The value of
708 the "profile" attribute MUST be a non-empty list of space-separated
709 URIs, each of which identifies specific constraints or conventions
710 that apply to the link set document. Profile URIs MAY be registered
711 in the IANA Profile URI Registry in the manner specified by
712 [RFC7284]. Section 7.4.1 shows an example of using the "profile"
713 attribute on a link with the "linkset" relation type, making both the
714 link set and the profile(s) to which it complies discoverable.
716 7. Examples
718 Section 7.1 and Section 7.2 show examples whereby a set of links is
719 provided as "application/linkset" and "application/linkset+json"
720 documents, respectively. Section 7.3 illustrates the use of the
721 "linkset" link relation type to support discovery of sets of links
722 and Section 7.4 shows how to convey profile information pertaining to
723 a links set.
725 7.1. Set of Links Provided as application/linkset
727 Figure 7 shows a client issuing an HTTP GET request against resource
728 .
730 GET /links/resource1 HTTP/1.1
731 Host: example.org
733 Figure 7: Client HTTP GET request
735 Figure 8 shows the response to the GET request of Figure 7. The
736 response contains a Content-Type header field specifying that the
737 media type of the response is "application/linkset". A set of links,
738 revealing authorship and versioning related to resource
739 , is provided in the response body.
740 The HTTP "Link" header field indicates the availability of an
741 alternate representation of the set of links using media type
742 "application/linkset+json".
744 HTTP/1.1 200 OK
745 Date: Mon, 12 Aug 2019 10:35:51 GMT
746 Server: Apache-Coyote/1.1
747 Content-Length: 1023
748 Content-Type: application/linkset
749 Link:
750 ; rel="alternate"
751 ; type="application/linkset+json"
753
754 ; rel="author"
755 ; type="application/rdf+xml"
756 ; anchor="https://example.org/resource1",
757
758 ; rel="latest-version"
759 ; type="text/html"
760 ; anchor="https://example.org/resource1",
761
762 ; rel="predecessor-version"
763 ; type="text/html"
764 ; anchor="https://example.org/resource1?version=3",
765
766 ; rel="predecessor-version"
767 ; type="text/html"
768 ; anchor="https://example.org/resource1?version=2",
769
770 ; rel="memento"
771 ; type="text/html"
772 ; datetime="Thu, 13 Jun 2019 09:34:33 GMT"
773 ; anchor="https://example.org/resource1",
774
775 ; rel="memento"
776 ; type="text/html"
777 ; datetime="Sun, 21 Jul 2019 12:22:04 GMT"
778 ; anchor="https://example.org/resource1",
779
780 ; rel="author"
781 ; anchor="https://example.org/resource1#comment=1"
783 Figure 8: Response to HTTP GET includes a set of links
785 7.2. Set of Links Provided as application/linkset+json
787 Figure 9 shows the client issuing an HTTP GET request against
788 . In the request, the client
789 uses an "Accept" header field to indicate it prefers a response in
790 the "application/linkset+json" format.
792 GET links/resource1 HTTP/1.1
793 Host: example.org
794 Accept: application/linkset+json
796 Figure 9: Client HTTP GET request expressing preference for
797 "application/ linkset+json" response
799 Figure 10 shows the response to the HTTP GET request of Figure 9.
800 The set of links is serialized according to the media type
801 "application/linkset+json".
803 HTTP/1.1 200 OK
804 Date: Mon, 12 Aug 2019 10:46:22 GMT
805 Server: Apache-Coyote/1.1
806 Content-Type: application/linkset+json
807 Link:
808 ; rel="alternate"
809 ; type="application/linkset"
810 Content-Length: 1349
812 {
813 "linkset": [
814 {
815 "anchor": "https://example.org/resource1",
816 "author": [
817 {
818 "href": "https://authors.example.net/johndoe",
819 "type": "application/rdf+xml"
820 }
821 ],
822 "memento": [
823 {
824 "href": "https://example.org/resource1?version=1",
825 "type": "text/html",
826 "datetime": "Thu, 13 Jun 2019 09:34:33 GMT"
827 },
828 {
829 "href": "https://example.org/resource1?version=2",
830 "type": "text/html",
831 "datetime": "Sun, 21 Jul 2019 12:22:04 GMT"
832 }
833 ],
834 "latest-version": [
835 {
836 "href": "https://example.org/resource1?version=3",
837 "type": "text/html"
838 }
839 ]
841 },
842 {
843 "anchor": "https://example.org/resource1?version=3",
844 "predecessor-version": [
845 {
846 "href": "https://example.org/resource1?version=2",
847 "type": "text/html"
848 }
849 ]
850 },
851 {
852 "anchor": "https://example.org/resource1?version=2",
853 "predecessor-version": [
854 {
855 "href": "https://example.org/resource1?version=1",
856 "type": "text/html"
857 }
858 ]
859 },
860 {
861 "anchor": "https://example.org/resource1#comment=1",
862 "author": [
863 {
864 "href": "https://authors.example.net/alice"
865 }
866 ]
867 }
868 ]
869 }
871 Figure 10: Response to the client's request for the set of links
873 7.3. Discovering a Link Set via the "linkset" Link Relation Type
875 Figure 11 shows a client issuing an HTTP HEAD request against
876 resource .
878 HEAD resource1 HTTP/1.1
879 Host: example.org
881 Figure 11: Client HTTP HEAD request
883 Figure 12 shows the response to the HEAD request of Figure 11. The
884 response contains an HTTP "Link" header field with a link that has
885 the "linkset" relation type. It indicates that a set of links is
886 provided by resource , which
887 provides a representation with media type "application/linkset+json".
889 HTTP/1.1 200 OK
890 Date: Mon, 12 Aug 2019 10:45:54 GMT
891 Server: Apache-Coyote/1.1
892 Link:
893 ; rel="linkset"
894 ; type="application/linkset+json"
895 Content-Length: 236
896 Content-Type: text/html;charset=utf-8
898 Figure 12: Response to HTTP HEAD request
900 Section 7.2 shows a client obtaining a set of links by issuing an
901 HTTP GET on the target of the link with the "linkset" relation type,
902 .
904 7.4. Link Set Profiles
906 The examples in this section illustrate the use of the "profile"
907 attribute for a link with the "linkset" link relation type and the
908 "profile" attribute for a link set media type. The examples are
909 inspired by the implementation of link sets by GS1 (the standards
910 body behind many of the world's barcodes).
912 7.4.1. Using a "profile" Attribute with a "linkset" Link
914 Figure 13 shows a client issuing an HTTP HEAD request against trade
915 item 09506000134352 at .
917 HEAD /01/9506000134352 HTTP/1.1
918 Host: id.gs1.org
920 Figure 13: Client HTTP HEAD request
922 Figure 14 shows the server's response to the request of Figure 13,
923 including a "linkset" link with a "profile" attribute that has the
924 Profile URI as its value.
925 Dereferencing that URI yields a profile document that lists all the
926 link relation types that a client can expect when requesting the link
927 set made discoverable by the "linkset" link. For posterity that
928 profile document was saved in the Internet Archive at
929 on 27 September 2021.
932 HTTP/1.1 307 Temporary Redirect
933 Date: Mon, 27 Sep 2021 16:03:07 GMT
934 Server: nginx
935 Link: https://id.gs1.org/01/9506000134352?linkType=all
936 ; rel="linkset"
937 ; type="application/linkset+json"
938 ; profile="https://www.gs1.org/voc/?show=linktypes"
939 Location: https://dalgiardino.com/risotto-rice-with-mushrooms/
941 Figure 14: Response to the client's HEAD request including a
942 "profile" attribute for the "linkset" link
944 7.4.2. Using a "profile" Parameter with a Link Set Media Type
946 Figure 15 shows a client issuing an HTTP HEAD request against the
947 link set that was
948 discovered through the HTTP interactions shown in Section 7.4.1.
950 HEAD /01/9506000134352?linkType=all HTTP/1.1
951 Host: id.gs1.org
953 Figure 15: Client HTTP HEAD request
955 Figure 16 shows the server's response to the request of Figure 15.
956 Note the "profile" parameter for the application/linkset+json media
957 type, which has as value the same Profile URI as was used in xref target="Response_pr_at"/>.
960 HTTP/1.1 200 OK
961 Date: Mon, 27 Sep 2021 16:03:33 GMT
962 Server: nginx
963 Content-Type: application/linkset+json; profile="https://www.gs1.org/voc/?show=linktypes"
964 Content-Length: 396
966 Figure 16: Response to the client's HEAD request including a
967 "profile" parameter for the "application/linkset+json" media type
969 7.4.3. Using a Link with a "profile" Link Relation Type
971 Note that the response Figure 16 from the link set resource is
972 equivalent to the response shown in Figure 17, which leverages the
973 "profile" link relation type defined in [RFC6906].
975 HTTP/1.1 200 OK
976 Date: Mon, 27 Sep 2021 16:03:33 GMT
977 Server: nginx
978 Content-Type: application/linkset+json
979 Link: https://www.gs1.org/voc/?show=linktypes; rel="profile"
980 Content-Length: 396
982 Figure 17: Response to the client's HEAD request including a
983 "profile" link
985 A link with a "profile" link relation type as shown in Figure 17 can
986 also be conveyed in the link set document itself. This is
987 illustrated by Figure 18. Following the recommendation that all
988 links in a link set document should have an explicit anchor, such a
989 link has the URI of the link set itself as anchor and the Profile URI
990 as target. Multiple Profile URIs are handled by using multiple
991 "href" members.
993 {
994 "linkset":
995 [
996 { "anchor": "https://id.gs1.org/01/9506000134352?linkType=all",
997 "profile": [
998 {"href": "https://www.gs1.org/voc/?show=linktypes"}
999 ]
1000 },
1001 { "anchor": "https://id.gs1.org/01/9506000134352",
1002 "https://gs1.org/voc/whatsInTheBox": [
1003 {"href": "https://example.com/en/packContents/GB"}
1004 ]
1005 }
1006 ]
1007 }
1009 Figure 18: A Link Set that declares the profile it complies with
1010 using a "profile" link
1012 8. IANA Considerations
1014 8.1. Link Relation Type: linkset
1016 The link relation type below should be registered by IANA per
1017 Section 6.2.1 of Web Linking [RFC8288]:
1019 Relation Name: linkset
1020 Description: The link target of a link with the "linkset" relation
1021 type provides a set of links, including links in which the link
1022 context of the link participates.
1024 Reference: [[ This document ]]
1026 8.2. Media Type: application/linkset
1028 The Internet media type [RFC6838] for a natively encoded linkset is
1029 application/linkset.
1031 Type name: application
1033 Subtype name: linkset
1035 Required parameters: none
1037 Optional parameters: profile
1039 Encoding considerations: Linksets are encoded according to the
1040 definition of [RFC8288]. The encoding of [RFC8288] is based on
1041 the general encoding rules of [I-D.ietf-httpbis-semantics], with
1042 the addition of allowing indicating character encoding and
1043 language for specific parameters as defined by [RFC8187].
1045 Security considerations: The security considerations of [[ This
1046 document ]] apply.
1048 Interoperability considerations: N/A
1050 Published specification: [[ This document ]]
1052 Applications that use this media type: This media type is not
1053 specific to any application, as it can be used by any application
1054 that wants to interchange web links.
1056 Additional information:
1058 Magic number(s): N/A
1060 File extension(s): This media type does not propose a specific
1061 extension.
1063 Macintosh file type code(s): TEXT
1065 Person & email address to contact for further information: Erik
1066 Wilde
1067 Intended usage: COMMON
1069 Restrictions on usage: none
1071 Author: Erik Wilde
1073 Change controller: IETF
1075 8.3. Media Type: application/linkset+json
1077 The Internet media type [RFC6838] for a JSON-encoded linkset is
1078 application/linkset+json.
1080 Type name: application
1082 Subtype name: linkset+json
1084 Required parameters: none
1086 Optional parameters: profile
1088 Encoding considerations: The encoding considerations of [RFC8259]
1089 apply
1091 Security considerations: The security considerations of [[ This
1092 document ]] apply.
1094 Interoperability considerations: The interoperability
1095 considerations of [RFC8259] apply.
1097 Published specification: [[ This document ]]
1099 Applications that use this media type: This media type is not
1100 specific to any application, as it can be used by any application
1101 that wants to interchange web links.
1103 Additional information:
1105 Magic number(s): N/A
1107 File extension(s): JSON documents often use ".json" as the file
1108 extension, and this media type does not propose a specific
1109 extension other than this generic one.
1111 Macintosh file type code(s): TEXT
1113 Person & email address to contact for further information: Erik
1114 Wilde
1115 Intended usage: COMMON
1117 Restrictions on usage: none
1119 Author: Erik Wilde
1121 Change controller: IETF
1123 9. Security Considerations
1125 The security considerations of Web Linking [RFC8288] apply, as long
1126 as they are not specifically discussing the risks of exposing
1127 information in HTTP header fields.
1129 In general, links may cause information leakage when they expose
1130 information (such as URIs) that can be sensitive or private. Links
1131 may expose "hidden URIs" that are not supposed to be openly shared,
1132 and may not be sufficiently protected. Ideally, none of the URIs
1133 exposed in links should be supposed to be "hidden"; instead, if these
1134 URIs are supposed to be limited to certain users, then technical
1135 measures should be put in place so that accidentally exposing them
1136 does not cause any harm.
1138 For the specific mechanisms defined in this specification, two
1139 security considerations should be taken into account:
1141 * The Web Linking model always has an "implicit context", which is
1142 the resource of the HTTP interaction. This original context can
1143 be lost or can change when self-contained link representations are
1144 moved. Changing the context can change the interpretation of
1145 links when they have no explicit anchor, or when they use relative
1146 URIs. Applications may choose to ignore links that have no
1147 explicit anchor or that use relative URIs when these are exchanged
1148 in stand-alone resources.
1150 * The model introduced in this specification supports "3rd party
1151 links", where one party can provide links that have another
1152 party's resource as an anchor. Depending on the link semantics
1153 and the application context, it is important to verify that there
1154 is sufficient trust in that 3rd party to allow it to provide these
1155 links. Applications may choose to treat 3rd party links
1156 differently than cases where a resource and the links for that
1157 resource are provided by the same party.
1159 10. Normative References
1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1162 Requirement Levels", BCP 14, RFC 2119,
1163 DOI 10.17487/RFC2119, March 1997,
1164 .
1166 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1167 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1168 May 2017, .
1170 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
1171 Interchange Format", STD 90, RFC 8259,
1172 DOI 10.17487/RFC8259, December 2017,
1173 .
1175 [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
1176 DOI 10.17487/RFC8288, October 2017,
1177 .
1179 [RFC8187] Reschke, J., "Indicating Character Encoding and Language
1180 for HTTP Header Field Parameters", RFC 8187,
1181 DOI 10.17487/RFC8187, September 2017,
1182 .
1184 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1185 Resource Identifier (URI): Generic Syntax", STD 66,
1186 RFC 3986, DOI 10.17487/RFC3986, January 2005,
1187 .
1189 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
1190 Specifications and Registration Procedures", BCP 13,
1191 RFC 6838, DOI 10.17487/RFC6838, January 2013,
1192 .
1194 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
1195 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
1196 September 2009, .
1198 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
1199 Code: The Implementation Status Section", RFC 6982,
1200 DOI 10.17487/RFC6982, July 2013,
1201 .
1203 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
1204 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
1205 .
1207 [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
1208 DOI 10.17487/RFC6906, March 2013,
1209 .
1211 [RFC7284] Lanthaler, M., "The Profile URI Registry", RFC 7284,
1212 DOI 10.17487/RFC7284, June 2014,
1213 .
1215 [I-D.ietf-httpbis-semantics]
1216 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
1217 Semantics", Work in Progress, Internet-Draft, draft-ietf-
1218 httpbis-semantics-19, 12 September 2021,
1219 .
1222 11. Informative References
1224 [W3C.REC-json-ld-20140116]
1225 Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0",
1226 World Wide Web Consortium Recommendation REC-json-ld-
1227 20140116, 16 January 2014,
1228 .
1230 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
1231 Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
1232 December 2005, .
1234 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
1235 DOI 10.17487/RFC5988, October 2010,
1236 .
1238 Appendix A. JSON-LD Context
1240 A set of links rendered according to the JSON serialization defined
1241 in Section 4.2 can be interpreted as RDF triples by adding a JSON-LD
1242 context [W3C.REC-json-ld-20140116] that maps the JSON keys to
1243 corresponding Linked Data terms. And, as per
1244 [W3C.REC-json-ld-20140116] section 6.8 (https://www.w3.org/TR/2014/
1245 REC-json-ld-20140116/#interpreting-json-as-json-ld), when delivering
1246 a link set that is rendered according to the "application/
1247 linkset+json" media type to a user agent, a server can convey the
1248 availability of such a JSON-LD context by using a link with the
1249 relation type "http://www.w3.org/ns/json-ld#context" in the HTTP
1250 "Link" header.
1252 Figure 19 shows the response of an HTTP GET against the URI of a link
1253 set resource and illustrates this approach to support discovery of a
1254 JSON-LD Context. The example is inspired by the GS1 implementation
1255 and shows a link set that uses relation types from the GS1 vocabulary
1256 at that are expressed as HTTP URIs.
1258 HTTP/1.1 200 OK
1259 Date: Mon, 11 Oct 2021 10:48:22 GMT
1260 Server: Apache-Coyote/1.1
1261 Content-Type: application/linkset+json
1262 Link:
1263 ; rel="http://www.w3.org/ns/json-ld#context"
1264 ; type="application/ld+json"
1265 Content-Length: 1532
1266 {
1267 "linkset": [
1268 {
1269 "anchor": "https://id.gs1.org/01/09506000149301",
1270 "https://gs1.org/voc/pip": [
1271 {
1272 "href": "https://example.com/en/defaultPage",
1273 "hreflang": [
1274 "en"
1275 ],
1276 "type": "text/html",
1277 "title": "Product information"
1278 },
1279 {
1280 "href": "https://example.com/fr/defaultPage",
1281 "hreflang": [
1282 "fr"
1283 ],
1284 "title": "Information produit"
1285 }
1286 ],
1287 "https://gs1.org/voc/whatsInTheBox": [
1288 {
1289 "href": "https://example.com/en/packContents/GB",
1290 "hreflang": [
1291 "en"
1292 ],
1293 "title": "What's in the box?"
1294 },
1295 {
1296 "href": "https://example.com/fr/packContents/FR",
1297 "hreflang": [
1298 "fr"
1299 ],
1300 "title": "Qu'y a-t-il dans la boite?"
1301 },
1302 {
1303 "href": "https://example.com/fr/packContents/CH",
1304 "hreflang": [
1305 "fr"
1306 ],
1307 "title": "Qu'y a-t-il dans la boite?"
1308 }
1309 ],
1310 "https://gs1.org/voc/relatedVideo": [
1311 {
1312 "href": "https://video.example",
1313 "hreflang": [
1314 "en",
1315 "fr"
1316 ],
1317 "title*": [
1318 {
1319 "value": "See it in action!",
1320 "language": "en"
1321 },
1322 {
1323 "value": "Voyez-le en action!",
1324 "language": "fr"
1325 }
1326 ]
1327 }
1328 ]
1329 }
1330 ]
1331 }
1333 Figure 19: Using a typed link to support discovery of a JSON-LD
1334 Context for a Set of Links
1336 In order to obtain the JSON-LD Context conveyed by the server, the
1337 user agent issues an HTTP GET against the link target of the link
1338 with the "http://www.w3.org/ns/json-ld#context" relation type. The
1339 response to this GET is shown in Figure 20. This particular JSON-LD
1340 context maps "application/linkset+json" representations of link sets
1341 to Dublin Core Terms. Note that the "linkset" entry in the JSON-LD
1342 context is introduced to support links with the "linkset" relation
1343 type in link sets.
1345 HTTP/1.1 200 OK
1346 Content-Type: application/ld+json
1347 Content-Length: 658
1348 {
1349 "@context": [
1350 {
1351 "@version": 1.1,
1352 "@vocab": "https://gs1.org/voc/",
1353 "anchor": "@id",
1354 "href": "@id",
1355 "linkset": {
1356 "@id": "@graph",
1357 "@context": {
1358 "linkset": "linkset"
1359 }
1360 },
1361 "title": {
1362 "@id": "http://purl.org/dc/terms/title"
1363 },
1364 "title*": {
1365 "@id": "http://purl.org/dc/terms/title"
1366 },
1367 "type": {
1368 "@id": "http://purl.org/dc/terms/format"
1369 }
1370 },
1371 {
1372 "language": "@language",
1373 "value": "@value",
1374 "hreflang": {
1375 "@id": "http://purl.org/dc/terms/language",
1376 "@container": "@set"
1377 }
1378 }
1379 ]
1380 }
1382 Figure 20: JSON-LD Context mapping to Dublin Core Terms
1384 Applying the JSON-LD context of Figure 20 to the link set of
1385 Figure 19 allows transforming the "application/linkset+json" link set
1386 to an RDF link set. Figure 21 shows the latter represented by means
1387 of the "text/turtle" RDF serialization.
1389
1390
1391 "text/html" .
1392
1393
1394 "en" .
1395
1396
1397 "Product information" .
1398
1399
1400 "en" .
1401
1402
1403 "What's in the box?" .
1404
1405
1406 "fr" .
1407
1408
1409 "Information produit" .
1410
1411
1412 "fr" .
1413
1414
1415 "Qu'y a-t-il dans la boite?" .
1416
1417
1418 "fr" .
1419
1420
1421 "Qu'y a-t-il dans la boite?" .
1422
1423
1424 .
1425
1426
1427 .
1428
1429
1430 .
1431
1432
1433 .
1434
1435
1436 .
1438
1439
1440 .
1441
1442
1443 "en" .
1444
1445
1446 "fr" .
1447
1448
1449 "See it in action!"@en .
1450
1451
1452 "Voyez-le en action!"@fr .
1454 Figure 21: RDF serialization of the link set resulting from
1455 applying the JSON-LD context
1457 Appendix B. Implementation Status
1459 This section is to be removed before publishing as an RFC.
1461 This section records the status of known implementations of the
1462 protocol defined by this specification at the time of posting of this
1463 Internet-Draft, and is based on a proposal described in RFC 6982
1464 [RFC6982]. The description of implementations in this section is
1465 intended to assist the IETF in its decision processes in progressing
1466 drafts to RFCs. Please note that the listing of any individual
1467 implementation here does not imply endorsement by the IETF.
1468 Furthermore, no effort has been spent to verify the information
1469 presented here that was supplied by IETF contributors. This is not
1470 intended as, and must not be construed to be, a catalog of available
1471 implementations or their features. Readers are advised to note that
1472 other implementations may exist.
1474 According to RFC 6982, "this will allow reviewers and working groups
1475 to assign due consideration to documents that have the benefit of
1476 running code, which may serve as evidence of valuable experimentation
1477 and feedback that have made the implemented protocols more mature.
1478 It is up to the individual working groups to use this information as
1479 they see fit".
1481 B.1. GS1
1483 GS1 is a provider of barcodes (GS1 GTINs and EAN/UPC) for retail
1484 products and manages an ecology of services and standards to leverage
1485 them at a global scale. GS1 has indicated that it will implement
1486 this "linkset" specification as a means to allow requesting and
1487 representing links pertaining to products from various retailers.
1488 Currently, the GS1 Digital Link specification makes an informative
1489 reference to version 03 of the "linkset" I-D. GS1 expresses
1490 confidence that this will become a normative reference in the next
1491 iteration of that specification, likely to be ratified as a GS1
1492 standard around February 2021.
1494 B.2. FAIR Signposting Profile
1496 The FAIR Signposting Profile is a community specification aimed at
1497 improving machine navigation of scholarly objects on the web through
1498 the use of typed web links pointing at e.g. web resources that are
1499 part of a specific object, persistent identifiers for the object and
1500 its authors, license information pertaining to the object. The
1501 specification encourages the use of Linksets and initial
1502 implementations are ongoing, for example, for the open source
1503 Dataverse data repository platform that was initiated by Harvard
1504 University and is meanwhile used by research institutions, worldwide.
1506 B.3. Open Journal Systems (OJS)
1508 Open Journal Systems (OJS) is an open-source software for the
1509 management of peer-reviewed academic journals, and is created by the
1510 Public Knowledge Project (PKP), released under the GNU General Public
1511 License. Open Journal Systems (OJS) is a journal management and
1512 publishing system that has been developed by PKP through its
1513 federally funded efforts to expand and improve access to research.
1515 The OJS platform has implemented "linkset" support as an alternative
1516 way to provide links when there are more than a configured limit
1517 (they consider using about 10 as a good default, for testing purpose
1518 it is currently set to 8).
1520 Acknowledgements
1522 Thanks for comments and suggestions provided by Phil Archer,
1523 Dominique Guinard, Mark Nottingham, Julian Reschke, Rob Sanderson,
1524 Stian Soiland-Reyes, and Sarven Capadisli.
1526 Authors' Addresses
1527 Erik Wilde
1528 Axway
1530 Email: erik.wilde@dret.net
1531 URI: http://dret.net/netdret/
1533 Herbert Van de Sompel
1534 Data Archiving and Networked Services
1536 Email: herbert.van.de.sompel@dans.knaw.nl
1537 URI: https://orcid.org/0000-0002-0715-6126