Handle mean and median type_id specifications more efficiently? about schemas HOT 4 CLOSED

I don't feel like I know enough about JSON conventions to have strong feelings about this one way or another. I guess my strongest feeling about it all is that we should strive to make the tasks.json file that users have to write be as simple as possible, even if it means writing some additional custom code to check/add NAs that aren't present in the actual file. But this is not a strongly held conviction on this.

from schemas.

Under this proposal, is there a way for a hub to specify that a mean prediction is accepted, but not required? For example, with the current set up (which I agree is awkward):

• a hub that wants the mean to be required could specify this via:

          "output_types": {
            "mean": {
              "type_id": {
                "required": ["NA"],
                "optional": null
              },
              "value" : {
                "type": "integer",
                "minimum": 0
              }
            },
            ...
          }

• a hub that wants the mean to be optional could specify this via:

          "output_types": {
            "mean": {
              "type_id": {
                "required": null,
                "optional": ["NA"]
              },
              "value" : {
                "type": "integer",
                "minimum": 0
              }
            },
            ...
          }

I agree that this is both verbose and kind of confusing, so I'm potentially open to defining another way of setting this up -- but (a) I do think we need the ability to specify whether each output type is required or optional, and (b) although I'm not super happy with the current solution, it does at least have the merit of consistency with the other types...

from schemas.

Personally your suggestion @elray1 feels a bit inconsistent as we've been using required and optional to determine valid values of properties rather than the requirement of the property itself. Using "NA" and null to specify optional vs required also feels a bit confusing.

Perhaps using the json schema way of including a "required" property containing a vector of property names that are required might be cleaner?

Feels like this might need a bit of discussion at our next meeting?

from schemas.

Further discussion sounds good. I agree that currently, the primary/most obvious effect of required and optional is to specify valid values, and as an unclear byproduct, we also end up specifying whether the property as a whole is required (if it has at least one required value) or optional (if it does not have at least one required value). Separating those things would make it much clearer!

from schemas.