Proposal of additional links for registered nodes

[fmigneault]

As mentioned in

• https://github.com/DACCS-Climate/DACCS-node-registry/pull/9#discussion_r1224581547
• https://github.com/DACCS-Climate/DACCS-node-registry/pull/9#issuecomment-1584890587

On top of links under each service of each node, the node themselves could have a links section that provides useful metadata references. A few typical items from https://www.iana.org/assignments/link-relations/link-relations.xhtml to consider:

rel	Meaning
about	URL to a summary or purpose of the node
author	URL to the maintainer/institution of the node
acl	Endpoint to Access Control List such as the /magpie endpoint or another access management method
collection	URL to the /services endpoint of the node
cite-as publication	Attribution by researchers to reference the node when using it for publications
copyright license terms-of-service	Legal use of the node
describedby	URL to full documentation and details of the node, its purpose and so on
edit	A self-reference to https://github.com/DACCS-Climate/DACCS-node-registry or anywhere that the specific node registry entry to redirect users where to update it
icon	Logo of the institution of specific node
status	URL to a monitoring service endpoint, such as /canarie or another alternative
version-history	link to https://github.com/bird-house/birdhouse-deploy/blob/master/CHANGES.md or similar

All of those links can be optional, except maybe collection that should be expected for the node-registry itself to know where to redirect for the service-listing of an instance. Providing an example with as many references as possible would guide users into a strongly recommended set of definitions.

[mishaschwartz]

I'm in favor of this change. Doing so would remove:

• the "icon_url" key (replaced by icon)

We should still support the following keys:

• affiliation
• description
• location
• contact

So that we can rely on this static data that can be displayed even if the node is down.

[mishaschwartz]

All of those links can be optional, except maybe collection that should be expected for the node-registry itself to know where to redirect for the service-listing of an instance.

If we're going to refer to the services endpoint here and make is required, why not also do the same for the version endpoint and maybe even the landing page for the node.

@fmigneault do you have any suggestions for what the best "rel" value would be for the version endpoint and the node's landing page?

@dchandan what do you think about that?

[fmigneault]

The best "official" one would be latest-version. You could also use just version.

In the context of the node-registry, the remote landing page of the node should probably use service. It could also report it using current, but I think I prefer service personally, since it aligns with service-desc, service-doc and service-meta that can be used for human/machine-readable references. The service-desc could also refer to /components now that they are available.