Change:
Clarifications regarding application/linkset In order to address URL, added wording (1) to clarify the distinction between application/linkset and application/link-format defined in RFC6690) and (2) to indicate that encoding of application/linkset is UTF-8. This includes addition of appropriate references. Value for internationalized target attributes must be unordered In order to address URL Changed the language to remove the suggestion that the JSON objects used in the array for inernationalized target attributes required ordering of members. A JSON object is defined as unordered collection of zero or more name/value pairs and as such suggesting ordering is inappropriate. Use example including 'anchor' with a fragment In order to address URL : Updated the application/linkset example with one link that has a URI with fragment as anchor. Added Implementation Status section Added a section about the FAIR Signposting Profile (see URL) community specification that promotes the use of Linkset.
looks good to me. thanks for the edits and feel free to merge, NAME
In the mail thread discussing the perceived overlap between application/linkset defined in the I-D and application/link-format defined in RFC6690, NAME suggests .
Proposal to address with
hi NAME I think we addressed this issue, so probably it can be closed.
I'll close this one. I invited you to be an admin on this repo so you can close the others ;)
Copied from URL; here's the comments: From NAME I think using one of the examples with an anchor including a fragment can diversify (at least visibly) what's possible - this is of course beside the definition of stating (or referring to RFC 8288) as to what an anchor value may be. So like the copyright example in URL which refers to a particular part of the document, the following example is about the correction section in the document made by an author: (or whatever example is more clear using #) From NAME sorry for leaving this open for so long. if you think this is somehow is essential, could you maybe explain why? otherwise we think that of course this can be done, but we're not quite sure why would have to point it out specifically. From NAME As said, using diverse examples can (indirectly) help the reader. It is an editorial call. From NAME i'll leave it up to NAME to add examples if he feels the need. if not, let's close this one. it is the last open issue! yay!
Proposal to address with
hi NAME NAME I think we addressed this issue, so probably it can be closed.
Copied from URL ; here's the comments. raised by NAME at URL In draft-wilde-linkset-07 , "Section 4.2.4.2. Internationalized Target Attributes" seems to indicate that the order of attributes of JSON objects representing the value of an internationalized target attribute is significant:
Proposal to address with
hi NAME NAME I think we addressed this issue, so probably it can be closed. In draft-wilde-linkset-07 , "Section 4.2.4.2. Internationalized Target Attributes" seems to indicate that the order of attributes of JSON objects representing the value of an internationalized target attribute is significant: The use of "first" and "second" here seems to imply that a value of this form does not conform to the specification: { "language": "de", "value": "nachstes Kapitel" } because the attributes are in the wrong order. Is it the intention that this be considered wrong? That might be problematic because some popular JSON handling mechanisms make it difficult or impossible for developers to control the order in which attributes are emitted. If the use of "first" and "second" here isn't meant to impose an ordering requirement, it might be worth considering rewording this. But if there is an ordering requirement, it might be good to make that clearer. Ian Griffiths URL
we looked at CoRE at the very beginning of the linkset work. CoRE does look similar (and it is), but we decided that the approach wasn't matching our needs. Perhaps some of that can make it into the draft. Sure, I'll start it next week.

Discussion:
This document format is identical to the payload of the HTTP "Link" header field as defined in Section 3 of RFC8288, more specifically by <del> its ABNF production rule for "Link" and subsequent ones. </del> <ins> its ABNF production rule for "Link" and subsequent ones.  Whereas the HTTP "Link" Header field depends on HTTP and hence on RFC0822 for its encoding, the format specified here is encoded as UTF-8 RFC3629. </ins> The assigned media type for this format is "application/linkset".

"application/linkset" documents will depend on which URI is used as context. <ins> It should be noted that the "application/linkset" format specified here is different than the "application/link-format" format specified in RFC6690 in that the former fully matches the payload of the HTTP "Link" header as defined in Section 3 of RFC8288, whereas the latter introduces constraints on that definition to meet requirements for Constrained RESTful Environments. </ins> 4.2. This document format uses JSON RFC8259 as the syntax to represent a

links. The value of the internationalized target attribute is an array <del> that contains one or more JSON objects.  The name of the first member of such JSON object is "value" and its value is the actual content (in its unescaped version) of the internationalized target </del> <ins> that contains one or more JSON objects.  The name of one member of such JSON object is "value" and its value is the actual content (in its unescaped version) of the internationalized target </ins> attribute, i.e. the value of the attribute from which the encoding <del> and language information are removed.  The name of the optional second member of such JSON object is "language" and its value is the language tag RFC5646 for the language in which the attribute content is conveyed. </del> <ins> and language information are removed.  The name of another, optional, member of such JSON object is "language" and its value is the language tag RFC5646 for the language in which the attribute content is conveyed. </ins> The following example illustrates how the "title*" target attribute defined by RFC8288 is represented in a link target object.

7.2. <ins> The FAIR Signposting Profile is a community specification aimed at improving machine navigation of scholarly objects on the web through the use of typed web links pointing at e.g.  web resources that are part of a specific object, persistent identifiers for the object and its authors, license information pertaining to the object.  The specification encourages the use of Linksets and initial implementations are ongoing, for example, for the open source Dataverse data repository platform that was initiated by Harvard University and is meanwhile used by research institutions, worldwide. 7.3. </ins> Open Journal Systems (OJS) is an open-source software for the management of peer-reviewed academic journals, and is created by the Public Knowledge Project (PKP), released under the GNU General Public