break out NIDM OWL files to separate repo

[dbkeator]

Discussed putting NIDM-related OWL files in separate repo to be used by APIs as sub-modules...

@satra @khelm @cmaumet

[khelm]

Hi @dbkeator - that's fine with me as I could see how that would make them more portable. We should discuss:

1. do we make just a single NIDM ontology?
2. does the splitting have an affect on the integrity testing?
3. what about the import files?

[cmaumet]

@dbkeator: can you give us more info on the use cases? Is this for import of the owl files in pyNIDM? Do you have other usecases in mind?

I think having the owl files in separate repos would make discussions/contributions on the data models much easier. But my experience with git sub-modules is not great... Also, having separate repos means that it will be more difficult to deal with updates that are common to all components (e.g. updating the website when one of the owl file is changed, creating the master NIDM owl file, etc.).

I think we should carefully think about the pros and cons and how we will need to update our processes in place.

[satra]

@cmaumet and @dbkeator - yes the intend is to use git submodules so that we can simply import a specific version of the project in any underlying library whether python or javascript or something else.

i would keep the repo very simple. versioning would happen through releases on github, which means any specific state of the repo can be incorporated. any change in any individual file should update via a PR the nidm.owl aggregate file.

-- nidm.owl
-- nidm-experiment.owl
-- nidm-workflows.owl
-- nidm-results.owl
-- nidm-dicom.owl
-- nidm-....owl

regarding @khelm questions:

do we make just a single NIDM ontology?

we will aggregate into one.

does the splitting have an affect on the integrity testing?

it should not, since this repo itself can either have the tests or can be imported into a repo with the tests. the main idea is to have a lightweight module.

what about the import files?

imports from other ontologies would stay as per normal. we need to decide whether imports would be flattened into a nidm.owl file (my preference for the flat nidm) or not.