DACCS-Climate / Marble-node-registry

The central node registry of the DACCS network
0 stars 1 forks source link

Proposal of additional links for registered nodes #10

Closed fmigneault closed 1 year ago

fmigneault commented 1 year ago

As mentioned in

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 commented 1 year ago

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

We should still support the following keys:

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

mishaschwartz commented 1 year ago

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 commented 1 year ago

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.