h1. Site designs

Here we collect ideas for the generic presentation sites.
Sorry about the not so fine looking draft, it's just a starting point and feel free to add/adapt/restructure.

h2. Views

This are individual views, in parenthesis criteria are criteria defined how to fetch related entities. Possible are:
* system_class (OpenAtlas specific class definitions used in the backend and also useful for frontend)
* view_class (Collection of system_class, e.g. actor for person and group)
* cidoc_class (not sure if needed)
You can see how these are related in the backend at **model/OpenAtlas classes**, e.g. in the demo at this "site":https://demo.openatlas.eu/overview/model/openatlas_class_index

*General Notes*

* Empty fields/attributes should be hidden.
* It should be possible to choose the default entity view via the CMS, similar to how it should be possible to what the default landing page is.


*Main views*

* All
** Should have a breadcrumb for their system classes. Clicking on elements higher in the hierarchy should lead to the data view containing elements of that system class.
  *Note about the breadcrumb* (by Alex): in the backend the breadcrumb begins with the *view*, not the *system class*. E.g. with a *system class* of activity, acquisition, move, ... the first element would be the *view* for "event".
  This is just a note and it can of course differ at the frontend. See about "classes and views":https://demo.openatlas.eu/overview/model/openatlas_class_index

** Primary
*** Name
*** Alias (only for place and actor)
*** Types
*** Dates
*** Description
*** Profile image
** Secondary
*** References (This is probably dependent on the entity). 
*** All other Attributes
*** @Mocca, I believe it should not include the attributes shown already, e.g. if the images are shown in the gallery, the link to the file entity would not be needed. 


* Source (system_class source)
** Description extra important. It could be a summary or the source itself.
** Multiple Tabs for the different texts (Translations, Transliterations, ...)
** Download buttons for the non-viewable files extra important here.
* Event (view_class event), this includes: Acquisition, Activity, Creation, Event, Modification, Move, Production. 
** The diferences are detailed in the Manual. Most share most commonalities with Activity, therefor a common template would be sensible.
** All except Event: 
*** Sub-Event
*** Pre/Super-ceding event.
*** Location (on map)
*** Actors:
**** Timespan of Actor for the event.
**** Standard type: Involvement
* Actor (view_class actor), this includes: Person, Group. Detailed in Manual
** All
*** Residence
*** Born/Started in
*** Died/Ended in
* Place (system_class place)
** All
*** Location (on map)
*** Administrative unit & historic place:
**** Show as title & description & date (the Most important info)
*** Show sub-locations (on map)
*** Show all connected artifacts & human remains.
** Feature (system_class feature) 
*** For features and all "lower" elements (like Stratographic units, ..) it should be possible to navigate to the neighbouring entities (in the list not necessarily location wise).
*** Linked Stratographic units
*** Here breadcrumbs are especially important again.
** Stratigraphic unit (system_class stratigraphic_unit)
* Artifact (view_class artifact), this includes artifacts and human remains (maybe split them?)
** Images are essential, it might make sense to differ the view for images a bit for artifacts to accommodate for that.
** Owned by -> Actor
** Sub-Artifacts
* Vocabulary (not sure how to name or structure these)
** Type (system_class type)
*** External & Interal reference are crucial.
*** Type hierarchy, potentially a place for breadcrumbs again.
*** Linked entities, both directly and for subtypes:
**** Count
**** List
*** Bar Graph
** Administrative unit (system_class administrative_unit), there are 2 fixed hierarchies (administrative units and historical places)
* File


There is some information that can possible be included in most (or at least multiple) classes so maybe we want to design a kind of "base layout". These are:
* Name
* Alias (only for place and actor)
* Types
* Dates
* Description
* Profile image (either a set one or just the first one, this could be a good point for a gallery function. The file class obviously is a special case)
* Reference to a source entity
* External references (e.g. to Wikidata, GeoNames or Vocabs)
* References (e.g. edition)
* Map (if connected to a place, e.g. in a move event or a residence of a person)
** I(@mocca) believe it would be a good idea to show linked places in this map as well, at least on demand. E.g. a gravesite would also show the connected graves on the same map.
* Files (attached to that entity)

*Likely an extra view isn't needed for these*
Following system classes probably won't need an own view:
* actor_function (actor function at a group e.g. a profession)
* actor_relation (between actors)
* appellation (alias)
* involvement (actor function at an event)
* bibliography
* edition
* external_reference
* object_location
* reference_system
* type_tools (types for e.g. radio carbon values, ... we take of these later)

h2. Maps

* When an overview, e.g. at start page, only show system_class place and only use markers (if area choose center point)
* When showing at a detail view (e.g. of a place) show areas (instead of center points) and next subunits (e.g. features of a place)