What version_id should a client use when requesting a tool version?

[fbacall]

the spec says /tools/{id}/versions/{version_id}

I assumed this version_id referred to the id field in the tool version JSON, but dockstore uses the name field for this:

https://dockstore.org/api/api/ga4gh/v2/tools/%23workflow%2Fgithub.com%2Fjmchilton%2Fgalaxy-workflow-dockstore-example-1%2Fmycoolworkflow/versions/master

┆Issue is synchronized with this Jira Story
┆containerName: GA4GH tool-registry-service
┆Issue Number: TRS-40

[coverbeck]

Hi @fbacall , I'm on the Dockstore team, but I joined after most of TRS was finalized, so the following is my opinion (and hopefully not wrong!). @denis-yuen, also on Dockstore, has been one of TRS drivers, can give a better explanation, but here's my take for now, until he gets back from vacation.

My reading of the spec is the ids can be whatever the TRS implementation wants them to be. Dockstore has chosen names for both the tool and version, because that makes it user friendly -- looking at a fully qualified entry id + version id, you can get a sense of what it is, whereas if your ids where just numbers it wouldn't be obvious.

In other words, as long as the version id is unique for that tool, it can be whatever you want.

[fbacall]

I see that Dockstore will also accept the Tool Version's ID:
https://dockstore.org/api/api/ga4gh/v2/tools/%23workflow%2Fgithub.com%2Fjmchilton%2Fgalaxy-workflow-dockstore-example-1%2Fmycoolworkflow/versions/#workflow/github.com/jmchilton/galaxy-workflow-dockstore-example-1/mycoolworkflow:master
👍

I guess a related question to this: is it expected that the url field for a ToolVersion contains the URL to access it via TRS? (i.e. should a TRS client GET this URL, or try and generate the URL using the /tools/{id}/versions/{version_id} pattern?)

I'm currently using it for the canonical URL of the tool version in the registry (an HTML landing page), but I notice Dockstore and BioContainers both have TRS URLs in this field.

[denis-yuen]

Looks like the canonical URL might be what we intended originally, ideally we would have both actually. That might have been an oversight. https://github.com/ga4gh/tool-registry-service-schemas/blob/develop/openapi/ga4gh-tool-discovery.yaml#L617

[uniqueg]

It would certainly be very useful if a version's url self reference would follow the /tools/{id}/versions/{version_id} pattern so that TRS URIs of the form trs://<server>/<id>/versions/<version_id> could be used by a client to pinpoint a specific version.

In fact we are just about to implement support for TRS URIs of that form to our TES implementation, so that it is able to download containers based on that. We are hijacking the tesTask.tesExecutor.image property to pass TRS URIs as our workflow engine (cwl-tes) does not seem to complain about them and passes them along just like they were image names/tags. Note that a TRS URI of just the form trs://<server>/<id> wouldn't be very helpful for this use case.

If you guys agree on this to be the intended/desired behavior, perhaps the description of TRS URIs should be amended to clarify this issue somewhat (without requiring immediate changes to the specs themselves).

[denis-yuen]

We could also add self-link headers or properties to the version somewhat similar to https://github.com/ga4gh/tool-registry-service-schemas/blob/develop/openapi/ga4gh-tool-discovery.yaml#L205

I'm ok with both

1. Alter url description to specify the TRS URL and add a new property for the canonical HTML landing page, perhaps landing_page
2. Leaving url as is and add a new property like self_link

Leaning toward 1. for backwards compatibility with Dockstore and biocontainers implementations.

Not entirely following the TRS URI discussion, but it seems reasonable.

[uniqueg]

Just meant a sort of versioned flavor of a TRS URI (in additional to the one described) that unambiguously describes a container image (or multiple equivalent images of different image types). Such an identifier could be used in workflows instead of an image name. WES or TES implementations could then resolve these via a TRS call, and, if available, choose their preferred container type flavor. We have implemented this now and tested it with Biocontainers. Works nice. Will probably open a separate issue on that though, likely after the demo next week.

[uniqueg]

Opened issue #164 for versioned TRS URIs