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