idnits 2.17.1 draft-ietf-httpapi-linkset-05.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 (21 October 2021) is 918 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4287' is defined on line 1233, 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: 24 April 2022 Data Archiving and Networked Services 6 21 October 2021 8 Linkset: Media Types and a Link Relation Type for Link Sets 9 draft-ietf-httpapi-linkset-05 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 24 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" parameter 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 separators but also newline 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, newline 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 target 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. No other form of 642 extensions SHOULD be used. In case they are used nevertheless, they 643 MUST NOT change the semantics of the JSON members defined in this 644 specification. Agents that consume JSON linkset documents MUST 645 ignore such extensions. 647 This limitation of the JSON format allows to unambiguously round trip 648 between links provided in the HTTP "Link" header field, sets of links 649 serialized according to the "application/linkset" format, and sets of 650 links serialized according to the "application/linkset+json" format. 652 5. The "profile" parameter for media types to Represent Sets of Links 654 As a means to convey specific constraints or conventions (as per 655 [RFC6906]) that apply to a link set document, the "profile" parameter 656 MAY be used in conjunction with the media types "application/linkset" 657 and "application/linkset+json" detailed in Section 4.1 and 658 Section 4.2, respectively. For example, the parameter could be used 659 to indicate that a link set uses a specific, limited set of link 660 relation types. 662 The value of the "profile" parameter MUST be a non-empty list of 663 space-separated URIs, each of which identifies specific constraints 664 or conventions that apply to the link set document. Profile URIs MAY 665 be registered in the IANA Profile URI Registry in the manner 666 specified by [RFC7284]. 668 The presence of a "profile" parameter in conjunction with the 669 "application/linkset" and "application/linkset+json" media types does 670 not change the semantics of a link set. As such, clients with and 671 without knowledge of profile URIs can use the same representation. 673 Section 7.4.2 shows an example of using the "profile" parameter in 674 conjunction with the "application/linkset+json" media type. 676 6. The "linkset" Relation Type for Linking to a Set of Links 678 The target of a link with the "linkset" relation type provides a set 679 of links, including links in which the resource that is the link 680 context participates. 682 A link with the "linkset" relation type MAY be provided in the header 683 field and/or the body of a resource's representation. It may also be 684 discovered by other means, such as through client-side information. 686 A resource MAY provide more than one link with a "linkset" relation 687 type. Multiple such links can refer to the same set of links 688 expressed using different media types, or to different sets of links, 689 potentially provided by different third-party services. 691 A user agent that follows a "linkset" link MUST be aware that the set 692 of links provided by the resource that is the target of the link can 693 contain links in which the resource that is the context of the link 694 does not participate; it MAY decide to ignore those links. 696 A user agent that follows a "linkset" link and obtains links for 697 which anchors and targets are expressed as relative references (as 698 per Section 4.1 of [RFC3986]) MUST determine what the context is for 699 these links; it SHOULD ignore links for which it is unable to 700 unambiguously make that determination. 702 As a means to convey specific constraints or conventions (as per 703 [RFC6906]) that apply to a link set document, the "profile" attribute 704 MAY be used in conjunction with the "linkset" link relation type. 705 For example, the attribute could be used to indicate that a link set 706 uses a specific, limited set of link relation types. The value of 707 the "profile" attribute MUST be a non-empty list of space-separated 708 URIs, each of which identifies specific constraints or conventions 709 that apply to the link set document. Profile URIs MAY be registered 710 in the IANA Profile URI Registry in the manner specified by 711 [RFC7284]. Section 7.4.1 shows an example of using the "profile" 712 attribute on a link with the "linkset" relation type, making both the 713 link set and the profile(s) to which it complies discoverable. 715 7. Examples 717 Section 7.1 and Section 7.2 show examples whereby a set of links is 718 provided as "application/linkset" and "application/linkset+json" 719 documents, respectively. Section 7.3 illustrates the use of the 720 "linkset" link relation type to support discovery of sets of links 721 and Section 7.4 shows how to convey profile information pertaining to 722 a links set. 724 7.1. Set of Links Provided as application/linkset 726 Figure 7 shows a client issuing an HTTP GET request against resource 727 . 729 GET /links/resource1 HTTP/1.1 730 Host: example.org 732 Figure 7: Client HTTP GET request 734 Figure 8 shows the response to the GET request of Figure 7. The 735 response contains a Content-Type header field specifying that the 736 media type of the response is "application/linkset". A set of links, 737 revealing authorship and versioning related to resource 738 , is provided in the response body. 739 The HTTP "Link" header field indicates the availability of an 740 alternate representation of the set of links using media type 741 "application/linkset+json". 743 HTTP/1.1 200 OK 744 Date: Mon, 12 Aug 2019 10:35:51 GMT 745 Server: Apache-Coyote/1.1 746 Content-Length: 1023 747 Content-Type: application/linkset 748 Link: 749 ; rel="alternate" 750 ; type="application/linkset+json" 752 753 ; rel="author" 754 ; type="application/rdf+xml" 755 ; anchor="https://example.org/resource1", 756 757 ; rel="latest-version" 758 ; type="text/html" 759 ; anchor="https://example.org/resource1", 760 761 ; rel="predecessor-version" 762 ; type="text/html" 763 ; anchor="https://example.org/resource1?version=3", 764 765 ; rel="predecessor-version" 766 ; type="text/html" 767 ; anchor="https://example.org/resource1?version=2", 768 769 ; rel="memento" 770 ; type="text/html" 771 ; datetime="Thu, 13 Jun 2019 09:34:33 GMT" 772 ; anchor="https://example.org/resource1", 773 774 ; rel="memento" 775 ; type="text/html" 776 ; datetime="Sun, 21 Jul 2019 12:22:04 GMT" 777 ; anchor="https://example.org/resource1", 778 779 ; rel="author" 780 ; anchor="https://example.org/resource1#comment=1" 782 Figure 8: Response to HTTP GET includes a set of links 784 7.2. Set of Links Provided as application/linkset+json 786 Figure 9 shows the client issuing an HTTP GET request against 787 . In the request, the client 788 uses an "Accept" header field to indicate it prefers a response in 789 the "application/linkset+json" format. 791 GET links/resource1 HTTP/1.1 792 Host: example.org 793 Accept: application/linkset+json 795 Figure 9: Client HTTP GET request expressing preference for 796 "application/ linkset+json" response 798 Figure 10 shows the response to the HTTP GET request of Figure 9. 799 The set of links is serialized according to the media type 800 "application/linkset+json". 802 HTTP/1.1 200 OK 803 Date: Mon, 12 Aug 2019 10:46:22 GMT 804 Server: Apache-Coyote/1.1 805 Content-Type: application/linkset+json 806 Link: 807 ; rel="alternate" 808 ; type="application/linkset" 809 Content-Length: 1349 811 { 812 "linkset": [ 813 { 814 "anchor": "https://example.org/resource1", 815 "author": [ 816 { 817 "href": "https://authors.example.net/johndoe", 818 "type": "application/rdf+xml" 819 } 820 ], 821 "memento": [ 822 { 823 "href": "https://example.org/resource1?version=1", 824 "type": "text/html", 825 "datetime": "Thu, 13 Jun 2019 09:34:33 GMT" 826 }, 827 { 828 "href": "https://example.org/resource1?version=2", 829 "type": "text/html", 830 "datetime": "Sun, 21 Jul 2019 12:22:04 GMT" 831 } 832 ], 833 "latest-version": [ 834 { 835 "href": "https://example.org/resource1?version=3", 836 "type": "text/html" 837 } 838 ] 840 }, 841 { 842 "anchor": "https://example.org/resource1?version=3", 843 "predecessor-version": [ 844 { 845 "href": "https://example.org/resource1?version=2", 846 "type": "text/html" 847 } 848 ] 849 }, 850 { 851 "anchor": "https://example.org/resource1?version=2", 852 "predecessor-version": [ 853 { 854 "href": "https://example.org/resource1?version=1", 855 "type": "text/html" 856 } 857 ] 858 }, 859 { 860 "anchor": "https://example.org/resource1#comment=1", 861 "author": [ 862 { 863 "href": "https://authors.example.net/alice" 864 } 865 ] 866 } 867 ] 868 } 870 Figure 10: Response to the client's request for the set of links 872 7.3. Discovering a Link Set via the "linkset" Link Relation Type 874 Figure 11 shows a client issuing an HTTP HEAD request against 875 resource . 877 HEAD resource1 HTTP/1.1 878 Host: example.org 880 Figure 11: Client HTTP HEAD request 882 Figure 12 shows the response to the HEAD request of Figure 11. The 883 response contains an HTTP "Link" header field with a link that has 884 the "linkset" relation type. It indicates that a set of links is 885 provided by resource , which 886 provides a representation with media type "application/linkset+json". 888 HTTP/1.1 200 OK 889 Date: Mon, 12 Aug 2019 10:45:54 GMT 890 Server: Apache-Coyote/1.1 891 Link: 892 ; rel="linkset" 893 ; type="application/linkset+json" 894 Content-Length: 236 895 Content-Type: text/html;charset=utf-8 897 Figure 12: Response to HTTP HEAD request 899 Section 7.2 shows a client obtaining a set of links by issuing an 900 HTTP GET on the target of the link with the "linkset" relation type, 901 . 903 7.4. Link Set Profiles 905 The examples in this section illustrate the use of the "profile" 906 attribute for a link with the "linkset" link relation type and the 907 "profile" attribute for a link set media type. The examples are 908 inspired by the implementation of link sets by GS1 (the standards 909 body behind many of the world's barcodes). 911 7.4.1. Using a "profile" Attribute with a "linkset" Link 913 Figure 13 shows a client issuing an HTTP HEAD request against trade 914 item 09506000134352 at . 916 HEAD /01/9506000134352 HTTP/1.1 917 Host: id.gs1.org 919 Figure 13: Client HTTP HEAD request 921 Figure 14 shows the server's response to the request of Figure 13, 922 including a "linkset" link with a "profile" attribute that has the 923 Profile URI as its value. 924 Dereferencing that URI yields a profile document that lists all the 925 link relation types that a client can expect when requesting the link 926 set made discoverable by the "linkset" link. For posterity that 927 profile document was saved in the Internet Archive at 928 on 27 September 2021. 931 HTTP/1.1 307 Temporary Redirect 932 Date: Mon, 27 Sep 2021 16:03:07 GMT 933 Server: nginx 934 Link: https://id.gs1.org/01/9506000134352?linkType=all 935 ; rel="linkset" 936 ; type="application/linkset+json" 937 ; profile="https://www.gs1.org/voc/?show=linktypes" 938 Location: https://dalgiardino.com/risotto-rice-with-mushrooms/ 940 Figure 14: Response to the client's HEAD request including a 941 "profile" attribute for the "linkset" link 943 7.4.2. Using a "profile" Parameter with a Link Set Media Type 945 Figure 15 shows a client issuing an HTTP HEAD request against the 946 link set that was 947 discovered through the HTTP interactions shown in Section 7.4.1. 949 HEAD /01/9506000134352?linkType=all HTTP/1.1 950 Host: id.gs1.org 952 Figure 15: Client HTTP HEAD request 954 Figure 16 shows the server's response to the request of Figure 15. 955 Note the "profile" parameter for the application/linkset+json media 956 type, which has as value the same Profile URI as was used in xref target="Response_pr_at"/>. 959 HTTP/1.1 200 OK 960 Date: Mon, 27 Sep 2021 16:03:33 GMT 961 Server: nginx 962 Content-Type: application/linkset+json; profile="https://www.gs1.org/voc/?show=linktypes" 963 Content-Length: 396 965 Figure 16: Response to the client's HEAD request including a 966 "profile" parameter for the "application/linkset+json" media type 968 7.4.3. Using a Link with a "profile" Link Relation Type 970 Note that the response Figure 16 from the link set resource is 971 equivalent to the response shown in Figure 17, which leverages the 972 "profile" link relation type defined in [RFC6906]. 974 HTTP/1.1 200 OK 975 Date: Mon, 27 Sep 2021 16:03:33 GMT 976 Server: nginx 977 Content-Type: application/linkset+json 978 Link: https://www.gs1.org/voc/?show=linktypes; rel="profile" 979 Content-Length: 396 981 Figure 17: Response to the client's HEAD request including a 982 "profile" link 984 A link with a "profile" link relation type as shown in Figure 17 can 985 also be conveyed in the link set document itself. This is 986 illustrated by Figure 18. Following the recommendation that all 987 links in a link set document should have an explicit anchor, such a 988 link has the URI of the link set itself as anchor and the Profile URI 989 as target. Multiple Profile URIs are handled by using multiple 990 "href" members. 992 { 993 "linkset": 994 [ 995 { "anchor": "https://id.gs1.org/01/9506000134352?linkType=all", 996 "profile": [ 997 {"href": "https://www.gs1.org/voc/?show=linktypes"} 998 ] 999 }, 1000 { "anchor": "https://id.gs1.org/01/9506000134352", 1001 "https://gs1.org/voc/whatsInTheBox": [ 1002 {"href": "https://example.com/en/packContents/GB"} 1003 ] 1004 } 1005 ] 1006 } 1008 Figure 18: A Link Set that declares the profile it complies with 1009 using a "profile" link 1011 8. IANA Considerations 1013 8.1. Link Relation Type: linkset 1015 The link relation type below should be registered by IANA per 1016 Section 6.2.1 of Web Linking [RFC8288]: 1018 Relation Name: linkset 1019 Description: The link target of a link with the "linkset" relation 1020 type provides a set of links, including links in which the link 1021 context of the link participates. 1023 Reference: [[ This document ]] 1025 8.2. Media Type: application/linkset 1027 The Internet media type [RFC6838] for a natively encoded linkset is 1028 application/linkset. 1030 Type name: application 1032 Subtype name: linkset 1034 Required parameters: none 1036 Optional parameters: profile 1038 Encoding considerations: Linksets are encoded according to the 1039 definition of [RFC8288], with the addition of allowing newline 1040 characters as whitespace characters. The encoding of [RFC8288] is 1041 based on the general encoding rules of 1042 [I-D.ietf-httpbis-semantics], with the addition of allowing 1043 indicating character encoding and language for specific parameters 1044 as defined by [RFC8187]. 1046 Security considerations: The security considerations of [[ This 1047 document ]] apply. 1049 Interoperability considerations: N/A 1051 Published specification: [[ This document ]] 1053 Applications that use this media type: This media type is not 1054 specific to any application, as it can be used by any application 1055 that wants to interchange web links. 1057 Additional information: 1059 Magic number(s): N/A 1061 File extension(s): This media type does not propose a specific 1062 extension. 1064 Macintosh file type code(s): TEXT 1066 Person & email address to contact for further information: Erik 1067 Wilde 1069 Intended usage: COMMON 1071 Restrictions on usage: none 1073 Author: Erik Wilde 1075 Change controller: IETF 1077 8.3. Media Type: application/linkset+json 1079 The Internet media type [RFC6838] for a JSON-encoded linkset is 1080 application/linkset+json. 1082 Type name: application 1084 Subtype name: linkset+json 1086 Required parameters: none 1088 Optional parameters: profile 1090 Encoding considerations: The encoding considerations of [RFC8259] 1091 apply 1093 Security considerations: The security considerations of [[ This 1094 document ]] apply. 1096 Interoperability considerations: The interoperability 1097 considerations of [RFC8259] apply. 1099 Published specification: [[ This document ]] 1101 Applications that use this media type: This media type is not 1102 specific to any application, as it can be used by any application 1103 that wants to interchange web links. 1105 Additional information: 1107 Magic number(s): N/A 1109 File extension(s): JSON documents often use ".json" as the file 1110 extension, and this media type does not propose a specific 1111 extension other than this generic one. 1113 Macintosh file type code(s): TEXT 1115 Person & email address to contact for further information: Erik 1116 Wilde 1118 Intended usage: COMMON 1120 Restrictions on usage: none 1122 Author: Erik Wilde 1124 Change controller: IETF 1126 9. Security Considerations 1128 The security considerations of Web Linking [RFC8288] apply, as long 1129 as they are not specifically discussing the risks of exposing 1130 information in HTTP header fields. 1132 In general, links may cause information leakage when they expose 1133 information (such as URIs) that can be sensitive or private. Links 1134 may expose "hidden URIs" that are not supposed to be openly shared, 1135 and may not be sufficiently protected. Ideally, none of the URIs 1136 exposed in links should be supposed to be "hidden"; instead, if these 1137 URIs are supposed to be limited to certain users, then technical 1138 measures should be put in place so that accidentally exposing them 1139 does not cause any harm. 1141 For the specific mechanisms defined in this specification, two 1142 security considerations should be taken into account: 1144 * The Web Linking model always has an "implicit context", which is 1145 the resource of the HTTP interaction. This original context can 1146 be lost or can change when self-contained link representations are 1147 moved. Changing the context can change the interpretation of 1148 links when they have no explicit anchor, or when they use relative 1149 URIs. Applications may choose to ignore links that have no 1150 explicit anchor or that use relative URIs when these are exchanged 1151 in stand-alone resources. 1153 * The model introduced in this specification supports "3rd party 1154 links", where one party can provide links that have another 1155 party's resource as an anchor. Depending on the link semantics 1156 and the application context, it is important to verify that there 1157 is sufficient trust in that 3rd party to allow it to provide these 1158 links. Applications may choose to treat 3rd party links 1159 differently than cases where a resource and the links for that 1160 resource are provided by the same party. 1162 10. Normative References 1164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1165 Requirement Levels", BCP 14, RFC 2119, 1166 DOI 10.17487/RFC2119, March 1997, 1167 . 1169 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1170 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1171 May 2017, . 1173 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1174 Interchange Format", STD 90, RFC 8259, 1175 DOI 10.17487/RFC8259, December 2017, 1176 . 1178 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 1179 DOI 10.17487/RFC8288, October 2017, 1180 . 1182 [RFC8187] Reschke, J., "Indicating Character Encoding and Language 1183 for HTTP Header Field Parameters", RFC 8187, 1184 DOI 10.17487/RFC8187, September 2017, 1185 . 1187 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1188 Resource Identifier (URI): Generic Syntax", STD 66, 1189 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1190 . 1192 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1193 Specifications and Registration Procedures", BCP 13, 1194 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1195 . 1197 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1198 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1199 September 2009, . 1201 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1202 Code: The Implementation Status Section", RFC 6982, 1203 DOI 10.17487/RFC6982, July 2013, 1204 . 1206 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1207 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1208 . 1210 [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, 1211 DOI 10.17487/RFC6906, March 2013, 1212 . 1214 [RFC7284] Lanthaler, M., "The Profile URI Registry", RFC 7284, 1215 DOI 10.17487/RFC7284, June 2014, 1216 . 1218 [I-D.ietf-httpbis-semantics] 1219 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1220 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1221 httpbis-semantics-19, 12 September 2021, 1222 . 1225 11. Informative References 1227 [W3C.REC-json-ld-20140116] 1228 Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0", 1229 World Wide Web Consortium Recommendation REC-json-ld- 1230 20140116, 16 January 2014, 1231 . 1233 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1234 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 1235 December 2005, . 1237 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 1238 DOI 10.17487/RFC5988, October 2010, 1239 . 1241 Appendix A. JSON-LD Context 1243 A set of links rendered according to the JSON serialization defined 1244 in Section 4.2 can be interpreted as RDF triples by adding a JSON-LD 1245 context [W3C.REC-json-ld-20140116] that maps the JSON keys to 1246 corresponding Linked Data terms. And, as per 1247 [W3C.REC-json-ld-20140116] section 6.8 (https://www.w3.org/TR/2014/ 1248 REC-json-ld-20140116/#interpreting-json-as-json-ld), when delivering 1249 a link set that is rendered according to the "application/ 1250 linkset+json" media type to a user agent, a server can convey the 1251 availability of such a JSON-LD context by using a link with the 1252 relation type "http://www.w3.org/ns/json-ld#context" in the HTTP 1253 "Link" header. 1255 Figure 19 shows the response of an HTTP GET against the URI of a link 1256 set resource and illustrates this approach to support discovery of a 1257 JSON-LD Context. The example is inspired by the GS1 implementation 1258 and shows a link set that uses relation types from the GS1 vocabulary 1259 at that are expressed as HTTP URIs. 1261 HTTP/1.1 200 OK 1262 Date: Mon, 11 Oct 2021 10:48:22 GMT 1263 Server: Apache-Coyote/1.1 1264 Content-Type: application/linkset+json 1265 Link: 1266 ; rel="http://www.w3.org/ns/json-ld#context" 1267 ; type="application/ld+json" 1268 Content-Length: 1532 1269 { 1270 "linkset": [ 1271 { 1272 "anchor": "https://id.gs1.org/01/09506000149301", 1273 "https://gs1.org/voc/pip": [ 1274 { 1275 "href": "https://example.com/en/defaultPage", 1276 "hreflang": [ 1277 "en" 1278 ], 1279 "type": "text/html", 1280 "title": "Product information" 1281 }, 1282 { 1283 "href": "https://example.com/fr/defaultPage", 1284 "hreflang": [ 1285 "fr" 1286 ], 1287 "title": "Information produit" 1288 } 1289 ], 1290 "https://gs1.org/voc/whatsInTheBox": [ 1291 { 1292 "href": "https://example.com/en/packContents/GB", 1293 "hreflang": [ 1294 "en" 1295 ], 1296 "title": "What's in the box?" 1297 }, 1298 { 1299 "href": "https://example.com/fr/packContents/FR", 1300 "hreflang": [ 1301 "fr" 1302 ], 1303 "title": "Qu'y a-t-il dans la boite?" 1304 }, 1305 { 1306 "href": "https://example.com/fr/packContents/CH", 1307 "hreflang": [ 1308 "fr" 1309 ], 1310 "title": "Qu'y a-t-il dans la boite?" 1311 } 1312 ], 1313 "https://gs1.org/voc/relatedVideo": [ 1314 { 1315 "href": "https://video.example", 1316 "hreflang": [ 1317 "en", 1318 "fr" 1319 ], 1320 "title*": [ 1321 { 1322 "value": "See it in action!", 1323 "language": "en" 1324 }, 1325 { 1326 "value": "Voyez-le en action!", 1327 "language": "fr" 1328 } 1329 ] 1330 } 1331 ] 1332 } 1333 ] 1334 } 1336 Figure 19: Using a typed link to support discovery of a JSON-LD 1337 Context for a Set of Links 1339 In order to obtain the JSON-LD Context conveyed by the server, the 1340 user agent issues an HTTP GET against the link target of the link 1341 with the "http://www.w3.org/ns/json-ld#context" relation type. The 1342 response to this GET is shown in Figure 20. This particular JSON-LD 1343 context maps "application/linkset+json" representations of link sets 1344 to Dublin Core Terms. Note that the "linkset" entry in the JSON-LD 1345 context is introduced to support links with the "linkset" relation 1346 type in link sets. 1348 HTTP/1.1 200 OK 1349 Content-Type: application/ld+json 1350 Content-Length: 658 1351 { 1352 "@context": [ 1353 { 1354 "@version": 1.1, 1355 "@vocab": "https://gs1.org/voc/", 1356 "anchor": "@id", 1357 "href": "@id", 1358 "linkset": { 1359 "@id": "@graph", 1360 "@context": { 1361 "linkset": "linkset" 1362 } 1363 }, 1364 "title": { 1365 "@id": "http://purl.org/dc/terms/title" 1366 }, 1367 "title*": { 1368 "@id": "http://purl.org/dc/terms/title" 1369 }, 1370 "type": { 1371 "@id": "http://purl.org/dc/terms/format" 1372 } 1373 }, 1374 { 1375 "language": "@language", 1376 "value": "@value", 1377 "hreflang": { 1378 "@id": "http://purl.org/dc/terms/language", 1379 "@container": "@set" 1380 } 1381 } 1382 ] 1383 } 1385 Figure 20: JSON-LD Context mapping to Dublin Core Terms 1387 Applying the JSON-LD context of Figure 20 to the link set of 1388 Figure 19 allows transforming the "application/linkset+json" link set 1389 to an RDF link set. Figure 21 shows the latter represented by means 1390 of the "text/turtle" RDF serialization. 1392 1393 1394 "text/html" . 1395 1396 1397 "en" . 1398 1399 1400 "Product information" . 1401 1402 1403 "en" . 1404 1405 1406 "What's in the box?" . 1407 1408 1409 "fr" . 1410 1411 1412 "Information produit" . 1413 1414 1415 "fr" . 1416 1417 1418 "Qu'y a-t-il dans la boite?" . 1419 1420 1421 "fr" . 1422 1423 1424 "Qu'y a-t-il dans la boite?" . 1425 1426 1427 . 1428 1429 1430 . 1431 1432 1433 . 1434 1435 1436 . 1437 1438 1439 . 1441 1442 1443 . 1444 1445 1446 "en" . 1447 1448 1449 "fr" . 1450 1451 1452 "See it in action!"@en . 1453 1454 1455 "Voyez-le en action!"@fr . 1457 Figure 21: RDF serialization of the link set resulting from 1458 applying the JSON-LD context 1460 Appendix B. Implementation Status 1462 This section is to be removed before publishing as an RFC. 1464 This section records the status of known implementations of the 1465 protocol defined by this specification at the time of posting of this 1466 Internet-Draft, and is based on a proposal described in RFC 6982 1467 [RFC6982]. The description of implementations in this section is 1468 intended to assist the IETF in its decision processes in progressing 1469 drafts to RFCs. Please note that the listing of any individual 1470 implementation here does not imply endorsement by the IETF. 1471 Furthermore, no effort has been spent to verify the information 1472 presented here that was supplied by IETF contributors. This is not 1473 intended as, and must not be construed to be, a catalog of available 1474 implementations or their features. Readers are advised to note that 1475 other implementations may exist. 1477 According to RFC 6982, "this will allow reviewers and working groups 1478 to assign due consideration to documents that have the benefit of 1479 running code, which may serve as evidence of valuable experimentation 1480 and feedback that have made the implemented protocols more mature. 1481 It is up to the individual working groups to use this information as 1482 they see fit". 1484 B.1. GS1 1486 GS1 is a provider of identifiers, most famously seen in EAN/UPC 1487 barcodes for retail and healthcare products, and manages an ecology 1488 of services and standards to leverage them at a global scale. GS1 1489 has indicated that it will fully implement this "linkset" 1490 specification as a means to allow requesting and representing links 1491 pertaining to products, shipments, assets and locations. Currently, 1492 the GS1 Digital Link specification makes an informative reference to 1493 version 03 of the "linkset" I-D. GS1 expresses confidence that this 1494 will become a normative reference in the next iteration of that 1495 specification. 1497 B.2. FAIR Signposting Profile 1499 The FAIR Signposting Profile is a community specification aimed at 1500 improving machine navigation of scholarly objects on the web through 1501 the use of typed web links pointing at e.g. web resources that are 1502 part of a specific object, persistent identifiers for the object and 1503 its authors, license information pertaining to the object. The 1504 specification encourages the use of Linksets and initial 1505 implementations are ongoing, for example, for the open source 1506 Dataverse data repository platform that was initiated by Harvard 1507 University and is meanwhile used by research institutions, worldwide. 1509 B.3. Open Journal Systems (OJS) 1511 Open Journal Systems (OJS) is an open-source software for the 1512 management of peer-reviewed academic journals, and is created by the 1513 Public Knowledge Project (PKP), released under the GNU General Public 1514 License. Open Journal Systems (OJS) is a journal management and 1515 publishing system that has been developed by PKP through its 1516 federally funded efforts to expand and improve access to research. 1518 The OJS platform has implemented "linkset" support as an alternative 1519 way to provide links when there are more than a configured limit 1520 (they consider using about 10 as a good default, for testing purpose 1521 it is currently set to 8). 1523 Acknowledgements 1525 Thanks for comments and suggestions provided by Phil Archer, 1526 Dominique Guinard, Mark Nottingham, Julian Reschke, Rob Sanderson, 1527 Stian Soiland-Reyes, and Sarven Capadisli. 1529 Authors' Addresses 1530 Erik Wilde 1531 Axway 1533 Email: erik.wilde@dret.net 1534 URI: http://dret.net/netdret/ 1536 Herbert Van de Sompel 1537 Data Archiving and Networked Services 1539 Email: herbert.van.de.sompel@dans.knaw.nl 1540 URI: https://orcid.org/0000-0002-0715-6126