Current registry model requires custom wrapper functions around existing APIs in Software Heritage, DataONE, and Zenodo to parse metadata and identify checksum and download URL parts.
In general, object ids, checksums, and downloadURLs may be made accessible following appropriate metadata standards, like schema.org (available from DataONE, Zenodo, and other repositories, though often without checksums)
For instance, schema.org markup for a download URL might be expressed with this information as follows:
{
"type": "DataDownload",
"id": "hash://sha256/8be0e572cde7ae0c5eb00d3c6e07c0a56c9fec05d947282f45b2f37bd58ddb0b",
"contentSize": 136824,
"contentUrl": "https://github.com/cboettig/rfishbase_board/raw/main/fb_parquet_2023-01/abundance.parquet",
"encodingFormat": "application/vnd.apache.parquet",
"identifier": [
"hash://sha256/8be0e572cde7ae0c5eb00d3c6e07c0a56c9fec05d947282f45b2f37bd58ddb0b",
"hash://md5/7660babc0b4d95261f6054f55de696f9"
],
"name": "abundance.parquet"
}
It might be nice to allow contentid to operate against Schema.org metadata as a registry. While this is related to long-standing questions of metadata standards for contentid here (#1, #5), notably this is not about establishing a preferred internal standard for contentid, but rather just adding another extension which operates against a metadata standard rather than a current service endpoint.
Functionally, this would work very much like the local tsv registry, with a sources_schema() that could parse schema.org JSON-LD to detect hash identifiers and corresponding contentUrl values. Optionally, this could include a register_schema() able to serialize a URL as a @graph of DataDownload entries (like above), though users would be better served to use create more metadata rich schema.json with a tool like prov.
Current registry model requires custom wrapper functions around existing APIs in Software Heritage, DataONE, and Zenodo to parse metadata and identify checksum and download URL parts.
In general, object ids, checksums, and downloadURLs may be made accessible following appropriate metadata standards, like schema.org (available from DataONE, Zenodo, and other repositories, though often without checksums)
For instance, schema.org markup for a download URL might be expressed with this information as follows:
It might be nice to allow contentid to operate against Schema.org metadata as a registry. While this is related to long-standing questions of metadata standards for contentid here (#1, #5), notably this is not about establishing a preferred internal standard for contentid, but rather just adding another extension which operates against a metadata standard rather than a current service endpoint.
Functionally, this would work very much like the local tsv registry, with a
sources_schema()that could parse schema.org JSON-LD to detect hash identifiers and corresponding contentUrl values. Optionally, this could include aregister_schema()able to serialize a URL as a@graphof DataDownload entries (like above), though users would be better served to use create more metadata rich schema.json with a tool like prov.