resolve confusing state of Processing schema

[tmchartrand]

We attempted to improve Processing in 2.0, but it has become clear there are many inconsistencies in the current usage that still need to be resolved, likely requiring breaking changes in 3.0:

• can a helper method for creating a derived asset from an existing record make sure that input_data references in processing correctly refer to that record?
• should asset references use s3 paths, asset names, or both?
• how do we distinguish references to assets that are intermediate results in a computation graph (and inputs to later steps) from those that are separate inputs to those later steps?
• how should we distinguish on-rig or other processing that occurs prior to the "raw" asset from processing that creates a "derived" asset? (and is it necessary to record a "copy data" process from aind_data_transfer?)
• how should we distinguish processing that updates the metadata only (version upgrades)?
• do we want to keep the process dependency graph but make it easier to create, instead simplify accessing that information elsewhere (CO API or nextflow files), or accept that input/output information will be incomplete for more complex process workflows?

[tmchartrand]

ideally, this will also make it possible to remove DataDescription.source_data which is currently conceptually redundant but required for practical reasons.

[saskiad]

A few thoughts:
For on-rig, these should be annotated in the processing.json of the primary data asset. The process_type and the output_path should probably make it clear what they are. I don't know that they need to be otherwise distinguished from subsequent processing of the primary asset to create the derived asset.
Processing that only updates the metadata does not need to be annotated in the processing json. The metadata describes the data asset.

[saskiad]

@dbirman you moved this to the backlog - are you taking it on? or should we triage it on monday?

[dbirman]

I think we did triage it and agreed to just push off deciding who to assign it until we get closer to V3 and discuss how it would be implemented.