Foire Aux Questions

Concepts

Imports

Interopérabilité

Concepts

Dans mon menu, je n'ai pas tous les modules que je vois sur certaines captures d'écran ! Comment faire ?

comparaison des menus de deux instances Ishtar

En effet, Ishtar a été développé sous forme de modules pour que seules les fonctionnalités réellement nécessaires soient présentes dans l'interface utilisateur, pour ne pas noyer l'utilisateur sous une profusion de fonctionnalités dont il ne se sert jamais. Ishtar ayant vocation a être utilisé par tous les archéologues, du Service Régional de l'Archéologie à l'association d'archéologues bénévoles, en passant par les opérateurs d'archéologie préventive publics et privés, les dépôts archéologiques et CCE, les Programmes Collectifs de Recherche et autres ANR, les musées archéologiques, il y a forcément des modules à la fois indispensables à certains et inutiles à d'autres.

Sur une instance par défaut, seuls les modules considérés comme le tronc commun (Ishtar-core) sont activés. Pour activer les autres modules, il faut être administrateur de l'instance. Cela se fait dans l'interface d'administration, puis Ishtar - commun > Profils d'instance Ishtar, ou, plus directement : url_de_votre_instance/admin/ishtar_common/ishtarsiteprofile/

Il y a plein de champs dont je ne veux pas dans Ishtar ! Je n'en ai pas besoin, comment faire ?

Ishtar permet de supprimer de l'affichage tout champ non obligatoire, ou de limiter cette perception par type d'utilisateur (formulaires personnalisés). Ceci ne peut être défini que par un administrateur de la base, via l'interface d'administration. Il est ainsi possible d'adapter Ishtar à votre usage, tout d'abord en sélectionnant les modules qui vous sont utiles (cartographie, sites archéologiques, unités d'enregistrement, dossiers, lieux de conservation, etc.) puis en supprimant les champs qui ne vous semblent pas utiles. Notez qu'il est possible de revenir sur ces décisions (modules, champs) plus tard !

Pourquoi dans Ishtar les données sont-elles gérées par opération et non par site (ou entité) archéologique ?

Tout d'abord, précision sur la notion d'opération archéologique : elle est définie comme une action (ou un projet d'action) permettant d'acquérir des données archéologiques, sous la responsabilité d'une personne (exemples : découverte fortuite, diagnostic, fouille programmée, prospection, etc.) et dans un lieu si possible défini.

Si l'opération est le cœur du modèle de données d'Ishtar plutôt que le site ou l'entité archéologique, c'est parce que ce dernier est une interprétation (comme toute interprétation, sujette à évolution dans le temps) des données, alors que l'opération est l'information qui permet au mieux de regrouper un corpus documentaire cohérent mettant en lien des documents (plans, rapports, photos, etc.) et du mobilier.

Au sein d'Ishtar, il est possible de créer des liens entre des opérations, soit en les associant à un même dossier source (avec le module « administratif », ex. : un permis de construire qui est associé à un diagnostic et une fouille préventive), soit en définissant une relation entre des opérations globales (ex. : PCR, suivi d'autoroutes, etc.) et d'autres plus ponctuelles (phases, tranches, secteurs, etc.). Le regroupement d'opérations est également pratique en contexte de fouilles programmées, où il peut être utile d'avoir des inventaires pour chaque opération par année, mais également une vision globale de la succession des fouilles (opération globale). En contexte de grande opération préventive, ce système peut servir à individualiser des secteurs de fouilles disposant de modes d’enregistrements spécifiques. L'utilisateur a toute latitude pour organiser les opérations entres elles selon ses besoins, du moment que ces éléments clefs représentent bien des lots documentaires et mobilier a priori cohérents.

Pourquoi avoir utilisé des Unités d'Enregistrement (UE), et pas des Unités Stratigraphiques (US) ou ... ?

exemple de diagramme des relations stratigraphiques généré automatiquement sur la fiche de l'US-2402

Pour ne pas imposer une façon unique de faire à nos collègues archéologues !

Ishtar propose ainsi un usage large du concept d'unité d'enregistrement (UE), définie comme étant un volume (ou une surface) référencé dans l'espace (précisément ou non), associé à des informations archéologiques et contenant (ou pas) du mobilier. La tranchée 3, la structure ST25, l'US137 ou le quart NE du carré A3 sont tous des UE valides pour Ishtar.

Ishtar gère les relations entre UE. Cela permet notamment de définir des UE emboîtées (par exemple : tranchée > structure > US) mais aussi de gérer les relations stratigraphiques entre US.

Il est possible de générer des diagrammes des relations stratigraphiques à partir de chaque fiche d'UE. Sur ces diagrammes les relations erronées (par exemple relation circulaire d'une UE à la fois sur et sous une autre suite à une erreur de saisie) sont mises en évidence en rouge, et permettent ainsi de repérer et corriger les erreurs de la base de données.

Les données d'Ishtar sont en outre compatibles avec l'usage d'outils tels que Le Stratifiant de Bruno Desachy.

Pourquoi une Unité d'Enregistrement (UE) est-elle obligatoirement associée à une parcelle ?

Pour des raisons légales : cela permet d'obtenir des listes d'UE (et donc de mobilier) lié à une parcelle afin de définir la propriété de ces objets et faciliter ainsi la réalisation du « partage du mobilier » ou plus simplement la responsabilité dans le cas de travaux de restauration.

De nombreux inventaires anciens ne permettent pas de définir la parcelle correspondant au mobilier : la parcelle associée à l'UE est alors une parcelle virtuelle.

Sur les instances qui n'ont aucun besoin de la parcelle, il est néanmoins possible de désactiver cette obligation en interface d'administration.

Je ne sais pas quoi mettre comme Unité d'Enregistrement dans mon contexte, que faire ?

You're damned! Non, en fait tout va bien. Un des principes d'Ishtar est de permettre la meilleure standardisation possible des données, afin de permettre le plus de réutilisation possible de ces données ; mais cela n'est jamais bloquant ! Pas d'UE = créez une UE virtuelle.

Imports

La première ligne de mon CSV n'est pas importée, pourquoi ?

Par défaut Ishtar propose de ne pas prendre en compte la première ligne du CSV car celle-ci contient d'ordinaire des noms de colonnes. Mais vous pouvez modifier cela en mettant à 0 le Nombre de lignes d'entête (par défaut à 1) dans les champs proposés lors d'un Nouvel import.

J'ai plein de problèmes d'accents et de signes diacritiques mal importés !

Il y a également un champ lors d'un Nouvel import pour résoudre ce problème, c'est le champ Codage. Il y a par défaut 3 types de codage, les 3 plus courants en France : utf-8, ISO-8859-15, windows-1252. Si ça ne passe toujours pas, convertissez votre fichier en utf-8 dans votre logiciel source, il serait surprenant que vous ayiez réellement besoin d'un autre encodage (utf-8 est le standard mondial).

Peut-on ajouter plusieurs images lors d'un import de mobilier ?

Tout à fait ! Petite astuce : la première image citée dans le fichier à importer pour un mobilier sera considérée par défaut comme son image principale, c'est-à-dire celle qui s'affiche en plus grand sur la fiche concernée. Si vous avez déjà importé vos images et que la première n'était pas l'image principale, il suffit de modifier la fiche de l'image qui devrait l'être et de cocher la case idoine.

J'ai fourni un fichier calc (libreoffice, format ods) à Ishtar pour faire un import et ça ne marche pas !

Ishtar n'accepte actuellement que du CSV, qui est le format d'échange standard entre tableurs. C'est accessible dans tous les tableurs comme format de base dans les fonctions "Enregistrer" ou "Enregistrer sous".

Interopérabilité

Peut-on connecter une base de données Ishtar à un Système d'Information Géographique (SIG) ?

Oui ! Cela est possible si vous hébergez votre propre instance ou, pour l'offre d'hébergement Iggdrasil, si vous êtes sur l'offre « dédiée ».

Tutoriel à venir (sur le forum) pour se connecter à partir du logiciel libre QGIS.

Ishtar

Ishtar est un projet de base de données visant à gérer les données et la documentation (mobilier inclus) provenant d’opérations archéologiques, en assurant une traçabilité maximale des informations, publié sous la forme d'un logiciel libre sous licence AGPL.