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.

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.

https://www.mavcsoport.hu/sites/default/files/upload/page/gyomore_0.pdf

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.

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

capture écran

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. }
}

Essayez !

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. }
}

Essayez !

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?

Hi! I have undone your changes to Rülzheim Bahnhof because you are mixing two different train stations here. The data object Q15792333 deals with the “Rülzheim Bahnhof” stop that is in use (see timetable here or here). If you want to savedata about the former train station and station building, please create a new data object.

I've created object Q126120664 now for the former train station.

You seem to be misusing deprecated rank on items such as Q800651 and Q801499, and presumably elsewhere. As far as I can see, you set statements to deprecated rank when they are no longer true (such as that Surrey Quays is no longer an underground station, or that Dalston Junction no longer has a connection to Canonbury railway station).

Deprecated rank is for statements THAT WERE NEVER TRUE. The correct course of actions for a statement which WAS ONCE TRUE BUT IS NO LONGER TRUE is to leave that statement as Normal Rank, and to set statements which are true in the present to Preferred Rank. That results in the desired outcome of statements which are currently true being given BestRank by virtue of them having Preferred Rank, and so being selected by wdt: predicates, whilst leaving statements which were true in the past at Normal Rank.

Please have a look at [[Help:Ranking]]. Note especially the sentence "The deprecated rank is used for statements that are known to include errors (i.e. data produced by flawed measurement processes, inaccurate statements) or that represent outdated knowledge (i.e. information that was never correct, but was at some point thought to be)." That sentence describes, in full, the scope of meaning of deprecated rank. Please notice that it does not say "or statements which were once true but are no longer true).

Right now, you are degrading wikidata by serially indicating that statements are not true, when the statements were once true but are not true in the present. There is no good reason for doing this except that you do not understand rank as well as you should, and do not appreciate the semantic effect of your actions.

I have amended the Surrey Quays / underground station statement, but not others. I hope you will correct your own mistakes.

I know the ranks. Thanks. By the way I've modestly corrected a typo there https://www.wikidata.org/w/index.php?title=Q29379049&oldid=2164722823 .

Bonjour Bouzinac, sur la ligne 1 (Q126093) du métro de New York le terminus sud n'est pas South Ferry (Q11704016) comme indiqué par Stations voisines sur les pages des stations mais South Ferry – Whitehall Street (Q2630288) . Bonne journée

Salut @Quoique, il n'y a pas d'erreur comme indiqué dans ce plan https://new.mta.info/map/5256 tout comme dans ce plan détaillé OSM https://www.openstreetmap.org/search?whereami=1&query=34.8253%2C113.7287#map=18/40.70243/-74.01233&layers=T

il y a bien deux stations distinctes.

Pour wiki en c'est un complexe avec deux sous-stations qu'ils dénomme : "The South Ferry/Whitehall Street station is a New York City Subway station complex in the Financial District neighborhood of Manhattan, under Battery Park. The complex is shared by the IRT Broadway–Seventh Avenue Line and the BMT Broadway Line. It is served by the 1 and R trains at all times, the W train only on weekdays during the day, and the N train at night."... ont peut ne pas faire comme eux et avoir deux articles autonomes même si l'une des bouches est communes aux deux. Qu'en penses-tu ?

Salut

enwiki a souvent pour habitude de "condenser" les multiples stations dans un seul article, avec des infobox internes à l'intérieur pour chaque sous-station ou pour la station de chaque réseau (mix gare+station de métro). Pourtant, c'est bien deux stations (proches) mais distinctes, comme le disent les sources cartes MTA + référentiel MTA https://data.ny.gov/Transportation/MTA-Subway-Stations/39hk-dx4f/data_preview (filtrer sur "south ferry").

J'ai l'impression que frwiki est au grain plus fin que enwiki sur ce genre de problématique.

À noter que ça s'appelle respectivement Whitehall St-South Ferry et South Ferry