Hello, I don't understand your additions like this. Is it really semiaxis of a body? And what's the unit?
User talk:VIGNERON
Yes, it's the semi-major axis of the orbit of the body, I imported it from Wikipedia (as indicated in the reference). But yes, apparently the unit (km) was not imported with the quantity. I'll look to fix that.
Unit added.
what about meaning? you instsist that this property is for orbit and not for body itself?
I'm not sure to understand. A body itself has no semiaxis, or rather when we say "the semiaxis of a body" it's a short formulation for saying "the semiaxis of the orbit of the body".
Look at this definition for instance: https://ssd.jpl.nasa.gov/?glossary&term=sma you can also look at the 40 396 uses of this property, it's always for the orbit of the body.
Hm, yes, there is some misunderstanding. Look at en:Semi-major and semi-minor axes - any conic section (and any ellypsoidal body) has semimajor axes, not only orbit.
Yes, there is misunderstanding, the semi axis can indeed be about any trajectory obviously, orbit is just the most common recorded one. And anyway, it's *never* for the body itself.
Salut,
J'aimerais faire des requêtes concernant les articles scientifiques, mais leur quantité fait en sorte que je timeout systématiquement, même avec COUNT. Par exemple, cette requête, en tout ou en partie, ne fonctionne pas :
select distinct (COUNT(?item) AS ?count) where {?item wdt:P31 wd:Q13442814 ; wdt:P1433 ?pub ; wdt:P407 ?lang .}
Try it!
J'ai aussi essayé avec https://ldfclient.wmflabs.org/, mais ça ne marche pas (d'ailleurs, ça ne marche jamais sur ce site).
As-tu une idée de ce que je peux faire ? S'il n'y a rien à faire, serons-nous toujours condamnés à ne pouvoir aborder qu'une fraction des articles scientifiques ?
Salut,
Oui, malheureusement on ne peux pas utiliser Query pour cela (le problème est réel, connu et ne concerne pas que les publications scientifiques d'ailleurs).
Pour LDF, c'est logique que ça ne marche pas non plus mais par contre, je suis surpris par ton « ça ne marche jamais sur ce site », sur une requête simple LDF fonctionne bien (je viens de tester).
La seule solution que je vois est de télécharger le dump et de travailler directement dessus (mais là je ne pourrais pas te guider, désolé).
PS: Ooups, je n'ai rien dit, il y a aussi cet endpoint SPARQL qui semble fonctionner : https://wikidata.demo.openlinksw.com/sparql (je pensais que c'était SPARQL lui-même le problème mais visiblement c'est plutôt du côté de Blazegraph puisque Virtuoso réussit à renvoyer des résultats).
Yahoo ! Merci pour le lien. C'est surprenant car mes requêtes donnent une réponse quasi-instantanée ! Pour LDF, à chaque fois que j'y ai tenté une requête, j'ai jamais obtenu de résultat. Il faut dire que je ne l'essaie que lorsque Query timeout.
Pour Virtuoso, se peut-il qu'il fonctionne avec un dump ? Sinon, sais-tu son taux de "rafraîchissement" ? Par exemple, ce chiffre n'a pas changé en plusieurs heures, alors que plusieurs Q5 ont été créés depuis.
Je n'ai pas les détails de fonctionnement (la doc est très générale et généraliste) mais comme le dit l'URL c'est une démo donc il est probable que ce soit moins souvent mis à jour.
Je me joins à la conversation puisqu’on en a parlé avec VIGNERON hier.
J’ai fait quelques tests pour savoir ce qu’était ce endpoint et notamment la date de la mise à jour du jeu de données. Ils ont retiré les propriétés schema:dateModified et il ne semble pas y avoir toutes les wikibase:timestamp (indiquant la date de dernière modif d’un item). Du coup j’ai procédé par dichotomie du plus grand item créé et je suis arrivé aux alentours de Q64749123 (existant dans le dataset, item créé le 21 juin 2019) et Q64849123 (inexistant dans le dataset, item créé le 27 juin 2019), la date de ce dump est donc vers fin juin 2019 et on voit donc que ce n’est pas du temps réel mais plus probablement des imports de dumps tous les quelques mois.
Ok. Merci !
Je ne sais pas à quel point cela s'est discuté, mais à défaut, pour le moment, d'être capable de faire des requêtes "en temps réel" sur les corpus dépassant (environ) 100 000 éléments, ou dépassant 3 millions avec COUNT, ne pourrait-on pas avoir un outil de requête semblable à celui de Virtuoso, mais qui utiliserait le dernier dump disponible ?
Sinon, on a un début d'idée de solution pour le problème des requêtes en temps réel sur les gros échantillons ?
Bonjour Vigneron, j'ai un problème pour indiquer les références de l'ODNB sur WD, pour les pages récemment créées sur ce dictionnaire. Par exemple pour Joyce M. Bennett https://www.oxforddnb.com/view/10.1093/odnb/9780198614128.001.0001/odnb-9780198614128-e-110576?rskey=KlqGXR&result=1 ou Sheila Jeanne Browne [https://www.oxforddnb.com/view/10.1093/odnb/9780198614128.001.0001/odnb-9780198614128-e-110806?rskey=QGQ6SS&result=1... Si tu peux faire quelque chose pour moi, parce que le lien que j'insère sur WP n'aboutit nulle part non plus... Rien d'urgent, bonne journée à toi et merci,
Oui, visiblement il y a un problème qui vient de changement du côté du site d'Oxford. Voir ces discussions : https://www.wikidata.org/wiki/Property_talk:P1415 (notamment la toute dernière).
Merci de ta réponse. Du coup, je ne peux plus me servir du code {{ODNB}} mais cela concerne alors Wikipédia. Bonne journée et merci,
C'est dommage, la propriété Oxford Dictionary of National Biography ID (P1415) marche encore pour la plupart des identifiants : tout ceux sous la forme https://doi.org/10.1093/ref:odnb/XXXXX , seul ceux sous la forme https://doi.org/10.1093/odnb/9780198614128.013.YYYYY ne fonctionne plus. De plus, j'imagine que le problème est temporaire et devrait être rapidement réglé (soit de notre côté, soit plus probablement du côté de l'ODNB).
D'ailleurs, tu va sans doute pouvoir éclairer ma lanterne, quelle est la distinction entre les personnes des deux URLs ? sachant que la deuxième URLs contient l'e-ISBN de l'ODNB, serait-ce les personnes uniquement dans la version électronique ? et dans ce cas, peut-on vraiment dire qu'il s'agit du même dictionnaire ? (si OBNB ne règle pas le problème d'URL de leur côté, une solution serait d'avoir deux propriétés distinctes de notre côté mais cela ne se justifie que si il s'agit vraiment d'édition distincte).
https://www.oxforddnb.com/view/10.1093/odnb/9780198614128.001.0001/odnb-9780198614128-e-110576
https://www.oxforddnb.com/view/10.1093/odnb/9780198614128.001.0001/odnb-9780198614128-e-110806
En fait j'ai copié la ligne mais les liens sont de même forme. Par contre ce sont les versions récentes qui sont bizarres, les anciens liens fonctionnent en indiquant comme propriété les derniers chiffres
https://www.oxforddnb.com/view/10.1093/ref:odnb/9780198614128.001.0001/odnb-9780198614128-e-38017 on peut écrire 38017 pour renseigner le champ ODNB.
Bon je renonce... en attendant que quelqu'un trouve la solution, merci à toi et bonne fin de journée,
Oui, le site fait une redirection. https://doi.org/10.1093/ref:odnb/95491 redirige vers https://www.oxforddnb.com/view/10.1093/ref:odnb/9780198614128.001.0001/odnb-9780198614128-e-95491
Mais la redirection ne marche pas pour tout les identifiants : cela ne fonctionne que pour les liens commençant par https://doi.org/10.1093/ref:odnb et pas ceux en https://doi.org/10.1093/odnb D'où ma question de savoir quelle est la différence entre ces deux URLs... Tant que cette différence ne sera pas comprise, le problème est difficile voire impossible à résoudre.
Cela dépasse de loin mes compétences...
Dommage. Malgré son apparence, la question n'est pas du tout technique. Je suppose que cela correspond à quelque chose comme des personnes de différentes éditions de l'ODNB mais je ne connais que vaguement le fonctionnement de ce dictionnaire, en sais-tu plus sur ce point ?
Je ne suis pas sûre de comprendre ta question. Si on prend l'exemple de Tory Dutt, sur la page d'accueil du dictionnaire, le lien fonctionne https://www.oxforddnb.com/view/10.1093/ref:odnb/9780198614128.001.0001/odnb-9780198614128-e-369160, permet d'accéder à la page requise, mais le lien qu'ils donnent sur la page même ne fonctionne pas https://doi.org/10.1093/odnb/9780198614128.013.369160
J'ai l'impression que ce sont les pages récentes qui ont ce problème... 2018, 2019. Ils ont changé leur présentation.
Ah, je n'avais pas vu que même leur propre lien en fonctionne pas, du coup le problème est définitivement de leur côté. Je crains que la seule chose à faire côté Wikimédia est de prendre son mal en patience. Désolé pour cette non-réponse...
ça fait rien, tu as été très sympa d'essayer de résoudre le problème, bonne soirée à toi et merci,
Hello VIGNERON,
where can I find the list with the mayors of Colombia. I have seen that you asked if they should be imported to Wikidata and I am interested in this topic and would help you if you want. Can you please give me a link to the page where I can find the data.
Hi,
On the PC I gave the link to https://www.datos.gov.co/browse?q=alcalde&sortBy=relevance is the results of all the files concerning "alcalde" (Spanish "for mayor").
I didn't look at all of them in detail but there is a bit of everything in there :
- files like https://www.datos.gov.co/Funci-n-p-blica/Alcaldes-2016-2019/fmw5-2cbs is all the mayors for 2016-2019 for the department of Colombia (Q215655) of Cauca Department (Q230602) (it seems we have all the 32 department of Colombia (Q215655))
- files like https://www.datos.gov.co/Funci-n-p-blica/Alcaldes-Municipales-1950-a-2017/fqga-fyhj is all mayors for 1950-2017 but only for the municipality of Colombia (Q2555896) of San Vicente de Chucurí (Q1256417)
- and there is probably some others type of files
Apparently there is no standard (some have multiple column with lot of information but most of them only have very basic information, only the name of the mayor and the city - and the date and function being implicite in the file title).
So I guess, the first step would be to merge and unify these files to have a coherent dataset for all Colombia (maybe we can do that in a Google spreadsheets together?). Then, I thought about using OpenRefine to do the import.
What do you think?
I think it is a good idea. I usually use QuickStatements directly to add items or other things and making the steps before in Calc. Both is possible and so if you upload them you can choose the way you want to do it. I can show you if you want how I do it with Calc in the Googlespreadsheet. What has all the functions I need. Do you prefer adding items for the mayor positions or not. With that I mean for example a item with the Label Mayor of Sucre. I think this is easier for querying if you dont know much about using Qualifiers in Querys in Wikidata with the Query Service.
Yes, specific item may be a good idea (I was not entirely convinced, but indeed I can see the advantages you point).
I'm not available this week-end but I'll look into it next week.
Moving discussion from the deleted lexeme here:
- You are correct, that word might be valid, and might get re-created soon. The issue was that the word was first added to Wiktionary, but later was moved to the incubator namespace without redirect. At this point I don't want the bot to create anything that's not in the main NS, thus delete request. Thanks for noticing!!
Hi,
Thanks for the explanation. It's very strange but ok.
In Google books usages don't seem to be Russian...
Thanks a lot @Infovarius:, that a very good argument. I didn't pay much attention to it but indeed it seems you're right.
Bonsoir VIGNERON,
il y a de longs mois il me semble que j'avais lu sous ta plume que tous types de publications (y compris des articles de magazines) pouvaient être considérés comme admissibles sur Wikidata, et y étaient bienvenus. Pourtant, à la lecture de Wikidata talk:Notability#Magazine articles and volumes, ça ne semble pas être une position universellement admise. Y a-t-il eu des débats, voire des décisions à ce sujet ? Et si oui, où peut-on les retrouver ?
Cela me semble un peu excessif (l'exagération était peut-être de moi) et les magazines sont clairement dans la zone grise mais si on se réfère aux principes généraux WD:N, en théorie selon le point 2, il suffit de sources pour qu'un sujet soit admissible. Et le mieux est encore de remplir les point 2 et 3, la publication possède des sources et remplie effectivement un besoin.
Je ne me souviens pas vraiment de débats (j'imagine qu'il y en a eu mais il faudrait les retrouver). Le plus proche dont je me souviens est Wikidata_talk:WikiProject_Periodicals/Archive_1#Daily_journal (mais cela ne concerne pas directement l'admissibilité vu que cela satisfait le point 1 de WD:N, ceci dit je le mentionne aussi car ce projet est un bon endroit où poser la question).
Bonjour @VIGNERON:c'est difficile de reprendre SPARQL toute seule!!! hahaha. Cela dit, j'aimerai te demander 2 exemples de recherche qui me seront très utiles pour le projet: 1. être humain / femme / auteur / d'un pays / ce pays est dans les caraïbes ou bien, ce pays est en afrique. 2. être humain / auteur / d'un pays / pays est dans les caraïbes ou bien, ce pays est en afrique ET n'a pas d'article wikipédia en EN, FR. Tout ceci est possible? je te remercie beaucoup d'avance et merci encore pour votre présentation à la Wikiconférence francophone à Bruxelles! ~~~~
Excuses-moi Vigneron je voulais aussi savoir comment extraire le résultat de la recherche en format tableau pour notre liste de travail. ^. ^
j'ai constitué par exemple cette recherche: https://w.wiki/8K3 Mais je n'ai pas le temps de chercher une par une si elles ont une page wikipédia. Si elle n'en a pas, il faudra encore chercher si elle est notoire pour la wikipédia. Bref... Enfin, pour extraire les donnée j'essaye en cliquant sur "tableau", puis sur "tableau HTML" mais ça je ne peux pas copier cela sur la liste de travail du projet. :-(
Pour cela il y a plusieurs solutions mais selon moi la plus simple est d'utiliser Listeria. Pour cela, il suffit de placer le modèle fr:Modèle:Wikidata list sur une page (je me suis permis de tester sur fr:Utilisatrice:Galahmm/Liste) d'y ajouter la requête SPARQL qui t'intéresse et d'attendre que le robot passe pour mettre les données (ou de cliquer sur Forcer la mise à jour). En bonus, cela permet de placer la page en liste de suivi et de suivre/vérifier les modifications sur Wikidata ;)
Bonjour,
Pour les Caraïbes, c'est un peu particulier, j'ai l'impression que la plupart des pays des Caraïbes ne sont pas correctement renseignés dans Wikidata :(
Pour les auteures d'Afrique par contre c'est assez simple : https://w.wiki/8K5 (je suis parti du lieu de naissance, on aurait aussi pu prendre le pays de nationalité).
Et la même requête pour filtrer ceux qui ont un article sur les Wikipédia fr et en : https://w.wiki/8K6
j'ai créé (en lien avec la présentation : https://programme.wikiconvention.fr/#_session-patrimoines) Q67184225 qui pourrait être utilisé comme valeur de P1485 (P1485) et qui permettrait de lister les objets immatériels listés. Est-ce que c'est ok?
Merci d'avance
Baptiste
Il faudrait vérifier mais il doit y avoir plus correct, notamment je découvre intangible cultural heritage status (P3259) (plus appropriée que heritage designation (P1435) qui semble limité au matériel).
Bonjour,
J'ai commencé à contribuer sur les intercommunalités et je suis tombée sur un machin particulier : Q16305617 . Je n'ai pas la preuve définitive (maudites soient les préfs qui ne publient pas leur RAA), mais je suis convaincue que cette communauté de communes n'a jamais existé qu'à l'état de projet.
Je n'ai pas du tout envie de m'en charger, et la personne que j'avais contacté sur ton conseil n'a pas donné suite. Puis-je te demander de t'en occuper ? Je peux fournir des éléments à l'appui si besoin.
Merci !
Cordialement, ~~~~
Bonjour,
Je veux bien regarder mais je veux bien les éléments qui appuient ta conviction.
Si les Yvelines ne publient leur RAA que depuis avril 2015 (ce qui est déjà fort utile), elles publient aussi d'autres documents comme ces fiches dont la fiche 15 (page 6) concernent cette interco.
Bonjour,
Oui, les fiches sont les annexes au SDCI de décembre 2011 qui prévoyait la création de cette interco. Mais qu'il semble bien qu'elle ne l'ait jamais été, puisque je n'ai trouvé nulle part trace de son existence.
La preuve définitive et absente, c'est l'"arrêté préfectoral n°2013353-0007 du 19 décembre 2013 portant rattachement des communes de Coignières et Maurepas à la Communauté de Communes des Étangs" dont la lecture devrait confirmer qu'elles étaient isolées. Le titre le dit en fait implicitement : si elles étaient réunies en comm comm, l'arrêté aurait dû prononcer la fusion des deux EPCI en un seul (nouveau) et pas le rattachement.
Il y a quelques documents qui évoquent cette situation. Il y a notamment ce journal municipal http://www.coignieres.fr/ville_dynamique/iso_album/bm84.pdf (page 26) qui dit bien que les communes sont restées isolées jusqu'à ce rattachement, et avant lui cette délib http://autouillet.fr/2014/01/conseil-municipal-du-5-septembre-2013/ où l'on apprend que le préfet n'a trouvé une porte de sortie qu'à la fin 2013.
Cordialement, ~~~~
Mhhh, étrange. Je notifie @Pymouss: qui est plus expert dans ce domaine.
Hi! Excuse me for writing in English, but my (written) French has to be revised. It was a pleasure to meet you at Wikimania in Stockholm! Now I come for this reason: a user from Chechen Wikipedia (ce.wiki), Takhirgeran Umar, has just ask me how to display French departments in a newly created template, ce:Кеп:НБМ-Франци. I thought it was a simple task, then I had a look at some items (e.g. Abbaretz (Q1001990), Hazebrouck (Q11131)) and I realised there was a problem :) I also had a quick look at Wikidata talk:WikiProject France and I saw a huge amount of discussions citing located in the administrative territorial entity (P131), in particular the interesting "Surveillons les cyrillographes" about users from Belarus not understanding the modelling of located in the administrative territorial entity (P131) in French administrative unit. Given these premises, I have to ask you two questions:
- (problem of modelling) could you explain me briefly which is the reason because of which French communes have in located in the administrative territorial entity (P131) not only the just-above administrative layer, the canton, but also arrondissements and departments (and not regions)? In Italy communes have in located in the administrative territorial entity (P131) only the province (e.g. Pisa (Q13375) located in the administrative territorial entity (P131) Province of Pisa (Q16244)) and then the province has located in the administrative territorial entity (P131) for the region (e.g. Province of Pisa (Q16244) located in the administrative territorial entity (P131) Tuscany (Q1273)). Isn't that system redundant?
- (problem of the template) would you be able to find a user which can make the template read only the value of located in the administrative territorial entity (P131) which is instance of (P31) department of France (Q6465)? At the moment the template, as you can see e.g. in ce:Аббарес, reads all the three values of located in the administrative territorial entity (P131), how can we select the department only?
Thank you and excuse me for asking you to explain for the umpteenth time the same problem :( Bye!
Hi,
No problem, write in any language you want ;) It was also nice to meet and I'm sorry we didn't has time to talk more.
Now, for the nightmare of French Département... (no problem, I'm starting to getting good at explaining it and talking about it will maybe make me find the perfect solution).
Yes, there has been a lot of discussion and the perfect solution has not been found yet. There is many aspects in this problem, for instance, the administrative layers are not always transitive nor clusive (A is in B and B is in C but A is not in C !). Plus there is some popular and historic aspect, the Département are the most stable and the oldest still existing administrative unit in France. The most precise value of P131 if often the less known (even difficult to find references) and the newest one.
For the template, I'm not an expert in Lua but I think fr:Module:Adresse has the code you're looking for (it is made for adress of monument but it should work for commune of France too).
OK, I understand that there can be a problem of transitivity plus a historical problem; so probably this solution is the best at the moment.
In fr:Module:Adresse I can't see anywhere any mention of department of France (Q6465), so I'm not sure it can solve the problem of the template. I will have a look in the templates of fr.wiki in order to find the solution!
Not the best but probably the "less worst" solution ;)
Yes, the Adresse module works with a sub-module : fr:Module:Adresse/Formats which gives an explicit list of expected value (which is not the most elegant solution but at least it works and it won't break if the model change on Wikidata ;) ).
Since you know Italy, what do you think of that Special:Diff/1007870540?
OK, the explicit list of fr:Module:Adresse/Formats can work ;)
I think your edit on Rome (Q220) is surely correct. In Italy we have still a lot of work to do with adding information about previous administrative units (in particular all the administrative units pre-1946, of Kingdom of Italy (Q172579).