Hi, why are you giving Swedish airports the name of the city they are in or close to? Not good and confusing. Please revert.
User talk:Bouzinac
About this board
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.
Hi, I aliased them because it's easier to "OpenRefine" statistics among them (for example, file with only city name + IATA code more easy to update). Please note it's only in alias and not true name.
Thanks for the response. You got a point there ("... it's only in alias"), but I still think it is a poor alias. I understand "Barcelona" being an alias for "FC Barcelona", people say that. But I don't think one would say "JÖNKÖPING" when meaning the airport of that city.
Well… it's not me calling them "JONKOPING" but the swedish agency of statistics : see this : https://www.transportstyrelsen.se/sv/luftfart/Statistik/Flygplatsstatistik-/ Having them in alias helps Wikidata to find them when uploading data for these statistics.
Hello Bouzinac,
I do not understand why you declare the Bulgarian Empire a "subclass of" empire. This is a clear instance of "empire" as you correctly define. Thanks for the clarification. - FabC
Not a single Bulgarian empires. There has been several Bulgarian empires, see this :
SELECT ?empires_bulgares ?empires_bulgaresLabel WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
?empires_bulgares wdt:P31 wd:Q2067184.}
hence the need to keep this as a subclass of empires.
If this is a class then many properties should be removed from the item: P571, P36, probably P140 (not single religion to many of empires), P576, P242, P41, P94 and they should go to specific instances of such empire. Are you sure in these changes?
Sounds good and well presented in https://tools.wmflabs.org/wikidata-todo/tree.html?lang=en&q=Q6256&rp=279. May I suggest to remove "instance of" from Bulgarian Empire (Q2067184) ? That would keep separate and clean the class from the instances. Thanks and success!
ok
What do you think of Mediterranean countries (Q51576574), a bit bizarro, isn't it ?
It is. Please, see my note in the talk page "Talk:Q51576574".
And Western world (Q160381) ?
At least this one seems to be created by a bot. It is a concept, we can hardly identifies countries that belong to this class. And this is justified by the pages thank link to it https://www.wikidata.org/wiki/Special:WhatLinksHere/Q160381: no country names. I would remove the "subclass of" statement.
The statement instance of Q3622002 is even more strange...
Je ne comprends pas la démarche. Tu mets « sous-classe » parce que tu considères qu’il y a eu plusieurs Empire perses ? L’utilisation de « valeur inconnue » me semble aussi un peu étrange, surtout que le qualificateur reste.
oui, il y a eu les sassanides, les afcharides, etc. il n'y a pas d'empire perse au sens "unique, continu";
j'ai mis valeur inconnue car je ne sais pas trop à quoi rattacher ce genre de page qui en fait recense les différents empires perse qui se sont succédés.
Bonjour Bouzinac,
Bravo pour tes imports de nombres de passagers ! Pour https://en.wikipedia.org/wiki/Queen_Alia_International_Airport#Statistics, as-tu envisagé d'importer les références qui sont dans le tableau? OpenRefine a un importeur de wikitexte qui permet normalement de faire ça assez facilement. Il y a un tutoriel ici: Wikidata:Tools/OpenRefine/Editing/Tutorials/Inverse_Listeria
Bonne continuation !
Bjr, je vais essayer :)
Ce qui m'ennuie toujours, c'est que je n'ai pas de propriété clairement définie pour clientèle internationale/domestique… cf Wikidata:Property proposal/Transportation#Général
Et ce qui est ennuyeux aussi c'est qu'une heure après l'import, la statistique semble vide en requête SPARQL… cf https://fr.wikipedia.org/wiki/Aéroport_international_Reine-Alia#Statistiques
C'est curieux en effet. Peut-être un lag du Query Service?
Très bizarre car j'ai fait qq autres modifs et c'est visible une minute ou deux après. Mais Amman, impossible de voir le résultat à jour….
Bonjour,
Dans ce diff Special:Diff/860390759, tu indiques qu'il ne faut pas confondre Lund Airport (Q35276478) avec lui-même. Cela me semble clairement une erreur. Je te laisse regarder et corriger.
Bonjour, je n'ai pas compris ce qui s'est passé car il y a deux Lund airport (Suède+Iowa) et d'après l'historique j'ai mis ne pas confondre Lund Airport (Q2022991) avec Lund Airport (Q35276478)
J'ai rajouté du label pour éviter les confusions.
D'après l'historique, tu as mis les deux : l'aérodrome homonyme et l'aérodrome lui-même.
Pas de souci, cela arrive et il y a toujours quelqu'un pour vérifier 
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:
de redirects:
fr redirects
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
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.
Q7443580 (just a proposal right now)
Q55638100 - I've added 3 statements - extant Chinese military airbase
Q24901414 - ditto - WW2 seaplane base
Q24901443 - ditto - WW2 seaplane base
mostly done