MARKLOGIC SERVER

Valid
Start: 2016-01-01
End: ∞
System
Start: 2016-01-05
End: ∞
Alameda
Doc 1
Created 2016-01-05
Figure 10: A document representing a person's location at a given time is added to a bitemporal
database.
Now let's say that the person moved to Berkeley on January 10, and we learn this on
January 12. We insert this knowledge as a new temporal document (Doc 3). To go
with this new document, MarkLogic creates a document to reflect the person's time in
Alameda as we know it now (Doc 2). MarkLogic also updates our first document to give
it a system end date. The first document is now a historical record of what we knew
about the person up to January 12:
Valid
Start: 2016-01-01
End: ∞
System
Start: 2016-01-05
End: 2016-01-12
Alameda
Valid
Start: 2016-01-01
End: 2016-01-10
System
Start: 2016-01-12
End: ∞
Alameda
Valid
Start: 2106-01-10
End: ∞
System
Start: 2106-01-12
End: ∞
Berkeley
Doc 1
Created 2016-01-05
Doc 2 Doc 3
Created 2016-01-12
Figure 11: A new person document (Doc 3) reflects the new location information. MarkLogic adds a
document (Doc 2) and updates the original version (Doc 1) to fill in the historical record.
On January 15, we discover a mistake: the person actually moved to Berkeley on
January 8! No problem. We insert a revised document noting the new valid times (Doc
5). Behind the scenes, MarkLogic creates a document (Doc 4) and edits system end
times in existing documents (Doc 2, Doc 3) to maintain an accurate historical record:
Valid
Start: 2016-01-01
End: 2016-01-10
System
Start: 2016-01-12
End: 2016-01-15
Alameda
Valid
Start: 2016-01-10
End: ∞
System
Start: 2016-01-12
End: 2016-01-15
Berkeley
Valid
Start: 2016-01-01
End: 2016-01-08
System
Start: 2016-01-15
End: ∞
Alameda
Valid
Start: 2016-01-08
End: ∞
System
Start: 2016-01-15
End: ∞
Berkeley
Doc 2
Doc 3
Created 2016-01-12
Doc 4 Doc 5
Created 2016-01-15
Figure 12: The person's location information changes again (Doc 5). Again, MarkLogic adds a
document (Doc 4) and updates times to fill in the historical record.
91