Free software for archaeological data management

Frequently Ask Questions





In my menu, I don't have all the modules that I can see on some screenshots!

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/

There are plenty of fields in Ishtar that I don't care of! How can I get rid of them?

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!

Why are data managed by archaeological operation rather than by archaeological site?

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.

Why use Context Records instead of Stratigraphic Units or ... ?

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

Why is a Context Record necessarily linked to a parcel?

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.

I don't know what to use as a Context Record, what should I do?

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.


The first row of my CSV file is not imported, why?

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.

I've got problems of accents or diacritic signs not well imported!

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

Is it possible to add several images in a Finds import?

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.

I've provided a Calc file (LibreOffice, ods format) to Ishtar for an import and that doesn't work!

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.


Is it possible to connect an Ishtar database to a Geographic Information System (GIS)?

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.


Ishtar is a database project for managing archaeological data and documentation (including archaeological finds) from archaeological operations, ensuring maximum traceability of the information, published as a free software under AGPL license.