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 <[email protected]> a écrit : > Le 31 mai 2012 11:37, <[email protected]> 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). _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
