Should salmodule ontologies have a defined schema? #178

Currently there is no schema for salmodule ontologies. There is an ontology that defines the properties that should be in the jsonld but users can fundamentally add any property in any shape. This makes it tricky to validate the contents and provide explicit feedback for what the user needs to add for the file to be valid and where the file such changes belong. I am worried that if there are no constraints on things like the stdoutShape / taskShape developers will have confusion during development since json-ld is so flexible and has many directives that are not immediately intuitive.

Example, I want to add additional functionality for

1. initializing a new salmodule and populating it from an intuitive browser-based UI.
2. validating a salmodule ontology by using ubiquitous tooling that integrates with the IDE like jsonschema. This will provide specific feedback in which json blocks which properties are missing.

As such, I would suggest that we constrain at least parts of the ontology file to a specific schema to allow for this. This would allow me to give the user precise, explicit feedback on what to fix if something is wrong, and what to remove if it is unnecessarily added.

Two options:

1. Any unstructured or general triples that don't affect how to call the salmodule belong in the output of the salmodule itself. The entire ontology.jsonld can be validated according to a schema.
2. All nodes in the @graph of the ontology that are typed as a salmodule:Task have an explicit schema and expected structure. For other nodes, they are schemaless and the user can define them as desired.