User talk:Bouzinac

Welcome to Wikidata, Bouzinac!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

• Introduction – An introduction to the project.
• Wikidata tours – Interactive tutorials to show you how Wikidata works.
• Community portal – The portal for community members.
• User options – including the 'Babel' extension, to set your language preferences.
• Contents – The main help page for editing and using the site.
• Project chat – Discussions about the project.
• Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, please ask me on my talk page. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards! Liuxinyu970226 (talk) 09:26, 28 March 2016 (UTC)

Previous discussion was archived at User talk:Bouzinac/Archive 1 on 2018-08-08.

Bonjour Bouzinac,

Je ne suis pas sûr que tu aies vu mon message sur le bistro - je serais intéressé d'avoir tes retours sur la page Wikidata:Tools/OpenRefine/Editing/New_items/fr qui explique comment créer des nouveaux éléments avec OpenRefine. Si les instructions ne sont pas claires c'est important qu'on les améliore !

Bonne continuation !

Bonjour, je pense que la doc est bien. C'est juste que le terme de "réconciliation" est un peu confusant, surtout si on cherche à réconcilier des éléments qui n'existent pas ... Il manque peut être un bouton direct du genre "créer de nouveau éléments" plutôt qu'une étape (réconcilier/nouveaux éléments)

Ok merci ! L'idée est que généralement on vérifie que les nouveaux éléments qu'on veut créer n'existent pas encore (s'ils sont admissibles, alors il y a toujours une chance que quelqu'un d'autre les a créés avant nous). Dans la version 3.1 il y a une nouvelle opération qui permet de réconcilier de manière aveugle et qui peut a priori être utilisée pour accélérer cette réconciliation (si on est 100% sûr que les éléments n'existent pas encore).

Je ne sais pas si c'est normal mais c'est un peu galère de "charger" environ 500 nouveaux éléments...

Ah mais il faut surtout pas les marquer comme "nouveau" un par un ! Il y a une opération qui fait ça, dans le menu "Reconcile" -> "Actions".

J'ai ajouté une mention plus explicite de cette opération dans la doc.

salut @Pintoch: oup's, j'ai fait une bêtise avec une import openrefine, comment l'annuler ?

Salut! Au passage n'oublie pas d'utiliser reference URL (P854) et non pas Wikimedia import URL (P4656) :)

Pour annuler tes modifications, va sur: https://tools.wmflabs.org/editgroups/?tool=OR&user=Bouzinac clique sur le groupe d'edits qui ne te plaît pas, et annule-le.

Bonjour @Pintoch:

j'ai de nouvelles difficultés : j'ai une colonne date nativement dd/mm/aaaa, convertie en "date" avec le 'Transformer en'. ça donne des dates du style +1963-03-01T00:00:00Z. Sauf que une fois envoyé à Wikidata, je ne vois pas le résultat... ?

Autrement, aurais tu un guide/un step-by-step pour importer des coordonnées (notamment à partir de ce fichier https://www.faa.gov/airports/airport_safety/airportdata_5010/, colonnes contenant par ex :

ARPLatitude	ARPLatitudeS	ARPLongitude	ARPLongitudeS
63-23-28.3370N	228208.3370N	148-57-20.2190W	536240.2190W

(j'ai l'impression qu'on ne peut pas concaténer deux colonnes)

Enfin, le réconcilier n'est pas super rapide, c'est normal ou c'est moi? Par ex, dans le même fichier, j'ai des comtés américains. J'ai filtré les lignes sur un État, fait 'réconcilier avec le type county of the United States" + à l'aide de la localisation administrative=l'État en question. Bon, y a beaucoup de doublons, par exemple Lee County. Mais comme j'ai filtré un état, je m'attendais à ce qu'il reconnaisse le Lee county de l'État X, et pas le Lee county des autres États. Ce qui donne encore un gros travail de réconciliation...

Merci pour tes conseils

Bonjour Bouzinac,

Il y a actuellement un bug qui empêche l'envoi de dates quand elles ont été d'abord transformées en dates dans OpenRefine (ça devrait être résolu dans la prochaine version). Le plus simple est de les garder comme chaines de caractères ("1963-03-01" au lieu de "+1963-03-01T00:00:00Z").

Pour tes coordonnées géographiques, c'est un problème intéressant ! Il faudrait essayer de comprendre le format de ces coordonnées géographiques et les convertir en degrés d'angle (https://www.wikidata.org/wiki/Wikidata:Tools/OpenRefine/Editing/Schema_alignment#Globe_coordinates).

Pour la réconciliation, il n'y a pour l'instant pas de solution simple pour filtrer par état vu la modélisation actuelle des États-Unis. Faire localisation administrative -> l'État en question ne va pas aider puisque les villes ne sont pas reliées à leurs états via located in the administrative territorial entity (P131). Par exemple, rien n'indique directement sur Dillingham (Q79383) qu'il s'agit d'une ville de l'Alaska. La ville est liée via located in the administrative territorial entity (P131) à Dillingham Census Area (Q277728), qui a ensuite instance of (P31)  census area of Alaska (Q56064719), mais curieusement census area of Alaska (Q56064719) n'est pas lié du tout à Alaska (Q797)! Sauf erreur de ma part, c'est un problème de modélisation, qui devrait être corrigé directement dans Wikidata: aller d'une ville à son état devrait être beaucoup plus simple (je m'attendrais à ce qu'il suffise de suivre located in the administrative territorial entity (P131) un certain nombre de fois, ou utiliser une propriété analogue à country (P17) qui est ajoutée directement sur les items). Tu peux contourner le problème dans OpenRefine mais ça va être effectivement assez lent:

• Prends ta colonne avec les états, et ajoutes-en une autre à partir de cette colonne, qui contient "census area of "+état (donnant par exemple "census area of Alaska").
• Réconcilie cette colonne avec le type type of administrative division of one state of the USA (Q20687176)
• Utilise cette nouvelle colonne pour ta réconciliation des villes, en la configurant avec la propriété "P131/P31" dans le dialogue de réconciliation.

J'ai pas testé si ça marche mais en théorie ça devrait.

Salut

Et bien c'est un demi échec: je n'ai pu créer que 5000 items. Les 5000 suivants n'ont pas pu être importés : y a t il une limite de OpenRefine?

A priori non, il n'y a pas de limite particulière. Tu peux essayer d'augmenter la mémoire disponible pour OpenRefine: https://github.com/OpenRefine/OpenRefine/wiki/FAQ%3A-Allocate-More-Memory. Tu peux aussi regarder dans la console pour voir s'il y a une erreur particulière.

Have you thought about adding values for this (in my opinion) underused property to items for various airports?

Hi Mahir, yes, I wish too it was densely populated amongst airports wikielements. See for instance Q583453

However, I am facing two problems for this property :

- how do I have a reliable file containing links between airports (+ companies) ? I'd be happy pushing it into the wikidata

- how can one update wikidata as it is very "fragile" information (closure/opening of schedules, airline bankrupcy,etc)

- what's the use for it? Since wikidata is disliked by wikipedia users... and hard to find a correct table(or Lua) template that would present a readable table with the sparql result for P521...

That's a pretty thorough import for that airport (though I wonder if P931 and P518 are better left on the items for the airports rather than as qualifiers). As for your points...

• I am going to go through some schedules for Indian airlines soon, and the first thing I do once I find a stable link to a schedule is save it in the Wayback Machine. That way there is at least a constant record of a flight between two places at a point in time that can be used as a reference.
• This is certainly a valid point which applies to many concepts besides airline destinations in Wikidata. I don't think there's a good way to avoid the volatility inherent in flight schedules, which can be affected by any of flight accidents as well as domestic and international affairs. If the bloat on airport items becomes too great for a single item when representing flight destinations, then finding a way to represent these consistently in tabular form may be necessary.
• (I'm sure @Joshbaumgartner: has a better answer than I do regarding the use of this property and @GZWDer: has a better answer than I do regarding the lack of use.) As to the latter part of your question, you're working on something here because you find a purpose for it, no? :-)

BTW, I have a gut feeling that you're using everything (Q2165236) improperly when importing patronages. (Linking to the metaphysical concept seems a bit strange.) Although I admit I'm not sure what a good alternative to this would be (in the same way that for e.g. populations there are different properties for various sub-populations), I'd suggest not using Q2165236 further and if possible changing it to something else. Feel free to ask around about it.

Hi @Mahir256: it's interesting that you wish to populate scheduled service destination (P521) for Indian airports .

Will you input on this basis for one airport (for instance Mumbai/BOM) :

P521={Delhi airport/DEL} operator (P137) = {airlines X and Y} applies to part (P518)={yearly}

P521={some other airport} operator (P137) ={airlines Z} applies to part (P518)={only on summer/season}

For your between remark, yes... some other people have raised an eyebrow... (discussion in French there: Topic:Ut1bx85v7iopca3l) still not closed. The trouble is that I wanted to populate Q with data from airport patronages. They are very often furnished with (international passengers/domestic passengers/grand total passengers). I thought it was a good idea using P518 = (everything (Q2165236)/rest of the world (Q61029267)/(the name of the country as domestic).

And now, so as to keep Wikidata simple, I only populate with the grand total :) If you have references (statistical institute or whatever) with data for Indian airports, I'd be happy to populate them. Sincerely

Bonjour,

Je viens de remarquer que tu as ajouter Quebec (Q176) sur plusieurs aéroports qui avaient déjà une valeur plus précise en located in the administrative territorial entity (P131). Est-ce volontaire ?

J'ai annulé sur Lebel-sur-Quévillon Airport (Q3915618) pensant à une simple erreur - on ne met généralement que la valeur la plus précise - mais je me rends compte que c'est le cas pour une cinquantaine d'aéroports : requête. Du coup, je veux bien une confirmation avant d'annuler l'ajout sur ces éléments.

Hello

Tu me mets dans le doute, cf ce que j'avais remonté sur l'histoire du pays + état dans la fiche Canada.

Que faut il mettre dans la P131 : uniquement le plus petit niveau administratif ? Si oui, est ce que si je filtre les aéroports du Québec Q176, je vais aussi avoir les aéroports ayant une ville situé au Québec ?

Et cf la discussion avec Pierre Martins : Orly est techniquement située sur plusieurs communes de plusieurs départements différents...

Oui, l'usage est de ne pas que la (ou les) valeur(s) les plus précise(s) (toutes les valeurs supérieures peuvent - normalement - être récupérées par une requête et condition que la requête soit bien construite - avec P131* - et les données correctes, alors oui, on peut avoir tout ce qui est situé au Québec ou dans quelque chose lui-même situé directement ou indirectement au Québec).

Dans le cas comme Orly où il y a plusieurs valeurs de même niveau, alors oui on mets l'ensemble de ces valeurs.

airport items with links to en redirects ... you may have got these all by now, but anyway:

• Andreas Airfield (Q4755356)

• Bolling Field (Q12053257)

• Bordeaux-Mérignac Air Base (Q2886451)

• Castaway Cay Airport (Q12692147)

• Castel Benito (Q21974295)

• Chennault Air Force Base (Q5091503)

• City Airport & Heliport (Q1999184)

• Coolidge Air Force Base (Q15211590)

• Crows Landing Naval Auxiliary Air Station (Q1654943)

• Drammen Hospital (Q11966016)

• Fairfax Airport (Q5430146)

• First Royal Moroccan Air Force Base (Q5453767)

• Forbes Field Air National Guard Base (Q5467246)

• Gardez Air Base (Q5522506)

• Huslia Airport (Q3084957)

• Dhahran Airfield (Q1658103)

• Lake Hood Strip (Q4257448)

• Leavesden Aerodrome (Q24897603)

• Locarno Air Base (Q1433959)

• Lyda Ranch Airstrip (Q6707517)

• Mountain Shadow Air Force Station (Q24942054)

• NDA Gliderdrome (Q3015031)

• Perry County Airport (Q7169748)

• Pine Cay Airport (Q11824673)

• RAAF Woomera Airfield (Q7274994)

• RAF Al Udeid (Q7275130)

• Richards-Gebaur Air Force Base (Q7330272)

• Springfield Air National Guard Base (Q7580932)

• Tucson Air National Guard Base (Q7851143)

de redirects:

• Coolidge Air Force Base (Q15211590)

• Laucala Airport (Q11824529)

• Meiningen Airport (Q1432018)

fr redirects

• Phu Quoc International Airport (Q1423325)

thanks

have a look at Pine Cay Airport (Q11824673) ==> it is not a redirection but a shortcut to a part of article; what do you think?

I think you were correct to remove it.

sv redirects

• CFB Borden (Q1032107)

• 5th Canadian Division Support Base Gagetown (Q1023449)

• CFB Goose Bay (Q1032124)

• CFB Winnipeg (Q1836849)

• Naval Air Station Bermuda (Q3015996)

should be all ok

thanks!

btw, I've found with the MWAPI searches, it helps to have search terms like "helip*" ... compare, for the last of the five queries I posted, the returns from "helip" versus "helip*" ... equally, on the fourth query, this technique seems to lead to timeouts. Meanwhile here are some more candidates for you.

Q55639265

Q54933061

Q12691554

Q29841779

Q20471525

Q29015607

Q5454920

Q7443580 (just a proposal right now)

Q56377770

Q17448884

Q29000296

Q25471866

Q22951949

Q50198953

Q20982491

Q28465323

Q7534019

Q27963514

Q1593547

Q17519526

Q17514241

Q12693545

Q55638100 - I've added 3 statements - extant Chinese military airbase

Q24901414 - ditto - WW2 seaplane base

Q24901443 - ditto - WW2 seaplane base

mostly done

We should probably do a cross-check with http://weather.rap.ucar.edu/surface/stations.txt sometime - I understand it has some weather stations that are not airfields; but it might throw up some stuff. (I understand a list from ICAO costs £££) I'll do so, sometime, and come back to you.

Which I've now done ... drop me an email if you want to see the resulting spreadsheet ... not sure if it'll be of any use, having done it, but who knows. If so, let me know if you want an XLS, or an ODS (i.e. LibreOffice) - Special:EmailUser/Tagishsimon

Yes, please, might always help clean wikidata. abouzinac{arobase}bbox(dot)fr

Can you read ODS files - do you have OpenOffice or LibreOffice? Or do you need an Excel file?

never mind - I sent both. Let me know if problems