• Table of contents
• Model
• Dates
• Sources Workflow
• References and files

Model¶

Here you can see an already simplified version of the model used in OpenAtlas which is based on classes and properties of the CIDOC CRM.

OpenAtlas and CIDOC CRM

Dates¶

The OpenAtlas data model can store chronological information for certain entities and properties.
In general it can document a timespan for the begin and a timespan for the end of these. The smallest timespan unit possible is one day. There are no restrictions regarding the length of these time spans.

E.g. if you you do not know the exact date of an actor's birth but only that she/he was born at the earliest in 800AD and at the latest before 805AD this timespan would range from Jan, 1st,800 to the Jan.1st 805. Given that person died on Aug. 23rd in 877 you would only enter that day as and end-date. In the user interface this case would look like:

The system automatically creates the correct timestamps given by the bounding dates provided by the user:

This way you can store chronological information as precise as possible respectively as fuzzy as necessary. Also it is possible to add a comment on the date e.g. "circa".
The same principle works for all of the following entities and properties:

Entities
  Physical Things
     Places (E18)
       Features (E18)
       Stratigraphic Units (E18)
       Finds (E22)
   Actors
       Persons (E21)
       Groups (E74)
       Legal Bodies (E40)
   Events
       Activity (E7)
       Acquisition (E8)
       Production (E12)
       Destruction (E6)

Properties that link actors to Events
   performed (P14)
   participated in (P11)
   acquired title through (P22)
   surrendered title through (P23)
 Properties that link actors to Actors
   has relationship to (OA7)
   is current or former member of (P107)

The data is stored in the table model.entity respectively model.link in the fields begin_from, begin_to, begin_comment, end_from, end_to, end_comment as timestamps.
Depending on class of the entity respectively the domain and range classes of the link these dates can be mapped as time primitive (E61) entities within the CIDOC CRM.
The respective paths are the following:

E77 Persistent Item begin linked with a E61 Time Primitive:

• Domain: E77 Persistent Item
• Range: E61 Time Primitive

E77 (Persistent Item) - P92i (was brought into existence by) - E63 (Beginning of Existence) - P4 (has time span) - E52 (Time Span) - P81 (ongoing throughout) - E61 (Time Primitive)

Example: [Holy Lance (E22)] was brought into existence by [forging of Holy Lance (E12)] has time span [Moment/Duration of Forging of Holy Lance (E52)] ongoing throughout [0770-12-24 (E61)]

E77 Persistent Item end linked with a E61 Time Primitive:

• Domain: E77 Persistent Item
• Range: E61 Time Primitive

E77 (Persistent Item) - P93i (was taken out of existence by) - E64 (End of Existence) - P4 (has time span) - E52 (Time Span) - P81 (ongoing throughout) - E61 (Time Primitive)

Example: [The one ring (E22)] was destroyed by [Destruction of the one ring (E12)] has time span [Moment of throwing it down the lava (E52)] ongoing throughout [3019-03-25 (E61)]

E21 Person's Birth linked with a E61 Time Primitive:

• Domain: E21 Person
• Range: E61 Time Primitive

E21 (Person) - P98i (was born) by - E67 (Birth) - P4 (has time span) - E52 (Time Span) - P81 (ongoing throughout) - E61 (Time Primitive)

Example: [Stefan (E21)] was born by [birth of Stefan (E12)] has time span [Moment/Duration of Stefan's birth (E52)] ongoing throughout [1981-11-23 (E61)]

E21 Person's Death linked with a E61 Time Primitive:

• Domain: E21 Person
• Range: E61 Time Primitive

E21 (Person) - P100i (died in) - E69 (Death) - P4 (has time span) - E52 (Time Span) - P81 (ongoing throughout) - E61 (Time Primitive)

Example: [Lady Diana (E21)] died in [death of Diana (E69)] has time span [Moment/Duration of Diana's death (E52)] ongoing throughout [1997-08-31 (E61)]

E2 Temporal Entity (also property) begin linked with a E61 Time Primitive:

• Domain: E2 Temporal Entity
• Range: E61 Time Primitive

E2 (Temporal Entity) - P4 (has time span) - E52 (Time Span) - P81 (ongoing throughout) - E61 (Time Primitive)

Example: [Thirty Years' War (E7)] has time span [Moment/Duration of Beginning of Thirty Years' War (E52)] ongoing throughout [1618-05-23 (E61)]

E2 temporal entity (also property) end linked with a E61 Time Primitive:

• Domain: E2 temporal entity
• Range: E61 Time Primitive

E2 (temporal entity) - P4 (has time span) - E52 (Time Span) - P81 (ongoing throughout) - E61 (Time Primitive)

Example: [Thirty Years' War (E7)] has time span [Moment/Duration of End of Thirty Years' War (E52)] ongoing throughout [1648-10-24 (E61)]

Sources Workflow¶

#1064 In conception phase, draft by Stefan:

Due to the increasing complexity and additional features regarding written sources and their interconnections we need to reorganise the respective UI.
It should be easy to distinguish between:

Core

1. Content: Source Content (summary of the content), Source Translation, Source Transliteration on one hand and further linked entities like the
2. Information Carrier (physical object like the letter, paper, papyrus etc.)
3. References bibliographic references (e.g. Edition of the charter, further bibliography) and external references

Entities referred to by the content

1. Actors mentioned in the content
2. Places mentioned in the content
3. Events mentioned in the content

Entities involved in creation of the source

1. Creators/writers/involved actors of the information carrier
2. Place of creation
3. Date of creation

Linking between event entities from the content

1. Activity including location where it took place and involved actors along with dates
2. Acquisition including place/property that changed ownership along with new and old owner plus dates

Further links

1. Move of information carrier/physical object in case of e.g. letter exchange along with date and start/end location

References and files¶

Various entities can be connected to files. This is mapped as E31 (Document = file) refers to (P67) -> E1. In our case files can refer to any of the "top level" entitites.
Files can (but need not necessarily) be images. Files are stored with a certain system type (i.e. file). If the file is an image, this is most probably a depiction of the entity.

A file can also have a further reference. E.g. the source where the file comes from. This is for example the bibliographical reference to the publication where a file (e.g. a scanned image) is extracted from. In this case there is a link between a document E31 with a type "Bibliography" (or subtype) via P67 to another document E31 with a system type "file". In this case the file is not the depiction of the reference but the reference is the origin of the file. This is mostly needed to document the copyright resp. right holder or source of the file.