En effet, la génération de diagramme est une fonctionnalité non-paramétrée par défaut. Elle est encore en cours de stabilisation et n’est, en effet, pas encore documentée.
Pour que cette génération de diagramme fonctionne, il faut deux choses :
que « Générer le graphe de relations » soit coché sur le profil ;
que les « Relations logiques » soient paramétrées au niveau des types de relations entre unités d’enregistrement (à l’heure actuelle sont prises en comptes les relations logiques « au dessus », « au dessous » et « égal »).
Sur votre instance, le profil est bien paramétré mais au niveau des types de relations, ces relations logiques ne sont pas paramétrées.
Bonjour Étienne,
Merci de ta réponse… mais je ne vois où trouver les paramètres que tu évoques. J’ai cherché dans les pages Consultation/saisie UE et les deux interfaces d’administration, mais je ne vois pas.
Est ce que je peux faire ce paramétrage moi-même?
C’est une fonctionnalité qui nous intéresse vraiment…
J’avais oublié cette question en souffrance (des vacances sont passées par là).
Pour accéder à ces paramétrages, il faut tout d’abord avoir les droits en administration (j’ai vérifié ton compte est bien paramétré pour avoir ces droits).
Ensuite il faut se rendre en administration Ishtar https://<nom-de-domaine-de-mon-instance>/admin ou, depuis l’interface générale, l’icône engrenages en haut à droite.
Les éléments à modifier se trouvent au niveau de : Ishtar - Unités d'enregistrement > Types de relation > Modifier.
Depuis la liste de types de relation, cliquer sur les éléments à modifier (première colonne), faire la modification de l’élément en lui ajoutant une équivalence logique et Enregistrer. Édité
Super, ça fonctionne sur mon exemple avec quelques US!
Question peut-être stupide… Pourquoi est-ce que ce n’est pas activé par défaut? Un ticket à créer ?
Quelques remarques/questions suggestions sur les relations. Elles sont actuellement listées ainsi :
Dénomination Identifiant textuel
Comble filling
Comblée par filled_by
Coupe cutting
Coupée par cutted
Équivaut à equals
Incluse dans is_included
Inclut include
Relation indirecte indirect_relation
Sous is_below
Sur is_above
A Bourges nous utilisons de manière distincte dans notre enregistrement:
Égale à
Équivalent à
Ce qui équivaudrait a priori aux valeurs dans le Stratifiant
Synchrone avec
Peut-être synchrone [avec]
Il nous manquerait donc une relation « égale à »/ « synchrone avec » … que je pourrais ajouter manuellement, mais la traduction textuelle en anglais ne correspondra pas.
Je vais faire une solution à court terme avec un
Dénomination Identifiant textuel
Égale à strictly_equals
Ma proposition pour une correction à long terme serait donc:
Dénomination Identifiant textuel
Égale à equals
Équivaut à equivalent_to
ou quelque chose… d’équivalent (vu mon niveau d’anglais…)!
… avec une reprise des enregistrements existants utilisant « equals » en corollaire…
Alors ce n’est pas activé par défaut parce que tout le monde ne s’en sert pas .
Il y a plein de manières d’utiliser des données archéologiques. Certaines instances d’Ishtar n’utilisent que l’aspect carte archéologique, certaines même seulement pour les sites et sans opérations. D’autres gèrent du mobilier et de la doc d’opérations +/- anciennes et sont bien loin d’avoir besoin des relations stratigraphique (cas typique des CCE). Il y a aussi les labo et/ou équipes de fouilles programmées qui fouillent en référençant tout en 3D (type fouille « préhistorique », mais ça peut être de la seconde guerre mondiale pour le même prix) et qui n’utilisent pas les relations strati (à tord ou à raison).
Les modules (en plus des possibilités de modification des formulaires) sont là pour permettre d’adapter Ishtar à l’usage de chacun.
Sinon pour ce qui est des types de relations :
sur ton instance les types de relations sont celles livrées à titre d’exemple. Toute instance Ishtar « neuve » démarre avec des typologies ( type de sites, d’opérations, de documents, de relations UE) mais nous n’imposons pas ces typologies.
L’administrateur de ton Ishtar ( toi peut être ? ) a la main pour modifier toutes les typologies (types d’opérations, chronologie, matériaux, type d’UE, relations entre UE …),
si tu met en place une typologie différentes ( ce serait super !) . N’hésites pas à la partager ici. Les typologies s’exportent et s’importent facilement dans Ishtar.
Sur le détail des typologies que tu proposes, je pourrais avoir des réserves, mais ne veux pas ouvrir la boîte de Pandore de ce genre de discussion archéologique🦄. Je te proposerais de poser ta typologie au complet, de la partager dans un post (dans [Normes, procédures, interopérabilité](https://discourse.ishtar-archeo.net/c/normes-procedures-interoperabilite/ par exemple)) spécifique et on en reparlera éventuellement à ce moment là ?
Sinon on est en contact avec Bruno Desachy depuis les tout début d’Ishtar (avant même que ça s’appelle Ishtar en fait ). On a déjà testé des imports / exports avec le Stratifiant (ça roule). Si on a le temps ( peu probable) ou des sous ( qui…) Il est même prévu d’inclure un module Stratifiant ( y compris avec la sériation chrono etc.).
Mais on en est encore loin et ce que nous proposons n’est pas au sens strict un diagramme stratigraphique, mais plutôt un diagramme d’état des relations stratigraphiques. Il ne prend par exemple pas en compte les datations associées au mobilier présent dans les UE ou les datations des UE elles-même afin de placer verticalement les UE (TPQ/TAQ). Par contre ce diagramme permet de mettre au clair les relations, de détecter d’éventuelles erreurs, de retravailler ensuite cela via le stratifiant ou à la main (export SVG etc.).
Pour finir les relations ça s’importe dans Ishtar. Si tu as déjà des trucs dans le Stratifiant tu peux partir de ça pour importer N relations dans Ishtar.
N’hésites pas à créer aussi des erreurs strati pour voir. Ishtar est assez utile pour raffiner des données et les relations avant utilisation du Stratifiant ou autre outil.
Le fait que les relations logiques ne soient pas remplies par défaut dans la typologie proposée par défaut est due à deux facteurs :
l’équivalence logique des relations est arrivée plus tardivement dans l’histoire d’Ishtar que les types de relations (on a enregistré les relations entre UE avant de vouloir en faire des diagrammes), et on a sans doute omis de compléter les données sur l’instance de référence qui sert de modèle pour les typologies embarquées par défaut dans Ishtar ;
pour certains termes, l’équivalence logique n’est pas évidente selon l’utilisation locale du terme (et Ishtar ne prend pas parti dans les guerres de religion archéo ;-))… On a donc souhaité laisser chaque instance faire ses équivalences en fonction des termes locaux employés et de ce qui est attendu sur les diagrammes (toutes les relations n’ont pas forcément vocation à y être représentées).
Les exemples que tu pointes en anglais sont les identifiants textuels de cette typologie. Ce sont des éléments qui servent d’identifiant unique pour les valeurs des typologies et qui peuvent être notamment utilisés dans les patrons de document (type publipostage) afin de générer des réponses différentes selon les cas (par exemple mettre une phrase au féminin selon le genre grammatical d’une organisation, ne pas afficher certaines valeurs, etc.). Tant que tu n’as pas commencé à les utiliser dans des patrons de document, tu peux les modifier, ensuite il ne faut pas.
Les identifiants textuels servent aussi à faciliter le dialogue entre instances. Chaque instance peut personnaliser le titre du type, mais si l’identifiant textuel reste le même, les instances Ishtar se comprendront plus facilement entre elles, surtout pour la nouvelle fonctionnalité de syndication des bases qui permet de consulter les données d’une base Ishtar « amie » : lors de la mise en correspondance des typologies des deux instances, les éléments avec le même identifiant textuel seront automatiquement reconnus comme identiques, limitant le nombre de correspondances à créer manuellement.
Les identifiants n’ont pas forcément à être en anglais. Les identifiants textuels de la plupart des typologies par défaut d’Ishtar avaient été créés en anglais pour prévoir un éventuel futur développement de typologies multilingues (avec identifiant unique en anglais).
Les identifiants que tu pointes présentent en outre un vieux défaut qui n’a pas été corrigé, ils utilisent le tiret bas (du 8 sur un clavier azerty) alors que la norme des identifiants textuels c’est uniquement des minuscules non accentuées et le tiret simple (du 6).
Tout d’abord, excusez moi pour cette réponse si tardive, c’était prévu, mais…
Merci en tous cas à tous les deux pour vos explications.
Mon propos n’était en effet pas de proposer une typologie (n’étant pas archéo, moi-même, je laisse aux archéos ce plaisir) , mais de proposer une correction de de traduction et une éventuelle amélioration de l’expérience utilisateur, comme on dit dans la startup nation .
Je n’ai testé que les relation sur-sous, mais je trouve le rendu déjà très réussi ! Petit exemple:
.
Je viens d’ailleurs de me rendre compte que le graphe était interactif (quand on clique sur une UE, on est en renvoyé vers sa fiche). Quelle classe décidément!
Il est possible que j’ouvre un business de pop-corn pour assister aux discussions qui suivront , mais blagues à part, je pense que le sujet est pertinent et si on peut proposer de meilleures typologies sur les installations d’Ishtar « de base », c’est toujours mieux !