Ishtar's development is indeed modular, so that only really necessary functionnalities are present in the user interface, so as not to drown the user in a profusion of functions that he never uses.
On a default instance, only modules from what is considered as the core of the software are enabled. To enable other modules, you have to be an administrator of the instance. It can be done in the administration interface, then Ishtar - common > Ishtar instance profiles, or, more directly, through the url your_instance_url/admin/ishtar_common/ishtarsiteprofile/
Ishtar enables to remove any non-mandatory field from display, or to limit this perception by user type (custom forms). This can only be defined by an administrator of the database, via the administration interface. It is thus possible to adapt Ishtar to your use, first by selecting the modules which are useful to you (cartography, archaeological sites, context records, files, warehouses, etc.) then by not displaying the fields which do not seem useful to you. Note that it is possible to change your mind (modules, fields) later!
First of all, clarification on the notion of archaeological operation: it is defined as an action (or a project of action) allowing to acquire archaeological data, under the responsibility of a person (examples: incidental discovery, trial trenching, research excavation, field survey, etc.) and in a place if possible defined.
If the operation is the core of Ishtar's data model rather than the archaeological site, it is because the latter is an interpretation (like any interpretation, subject to evolution over time) of the data, whereas the operation is the information that best brings together a coherent documentary corpus linking documents (plans, reports, photos, etc.) and finds.
Within Ishtar, it is possible to create links between operations, either by associating them with the same source file (with the "administrative" module, e.g. a building permit which is associated with a trial trenching and a rescue excavation), or by defining a relationship between global operations (e.g. collective research program, motorway monitoring, etc.) and more specific operations (phases, sections, sectors, etc.). The clustering of operations is also practical in the context of research excavations, where it may be useful to have inventories for each operation per year, but also a global view of the sequence of excavations (global operation). In the context of a major rescue operation, this system can be used to identify excavation areas with specific recording methods. The user has full latitude to organize the operations between them according to his needs, as long as these key elements represent a priori coherent documentary and finds collections.
So as not to impose a unique way of doing things on our fellow archaeologists!
Ishtar thus proposes a broad use of the concept of Context Record, defined as a volume (or surface) spatially referenced (specifically or not), associated with archaeological information and containing (or not) finds. Trench 3, structure ST25, stratigraphic unit 137 or the NE quarter of A3 square are all valid Context Records for Ishtar.
Ishtar manages relations between the Context Records. This enables in particular to define nested Context Records (for example: trench > structure > stratigraphic unit) but also to manage stratigraphic relations between stratigraphic units.
The creation of stratigraphic diagrams is not yet implemented, but could be the subject of a specific module. Ishtar's data are compatible with the use of tools such as Bruno Desachy's Stratifiant (in French only).
For legal reasons: this enables to obtain lists of Context Records (and therefore of finds) linked to a cadastral parcel in order to define the ownership of these objects and thus facilitate the sharing or, more simply, the responsibility in the case of restoration work.
Many old inventories do not allow to define the parcel corresponding to finds: the parcel associated with the Context Record is therefore a virtual parcel.
You're damned! No, actually, everything is under control. One of Ishtar's principles is to allow the best possible data standardisation, in order to maximize the possibility of data reuse and statistics; but that should never be a hurdle! No Context Record = creating a virtual Context Record.
Ishtar will not take the first row into account as it often contains column names. But you can modify that behavior by setting the Skip lines parameter to 0 (default value: 1) during a New import.
The Encoding parameter of a New import is your friend. There are three default encoding types: utf-8, ISO-8859-15, windows-1252. If the problem persists, convert your file to utf-8 in your source software, it would be surprising that you really need another encoding (utf-8 is a worldwide standard).
Currently, in v1, for the import as a thumbnail, it is only one image by object. This will change in 2018, with the development of a real media manager within Ishtar v2. On the other hand, photos can already be imported as document related to finds (or context records), via the import of sources. The thumbnail related to finds is the equivalent of an easily accessible photo ID, this is not managed as a document in Ishtar v1. But this is bound to evolve greatly in the version 2 of Ishtar.
Ishtar currently only accepts CSV, which is the standard exchange format between spreadsheets. It's accessible in all spreadsheets as basic format in the "Save" or "Save As" functions.
Yes! This is possible if you host your own instance or, for Iggdrasil's hosting offers, if you are on the "dedicated" offer.
Upcoming tutorial (on the forum) with QGIS.