Change:
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

Discussion:
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.