Closed MichaelLukowski closed 1 year ago
Sorry if I missed earlier discussion of this PR, but I'm not following the intended use of this new method, or how it would address the stated goals fetching requestor-pays content or supporting complex objects. Is there more background somewhere? (I did look at #343 and didn't see answers there.) I'll reserve most comments until I hear back, but in general I think providing a method that returns arbitrary unspecified metadata creates a big risk of breaking interoperability.
Referring back to this hackathon exploration and the DRS issue that generated it.
It may be a separate use case - all depends on exactly what metadata are intended in each situation. The hackathon was following an approach that aligns with "bundling alternatives" described in PR 389. Both 336 and 389 rely on higher level schemas that provide the metadata.
Despite the ambiguity, the motivation of this issue and 389 seems to be the same. So am also waiting on what @dglazer asked.
Commenting on
arbitrary unspecified metadata creates a big risk of breaking interoperability.
Yes, a shared concern. A key characteristic of the protocols (e.g. Data Connect) that provide the higher level schemas is that allow for, and encourage, for those metadata to be well specified.
@MichaelLukowski just wanted to check in with you on this PR
To keep this on track for Connect in April 2023 can you confirm the following:
Champion → @MichaelLukowski Deadline for revisions: 2 weeks from last DRS call (2/6) Deadline for comments: 2/20 Merge date: CANCELED (target 3/13 at latest)
@MichaelLukowski suggested this might be closed and replaced with GA4GH Connect... since it already provides the ability to specify a metadata definition.
@ianfore has an example that we can point to... from FASP work. Ian can you drop links here?
Examples from @ianfore Examples: DRS and metadata exploration https://github.com/ga4gh/fasp-scripts/blob/master/notebooks/drs/altMetadata.ipynb https://github.com/ga4gh/fasp-scripts/tree/master/notebooks/drs
This is a PR for introducing a new metadata endpoint that supports an arbitrary JSON response at a new
/metadata/{object_id}
endpoint.There is a need for requestor pays and egress for additional metadata of DRS objects that shouldn't be included in the
/object
endpoint.This will also be useful for a best practice of "complex objects" where one DRS id can point to a json file that describes many DRS objects.