Present:
- Kay
- Jutta
- Mark
- Enrique
- Thomas
- Tamas
- Gareth
# OSSR-ESAP interface and metadata
The discussion led to clarify what should be in the OSSR metadata and what should be left to ESAP:
- OSSR metadata should be very generic and not implementation specific
- ESAP metadata is platform specific and will take time to be implemented + will evolve through time
# Keywords
- Be careful to not avoid overlap with existing vocabulary if we use a keyword for OSSR classification
- However, the recommended keywords should stay generic enough to still have meaning in xx years
- the keyword `jupyter-notebook` for example does not mean that it is runnable by a specific service (that would require specifying versions and environments) but simply that it contains a jupyter notebook
- no specific keyword is required - they are overall recommended
- Issue #68 got closed
- Issue #75: we will include the Astronomy Thesaurus in the recommendation for keywords
- We stay open to suggestions for other widely used thesaurus for other communities (particle physics in particular)
# Building instruction / environment
- We want to mention clearly that an environment must be provided in the policy
- the build instruction should link to an internal document in codemeta (good practice)
- the documentation URL is required but we can't require the human-readable documentation itself to be included in the record (this documentation is often automatically built)