Terry-Weymouth
commented
6 years ago Brian, reviewing this at a future meeting (maybe between you and Glenn) might be a good idea.
Open Terry-Weymouth opened 7 years ago
Terry-Weymouth
commented
6 years ago Brian, reviewing this at a future meeting (maybe between you and Glenn) might be a good idea.
From Brian: 1)For
experiment.deleteWorkflow(), what is being deleted?What specifically is a 'workflow'? Is it everything in an Experiment? Or a connected subgraph? Or just downstream dependencies of anything? Or something else? I'm hesitant to use this term in the mcapi unless we have a precise definition that will be consistent across Materials Commons, which I don't think we have yet. Maybe I'm wrong and you and Glenn have a particular definition I'm not aware of.
"Delete all downstream" would be a pretty generally useful feature.
2) More broadly, there are a number of ways we could group parts of the graph, and it would be useful to list a few of these, name, and define them within Materials Commons so that people can more easily select parts of the graph. This would be useful as we think about "views" and interacting with the visualization tools also. Perhaps to do this we should familiarize ourselves with graph theory terminology. I believe our workflows can described as "directed acyclic graphs", though I'm not sure if we strictly enforce this. I'm not familiar with whether there are particular names for "everything upstream (downstream) from a particular node/edge", etc. but if there are, it would be good to at least not misuse terms.
3) I think you can always add more things to a Process (i.e. create more samples, setup properties, and measurments, link more files)? Is that right? What about delete a single setup property or measurement? Can you unlink a file? We can get by without this in the short term, but is this on the todo list?
4) Not allowing deletion of interior nodes/edges makes sense, but maybe we need a way to mark a "bad" process / sample / property / measurement? Something that could inform downstream analysis that something might be wrong? This could be because you want to keep a record of the "wrong" thing instead of deleting it, but it could also be because there are objects that depend on it that you can't delete because you don't have permission to modify, for instance with sharing across projects.