Thank you for your contribution, but you have added wrong images to some Chinese railway stations, like Q104834563, Q104834572, Q104834562, Q104834580, Q104834571, Q104834581, Q104834579, Q107974713, Q104835736.
User talk:Bouzinac
Jump to navigation
Jump to search
Hi Bouzinac, on Murgtalbahn (Q286817) you stated a wrong state, please check your algorithm. -- Gerd Fahrenhorst (Diskussion) 20:30, 7 October 2024 (UTC)
Hi https://www.wikidata.org/wiki/Q286817#P3999 is it wrong?
Yes indeed that's wrong, the line was only temporarily closed in 2000 due to construction works. I removed P3999 there. So the problem is solved now.
Yes, but instead of removing P3999, I would have added a "no value" + preferred rank inside P3999 which would have smothered the P3999=2000
Hello, could you unmerge Q130335420 and Q2356943. Items are not the same, "HVDC converter station" is subclass of "converter station". That term means not only HVDC converter station, but converter station at plants and some other types of power stations. This is ukrainian-specific term. ~~~~
Ok, i'm no specialist in this, so here you go : https://www.wikidata.org/wiki/Q130335420#P1889
Thank you!
Thank you for your contribition at Gyömöre station but unfortunately you're wrong.
The map linkes by you says ther is no passenger train that stops there. Unfortunately for you the station is very active. Although you can't get off or get on to the train at this station trains stops here for passing because the line has only one track. Furthermore I'd like to infrorm you that there are freight trains in railway services and Gyömöre station serve these kind of trains (remember: the map says '''passanger''' trains skip this station).
Maybe it would be easier if you don't mess up things that you know nothing about. And it seems obvious that your knowledge about the railway in Hungary is poor (it's not nescessary your fault since you are not Hungarian). So Gyömöre is a staffed station with very own railway dispatcher. If you won't revert your nonsense then I will with decisive evidence. Please check the other stations because if I will see sg like this again I would't be patient like now.
Thank you for your understanding.
It is my understanding this station does not propose any passenger service, so I'd put Q55570340. Also, the hungarian wikipedia page is a bit messy too. Sorry for the Hungarian wikipedia. If you wish to fill in the lacking état d'usage (P5817) in this list... https://w.wiki/BG89
Hort-Csány is similar. At least it's impossible to make an accident at a station which was shut-down: http://www.kbsz.hu/j25/dokumentumok/2019-0871-5.pdf
I don't understand your logic : this Hort-Csány station can no longer be called a running station since hungarian wikipedia had it into https://hu.wikipedia.org/wiki/Kateg%C3%B3ria:Heves_megye_megsz%C5%B1nt_vas%C3%BAt%C3%A1llom%C3%A1sai
Yeah, huwiki has many mistakes. However Wikipedia is not a proper source therefore my logic is based on basic railway knowledge and information.
And one more thing. Although I'm not German and my knowledge about the German railway network is limited but it's hard to belive that the famous Berlin Hauptbahnhof has been decommissioned.
Maybe it would be wise for you to stop messing around in the railway elements and start to restore what you did. Otherwise...
There is a saying in Hungary: If it doesn’t work, don’t force it. Maybe you shouldn't force this state of use property.
Mistakes can happen all the more as there is a https://www.wikidata.org/wiki/Q1097#P3999 . Thanks for being such a positive wikidatist.
Salut,
Je me permets de te répondre ici directement et en français. QLever est un endpoint SPARQL qui se base sur les dumps de Wikidata. Cela lui permet d'être plus rapide mais du coup, les données ne sont mises à jour que tout les quinze jours. Ce n'est donc pas un « problème de cache » mais une fonctionnalité attendue de l'outil.
Cdlt,
Salut, okay !
@VIGNERON j'en profite pour te demander qui (ou quoi) paramètre les langues par défaut quand tu commence à taper une requête dans https://query.wikidata.org/ (en partant d'une page blanche), tu as ça [AUTO_LANGUAGE],mul,en qui donne l'impression que mul est à privilégier (et que visiblement ne devrait pas être trop présente)?
Pas de problème, n'hésite pas à me poser des questions.
Sauf erreur, je dirais que c'est paramétrer directement le logiciel. Et c'est logique, on privilégie effectivement les langues les plus courantes et quoi de plus courant que la langue par défaut ? Par contre, c'est bien une préférence pour les requêtes en SPARQL, pas forcément pour entrer les libellés dans Wikidata.
De même tu as deux boutons qui proposent des requêtes toutes faites mais avec une modélisation un peu bancale qui rend difficile la remodification
D'où vient cette copie d'écran ? (cela ne ressemble pas à "Wikidata Query Service", on dirait plutôt l'interface de Wikidata mais cela ne me dit rien de précis)
Quand tu vas dans un item au hasard tu as à ta gauche un genre de menu. Tu regardes tout en bas et tu as des boutons "Custom tools"
Je n'ai pas ces boutons, ce doit être un gadget que tu as activé (sans doute User:Lagewi/navigation.js).
Ceci dit, quand tu es dans le WDQS, il suffit de cliquer sur le diamant dans le menu à droite pour rendre la requête plus lisible.
Ah bah super, je l'ai repris et adapté à mes besoins ici : https://www.wikidata.org/wiki/User:Bouzinac/navigation_tools_FR.js
Génial !
Petit clin d'oeil à ta bretonnitude avec cette gare allemande Porz-Wahn(Q12066259)
I noticed that you added a lot of MUL labels with QuickStatements. But some of these labels are not also used in any other language. This is not the use case with MUL label, and I'm afraid that this batch edit should be reverted. Also, since the MUL language code is still in limited testing, you should not be mass editing MUL labels with batch editing tools, until the limited testing ends.
Hello. Please have a suggestion of reverting on the mul project, not on a private talk . Personally I was thinking Chinese labels would be the perfect use case for mul since other languages cannot read Chinese and since you can still add correct words in the correct language . But I 'd prefer wait for others to have a say. Thanks
I don't think your use of object of action (P12912) here was appropriate. First, since the subject and successor state (Q127693126) are classes, the right property would be object class of action (P12913). But I also don't think successor state (Q127693126) is necessarily the unique undergoer class of succession of states (Q1054283). You could also say that the predecessor state "undergoes" the succession, and based on the item description, it seems like the "roles and responsibilities" are what undergoes the process of transition. I think we should reserve object of action (P12912)/object class of action (P12913) as main statement properties for cases where the undergoer is unambiguous. So in this case, I might use source of transfer (P12693) and destination of transfer (P12694) for predecessor and successor states respectively, and/or indicate both with participant (P710). And then it would be appropriate to use object class of action (P12913) = sovereignty (Q42008) to qualify succession of states (Q1054283)subclass of (P279)transfer (Q125506646). Make sense?
Hello. My understanding is that Q6276051 is a commuter rail service that runs on Q125845486, which is a commuter rail line. There is a slight difference between the two because the rail line goes from Perth Underground station to Yanchep station, but the rail service runs from Elizabeth Quay station to Yanchep station. The difference is greater for some other Transperth lines. For example, the Airport Line (Q109448267), which runs on the Eastern Railway (Q5330395) and the Airport railway line (Q19818701). The Eastern Railway has regional rail services in addition to suburban services. That's why all of Transperth's services should be separated from their rail lines. Cheers.
Hi, I agree on services versus physical lines but the point is that one should not confuse commuter rail line(Q124130104) with commuter rail service(Q1412403) . I think there is some misleading text in the English label of Q1412403 which speaks more about the locomotives, the materiel used for these kind of urban rail whilst Q124130104 speak much more specifically about urban services
Compare for instance
SELECT ?ligne ?ligneLabel ?réseau_de_transportLabel ?paysLabel WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
?ligne wdt:P31 wd:Q124130104 ;wdt:P5817 wd:Q55654238.
OPTIONAL { ?ligne wdt:P16 ?réseau_de_transport. }
OPTIONAL { ?ligne wdt:P17 ?pays. }
}
with
SELECT ?train ?ligneLabel ?réseau_de_transportLabel ?paysLabel WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
?train wdt:P31 wd:Q1412403 ;wdt:P5817 wd:Q55654238.
OPTIONAL { ?ligne wdt:P16 ?réseau_de_transport. }
OPTIONAL { ?ligne wdt:P17 ?pays. }
}
It appears that many of the pre-AD solar eclipses you are importing already exist, albeit with their names (when they were initially added to the Persian Wikipedia) off by a year: -1970 Nov 16 (Q126501209) already exists as নভেম্বর ১৬, খ্রিষ্টপূর্ব ১৯৭১ এর সূর্যগ্রহণ (Q5692752), for example. Would you mind merging these and other such items like it?
Hi, yes, I'm working on it, it's a bit cautious since pre-AD dates are confusing
NASA numbers years pre-AD with them stating there is a year 0, which is false... so I have to curate date after import
I wouldn't call that false exactly, they're using Julian day (Q14267)s.
And Julian calendar does not have year O either https://cirrus.ucsd.edu/~pierce/calcalcs/calendars.html#:~:text=The%20Julian%20calendar%20implemented%20here,CalCalcs%20routines%20follow%20this%20practice. NASA just computed years with the need of a year 0, thus the confusions in years pre christus .
Perhaps but WDQS is using a rendering gregorian only so I'd prefer store dates as gregorian as a principe de moindre surprise (Q22668)
Hope it's now okay with https://w.wiki/AQcy + a visualisation of their numbers per decades https://w.wiki/AQdC (with the difficulties of decade 0 and decade "-0")
Salut,
Pour info, suite à ton message sur Wikidata:Bistro/Archive/2024/05#Sautend_na_moru(e), je suis tombé sur phab:T195318 qui semble lié (au minimum qui montre que la récupération de la carte OSM a quelques problèmes de compréhension des langues...).
Cdlt,
Salut!
ça a l'air de ressembler à l'histoire de sautend na moru;, comme c'est tjs visible avec la langue fr (et autres langues non-"en") https://maps.wikimedia.org/?lang=fr#10/51.4159/0.6963
et ça gêne aussi visiblement côté enwiki https://en.wikipedia.org/wiki/Wikipedia:Help_desk#What's_up_with_the_maps_in_New_York?