remove DerivedDataDescription class

[saskiad]

I don't think we need separate DerivedDataDescription class. The process field doesn't belong in the data description ... or is this used to automate the naming?

[dyf]

this class does two things:

1. automate naming
2. automate creating a derived data description based on a primary data description

if you want to get rid of the class I would vote to keep the utility methods

[saskiad]

If you poke around the database, you'll see the derived data description is one of the thing that is missing the most. People aren't using this.
I'm fine having it as a utility function, but I think it's confusing having it as a separate class

[saskiad]

I also just don't think the process_name belongs in the data description. So having this as a function where the process_name is a variable to the function used to create the name would be good, but adding a field that doesn't belong in the data description because we're using this class to create the name feels off to me.

[tmchartrand]

I agree on all counts here, moving this to utility functions will be less confusing in my view.

[dbirman]

Collapse into a single class

• related_data goes away
• input_data moves up to DataDescription becomes an Optional[], with a validator
• label -> tags List[str]
• UpgradeToDerivedDataDescription but less long becomes a utility function

[tmchartrand]

@dbirman sounds good, and also resolves #1045. I would just add the suggestion that the description should clarify the intent of the input/related data field is not to be comprehensive (that should be in the processing side) but to list a single or few primary inputs.