Quelques remarques et suggestions concernant la saisie des unités d’enregistrement (UE), plus particulièrement dans la première fenêtre (général) :
On ne peut pas associer plusieurs parcelles cadastrales à une même UE alors que le cas est fréquent si l’on considère des unités surfaciques relativement étendues (tranchées, zones, secteurs…).
Il serait utile de pouvoir choisir l’unité de mesure un moyen d’un menu déroulant : par exemple, le cm (seule unité actuellement proposée) n’est pas très pertinent pour une longueur de tranchée, mais l’est davantage pour une profondeur d’US. En outre, il serait bien d’ajouter d’autres champs (surface, volume,…), ce qui permettrait, par exemple, de calculer des taux d’échantillonnage (pour les diags).
Le menu déroulant ‘Unité’ me semble confus car il mélange différents niveaux de lecture (je souscris pleinement aux remarques d’Anne Chaillou postées le 18/08/2011 à propos des listes). Je propose 3 principales distinctions et quelques sous-catégories associées (la liste ci-après n’est pas exhaustive) :
UF = unités de fouille (au sens large / NB : une parcelle cadastrale peut désigner une UF dans le cas d’une prospection au sol par exemple). Ce type d’unité procède du plan d’échantillonnage mis en place par le RO : zone, secteur, carré, tranchée, sondage, log stratigraphique, etc. ;
UA = unités archéologiques (je n’ai pas trouvé mieux comme terme…), qui découlent de l’interprétation du site : fait, structure, ensemble, etc. ;
enfin, je distinguerais les US en tant qu’unités élémentaires de description de la stratigraphie.
La désignation des types d’unités mérite en tout cas plus de clarté, notamment dans la perspective d’une gestion des relations entre UE dans Ishtar : e.g. une US documentant de la stratigraphie de tel fait (UA) participant de tel ensemble structuré (autre UA) mis au jour à l’occasion de tel sondage (UF) ou de telle tranchée (autre UF), réalisé(e) dans tel secteur (autre UF)…
Je suggère aussi de réfléchir à une possible réorganisation des champs en fonction des types d’unités. Les champs intéressant la chronologie et l’interprétation en termes archéologiques des UE n’ont guère de sens pour les unités de fouille (telles
que définies plus haut). Parallèlement, la description des US s’appuie sur des champs spécifiques qui n’ont pas nécessairement leur place parmi les descripteurs des UF ou des UA
Dernier point, je ne comprends pas le sens du champ ‘Lieu’ dans la fenêtre ‘Général’.
Je fais ici une réponse rapide, j’en ferais une plus détailéle plus tard (je suis sur le terrain) :
1 : UE et parcelles : Oui, pour l’instant nous somms resté sur cela car avec la loi actuelle (pourvu qu’elle change !!!) la propriété du mobilier est liée en partie à celle associée aux parcelles. La gestion des partage implique alors qu’une UE soit uniquement dans une seule parcelle… Pénible mais unique moyen pour être conforme à la réglementation actuelle (qui est stupide). CEPENDANT étant donné que nous espérons que cela change nous allons modifier cela pour permettre plusieurs parcelles pour une UE ce qui est, nous en sommes conscient, bien plus simple et cohérent par rapport aux données. Je vais faire un ticket à ce sujet.
2 : OK pour ajouter des champs (surface autre), bonne idée pour les taux d’ouverture (on peut en effet les calculer automatiquement). Pour les unités c’est plus génant, surtout pour gérer des calculs entre des unités variées. A garder en proposition, mais ce n’est aps évident. A réflechir.
3 : Tout cela ce sont bien des types d’UE, les listes actuelles sont modifiables bien sur, cela ne change pas grand chose en base et n’empêche même pas l’intercompatibilité interbase. Donc chacun peut prendre ce qui lui convient ou bine créer sa typologie personelle, ce que tu viens de faire et pourrait être très discutable.
“les US en tant qu’unités élémentaires de description de la stratigraphie” là ça ferait hurler plein de gens à réflechir.
La prochaine aélioration de la base (pour décembre) prévoit dejà les relations entre UE (inclusions, etc…) cela devrait de toute manière régler le problème.
Sinon en effet certaines fenêtre pourraient n’être associées qu’a des éléments ayant un sens chronologique, mais cela pourrait être géré plus simplement, et de manière plus souple avec un binaire. Si nous contraignons trop la base elle perdra de sa souplesse. Certains vont vouloir donner des valeurs chrono à des structures, et ne pas utiliser d’US. Le but n’est pas de savoir si ils ont raison ou tard, mais que cela corresponde à un usage. Donc oui, très bonne remarque mais à réflechir pour garder une système souple et simple… pas facile. Je vais voir cela.
4 : De mémoire c’est un champ optionnel qui permet une précision sur l’emplacement de l’UE. Cela peut aussi être utilisé pour une jointure SIG, mais nous reparlerons de cela
Merci beaucoup pour ces remarques ! Nous avons besoin d’autres retours donc n’hésite pas ! Je repost-ici une fois les tickets en place.
Concernant les US et la notion « d’unité élémentaire » (sic), je voulais simplement dire – sans vouloir faire de polémique – que les US peuvent justifier un module en soi avec des champs spécifiques (couleur, texture, sur, sous, etc.) qui - a priori - n’ont pas leur place dans les masques de saisie pour les autres UE, notamment pour les unités de fouille (zone, secteur, carré, sondage, etc.) ; ça se discute pour les faits, structures, ensembles…mais elles correspondent, à mon avis, à un autre niveau de description et/ou d’interprétation. Cela dit, je suis conscient que cette coupure est quelque peu arbitraire et répond plus à une nécessité pratique qu’à une exigence conceptuelle. Enfin, tout ça pour dire que ma réflexion portait plus sur l’architecture d’Ishtar. Par exemple, dans la base que je développe (plus trop d’ailleurs, parce qu’Ishtar est bien plus viable à terme et présente de nombreux autres avantages), j’ai une table UE qui constitue un tronc commun (Identifiant, Type d’UE,…) et trois tables liées à la première au moyen d’une jointure de type 1 à 1 (UF, UA, et US). Le système gère les relations entre unités au niveau des UE. On peut mettre donc mettre en relation deux UE, quelle que soit leur nature respective (ce qui peut changer, en revanche, c’est la modalité de la relation). En outre, si la notion de fait (ou de structure, d’ensemble, de zone…) est absente du système d’enregistrement, cela n’a pas d’importance. De même, un système hyper-hiérarchisé, voire rigide (zone>secteur>carré>ensemble>structure>fait>US, etc.), peut être géré aussi…
à réflechir.