Add geolocation information to implementations catalogued in the service registry

[jppay]

Problem Statement
Implementation registry service is used for cataloguing implementations of GA4GH standards. Most of the implementations that can be included in the service registry are web-based API standards. The current specification for the registry doesn't expect implementation submission to include geolocation information. With the recent rise in implementations of GA4GH standards, geolocation would be useful information to help understand the geographies where GA4GH standards are being actively implemented. This would help drive GA4GH objectives and decisions to explore ways of increasing the outreach and adoption of standards in nascent geographies.

Alignment between GA4GH standards
As the registry serves as the catalogue for all web-based API implementations, it can foster collaboration between Work Streams and align with the wider GA4GH objectives such as implementation support and interoperability. This data would also help understand the uptake of standards and any blockers in implementation of any GA4GH standards.

Background research and landscape analysis
Current specification of service registry doesn't support this data being captured. This gap makes it difficult to understand the adoption map of the standards across the globe. This also blocks providing timely support to institutions who are looking to implement standards in their infrastructure. The implementations currently documented in the registry would need retrospective updates which would be requested from the owners or contacts of the implementations. This would also have the additional benefit of helping flag redundant implementations, and refreshing the list of active implementations in the registry.

Proposed solution
The solution being proposed is that all the implementations to be catalogued into the service registry should share geolocation information. It would be a mandatory parameter and modelled similar based on and compatible with GeoJson (https://geojson.org).

[mbaudis]

@jppay Excellent! Minor change request:

modelled similar GeoJson

... might better be "based on and compatible with GeoJSON" to avoid confusion (not creating a fork).

Also: You should directly reference ga4gh-discovery/ga4gh-service-info#74 and/or https://schemablocks.org/schema_pages/Progenetix/GeoLocation/ since the format has been done (pending review for adding it here but in principle done).

[jmarshall]

It is unclear why this has been raised here rather than in the ga4gh/ga4gh-registry repository, which is the repository for the implementation registry service that you are presumably referring to.

Adding geolocation information to the service-info response would be done in the service-info specification, which AIUI is maintained by the discovery work stream (though there have been no merged updates in over four years). Indeed, issue ga4gh-discovery/ga4gh-service-info#73 and PR ga4gh-discovery/ga4gh-service-info#74 discuss and propose adding optional geolocation information to the service-info response.

[mbaudis]

@jmarshall I understood this as a prototype issue for TASC driven cross-project/WS standards. The GeoLocation format had been documented a long time ago (and goes back to DWG MTT¹ discussions); and more recently being invoked (by me) in the issue/PR you've linked as well as in a presentation about its use in a Beacon scenario (by Victor Rochelau, based on the SchemaBlocks version / progenetix.org).

So: Tackle this as a general schema and take it from here (I'll push then for Beacon schemas, too, though on the service level the GeoLocation will then move in through service-info in - hopefully - any case).

Footnotes

1. Data Working Group Metadata Task Team ↩

[jppay]

As discussed and agreed in the TASC workshop at Hinxton, @mbaudis and @briandoconnor would be the Product Owners (PO) for this issue. It was also agreed to evaluate the work done on similar requirements and available at https://schemablocks.org/schema_pages/Progenetix/GeoLocation/. More information would be added after reviewing the meeting notes.