Publishing ePO releases on Github

# Publishing ePO releases on Github

We have created two different repositories, [ePO](https://github.com/OP-TED/ePO) and [epo-conceptual-model](https://github.com/OP-TED/epo-conceptual-model).

## ePO

Used to publish and review the Semantic data specification + Conceptual model. It also contain links to any reference material and keeps track of the issues

This repository does now know how this data-specification was generated, it's meant to publish and to do reviews.

All reviews are done by people who approve or not the specification.

## epo-conceptual-model

Used to maintain the conceptual model, currently used to contain the mechanism that produces the Semantic data specification.

### Why did we create two repositories?

One could argue now we have the conceptual model in two places. The rationale was we had problems with Git branching the Enterprise Architect binaries, also versioning and reviewing auto-generated files is cumbersome. We had a situation of several branches with `ahead` and `behind` counts.

We want to maintain the Conceptual model in ePO but not maintain changes in the binaries and several auto-generated artifacts. Perhaps this might change in the future.

> Initial argument Ioannis
> - We want to avoid versioning any artefacts that *are derived from others* in the same repository.
> - Source code (ePO_CM.eap) in one repository, generated artifacts in other (ontology.rdf)

We also want to maintain only the essential artefacts of the Semantic Data specification, we opt to maintain only the files related to the Ontology and leave oyt the files that support the modelling effort, such as convention reports and the model2owl configuration files.

## Ontology reviews

### Release Candidate

A release candidate is built so it can be inspected by the community. Currently it's pulled into the branch `develop`

The following aspects are to be reviewed:

- Github tickets
	- Relevant tickets are linked to the pull request. Later on the tickets are presented in the release notes.
- Semantic data specification
	- Correctness of the artefacts produced
	- Completeness of the artefacts produced
	- Metadata of the artefacts produced
- Timestamp
	- Glossary
	- Conceptual model HTML version (or similar)

If the Semantic data specification is not suitable for public review, then is not published.

- If more elements than expected, elements need to be filtered out.
- If relations are missing, these need to be added.

### Release

After period of review is done, we send this to Cellar, so it can be further reviewed and merged into `main`

We create a tag corresponding to the version and do a release