Archives.

Classe d'une course cycliste edit

Hop, je viens directement ici et je notifie @Snipre: pour parler un peu en français. La définition des classes et les exemples sont visibles ici. Le premier chiffre, 1 ou 2, indique si la course dure un seul jour ou si elle comporte des étapes. Le deuxième chiffre n'est pas vraiment une difficulté, ça représente plus une question d'organisation, par exemple, le Grand Prix de Denain 2016 est désormais en catégorie 1.HC, mais est simple car tout est si plat que je le fais facilement avec mon VTT. Ce second chiffre, ou HC, permet d'indiquer également la part des équipes de différents niveaux qu'il est possible d'inviter. Par exemple, le Triptyque des Monts et Châteaux est assez difficile à courir, mais est en 2.2, et ne peut pas inviter les plus grosses équipes mondiales, alors que le GP de Denain peut inviter 70 % de son plateau en WorldTeams. Je prévois de créer les éléments, mais s'il n'y a pas de propriété, je vais demander la création. Tout doit être le plus simple possible car ces données seront réutilisées à l'intérieur d'un tableau dans le corps de l'article (pour lister les victoires)

Jérémy-Günther-Heinz Jähnick (talk) 12:41, 22 January 2016 (UTC)Reply

Jérémy-Günther-Heinz Jähnick Peux-tu donner un exemple avec tous les paramètres que tu veux ajouter (et un mot d'explication). Et surtout explique si les paramètres sont globaux, c'est-à-dire utilizable pour toutes les courses cyclists. 141.6.11.23 15:18, 22 January 2016 (UTC)Reply

Par exemple, sur 2015 Grand Prix de Denain (Q19249082), j'aimerais rajouter une déclaration Propriété classe d'une course cycliste ayant pour valeur l'élément à créer 1.1. Dans l'article fr:Grand Prix de Denain 2015, l'infobox viendrait ajouter classe et pour valeur 1.1 sous la ligne indiquant la compétition. Et un peu plus tard, dans l'article de la saison d'équipe du vainqueur fr:Saison 2015 de l'équipe cycliste Cofidis, on aurait un tableau reprenant la victoire, construit à partir du même programme que fr:Modèle:Cycling race/listofstages. C'est pour ça que l'indication de cette mention doit se faire comme comme une déclaration habituelle. Ce système permettrait effectivement d'être utilisé pour toutes les courses cyclistes, même les championnats nationaux et les courses nationales. Jérémy-Günther-Heinz Jähnick (talk) 17:47, 22 January 2016 (UTC) Pour en dire un peu plus, sur la création de ce futur tableau, c'est la seule donnée que je ne suis pas encore en mesure d'insérer. Jérémy-Günther-Heinz Jähnick (talk) 17:49, 22 January 2016 (UTC)Reply

À mon avis si les premiers et second nombres sont indépendants (c'est le cas, si je comprends bien) ce serait normal d'avoir deux propriétés distinctes (durée et xxx à nommer). J'ai aussi remarqué qu'il existait single-day road race (Q2912397) mais je pense pas qu'on veuille l'utiliser avec instance of (P31). —Tinm (d) 17:57, 22 January 2016 (UTC)Reply

Ça n'est pas indépendant, l'un ne va pas sans l'autre, voir les articles. Jérémy-Günther-Heinz Jähnick (talk) 18:51, 22 January 2016 (UTC)Reply

Je n'ai pas bien compris, et pas trouvé la réponse dans les articles (parlais tu bien de w:fr:Circuits continentaux de cyclisme ?). Par « pas indépendant », veux-tu bien dire que toute course UCI devrait avoir les deux nombres ? Dans ce cas il peut y avoir des “contraintes” associées aux propriétés indiquant qu'un élément ayant la propriété devrait avoir l'autre (et être P31: course UCI, etc.). Les éléments violant ces contraintes sont détectés comme éronnés et listés sur Database reports/Constraint violations/#propriete. Ce dont je parle est d'avoir 2x3 catégories croisées au lieu de 6 catégories (c'est compréhensible ?). @Snipre: Peux-tu confirmer qu'il est recommandé d'avoir deux propriété distinctes ? —Tinm (d) 19:35, 22 January 2016 (UTC)Reply

@Jérémy-Günther-Heinz Jähnick: Tu peux simplement utiliser instance of (P31) qui est faite pour la classification. Tu peux simplement mettre

⟨ 2015 Grand Prix de Denain (Q19249082)      ⟩ instance of (P31)   ⟨ course de catégorie XXX ⟩

et créer autant de classes course de catégorie XXX que nécessaire. En plus de

⟨ 2015 Grand Prix de Denain (Q19249082)      ⟩ instance of (P31)   ⟨ GP de Denain ⟩

bien sûr. author  TomT0m / talk page 20:26, 22 January 2016 (UTC)Reply

@TomT0m: Pour info, sur le Project chat :
Jérémy-Gunther-Heinz : « ... »
Isno : « nature de l'élément (P31) "HC race" sous-classe de (P279) "cycling race" seems fine to me. »
Jérémy-Gunther-Heinz : « No, we already use nature de l'élément (P31) for the race like Grand Prix de Denain 2015 ==> nature de l'élément (P31) : Grand Prix de Denain. Here, it is something of really secondary. »
Snipre : Use dedicated properties instead of instance of/subclass of like duration.
Tinm : « ... »
On peut éventuellement utiliser les classes, en plaçant instance de Grand prix de Denain en rang privilégié, mais il faut réfléchir aux conséquences. Pas sûr que ce soit le plus pratique. —Tinm (d) 20:48, 22 January 2016 (UTC)Reply

@Tinm: Oui, Snipre et moi on a des vues divergentes sur la classification. J'ai résumé mes vues dans Help:Classification. Utiliser les propriétés générique est souple et puissant, et beaucoup plus cohérent. On a éliminé beaucoup de propriété spécifiques.

Pour le traitement, ça se résume à un "si c'est une course cycliste, alors rechercher à quelle classe de difficulté elle appartient" dans le code de l'infobox. Pour récupérer les classes de difficultés, je prospose de marquer toutes les classes de difficulté avec

⟨ classe machin ⟩ instance of (P31)   ⟨ classe de difficulté ⟩

.

author  TomT0m / talk page 21:21, 22 January 2016 (UTC)Reply

J'ai tendance à penser que le plus important est de maintenir des pratiques cohérentes dans l'ensemble de la communauté. Et je crois que je vais m'arrêter là, je n'ai pas assez d'expérience sur Wikipédia pour juger des pratiques. —Tinm (d) 23:01, 22 January 2016 (UTC)Reply
@Tinm : je peux te faire un topo de mon avis et des avantages / inconvénients (je pense que c'est important parce que comme tu l'as fait fort justement remarquer c'est une question de cohérence du projet)
Utiliser de préférence instance of (P31) et subclass of (P279) pour la classification c'est:
avantages
  • cohérent : on a pas 42 propriétés à connaître pour chacun des domaines, quasi tout est dit dans Help:Classification
  • Simple : quasi tout est dit dans Help:Classification
  • Souple : créer une nouvelle classe, c'est créer un nouvel élément, et c'est infiniment plus rapide que de créer une nouvelle propriété. Et c'est pas du luxe sur Wikidata vu le côté aléatoire de la procédure à l'heure actuelle, c'est assez dûr d'atteindre un concensus.
  • Standard : c'est compatibles avec base de langages de représentation des connaissances
  • Très bien compris philosophiquement avec des notions comme les types/jetons/classes de classes, et ça couvre donc une vaste étendue de domaines (contre exemple, les maths elles mêmes sont plus dures à caser dans ce type de schéma)
inconvénient
  • C'est un peu plus complexe du point de vue traitement de l'information, mais ça se gère très bien en SPARQL ou en lua (cf la discussion qu'on est en train d'avoir avec Jérémy) : la notion de métaclasse permet de filtrer les classes qui nous intéressent dans les différents type de classe.
  • C'est tout ce qui me vient.
@TomT0m: : j'ai compris, les éléments 1.UWT (Q22231106), 2.UWT (Q22231107), 1.HC (Q22231108), 2.HC (Q22231109), 1.1 (Q22231110), 1.2 (Q22231111), 2.1 (Q22231112), 2.2 (Q22231113), 1.Ncup (Q22231114), 2.Ncup (Q22231115), 1.2U (Q22231116), 2.2U (Q22231117), CC (Q22231118), CN (Q22231119) seront au choix ajoutés en instance of (P31). Dans l'infobox (et là, je suis intéressé par le code), ça va se traduire par un exclude de ces valeurs pour la ligne qui indique la course et son numéro d'édition, alors que pour la ligne de la compétition, on va faire un champ concaténé avec part of (P361) et cette classe, où les seules valeurs possibles prises sur P31 seront celles-ci. Et quand on travaillera à générer le tableau des victoires, il suffira simplement de n'accepter que les valeurs précitées pour instance of (P31). Jérémy-Günther-Heinz Jähnick (talk) 10:26, 23 January 2016 (UTC)Reply
@Jérémy-Günther-Heinz Jähnick: J'ai fait ce genre de trucs pour savoir si un élément était membre d'un ensemble de valeur : fr:Module:Wikidata/Références/classes_d'articles. Il faut appeler la fonction "is_in". Si tu veux je peux créer une fonction "filtre" qui prend en paramètre ce genre d'ensemble et qui ne retourne que les éléments qui conviennent (ou pas) dans un autre ensemble de valeur (je crois qu'il y a des fonctions de ce type quelque part dans le (un des sous) module(s) Wikidata. Bon là je suis bloqué /o\ author  TomT0m / talk page 11:12, 23 January 2016 (UTC)Reply
Oui, j'ai vu ça il y a quelques jours. Les RA sont une façon pour certains contributeurs d'en faire taire d'autres, et en général ces contributeurs sont plus doués pour frapper dans le dos des gens que pour être productifs. Isolée, la RA ne sert à rien, son intérêt vient pour les contradicteurs lorsqu'elles forment un casier judiciaire, celui-ci est ensuite utilisé pour demander des blocages de plus en plus longs. La vérité, c'est que tout un tas de contributeurs sont véritablement médiocres, mais parce qu'ils savent se placer aux bons endroits, ils empêchent quiconque de faire un bilan de leurs actions sur plusieurs années. C'est pour cette raison qu'il faut veiller à ce qu'ils ne viennent pas prendre le dessus par ici. Ne pas avoir de vue à long terme n'est pas un crime, mais ça ne doit pas gêner des contributeurs qui vont permettre de développer Wikipédia. Ces débats houleux et ces méthodes me rappellent ce qu'il y avait jusqu'il y a un an, quand un certain Suprememangaka, suppressionniste, était de tous les combats. S'il avait perduré pendant des années, ce n'était pas un hasard : il ne rédigeait jamais d'articles et passait son temps à sociabiliser avec les autres, si bien que dès que quelqu'un le contredisait, les administrateurs tombaient très vite sur cette personne. Quand il s'est fait bannir, il y avait eu des pages et des pages de débats, parce que les contributeurs avaient compris que si on en était arrivé là, c'était parce qu'il avait bénéficié de solides soutiens, qui sont encore là aujourd'hui. C'est pour ça que je n'interviens plus dans ces débats, j'ai compris que c'était la même pièce qui se rejouait à chaque fois, et que certains contributeurs comme Hdetorcy n'ont strictement rien apporté à Wikipédia ces six derniers mois (je me base sur le top 500, et je le fais régulièrement). L'opposition ne sert à rien, c'est du temps qui est perdu, la meilleure solution serait que tout le monde se mette au tour de la table et discute de comment procéder pour passer à Wikidata pour la prise de certaines informations. La nature a horreur du vide, c'est pour ça que l'histoire est un éternel recommencement. Je ferme ma petite parenthèse, mais c'était important pour moi de contextualiser un peu tout ça (et de te montrer que les RA ne sont pas faites pour te punir d'avoir dérapé mais pour te mettre des bâtons dans les roues).
Pour en revenir aux classes, tu mettrais quoi comme instance of (P31) ou subclass of (P279) aux éléments que je viens de créer sur les différentes classes de courses ? J'ai pas d'avis sur cette question. Quant à l'infobox, je suis intéressé si tu peux me marquer les lignes ici, pour le moment elle n'existe que sur FR Wiki, mais le programme élaboré avec Molarus pour générer des tableaux dans le corps des articles (Cycling race) fonctionne si bien sur quelques versions linguistiques que partager l'infobox sur plusieurs versions ne paraît plus irréaliste (et ça répond à un besoin dans plusieurs versions linguistiques). Jérémy-Günther-Heinz Jähnick (talk) 13:25, 23 January 2016 (UTC)Reply
@Jérémy-Günther-Heinz Jähnick: Si ce sont des courses cyclistes je mettrai tout simplement sous-classe de course cycliste. Comme instance of (P31) je mettrai "classe de course cycliste définie par l'UICN" (si c'est l'UICN qui définit les types, par exemple".
Pour le code, j'ai créé Module:Filters
qui s'utilise comme ça (au débuggage prêt), et en supposant que le code "claim.value" donne les identifiants numédiques des éléments valeur des déclaration et que "claim_list" est une liste ou un tableau de déclaration P31, par exemple
local filters = import('Module:Filters')

function filter_cycling_types(claim_list)
    local qset = filters.Set:new({"Qxxxxx", "Qyyyyy", "Qzzzzz"})
    return filters.filter_in(qset, claim_list, function (claim) return "Q" .. claim.value end)
end
Ce code filtrera les déclarations qui correspondent à la liste d'élément passé en paramètres - il doit être adapté, j'ai pas le code qui récupère l'id de l'élément à partir d'une déclaration complète en tête.
Une autre possibilité serait
local filters = import('Module:Filters')

local claim_set=filters.Set:new(claim_list)
local function get_id(claim) return "Q" .. claim.value end

if claim_set:value_has_match_in("Qdutypedecourse",get_id) then
    -- code pour ce type de courses
end
N'hésite pas à me repinger. author  TomT0m / talk page 21:03, 31 January 2016 (UTC)Reply
Merci TomT0m. Finalement quand j'avais posé la question c'était en vue d'adapter l'infobox que nous avons sur FR Wiki. Les choses ont bien évolué depuis, et @Molarus: est en train de concevoir une infobox commune aux versions linguistiques de Wikipédia (voir Module talk:Cycling race). Le procédé est déjà bien rodé parce que nous avons déjà dans plusieurs versions linguistiques des tableaux qui servent à lister les étapes d'une course cycliste ou encore le palmarès d'une course depuis sa création. Je lui ai donc indiqué cette page à l'instant, il est beaucoup plus compétant que moi sur tout ce qui tourne autour du code. Jérémy-Günther-Heinz Jähnick (talk) 14:42, 1 February 2016 (UTC)Reply