Documentation Notes

This page is just to collect notes that will be relevant to place in a more structured documentation about the module.

Versioning

• The API will allow you to create a revision even when there aren't any changes. Since a revision is always associated with a unique change set, if the last set of changes is always associated with the current revision, internally an empty change set will be added to the graph only for the purpose of creating the revision. An end-user facing interface (GUI or CLI) would normally not let the user create such empty revisions, or make it a special operation with a "--force" flag or something.

• The VChange interface is a general interface representing a change in a structured Versioned object. General purpose management routines such as reducing a list of changes to an equivalent shorter list or detecting conflicts between two lists of changes can be implemented independent of the details of what is being versioned (OWL axioms, or text or multi-module projects or whatever).

• When serializing snapshots, an in memory copy of the ontology is created because it is always possible that there are concurrent changes during the serialization and we don't protect for that. That is, we cannot rely on the working copy if when we are trying to serializing and send to a peer the current revision. So when we serialize revision X, we always start from the root revision R, find the shortest path to X and reply all changes in an in memory ontology.

• When an existing ontology that already contains axioms is versioned for the first time, a revision with a changeset consisting of the addition of all existing axioms is automatically created as a child of the root revision. This emulates what normally what would with GIT by first creating the report and then doing an initial commit+push of existing work.