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.

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

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

• 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)

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)