Create a process for standardising ontologies

[benjamingeer]

We will have two categories of ontologies:

• Project-specific ontologies, which the project admins may change. So we should try to prevent other projects from using them, to avoid data consistency problems. (E.g. if you try to change a cardinality that someone else is using, GraphDB won't allow you to do so.)
• Standardised ontologies, which are available for reuse and will not be changed.

We need a process for standardising ontologies. This would involve a public forum where proposals could be posted and discussed. We could create a GitHub project for this.

Ideally, before an ontology can be standardised, it should be discussed and agreed by at least two projects that want to use it. Those projects need not put everything they require into the standard, but only the requirements they have in common. Other features can be added by subclassing in project-specific ontologies.

The IRI of a standardised ontology will contain something indicating that it has been standardised, as well as a version number (as many ontologies do, like http://xmlns.com/foaf/0.1/). So if a new version is made, all the entities in the new version will have different IRIs. Anyone who wants to migrate their data to the new version will have to do so deliberately.

So when you create a new resource, and the GUI asks the API server what classes are available, the response will contain only the standardised classes and the classes in your project.

Sub-Issues

• Allow shared ontologies #986

[SepidehAlassi]

@danielasubotic & @subotic I believe this is relevant to the metadata ontology. We have actually many resource classes and properties that are repeatedly defined in various project ontologies and also in the metadata ontology. Maybe it is now time to actually consider standardizing the ontologies.