Sémantisation dans Panoramax... brainstormons!

Panoramax : photo-cartographions les territoires
,
21

Je confirme qu’on ne peut pas mettre de valeur nulle dans une clé primaire composée :

psql (16.3)
db=# create table bla(a int, b int[], c varchar, primary key(a,b,c));
CREATE TABLE
db=# insert into bla values(10, null, 'test');
ERREUR:  une valeur NULL viole la contrainte NOT NULL de la colonne « b » dans la relation « bla »
DÉTAIL : La ligne en échec contient (10, null, test).

Et d’ailleurs le type box que je pensais utiliser ne peut pas faire partie de la clé primaire non plus, pas de classe d’opérateur pour accès btree me dit-il.

Et pour l’endpoint SPARQL, ça pourrait en effet être un service offert à la fédération par le métacatalogue, comme les stats & co.

22

C’est volontaire d’interdire d’avoir plusieurs fois la même clé? Ca me semble pourtant utile dans de nombreux cas (plusieurs mots-dièse, lien vers plusieurs éléments wikidata/osm, …)

23

Bonsoir,

J’ai l’impression qu’il y a ici un mélange de termes qui ont des sens différents.
Un objet unique pour être trouvable doit avoir un “identifiant” unique. Ensuite dans des bases de données il faut lier cet “identifiant” à tous les attributs qui s’y rattachent.

Pour moi le terme clé correspond à ce que j’ai précédemment nommé “identifiant unique”.
Les hashtags, liens correspondent aux attributs.
Il me parait donc possible d’associer plusieurs attributs à un même objet. Cet objet est identifiable par son identifiant.

Après il y a les aspects techniques de comment est créé l’identifiant et comment sont rattachés les attributs.

24

Ma compréhension était que pour l’attribut wikidata=Qxxx sur la photo 42, était représenté par id=42 key=wikidata value=Qxxx.
Et si l’on souhaite attacher à la même photo deux attributs avec la même clé, par exemple wikidata=Q42 et wikidata=Q56, la clé primaire (id,key) l’empêche.

25

Hum, je serais plutôt d’accord avec @cquest , j’ai l’impression qu’on peut séparer la partie annotation de la partie requêtes, et particulièrement SPARQL, qui peut être déportée dans un autre outil, une fois qu’on expose les annotations non ?

Quelques remarques :

unicité

Je suis aligné avec @tdelmas , je n’ai pas l’impression qu’on veuille une unicité objet/tag (ou subject/predicate dans la nomenclature RDF), j’ai l’impression que c’est valable d’associer 2 objects osm à une photo, plusieurs entités wikidata, ou plusieurs hashtags libres (du coup qu’on pourrait définir comme le propose @overflorian en hashtag=Paris2024).

Zone définie dans l’image

Vous pensez qu’une bbox est suffisante ? Dans la majorité des cas, je pense que oui, mais est ce qu’on ne voudra pas définir des zones précises, surtout si on veut utiliser des modèles de segmentation comme Segment Anything ? Si oui, il faut peut-être stocker ca sous forme de GEOMETRY pour pouvoir gérer des bbox ou des formes plus complexes au besoin ?

Modèle de données

Si on fait sauter la contrainte d’unicité, on peut tout mettre dans une même table non ? (enfin 2, une pour les images, une pour les séquences).

RDF

Ca me fait assez peur la partie très standardisée RDF/OWL/…

Aprés, est ce qu’on pourrait avoir une approche un peu hybride, avec des tags non structurés et de la doc et des outils pour utiliser quand c’est possible des prédicats définis par les différents standards (+ des prefix comme dit par @PanierAvide pour que ca soit moins imbitable) ?

Par contre, pour faire rentrer le fait de décrire une partie d’une image avec un triplet, je ne vois pas comment on peut faire sans une indirection en rajoutant un sujet:

Un truc du genre (sans avoir regardé les prédicats existants pour ca):

  • picture:another_id - has_annotation - annotation:an_id (ou alors dans l’autre sens pour dire que l’annotation porte sur la photo)
  • annotation:an_id - geo:hasGeometry - une geometrie
  • Puis rajouter des prédicats sur cette annotation.

Ca fait tout de suite un truc compliqué :sweat_smile:

Après l’avantage, c’est que ça ouvre la possibilité de lier une annotation à d’autres choses (wikipedia, osm, voir une annotation d’une autre photo pour dire que c’est la même chose).

Cette modélisation implique de rajouter une clé aux tables pictures_semantics/sequences_semantics.

Conclusion

Comme dit au début, j’ai l’impression qu’il faut qu’on garde un modèle un peu simple en bdd + en API d’alimentation et qu’un jour on fera une transformation vers du RDF pour un autre outil (en s’assurant dès maintenant que la modélisation le permet).

2 Likes
26

De mon côté j’aimerais proposer des pistes

  1. sur le pourquoi d’usages sémantiques :
  • le contexte : une photo peut-être prise au bord du Rhône mais lors d’un débordement le contexte (inondation) est la culture du risque avec les aménagements et sécurisations nécessaires
  • peut-être qu’une base adresse serait bienvenue pour rattacher les photos qui prennent de façon explicite des façades de monuments
  • le profil du contributeur : un contributeur dans une collectivité peut avoir plusieurs profils : contributions touristiques, expertes, adressage (noms de résidences)
  • la qualité : certaines photos isolées ou dans une séquence, peuvent avoir les qualités requises pour être republiées de plein de manière, en cela un système de notation serait bienvenu
  • le contenu : à l’intérieur d’une photo tout n’apparaît pas forcément de façon évidente et une annotation sémantique peut s’avérer utile autant pour documenter la dégradation d’un équipement que la mutation du commerce ou encore la réalisation d’une construction
  1. sur le comment utiliser un système sémantique aux photos panoramax :
  • permettre une mise en miroir de la maturité du système clé-valeur d’OSM
  • permettre une utilisation universelle grâce aux URI polyglottes et aux précisions conceptuelle de wikidata
  • en s’appuyant sur l’architecture d’archivage et documentaire du système IPTC
  1. sur le avec les usages sémantiques :
  • je suis convaincu que se posera le sujet à terme d’un bout de xml issu d’OSM pour permettre d’associer à la photo la version d’OSM qui correspondait à la prise de vue (ou une solution équivalente renvoyant sur un historique de la version d’OSM)
27

Pour ne parler que de la forme des métadonnées, est-ce qu’on pourrait partir sur un système du genre :

On permet l’association de clés/valeurs ouvertes à :

  • une séquence
  • une image
  • un bout d’image (une image + une forme géométrique, potentiellement limité à une bbox au début)

Note: l’idée est d’ajouter des tags non disponibles dans les tags exif, du coup il ne faut pas mettre d’info sur le modèle de caméra, la date, la ville…

Des contraintes sur ces clés valeurs très limitées, on pourrait accepter 256 caractères pour la clé et ~2000 pour la valeur, (et Unicode pour être joueurs ?).

Afin, entre autres, de gérer le cas d’usage de simples hashtags, on pourrait avoir plusieurs clés identiques dans la liste.

Une fois qu’on se sera mis d’accord sur le cadre, il faudra aussi discuter de la forme des clé-valeurs, et comment on les structure.

28

Sur la caméra je suis d’accord, pour la date ou la ville, on peut envisager que l’exploitation de l’horodatage ou de la géolocalisation puisse être traduite en quelque chose de plus facile à exploiter par exemple déterminer la saison, la hauteur du soleil dans le ciel, le fait d’être dans une zone urbaine ou au milieu des champs ou de la forêt…

Ce sont des informations dérivées de données EXIF, qui sont riches et peuvent être plus utiles et exploitables surtout pour sélectionner des images.

Sur les tailles maxi des clés et valeurs, ça me semble bien élevé, surtout si on peut avoir des clés non uniques.

29

Pour les valeurs, si on envisage des urls, 256 est un peu juste. 2000 semble raisonnable.

Pour le projet OSM, la valeur 256 semble être trop juste dans certains cas: Increase may key and value max length · Issue #2025 · openstreetmap/openstreetmap-website · GitHub

30

C’est le plus souvent à cause des valeurs multiples.

31

Bonjour,
Voici une proposition que j’ai poussée dans GitLab sur des catégorisations d’annotation, pouvez-vous en prendre connaissance et donner des retours techniques en terme d’API ?

32

Bonjour !

La vidéo de présentation du sujet au SOTM-FR ayant été rapidement en ligne, j’ai pu prendre connaissance du travail réalisé jusque là.
Rien à dire, c’est une belle vision et un vrai différenciant.

Sur le plan technique, à la suite de cette discussion, un détail : le choix du vocabulaire pour l’implémentation. Au lieu de semantics j’aurais préféré tags puisque c’est ainsi que les couples clé/valeur sont appelés dans OSM.
Et ainsi les tags sont utilisés dans des annotations sur les photos.
C’est aussi plus court. A voir si cela vaut le coup de considérer cette possibilité avant que l’API soit trop utilisé.

Bonne journée

1 Like
33

Bonjour François, merci du retour. On a bien pensé au terme tags, mais comme on a aussi les tags EXIF, on voulait éviter la confusion :

  • Tags EXIF : modifiable que dans certaines conditions, respecte la logique de notation de Exiv2
  • Sémantique Panoramax : modifiable par tout le monde, avec le modèle ouvert présenté (mais pas contraint)

Ça veut pas dire qu’il ne faut pas changer le terme, mais juste trouver une façon de clarifier que ce n’est pas des tags EXIF :wink:

34

Point intéressant, et je ne crois pas l’avoir vu dans la vidéo : pourquoi ne pas mettre les tags exif sous la même forme avec exif|blabla=valeur ?
Ainsi, il serait possible d’appliquer des règles d’édition comme celle que tu mentionnes sur les exif à l’ensemble des attributs.

Sinon je n’ai pas de meilleure proposition qui vaille la peine de faire la modification à présent.

35

C’est pour la rétrocompatibilité, comme les tags EXIF sont déjà exposés dans les réponses actuelles, les déplacer dans la partie sémantique casserait toutes les intégrations (y compris la visionneuse qui va lire certains d’entre eux). Même si on est d’accord que ce serait plus logique en termes de présentation :grin:

36

Si on est d’accord sur le principe, cela doit pouvoir se faire avec une période de transition.

Sans avoir étudié la question, il serait peut-être possible de supporter deux objets différents sous le concept de tags : les exifs legacy et les nouveaux attributs (dont les exifs au nouveau format), pour permettre la transition.
Dans quelques versions il sera possible de supprimer les exifs à l’ancien format et le concept de semantics n’aura pas prospéré.

Ou même plus simplement avec du versionnage dans les routes de l’API.

A mûrir mais ce serait dommage de renforcer la cloison entre les deux en tout cas.

37

Il ne faut pas oublier les réutilisations possibles par des outils qui ne comprennent que les exif standards. Par exemple, Josm considérerait que les photos ne sont pas géolocalisées.

Et conserver les infos dans 2 catalogues différents, c’est s’exposer à des conflits si un outil ne modifie que l’un ou l’autre.

38

A mon avis on parle de deux choses différentes :

  • Je parle de la terminologie interne, dans la base de données et certaines réponses API (spécifique à Panoramax donc)
  • Tu dois parler des exifs intégrés aux fichiers image, lu notamment par JOSM (normés dans les format image et apparentés)

A moins que je n’ai pas compris que l’ensemble des tags exifs et des attributs sémantiques présentés soient aussi joints dans les fichiers images eux-même ?

39

Tu fais bien d’en parler, car j’ai compris que ces attributs étaient bien entendu en base, mais aussi sous forme de tags dans un catalogue XMP intégré à la photo. Ça s’arrête bien entendu aux attributs des photos, et met de côté ceux propres à une séquence.

40

Est-ce que les méta-données XMP des photos conditionnent les choix de vocabulaire dans le reste du projet @PanierAvide ?