[OSM-talk-fr] Clé pour commentaires (était "Héritage et relation")

[Philippe Verdy]

En langage informatique strict, on devrait dire "propriété" (dans
certains langages on emploie plutôt le terme "facette"). Seulement
avec "tag" on dérive le verbe "taguer".

Mais cela dépend du sens qu'on donne au mot "tag", puisque les objets
géométriques ont des propriétés implicites de base (le type d'objet
"noeud, way, ou relation" et don identifiant unique, plus des
propriétés liéés à leur historique de création énumérant les versions
avec pour chacune la propriété de son groupe de modification, lui-même
ayant des propriétés que sont les dates de création, l'état de
finalisation, l'auteurs, le commentaire de révision..), les nœuds ont
aussi des propriétés de position (actuellement uniquement en 2D et en
projection implicite WGS84), les ways des propriétés qui sont des
listes ordonnées de nœuds, et les relations des propriétés énumérées
ayant chacune en clé un numéro d'ordre, et en valeur un couple formé
par un rôle et un objet géométrique).

Toutes ces propriétés ne sont pas ce qu'on appelle des "tags" qui ne
sont que les seules propriétés simples. (on a la même ambiguité avec
"attribut" qui peut prendre un sens aussi large que "propriété", mais
moins que "facette" qui correspond davantage à ce que désigne dans OSM
les tags.

Cependant tous ces termes n'ont pas qu'une signification statique mais
aussi une signification comportementale (qui n'est pas partie du
schéma OSM) impliquant une interdépendance éventuelle entre les
valeurs positionnées ou modifiées dans une propriété et les valeurs
exposées par les autres suite à cette modification : dans OSM il n'y a
pas de telle interdépendance, chaque "tag" est totalement indépendant
des autres dans tous les objets.

Du coup le mot "marque" n'est pas plus idiot (d'autant qu'on ne peut
pas associer dans la même propriété deux objets autres que de courtes
chaines de caractères aussi bien pour la clé que pour la valeur,
contrairement aux propriétés plus générales des collections
associatives), d'où on peut dériver le verbe "marquer" (même si une
marque n'est pas en soit une association entre une étiquette et une
valeur, mais ceci n'est qu'une restriction de nommage appliquée aux
marques afin que la marque dans son entier reste unique dans un même
objet, tout en préservant l'unicité d'un préfixe dans l'ensemble des
marques du même objet).

Je pense donc que '"marque" serait une meilleure traduction. C'est
aussi court à prononcer et pas tellement plus long à écrire, tout en
étant aussi facile à dériver, et c'est sémantiquement plus exact que
"note" (un peu trop vague et pas assez contraignant), tout en restant
moins contraignant que "trait" (qui implique un aspect comportemental
et interrelationnel, contraire à ce que sont en réalités les "tags"
indépendants des objets OSM).

Une marque est apparentée aussi à une étiquette ou un label, mais ces
derniers sont un peu trop "nominatifs", et oublient un peu trop
facilement le rôle distinctif joué par la clé (parmi les "tags" ou
"marques" d'un même objet), alors que la marque suppose un
enregistrement conventionnel pour leur réserver un rôle descriptif
(les clés sont codifiées par convention, et souvent aussi leurs
valeurs, qui n'ont rien de labels ou libellés).

La bizarrerie du schéma OSM c'est non pas ces tags ou marques mais le
fait que la liste des membres d'une relation soit ordonnée, alors
qu'on devrait les voir aussi comme étant un ensemble de propriétés,
dont la clé de chacun est le "rôle", et la valeur de chacun un
ensemble non ordonné d'objets). D'autre part les relations n'admettent
pas facilement qu'on puisse référencer deux fois le même objet avec
des rôles différents (c'est possible dans la base de données, mais
JOSM tente d'empêcher de le faire, même s'il parvient très bien à
charger une relation mentionnant le même objet plusieurs fois, y
compris avec le même rôle ! Car de fait ce n'est pas le rôle mais le
rang numérique implicite dans la liste des membres qui sert de clé,
une aberration qui ne sert à rien et surcharge la base de données pour
rien du tout d'utile, car ce rang prend bel et bien de la place dans
les index et ralentit les accès à cause des contraintes d'intégrité
lors de l'insertion des données, et du tri soit lors de
l'interrogation de la base dans chaque requête soit du stockage dans
un index).

Cette bizarrerie pourrait être éliminée en rendant non ordonnés les
membres des relations : on gagnerait en volume et en rapidité
d'interrogation et mise à jour de la base (à charge plus tard pour
l'utilisateur de l'objet de voir quel tri appliquer à ce qui est
pertinent parmi les membres qui l'intéressent (essentiellement ceux
ayant le bon rôle, quel que soit leur type géométrique) : ce serait
alors le rôle qui serait la clé discriminante, et qui permet donc de
voir alors les objets comme ayant des :
- propriétés simples : les "tags" ou "marques", pour attribuer aux
objets des valeurs simples indexées par la chaîne "clé" de chaque
tag/marque
- propriétés complexes : les "membres", pour leur attribuer aux objets
des valeurs géométriques (simples ou multiples) indexées par la chaîne
"clé" de chaque rôle.


Le 31 mai 2012 12:39, Ista Pouss <istaous at gmail.com> a écrit :
> Le 31 mai 2012 11:37, <teuxe at free.fr> a écrit :
>> Au passage, un "tag" c'est une clé (key) avec une valeur (value). On n'a
>> pas trouvé de traduction française pour tag :) mais j'aurais bien proposé le
>> terme de "propriété", étant perplexe sur le sens exact du mot "attribut".
>
> Il y a aussi "marque", "étiquette", "note", "trait", et plein d'autres plus
> poétiques ("griffe") ; on voit aussi quelque fois "label", mais ça fait
> contresens je trouve.
>
> Le problème est surtout que "tag" est 50 fois plus rapide à écrire, à part
> "note", peut être (mais le problème avec "note" est que c'est souvent déjà
> un... tag).