If you are looking how to manage epochs, see Epoch command
Epoch is something like complete database of assets within time. We are living in world where things are changed rapidly.
This is same for networks. The goal of platform is to represent some "snapshot" of network at specific time. This is technically impossible because even during collection process, network can change. From that reason, we define epoch which represents some minimal granularity of time for which we can make virtual representation of network.
You can see example of two epochs. See that one interface is missing in secondary epoch - model changed.
We can track time differences in network by using more epochs.
Time range of epoch is not strictly defined. It can be day, week, month or whatever. It does not have to be regular interval at all (even if it is much better). Let us say we choose daily epoch creation. This means that we want network represented in database every day.
And there is one day window to run all collections, reports and tasks. Remember that every epoch contains data about entire network. So if we have network with 1000 objects and 10 epochs, we need enough space and CPU power to save 10000 objects. Do not worry about these numbers, we can work with milions of objects.
It is user decision if he just wants to model network (one epoch) or do tracking of objects within history (more epochs).
You cannot ask for differences in time within one epoch. If object is created within epoch, and then modified/deleted by other task/collection, it is replaced or deleted. You cannot track this. If you want to track object history, more epochs is needed.
Object URL is primary identifier within epoch. Same object cannot be duplicated within epoch.
Epochs are independent representation of network within specified timerange.
There can be even temporary epochs which can be used as playground. For example, to copy data from other epoch, run some new collections or tasks, see result and then delete it.
If you are just playing with platform, do not worry. Just use init epoch and play. You can always add new epoch or delete it.
If you plan to implement regular indexing, consider these facts:
All commands which are run within epoch are saved to epoch history. See history command.
All commands which do management of epochs and other global objects are saved into global history.
When database is initialised, there is only one epoch named 'init' which is first epoch. See history command.
There are two kind of epochs - commited and open. Open epochs are work-in-progress. So there are some collections or tasks running. Commited epochs are epoch where all data are already settled and it can be used for reporting. Commited epochs are read-only. To do any changes within committed epoch, it needs to be reopened.
There is a data consistency problem we need to solve because there are two heads. One is latest stable, commited epoch which can be used for reporting/querying and second is work-in-progress epoch which is just processed. Do we need last usable data (last commited epoch) or last work-in-progress data (last opened epoch)? To solve this problem, we use parameter --epoch where you can specify this behaviour.
For epoch differences, you can use even --prev_epoch parameter to specify previous epoch.