Wikidata talk:WikiProject France

From Wikidata
Jump to navigation Jump to search

Langue du projet[edit]

Je sais que le projet France sera sans doute peuplé de francophone, mais je voudrais attirer l'attention que ce projet sera un point de ralliement pour des personnes externes au monde francophones, donc il faudrait que la page principale ainsi que les principales informations sont traduites en anglais. Snipre (talk) 14:27, 1 April 2014 (UTC)

Tout à fait ! Après, l'idéal serait d'utiliser l'extension/balise translate (comme pour les pages d'aide, eg. Help:Contents) mais je connais encore assez mal le fonctionnement précis de cette extension. Après, ce n'est pas juste linguistique, il y a aussi une certaine harmonisation des données à faire avec les autres pays (dans la mesure du possible évidemment). Cdlt, VIGNERON (talk) 14:44, 1 April 2014 (UTC)

Tentative de wikidataisation du mille-feuille administratif français[edit]

Bonjour,

Je lance une première « tentative de wikidataisation du mille-feuille administratif français ». Je suis plus spécialiste de l'administration et du territoire français que de la gestion de base de données, je laisse donc soin à d'autres de corriger et mettre en forme mon premier jet. J'ai mis quelques questions pour certains éléments.

Tout d'abord, les 4 collectivités territoriales (Q583865) :

  • La commune (commune of France (Q484170)) est l'unité de base du territoire français. Tout le territoire français est divisé en commune (mis à part quelques exceptions comme d'une part les îles de Saint-Barthélemy et Saint-Martin − pseudo-commune − et d'autre part Wallis-et-Futuna et les TAAF, Terres australes et antarctiques françaises pas de communes du tout).
    • La commune possède de nombreux caractéristiques plus ou moins homogènes donc un grand nombre se trouve dans la base du Répertoire Géographique des Communes RGC : un nom (officialisé par le COG, pas de propriété), une population (données INSEE), une surface, une altitude min/max, un chef-lieu − là encore il y a quelques exceptions où le chef-lieu de la commune ne se trouve pas sur le territoire de la commune − (ce qui peut poser des problèmes pour la coordonnée de localisation de la commune car le RGC géolocalise le chef-lieu de la commune et non la commune elle-même, eg. Demi-Quartier (Q841329), Taillepied (Q742531) ou Château-Chinon (Campagne) (Q665691)), éventuellement un découpage (en quartiers, sous-quartiers, voire en canton pour les grandes agglomérations et en arrondissements municipaux pour Paris-Lyon-Marseille ou des divisions plus exotiques comme les sections électorales), etc.
    • C'est également une circonscription électorale qui élit un conseil municipal (élisant lui-même un maire et un ou plusieurs adjoints et servant éventuellement à des référendums municipaux).
    • Du coup, selon quel référentiel, la commune française est-elle une fifth-level administrative country subdivision (Q15640612) comme ajouté sans source ni référence par Arctic.gnome (talkcontribslogs) ? Dans le RGC, une « simple » commune est de « statut administratif 6 » (mais ce ne sont pas des niveaux à proprement parler) et légalement, c'est plutôt le premier niveau (mais en comptant en sens inverse du coup).
  • Le département (departments of France (Q6465)), au nombre actuel de 101, groupement de communes, dispose d'un Conseil général (assemblée, président, administration, etc.) et d'un préfet/préfecture, est divisé en un ou plusieurs arrondissements départementaux (qui correspondant aux sous-préfectures, les départements de Paris et de Belfort n'ont qu'un arrondissement).
  • La région (region of France (Q36784)), au nombre actuel de 27, groupement de départements, dispose d'un Conseil régional (assemblée, président, administration, etc.) et d'un préfet/préfecture.
    • Attention à la Corse qui est une région « étendue » juridiquement (pas de Conseil régional mais un Conseil exécutif et une assemblée).
    • Ibidem pour no label (Q13220202) (information ajoutée par Infovarius (talkcontribslogs)). Deuxième niveau selon NUTS.
  • les autres collectivités territoriales (collectivités à statut particulier − Paris, Lyon, Marseille, Nouvelle-Calédonie, Corse, etc. − et les 5 collectivités d'outre-mer COM remplaçant certains des TOM, aujourd'hui seuls les TAAF sont encore un TOM, et encore…).

Après, il existe de nombreuses divisions, notamment :

  • les diverses circonscriptions électorales (dont la commune et anciennement le département)
    • le canton, généralement regroupement de communes sauf pour les grandes agglomérations qui sont découpées en cantons, actuellement en réforme (dont on connait déjà les futures frontières, à priori en vigueur à partir de 2015). Du coup, le fait d'être subcommunale ou supracommunale selon le contexte est assez perturbant (heureusement que les cantons « ne servent pas à grand’chose »...). Le canton dispose d'un nom, d’un chef-lieu, des données INSEE (globalement les mêmes qu'au niveau communal), etc.
    • la circonscription législative (pour les élections des députés), plus ou moins des groupement de cantons (canton actuelle, je ne sais pas trop avec la future/actuelle réforme) mais pas uniquement
    • la circonscription sénatoriale (pour les élections des sénateurs), correspond aux départements mais pas uniquement
    • les 8 circonscriptions aux élections européennes (pour les élections des députés européens), regroupement de régions
  • les très diverses structures intercommunales : métropole, communauté urbaine, communauté d'agglomération, communauté de communes, syndicat (syndicat intercommunal et syndicat mixte) ; sous la forme juridique d'établissement public de coopération intercommunale (sauf pour les syndicats qui sont juridiquement des syndicats).
  • les pays « administratifs » (dit Loi Voynet, Pays (Q3184003)), groupement des nombreuses communes, diverses formes juridiques (syndicat mixte de pays, association, groupement d'intérêt public)
  • des territoires spécifiques plus ou moins thématiques
    • les 3 préfectures maritimes
    • les territoires de gestion de la l'eau (les 5 agences de l'eau, les syndicats de bassins, SAGE, SDAGE, etc.)
    • tout un tas d'autres territoires (par exemple en urbanisme, les périmètres des schémas de cohérence territoriale, SCoT qui correspondent parfois à des entités existants mais pas toujours)
  • les divisions historiques (paroisse, district, provinces, sénéchaussée, généralité, bailliage, duché, comté, marquisat, baronnie, ressort, etc.)

Cdlt, VIGNERON (talk)

Bon, si je regarde l’organigramme déjà affiché, il faudrait remplacer les located in the administrative territorial entity (P131) des communes (qui donne actuellement vers les cantons) et de remplacer le lien par celui des arrondissements. Et d'utiliser no label (P1134) pour tout le reste des truc à laquelle la commune fait partie (communauté de commune, circonscription, etc. ). --Fralambert (talk) 21:18, 12 April 2014 (UTC)
Merci pour le résumé. A propos de second-level administrative country subdivision (Q13220204) : Je ne crois pas que ce soit sensé correspondre aux divisions de NUTS (qui n'ont souvent pas d'existence administratives. Ca me parait en fait plus ou moins un invention de Wikipédiens un peu trop confiants dans les possibilités de faire un système international cohérent, selon lequel chaque pays serait divisé en premier niveau, deuxième niveau etc. (voir notamment en:Category:First-level administrative country subdivisions). Il me semble que ça ne fonctionne pas du tout et qu'on devrait simplement se débarrasser de tout ça. --Zolo (talk) 05:58, 13 April 2014 (UTC)
Merci pour la création de ce projet, c'est quelque chose qui me trainait dans la tête depuis un petit moment, notamment pour avoir où discuter d'un consensus sur la modélisation de notre bon vieux mille-feuilles administratif.
Quelques remarques:
1/ Ce n'est pas très clair dans la proposition de VIGNERON si l'arrondissement est inclus dans la hiérarchie ou non.
2/ Utiliser no label (P1134) est une proposition intéressante, mais il ne résout pas le problème que dans beaucoup de cas, les cantons (et autres) sont inclus dans une commune, voir à cheval sur plusieurs. Je pense qu'on aurait besoin d'une propriété du genre "division administrative associée", qui pourrait être utilisée de façon plus flexible.
3/ Une autre discussion à avoir est sur l'utilisation de la propriété shares border with (P47) au niveau des frontières. Celles que j'ai tentées d'initier au niveau globale n'ont rien donnée. Je pense qu'on devrait avoir un consensus local avant tout.
4/ Est-ce que quelqu'un participe ou a contacté le projet Communes de France sur WikiFR ? Ça serait bien que la stratégie adoptée ici soit compatible avec l'automatisation de leurs infoboxes.
5/ Je propose que tout consensus soit approuvé par un vote, pour qu'on puisse ensuite l'opposer à des contributeurs qui voudrait faire à leur façon.
A+ --LBE (talk) 10:41, 13 April 2014 (UTC)
@Zolo : visiblement ce n'est pas une division NUTS et effectivement, à moins d'avoir une source, je serais plutôt d'avis de les retirer. Pour NUTS, aussi critiquable et critiqué soit-il, au moins c'est sourcé et documenté. Cela recoupe assez souvent des entités existantes (en tout cas en France et sauf erreur, les niveaux 2 et 3 correspondent aux régions et aux départements). Puisque l'on parle de codage, il existe aussi la norme ISO 3166 ainsi que les codes INSEE pour les régions/arrondissements/cantons (pas sur que ce soit vraiment utile mais sait-on jamais…).
1/ Ce qui est clair est que l'arrondissement départemental est une subdivision du département et que ce ne sont pas des collectivités territoriales. Personnellement, je dirais que ce n'est pas vraiment un échelon entre le département et la commune (ou bien canton ? ce doute même me semble révélateur) ; de plus, les arrondissements départementaux sont globalement inconnus en France (on avait eu le problème pour la création de liste de MH par arrondissement sur fr.wp, il n'est pas du tout immédiat de savoir dans quel arrondissement se trouve une commune).
2/ Je ne sais pas trop quelle est la meilleure façon mais effectivement un canton peut être composé :
  • d'un groupement de communes (nombre entier de communes appartenant au canton de 1 à X, la moyenne pour les cantons actuellement en vigueur est de 9)
  • de fraction d'une commune (nombre compris entre 0 et 1)
  • de fractions de plusieurs communes (nombres compris entre 0 et 1 pour chaque communes)
De plus, le département-commune de Paris n'est pas divisé en cantons. Enfin, les cantons ont pas mal évolués à travers l'histoire et sont actuellement en cours de réformes (avec pas mal de protestations donc les futurs cantons dont la composition a été publiée au JORF sera peut-être amené à évoluer d'ici leur date d'entrée en vigueur ce qui va être difficile à modéliser même avec des qualificateurs).
4/ Oui, le projet Communes de France a été contacté (merci Snipre (talkcontribslogs)) et il y a même plusieurs discussions en cours là-bas (notamment sur le formatage des données de populations).
5/ Je ne suis pas trop chaud par un vote, pas maintenant en tout cas ; il faut tester minutieusement et valider par la pratique d'abord. Je pense qu'il serait plutôt opportun de le faire sur quelque chose de globale (personnellement, il me semble qu'il n'y a rien de pire qu'un consensus sur un détail qui se révèle impossible à appliquer avec des usages généraux).
Cdlt, VIGNERON (talk) 18:37, 13 April 2014 (UTC)
Il faut commencer par séparer les familles: il y a les divisions administratives et les divisions électorales. A première vue le canton appartient à la deuxième famille. Snipre (talk) 09:08, 14 April 2014 (UTC)
Note : les "niveaux NUTS" ne sont pas les niveaux administratifs, ce sont seulement des niveaux statistiques propres à NUTS (puisque le niveau 1 de NUTS n'a jamais correspondu à rien administrativement en France, il correspond juste aux anciennes ZEAT qui n'ont jamais eu un rôle admoinistratif, et d'ailleurs les NUTS1 français ne correspondent plus au regroupement des régions mais ne sont plus que des regroupements d'anciennes régions, en attendant une éventuelle mise à jour de NUTS tenant compte des nouvelles régions administratives françaises, mais qui n'a pas encore eu lieu). NUTS aussi ajoute des pseudos-divisions comme les EX REGIO, et il ne couvre pas non plus l'ensemble du territoire français, juste le sous-ensemble territorial inclus dans le champ d'application des traités européens.
Bref ne pas tenir compte du niveau NUTS pour "division territoriale de premier niveau" et suivants, car ils sont tous décalés statistiquement (et incomplets pour la France). Verdy p (talk) 14:17, 28 February 2016 (UTC)

Receil de Queries utiles pour vérification[edit]

J'ai sur ma page perso toute une série de WikiData Queries très utiles pour des vérifications de cohérence et complétude d'item liés à la France. Ça me fait une bonne source de TODO au quotidien. Beaucoup sont reproductibles pour d'autres villes/régions. Je pense qu'elles sont utiles pour ce projet

Est-ce que vous êtes d'accord pour créer une page "Rapport" dans ce projet, où je pourrais les mettre (et chacun pourrait en rajouter) ?

A+, --LBE (talk) 10:48, 13 April 2014 (UTC)

Carrément, cela sera très utile (on pourrait en plus, y mettre pour mémoire les cas spéciaux que j'ai évoqué plus haut). Thanxs. VIGNERON (talk) 17:50, 13 April 2014 (UTC)

Import massif des adjacences entre communes[edit]

Re-re-salut,

Ce projet m'a aussi fait faire ce que je procrastinais depuis un bout de temps : aller demander de l'aide à nos amis d'Open Streetmap pour connaitre la valeur de shares border with (P47).

La réponse a été même plus efficace que prévue, et nous avons maintenant un fichier qui les donne toutes : ici. Ce sont des paires de code INSEE, les communes isolées (iles) ont une seule valeur sur leur ligne et chaque adjacence n'est présente qu'une fois (il faudra donc dupliquer chaque ligne).

Je ne suis pas dresseur de bot. Il y a un volontaire pour s'en charger ?

--LBE (talk) 15:22, 13 April 2014 (UTC)

Avant de les injecter dans Wikidata, serait-il possible de les comparer aux valeurs dans les articles sur Wikipédia (pas forcément fiable à 100 %, je passe d'ailleurs pas mal de temps à les corriger mais le croisement serait toujours intéressant). Cdlt, VIGNERON (talk) 17:53, 13 April 2014 (UTC)
Le projet OSM Fr vient de terminer un alignement global des frontières communales sur le cadastre français. Ça leur a pris 6 ans. J'aurais donc tendance à faire confiance à leur données, plus qu'à celles de Wikipédia. Cela dit, si le bot peut signaler les différences avec ce qui existe déjà dans Wikidata (et Wikipédia), ça sera toujours mieux. --LBE (talk) 21:00, 13 April 2014 (UTC)
Je viens d'y re-réfléchir, quelqu'un pourrait-il commencer par faire un fichier à partir de Wikipédia ainsi que du fichier GEOFLA du RGC (ce ne serait pas les données Wikipédia/RGC elle-même mais un calcul à partir des données donc pas de problème de licences sur ce coup-là) pour pouvoir comparer ? En parcourant rapidement le document de Chritian Quest, je remarque quelque lignes étranges, il y a des codes isolés qui ne correspondent pas à des communes isolées (notamment pour La Réunion 974). On pourrait ainsi au moins importer les cas cohérents dans les trois cas. Cdlt, VIGNERON (talk) 08:36, 11 December 2014 (UTC)
En fait, ce fichier contient la liste des lignes de contours de communes sur OSM, avec les ID de commune de chaque côté. Pour les lignes qui n'ont qu'une commune (frontière internationale, mer), il n'y a qu'un ID. --LBE (talk) 13:30, 11 December 2014 (UTC)
Ah oh… subtil ! Je croyais que c'était la liste des communes limitrophes d'autres communes. Je n'avais pas compris que quand le contour touchait autre chose qu'une commune, c'était indiqué par une ligne « vide ». Après coup pourtant cela semble super évident. Du coup, je me pose la question comment gère-t-on ces cas sur Wikidata ? Pour une île, au départ, je pensais juste mettre un « aucune valeur », eg. pour Île-de-Bréhat (Q272373). C'est logique si on suit la description de shares border with (P47) « pays ou division administrative de même niveau partageant une frontière commune » (description qui a déjà suscité de nombreuses discussions) mais dans l'absolu cela signifie que l'on oublie une partie de l'information.
Bon après, cela concerne une minorité de cas, pour le reste peut-on avancer ou bien ?
Cdlt, VIGNERON (talk) 13:58, 11 December 2014 (UTC)
Effectivement, la contrainte de symétrie de shares border with (P47) n'est pas très pratique, et la règle "de même niveau" n'est pas très claire. Et de facto, tout le monde fait un peu ce qu'il veut. Certains mettent "voisin de l'océan atlantique", d'autre "voisin de l'Allemagne", d'autre encore "voisin d'une commune allemande" (est-ce bien le même niveau ?) ...
J'avais levé le pb sur la PDD de shares border with (P47) il y a longtemps, avec des propositions. Mais sur ce genre de sujet, impossible de discuter d'un consensus, et encore moins de le faire appliquer.
Pour mémoire : il faudrait rendre la symétrie optionelle, avec un qualificatif qui l'indique. Comme ça, on évite la propagation des stratégies utilisées ici ou là. Esuite, il faudrait que chaque sous projet (comme celui-ci) définisse ses propres règles, applicables à un scope donné (ici, les éléments relatifs à la France) : que faire pour des adjacences avec l'océan (rien, une adjacence) ? que faire sur les frontières (rien, pays, structure de niveau équivalent) ? Ensuite vote public pour que ça devienne opposable à tout contributeur (nouveau ou non informé), et implémentation systématique avec rapport de checks. --LBE (talk) 10:08, 12 December 2014 (UTC)
Pour les adjacences, il serait bien de les compléter avec un qualificateur indiquant la direction géographique (un des 8 points cardinaux ou intercardinaux), ce qui permettrait de remplir automatiquement ensuite les modèles des pages Wikipédia qui mentionnent les entités limitrophes.
Le problème : quelle entité limitrophe choisir ? Il y en a a plusieurs niveaux, qui ne sont même pas tous des subdivisions directes de la même subdivision parente de l'entité courante.
Il me semble que si on doit choisir, ce devrait être la plus petite division limitrophe dont le parent direct contient (directement ou pas) les deux entités mais ne contient pas l'entité courante (ce parent direct peut être le Monde dans ce cas la plus petite division limitrophe est un pays). Dans le cas où il y en a encore plusieurs, prendre celle de même type ou de la classe parente commune la plus proche.
Si une entité limitrophe est dans un autre pays, la subdivision limitrophe pertinente à indiquer est ce pays, et non une des ses régions, Etats, province, commune ou autre, dont le statut n'est pas comparable à l'entité courante. D'ailleurs même si on essaye de chercher une division administrative de "même niveau" administratif, cette recherche peut échouer car elle n'existe pas forcément à ce niveau !
Même en France métropolotaine, une commune d'un département limitrophe de la circonscription départementale du Rhône ne devrait mentionner comme limitrophe que cette circonscription et pas le nouveau département du Rhône ou la nouvelle métropole de Lyon ou une de leurs communes.
Cette règle induit une plus grande stabilité et une prédictibilité du schéma et sa complétude: elle évite de s'intéresser aux découpages ou regroupements internes des entités voisines, qui peut changer indépendamment.
Appliquée à un EPCI à fiscalité propre, cette règle donnera un autre EPCI à fiscalité propre (dont le parent direct est la France, puisque les EPCI à fiscalité propre ne sont pas des subdivisions d'une région, d'un département, d'un arrondissement), ou alors une commune sans EPCI à fiscalité propre.
Concernant les autres EPCI (SIVU, SIVOM, EPT, etc.), on ne trouvera que des communes isolées ou d'autres EPCI de même type (exemple: un EPT de la métropole du Grand Paris aura comme entités limitrophes que la ville de Paris, ou un autre EPT, ou une commune hors de cette métropole), voire un arrondissement, un département ou une région qui ne contiendrait aucune partie de l'entité courante (choisir la plus petite dont un parent contient entièrement l'entité courante). Verdy p (talk) 19:58, 26 February 2016 (UTC)

@LBE, Verdy p: ce sujet traîne depuis près de deux ans, j'ai décidé de faire quelque chose. Après quelques vérifications sur des échantillons pris au hasard où je n'ai pas vu d'erreurs, je viens d'importer la majorité des données du fichier de Chritian Quest. Globalement, la structure est triviale vu qu'il y a uniquement des communes (donc forcément du même niveau communal, cela exclut et résout cette question de niveau). J'ai tout de même exclu quelques cas : les frontières avec rien et les codes INSEE partagés par plusieurs communes.
Un exemple de visualisation du résultat pour les communes de l'Ain.
Pour aller plus loin, il faudrait :
  • vérifier les données
    • mais je n'ai pas trop d'idée de vérification ; pour les vérifications avec des données externes, à part le fichier de Christian, il n'existe pas de source à ma connaissance ; pour les vérifications internes, il me faudrait les cas limites : commune ayant le plus grand nombre de communes limitrophes (j'ai trouvé Lille (Q648) avec 18 communes limitrophes, serait-ce le record ?), commune limitrophe dont les chef-lieux sont les plus éloignés (il y a le cas évident et extrême des communes de Guyane mais quid des communes de France Métropolitaine ? et surtout comment formuler la requête de vérification ?), etc.
  • enrichir les données avec des qualificatifs :
    • trivialement, start time (P580) et end time (P582), important en particulier pour les communes crées après 1789 et toutes celles ayant disparus.
    • par exemple la direction géographique mais d'une part, quelle propriété utiliser ? d'autre part, comment obtenir cette donnée ? (le calcul n'est pas trivial, et il y a un certain nombres de communes au territoire non-contigu ce qui complique encore plus la chose).
      • le qualificatif "direction géographique" existe, avec les valeurs énumérées des 8 points cartinaux et intercalaires (les 16 demi-intercalaires existent aussi). Tous les points cardinaux ont une propriété donnant leur angle relatif en degrés par rapport au nord (mesuré dans le sens horaire comme cela est fait en géographie et sur les compas), ce qui facilitera le tri.
      • il permettrait de remplir automatiquement les box dans les bons paramètres, et de les ordonner correctement. Sinon on obtient une liste non triée. Verdy p (talk) 06:45, 27 April 2016 (UTC)
    • dans l'idéal il faudrait ajouter des sources (mais idem supra sur l'absence de source).
J'en ai profité pour faire quelques vérifications en plus de mon import. J'ai notamment 17 déclarations de communes limitrophes de pages d'homonymie. Sinon, pour revenir à la condition de « même niveau », il y a assez peu de communes reliées à des éléments qui ne sont pas des commune of France (Q484170), il y a seulement éléments-communes et 50 valeurs différentes dont pas mal de communes d'autres pays : comune of Italy (Q747074) 77 fois, municipality of Belgium (Q493522) 38 fois, municipality of Switzerland (Q70208) 14 fois, etc. Résultats complets :
SELECT ?class ?classLabel ?count WHERE {
  {
    SELECT ?class (COUNT(*) AS ?count) WHERE {
       ?a wdt:P31 wd:Q484170 .
       ?b wdt:P31 ?class .
       ?a wdt:P47 ?b .
    } GROUP BY ?class
  } . 
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" . }
}
ORDER BY DESC(?count) ?classLabel
Try it!
Certains chiffres sont un peu trompeurs car un territoire peut avoir avoir plusieurs natures, par exemple les 205 city (Q515) sont en fait tous aussi des commune of France (Q484170) (à l'exception de La Chaux-de-Fonds (Q68124) et Saarbrücken (Q1724).
Cdlt, VIGNERON (talk) 15:42, 26 April 2016 (UTC)

Importer des données de l'IGN et de l'Insee[edit]

J'ai créé pas mal d'ébauches de communes françaises sur la Wikipédia en espéranto, et pour ça je me suis aidé de cette base de données de l'IGN. Je me suis fait un script pour analyser leur fichier texte pour le mettre dans une base de données et j'ai aussi importé les données de population de l'Insee. Bref, j'ai sur mon ordinateur une base de données MySQL qui contient la population, la superficie, les coordonnées géographiques, l'altitude, etc. de toutes les communes de France métropolitaine, c'est-à-dire le genre de données utiles à Wikidata. Comment est-ce que je peux m'y prendre pour les importer ? Mutichou (talk) 17:03, 25 April 2014 (UTC)

La première chose à faire c'est sans doute de vérifier que la licence de ces données est compatible avec celle de Wikidata, la CC0, malheureusement c'est sans doute pas le cas :/ sinon il y a différentes plateforme pour coder un bot d'import, pywikibot par exemple, et il faut passer par une requête sur Wikidata:Bot requests pour ton bot. TomT0m (talk) 17:14, 25 April 2014 (UTC)
Les données de l'IGN sont publiées sous la Licence ouverte de l'État français, compatible avec CC-BY 2.0, et l'Insee demande de citer la source. Je ne m'y connais pas trop en licences, mais apparemment les deux permettent d'utiliser librement les données du moment qu'on cite la source. Wikidata permet d'indiquer la source des données, mais je ne suis pas sûr que ces licences soient compatibles avec CC0. Si ce n'est pas le cas, ça veut dire qu'il sera simplement impossibles d'avoir les données de population et de superficie des communes dans Wikidata ? Mutichou (talk) 18:46, 25 April 2014 (UTC)
Pas possible en effet pour un import massif: CC BY implique que le crédit aux auteurs soient intégralement donné lors de la reprise des données de WD, alors que CC0 n'implique rien. En l'état, on ne peut donc pas espérer obtenir une seule donnée des institutions françaises mais également de tous les pays, car la licence CC BY est le minimum demandé par tous les instituts de statistique nationaux. Snipre (talk) 20:31, 25 April 2014 (UTC)
Bonjour Mutichou (talkcontribslogs), Snipre (talkcontribslogs) et TomT0m (talkcontribslogs),
Je ne suis pas aussi certain que vous que l'import de données CC-by soit impossible sur Wikidata. Tout d'abord, le By est une obligation légale en France (en tant que droit morale inaliénable) et ce en tout circonstance et quelle que soit la licence (CC0, CC-BY, domaine public, etc.). De plus, la licence CC0 indique clairement et explicitement qu'elle s'entend to the extent allowed by law (ce que je comprend comme « pour la France, une CC0 correspond à une CC-by). Enfin, sur Wikidata, indépendamment des questions juridiques de licences, il est fortement conseillé d'indiquer la source en référence (ce qui correspond fortement à l'esprit du By).
Cdlt, VIGNERON (talk) 11:29, 8 December 2014 (UTC)
Nicolas, je pense que le pb est (comme sur Commons) le fait que CC0 autorise la réutilisation sans citer la source. Donc le fait que nous la citions nous ne change rien.
J'ai posé le même sujet il y a quelques moi sur le Bisto anglais : Wikidata:Project chat/Archive/2014/10#Copyright and licensing of extracted facts. Une des réponses renvoient sur un texte de Meta, mais en gros la réponse est que en France et dans beaucoup de pays d'Europe, le contenu des BDD peut-être protégé de façon globale même si chaque info ne l'est pas individuellement. Donc l'import massif sur WD en CC0 est de facto interdit, sauf si la BDD est aussi en CC0.
D'où aussi mon hésitation à faire l'import massif de données OSM mentionné au sujet précédent.
(Je suis persuadé que la plupart des imports massif par bot sont de ce fait hors limite, mais bref).
--LBE (talk) 14:45, 9 December 2014 (UTC)
@VIGNERON. Pareil que LBE: le problème de CC0, ce n'est pas la citation dans Wikidata, mais l'obligation de citer cette référence si on réutilise les données de Wikidata. Et le "to the extent allowed by law" n'est pas une application d'une autre licence selon la loi du pays, mais correspond au degré minimal de protection de la loi : dans certaines lois, on ne peut donner tous les droits d'une oeuvre, il y a toujours un droit moral de l'auteur sur son oeuvre. Si la loi requiert une licence CC-by, alors CC0 ne peut pas être utilisé. Snipre (talk) 15:20, 9 December 2014 (UTC)
Désolé mais je ne suis toujours pas convaincu, j'ai l'impression que vous êtes plus légaliste que la législation… (et la protection sui generi de la directive de 1996 ne change rien à l'histoire d'abord parce qu'il protège la base et pas les données et ensuite parce que ces bases sont placées sous une licence libre correspondant au domaine du droit d'auteur et pas du droit sui generi). Il me semble que si on suit votre logique jusqu'au bout, aucun citoyen français ne peut contribuer sur Wikidata et aucun citoyen du monde ne pourrait contribuer sur un sujet touchant à la France. Or ce n'est pas le cas ! (ni de jure ni de facto).
D'ailleurs Snipre je ne suis pas sur de bien comprendre ton explication : tu estimes que les données en CC0 ne sont pas utilisables selon la loi française ?
Cdlt, VIGNERON (talk) 16:03, 9 December 2014 (UTC)
Le pb de CC0, c'est que le contenu WD est publié sous cette licence, qui n'oblige pas à citer la source lors d'une réutilisation. Donc si on publie des infos sous licence CC-BY, même en mentionnant la source, on autorise du même coup les gens à la réutiliser en CC0, donc bug. C'est la même raison qui fait que les contenus CC-NC ne sont pas admis sur Commons, même si Commons lui même peut être considéré comme non commercial.
Pour le sui generis, je me réfère à la page Meta, avec le lien cette fois. Je quote : (in the EU) the sui generis right is infringed when "all or a substantial part of the database" is transferred into another document or database. J'aurais tendance à faire confiance à cette analyse de la directive, qui s'applique à tous les projets Wikimedia.
--LBE (talk) 20:08, 9 December 2014 (UTC)
Bon j'y suis allé un peu fort dans mon précédent message.
Je suis bien d'accord que publié des données originellement sous CC-by sur une plateforme en CC0, ce n'est pas « normal ». Ceci dit, si un citoyen français (et de tout pays imposant la paternité ce qui est − à divers degré − le cas de tout les pays du monde ! cf. notamment l'article 6bis la Convention de Berne de 1886) réutilise des données de Wikidata, il ne peut pas ne pas citer la source, il est sous CC0-by en quelque sorte (sauf cette disposition est déjà prévu dans la CC0, on est donc bien toujours sous licence CC0).
Pour le droit voisin sui generi, je ne sais pas trop. Tout d'abord, reprend-on vraiment une part substantielle de la base de données ? (de quelle base d'ailleurs ? si on considère la base Insee comme l'ensemble des données Insee, elle est immense et contient énormément de données qui n'intéresse pas Wikidata). En plus, il me semble que la directive de 1996 concerne une possibilité de protection, possibilité qui (toujours il me semble) un peu contredite par l'esprit d'OpenData en général et en particulier celui d'ouverture des données Insee sous licence CC-by (ouverture issue notamment de la directive de 2003 sur la réutilisation).
Bref je reste un peu sur mon avis initial : je ne suis suis pas certain que l'import est impossible.
Cdlt, VIGNERON (talk) 21:06, 9 December 2014 (UTC)
Pour info, il y a eu à peu près la même discussion sur Wikidata:Requests for permissions/Bot/Symac bot 4. --Zolo (talk) 21:13, 9 December 2014 (UTC)
Merci beaucoup pour cette info. Je pense que l'on va suivre le conseil de Dereckson et poser la question sur meta (reste à trouver où exactement ?) et à la WMF. Sinon, il restera toujours la possibilité de contacter l'Insee et Cie pour leur demander de passer les données sous CC0. Cdlt, VIGNERON (talk) 21:29, 9 December 2014 (UTC)
@VIGNERON WMF a déjà donné son avis, et ayant déjà essayé de discuter avec eux, tu peux éviter de perdre du temps à leur poser des question: dès que l'on entre dans les details, ils ne veulent pas donner de réponse claire, 1) parce que cela depend de chaque pays et donc il y a autant de réponse que de pays, 2) car en cas de problem, ils ne veulent pas être impliqués alors que c'est WM Deutschland qui gère Wikidata. Snipre (talk) 07:27, 10 December 2014 (UTC)

Propriété « nom COG » ?[edit]

Bonjour,

Je me demandais si il ne serait pas utile et pertinent de créer une propriété « nom selon le COG » pour les communes de France. Certes, cela serait très similaire au label mais cela serait plus explicite et surtout cela serait très utile dans les cas où le nom COG a changé (on pourrait ainsi mettre les différents noms avec les qualificateurs temporels qui vont bien).

Sinon autre solution, on pourrait utiliser la propriété official name (P1448) et indiqué le COG en référence et/ou qualificateur.

Qu'en pensez-vous ?

Cdlt, VIGNERON (talk) 11:29, 8 December 2014 (UTC)

official name (P1448) avec COG en reference. Sinon on va avoir une nouvelle propriété par pays rien que pour nommer les communes. Snipre (talk) 15:14, 9 December 2014 (UTC)
Ok, et avec simplement stated in (P248) comme qualificateur ? est-ce que cela ne vaudrait pas le coup d'indiquer le décret de renommage aussi ? et comment trouver la date (la date du décret ? la date de parution du décret au JORF ? la date du COG ? évidemment ce sont trois dates différentes…) et comment gérer ?
Je prends un exemple : Trans-la-Forêt (Q216677) (j'ai pris la date du COG qui correspond au lendemain de la parution du décret). Est-ce que cela vous semble correct ?
Cdlt, VIGNERON (talk) 16:14, 9 December 2014 (UTC)
Ça me semble correct, c'est la même chose que j'ai fait avec Sainte-Hélène-de-Kamouraska (Q3464302). Pour la date, je n'oserai pas trop m'avancer, ne connaissant pas la tradition française sur le sujet, mais il me semble que la date devrait être celle de la mise en vigueur du changement de nom. Au Québec, c'est la date de publication à la gazette officielle du Québec, sauf mention dans le règlement ou la loi d'une mise en vigueur ultérieur. --Fralambert (talk) 02:20, 10 December 2014 (UTC)

Bazar dans l'utilisation de P131[edit]

Bonjour,

En utilisant l'application Wikidata Spiral, je me suis rendu compte que l'utilisation de P131 dans les diverses entités territoriales en France est complètement incohérente. Il y a des choses qui me semblent complètement fausses :

  • mettre un lieu/bâtiment/monument dans plusieurs niveaux territoriaux, typiquement : la commune, la département et la région (voir le canton, l'arrondissement, le pays)
    • il me semble que l'habitude et la logique (surtout depuis l'arrivée de l'arbitrary acces) est de mettre uniquement le niveau le plus bas (généralement la commune)

Il y a des choses moins claires (mais qui mérite clarification pour harmoniser tout ça) :

Des avis, commentaires, remarques ?

Cdlt, VIGNERON (talk) 15:36, 25 June 2015 (UTC)

Il faut définir les niveaux administratifs reconnus et pertinents.L'idéal est que le projet définisse la structure sur une page ad hoc afin de pouvoir s'y référer. Et le mieux est l'ennemi du bien: il ne faut pas chercher à établir une structure trop complexe au début capable de représenter tous les détails et exceptions. Snipre (talk) 19:37, 25 June 2015 (UTC)
Interrogation sur le "le niveau le plus bas" : Paris (Q90) (commune), 1st arrondissement of Paris (Q161741) (arrondissement), Ménilmontant (Q2701404) (quartier) ?
Personnellement j'utilise la commune sauf pour Paris, Lyon, Marseille où j'utilise les arrondissements. Gzen92 (talk) 06:00, 26 June 2015 (UTC)
Oui, « le plus bas » demande quelques précisions mais il me semble qu'il est clair les niveaux supra-communaux (pays, région, département, arrondissement, canton, etc.) sont − sauf exceptions − à exclure. Quid aussi de mettre plusieurs valeurs imbriquées en located in the administrative territorial entity (P131) ? cela me semble d'autant moins pertinent avec l'arrivée de l’arbitrary access. Cdlt, VIGNERON (talk) 10:14, 28 June 2015 (UTC)
Au moins quatre types qui posent problème :
  1. les arrondissements administratifs (car peu utilisés dans la vie courante)
  2. les cantons (particulièrement enquiquinants, étant donné que certaines communes possèdent plusieurs cantons et réciproquement)
  3. les quartiers administratifs de Paris (qui n'ont plus vraiment d'existence administrative ni de pertinence pratique, mais qui sont plus petits et plus précis que les arrondissements).
  4. les quartiers de Paris au sens de no label (Q2993798), généralement encore plus petits que les quartiers administratifs, mais il me semble que personne ou presque ne les utilise ni ne les connait.
Je suppose que le modèle à choisir dépend de la complexité que l'on peut attendre des outils utilisant les données. J'aurais tendance à penser qu'il ne faut avoir comme valeur "preferred" que les niveaux administratifs que l'on utilise couramment, donc aucune utilisant les trois types précédent. En revanche, on peut ajouter d'autres niveaux administratifs avec le rang "normal". Dans l'idéal, il faudrait que les constraint violation reports prennent en compte le rang. --Zolo (talk) 06:10, 26 June 2015 (UTC)
Bonjour Zolo, utiliser les niveaux « courants » me semble gênant à plusieurs niveaux.
D'abord, cette notion me semble très subjective (selon que celui qui lit la donnée est français ou non, et s'il est français local ou non ; perso en tant qu'habitant de l'Ouest de la France, je mets parfois quelques secondes/minutes avant de me souvenir où se situe tel ou tel département de l'Est de la France).
De plus, j'ai du mal à voir l'intérêt de multiplier les informations sans raisons (et cela d'autant moins avec l'arrivée de l’arbitrary access) ; utiliser le rang est une idée intéressante mais l’information reste présente en double (donc double travail, double maintenance, etc). Une autre possibilité (dont je ne suis pas fan non plus mais que j'ai croisé sur quelques éléments comme no label (Q1047114) ou Monument aux Girondins (Q1064990)) est de mettre la commune en located in the administrative territorial entity (P131) et un niveau plus bas en location (P276).
Après, je préfère que l'on utilise une méthode à laquelle je n'adhère pas totalement mais utilisée uniformément sur le territoire plutôt que l'absence de méthode ce qui conduit au bazar actuel.
Cdlt, VIGNERON (talk) 10:14, 28 June 2015 (UTC)
Perso je pars du principe que si l'on veut à terme utiliser ces données sur wikipédia, on ne peut pas tout laisser en vrac dans la localisation. Donc pour ne pas perdre d'informations et rester cohérent, je laisse la commune (ou l'arrondissement pour Paris/Lyon/Marseille) dans located in the administrative territorial entity (P131) et les autres "lieux" dans location (P276) ou located on terrain feature (P706). Gzen92 (talk) 06:23, 29 June 2015 (UTC)
Pour reprendre les choses concrètement :
Pour les bâtiments et autres petits objets ponctuels :
  • Hors Paris-Lyon-Marseille : il parait y avoir consensus pour utiliser la commune.
  • Pour Paris -je sais pas pour Lyon et Marseille- il parait y avoir deux pratiques : l'arrondissement ou le quartier administratif. Le quartier administratif est plus précis, mais me gêne un peu, parce qu'il n'est pratiquement jamais utilisé, et n'est même, ou plus, vraiment un division administrative.
Quand il s'agit d'utiliser P131 sur des éléments désignant eux-mêmes des divisions administratives, c'est plus complexe. Plutôt que de divisions "couramment utilisées", j'aurais peut-être du parler de divisions administratives qui sont vraiment des divisions administratives, et qui ont une vocation généraliste. Après tout Academic district, France (Q2822246) et area of ​​defense and security (Q3575784) sont aussi des divisions administratives.
  • Pour les communes, hors Paris et Lyon, le plus logique me semble de mettre l'arrondissement. J'ai vu des cas où on mettait le canton, mais ça ne me parait pas une bonne idée. D'une part parce que les cantons ne sont pas vraiment des divisions administratives, et puis surtout parce que le canton n'est pas toujours "au dessus" de la commune : certaines communes contiennent plusieurs cantons. (entre parenthèse, certains contributeurs ajoutent plein de classes comme "subdivision administrative de quatrième niveau" dans canton of France (until 2015) (Q184188), c'est un système largement utilisé pour les catégories de Wikipédia en anglais, mais ça me parait inutile sur le plan pratique et problématique sur le plan conceptuel)
Je pense qu'on peut sans crainte utiliser des départements pour les arrondissements et des régions pour les les départements, mais en cherchant un peu, on doit pouvoir trouver pas mal de cas problématiques (Metropolis of Lyon (Q16665897)). --Zolo (talk) 07:58, 29 June 2015 (UTC)
@Zolo, Gzen92: désolé pour le retard de réponse.
Pour le ponctuel, c'est effectivement généralement la commune qui est utilisée. Pour les grandes villes (et pas uniquement PLM), le quartier est parfois utilisé. Est-ce que l'on harmonise pour utiliser uniquement la commune (sauf PLM), est-ce que l'on utilise la commune et la quartier ? (éventuellement avec deux différentes propriétés : located in the administrative territorial entity (P131) pour la commune et location (P276) pour le quartier).
Oui, le canton est complexe (et mouvant) et mériterait une discussion à part.
Pour les communes, la question ne me semble pas tant « canton ou arrondissement ? » mais plutôt « arrondissement ou département ? » Tout le monde est d'accord pour les arrondissements ? Du coup, cela semble à la fois simple et logique : commune > arrondissement > département > région.
Cdlt, VIGNERON (talk) 09:37, 10 July 2015 (UTC)
D'accord pour commune > arrondissement > département > région (même si on pourrait enlever l'arrondissement, peu utilisé dans la pratique).
Du coup, à quel endroit précise-t-on le(s) canton(s) d'une commune ? Il y aurait bien electoral district (P768) mais ça semble réservé aux élus.
En cas d'accord, ne faudrait-il pas faire passer un bot pour les articles sur les communes ? --El Caro (talk) 15:45, 3 August 2015 (UTC)
Déjà, depuis le début de la discussion, l'intitulé de located in the administrative territorial entity (P131) a été changé plusieurs de « localisation territoriale » en « localisation administrative » et inversement (le 17 juin par Fralambert (talkcontribslogs) puis de nouveau par El Caro (talkcontribslogs) et Genium (talkcontribslogs) aujourd'hui). Est-ce qu'il y a eu des discussions à ce propos ? (je ne me souviens pas d'en avoir vu ; a priori « territoriale » me semble mieux mais je n'ai sans doute pas tout les arguments pour décider).Une discussion a débuté ici : Wikidata:Bistro#Property:P131 en français.
Les cantons (desquels parle-t-on d'ailleurs ? depuis 1789 la notion a évolué plusieurs fois, en 1793-1795, en 1958, en 2013-2015, etc. les éléments canton of France (until 2015) (Q184188)-canton of France (Q18524218) étant pour le moins bancals) et autres entités administro-civilo-militaro-religio-juridico-territoriales peu connues, c'est le bazar, je propose de les laisser de côté pour le moment afin de se concentrer sur un problème relativement simple avant de s'attaquer à plus complexe et plus compliqué.
Si tout le monde est d'accord pour le schéma « commune > arrondissement > département > région », nul besoin d'un bot, un outil comme Autolist suffit largement. Tout le problème semble résider dans l'arrondissement... Ceci dit, si on ne le met pas au dessus des communes, on peut toujours le mettre en dessous des département en surplus (ce qui est bizarre mais possible et pas forcément moins pratique).
Cdlt, VIGNERON (talk) 16:16, 3 August 2015 (UTC)

J'ai pas tout lu, mais il me semble que vous essayez d'établir un total order (Q369377) View with Reasonator View with SQID entre les niveaux. C'est vain quand l'ordre est manifestement une partial order (Q1069998) View with Reasonator View with SQID générale, dans lequel tous les éléments sont pas inclus les uns dans les autres, donc pas comparables 2 à 2 systématiquement. On a vraiment besoin de hiérarchiser totalement ? Je ne pense pas. Si on est dans un "minimum", c'est à dire qu'il n'y a aucune division qui soient "inférieure" à notre division, ça m'a l'air de suffire très bien comme règle, même si c'est pas parfait. On peut même envisager qu'il y ait plusieurs localisation avec la règle suivante :

  • Si il existe deux déclarations "M est localisé dans A ; M est localisé dans B", si on a à la fois "A n'est pas inférieure à B" et "B n'est pas inférieure à A", alors les deux déclarations ne sont pas redondantes.

J'ai pas non plus l'impression que toutes les entités soient intéressantes pour la localisation, par exemple personne ne dira naturellement qu'un monument est situé dans un canton ... Dans une commune ou un arrondissement Parisien par contre, certainement. Après est-ce si important ? D'autant plus qu'on a souvent les coordonnées GPS qui sont bien plus informatives. author  TomT0m / talk page 18:27, 3 August 2015 (UTC)

Euh désolé TomT0m mais je n'ai globalement pas compris ce que tu essayais de dire.
Mon problème de base (duquel on s'est largement écarté) est simple. Actuellement, la propriété located in the administrative territorial entity (P131) a des valeurs incohérentes pour des entités de même niveau (typiquement, on a certaines communes dans des arrondissements et certaines communes dans des départements, parfois les deux, parfois d'autres valeurs encore) ce qui me semble dommage et dommageable. Ne faudrait-il pas corriger cela et choisir de mettre toutes les communes toujours sous la même entité ? (sachant que c'est ce qui se passe dans la réalité et pour une fois sans exceptions).
Cdlt, VIGNERON (talk) 20:11, 3 August 2015 (UTC)
@VIGNERON: Ce n'est pas si dommageable que ça, si vraiment la commune est située dans l'arrondissement pourquoi pas. De toute façon on peut normaliser dans l'infobox en choisissant d'afficher uniquement les déclarations located in the administrative territorial entity (P131) dont le sujet est une instance de département si on veut. C'est autre chose si c'est pour indiquer une subordonnation"politique", genre "les communes répondent au département et doivent se soumettre aux lois départementales", je sais pas si on a une propriété pour dire ça. Mais une simple localisation n'a pas vraiment de conséquences ... author  TomT0m / talk page 22:37, 3 August 2015 (UTC)
@TomT0m: dans une infobox comme ailleurs, un programme a tout intérêt de vérifier qu'il récupère ce qu'il s'attend à récupérer (sinon, çafinit comme Mars Climate Orbiter (Q574464)). Mais ce n'est pas une raison pour utiliser des systèmes différents pour des choses identiques sur Wikidata. « si vraiment la commune est située dans l'arrondissement » ben oui, chaque et toute commune de France est située dans un arrondissement (circonscription administrative strictement inférieur au département et supérieur à la commune). Cdlt, VIGNERON (talk) 08:54, 4 August 2015 (UTC)
@VIGNERON: Je suis pour conserver une certaine souplesse étant donné que Wikidata est d'abord et avant tout un projet collaboratif que tout le monde peut éditer, et que par conséquent une structure trop rigide risque d'être éprouvante à maintenir. En france encore dans le cas des divisions administratives le jeu de données est public et relativement bien normalisé, défini par les lois et tout, mais imagine dans des pays en guerre ou dans des cas comme le tremblement de terre en Haiti ou des journalistes qui entre les informations qu'il a pu glaner ... On a tout intérêt à maintenir des choses qui peuvent exploiter l'information même si elle est pas normalisée idéalement. Un Wikidataien se plaint régulièrement que la structure administrative de son pays (j'ai oublié lequel, un des pays du nord de l'europe) est pas spécialement adaptée à l'utilisation de propriétés strictement hiérarchiques comme celle-ci et sait pas trop comment s'y prendre, je peux vous mettre en contact :) Après ça empêche pas une phase de nettoyage et de normalisation par la suite évidemment, mais je ne pense pas qu'on puisse partir de l'hypothèse que tout sera bien lisse et propre, c'est pas du tout l'esprit de Wikidata ou les contraintes ne sont pas des contraintes strictes mais juste des rapports sur la potentielle mauvaise utilisation ou l'indication que le modèle doit évoluer ...
Cela dit quand on utilise certaines propriétés avec une définition très précises avec des données importées, c'est différent. author  TomT0m / talk page 09:16, 4 August 2015 (UTC)
Je suis à 1000 % d'accord avec toi, restons souple et de toute façon tout ne sera jamais lisse sur Wikidata. Par contre, là on a quand même un sous-ensemble très restreint et parfaitement normalisé, ce serait dommage de ne pas en profiter.
Bref, et si il y a une opposition majeure, je propose et prévois de faire le ménage suivant : pour les communes françaises (instance of (P31) = commune of France (Q484170), seulement 36 960 éléments pour le moment), je retire toute mention du département et de la région en located in the administrative territorial entity (P131) ; j'y ajoute l'arrondissement (si il n'est pas déjà présent) ; je ne touche pas au reste. Cdlt, VIGNERON (talk) 09:49, 4 August 2015 (UTC)
Ok pour enlever la mention de la région ou du département. Même si l'arrondissement (hors Template:Q702842) n'est pas très important, on peut toujours l'utiliser pour remonter vers le niveau supérieur. Mais à la limite, c'est un peu du détail, le point qu'il faut vraiment régler, c'est les cantons. Là on a vraiment quelque chose de faux. Par exemple, Blois (Q160927) est sensée être localisée dans 5 cantons, ce qui voudrait dire que Blois toute entière est incluse dans chacun des 5 cantons. Ca viole le présomption de transitivité de la propriété, et ça c'est mal. Qu'est ce qu'on fait ? --Zolo (talk) 13:51, 28 August 2015 (UTC)

Cantons[edit]

Bonjour,

Comme demandé ci-dessus, j'ouvre une section pour les cantons.

La question de leur import depuis wikipédia dans les communes se pose sur fr:Discussion Projet:Communes de France. Depuis leur nouvelle version, ils sont considérés comme des circonscriptions électorales. Mais ici, electoral district (P768) est réservée aux élus, pas aux territoires. Faut-il créer une nouvelle propriété "circonscription électorale" pour les territoires ? Étonnant qu'elle n'existe pas déjà... --El Caro (talk) 13:42, 5 August 2015 (UTC)

Ah les cantons, je ne suis pas vraiment sur de vouloir m'engager dans ce débat... bon, allons-y.
Déjà, je ne comprends pas trop pourquoi il y a deux éléments canton of France (until 2015) (Q184188) et canton of France (Q18524218). Soit on considère qu'il n'y a qu'un concept (comme l'article de la Wikipédia francophone), soit on considère qu'il y en a une dizaine et de toute façon, il faudrait alors un élément chapeau à relier aux articles Wikipédia ; mais seulement deux éléments c'est très bancal, surtout quant un seul est relié aux articles alors que ceux-ci parlent des deux... D'ailleurs, j'ai suivi la réforme mais je ne suis pas forcément spécialiste du sujet, le canton n'est-il plus qu'une circonscription électorale ? (du point de vue du gouvernement au moins - je crois vaguement me souvenir que cela reste utilisé notamment par l'administration fiscale et l'INSEE (Q156616) l'utilise évidemment -, tout un tas d'organisations non gouvernementales utilisant par ailleursle canton pour leurs besoins).
As-t-on vraiment besoin d'un propriété spécifique pour les cantons ? J'hésite mais j'aurais plutôt tendance à considérer que located in the administrative territorial entity (P131) est suffisant (d'autant plus pour les cantons de 1789 à 2015).
Après, j'ai l'impression que ce sont plutôt des détails qui pourraient se résoudre à l'aide de sources et d'un peu de réflexions : il me semble que la question principale est : où place-t-on les cantons ? à partir des communes ? (au-dessus et en-dessous ce qui complique la chose) à partir des arrondissements ? (là encore la réforme de 2015 met le bazar) à partir des départements ? (logique si on se réfère au no label (Q2981581), notamment le « CHAPITRE III : Subdivisions du département ») ou bien à partir des élus ? (pour le coup, electoral district (P768) semble parfaitement adapté dans ce cas) seulement un de ces choix ou plusieurs ?
Cdlt, VIGNERON (talk) 15:12, 5 August 2015 (UTC)
(au-dessus et en-dessous ce qui complique la chose) Je persiste : tu essayes de former un ordre total entre les divisions administratives :) C'est à dire en reprenant tes mots : chaque type de circonscription est soit au dessus soit en dessous d'un autre type. Ce qui n'est pas forcément pertinent : on peut avoir des types qui ne sont pas comparables, genre le canton n'est ni au dessus ni en dessous de la commune. Dans ce cas c'est vain de forcément vouloir recréer un ordre total, qui sera forcément bancal, faut trouver une autre solution, genre les afficher dans deux items différents ou deux liste différentes, et renoncer à les comparer dans le cas de l'utilisation de located in the administrative territorial entity (P131). En terme mathématique, on garde un ordre (partiel).
Pour la définition des canton : il y a pas de réponse évidente entre avoir deux éléments pour deux définitions un élément avec un élément dont la définition est obsolète à partir d'une certaine date.
J'ai été confronté au problème avec Plution : Pluton n'est plus une planète. Mais c'est la définition de planète qui a changé. Du strict point de vue des définition, Pluton rentre toujours dans la définition de "Planète du système solaire ancienne définition". Si une définition est associée à une classe d'élément, alors c'est aussi pertinent de créer un élément par définition, une définition = un concept = un élément ... c'est à mon avis une manière élégante de gérer les problèmes de définitions. Après je comprend qu'on soit pas d'accord, mais le flou entre les concepts et les interwikis c'est de toute façon un casse tête qu'il faut gérer, on verra ce qui sortira de WD:XLINK qui pourrait trouver un moyen de relier tout ça ...
Concrêtement avec les cantons : si les cantons ont été complètement vidés de leur substance (je croyais même qu'ils n'existaient plus en fait /o\) ou si la carte des région a été complètement redécoupée, on a pas carrément intérêt à créer de nouveaux éléments ? ça permet de simplifier la gestion de l'historique non ? author  TomT0m / talk page 08:34, 6 August 2015 (UTC)
Je ne sais toujours pas bien ce qu'est un ordre total (je vais sur ta PDD pour en savoir plus) et pour le moment, je n'essaye de rien former du tout, je ne fais que poser des questions et des remarques. Si je comprends bien ce que tu dis, ta remarque ne dit-elle pas « au-dessus et en-dessous ce qui complique la chose » mais avec plus de mots ?
Avoir deux éléments pour un concept qui a changé plus de deux fois de réalité, c'est étrange.
« on a pas carrément intérêt à créer de nouveaux éléments ? » c'est ce qui a généralement été fait, non ?
Cdlt, VIGNERON (talk) 06:51, 7 August 2015 (UTC)
Non pas forcément. Un autre exemple est les taxons en taxonomie, ou ça évolue pas mal. et je viens de voir que Brya a rajouté les deux possiblités dans leur tutoriel, ce qui signifie qu'ils ont pas encore tranché l'option idéale (si elle existe) ... la taxonomie est autrement plus compliquée que l'administration par contre vu que la classification a déja pas mal évoluée et évolue encore au gré des études et découvertes scientifiques. author  TomT0m / talk page 09:12, 7 August 2015 (UTC)
@TomT0m. Peut-on éviter de polluer la discussion en introduisant des concepts qui sont inutiles ? Il n'y a pas d'ordre total ou non qui se pose, la question est de savoir comment est structurée l'administration française. Ce n'est pas au contributeur de décider comment faire cette structure, il suffit de poser sur le papier la structure réelle et de voir quelle partie est intégrée dans quelle autre. Snipre (talk) 09:44, 7 September 2015 (UTC)
@Snipre, non pas du tout, le problème est que les structure ne s'intègrent pas les unes dans les autres, ce n'est d'ailleurs pas spécifique à la France.

Tentative de résumé sur la question P131[edit]

On a pour l'instant :

Tours (Q288)located in the administrative territorial entity (P131)  canton of Tours-Centre (Q913072)

En vrai, c'est pourtant canton de Tours-centre qui est localisé dans Tours. Il y aurait une solution simple : retirer la déclaration sur Tours, et ajouter le contraire :

canton of Tours-Centre (Q913072)located in the administrative territorial entity (P131)  Tours (Q288).

Mais :

  • on se retrouvera parfois avec des communes avec P131 un canton, et parfois avec l'inverse (pas sûr que ce soit très grave, mais peut-être un peu bizarre pour des tests de cohérence)
  • "canton" est est marqué sous-classe de third-level administrative country subdivision (Q13221722) et commune comme sous-classe de fifth-level administrative country subdivision (Q15640612). Pour ça, la solution est simple, enlever ces classifications vides de sens. Mais ça risque d'être un mélodrame pour changer ça, il y a des gens qui ont l'air de tenir beaucoup à leurs "niveaux" (qui pourraient effectivement être très pratiques s'ils correspondaient à quelque chose de réel)

Il faudrait peut-être lancer un discussion sur le Project Chat, mais j'ai peur que ça s'éternise sans résultat concret. --Zolo (talk) 17:20, 6 September 2015 (UTC)

Il me semble que ta proposition est plutôt bonne. En tout cas, elle me semble à la fois simple et logique. Ceci dit, je m'interroge toujours : est-ce que located in the administrative territorial entity (P131) est adapté pour un canton ? plus précisément une constituency (Q192611) (ou no label (Q19999072) ?) est-elle aussi une administrative territorial entity (Q56061) ?
Sur canton of France (Q18524218) : subclass of (P279) = third-level administrative country subdivision (Q13221722), je vois qu'il n'y a pas de sources pour cette déclaration ; idem sur commune of France (Q484170) (par contre, rien sur canton of France (until 2015) (Q184188)). @Verdy p, Arctic.gnome: avez-vous des références pour ces ajouts ? Special:Diff/172834394 et Special:Diff/104550849. Personnellement, en l'absence de source, je serais plutôt pour les enlever (on ne sait pas de quelle administration on parle, or il suffit de lire fr:Administration territoriale de la France pour voir que suivant l'administration, les niveaux s'imbriquent - ou pas - très différemment).
Concernant les cantons c'est très clair: avant mars 2015, c'était exclusivement des subdivisions administratives des arrondissements (niveau 4), eux-mêmes divisions des départements (niveau 3). Depuis mars 2015, les cantons sont exclusivement des divisions des départements (les nouveaux cantons sont fréquement à cheval sur plusieurs arrondissements, jamais à cheval sur plusieurs départements).
Avant mars 2015, les cantons étaient clairement de nature administrative (en plus d'être des subdivisions judiciaires depuis l'origine, puis des circonscriptions électorales, un rôle ajoutés bien plus tard). Aujourd'hui les nouveaux cantons n'ont plus aucun rôle au plan judiciaire (les territoires de compétence des tribunaux sont définis par départements comme des listes de communes entières, avant 2015 cela correspondait à peu près aux cantons sauf dans les communes découpées sur plusieurs cantons, mais depuis mars 2015, les nouveaux cantons n'ont pas de définition judiciaire).
Le rôle administratif a également été supprimé pour les nouveaux cantons (mais les rôles administratifs des anciens cantons persistent encore dans le code rural et de l'environnement où il y a de nbombreuses références, bien que ce soit encore des facilités liées à l'ancien découpage cantonal en vigueur à la date de publication des décrets et arrêtés, maintenant les nouveaux arrêtés publiés ne font plus référence aux cantons mais uniquement aux listes de communes, voire d'autres collectivités comme les EPCI).
Bref les nouveaux cantons depuis mars 2015 sont bien en 3e niveau (en parallèle des arrondissements), les anciens en 4e niveau... Tu n'as pas bien cherché ou tu ne t'es pas donné beaucoup d'effort pour comprendre.
Note: je n'ai jamais dit non plus que les communes étaient de 5e niveau administratif, elles restent en 4e niveau comme subdivisions des arrondissements en 3e niveau, et même si elles peuvent faire partie de plusieurs cantons (aussi bien avant qu'après le changement de découpage cantonal), mais dans une seule zone judiciaire (c'était le cas déjà avant mars 2015 mais pas depuis longtemps, historiquement les communes suivaient leur découpage cantonal pour les zones de compétences des tribunaux, mais cela a disparu depuis quelques années). Verdy p (talk) 18:23, 23 November 2015 (UTC)
En plus de l'utilisation du ou des éléments cantons sur les communes, il y a d'autres problèmes. D'abord, les deux éléments canton of France (Q18524218) et canton of France (until 2015) (Q184188), dont il semble que le découpage en deux éléments ne convient pas et dont les propriétés renseignées serait à vérifier (cela semble un peu le bazar notamment pour instance of (P31) et subclass of (P279)). Ensuite, il y a les éléments sur les cantons eux-mêmes : il manque des éléments sur la quasi-totalité des cantons historiques, les éléments existants ont souvent bien peu de propriétés renseignés (et question de nouveau : l'usage de contains administrative territorial entity (P150) est-il correct et pertinent pour les cantons ?), enfin cf. question précédente : un ou plusieurs éléments pour un canton qui a changé de territoire, de population, d'élus, de nom, etc.
Cdlt, VIGNERON (talk) 10:45, 7 September 2015 (UTC)
Merci à VIGNERON pour enfin mettre la structure à plat en pointant sur fr:Administration territoriale de la France. On y voit qu'il existe 3 structures différentes: collectivités territoriales, circonscription électorale et administration déconcentrée de l'État. On ne peut pas mélanger les 3 trois. Il faut donc définir ce que l'on veut représenter en utilisant located in the administrative territorial entity (P131). Il est clair que les cantons nouvelle version ne sont plus un niveau administratif, mais un niveau électoral au meme titre que les circonscriptions pour élection européenne et qu'il faut envisager un autre système de classification avec d'autres propriétés. On devrait laisser tomber le problèmes des anciens cantons pour déjà se concentrer sur la structure actuelle.
Pour advancer avec les cantons, l'idéal serait de se renseigner pour voir si d'autres pays ont un problème similaires avec différentes organisations qui ne se recoupent pas (administratives vs. électorales) et établir avec eux une nouvelle propriété et des qualificatifs. Snipre (talk) 15:01, 7 September 2015 (UTC)
Faudrait surtout déja préciser le sens de P131 parce que "situé dans" ne veut rien dire (enfin, d'utile pour le problème qui nous occupe :p). Par sûr qu'on ait besoin d'une nouvelle propriété pour dire que c'est essentiellement électoral quand on peut le préciser par la classification (instance de type de division à but électoral par exemple). Si les cantons servent pour les régionales, on peut dire que les cantons sont subordonnés à la région par exemple. Si on veut préciser les relations entre les régions et les départements, par contre, pas sûr que situé dans soit vraiment utile. author  TomT0m / talk page 16:48, 7 September 2015 (UTC)
Cela dépend comment tu veux créer ton arbre:
*Solution 1:
Commune X located in the administrative territorial entity (P131) département Y (classification administrative)
Commune X located in the administrative territorial entity (P131) canton Z (classification électorale)
Si tu veux établir l'arbre de la classification administrative Commune X dans département Y qui se trouve dans région A qui se trouve dans pays France), tu devras tester chaque déclaration located in the administrative territorial entity (P131) et filtrer celles qui sont définies comme divisions administratives. Pas impossible, mais il faudra être rigoureux et s'assurer que toutes les divisions sont correctement identifiées.
*Solution 2:
Commune X located in the administrative territorial entity (P131) département Y (classification administrative)
Commune X localisation électorale canton Z (classification électorale)
Ici tu peux reconstruire l'arbre de manière plus simple puisqu'il suffit de suivre une seule propriété.
La classification est dépendante de la manière dont se font les recherches: une classification doit intégrer le fait qu'elle doit servir à la recherche, aux croisements et autres joyeusetés des bases de donnée. On peut toujours effectuer une recherche si la classification est rigoureuse, mais le requête peut être plus ou moins facile à écrire. Personnellement j'étais pour limiter le nombre de propriétés, mais maintenant sans être partisan de la multiplication des propriétés, je comprends le besoin de davantage de propriétés, surtout que les outils pour créer des requêtes ne sont toujours pas finalisés, ce qui rend difficile de tester une requête pour vérifier si la classification est utile et facile à utiliser. Snipre (talk) 19:35, 7 September 2015 (UTC)
C'est toujours conceptuellement bancal. On peut classer des trucs en fonction de leur localisation, mais ça ne fait pas de la localisation en soi une classification (on emploie classification à toutes les sauces pas de manière appropriée souvent). Je dis ça je propose rien mais si déjà on pouvait partir sur des bases correctes on éviterait bien des problèmes :) author  TomT0m / talk page 09:37, 8 September 2015 (UTC)

P131[edit]

Bonjour, cette propriété se réfère-t-elle à la notion de Collectivité territoriale ? Prenons l’exemple de l’Université Montpellier 1. Elle est certes liée au Languedoc-Roussillon (localisation administrative de la région ou de l’académie?) mais se trouve surtout implantée dans plusieurs villes (localisation territoriale)… Pour les églises, le terme localisation administrative peut renvoyer à différents niveaux d’administration (clergé, laïque)… Le terme localisation territoriale souvent employé sur Wikipédia me semble adapté si l’objet de la propriété est de localiser un objet sur un territoire donné… genium ⟨✉⟩ 21:23, 25 October 2015 (UTC)

Bonjour, il s'agit de la localisation administrative, dans le cas de cette université, le plus adapté est la commune (une ou plusieurs, ça ne pose pas de problème). Gzen92 [discuter] 06:59, 26 October 2015 (UTC)

Wikimania 2016[edit]

Only this week left for comments: Wikidata:Wikimania 2016 (Thank you for translating this message). --Tobias1984 (talk) 11:44, 25 November 2015 (UTC)

Deux nouvelles propositions de propriétés[edit]

Hello, je viens de créer deux nouvelles propositions de propriétés :

On a déjà des propriétés pour les communes et les cantons, il manque encore les arrondissements si quelqu'un veut s'en charger. -Ash Crow (talk) 15:01, 27 February 2016 (UTC)

Bonjour, bonne idée, seulement, n'y a-t-il pas un "minimum" lors de la création de propriété ? Avec une centaine de départements et une vingtaine de régions, pas sûr que ça passe. Gzen92 [discuter] 17:29, 27 February 2016 (UTC)
Rien n'est indiqué dans la page de propositions de propriété à ce sujet. En l'occurrence, ce sont des identifiants externes correspondant à une classification étatique, qui plus est très utilisée dans le cas des départements. -Ash Crow (talk) 22:54, 27 February 2016 (UTC)

Détricotage d'interwikis[edit]

Hello,

je viens de tomber sur subprefecture (Q1367821) et subprefecture in France (Q16481846), il semble qu'il y ait du nettoyage à faire sur les interwikis et les déclarations, c'est mélangé... Si quelqu'un se sent le courage de s'en charger... -Ash Crow (talk) 21:05, 29 February 2016 (UTC)

Nature d'un ancien arrondissement[edit]

Bonjour,

Je viens de tomber sur arrondissement of Bonn (Q19259655), où Jura1 avais mis instance of (P31) = former administrative territorial entity (Q19953632). J'ai rajouter instance of (P31) = arrondissement of France (Q194203) (avec start time (P580) et end time (P582)). Mais du coup je me pose la question : la nature instance of (P31) = former administrative territorial entity (Q19953632) est-elle vraiment encore utile ? Je l'ai laissé pour le moment mais cela me semble un peu redondant, qu'en pensez-vous ?

Jura1 soulève très justement la potentielle non-possibilité de pouvoir faire une requête intégrant des qualificatifs mais je dois avouer que je ne suis que moyennement convaincu (nos données ne devraient en théorie pas être organisées en fonction des limitations externes) ; je reste donc neutre et surtout en attente d'autres avis.

Au passage, je teste la notification de projet, n'hésitez pas à me dire si cela fonctionne ;) : VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France

Cdlt, VIGNERON (talk) 19:09, 22 May 2016 (UTC)

J'aimerais bien savoir quel type de requête peut nécessiter des instance of (P31) = former entity (Q15893266) (ou une de ses sous-classes), concrètement ? -Ash Crow (talk) 19:13, 22 May 2016 (UTC)
On peut faire des requêtes SPARQL avec des qualificatifs. Je ne comprends pas cet argument. A mon avis, il ne reflète pas la réalité actuelle. Snipre (talk) 21:13, 22 May 2016 (UTC)
@Ash Crow, Snipre: j'imagine juste qu'il y a des systèmes externes pour lesquels faire le tri sans passé par les qualificatifs est plus simple. Ceci dit, comme je le disais, ce n'est pas un argument décisif pour moi. Du coup, que pensez-vous ? on retire purement et simplement les instance of (P31) = arrondissement of France (Q194203) quand il y a instance of (P31) = arrondissement of France (Q194203) (avec start time (P580) et end time (P582)) ? Ou bien y a-t-il d'autres aspects à prendre en compte ? Quid d'autres cas que les arrondissement of France (Q194203) ? Je me souviens que pour les commune of France (Q484170), on avait décidé de ne pas utiliser former commune of France (Q18821702). Cdlt, VIGNERON (talk) 21:41, 22 May 2016 (UTC)
Pour moi un truc assez simple pour virer toutes les anciennes entités sans faire de détail c'est de virer tout ce qui est instance "d'ancienne entité" (avec les sous classes évidemment). Ça permet de virer tout ce qui est "province romaine" en même temps que toutes les anciennces entités administratives française sans trop se prendre la tête à savoir si quelqu'un a rajouté une date de fin/une déclaration de destruction/dissolution ou que sais-je sur toutes les provinces romaines. author  TomT0m / talk page 05:39, 23 May 2016 (UTC)
Par ailleurs je vois pas trop à quoi ça sert de vouloir les supprimer, surtout tout seul dans son coin sur un bout de projet alors que c'est une question de modélisation qui peut potentiellement toucher tout le projet. Il me parait difficile de prendre ce type de décision sans en parler au minimum sur le project chat (même si je me fais pas trop d'illusion sur le fait que tout le monde fait des trucs dans son coin sur pas mal de projets locaux) alors que ce serait dommageable que des gens adoptent sans s'en rendre compte des modèles trop disparates à l'échelle du projet.
Enfin : quand on aura un WikiProject Reasoning plus avancé, on saura comment gérer la classification avec des règles un peu précise, et si on choisit une stratégie ou on intègre en redondance des déclarations qui peuvent être déduites d'autres déclarations (les propriétés symétriques ou des trucs plus avancés, genre que le pays d'une région française est nécessairement la France) ou d'autre parcimonieuses comme vous proposez (on déduit qu'une entité peut être classifiée dans la classe "ancienne entité" à partir de valeur de qualificateur ou de propriétés) mais il me semble aussi qu'on peut (potentiellement) faire l'inverse, à savoir si on sait qu'une entité n'existe plus, on peut en déduire qu'elle a une date de dissolution/destruction par un raisonnement.
Tant qu'on est pas plus avancé, je suis mollement pour ce genre d'initiatives de normalisation des données qui peuvent virer des points d'entrées / requêtage / entrage de données efficaces (c'est plus simple de rentrer "ancienne entité" en une déclaration rapidement que de rentrer une paire de déclarations/qualificateurs je ne sais comment pour faire la même chose) pour une valeur ajoutée assez douteuse de mon point de vue tant qu'on s'est pas mis d'accord sur le pourquoi du comment. C'est bien plus utile de rajouter des données. author  TomT0m / talk page 05:54, 23 May 2016 (UTC)
TomT0m Euh ok, si certains estiment que ce n'est pas inutile, je ne touche donc pas à ces quelques déclarations éparses (ni en suppression sur les quelques dizaines d'éléments où elles présentes, ni en ajout sur les dizaines de milliers d'éléments où elles sont absentes). Cdlt, VIGNERON (talk) 07:00, 23 May 2016 (UTC)
@VIGNERON: N'oublie pas qu'on parle de classe, et que donc le nombre de déclaration en lui même n'est pas significatif, vu qu'il suffit de sous-classer un type d'entité administrative en ancienne entité pour que toutes ses instances soient elles même classifiées en ancienne entité sans qu'il y ait besoin d'explicitement mettre les déclarations sur toutes les instances. Le nombre de déclarations / pas déclarations est donc trompeur. author  TomT0m / talk page 16:56, 23 May 2016 (UTC)
@VIGNERON: certes mais cela ne change pas grand'chose, l'ordre de grandeur reste le même. Les déclarations dont la valeur est en sous-classe de former entity (Q15893266) sont très peu nombreuses (tant en absolu qu'en relatif, surtout que l'arbre de classe lui-même est très restreint et surtout mélange de chose plus ou moins disparues...). Cdlt, VIGNERON (talk) 18:56, 23 May 2016 (UTC)
Tu me titilles, c'est assez vague tout ça :) si tu as des méthodologies de calcul et des chiffres je prend. Ça m'a pas trop l'air de changer non plus le fait que si les informations ne sont pas actuellement entrée, il suffit de sous-classer si c'est pas fait "province romaine" en "entité qui n'existe plus" et de répéter l'opération pour l'empire bizantin, l'antiquité grecque et d'autres trucs, on aura été bien plus efficace que de rentrer individuellement une date de fin (redondante qui plus est) sur chacune des instances de ce type de divisions anciennes. author  TomT0m / talk page 19:33, 23 May 2016 (UTC)
Oui, désolé pour le titillement ;) Je n'ai pas vraiment de chiffres précis (je ne connais pas d'outil qui puisse vraiment visualiser les classes Wikidata sans rendre l'âme et/ou être illisible) mais j'ai fait une simple requête qui permet de voir que les éléments en sous-classes de former entity (Q15893266) sont peu nombreux (147 au moment où j'écris) :
SELECT ?item ?itemLabel WHERE {
	?item wdt:P279+ wd:Q15893266 . 
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}

Try it!

On voit facilement (par exemple via cet outil) que la classe contient des choses très diverses. Typiquement, j'ai repéré des ruines, qui techniquement n'ont pas complètement disparues puisque justement il reste une ruine. Pire, il y a des entités qui me semblent ne pas avoir disparu (eg. delegated commune (Q21869758) ou associated commune (Q666943) qui a certes disparu en tant que commune mais qui sont des entités existants encore en mai 2016 et sans doute pour longtemps encore). Au final, je trouve que le concept même de « disparition » est bancal, pour paraphraser Lavoisier et Anaxagore : « rien ne disparait, tout se transforme ». Et surtout ce concept est « pauvre » dans la mesure où (là c'est plus basé sur un constat de ce que j'ai pu croisé) on a généralement aucune date pour placer temporellement cette disparition. D'où le fait que je passe régulièrement ajouté des jalons temporels ce qui rend la déclaration de disparition redondante d'où le lancement de cette discussion. Après, si je titille c'est aussi parce que je ne suis pas trop à l'aise avec les classes et que pour des cas assez simple comme les arrondissements français, il ne me semble pas y avoir un besoin de se compliquer avec cela.
Cdlt, VIGNERON (talk) 20:21, 23 May 2016 (UTC)
@VIGNERON: C'est quoi qui te pose problème avec les classes ? faut pas être intimidé, c'est pas si terrible. Sinon le problème du changement de nature est bien plus large et se pose en permanence : doit-on créer un autre élément pour le charger avec des déclarations avec du sens ou garder un élément "coquille vide" genre dont l'invariant est vaguement la localisation mais dont tout le reste change ? Genre un "Champ de Mars" qui passe de champ de parade à endroit dans une ville avec des immeubles.
Je ne vois pas trop en quoi ça concerne WP France, ces arrondissements sont en Italie et en Allemagne.
--- Jura 06:16, 23 May 2016 (UTC)
Parce que ce sont des arrondissements français situés en France. Comme je te le disais sur ta page de discussion, on peut contacter d'autres projets. J'ai pris l'exemple de arrondissement of Bonn (Q19259655) parce que je suis tombé dessus mais arrondissement of Fougères (Q23018450) est exactement dans le même cas. Cdlt, VIGNERON (talk) 07:00, 23 May 2016 (UTC)
@TomT0m: : « Ça permet de virer tout ce qui est "province romaine" en même temps que toutes les anciennces entités administratives française sans trop se prendre la tête à savoir si quelqu'un a rajouté une date de fin/une déclaration de destruction/dissolution ou que sais-je sur toutes les provinces romaines » sauf que tu es quand même obligé de vérifier la date de fin dans tous les cas, pour enlever les entités qui ont été recréées ensuite. En fait, la phrase que je cite est une des meilleures raisons pour laquelle il ne faut jamais utiliser de tels éléments dans instance of (P31) : c'est trompeur et laisse croire à une fausse facilité... En plus de n'avoir aucun sens, sémantiquement (de même qu'on ne va pas ajouter « cadavre » comme instance of (P31) sur tous les humains morts) -Ash Crow (talk) 23:04, 23 May 2016 (UTC)
@Ash Crow: Euh, les provinces romaines tu peux raisonnablement être certain qu'il n'y en a plus étant donné qu'il n'y a plus d'empire romain. Que des divisions administratives aient été recrées avec le même nom c'est certain mais ce sont des entités de nature bien différentes. Les entités recrées je suis pas du tout convaincu que ce soit un problème en pratique. Pour la plupart, celle qui ont disparu depuis longtemps, le fait qu'il y ait eu une pose dans leur existence ne change pas grand chose pour nous. author  TomT0m / talk page 06:30, 24 May 2016 (UTC)
@TomT0m: Ton approche est limitée: tu considères uniquement l'époque présente comme critère de définition. Comment est-ce que l'on fait si on veut les anciennes entités en se plaçant dans un point temporal passé ? Par exemple quelles sont les provinces romaines en l'an 100 ? Avec ta classe ancienne province romaine, tu crées un paradoxe temporel en considérant que toutes les provinces romaines sont d'anciennes entités géographiques. Seule l'approche avec date de début et date de fin est neutre par rapport au point de référence temporel qui est définition arbitraire. Snipre (talk) 18:06, 24 May 2016 (UTC)
@Snipre: J'ai jamais dit que c'était la panacée. Mais je ne crée pas de classe "ancienne province romaine", je met simplement la classe "province romaine" en sous classe de "ancienne entité administrative". Ça n'a pas grand chose à voir, et il n'y a pas de paradoxe puisque les provinces romaines sont de toutes façon disparues et ne renaîtront certainement pas. author  TomT0m / talk page 19:20, 24 May 2016 (UTC)

Propriétés relatives à la France[edit]

Je vous annonce la création de la palette « France properties » après l'Australie, la Belgique, la République Tchèque, l'Allemagne, l'Indonésie, l'Italie, l'Espagne et le Royaume-Uni.

N'hésitez pas à ajouter les propriétés qui auraient été oubliées !

Tubezlob (🙋) 12:03, 19 August 2016 (UTC)

Le Retour de la Revanche des cantons français II : Le retour ![edit]

Pwet,

Faute de propriété reflétant correctement ce qu'est un canton pour une commune, je me suis permis d'en proposer la création. L'usage en est certes très spécifique, mais pas pour autant inutile.

J'apprécierais énormément des commentaires (argumentés, hein :tongue:) sur Wikidata:Property proposal/french canton !

Notez aussi qu'il s'agirait d'une propriété spécifique, dérivée d'une propriété générique "recouvrement territorial", aussi proposée

Alphos (talk) 13:14, 11 September 2016 (UTC) (cross-posté sur le Bistro)

Naissance et décès en France[edit]

Bonjour VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France,

Alors que l'on s'amusait à visualiser les lieux de morts des bretons avec Ash Crow, j'ai remarqué qu'il y avait quelques lieux de morts dans des départements voir en France (Q142). Il y a quelques personnes où c'est légitime (typiquement des personnes mortes il y a plusieurs siècles où il y a réellement une incertitude) mais il y a aussi et surtout de nombreux cas où ce n'est pas justifié (et qui fais râlé les wikipédiens avec raisons). Je pose donc ici quelques requêtes qui j'espère seront corrigées par la légendaire force collaborative des wikidatiens Face-wink.svg

#Naissance en France (1137 résultats au 29-09-2016)
SELECT ?item ?itemLabel ?date WHERE {
	?item wdt:P19 wd:Q142 .
  	OPTIONAL { ?item wdt:P569 ?date }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}

Try it!

#Décès en France (388 résultats au 29-09-2016)
SELECT ?item ?itemLabel ?date WHERE {
	?item wdt:P20 wd:Q142 .
  	OPTIONAL { ?item wdt:P570 ?date }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}

Try it!

#Naissance dans un département, sauf Paris (283 résultats au 29-09-2016)
SELECT ?item ?itemLabel ?date WHERE {
	?item wdt:P19/wdt:P31 wd:Q6465 .
	minus { ?item wdt:P19 wd:Q90 }.
  	OPTIONAL { ?item wdt:P569 ?date }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}

Try it!

#Décès dans un département, sauf Paris (232 résultats au 29-09-2016)
SELECT ?item ?itemLabel ?date WHERE {
	?item wdt:P20/wdt:P31 wd:Q6465 .
	minus { ?item wdt:P20 wd:Q90 }.
  	OPTIONAL { ?item wdt:P570 ?date }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}

Try it!

Cdlt, VIGNERON (talk) 11:52, 29 September 2016 (UTC)

Bonne idée. Ceci dit, c'est toujours mieux d'avoir le lieu le plus précis. D'ailleurs, je me suis permis d'insérer la date dans les query.
--- Jura 12:06, 29 September 2016 (UTC)

Nouveau sous-projet : Élus[edit]

Bonsoir. Un court message pour signaler que j'ai créé le sous-projet Élus consacré aux politiciens français. -- Envlh (talk) 17:43, 4 December 2016 (UTC)

Élément super bizarre[edit]

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France

Bonjour,

Je viens de tomber sur département (Q15631874) (en regardant les subclass of (P279) de administrative territorial entity of France (Q192498) car sa description était « canton français » !?! déjà ça commençait très mal) et je ne suis pas sur de savoir quoi en faire. Mon idée de départ était de fusionner cet élément avec departments of France (Q6465) mais quand je vois l'utilisation qui en fait, je me dit qu'il a minima faire un sacré ménage dans les utilisations d'abord (au pire du pire, à faire au karcher en remplaçant tout les département (Q15631874) par des department (Q643589)).

Sauf que je me rends compte que les descriptions en anglais et en espagnol introduisent une subtilité par le biais de « French-language » et « francófonos » et du coup, si je comprends bien la logique, la seule correction à faire serait de subclass of (P279) de administrative territorial entity of France (Q192498) (et peut-être ajouter no label (P2439) = French (Q150)) mais ai-je bien compris et cette subtilité est-elle vraiment pertinente et nécessaire ?

Est-ce que quelqu'un pourrait jeter un coup d’œil et me donner son avis ?

Cdlt, VIGNERON (talk) 19:21, 17 December 2016 (UTC)

@VIGNERON: Je suis assez d'accord que l'on devrait fusionner département (Q15631874) avec department (Q643589) et departamento (Q1806767). Il me semble que c'est le même truc, dans le sens général du moins. Je remarque cepandant que departamento (Q1806767) a des interwikis, département (Q15631874) a peut être été créée en symétrie à l'autre. --Fralambert (talk) 20:52, 17 December 2016 (UTC)

code canton INSEE[edit]

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France Est-il nécessaire d'avoir une espace au milieu du INSEE canton code (P2506) ? Le site de l'Insee n'en utilise pas, et la suppression de celle-ci sur Wikidata permettrait de faire un lien vers le site de l'Insee (https://www.insee.fr/fr/recherche/recherche-geographique?geo=CANTON-$1). Tubezlob (🙋) 09:58, 21 December 2016 (UTC)

Bonne question, je sais que c'est une habitude très courante de mettre une espace mais aucune idée d'où cela vient exactement ni si c'est vraiment nécessaire (et d'ailleurs, le code canton - formellement - ce ne sont que les deux derniers chiffres, as-t-on vraiment besoin des quatre chiffres ?). Peut-être @Gzen92: (qui a demandé la création de la propriété) en sait-il plus...
Sinon, il me semble que l'on peux se débrouiller pour faire le lien malgré l'espace ; je sais qu'il existe une solution via https://tools.wmflabs.org/wikidata-externalid-url/ pour quelques propriétés comme ISNI (P213), IMDb ID (P345), HURDAT identifier (P502), E number (P628), SOC Code (2010) (P919), Terminologia Anatomica 98 ID (P1323), CricketArchive player ID (P2698) (à demander à ArthurPSmith). Perso, je préfère que le format ne soit pas choisi uniquement sur des raisons externes et techniques (surtout que la technique peut généralement se débrouiller quelque soit le format).
Cdlt, VIGNERON (talk) 10:27, 21 December 2016 (UTC)
J'avais fait la démarche de la création de cette propriété sur demande de @Pino~eowiki:. Gzen92 [discuter] 10:47, 21 December 2016 (UTC)
Y a-t-il des documents de l'Insee qui mettent des espaces ? Autant utiliser le code original produit par l'Insee…
Je pense que le code canton est bien l'ensemble des quatre ou cinq chiffres, comme pour les communes (où il n'y a pas d'espaces d'ailleurs). Cela permet de les identifier au niveau national.
J'ai donc bien l'impression qu'il faudrait supprimer ces espaces.
Tubezlob (🙋) 11:19, 21 December 2016 (UTC)
D'ailleurs, pour la proposition du code arrondissement INSEE, j'ai supprimé l'espace que j'avais mis au début dans l'exemple. Cette conversation concerne donc aussi les arrondissements. Tubezlob (🙋) 11:23, 21 December 2016 (UTC)
@Tubezlob: Ce que l'insee nomme code canton stricto sensu est bien à comprendre au sens propre et « au sein du département » donc sur 2 chiffres (le site de l'INSEE ayant changé j'ai du mal à retrouver le nouvel équivalent des pages de définition que je consultais fréquemment...), même chose pour le code commune ou arrondissement d'ailleurs. Du coup, dans les documents INSEE/COG, le code est parfois (souvent ?) séparé, par exemple sur deux colonnes. Ceci dit, c'est un détail et il est effectivement infiniment plus logique de mettre le code sur 4 chiffres avec le code département au début : le code est ainsi unique et permet d'établir des contraintes de vérifications. Reste la question de l'espace qui me semble plus correct mais cela repose plus sur un sentiment que sur des références (et sur la lisibilité). @Pymouss, Roland45: un avis d'experts sur la question ? Cdlt, VIGNERON (talk) 10:28, 22 December 2016 (UTC)
Pour moi, l'espace n'est pas nécessaire. Pymouss (talk) 12:54, 22 December 2016 (UTC)

Pour moi aussi, l'espace n'est pas nécessaire. Pour répondre à la question, il faut se reporter au fr:code officiel géographique qui est la référence pour la nomenclature de toutes les divisions administratives françaises. Établi par l'Insee, il rassemble les codes et libellés des communes, des cantons, des arrondissements, des départements, des régions, des collectivités d'outre-mer, des collectivités territoriales à statut particulier (Métropole de Lyon) et des pays et territoires étrangers au 1er janvier 2016 pour la dernière version. Il a périodiquement évolué depuis sa création en 1941 (voir son histoire ici).

Le descriptif de sa structure est ici. Les principaux champs qui nous intéressent sont les suivants :

Nom Désignation en clair Nb de caractères
REG Code région 2
DEP Code département 3
COM Code commune 3
AR Code arrondissement 1
CT Code canton 2

Dans toutes les tables d'appartenance géographique, ces codes apparaissent dans des colonnes séparées. Pour une représentation compacte dans un texte on concatène les codes de divisions sans espace. Ainsi pour codifier une commune on concatène DEP & COM, pour un arrondissement DEP & AR, pour un canton DEP & CT. Ce qui est important est de respecter le nombre de caractères. Certaines représentations (comme ici peuvent laisser penser à un espace, mais les codes sont en colonnes. Cordialement.Roland45 (talk) 14:18, 22 December 2016 (UTC)

Merci Pymouss et Roland45 pour les avis et explications. D'accord pour ne pas mettre l'espace (tout comme pour le code commune d'ailleurs). Cdlt, VIGNERON (talk) 14:25, 22 December 2016 (UTC)
Merci à vous. VIGNERON comment faire pour supprimer les espaces maintenant ? J'ai essayé sur QuickStatements mais c'est impossible de modifier, je ne peux qu'ajouter. Faut-il faire la demande à un robot ? Tubezlob (🙋) 14:56, 22 December 2016 (UTC)
Si le fait d'enlever l'espace dans la propriété INSEE canton code (P2506) est bon pour tout le monde, je peux lancer la tâche avec mon bot. Cordialement, Gzen92 [discuter] 16:32, 22 December 2016 (UTC)
✓ Done c'est Noël avant l'heure Face-wink.svg. Gzen92 [discuter] 13:54, 24 December 2016 (UTC)
@Gzen92: Merci et joyeux Noël en retard ! Tubezlob (🙋) 20:13, 26 December 2016 (UTC)
@Gzen92: merci et bonnes fêtes ! Cdlt, VIGNERON (talk) 14:39, 29 December 2016 (UTC)

Nouvelle propriété ?[edit]

Bonjour,

J'ai fait une demande de création de propriété concernant les ZNIEFF, c'est ici Wikidata:Property proposal/ZNIEFF Code. Vos avis sont bienvenus. El Caro (talk) 12:11, 15 January 2017 (UTC)

P131 le retour[edit]

Bonjour,

Je poste ici pour élargir la discussion. VIGNERON a entrepris d'utiliser located in the administrative territorial entity (P131) pour placer des communes dans des communautés de communes. Exemple :

< Tuchan (Q495312) View with Reasonator View with SQID > located in the administrative territorial entity (P131) View with SQID < no label (Q28264241) View with Reasonator View with SQID >

J'y vois deux problèmes :

Il faudrait réserver les located in the administrative territorial entity (P131) des communes, à mon avis, à seulement deux choses : départements ou arrondissements (et éventuellement anciens cantons pour les petites communes qui étaient incluses dans un seul canton). Sinon, ça va être le bazar total et ça va compliquer les requêtes et les bots vont changer les églises de département. El Caro (talk) 12:32, 21 January 2017 (UTC)

Merci El Caro de relancer cette discussion. J'avais lancé de mon côté une discussion sur Wikidata talk:WikiProject France/Communes#Intercommunalité fin décembre sans réelles réactions.
Sur le principe, je laisse de plus expert que moi (Pymouss, Roland45, Richardbl ?) confirmer ou infirmer mais contains administrative territorial entity (P150)/located in the administrative territorial entity (P131) me semble plus juste que has part (P527)/part of (P361).
Pour ton problème concret, il me semble d'une part qu'il suffit d'affiner la requête (je regarde et je te propose une requête plus précise rapidement) et d'autres part que c'est plutôt au niveau de et que se situe le problème (on retombe sur la même question que l'on a déjà eu moultes fois - notamment pour les cantons - l'utilisation de located in the administrative territorial entity (P131) est-elle permise quand une entité n'est que partiellement située dans une autre entité, la tendance est plutôt sur le non mais cela n'a jamais été clairement acté il me semble).
En attendant des éléments de réponses à cette discussion, je ne touche évidemment plus aux intercommunalités (et je ne peux que suggérer aux autres de faire de même).
Cdlt, VIGNERON (talk) 12:57, 21 January 2017 (UTC)
Bonjour à tous.
Il ne me semble pas que la question soit d'utiliser telle ou telle propriété (P150 ou P131) pour définir la notion d'appartenance, mais plutôt l'usage que l'on veut en faire ensuite.
C'est une question d'ensembles. La difficulté vient de l'interprétation de la notion d'inclusion qui peut être soit totale ou partielle. Trois cas se présentent :
  • Si une division administrative A est entièrement incluse dans une division B qui elle-même est incluse dans une division C, alors bien entendu A est inclus dans C (cas classique).
  • Par contre si A est incluse dans B qui est partiellement incluse dans C1 et partiellement dans C2 (ex : B étant une intercommunalité interdépartementale et C1 et C2 des départements différents), alors on ne peut pas déduire que A est dans C1 ou C2;
  • De même si A est partiellement incluse dans B1 et dans B2 (ex : A est une commune, B1 et B2 deux cantons différents), alors on ne peut pas en déduire que A est plus dans B1 que dans B2 et on doit mettre dans l'Infobox les deux cantons.
En fait que l'on utilise contains administrative territorial entity (P150) ou son inverse located in the administrative territorial entity (P131), on a le même problème d'inclusion partielle ou totale.
Concernant les cantons le cas est réglé avec les fractions cantonales qui sont des divisions infracommunales. Pour info la création en nombre de communes nouvelles remet en avant cette problématique : le nombre de fractions cantonales est passé au 1er janvier 2017 (géométrie territoriale du 1er janvier 2016) de 609 à 651 du fait de la création de communes nouvelles issues de la fusion de communes appartenant à des cantons différents. La liste exhaustive des fractions cantonales est dans ce tableau. Les fractions cantonales n'ayant pas d'article n'ont pas d'élément wikidata. Il n'empêche que c'est une notion définie par l'Insee et que cela résoudrait, selon mon point de vue les problèmes d'inclusions et de sous-inclusions dans Wikidata. La question a semble-t-il été traitée dans cette discussion (Verdy p décrit d'ailleurs très bien cette notion de fraction cantonale) et je ne sais ce qu'il en est advenu.
De même on peut très bien inventer des fractions d'intercommunalités (par département) et on aurait aussi pas de pb pour faire des extractions ciblées. Noter qu'il existe quelques intercommunalités à cheval sur 3 départements qui peuvent être réglées avec la même solution : 3 fractions d'intercommunalités.Roland45 (talk) 17:46, 21 January 2017 (UTC)
Je pense qu'il n'est pas nécessaire de tordre la réalité avec des concepts aussi alambiqués. Une commune appartient totalement à un département et, à de rares exceptions, à une intercommunalité : le binôme contains administrative territorial entity (P150)/located in the administrative territorial entity (P131) est donc clairement adapté. Comme l'explique très bien Roland, cette double appartenance ne signifie pas que la communauté est entièrement comprise dans un seul et seul département, ni, à plus forte raison, que toutes les communes de l'EPCI sont membres du (ou des) département(s) / canton(s) / arrondissement(s) / diocèse(s) au(x)quel(s) appartient l'EPCI. Un article de wikipédia peut être utile : Syllogisme.
Il ne me semble donc pas nécessaire de modifier la base pour répondre à une question mal posée. Pymouss (talk) 20:58, 21 January 2017 (UTC)

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France

Deuxième épisode.
En parallèle de cette discussion, j'ai discuté avec Pymouss et Nono314 de l'utilisation de capital (P36) pour les intercommunalités et de son remplacement par headquarters location (P159) et étant tout les trois d'accords, j'ai demandé à un bot d'effectuer le remplacement (ce qui a été fait). Mais du coup, El Caro pointe une incohérence : si on considère que les intercommunalités sont des institutions - pour lesquelles headquarters location (P159) est plus pertinent que capital (P36) - est-ce qu'il ne serait pas plus logique d'utiliser has part (P527)/part of (P361) plutôt que contains administrative territorial entity (P150)/located in the administrative territorial entity (P131) ? (je parle ici de situer les intercommunalités par rapport à leurs communes, la situation des intercommunalités par rapport aux départements étant une autre question ; personnellement, je proposerait bien de ne pas situer les intercommunalités par rapport aux départements, l'information étant déjà présente dans les éléments sur les communes cela me semble de toute façon inutilement redondant).
Cdlt, VIGNERON (talk) 16:22, 29 January 2017 (UTC)
On peut ajouter que les intercommunalités sont un type d'EPCI établissement public de coopération intercommunale (Q3591564) et qu'il y en a plein d'autres SIVU, SICOM, SITOM, SICTOM... (voir fr:Établissement public de coopération intercommunale). Si on commence à placer les communes dans des EPCI, il va falloir dire pourquoi les unes et pas les autres et ça va devenir encore plus ingérable (en plus d'être sans doute incohérent comme signalé plus haut). Le rapport "commune/EPCI" est plus proche du rapport "membre d'une association/Association" que de P131. El Caro (talk) 16:43, 29 January 2017 (UTC)

Surveillons les cyrillographes[edit]

Bonsoir,

En farfouillant dans les densités de population pour une requête, je me suis rendu compte que pas mal de communes n'étaient plus placées (P131) dans leur département.

En farfouillant un peu plus, je me suis rendu compte que quelques comptes russophones, biélorussophones (sisi, ça existe), et peut-être d'autres langues, avaient retiré ce qu'ils pensaient être des doublons, par ci par là.

J'ai passé une bonne partie de la soirée à tout remettre en place, en attendant de créer le script pour transférer les P131:canton vers P3179:canton - prochain truc sur ma to-do list, promis.

Alphos (talk) 22:28, 3 May 2017 (UTC)

@Alphos:, pour infox les « cyrillographes » ne sont visiblement pas les seuls responsables, actuellement, il y a 744 communes sans départements :
SELECT ?item ?itemLabel WHERE {
  ?item wdt:P31/wdt:P279* wd:Q484170.
  minus { ?item wdt:P131 ?dpt . ?dpt wdt:P31 wd:Q6465 }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
}
Try it!
Cdlt, VIGNERON (talk) 16:13, 3 July 2017 (UTC)
@VIGNERON: En fait, il faut privilégier cette requête, qui prend en compte les DOM/COM/TOM/TAAF/métropoles/communes disparues/départements disparus. Auquel cas il n'y en avait qu'une à l'instant, Le Havre, déjà corrigé.
Promis juré je parachève mon bot dès que je peux, j'ai juste beaucoup trop d'IRL en ce moment, c'est pas sain. Faudrait arrêter de confier du matériel informatique à des vieux, ils savent pas s'en servir et ça complique la vie à tout le monde ! >_<
Alphos (talk) 15:30, 4 July 2017 (UTC)

Archives départementales[edit]

@Pymouss, Annaig29, Daieuxetdailleurs, Envlh:

Bonjour,

Je vois que l'on a maintenant un élément pour les archives de chaque départements français. Bien. Sauf qu'il y a encore pas mal de travail, les contenus sont encore très inégaux. Typiquement, je viens d'ajouter le BnF ID (P268) de Departmental archives of Ille-et-Vilaine (Q2860457) et je me rends compte que seulement 4 des 99 archives ont cet identifiant... En fait, il n'y a que les propriétés country (P17) (trivial), located in the administrative territorial entity (P131) et coordinate location (P625) à être présentes sur l'intégralité des 99 archives. Voici un requête de comptage des propriétés utilisées sur les archives :

SELECT ?property ?propertyLabel ?propertyDescription ?count WHERE { 
	{
		select ?propertyclaim (COUNT(*) AS ?count) where {
			?item wdt:P31/wdt:P279* wd:Q2860456 .
			?item ?propertyclaim [] .
		} group by ?propertyclaim 
	}
	?property wikibase:claim ?propertyclaim .
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . }
} ORDER BY DESC (?count)

Try it!

On voit que seulement 69 ont un official website (P856), 27 une image (P18) (là pas étonnant vu que les bâtiments sont souvent récents et donc sur-protégés par le droit d'auteur, après il y a possibilité comme pour Departmental archives of Ille-et-Vilaine (Q2860457) de ruser et de mettre une photo d'un ancien bâtiment), etc. (en allant decrescendo).

De plus, je suis un peu gêné par le confusion entre les archives-bâtiments et les archives-insitution-service départemental. D'ailleurs, on voit que Departmental archives of Somme (Q2860501), Departmental archives of Saône-et-Loire (Q19606452) et Departmental archives of Doubs (Q2860517) ont pour instance of (P31), {{Q18142}, architectural structure (Q811979), convent (Q1128397) en plus de departmental archives (Q2860456). Et pour plusieurs autres départements, il y a déjà deux éléments (Departmental archives of Jura (Q19606462) et no label (Q21619550)). Dans quelques cas, c'est plutôt perturbant, comment gérer les archives multi-sites et à quoi fait référence owned by (P127) ? Enfin, les propriétés PSS-archi ID (P1838), architect (P84) ou heritage designation (P1435) (etc.) sont prévues pour des bâtiments mais ISNI (P213) ou BnF ID (P268) (etc.) sont prévus pour des institutions.

Je propose donc de clairement distinguer les deux concepts.

Cdlt, VIGNERON (talk) 16:15, 3 July 2017 (UTC)

Wikidata:WikiProject France/Intercommunalités[edit]

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France

Pour information, j'ai lancé un nouveau sous-projet sur l'objet très spécifique que sont les intercommunalités : Wikidata:WikiProject France/Intercommunalités.

Cdlt, VIGNERON (talk) 11:22, 26 November 2017 (UTC)

Établissements de rattachement des unités de recherche du CNRS[edit]

Bonjour,

Avez-vous une idée sur les propriétés adéquates pour indiquer les établissements de rattachements d'unités de recherche du CNRS? Par exemple, pour Réseau sur le stockage électrochimique de l'énergie (Q47463068), la page du CNRS liste un certain nombre d'institutions (dont le CNRS) qui ont aussi des items Wikidata. Quelle serait la bonne manière d'importer ces relations? J'ai utilisé parent organization (P749) et subsidiary (P355) en important GRID (Q27768150) mais je ne suis pas sûr que ce soit le mieux pour ces relations particulières.

Pintoch (talk) 11:43, 22 January 2018 (UTC)

Rejoindre le WikiProject France/Églises/[edit]

Bonjour à tous, Au sein du laboratoire MAP (UMR CNRS/MCC 3495), nous travaillons sur un projet exploratoire autour du "petit patrimoine"/patrimoine mineur de la région Provence-Alpes-Côte-d'Azur. Cette plateforme appelée Territographie : http://territographie.map.cnrs.fr/, permet de relayer les initiatives citoyennes autour de 3 collections : chapelle rurales, agriculture/élevage et artisanat et pratiques commerciale. C'est autour de la collection des chapelles rurales que nous aurions aimé apporter notre contribution, à travers le groupe WikiProject France/Églises. Serait-il possible de rejoindre le groupe, en ayant créé un identifiant au préalable?

Merci d'avance! Et à très bientôt,

Ayack Manu1400 Jura VIGNERON Marianne Casamance Tubezlob Laurent Jerry

 – The preceding unsigned comment was added by Territo13 (talk • contribs).

Bonjour Territo13,
Pour rejoindre le groupe, il y a juste deux choses à faire :
  1. participer librement en créant ou modifiant des items ;
  2. jurer devant témoins que le plus beau département de France n'est pas le 13 mais le 66.
Et c'est tout ! --El Caro (talk) 11:14, 28 March 2018 (UTC)
@Territo13: Bonjour, j'ai ajouté votre nom d'utilisateur sur la liste des participants. On peut sans problème faire une demande de propriété pour vos identifiants. Je suppose que vous parlez de ce type de fiche : http://territographie.map.cnrs.fr/position/fichePosition416.html. Si c'est bien le cas, on peut se charger de faire cette demande avec pour titre « identifiant Territographie d'une chapelle rurale » et comme format d'URL http://territographie.map.cnrs.fr/position/fichePosition$1.html où $1 représente l'identifiant numérique. La propriété pourra être créée au plus tôt dans une semaine (c'est le délai minimum requis).
Pour ajouter cet identifiant aux chapelles déjà repertoriées ou créer de nouveaux éléments, nous disposons de l'outil Mix'n'match dans lequel on importe simplement une liste des identifiants avec leur nom (voir par exemple pour le site Clochers de France).
Tubezlob (🙋) 11:57, 28 March 2018 (UTC)

Bonjour, merci à vous El Caro et Tubezlob pour votre accueil, et vos réponses! Effectivement l'objectif serait de pouvoir créer un identifiant Territographie pour les chapelles rurales avec comme format d'URL : http://territographie.map.cnrs.fr/position/fichePosition$1.html. Comment faire pour effectuer cette demande ? L'outil Mix'n'match nous semble également très intéressant pour établir des liens entre les différents référentiels/sites. En attendant la validation de la demande de propriété, nous pouvons commencer à créer et des modifier des items. Merci aussi au contributeur qui a créé la fiche du laboratoire MAP (UMR CNRS/MCC 3495) :)

@Territo13: Bonjour, voici la demande de propriété : Wikidata:Property proposal/Territographie ID. D'ici une à deux semaines, elle sera créée et nous pourrons tous l'utiliser.
N'hésitez pas à nous poser des questions sur n'importe quel sujet, notamment sur les possibilités de créer semi-automatiquement des éléments ou d'ajouter des déclarations (je pense notamment à QuickStatements), il est très apprécié qu'une structure de recherche apporte ses connaissances précieuses au projet Wikidata !
Tubezlob (🙋) 19:36, 29 March 2018 (UTC)
Voici toutes les chapelles de Provence-Alpes-Côte d'Azur possédant un élément Wikidata avec des coordonnées : https://tools.wmflabs.org/monumental/#/list/15104?c=44.0250:5.9031:8&type=108325 (il y en a 421 pour l'instant). Tubezlob (🙋) 19:52, 29 March 2018 (UTC)

Bonjour à tous ! Ayack Manu1400 Jura VIGNERON Marianne Casamance Tubezlob Laurent Jerry Et merci de votre aide pour la création de la propriété Wikidata:Property proposal/Territographie ID. Nous avons saisi quelques nouvelles chapelles dans la base Wikidata, mais étant donné le nombre d'occurences, nous aimerions tester l'outil d'import de données Mix'n'match. J'ai fait le test sur un petit jeu de données, en les structurant de la manière suivante :

157;chapelle Notre-Dame-des-Champs de Selonnet;Selonnet, Alpes de Haute-Provence


J'obtiens le message d'erreur suivant : ERROR: Less than three coulmns on row 1: 157;chapelle Notre-Dame-des-Champs de Selonnet;Selonnet, Alpes de Haute-Provence Est-ce une erreur dans la structuration des données ? Avez-vous des conseils à nous donner pour réussir notre import ? Merci à tous!  – The preceding unsigned comment was added by Territo13 (talk • contribs).

Bonjour @Territo13:,
Je n'utilise pas cet outil, mais ne faut-il pas séparer les colonnes par des "tab" plutôt que des points-virgules ? Normalement, un copier-coller depuis un tableur le fait tout seul. --El Caro (talk) 14:16, 24 April 2018 (UTC)

Bonjour @El Caro:, merci infiniment pour votre aide, en effet, il fallait bien utiliser les tabulateurs et non les points-virgules comme séparateurs! L'export fonctionne :)

Principaux établissements d'enseignement supérieur[edit]

https://www.data.gouv.fr/fr/datasets/principaux-etablissements-d-enseignement-superieur-mesr/ Situation au 1er janvier 2015. Le fichier date un peu, mais il comporte des alignements avec Wikidata, et plein de données (genre le nombre d'élèves en 2014, 2015, …) :-)

Teolemon (talk) 13:37, 29 August 2018 (UTC)

uai
uo_lib
sigle
type_d_etablissement
secteur_d_etablissement
url
coordonnees
rattachement
rattachement_identifiants
dernier_decret_legifrance
localisation
com_code
com_nom
uucr_id
uucr_nom
dep_id
dep_nom
aca_id
aca_nom
reg_id
reg_nom
mention_distribution
adresse_uai
lieu_dit_uai
boite_postale_uai
code_postal_uai
localite_acheminement_uai
pays_etranger_acheminement
numero_telephone_uai
siret
identifiant_grid
identifiant_eter
statut_juridique_court
statut_juridique_long
qualification_court
qualification_long
compte_facebook
compte_twitter
compte_flickr
flux_rss
compte_linkedin
compte_pinterest
compte_france_culture
compte_scribd
compte_scoopit
compte_tumblr
compte_viadeo
compte_dailymotion
compte_vimeo
compte_youtube
compte_googleplus
autres
mooc
statut_operateur_lolf
libelle_mission_chef_de_file
identifiant_programme_lolf_chef_de_file
libelle_programme_lolf_chef_de_file
identifiants_autres_programmes_lolf
libelles_autres_programmes_lolf
association
association_identifiants
identifiant_wikidata
element_grid
identifiant_orgref
identifiant_isni
element_isni
element_fundref
reg_id_old
reg_nom_old
uo_lib_en
element_wikidata
inscrits_2010
inscrits_2011
inscrits_2012
inscrits_2013
inscrits_2014
typologie_d_universites_et_assimiles
implantations
inscrits_2015
compte_instagram
url_en
url_cn
siren
identifiant_funding_data
wikipedia
url_es
url_de
anciens_codes_uai
@Teolemon: oui j'ai déjà travaillé avec cette excellente base, pour importer un certain nombre de colonnes avec OpenRefine (SIREN, comptes de réseaux sociaux, identifiants variés). J'ai utilisé la méthode décrite ici: Wikidata:Tools/OpenRefine/Editing/Tutorials/Basic_editing (le tuto est écrit pour une base anglaise mais c'est essentiellement le même genre de données). − Pintoch (talk) 07:39, 30 August 2018 (UTC)

Mettre les arrondissements uniquement en P131[edit]

Bonjour,

Une discussion sur la page de discussion de located in the administrative territorial entity (P131), propose (notament par Сидик из ПТУ) de mettre uniquement les arrondissements en P131 pour les communes (et concepts similaires). Actuellement, les communes sont toutes dans l'arrondissement et dans le département (sans compter tout un tas de problèmes avec - notamment mais non exclusivement - les cantons et les intercos mais c'est un autre sujet), doit-on conserver cette redondance ou non ?

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France qu'en pensez-vous ? si possible, merci d'expliciter vos avis.

Cdlt, VIGNERON (talk) 13:16, 17 September 2018 (UTC)

Le problème des arrondissements, c'est qu'ils ne sont pas très parlants pour le commun des citoyens et, en plus, qu'ils ne sont pas très stables dans le temps (il y a eu des vagues de modifications au 1er janvier 2017) qui sont passées complètement inaperçues, sauf pour les lecteurs quotidiens des RAA). Même au sein de l'administration d'État, leur rôle est de moins en moins liés au territoire : un sous-préfet est souvent compétent pour un sujet particulier sur l'ensemble du département (par exemple, le sous-préfet de Saint-Malo est compétent pour l’accueil des gens du voyage sur toute l'Ille-et-Vilaine) et n'est plus un relais sur un territoire plus petit de l'ensemble de l'action du préfet. Leur découpage est la plupart du temps désormais calqué sur les périmètres des intercommunalités et peut donc être amené à évoluer dans le futur plus rapidement que par le passé. Jadis basés sur des cantons relativement stables (sauf en zones urbaines) jusqu'au big-bang de 2014, c'est devenu une division administrative fluctuante territorialement et dont le rôle est de moins en moins important dans l'action publique. Si, jusqu'à preuve du contraire, je n'ai pas encore vu de réel projet prévoyant leur disparition, on peut quand même légitimement penser que leur avenir est derrière eux.
Pratiquement, quand on voit le nombre considérable de communes qui, plus de trois ans après, ne sont pas encore localisées dans le bon canton sur Wikidata (j'en ai encore trouvé une hier) alors que le ménage a été relativement vite fait sur Wikipédia, je doute fort de la capacité de Wikidata à suivre toutes les évolutions de découpage d'arrondissements, dont certains n'ont été mis à jour que près d'un an après sur frwp. Là encore, ça ne plaide pas en faveur du recours au seul arrondissement en P131.
Enfin, je ne pense pas que ça tienne très longtemps : les contributeurs occasionnels de Wikidata s'empresseront d'ajouter le référent administratif qui reste le plus parlant pour chaque résident français : le département. Donc, si on souhaite maintenir la cohérence dans la base de données, on va au devant d'inutiles et perpétuelles opérations de maintenance, ce qui fait que cette solution engendrerait plus de dépense de temps et d'énergie que de ramener à la logique un ou deux technocrates russes.
Bref, restons-en aux départements et aux EPCI en P131, car ils correspondent à de vrais échelons d'action publique, et laissons cantons et arrondissements dans les mémoires des découpages administratifs (et donc présents à ce titre dans WD, sans en faire des pivots de la hiérarchie administrative).
Bien cordialement, Pymouss (talk) 18:18, 17 September 2018 (UTC)
Je serais curieux de savoir quel pourcentage des Français est au courant de l'existence de ces arrondissements. Clairement ça ne parle pas à grand-monde, moi le premier. Je ne sais pas quelle est la bonne solution, mais en tout cas je suis fortement contre la suppression des départements des communes. — Ayack (talk) 18:41, 17 September 2018 (UTC)
@Pymouss, Ayack: je comprends l'argument de la méconnaissance mais est-ce vraiment pertinent pour cette discussion ? Mon point de vue est que la majorité des gens ne connaissent pas la majorité des informations, d'autant plus quand il s'agit de l'organisation administrative française (combien de fois j'ai du expliquer la situation des outremers...). En plus, pour la réutilisation par exemple dans les infoboxes sur Wikipedia, il est facile d'afficher (en plus ou à la place) le département. Quant à la mise à jour, le fait que la situation actuelle soit peu claires et que l'on stocke plus de valeurs qu'il n'est strictement nécessaire, ne peut que compliquer la situation, on essaye de courir deux lièvres à la fois (et même 5 lièvres et 3 lapins...). J'imagine que si on retire les départements pour se concentrer uniquement sur les arrondissements (et les autres administrations éventuellement, la question n'est évidemment pas de ne garder uniquement les arrondissements), cela sera forcément bénéfique à la mise à jour des arrondissement, non ? Cdlt, VIGNERON (talk) 09:00, 20 September 2018 (UTC)
@VIGNERON: Après réflexion, je revois ma position. Ne mettre que l'arrondissement risque de me compliquer un peu la vie (sur WD), mais ça me semble quand même être la solution la plus propre et la plus exacte. OK donc pour retirer le département (et j'espère ensuite les cantons...). — Ayack (talk) 13:16, 20 September 2018 (UTC)
Je m'excuse d'avoir écrit en français via Google-Translator, mais j'aimerais vous poser quelques questions. 1) Comment proposez-vous de conserver la chronologie de la propriété communale des arrondissements et des chaises dans le Wikidat? Vous pouvez discuter de leur rôle réel dans la politique et dans la vie des gens, mais ils existaient et existaient toujours, leur chronologie devrait toujours être là. En d'autres termes, quelqu'un et, d'une manière ou d'une autre, doivent encore suivre ces changements et apporter les modifications appropriées aux éléments. 2) Pourquoi, pour tous les autres pays, où les frontières et les régions peuvent également changer fréquemment, une autre approche sera-t-elle utilisée? Qu'importe que quelque chose soit méconnaissable pour les utilisateurs? Nous parlons maintenant d'une base de données pour les robots, pas pour les personnes. Dans les articles de Wikipedia, les niveaux des cantons et des arrondissements peuvent être ignorés, mais la logique de P131 est que par cette propriété, une chaîne est construite en fonction des liens aux éléments. Regardez l'élément Krasnodar (Q3646), il entre actuellement dans le Krasnodar Municipality (Q4307501), même s'il ne s'agit que d'une entité formelle, qui ne dit rien à la majorité des habitants de Krasnodar. Cependant, c'est la bonne solution pour la base de données. La proposition de spécifier pour les communes simultanément toutes les unités administratives, y compris celles qui sont subordonnées les unes aux autres, du point de vue de la théorie des bases de données est incorrecte.Сидик из ПТУ (talk) 08:41, 18 September 2018 (UTC)
@Сидик из ПТУ: no problem, write in language you prefer. For your questions:
1) not sure to understand (probably some parts ere lost in the translation), I don't see any problem to have multiples values for the same point in time and the infoboxes works fine with that too.
2) I don't know for other country but France is clearly complicated. For instance, communes are very small and there is more communes in France than in all the rest of Europe (France has ~36000 communes but Germany ~11000, United Kingdom ~10000, Spain ~8000, Belgium 500, etc.). Some administrative units are not transitiv and/or inclusiv, so you can't make a chain or use P131+ in queries. Said more simply you have : A is located in B and B is located in C but A is not located in C :( (it exists in other country but it's more common in France, especially for intercommunalities). Finally, it's sometimes very hard to find a reference to know in what unit is located an other unit, especially for arrondissement. So, it's not just that the arrondissement are not known or used, it's that they are almost unreferencable.
Krasnodar (Q3646) is a city (Q515) (city) and we don't really have city in France, at least we don't have items about cities in Wikidata (and we don't need them, communes are smaller and more precise than cities ; if it was like in France, it would be Krasnodar Municipality (Q4307501) location (P276) Krasnodar (Q3646)).
If you really want only one value in P131, then the more logical would be to only keep the departements (and maybe the intercommunalities but that is an other question we need to sort separatly). So we can either just removed the departemental arrondissements or move them somewhere else (maybe territory overlaps (P3179)). @Pymouss, Ayack: what do you think?
Cdlt, VIGNERON (talk) 10:55, 18 September 2018 (UTC)
OK. 1) Arrondissements and cantons (present or pre-2015) must in any case be somehow indicated in the Wikidata for each commune. Perhaps their role in public or political life is becoming less and less significant, but the fact of their existence and the attachment of communes to them should be preserved here. Therefore, someone will still keep track of their relevance and completeness.
2) Please, give an example, where A (arrondissement) in B, B in C, but A not in C. How many such cases for the whole of France? By the way, a good database would allow to know this by query.
For all other countries there is no difference, we work with cities or something like communes - the rules for filling in P131 in both cases are the same.Сидик из ПТУ (talk) 12:14, 18 September 2018 (UTC)
Communes of Redon Agglomération.
1) indeed, is territory overlaps (P3179) the good property for that?
2) there is plenty of examples (I would say maybe 1000 communes?), for instance : Redon (Q206837) is in Redon Agglomération (Q2989211) which is in 3 départements (Ille-et-Vilaine (Q12549), Morbihan (Q12642), Loire-Atlantique (Q3068)) but Redon (Q206837) is only in Ille-et-Vilaine (Q12549) (same for the 30 others communes of Redon Agglomération (Q2989211) ; see the map, the colours are the 3 départements). And this is a simple and common example (mostly it's intercommunalities, but there is cantons between two arrondissement), there is some much more tricky cases.
Cdlt, VIGNERON (talk) 18:06, 18 September 2018 (UTC)
1) Maybe. 2) OK, intercommunalities like a cantons are bad for P131 and apparently are parallel to the main vertical (commune-arrondissement-department-region). Aren't they? Сидик из ПТУ (talk) 09:30, 19 September 2018 (UTC)
Intercommunalities are less complicated than cantons (at leat there always bigger than communes or city), they're more "vertical" (but verticality is maybe not the good way to look at how administrative units work in France). Cdlt, VIGNERON (talk) 09:00, 20 September 2018 (UTC)

As a general recommendation, I'd suggest to make sure that fairly stable layers are always present in P131. For France, I think these are departments. Furthermore, I don't think one should remove former administrative layers. These just have an end date and normal rank. In case this actually happened: don't add continents there ;) --- Jura 11:06, 18 September 2018 (UTC)

The stability of the data does not matter for the database. On the example of the Soviet Union of the times of Stalin, where the borders of the republics and their regions have changed every six months, for each moment we indicate only the nearest meaning and everything works fine.Сидик из ПТУ (talk) 12:14, 18 September 2018 (UTC)
  • Sounds interesting. Could you do a proof of concept with the Soviet Union? (or with "we" did you mean "you"?). --- Jura 19:02, 18 September 2018 (UTC)
  • Look, in Russian Wikipedia birthplaces in infoboxes are being filled via algorithm that builds a geo-chain (city, regions, country) according to the values of P131 on the specified date of birth of the person (works fine). So, if something is filled not according to the specified order, the place of birth in the card is displayed with an error or without detais (like here). These errors are regularly noticed by users and corrected on the Wikimedia. Moreover, the algorithm is used not only for those born or dead in the USSR or Russia, but also for all other countries. With France, we notice a problem caused by the atypical filling of P131, with other countries there is no such problem.Сидик из ПТУ (talk) 09:24, 19 September 2018 (UTC)
  • @Ayack: this template seems to be using location() from commons:Module:WikidataIB. It looks like they just take a first value of P131 statement (line 1018). If my understanding is correct, it is not only unreliable (order of statements is not fixed), it is plain wrong, because they do not respect P580/P582 qualifiers. --Ghuron (talk) 08:12, 20 September 2018 (UTC)
  • @Ghuron: not exactly, it takes the first *best* value (that's why rank are important) ; but true, if there is several value with the best rank (which is quite common), it still problematic. But in this case, the best way to solve this is to improve the template, not to twist the data into something there not in reality. Cdlt, VIGNERON (talk) 09:00, 20 September 2018 (UTC)
  • @VIGNERON: I would be delighted to hear your ideas how this template can be improved to handle ambiguous P131 statements in Mâcon (Q174247) --Ghuron (talk) 09:12, 20 September 2018 (UTC)
Yes, stability is not the problem here. The most problematic point here is to find one and only value at a given moment if we include all administrative levels (not a problem if we only include départements). For continents, that a very good point as France is the most extended country in the world (and one of the only country to have territories in 5 continents). Cdlt, VIGNERON (talk) 18:06, 18 September 2018 (UTC)
Bonjour the Project France!
I think that P131 is a very bad property, because it has very different meanings. It is a half measure, and not a good one. We should have:
  • either a very general property (location (P276)) into which we put everything: commune, departement, canton, oblast, mountain range (delete mountain range (P4552)), lake or whatever;
  • or create very specific properties, such as "is in the French arrondissement", "is in the French canton (before 2015)" and so on.
I prefer large, generic properties, easier to use and to create queries.
Can a collaborative project take strong decisions and follow them? --El Caro (talk) 18:22, 18 September 2018 (UTC)
As an experiment, we can try this for France, but for the vast majority of other countries everything works fine under the current rules which favorably universal.Сидик из ПТУ (talk) 09:35, 19 September 2018 (UTC)
@El Caro: I would stay with located in the administrative territorial entity (P131) for the arrondissement (not problem there) and I'm not sure a specific property for the cantons would help solve the problem that canton can be smaller or bigger than communes. Cdlt, VIGNERON (talk) 09:00, 20 September 2018 (UTC)

Can we focus on the main question here? cantons, intercommunalities, everything else is an other problem (that need to be solved too but we can't solve everything in one discussion). In P131 for French communes, we put both arrondissement and departement, which is actually redundant. What should we do? We can: 1. statu quo keep the mess as it is, 2. move the arrondissement to some other property (but which one?) 3. remove the departement since they can easily be inferred from the arrondissement. Cdlt, VIGNERON (talk) 09:00, 20 September 2018 (UTC)

Just want to make sure we are on the same page. I don't think I know enough to decided whenever (3) will be better than (2) or vice versa. Obviously members of this project are better prepared to make educated choice. But I strongly object option 1. Despite the fact that some people here think showing so-called "geo-chain" is naive, I can see strong consensus for this in all major wikipedias. It will be much easier if there will be not more than one P131 for any given point of time. In fact data for most countries follow this implicit constraint. Number of ambiguous P131 statements in Italy <1%, in Netherlands <1%, in Germany <2%, in USA <3%, but >15% in France. --Ghuron (talk) 09:48, 20 September 2018 (UTC)
@Ghuron:, yes I agree that 1 is the worst but if we can't decide between 2 and 3, 1 is the default option... 3 is probably the more rational choice but also the more difficult (see objections supra).
By the way, it's not >15%, it's 100% of communes that are ambiguous (which is logical since the statu quo has encouraged to put both the arrondissement and the departement). That said, the arrondissement-departement duplication is easy to filter for an infobox (for example one can just ignore the arrondissement - it works in 99% of the cases - or more thouroughly one can do checks on the duplication), and without the duplication between these two levels there is still more than 10 others administrative levels in France who can cause ambiguity... It will be almost impossible to go under the 1% (especially if we can't decide on the easy problem of arrondissement-departement which is probably the one of the more simple of all).
Cdlt, VIGNERON (talk) 13:06, 20 September 2018 (UTC)
@VIGNERON: So you are saying that infobox should ignore wdt:P131/wdt:P31 wd:Q194203? We definitely can start with that, but it will not help with Mâcon (Q174247) as well as 41K+ items. May be there are some other topics where it is possible to reach consensus? Such as placing P582:March'15 qualifier for all wdt:P131/wdt:P31 wd:Q184188? --Ghuron (talk) 13:28, 20 September 2018 (UTC)
@Ghuron: more or less, what I am saying is: if the infobox can't deal with multiple value (which is a bad idea but I understand that multiple values are harder to deal with), then ignoring the arrondissement of France (Q194203) can be an easy solution (not the canton of France (until 2015) (Q184188), like I said, this is an other matter) ; true, it's not perfect but it's better already (and logical since everybody, the French people first, ignore what the h*ll is an arrondissement of France (Q194203)). We can reach consensus on other matters but each level has it specificities so I would prefer to deal with them separately. The idea of placing placing P582:March'15 is interresting but very wrong as it can be any point in time between 1790 and 2015 ; but yes, ideally, we need to add a start time (P580) and a end time (P582) as qualifiers for all these values. Cdlt, VIGNERON (talk) 13:47, 20 September 2018 (UTC)

Communes et leurs localisations[edit]

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Pictogram voting comment.svg Notified participants of WikiProject France

Bonjour à tous,

Par curiosité, je viens de faire une requête générale pour voir dans quoi les communes françaises était localisés. Je savais qu'il y avait des erreurs et que c'était un peu le bazar mais je n'en connaissais pas l'ampleur. Voici donc les résultats (pas mal de boulot mais cela pourrait être bien pire).

See it in Wikidata Query Service

Ce graphique se mettant automatiquement à jour, je me permet de redonner les chiffres et de les commenter. Les deux premiers résultats sont "département" (39437) et "arrondissement" (34634). Je ne reviens pas dessus, la discussion au-dessus concerne déjà ce doublon. Ensuite en deuxième position il y a ancien canton français (36808), et ensuite vient canton français (12563) et là clairement ce n'est pas trop normal, autant pour les anciens cantons, la question peut se poser de les laisser ou non en P131 (je dirais que c'est la moins mauvaise solution malgré tout) autant pour les nouveaux cantons, clairement il me semblait clair pour tout le monde qu'il n'avait rien à faire en P131 (aurais-je imaginer ce consensus ?). Viennent ensuite, communauté de communes (1602), communauté d'agglomération (637), commune de France (242), cela mériterait discussions mais comme pour les anciens cantons, faute de mieux cela semble pas si pire. Par contre je vois district d'Alsace-Lorraine (1513), et là les valeurs actuelles en rang préféré devrait masquer ces valeurs, ce serait à corriger. Ensuite - fort heureusement - les valeurs diminuent rapidement mais il y aurait tout de même un sacré ménage à faire : historic comarca of North Catalonia (Q3573632) (là encore, le rang devrait masquer ces résultats) ; historic comarca of North Catalonia (Q3573632) (idem qu'avant mais au pays Basque au lieu de la Catalogne nord) ; natural region of France (Q572995), high island (Q1161185), archipelago (Q33837), island (Q23442) (là il s'agit des outremers mais selon le cas soit located in the administrative territorial entity (P131) est utilisé au lieu de location (P276), soit le located in the administrative territorial entity (P131) est correct mais le instance of (P31) de la valeur utilisée est incorrect ; je vais commencer par faire le ménage pour ceux-là).

Cdlt, VIGNERON (talk) 13:30, 20 September 2018 (UTC)

La question de la localisation des communes me semble un faux problème que nous nous infligeons à nous-même. Créons une propriété dédiée pour les intercommunalités, une autre pour les départements, une troisième s'il le faut pour autre chose encore et une bonne partie du problème sera réglé. Pour l'instant, les plus geeks d'entre nous veulent tout déduire depuis une propriété unique par des arbres de requêtes compliqués mais tout ce que nous déduisons à la fin, en vérité, c'est que c'est en bordel. Je lis ceci depuis plusieurs années. Thierry Caro (talk) 14:25, 20 September 2018 (UTC)
Comment peux-tu parler de faux problème et conclure dans le même message que c'est le bordel...
On peut effectivement créer une dizaine de propriétés spécifiques, mais cela ne changera absolument rien au problème des valeurs. Parce que c'est bien des valeurs dont je parle ici, c'est indépendant de la propriété : que l'on utilise "localisation administrative" ou "localisation dans le département de" dans les deux cas mettre "île" en valeur est faux. De même, que l'on mette deux valeurs en département (l'ancien et le nouveau) en oubliant de mettre des qualificateurs et d'utiliser les rangs est tout aussi faux quelle que soit la propriété.
De même le problème n'est pas au niveau des requêtes (qui ne sont pas - de très loin - les plus compliquées) puisque ces requêtes fonctionnent pour tout les pays du monde sauf la France, certes la France est particulièrement carabiné au niveau de son organisation administrative mais je doute que cela suffise à expliquer la situation actuelle.
Cdlt, VIGNERON (talk) 09:11, 21 September 2018 (UTC)

Nom officiel des hameaux[edit]

Bonjour,

Roberpl me pose une colle : est-ce que le nom de Hix (Q17182098) est officiel ? Le COG ne mentionne que les divisions supérieures ou égales à la commune, donc pas les hameaux. D'un autre côté, un nom de hameau doit être utilisé par la poste, je suppose, donc est-il quelque part officiel ? --El Caro (talk) 07:55, 6 October 2018 (UTC)

Bon, j'ai trouvé : "Les microtopoymes et les noms de lieux ont-ils une graphie officielle ? La réponse est non." page 12, Jean Bécat (Q9011846). --El Caro (talk) 08:26, 14 October 2018 (UTC)