Closed ehwenk closed 1 year ago
The following studies currently have much of their methods moved to method contexts for traits that have 2 entries, to avoid duplication:
@ehwenk has this been addressed now?
This is still an issue that needs to be solved and is the trickiest of the issues I know of, because it requires method context
to be more separated from other contexts. The current fix is not really satisfactory - not least, because it would be easy to input two traits with different methods and not realise why rows of data are being duplicated when you merge in the methods table.
Moving issue to traits.build.
Currently, there are instances where the same trait is measured in the same dataset using multiple methods. These instances all have a
method_context
assigned that indicates the differences between the two methods. However, thismethod_context
is captured only inaustraits$methods
(all information) andaustraits$traits
(method_id), which means there are still 2 entries for a given trait_name x dataset_id combination inaustraits$methods
with no indication of which row goes with which measurements. As a result, the actual trait measurements for those trait_name x dataset_id combinations are being duplicated, with each measurement assigned all methods.For now we are going to standardise the methods entered and move more information to method context. This solves the duplication, but isn't a good long term fix.
A better solution is to separate
method_context
from the other contextual properties, since method context is a specialisation of method, not a context of an observation. Method context would be better mapped through the method's table, but this is a much bigger fix.Below is code, not quite finished, that adds method_id's to the methods table, although only for those method contexts that are generated in
metadata[["traits"]]
. It is clunky, but a possible direction to expand upon.