This page contains a far more visual explanation of the Curation process and data model. It was written after the rest of the documentation in an attempt to create a new entry-point and/or supplemental information on what is really quite a dense topic.
In v1.2 the most common customisation that would be applied to this setup is to remove VITAL in ReDBox and replace with Handle integration instead:
However, until v1.3 there wasn't an easy way to build a test/demo system without Handle or VITAL both. With v1.3 however, we add the 'Local Curation' plugin which basically fakes the creation of a persistent ID based a template you provide in configuration:
The Life Cycle of a DigitalObject'. I've taken the final setup of the sample media object in that document and converted it show what a ReDBox object would like in our system prior to curation:
It is beyond the scope of explaining all the various parts shown here (but hopefully the core documentation linked above is helpful there), but the more important area to pay attention to is the 'Properties' associated with this object, because this is the area our various curation plugins will be fiddling with.
So Handle (above) creates a new property on the object that the Curation Manager can see which contains the complete Handle URL. Local Curation (below) does basically the same thing, except it has create a String from a template in configuration to use as a persistent ID:
The (slightly) more complicated scenario is VITAL, because it has to occur in two steps... the first is to send the record to VITAL (through Fedora) as an inactive object, and record the Fedora PID we created:
But at this stage we don't have our Handle... it is VITAL's job to do this as a background process. So the system will wait and periodically check for updates on that PID until it finds a Handle, then store the result:
Exciting stuff, I know... but for here we probably don't need to see all those details, so let's 'zoom out' a little to a more abstract idea of some object. The samples below represent a ReDBox Collection and a Mint Party, both of them do not have a persistent ID yet (note the empty properties):
So from here, the truly interested can take a detour into a slightly more technical (but still very visual) look at message flow through the system from the perspective of a single object. Or if the particulars don't interest you, the next section moves on to how curation events propagate through the network of objects across both systems.
In our example, the Curation Manager is going to look through the form data from the Collection (follow it's configuration) and notice it has an identifier for a creator in Mint, and a Mint Activity as well as a source of grant funding. In response it will send Mint a couple of messages asking for those records to in-turn undergo curation, and also request a response when this completes. For now, the work in ReDBox is complete, since it will await a response.
When Mint receives these requests its own Curation Manager is going to look at the metadata for the two objects and start curating those. The Activity is fairly straight forward (in our example, anyway), but the Party record for the creator also has a Party record related to it (his Faculty). So a similar process continues and the Faculty Party object will start curating and the trickle effect continues on to the Faculty's related Party record for the University as a whole.
At this point, having reached the 'end' of the network, the Curation Manager finds no more links to pursue and will start sending response back 'upstream':
(Click to enlarge)
These responses will contain all the newly curated persistent IDs, allowing each Object to update their metadata with a 'curated link' and in turn generate appropriate RIF-CS using externally visible persistent keys. Not diagrammed here is the final action; when the top-level Collection finally receives a curated PID from all downstream Objects it is going to send a general 'publish' message back downstream. This indicates that everything is ready to go and both ReDBox and Mint will release records to external parties via OAI-PMH. Until this 'publish' message is received, even a curated record would not be visible externally.