Discussion about ESAP/OSSR metadata
- the distinction between software and analysis is important. however, user don't always make that distinction and often provide a mix of both. ESAP metadata tries to solve that issue.
- Data location issue. In the future there might be several instances of the data lake. In that case, you might not want to retrieve data from across the world but rather use an analysis platform close to it. The issue of data location is left for the future.
- OSSR metadata and ESAP metadata requirements are very different (as they try to solve different issues). Having them in the same schema / format might not be the best approach then.
- metadata search: ESAP metadata won't be searchable in the OSSR, as the metadata is not part of the Zenodo schema.
- is such a wide search necessary? Are users really going to search for "all software runnable with #TB space or # CPUs"?
- another solution is for ESAP to build a database on its side by harvesting records and loading its specific metadata when available
OSSR metadata schema and resources
OSSR metadata doc:
- https://escape2020.pages.in2p3.fr/wp3/eossr/metadata.html
- https://escape2020.pages.in2p3.fr/wp3/eossr/metadata/ossr_metadata.html
Useful resources: https://escape2020.pages.in2p3.fr/wp3/eossr/resources.html
How the schema.org extension works:
https://schema.org/docs/extension.html
Examples:
- codemeta is an extension of schema.org: https://github.com/codemeta/codemeta/blob/master/codemeta.jsonld
- another example with many contexts: https://www.gs1.org/docs/gs1-smartsearch/gs1Voc_v1_5_1.jsonld
--> does it make sense to build ESAP metadata as a schema.org extension that could live in the same file as OSSR codemeta.json?
--> what advantages and drawbacks that might bring?
