Open kmexter opened 1 month ago
This came up during an internal meeting concerning the new work on the kgap analysis by @cedricdcc.
Some early samples there shows data-value-labels of the measurements through linking to the actual P01 terms (and harvest those) -- this obviously shows the power of our Linked Open Data approach here, but it also disclosed that making the round-trip to the spreadsheets not that easy --> feedback to the maintainers of this logsheets should be able to refer also to the actual column-name used -- so either through the template, or through the own emobon vocab triples we could be exposing that local emobon-logsheet-column-identifier ? (to consider how to catch that nicely in triples)
Another element of needed clarity was about the units of the measurements. Apparently these are now derived from the P01 markers -- but those only have "recommended units" relating them to P06. The triples we produce in emo-bon should provide some explicit mentioning of the "actual units" (P06) we are using. Maybe that is already there?
the units are specifically given in the logsheet_schema_extended file and I believe Laurian took those into the ontology but they are not specifically in the ttl files from the logsheets (I have raised an issue on this already)
take up with @marc-portier
need to generate provenance triples (in combination with data triples) within template to capture which actual column was used to produce which triples
note: this also ties in with more generic provenance that the subyt process should be proving: time, version, parameters of execution; location of input files and possibly crates; additionally subyt execution will probably need to inject provenance related identifiers into the ctrl variable
@marc-portier will fill in the details here, but he is requesting that the logsheet_schema_extended is tripleised (and perhaps I need to tidy it up first?)