Closed cmungall closed 3 years ago
Writing the python code to convert a TSV should be pretty straightforward. We can put code in a docker container if we want to run it as a service.
Another option would be using robot template. It depends on how much custom control we need. Robot
might not elegantly handle all our needs.
The link of the notebook does not seem valid anymore, I assume it is in the common-mixs-package-terms
folder of https://github.com/GenomicsStandardsConsortium/mixs-rdf/tree/master/src/notebooks.
@johanneswerner Yes. That is the notebook.
We are also working on a more general metadata converter for MIxS. See here:
https://github.com/microbiomedata/metadata_converter
And specifically in the Makefile around here: https://github.com/microbiomedata/metadata_converter/blob/5d5c52c9cda8d1023d977ce4b805a597e079a599/Makefile#L23
+1 for python and +1 for docker
On Tue, Feb 16, 2021 at 12:31 PM Bill Duncan notifications@github.com wrote:
@johanneswerner Yes. That is the notebook. We are also working on a more general metadata converter for MIxS. See here: https://github.com/microbiomedata/metadata_converter
And specifically in the Makefile around here: https://github.com/microbiomedata/metadata_converter/blob/5d5c52c9cda8d1023d977ce4b805a597e079a599/Makefile#L23
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
-- John Deck (541) 914-4739
Is there code to do this already with linkml?
Regardless of whether the nature of the rdf representation (#9) we will need a toolkit for doing conversion.
I would nominate python, and we can use @wdduncan's code as the starting point:
https://github.com/GenomicsStandardsConsortium/mixs-rdf/blob/master/notebooks/common-mixs-package-terms.ipynb
If we go with a native tsv representation (#10) I imagine we will retain something pretty similar to the existing column headings in the excel
The library would generate rdf (and possibly shex, as per comments in #9, also json-schema for the json-ld representation), we can play around with different representations. There are some decisions that can be made independent of properties vs classes, I suggest the following mappings:
I suggest URIs for each of the packages too (could use skos:scheme here)