Small comment round up

README.md

@@ -1,51 +1,50 @@
 ![ga4gh logo](https://raw.githubusercontent.com/dockstore/dockstore-ui2/2.7.4/images/high-res/ga4gh.png)
 
-[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.3374001.svg)](https://doi.org/10.5281/zenodo.3374001)
+[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.7079592.svg)](https://doi.org/10.5281/zenodo.7079592)
 
 
 Schemas for the GA4GH Tool Registry API
 =======================================
 
-This repository is the home for the schema for the GA4GH Tool Registry API.  The goal of the API is to provide a standardized way to describe the availability of tools and workflows.  In this way, we can have multiple repositories that share Docker-based tools and WDL/CWL/Nextflow/Galaxy/Snakemake-based workflows and have a consistent way to interact, search, and retrieve information from these various registries.  The end goal is to make it much easier to share scientific tools and workflows, enhancing our ability to make research reproducible, sharable, and transparent.
+This repository is the home for the schema for the GA4GH Tool Registry API.  The goal of the API is to provide a standardized way to describe the availability of tools and workflows.  In this way, we can have multiple repositories that share containerized (or alternative containerized) tools and WDL/CWL/Nextflow/Galaxy/Snakemake-based workflows and have a consistent way to interact, search, and retrieve information from these various registries.  The end goal is to make it much easier to share scientific tools and workflows, enhancing our ability to make research reproducible, sharable, and transparent.
 
 **See the human-readable [Reference Documentation](https://ga4gh.github.io/tool-registry-service-schemas). You can also explore the specification in the [Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/ga4gh/tool-registry-schemas/develop/openapi/openapi.yaml).**  *Manually load the JSON if working from a non-develop branch version.* Preview documentation from the [gh-openapi-docs](https://github.com/ga4gh/gh-openapi-docs) for the development branch [here](https://ga4gh.github.io/tool-registry-service-schemas/preview/develop/docs/index.html)
 
 The [Global Alliance for Genomics and Health](http://genomicsandhealth.org/) (GA4GH) is an international
 coalition, formed to enable the sharing of genomic and clinical data.
 
-The GA4GH [Data Working Group](http://ga4gh.org/#/) concentrates on data representation, storage,
-and analysis, including working with platform development partners and
-industry leaders to develop standards that will facilitate
-interoperability.
-
-Containers and Workflows Task Team
+Cloud Work Stream
 ----------------------------------
 
-The Containers & Workflows working group is an informal, multi-vendor working group born out of the BOSC 2014 codefest, consisting of various organizations and individuals that have an interest in portability of data analysis workflows. Our goal is to create specifications that enable data scientists to describe analysis tools and workflows that are powerful, easy to use, portable, and support reproducibility for a variety of problem areas including data-intensive science like bioinformatics, physics, and astronomy; and business analytics such as log analysis, data mining, and ETL.
+The Cloud Work Stream is focused on creating specific standards for defining, sharing, and executing portable workflows and accessing data across clouds.
+We work with many different Driver Projects to develop, enhance, test, and use the Cloud Work Stream APIs.
 
 What is the Tool Registry API Schema?
 -------------------------------------
 
-This is the home of the schema for the GA4GH Tool Registry API. The GA4GH Tool Registry API is a standard for listing and describing available tools (both stand-alone, Docker-based tools as well as workflows in CWL, WDL, Nextflow, Galaxy or Snakemake) in a given registry. This defines a minimal, common API describing tools that we propose for support by multiple tool/workflow registries like [Dockstore](https://www.dockstore.org/), [BioContainers](https://biocontainers.pro), and [Agora](https://github.com/broadinstitute/agora) for the purposes of exchange, indexing, and searching.
+This is the home of the schema for the GA4GH Tool Registry API. The GA4GH Tool Registry API is a standard for listing and describing available tools (both stand-alone, containerized tools as well as workflows in CWL, WDL, Nextflow, Galaxy or Snakemake) in a given registry. This defines a minimal, common API describing tools that we propose for support by multiple tool/workflow registries like [Dockstore](https://www.dockstore.org/), [BioContainers](https://biocontainers.pro), and [Agora](https://github.com/broadinstitute/agora) for the purposes of exchange, indexing, and searching.
 
 This repo uses the [HubFlow](https://datasift.github.io/gitflow/) scheme which is closely based on [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/). In practice, this means that the master branch contains the last production release of the schema whereas the develop branch contains the latest development changes which will end up in the next production release. 
-As of July 2019, this means that the 1.0.0 version is described on master whereas the develop branch contains the 2.0.0-beta.3 version which will evolve into the 2.0.0 production release.
+As of February 2022, this means that the 2.0.1 version is described on master whereas the develop branch contains work which will accumulate and evolve into a 2.1 production release.
 
-Our current proposal is to start with a read-only API due to potentially different views and approaches to registration/security.
+Our current iteration focuses on a read-only API due to potentially different views and approaches to registration/security.
 
-Key features of the current API proposal:
+Key features of the current API:
 
 * read-only API
-* May serve up CWL, WDL, Nextflow, Galaxy or Snakemake to describe a tool or represent a workflow 
-  depending on the tool/workflow submitter
-* ID:  globally unique across systems and also identifies the system that it came from (ex: 123456323@agora.broadinstitute.org )
-
+* Serve up one or more of CWL, WDL, Nextflow, Galaxy or Snakemake to describe a tool or represent a workflow depending on the tool/workflow submitter 
+* Download individual workflow files or the entire workflow as a zip
+* Interrogate the language versions of these workflows
+* Get specific versions of workflows and tools, potentially with immutable versions with checksums on their files
+* ID: globally unique across systems and also identifies the system that it came from (ex: 123456323@agora.broadinstitute.org )
+* Refer to our [data model](https://ga4gh.github.io/tool-registry-service-schemas/DataModel/) for information on how to define TRS URIs if desired
+* provides more structure than a simple un-formatted list of tools but it is also a standard for registries to implement as opposed to a registry implementation itself
 
 Outstanding questions:
 
 * How do we track authorship? Should we track authorship of the tool metadata, the Docker image, or the underlying algorithm, or all of above?
-* How to describe indexing and external services like an external [sparql](https://github.com/common-workflow-language/workflows#sparql) service.
-* Terminology discussion (do we describe triples separately from tools? should we describe them as aggregations of tools for just the case that documents have more than one tool? etc.)
+* How to describe indexing and external services like an external [sparql](https://github.com/common-workflow-language/workflows#sparql) service
+* How to better co-ordinate with WES, TES
 
 
 How to view
@@ -59,7 +58,7 @@ How to contribute changes
 
 Take cues for now from the [CONTRIBUTING.md](https://github.com/ga4gh/tool-registry-service-schemas/blob/develop/CONTRIBUTING.md) document.
 
-At the very least, create an issue in our [Github tracker](https://github.com/ga4gh/tool-registry-schemas/issues).
+At the very least, create an issue in our [GitHub tracker](https://github.com/ga4gh/tool-registry-schemas/issues).
 
 Even better, fork the codebase, fix the issue, and create a pull request back to the project along with your ticket.
 
@@ -86,7 +85,10 @@ See the [LICENSE](LICENSE)
 For more information
 --------------------
 
-* http://genomicsandhealth.org/
-* [LICENSE](LICENSE)
-* [Google Groups - old](https://groups.google.com/forum/#!forum/ga4gh-dwg-containers-workflows)
-* [Google Groups - new](https://groups.google.com/a/genomicsandhealth.org/forum/#!forum/ga4gh-dwg-containers-workflows)
+* [GA4GH Cloud Work Stream](https://github.com/ga4gh/wiki/wiki) - the wiki and meeting notes for the workstream
+* APIs that we co-ordinate/meet with
+  * [DRS](https://github.com/ga4gh/wiki/wiki/Data-Repository-Service)
+  * [TES](https://github.com/ga4gh/wiki/wiki/Task-Execution-Service)
+  * [WES](https://github.com/ga4gh/wiki/wiki/Workflow-Execution-Service)
+* [Global Alliance for Genomics and Health](https://www.ga4gh.org/) - GA4GH's main page
+* [GA4GH Technical Alignment Sub Committee (TASC)](https://github.com/ga4gh/TASC) - we try to co-ordinate GA4GH API decisions here

openapi/README.md

@@ -4,4 +4,4 @@ To make changes to the TRS, join the GA4GH organization or ask to join this repo
  - The openapi.yaml file with an OpenAPI 3 definition of the changes.
    - This openapi yaml file will be used in the TRS validation server.
 
-The v1 directory should not be modified. It provides backward compatibility support for TRS servers/clients.
+The v1 and v2 directories should not be modified. They provide a historical record and potentially backward compatibility support for TRS servers/clients.

openapi/openapi.yaml

@@ -13,13 +13,13 @@ info:
     described above. In practice, examples of "tools" include CWL
     CommandLineTools, CWL Workflows, WDL workflows, and Nextflow workflows that
     reference containers in formats such as Docker or Singularity.
-  version: 2.0.1
+  version: 2.1.0
 tags:
   - name: GA4GH
     description: A group of web resources proposed as a common standard for tool
       repositories
     externalDocs:
-      url: https://ga4gh.github.io/tool-registry-service-schemas/Introduction/
+      url: https://ga4gh.github.io/tool-registry-service-schemas/
 paths:
   /service-info:
     $ref: https://raw.githubusercontent.com/ga4gh-discovery/ga4gh-service-info/v1.0.0/service-info.yaml#/paths/~1service-info
@@ -40,9 +40,6 @@ paths:
             application/json:
               schema:
                 $ref: "#/components/schemas/Tool"
-            text/plain:
-              schema:
-                type: string
         "404":
           description: The tool can not be found.
           content:
@@ -131,6 +128,15 @@ paths:
           description: Filter tools by the name of the descriptor type
           schema:
             $ref: '#/components/schemas/DescriptorType'
+        - name: tags
+          in: query
+          description: Filter tools by registry specific tags
+          schema:
+            type: array
+            items:
+              type: string
+            minItems: 1
+          explode: false
         - name: registry
           in: query
           description: The image registry that contains the image.
@@ -632,7 +638,7 @@ components:
         descriptor_type_version:
           type: object
           description: A map providing information about the language versions used in this tool. The keys should be the
-            same values used in the `descriptor_type` field, and the value should be an array of all the language versions used 
+            same values used in the `descriptor_type` field, and the value should be an array of all the language versions used
             for the given `descriptor_type`. Depending on the `descriptor_type` (e.g. CWL) multiple version values may be used
             in a single tool.
           example: |
@@ -650,6 +656,9 @@ components:
           description: Reports if this tool has a containerfile available. (For
             Docker-based tools, this would indicate the presence of a
             Dockerfile)
+        description:
+          type: string
+          description: The description of the tool version. This allows for documentation of a specific tool version as a tool evolves over time.
         meta_version:
           type: string
           description: The version of this tool version in the registry. Iterates when
@@ -729,7 +738,7 @@ components:
         - WDL
         - NFL
         - GALAXY
-        - SMK        
+        - SMK
     DescriptorTypeVersion:
       type: string
       description: The language version for a given descriptor type. The version should correspond

scripts/update-ghpages.sh

@@ -4,7 +4,7 @@ set -o pipefail
 set -o nounset
 set -o xtrace
 set -u
-BRANCH=$(echo "${GITHUB_REF##*/}" | awk '{print tolower($0)}')
+BRANCH=$(echo "${GITHUB_REF#refs/heads/}" | awk '{print tolower($0)}')
 BRANCH_PATH="preview/$BRANCH"
 mv preview preview2
 git config --replace-all remote.origin.fetch +refs/heads/*:refs/remotes/origin/*