OpenAtlas

I agree that it's very important for the user interface to handle sub-events, sub-documents, etc., and therefore, dedicating a tab to it seems appropriate. However, there are two very important issues for me:

1. Obtaining an identifier for each sub-part (E42 Identifier) (Full identifier: Main Document + subpart)
2. Sub-parts (in the case of documents) can be diverse:
3. # 2.1 Pages
4. # 2.2 Chapters
5. # 2.3 Sections
6. # 2.4 ...
   and these sub-parts can coexist in the same document (one tab for each group of sub-parts?)

In previous post was proposed an implementation:

"Source 1" (E33 - linguistic object) - P148 has component - "Subdivision of Source 1" (E33)

But lets to me show an specific example:

Let’s say you have:
A notarial book: “Protocol Book of Notary Joan Serra (1632)”
An entry: “Sale of a house on Carrer Major”, located on page 45, entry no. 125

You could model it as:
- *E31 Document* → The full protocol book
- *E73 Information Object* (or E90) → The individual notarial entry
- P106 is composed of or P165 incorporates → To indicate the book includes the entry
- *E42 Identifier* → “entry 125, page 45”
- *E41 Appellation* → If you want to include a textual label

You could link the E31 Document to a physical object (E84 Information Carrier) or a digital scan (E73) depending on the material

or consider:

- Use E73 Information Object to represent specific, identifiable segments of information (e.g., a page or an entry).
- Link them to the document (E31 Document) using P165 incorporates or P106 is composed of.
- Use E42 Identifier or E41 Appellation to indicate location or reference info (e.g., “page 45”, “entry 125”).
- Use E90 Symbolic Object if the unit is more conceptual or abstract (like a named clause or legal phrase).

In short: the CIDOC model allows for different options for subdocuments, and if we add the handling of sub-events, it is a challenge for the Openatlas architect and programmers.

Hi everyone! Thanks for the very elaborated thoughts on this. The mappings suggested by Enric seem a good way to map the examples.
However this is not yet implemented in OpenAtlas.

A way/workaround would be this (using Enric's Example) :

Let’s say you have:
A notarial book: “Protocol Book of Notary Joan Serra (1632)”
An entry: “Sale of a house on Carrer Major”, located on page 45, entry no. 125

You could model it as:
- *E31 Document* → The full protocol book, E.g. with the type (E55) Edition/Protocol book or any other meaningful typology defined by you. 
- *E33 Linguistic Object/Source* → The individual notarial entry
- P67 is referred to by (between book and entry: “entry 125, page 45” - stored in the link description between E31 and E33) → To indicate the book includes the entry
- *Name of the Source* → If you want to include a textual label (can be resolved as Identifier)

You could link the E33 (Source/lunguistic object) Document to a physical object (E22 Human made object/ Open Atlas Artifact) via P128 (carries) - Information Carrier is deprecated and no longer in the currend CRM definitions.

We were planning an overwork of the UI for historical/textual entries #1064 that would make that workflow more comprehensive, it is on the wishlist.

hope this helps!
best regards,
Stefan