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