search

OBISCanada / nomenclature-image

Draft of naming standards to use for images
1 stars 1 forks source link

metadata, data, and scope. Oh my! #6

Open davidsean opened 1 year ago

davidsean commented 1 year ago

selon ma compréhenson, la porté d'un code par exemple: id_appareil=K1 n'est pas obligé d'être global.

L'idée est d'avoir un fichier métadonnées qui accompagnerais un jeu de données, et dans ce fichier on devrais mieux définir le système d'imagerie: 

(exemple de métadonnées de system d'imagerie)

id_appareil: K1
date achat: blah!
lieu: lab du 4 eieme
version logiciel: 2.34
fabricant: Keyence Inc
modèle: KEYS343
etc: etc

Mais un AUTRE jeu de données (par un autre groupe, pour un autre projet) POURRAIT AUSSI décider de prendre id_appareil=K1, leur métadonnées de système d'imagerie pourraient contenir:

id_appareil: K1
date achat: blah!
lieu: lab du 2 eieme
version logiciel: 2.34
fabricant: Leica Inc
modèle: DVM6
etc: etc

et ceci ne causerai pas de problèmes. ai-je bien compris @claudenozeres ?

Il serait évidement utile que certains codes, comme id_mission ai une porté globale. Donc devrions-nous définir la porté de chaque code et comment ajouter les métadonnées?

claudenozeres commented 1 year ago

@davidsean, il dépend d'usage, usagers, outils et systèmes. Par défaut, il y a souvent 2 approches différents: soit prendre le numéro séquentiel généré par l'appareil, ou crée un numéro séquentiel selon l'événement (mission). Pour les deux approches, un code-nom longue unique n'est pas obligé si aussi mis en dossiers et sous-dossiers (comme par date et ou mission). Le problème pour eux vient quand on transfère les fichiers de ces dossiers--ne seront plus unique (par ex., contient 'K1').

La raison pour une code appareil est parce que, parfois, il y a plus qu'un appareil utilisé dans 1 project (mission). Donc à prévoir les noms (préfix, suffix) pour les distinguer. Et parfois le même type, par ex. 2 fois un Olympus TG-4, fait par 2 personnes, même mission. On pourrait les distinguer par les numéros séries en métadonnées (et essayer de renommer différent).

Il n'est pas nécessaire de faire une code pour l'appareil quand :

davidsean commented 1 year ago

Pas certain que ça répond a ma question, mais ca soulève un autre point que je n'avais pas considéré (certain champs peuvent être optionnels?). Afin de mieux orienter la discussion, je vais ouvrir un autre Issue (#7 ) pour discuter de champs optionnels.

Mes questions sont:

  1. devrions nous mentionné dans l'énoncé si un champ doit-etre globallement unique ou pas ?
  2. dans le cas ou ce n'est pas globalement unique, comment on fait pour ne pas avoir de confusion?

réponse au point2: l'ajout d'un fichier de métadonnées (un par répertoire) pourrait résoudre le problème. sous-question: Devrons nous définir/standardiser comment ajouter les métadonnées

claudenozeres commented 1 year ago

1) les métadonnées seront définies selon l'utilisation, par ex., selon l'archive ou système des fichiers 2) en absence d'un système partagé (car chacun gère les données de leur projet), il est difficile, donc on essaie d'être globalement unique sans être trop lourd. Donc, pour la sous-question, oui, il y a un avantage de définir et standardiser l'ajout des métadonnées entre nous, mais il est fort probable pas compatible entre les groupes.

marieblue123 commented 1 year ago

Je pense qu'il faut d'abord définir pour qui on crée ce protocole d'identification de fichiers. Parce qu'il est difficile de se positionner ne sachant pas si on vise un seul labo ou plusieurs collaborateurs.

claudenozeres commented 1 year ago

Les métadonnées sont imposées par les archivistes (database managers) selon les besoins. Mais sont crées par les échantillonneurs en mer, selon l'activité en cours. Donc on cherche des définir entre eux.