Bonsoir, j'aimerais pouvoir modifier de façon massive toutes les déclarations patronage (P3872) contenant un qualificatif applies to part (P518) pointant vers Rest of the world (Q3427953) (qui est une notion sportive) et repointant vers le bon Rest of World (Q61029267). Quelqu'un pourrait m'aider ? Thanks !
Topic on Wikidata:Bistro/Archives des discussions structurées
Un exemple de problématique : Faa'a International Airport (Q1049719)Q1049719
Cette requête me semble recenser les cas problématiques :
select distinct ?item ?itemLabel ?client
WHERE
{
?item p:P3872 ?statement .
?statement ps:P3872 ?client.
?statement pq:P518 wd:Q3427953.
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO LANGUAGE],en". }
} order by ?itemLabel
J'ai rajouté quelques alias à rest of the world (Q61029267). Peut-être "non-domestic" (en anglais) est plus précis.
Le modèle me fait cligner des yeux. À mon humble avis, ça aurait été mieux de faire des déclarations sur les destinations en propriété principale et de qualifier par le nombre de passagers par ans.
Du coup, les déclarations sur le nombre de clients auraient sans ambiguïté possible portées sur le nombre total de clients indépendamment de la destination, et on se serait dispensé de « s’applique à » qui à ici pour valeur non pas une partie des passagers mais un lieu de destination desdits passagers … c’est un peu tordu.
Le modèle est peut-être un peu étrange et pourrait être amélioré (par exemple en mettant destination point (P1444) ou towards (P5051) plutôt que applies to part (P518) ?) mais globalement cela me semble logique. La proposition de mettre les mêmes types de données à deux endroits différents me semble moins logique. En plus, on n'utilise jamais destination sur un lieu comme un aéroport et quand bien même, la granularité des destinations ne correspond pas à celle du comptage à l'aéroport.
Sinon pour revenir à la question originelle, je ne connais que Wikidata-CLI (ou bien directement l'API) pour changer un qualificatif (voir plus exactement cette instruction).
L’idée ce serait plutôt un truc « propose des lignes à destination de » - qualifié par la date et la fréquentation de la ligne à cette date, éventuellement divisé par compagnie.
Les qualificateurs que tu proposes posent la question de comment exprimer « n’importe quelle destination », éventuellement ça nécessiterait de filtrer par l’abscence de ce qualificateur pour avoir la totalité. Il me parait bien plus naturel d’exprimer la totalité en mettant la valeur en déclaration principale sur l’élément, et de discriminer les valeurs par destination en qualifiant la destination, ça évite des contorsions conceptuelles pour faire rentrer des ronds dans des carrée et rend l’interrogation plus simple. Tu veux la totalité, tu prends la déclaration la plus simple, tu cherches par destination, tu cherches les qualificateurs des destinations elles-mêmes.
Dans ce cas, pourquoi ne pas juste créer des éléments sur ladite ligne ? tout comme on a des éléments sur les lignes de trains ou de bus, qui utilise les arrêts (ici les aéroports). Ainsi pas besoin de nouvelles propriétés ni même d'une nouvelle structure.
Oui, je réalise après coup que P518 convient sans doute mieux que P1444 ou P5051 (parce que ne sont pas à proprement parler des destinations mais plutôt des zones de destination).
Par contre, je ne comprends pas trop ton « faire rentrer des ronds dans des carrée et rend l’interrogation plus simple. » Pour moi, on a ici affaire à un seul type de données (donc toujours des ronds pour reprendre ton analogie) et cela me semble plus simple de mettre les mêmes données dans une même propriété.
Parce que applies to part (P518) ne convient pas du tout conceptuellement, à mon avis. Généralement on l’utilise pour déterminer de quelle partie du sujet de la déclaration on discute. Or ici il ne s’agit mais alors pas du tout d’une partie de l’aéroport, mais de quelque chose de bien différent et plus complexe. Je comprendrai par exemple si on parlait de combien de passager absorbe un des terminaux de l’aéroport, mais là on en est loin. Il s’agit d’exprimer de combien de passagers arrivent (et partent?) de telle ou telle destination. Donc on est pas du tout sur une partie de l’aéroport (le sujet), mais sur une partie des passagers (et même de leur effectif), donc plutôt de l’objet de la déclaration (et encore une « partie d’un nombre » c’est pas top conceptuellement non plus).
Rappel de la définition de « s’applique à » : « partie de l'élément concernée par l'affirmation »
Oui, P518 n'est pas l'idéal mais P1444 ou P5051 sont encore moins idéal (attention à ne pas confondre « mieux » et « bien » 
Autant je suis d'accord avec toi sur l'étrangeté du raccourci entre « partie de l'aéroport » et « partie des passagers de l'aéroport », autant je doute sur « une « partie d’un nombre » c’est pas top conceptuellement non plus ». Quel est le problème conceptuel à définir une partie d'une quantité ? (sous-entendu avec le qualificatif idéal qui reste à trouver évidemment)
Je préfère ma solution plus haut qui n’a pas besoin de qualificatif idéal - elle a besoin de moins de qualificatif - et qui en ce sens là est plus simple. Elle est de plus explicite sur le fait qu’il y ait différentes destinations possibles à partir d’un aéroport à un moment donné, ce qu’on pourrait vouloir exprimer indépendamment de l’effectif des passagers vers cette destination (si tu veux faire ça sans une telle propriété avec le schéma actuel tu te retrouve à mettre « aéroport : nombre de passager unknown value Help applies to part (P518) 
Mon sentiment c’est que ce qu’on sépare ici c’est pas le nombre, c’est les passagers. On divise les passagers en fonction de leurs destination, puis on compte l’effectif pour chaque destination. La somme est égale au total des passagers.
(conceptuellement on n’a pas trop de mal à définir une partie voire une partition d’un ensemble ou d’un espace, ou d’un objet, pour une partie d’un nombre je te laisse trouver une définition qui tient la route :) en dehors de manière un peu familière de parler, je ne crois pas qu’il existe vraiment de sens précis - par exemple une partie des employés, ça a du sens, une partie du nombre d’employés ça en a moins. On fait intuitivement le lien quand on dit informellement «L’effectif total est de 300. Seulement une partie de ce nombre est affecté à cette tâche » Il s’agit d’employés qui sont affectés à la tâche, certainement pas du nombre lui même.)
Aller, pour s’amuser un peu, il y a moyen mathématiquement de coder les nombres par des ensembles, cf. w:fr:Construction des entiers naturels : 0 = l’ensemble vide = {}; 1 = l’ensemble qui contient 0 = {{}}; 2 = l’ensemble qui contient 0 et 1 = {{}, {{}}} ; 3 = l’ensemble qui contient 0, 1 et 2 … avec la propriété intéressante que l’ensemble qui code le nombre « n » a exactement n éléments. Du coup on pourrait parler de partie d’un nombre sans soucis, au sens d’une partie d’un ensemble en tant que sous ensemble de cet ensemble. Seulement ça colle pas avec la notion de partie qu’on voudrait obtenir, on a seulement « 1 appartient à 2 », et pas « 1 est une partie de 2 » en fait ça fonctionne, contrairement à ce que je pensais, on a seulement « 2 ϵ 3 » mais aussi « 2 est inclus dans 3 » parce que 2 contient 0 et 1, et que 3 contient également 0 et 1 … Donc il y a bien effectivement une définition qui marche /o\ - avec ce codage des nombres en tout cas
Autre problème, indépendamment, en supposant qu’on parle de partie d’un nombre et que ça ne pose pas de problème: on ne parle pas vraiment d’une partie de l’objet de la déclaration. Si on a
, ce n’est pas une partie de 342 qu’on parle. C’est que ces 342 passagers sont une partie du total des passagers (à une certaine période). C’est 342 qui serait la partie du nombre total de passagers pour l’aéroport en entier … (et encore je passe sous silence le fait que ce soit à une période donnée).
Peut-être "critère utilisé" (P1013) est mieux que P518.
Wow. quel débat philosophique… ː)
Je voulais simplement charger des données de fréquentation pour les aéroports.
Les données sont souvent présentées différemment d'un aéroport à l'autre (voire parfois en n'ayant pas la même définition d'un passager, payant, gratuit, en transit, etc). Mais la trame qu'on trouve souvent est ː
- à minima un total passagers ayant usité l'aéroport telle année. Cette donnée est assez facile à trouver, du moins pour les aéroports ayant une certaine fréquentation ou faisant partie d'un système d'info structuré. Il y a parfois même discordance entre sources pour un même total et une même année.
- assez souvent, un total , un trafic international et un trafic intérieur telle année.
-parfois, des statistiques très détaillées sont dispo (trafic de telle ville à telle ville, par telle compagnie selon tel mois de l'année). Mais ce cas de figure est un peu rare et je ne souhaitais pas rendre complexe l'usage de Wikidata. Je pensais donc n'injecter que des totaux ou des totaux partiels (international+domestique=total). Pouvant aboutir à des graph intéressants comme celui-là https://fr.wikipedia.org/wiki/Aéroport_international_de_Tahiti-Faaa
Le débat semblait se positionner sur mon usage de applies to part (P518)... A un moment donné, je voulais proposer la création d'une propriété 'fréquentation annuelle' (un peu miroir de celle daily patronage (P1373) cf Wikidata:Property proposal/Transportation#Général mais ça ne semblait pas faire l'unanimité. Comment voulez vous faire ?