Wikidata:Project chat

Wikidata project chat

A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

Start a new discussion

Edit

On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/09.

taxon common name (P1843)

taxon common name (P1843) is currently very vague and imprecise, just giving lists devoid of any contextual information other than a language and an optional source reference. Names for animals and plants are frequently highly emotive issues, and the system here needs refinement to accomodate this. Names also vary considerably in whether they are in extensive widespread use, or are only very rarely used; no distinction is currently possible. Some ideas for progress:

names derived from demonyms or ethnic slurs considered offensive to some or many people (e.g. n*gger, k*ffir, m*ngol, g*psy, sc*tch, squ*w, p*ki, etc.) need a statement to be used as a reason for deprecated rank (P2241).
names commemorating persons not, or no longer, considered worthy of commemoration (e.g. slave holders; see Thick-billed Longspur) also need a statement to be used as a reason for deprecated rank (P2241).
names with official status (particularly in the native region of a taxon) need an option for setting as a reason for preferred rank (P7452).
names in the USA frequently differ from those in the rest of the English-speaking world (not just '-colored' rather than '-coloured', but also numerous others). It would be helpful if these (notably names sourced from USDA PLANTS ID (P1772)) could be entered as language code en-us rather than en, to indicate they are American usage that may not be used elsewhere. This will need a bot task to convert entries already added.
rarely used names (particularly archaic names, e.g. sourced from copyright-expired texts) need some form of tagging to indicate they are no longer in widespread use; some sort of "semi-deprecation" (not necessarily pink background, but will not be picked up by e.g. the VN lists at Commons).
factually inaccurate or misleading names also need a similar option for tagging, so that those who wish to strive for accuracy can know those names are not accurate.

MPF (talk) 11:41, 7 April 2022 (UTC)[reply]

I think that there could be utility in defining some qualifiers that indicate if, in a given source, one common name is preferred over another. For example, the Database of Vascular Plants of Canada (Q19544711) lists accepted names in English and French along with other synonyms in English and French (for an example, see http://data.canadensys.net/vascan/taxon/7174).

I think using language codes for specific varieties of a language will be fraught with problems. Just because a name is found in an American reference source does not necessarily mean that the usage is restricted to the U.S. For English, there are only Wikimedia codes en-ca, en-gb, and en-us. What about Australian English, New Zealand English, South African English, Singaporean English, etc.? We would need codes for all countries where English is spoken. French only has a specific code for Canadian French and Louisiana French, but not Swiss French, Belgian French, Guinean French, Senegalese French, etc. I think labeling something with a code such as en-ca should only be acceptable if the source specifically states that it is providing a specific language variety of the information (for example, terms found in Dictionary of American Slang (Q48813215) can assuredly be labeled as American English). The U.S. is not the only place in the world that uses "color" vs. "colour." According to this article, "around the world, the American way of spelling is now far more popular."

I also disagree with some of MPF's assumptions about certain words being pejorative, particularly the word "Scotch." The Oxford Lexico website says about this word: "The use of Scotch to mean ‘of or relating to Scotland or its people’ is disliked by many Scottish people and is now uncommon in modern English. It survives in a number of fixed expressions, such as Scotch broth and Scotch whisky. For more details, see Scottish." Under "Scottish" it says "The word Scotch, meaning either ‘of or relating to Scotland’ or ‘a person/the people from Scotland,’ was widely used in the past by Scottish writers such as Robert Burns and Sir Walter Scott. In the 20th century, it became less common. It is disliked by many Scottish people (as being an ‘English’ invention) and is now regarded as old-fashioned in most contexts." There's nothing that says the word is pejorative, just disliked by many Scots. The Collins English Dictionary does indicate that "Scotch" is American English and that its use as an adjective is "sometimes offensive." But its use for a plant name just doesn't seem to me to possibly be offensive. It's not putting down Scottish people. Collins notes "The natives of Scotland refer to themselves as Scots or, in the singular, Scot, Scotsman, or Scotswoman. The related adjectives are Scottish or, less commonly, Scots. Scotch as a noun or adjective is objected to except when used of whisky and in established phrases like Scotch egg and Scotch pine. In the United States, Scotch is often used where the Scots themselves, or some Americans of Scottish descent, would prefer Scottish or Scots." I would suggest that "Scotch elm", like "Scotch egg" and "Scotch pine," falls under the category of established phrases that are not objectionable. UWashPrincipalCataloger (talk) 01:09, 11 April 2022 (UTC)[reply]

MPF's suggestion that name statements should be marked as deprecated because of actual/supposed/conceivable offence is to propose a misuse of deprecation. Deprecation is for statements that were never true. WD does not deprecate data based on "highly emotional" reactions. --Tagishsimon (talk) 01:44, 11 April 2022 (UTC)[reply]

@UWashPrincipalCataloger, Tagishsimon: thanks for your replies. I would certainly support creation of en-au, en-in, en-nz, en-sg, en-za, etc. language codes; I find it strange that they have not been long ago.

Of usage of 'Scot*h', I suggest you visit Scotland and ask people there, how they feel about Americans telling them they must accept American renaming of their native plants for them (and that goes for any other European species where the US naming authorities like USDA and ITIS have changed the native name to something different): it is regarded as [cultural] imperialism, and greatly detested as an insult to their intelligence, the treatment of native rights with contempt. The term may not be pejorative, but it most certainly causes offence when it is suggested (as wikidata sadly now does) to be correct usage. This is a fact, and needs to be recorded in wikidata, for the data to be accurate. If deprecation is not appropriate, then some other form of notation is needed, to indicate that what may be acceptable in some areas, is not in others. Consider for example a German author writing an article in English about Ulmus glabra for a scientific paper, and wanting to mention the English name: how will he know that Wych Elm is the correct name to use, and that 'Scot*h elm' is considered offensive by many, if wikidata provides no clues when he turns to it? This sort of information is very important, and needs to be recorded.

Of the Daily Mail article cited above, a reminder that en:wp banned use of the Daily Mail several years ago as being an unreliable source. This article fits exactly into the sort of "sensationalism and flat-out fabrication" that they were banned for. I certainly would not rate their claim above as trustworthy. - MPF (talk) 15:15, 11 April 2022 (UTC)[reply]

I think several of the reasons suggested for deprecation (or it's opposite) are a matter of opinion, not fact, and that can sometimes be inferred from the source itself.

Notes inserted below each point; @Plantdrew, UWashPrincipalCataloger: - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]

Whether a name is archaic is an opinion (when is the cutoff? an arbitrary date is an opinion), and archaicness can be inferred if the source for a common name was published long ago.

It may be visible on wikidata if the source is cited with a publication date long ago, but it is not visible (a) if the source is secondary, and more importantly, (b) in details exported from wikidata to other wiki projects - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]

That McCown's longspur is deprecated can be inferred from it only being sourced to older versions of IOC, not the most recent (and there is a movement to rename all birds with eponyms, regardless of whether the namesake is worth of commemoration; if that succeeds do we really need to flag some eponymous names as having an unworthy (opinion again) namesake?

From which, I conclude that it is reasonable to tag names generally as deprecated, if they are only used in an older version of a source? - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]

"Official" status? Who decides that? A government or language academy? A international learned society? A regional learned society? What if a government and international learned society disagree on an "official" common name; will multiple names be flagged as "official"? Picking just one is an opinion. If somebody knows that certain governments or learned societies are in the habit of designating "offical" common names, that can be inferred by having that entity as a source for the common name (admittedly, many people don't know which entities are in the habit of designating "official" common names)

It 'just is'; disagreement like you clearly want, just doesn't happen. You're quibbling to try to discredit the near-universal UK concept of one English name being correct, and others incorrect. It's how we do things here. Much the same as formal scientific names, one correct, others invalid synonyms. Many/most other countries in Europe are the same; see e.g. the French wiki page nom normalisé; read it, understand it, and stop trying to apply American concepts of naming ("every vernacular name is of equal status, regardless of its source") to everyone. Wikidata is international, and not the sole preserve of US ideas and concepts. To exclude UK concepts of naming, is contrary to the wiki community ideals of inclusiveness; I, like at least some other UK editors I know, have felt very unwelcome at times on wiki projects for not wishing to submit to US supremacy in ideas and concepts. That should not be happening. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
I will qualify the above, by adding that not everyone in UK holds with these ideas; some prefer the US styles. But equally, the converse is also true, many in US (e.g. American Ornithological Society (Q465985)) adhere to more European concepts of right and wrong in vernacular names. Ditto, CNN (Q48340), in their famous 'Facts First' tweet pointing out that correct naming matters. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
Even in America, you must surely accept that not all vernacular names are of equal validity or status; the policy at en:wp of treating them so is ludicrous. For one example, see white spruce, listing it as "a common name for several species of spruce" without any qualification at all, despite it being the de facto universal standard name for Picea glauca, and virtually never used for either of the other two (likely only as misidentifications). Wikidata should not follow this sort of nonsense; we very badly need some form of distinguishing between widespread, and very minor, uses of names. Without it, liks of names used become worthless, as they become without meaning if the same name is given to multiple taxa. It needs some way of tagging rarely-used names as 'low importance', so that while they can still be found by wikidata's search, they are not automatically exported to other wikimedia projects where they are likely to cause confusion. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]

Factually inaccurate? Again, a matter of opinion in deciding what a name accurately refers to in the first place. Is it inaccurate to use the name "lily" for plants formerly, but not currently classified in the family Liliaceae (or should "lily" be restricted only to members of the genus Lilium, let alone any other former/current members of the Liliaceae). The "official" name for plants in the genus Phormium, according to MPF's favorite source, the BSBI, is "New Zealand flax". Phormium isn't at all closely related to "true flax". MPF, get the BSBI to change that before you start complaining about: "Wollemi pine", "prairie dog", "jellyfish", or "water lily" (none of the people that common names are supposed to serve have any clue why the last is sometimes written as "water-lily"; pedants sticking hyphens into common names is not actually helpful). Plantdrew (talk) 05:07, 15 April 2022 (UTC)[reply]

Granted that BSBI are not perfect in all of their choices, but overall, their list is widely (close to universally) accepted in UK, and should be followed at least for English names of European native species. Since Phormium is not a European species anyway, BSBI's name is of low relevance; better to follow New Zealand usage, where (as with other NZ endemic plants), the strong trend is to adopt native Maori names into English (in the case of Phormium, 'Harakeke') to remove the misleading names imported by settlers. As for your remark "pedants sticking hyphens into common names is not actually helpful" - that is your opinion, which I find demeaning and offensive, and many (including leading US authorities like American Ornithological Society (Q465985), United States Forest Service (Q1891156), and others) would disagree very strongly with. Sorry, but your turn for not being helpful. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]

If we have a discussion about whether to record important information, we should look at the sources you could cite for that important information. Having discussions about who's worthy of commemoration within Wikidata should be avoided as much as possible.

To the extend that there is one English name that's better than others, "best rank" is the way we would label that name and not deprecation. ChristianKl

@ChristianKl: - that is certainly a good idea, but as mentioned above, we also need the means to 'half-hide' names that are worse than others. Otherwise, exports from wikidata to other wikimedia projects become excessively cumbersome and increasingly worthless with huge long lists of very rarely used vernacular names that only serve to confuse and mislead users. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]

I'm also doubtful about whether this is the best place for the discussion. Wikiproject Taxonomy would likely be better. ❪✉❫ 10:58, 15 April 2022 (UTC)[reply]

I've no objection to its being moved there, if that is generally felt to be the best place - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]

"has use" qualifier for P31 values

My colleagues and I are working on the upload of the Scène Pro (Q111597636) dataset that includes entities of a class named "salle de spectacle" in the local database. This class describes performing spaces within performing arts buildings. This class does not exist in Wikidata. The closest concept is event venue (Q18674739), but it's a much, much broader class. The simplest solution might be to create a new class item for this concept. However, members of the WikiProject: Cultural venues are hesitant, because the concept does not seem to exist in thesauri and authority files (with the exception of this [terminology database record]).

In the absence of a clear consensus on the creation of a new class item, we are planning to describe these entities as instance of (P31)event venue (Q18674739). We are further considering to add a qualifier to distinguish these entities from sports stadiums, convention centres and ski resorts and other entities in the same subclass hierarchy. My first thought was to qualify them as event venue (Q18674739)of (P642)performing arts (Q184485). However, of (P642) is slated for deprecation and the property description recommends the use of a more specific property. The most specific property to qualify rooms/halls in the Scène Pro (Q111597636) dataset is has use (P366). The problem is, has use (P366) is not an allowed qualifier for instance of (P31).

I do not want to edit instance of (P31) constraints without consulting the Wikidata community. Should we add has use (P366) as an allowed qualifier for instance of (P31)? Should we opt for of (P642) and keep fingers crossed that it isn't deprecated too soon? Or are there other solutions that my colleagues and I should consider?

Notified participants of WikiProject Cultural venues

Notified participants of WikiProject Performing arts Fjjulien (talk) 02:48, 14 April 2022 (UTC)[reply]

@Fjjulien Why not use has use (P366) as independant statement ? I would propose not use of (P642) as qualifier. There was already many discussion about the bad efficacity of it. SAPA bdc (talk) 08:18, 14 April 2022 (UTC)[reply]

Using P366 as a main statement is indeed an option. Personally, I would prefer it if has use (P366) statements were added to class items - and could therefore be inferred to all instance of these classes. Otherwise, we have completeness issues that makes the data less reusable. However, in the case at hand, we are missing the class item, hence my suggestion of using a qualifier. This being said, unless the community provides any feedback on allowing P366 as an allowed P31 qualifier, then we'll have no other choice but to use it as a main statement. Fjjulien (talk) 17:28, 19 April 2022 (UTC)[reply]

@Fjjulien: subject has role (P2868) is probably the more commonly used property as a qualifier; though typically with the sense that "the main statement is true when the item has this role", in a case when an item is covering a thing which can have more than one role.

Personally I would create a new class for "salle de spectacle" -- it seems a well-enough defined concept, narrower and more precise than "event venue", so it would be a good thing to have an item for it. Jheald (talk) 18:17, 19 April 2022 (UTC)[reply]

Participants in the WikiProject Cultural venues once discussed the idea of creating a new class item and hesitated to (see this discussion). In the light of the data structure in this dataset, we will have to revisit this idea in an upcoming meetup. Fjjulien (talk) 22:01, 20 April 2022 (UTC)[reply]

@Jheald: @SAPA bdc: After discussion with my colleagues, we retained two options:

P31 qualifier event venue (Q18674739)of (P642)performing arts (Q184485): The qualifier tells human users that the value is not granular enough to accurately describe the subject. If a new class item is eventually created, we will update these items and use the new value instead.
Main statement has use (P366)performing arts (Q184485): This main statement will facilitate queries and data reuse.

Here is a sample item from the upload: Salle Cogeco (Q111669162). Fjjulien (talk) 22:12, 20 April 2022 (UTC)[reply]

Jheald gave good advice; I'm sorry you've decided instead to use the most unhelpful qualifier available - User:Lucas Werkmeister/P642 considered harmful. --Tagishsimon (talk) 00:55, 21 April 2022 (UTC)[reply]

Germans have invaded city hall

We used to have city hall, but now it became rathaus? What the heck? @BohemianRhapsody, VIGNERON, Fralambert: I understand you trying to clean up based on these edits, but the last time City Hall (Q2587792) was a rathaus, was in WWII. You seem to have the mess even bigger than it was in your attempts to fix it. Maybe better to revert and start over? Changing the meaning of a widely used item is not the way to go. Probably better to split out in specific well defined items like we did with mayor of a place in the Netherlands (Q13423499)? Multichill (talk) 12:29, 14 April 2022 (UTC)[reply]

I don't remember all the details and I'm not sure if the mess was bigger before or after (the second version of this item was already very confusing and confused). But clearly it's a mess now.

Not sure what is the solution, revert doesn't seem right, maybe the best now would be to entirely delete this item and start other? And agreed, mayor of a place in the Netherlands (Q13423499) is what we should aim for.

Cheers, VIGNERON (talk) 15:04, 14 April 2022 (UTC)[reply]

Revert does indeed seem right. Difficult to delete an item on which hundreds of other items have a dependency. --Tagishsimon (talk) 17:10, 14 April 2022 (UTC)[reply]

Revert or not, in both cases, there is at least ~5000 items to clean anyway. Cheers, VIGNERON (talk) 18:52, 14 April 2022 (UTC)[reply]

town hall (Q25550691) is the broader term for every city hall, while "Rathaus" is a specific word used only in German language, so it's correct that Rathaus is a subclass of town hall. Before of my edits, Rathaus (Q543654) already had most of his Wikipedia links pointing to "Rathaus" pages, I just fixed the labels to reflect this. The problem is in the use of Rathaus (Q543654) in Wikidata items that aren't in German-speaking countries. Maybe these items can be fixed by a bot? --BohemianRhapsody (talk) 08:31, 15 April 2022 (UTC)[reply]

842 German items with this P31. 4,862 non-German items with this P31. There's no 'just' about this. You're breaking wikidata on an industrial scale. In general, the onus is on users not to do this sort of thing: not to make a huge mess and stand back expecting other people to clear it up. If you take on the responsibility for changing the semantics of an item to fit your idea of what the item truly represents, you need to take on responsibility for fixing the 85.2% of items you've broken. --Tagishsimon (talk) 09:58, 15 April 2022 (UTC)[reply]

It looks like the "town hall" sitelinks are split between the two items. de:Gemeindehaus (Kommune) at Q25550691 is limited to German-speaking countries and seems to describe different things; it's probably closer to "parish hall" or "village hall" in Germany and Austria, and is only the same as "town hall" in Switzerland. de:Rathaus is not specific to any country, and de:City Hall (London) is described as a Rathaus. Q3604202 (talk) 07:18, 20 April 2022 (UTC)[reply]

Wikisource Sitelinks Policy

Over the past several months, some Wikidata editors have been deleting Wikisource sitelinks from literary work data items and moving them to newly created version/edition/translation items linking to the original work. These changes break the sitelinks system for Wikisource because Property:P747 is not searched for additional language links, for very good reasons. The problem currently affects over 6500 Wikisource pages, making them inaccessible from other Wikisource language versions through the sitelinks system. In addition, those changes also violate at least three different editing guidelines which implicitly state that Wikisource sitelinks belong primarily on the data item of the main literary work:

Sitelinks documentation
Wikisource: How to Help (see Works example #4 in particular)
Wikisource Language Policy

I'd like to propose the following solution:

Clarify Wikisource: How to Help to explicitly state that the main data item of a literary work must link to an appropriate page on all Wikisource language domains where the literary work is available. Which page is "appropriate" will be decided by the respective Wikisource language community.
Add a constraint check to Property:P747 that will indicate an issue when the child data item has a link to Wikisource language domain which is missing on the parent data item.
Fix those 6500+ Wikisource pages by moving the sitelinks to the main literary work data items.

Next ghost (talk) 19:23, 14 April 2022 (UTC)[reply]

No. The thing on Wikisource is a version/edition. It's quite right for a WD item on the same version/edition to point to the WS version/edition. It's unclear what the problem you're observing on WS is, but you've not made a compelling argument for WD changing what it does. Not least, I'm unclear how your suggestion works if WS has two distinct editions of the same literary work. --Tagishsimon (talk) 19:34, 14 April 2022 (UTC)[reply]

My suggestion does not apply to WS domains with multiple editions of the same work because the main data item already links to a disambiguation page and the existing version/edition data items are linked correctly. Only works with single version of the text on Wikisource are affected by the problem. Here's an example: The Ugly Duckling has a total of 11 language versions on Wikisource but only 3 of them are visible through the sitelinks system as you can see e.g. on the Romanian Wikisource which does not use any explicit interwiki links in the page text. The Romanian text itself is not visible from any other language version of Wikisource because it's linked to an edition data item instead of the main work as it should be according to written guidelines. If you want to change the guidelines to "legalize" the recent breaking changes, you'll have to ask for approval from all Wikisource communities because you'll be changing guidelines for a system created primarily for their use. Next ghost (talk) 20:25, 14 April 2022 (UTC)[reply]

Yes. It's kinda sort of like the Bonnie & Clyde problem. Still, WD is doing the correct thing in linking WD edition items to WS edition pages. Arguably any sitelink from a WD literary work to a WS edition of that work is wrong; WD should have an edition item. I respect that that all means that sitelinks, on their own, cannot be relied on in WS to link one edition to the next, one language version to the next. But you fix that problem not by screwing up and bodging the wikidata, but by developing technology - a template perhaps - which can cope with the not very big leap from a WD edition item to its WD literary work item. Something like Common's Wikidata Infobox would do the trick. You speak of "written guidelines", but WD is not bound by anything written on WS, and I'm unaware of any guidelines agreed by the WD community which say "link apples to pears to help a poor WMF site out". WD does not have to ask WS for approval. You have, in short, an admitted problem, but also ahold of the wrong end of the stick. --Tagishsimon (talk) 20:47, 14 April 2022 (UTC)[reply]

Sitelinks documentation and Wikisource: How to Help are both Wikidata guidelines for working with sitelinks. Next ghost (talk) 21:55, 14 April 2022 (UTC)[reply]

Hmm, I think the issue here is what exactly documents on Wikisource mean. Are they like the encyclopedic articles on a Wikipedia, that are "about" a particular work (in all its editions and translations)? Or are they themselves works that are editions/translations of the work in question. If the latter then the interwiki-linking solution that works for Wikipedias simply is not correct for Wikisource, and WMF/Mediawiki devs need to fix it. ArthurPSmith (talk) 21:00, 14 April 2022 (UTC)[reply]

Asking what they're about is a little like asking about intentionality w.r.t. a crime. The fact remains that a wikisource document which is a copy of an edition or version, is an edition or version. And should be linked to a WD edition/version item. WMF/Mediawiki devs - despite WMF having 600ish staff - has shown no interest in solving Bonnie & Clyde, so I'd not hold out for them solving WS's problem. --Tagishsimon (talk) 21:22, 14 April 2022 (UTC)[reply]

I would argue that the sitelinks records should stand outside the regular Wikidata ontology and Sitelinks documentation strongly suggests that that was the intent behind the feature all along. Sitelinks to various wikiprojects are not inherent properties of the entities described by data items. Sitelinks are an interface for the wikiprojects to access additional features provided by Wikidata. Therefore sitelinks should follow the best approximation approach to fulfill the needs of those wikiprojects rather than trying to shoehorn wikipages into some rigid information structure. After all, the discussion about the Bonnie & Clyde problem is a discussion how to best serve the needs of wiki users reading about Bonnie and Clyde. Next ghost (talk) 22:12, 14 April 2022 (UTC)[reply]

Well, good luck with that argument. WS's time would be better spent developing a template which provides interwiki links based on WD's standard for Bibliographic Records, which makes a clear distinction between a work and its manifestations. Your "argue that the sitelinks records should stand outside the regular Wikidata ontology" is just a posh way of asking WD not to link an WD edition item to an edition WS page, but rather link the WD work item because neither WMF nor WS feel like putting in place templates or code to solve the not-hugely-difficult parent/child problem. Break the data because we lack a means of implementing a software solution. As I said at the start: no. --Tagishsimon (talk) 22:30, 14 April 2022 (UTC)[reply]

OK, let's see what solving the "not-hugely-difficult" parent/child problem would look like in practice. There are currently 75 Wikisource language domains and there may be hundreds in the future. So the list of links can also have hundreds of items. Whether it'll be a wiki sidebar or an infobox template inserted into page text doesn't matter, the contents will be exactly the same. Next, you don't want to label the links with the name of the literary work or edition, otherwise you'll end up with dozens of links saying e.g. "Iliad" pointing to different languages. You want to label the links with language names because that's what the user will be looking for. You also don't want a dozen links saying "English" pointing to different version of the text because the user has no way to tell the links apart. You want one link per language pointing to a disambiguation page or the edition text itself. And if the Wikisource community did not link any disambiguation page to the data item of the main literary work, you'll have to generate one automatically on demand. Sounds easy so far, right? Well, not so fast. What are you going to show on the autogenerated disambiguation page? All you have to work with is what's in the text edition data item. And there can be literally nothing else but the Wikisource sitelink and a reference to the parent data item. No translator, no publisher, no publication date, nothing. So again, you'll end up with a handful of links all saying e.g. "Iliad" and no way to tell them apart. I bet the WMF developers went through this design process and realized that any technical solution they create will be garbage. This is a problem that needs a bureaucratic solution instead and any technical solution they would create will only distract wiki communities from solving the problem properly. All the tools for implementing the bureaucratic solution already exist - sitelinks, disambiguation pages and redirects. The only thing left is for wiki editors to agree how to use them. Next ghost (talk) 13:28, 15 April 2022 (UTC)[reply]

@Next ghost: I'm a bit confused. Wikisources have both pages for works and editions. s:en:The Odyssey is a work (or close enough to be assimilated) and s:en:Odyssey (Pope) is an edition (same caveat). There is a consensus on that for along time and it seems it is what is reflected both in the policies you mention and in the uses of the community. Am I missing something?

« because Property:P747 is not searched for additional language links », uhh? we have the mw:Extension:Wikisource for that (since 2017). Again, am I missing something?

Cheers, VIGNERON (talk) 06:48, 16 April 2022 (UTC)[reply]

There are currently 6500+ edition pages with no corresponding Wikisource page for the main work. Most of those "orphan" edition items have been created in recent months and their Wikisource link was moved from the main work data item, which broke interwiki navigation. I am simply asking for policy clarification that when someone moves a Wikisource link from the main work data item to a new edition item, they have to backfill the main work item with something appropriate. In this situation, removing the Wikisource link from the main work data item without replacement is a data integrity error. The Wikisource extension only searches Property:P629 when generating interwiki links. You can see this for yourself in EditionLookup.php: The getEditions() method is not called anywhere in the code. Next ghost (talk) 18:44, 16 April 2022 (UTC)[reply]

@VIGNERON:Separate page for work and edition have only few projects, majority have only page for edition and the page for work only in case when more editions have own page. eg. on cs.wikisource we have at least 750 works with subpages (editions) and hundrets of work without subpage (editions, news articles etc), but only 38 "thematic disambiguations" (some of them are about work).

On edition with this extension page you can usually see only link which are on "work" item, but not editions on this item. Look at ro:Corbul_(Poe,_Caragiale) - there are only links from work. And then look to sv:Korpen_(Poe) - this wiki uses special module and you are able to see all other editions - and that'a the point Next ghost is talking about.

Is possible to use the script from sv+pl wikisource and enable edition links on all wikisources. JAn Dudík (talk) 17:04, 17 April 2022 (UTC)[reply]

@Next ghost, JAn Dudík: oh, I see now, thanks. Indeed when correcting a mistake it's not a good idea to stop midway, but I would say it's still better to half-correct than just leaving the error in the first place. Cheers, VIGNERON (talk) 18:00, 17 April 2022 (UTC)[reply]

this script and this module:Q86127036 can display editions via Wikidata on every wikisource. JAn Dudík (talk) 18:50, 17 April 2022 (UTC)[reply]

Global unicode attack

"User:Ekirahardian cont User:Ekirahardian" is about to upload SVG images of all Unicode characters to commons. This is of course good if done in a legal way. A related strange effect is uploading of thousands of huge modules to hundreds of wiktionaries (example) by "User:Ekirahardian" and "User:Kwamikagami", identical with each other, and needing frequent updates. On some wikis those modules got deleted equally quickly as they were created. Uploading affects particularly "weak" wikis (eowikt, idwikt), while no such modules have been uploaded to svwikt (having a well working bunch of active sysops) so far. All that those modules do is to convert a unicode codepoint thus an integer into 2 strings: offcial name of the char, and filename on commons. IMHO this should be done via wikidata, and those local modules should be deleted. I advocate to stop uploading and updating those modules until an efficient global solution has been elaborated. Taylor 49 (talk) 13:28, 15 April 2022 (UTC)[reply]

Speaking of efficiency, direct mapping via Lua is orders of magnitude faster than using Wikibase, Semantic Mediawiki and such. I doubt efficiency matter in this case though, it just seems like lack of planning. As for solutions, how about just adding image (P18) to instances of Unicode character (Q29654788), will that do? ~~Or maybe sitelink to commons is better?~~ Infrastruktur (talk) 13:49, 15 April 2022 (UTC)[reply]

I actually support this if that means we can have a centralized way to maintain the name and the images of the Unicode characters. AFAIK, modules that convert a Unicode codepoint to its official name (example) don't need to be updated frequently unless there is a new Unicode update (Like Unicode 13.0.0 to Unicode 14.0.0). But modules that convert a Unicode codepoint to its image (example) indeed need to be updated frequently depending on the availability of the images on Commons. Ekirahardian (talk) 14:30, 15 April 2022 (UTC)[reply]

Thank you for the thoughts. With efficiency I do not mean only the time to cary out a single conversion, but the overall efficiency of the wiki system, including all the stored modules and updates of those. Adding image (P18) to instances of Unicode character (Q29654788) seems to be a good idea, and the modules in single wikis can peek that. Taylor 49 (talk) 14:38, 15 April 2022 (UTC)[reply]

I asked elsewhere (on a bot talk page) how we might do this. Unless one of the Wiktionaries wants different images of the characters, I agree it would be best to have them mirror centralized lists, presumably kept on WD. That could be overridden locally if need be, but so far I haven't come across any language-dependent images. Certainly the names should be centralized, since they're standard. And a centralized db should make it easier to extend coverage to additional Wiktionaries.

The one place where I've seen language customization is in the Unicode block names, which are frequently translated. So that at least should allow for local override.

BTW, Taylor's repeated claim of "uploading of thousands of huge modules to hundreds of wiktionaries" is a gross exaggeration. There are 44 modules, some of them quite small. E.g. the images 025 module, to pick one at random, is tiny and has been uploaded to only 11 wiktionaries. Modules 002 and 01F have been uploaded to 29, which is the maximum. So more accurately there are "dozens of modules of varying size uploaded to a few dozen wiktionaries." Manipuri wikt has requested all 44, but I haven't gotten to it yet.

No reason to stop uploading SVG images, though, as all the files will be kept at Commons regardless, and the conversion once decided on will be trivial. Kwamikagami (talk) 17:29, 15 April 2022 (UTC)[reply]

Looking at a few entries on Wikidata (https://w.wiki/54BC), there's a couple of entries 844 / 150 000 that have images already in different styles. I wonder if lack of standardization will be an issue? Then again I don't know what the use case for this was supposed to be. This might be fixed by marking the preferred image with preferred rank. Infrastruktur (talk) 19:10, 15 April 2022 (UTC)[reply]

Sure uploading of SVG images to commons can and should continue, but maybe not uploading and updating those modules. Local overrride is always inherently possible. No need to permit it here on WikiData. There can be a local table for translating the block names. As to the nonstandard images, I can see several possible solutions:

create a new property "Unique image of unicode char" allowing only one image and only in SVG format, complementary to Unicode character name (P9382) (preferred)
delete all existing images, and upload the new ones instead, by a bot
keep all images, if multiple are present, pick the SVG one, if multiple are SVG, pick just one "first come first served"

Taylor 49 (talk) 19:43, 15 April 2022 (UTC)[reply]

Wikidata:Property_proposal/Generic#Unique_image_of_unicode_char Taylor 49 (talk) 20:36, 15 April 2022 (UTC)[reply]

Another problem is how one can implement a "reverse query" in LUA:

SELECT ?officialname ?uniblock
WHERE 
{
 [ wdt:P31 wd:Q29654788 ; wdt:P4213 "6666" ] wdt:P9382 ?officialname ; wdt:P5522 ?uniblock
}

md_docs_topics_lua.html Wikidata:SPARQL_tutorial Taylor 49 (talk) 12:55, 16 April 2022 (UTC)[reply]

Still curious what @Ekirahardian: thinks about standardising the image style of character pictures. Sometimes it's more important to understand why a particular rule (such as try to preserve old claims) exists than to always follow it to the letter. I suspect standardising the images would be a nice thing to have, and the tools like Quickstatements don't work all that well with ranks. Also the number of images out of the amount that could be added is miniscule so, deleting the link to the old picture before replacing it with a new one might be pragmatic since this data will be added in bulk, after all we don't want to make things more difficult than they have to be for contributors. If someone complains I'd say that means that they've volunteered to do the job themselves.

@Taylor_49: Not sure what you mean by reverse query, if this is a use case noone has mentioned it yet. When you grab things in LUA the results of that is usually saved in the page cache. However queries are not cached for a long time, so you'd typically use something like Listeria, to have the results cached for some amount of time. But that might not be all that reliable depending on what you intend to use this for. What I've done in the past to improve performance or cut down on the amount of queries is to save the results of the query in Lua or JSON format, this will then act as a fast cache. The downside is this requires help from the site technicians to completely automate, otherwise you'll be running scripts manually from time to time. So yeah, if you actually need efficient reverse lookups then you won't get rid of those pesky modules. Infrastruktur (talk) 13:40, 16 April 2022 (UTC)[reply]

@Ekirahardian, Infrastruktur: Well the problem is not page cache, but the fact that I do NOT have the QID. I have a "need Q-item with property YYY having value ZZZ" request. SPARQL can, but how to access it from LUA? Taylor 49 (talk) 21:59, 22 April 2022 (UTC)[reply]

This is the XY problem. You say you want something done a certain way, but you're not saying what you are trying to accomplish in plain english. Ekirahardian doesn't say anything about what he's going to use this for either, or whether it's considered useful to the site it was added to. I see no point in continuing this conversation until that happens. No one here reads minds. Infrastruktur (talk) 23:09, 22 April 2022 (UTC)[reply]

NOT really. YES we CAN @Germartin1, Infrastruktur: How do I find the Q-item with Unicode code point (P4213) having value "6666" from LUA ? Taylor 49 (talk) 11:52, 23 April 2022 (UTC)[reply]

Help needed for merging

Hello, I want to merge

Q97170323 Cupra Born, created on July 12th, 2020‎

with the older

Q61934112 [SEAT el-Born/ Cupra el Born], March 1st, 2019‎

However at the page Special:MergeItems I get the message that „‪Q97170323“ is unknown. What is my mistake? --KaPe (talk) 17:05, 17 April 2022 (UTC)[reply]

Both items have sitelinks for the same project, so it is not possible to merge them. By the way, it does not look to me like Cupra Born (Q97170323) and SEAT el-Born (Q61934112) are the same thing. --Ameisenigel (talk) 18:24, 17 April 2022 (UTC)[reply]

Hello Ameisenigel, in your answer we have the technical aspect („items have sitelinks for the same project“) where my English isn‘t sufficient to unterstand the meaning (auf Deutsch?). And the content question – should we regard the two wikidata items as referring to the same object. Lacking the knowledge of the place to discuss the merging, I had tried to act according to de:WP:Sei mutig, or en:WP:Be bold. Where is that discussion place? --KaPe (talk) 12:10, 19 April 2022 (UTC)[reply]

One item links to cs:CUPRA Born and the other links to cs:SEAT el-Born. If they are the same then these articles will need to be merged — Martin (MSGJ · talk) 16:05, 20 April 2022 (UTC)[reply]

Wikidata weekly summary #516

Here's your quick overview of what has been happening around Wikidata over the last week.

Discussions
- Open request for adminship: Pi admin bot (RfP scheduled to end after 20 April 2022 17:58 UTC)
- Closed request for adminship: Stang (successful)
- New requests for permissions/Bot:
  - Stangbot 2. Task/s: Insert electorate (P1831) and keep it updated on Brazilian municipalities and states items
  - AmeisenBot. Task/s: Label unsigned comments on talk pages

Events
- Upcoming:
  - Next Linked Data for Libraries LD4 Wikidata Affinity Group call will be on Tuesday, April 19 at 11 AM Eastern US time: Martin Schibel will be speaking on Entitree. Please note this is one hour earlier than the usual meeting time Agenda
  - The next Wikidata+Wikibase office hours will take place on Wednesday, April 20th 2022 at 17:00 UTC (18:00 Berlin time) in the Wikidata Telegram group. The Wikidata and Wikibase office hours are online events where the development team presents what they have been working on over the past quarter, and the community is welcome to ask questions and discuss important issues related to the development of Wikidata and Wikibase.
  - LD4 Wikibase Working Hour: Learn about Wikibase system exploration, data model development, and the road ahead for Digital Scriptorium. When: Thurs. 21 April 2022, 3PM Eastern US (time zone converter). Where: Registration Link
  - Register for Contribuling – Conference on minority languages and free participative software. Conference date: April 22
  - Online Wikidata meetup in Swedish #105, April 24th at 12.00 UTC

Press, articles, blog posts, videos
- Blogs
  - WeDigBio Transcription workflow "...blogpost...showing how I go from finding the name of a collector when transcribing labels to adding them to Wikidata & then linking them to their collections via Bionomia."
  - More Wikidata metrics on the Dashboard
- Videos
  - Transfer bibliographic data from Zotero to Wikidata (in Italian) - YouTube
  - Art+Feminism community Hours: Add your event data to Wikidata! - YouTube (En, Fr)
- other:
  - Decolonizing the Internet’s Structured Data – Summary Report by Whose Knowledge?

Tool of the week
- Bird O'Clock! is a tool based on Wikidata and other data sources that shows pictures and numbers from actual people counting actual birds in the actual world!
- Tiago's Coin Herbarium is a coin collection depicting different plant information displayed via Wikidata SPARQL queries.

Other Noteworthy Stuff
- Wikidata and Wikibase 2022 development plan has been updated to include activity estimates for the second quarter (Q2).
- There is a new hub page for the Wikidata Query Service scaling updates, to help you all stay updated.
- Wikidata metrics are now easily accessible on the Dashboard. Here's an example Dashboard including a blog post above detailing the process.

Did you know?

Development
- Lexicographical data: Worked on inferring the spelling variant from the language's Item on the new Special:NewLexeme page and started building a little help box on the special page to explain what lex. data is.
- REST API: Getting closer to having a first version of the REST API that returns Item data.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Monthly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Comment on property proposals: all open proposals
- Contribute to a Showcase item.
- Help translate or proofread the interface and documentation pages, in your own language!
- Help merge identical items across Wikimedia projects.
- Help write the next summary!

Read the full report · Unsubscribe · Mohammed Sadat (WMDE) 13:41, 18 April 2022 (UTC)[reply]

Merge plant synonyms?

I wanted to merge Michelia figo (Q15613376) to Magnolia figo (Q311864), but I noticed that another synonym for the same plant, Liriodendron figo (Q15613379), has its own item. What's the procedure here to get all of the Wikipedia links listed together? AjaxSmack (talk) 15:03, 18 April 2022 (UTC)[reply]

@AjaxSmack You can move the sitelinks to any item you like. But please keep all taxon items separate (do not merge!) - each scientific name has its own item in Wikidata. Vojtěch Dostál (talk) 12:29, 19 April 2022 (UTC)[reply]

Thanks. AjaxSmack (talk) 21:18, 19 April 2022 (UTC)[reply]

Donation of Bibliographic Info from a Journal

Hi all, My team and I are interested in making bibliographic data from the Semantic Web Journal available in Wikidata.

This would include the following metadata from the papers: title, DOI, DOI URL, authors, author affiliation, issue the article appears in, issue editor list, publication date, preprint date, page start, page end, keywords, and link to the full text of the article where avaialable. (The journal recently moved to full open-access.)

We are happy to maintain the data, and in fact one of our goals is to fully automate this process as much as possible. From a community standpoint, what are the next steps in this process?

Thank you, AndrewEells (talk) 17:11, 18 April 2022 (UTC)[reply]

@AndrewEells: thanks for your offer, but nobody seems to have considered it interesting enough to respond. How does your data improve Wikidata? Wikidata has become the dumping ground for scientific papers, this just seems to just add on to the pile. Multichill (talk) 11:10, 23 April 2022 (UTC)[reply]

Name for Swinton Community School (Q16900993)

Not sure how renames are done in wikidata, probably best that I do not know. Hoping that it is fair (vs avoid being a burden on other editors) to request that Swinton Community School (Q16900993) be renamed as Swinton Academy. It converted to an academy, per the 2010 Academies Act, in 2016. Thanks. Jmg38 (talk) 23:34, 18 April 2022 (UTC)[reply]

Done. Your request was completely fair and not a burden at all. :) --Quesotiotyo (talk) 18:35, 19 April 2022 (UTC)[reply]

Can checksum (P4092) be used for software?

Can checksum (P4092) be used for software? Checksums that is. If not, I'm willing to host such data on an own Wikibase instance. Thank you. Maskingself (talk) 07:51, 19 April 2022 (UTC). I changed my mind, if nobody wants the data I will host the Wikibase intance locally but publish the RDF(linked data) on the web in a "recurring fashion". That way, more linked data for the internet in matters I'm concerned. I might publish to Internet Archive, if nobody wants this data here Maskingself (talk) 08:09, 19 April 2022 (UTC)[reply]

If the software is notable you can add a checksum for the latest stable release. However I think adding checksums for all the releases is junk data, so this should be hosted elsewhere. You don't really need a Wikibase instance for something like this, most FOSS projects simply store the checksum in a file on the webserver, with the filename of the original file with a suffix of ".sha1" or whatever hash you prefer, this is dead easy to generate with a script. Infrastruktur (talk) 16:04, 19 April 2022 (UTC)[reply]

WikiProject Clinical Trials for Wikidata - the paper

See Wikidata:WikiProject Clinical Trials. Care about this because

We presented it as a model WikiProject in this new preprint - https://doi.org/10.1101/2022.04.01.22273328
It is a tidy cool WikiProject which coordinated the import of ClinicalTrials.gov (Q5133746) to Wikidata
I and others will continue to develop this project and further integrate it with Wikidata for medicine, universities, biographical records of medical researchers, and meta:WikiCite

Comments requested here or at the WikiProject talk page.

THANKS TO ANYONE WHO COMMENTS! Bluerasberry (talk) 19:22, 19 April 2022 (UTC)[reply]

Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines

More languages • Please help translate to your language

The Community Affairs Committee of the Wikimedia Foundation Board of Trustees would like to thank everyone who participated in the recently concluded community vote on the Enforcement Guidelines for the Universal Code of Conduct (UCoC).

The volunteer scrutinizing group has completed the review of the accuracy of the vote and has reported the total number of votes received as 2,283. Out of the 2,283 votes received, a total of 1,338 (58.6%) community members voted for the enforcement guidelines, and a total of 945 (41.4%) community members voted against it. In addition, 658 participants left comments with 77% of the comments written in English.

We recognize and appreciate the passion and commitment that community members have demonstrated in creating a safe and welcoming culture that stops hostile and toxic behavior, supports people targeted by such behavior, and encourages good faith people to be productive on the Wikimedia projects.

Even at this incomplete stage, this is evident in the comments received. While the Enforcement Guidelines did reach a threshold of support necessary for the Board to review, we encouraged voters, regardless of which way they were voting, to provide feedback on the elements of the enforcement guidelines that they felt needed to be changed or fixed, as well as why, in case it seemed advisable to launch a further round of edits that would address community concerns.

Foundation staff who have been reviewing comments have advised us of some of the emerging themes, and as a result we have decided as Community Affairs Committee to ask the Foundation to reconvene the drafting committee and to undertake another community engagement to refine the enforcement guidelines based on the community feedback received from the recently concluded vote.

For clarity, this feedback has been clustered into 4 sections as follows:

To identify the type, purpose, and applicability of the training;
To simplify the language for easier translation and comprehension by non-experts;
To explore the concept of affirmation, including its pros and cons;
To review the conflicting roles of privacy/victim protection and right to be heard.

Other issues may emerge during conversations, and particularly as the draft Enforcement Guidelines evolve, but we see these as the primary areas of concern for voters and are asking staff to facilitate review of these issues. After further engagement, the Foundation should re-run the community vote to evaluate the revamped Enforcement Outline to see if the new document is then ready for its official ratification.

Further, we are aware of the concerns with the note 3.1 in the Universal Code of Conduct Policy. We are directing the Foundation to facilitate a review of this language to ensure that the Policy meets its intended purposes of supporting a safe and inclusive community, without waiting for the planned review of the entire Policy at the end of year.

Again, we thank all who participated, thinking about these critical and difficult challenges and contributing to better approaches across the movement to working together well.

Best,

Rosie

Rosie Stephenson-Goodknight (she/her)
Acting Chair, Community Affairs Committee
Wikimedia Foundation Board of Trustees
YKo (WMF) (talk) 04:06, 20 April 2022 (UTC)[reply]

How to proceed

Dear Wikidata members,

Since I am new to Wikidata I thought the best way to act now is to ask a question. At the moment I am keen to understand how to proceed for a specific data import. The Wikidata:Dataset Imports page has a warning that it is inactive and the module also doesn't provide the specifics I am looking for (I don't have a distinct online dataset, I have my own, see below.) Also I see that on Wikidata:Bot requests there is rather a large list with requests and (I haven't read them all, but) sometimes it is mentioned that a discussion is required first. I hope this is the right place to start that discussion, and if not, I hope to learn where to address my questions / requests.

Based on data from Statistics Netherlands (Q167086) I have created a dataset with the population per municipality per month. The current version of the script runs for februari 2022. In this set I have joined data from two Statistics Netherlands sources and added Wikidata item-ID's and some Properties that might be of importance.

At this moment the script produces a dataframe / spreadsheet and isn't the most pretty code. The python script and a result table can be found here. Please have a look and share your thoughts with me, any kind of feedback is welcome. The idea is that it can run every month forward (and back to 2002 with a few changes - because the data needs to map on old municipalities) and needs revision once the municipalities change (which is annual and sometimes more frequent). The published script is 'just' a script that generates a desired dataset. First I wrote building blocks in two layers (reusable functions and data specific functions) which still is visible in the script. For communication purposes on the Dutch wiki and here I moved it into one script. And I was too lazy to set up a main().

Please advice me how to proceed... Démarche Modi (talk)

Monthly data is too granular for Wikidata; items become unusable when they have hundreds or thousands of statements, and each month would be its own statement for something like this. Wikimedia Commons has a tabular data format you could use, and we have tabular population (P4179) to link to those files from here. It would probably be helpful to place the most up-to-date value on the item here though too. ArthurPSmith (talk) 19:56, 20 April 2022 (UTC)[reply]

Thank you, I'll look into this. With your last sentence, do you mean to have one P1082 which is periodically overwritten with the latest value? Démarche Modi (talk) 07:35, 21 April 2022 (UTC)[reply]

@Démarche Modi: Yes, that is what I had in mind there. ArthurPSmith (talk) 19:26, 22 April 2022 (UTC)[reply]

Also as a note, the latest value should be marked as preferred. AntisocialRya n (Talk) 22:16, 22 April 2022 (UTC)[reply]

Roller Coasters with unrealistically high speeds

I just noticed an issue with several roller coaster (Q204832), that have rediculously high speed (P2052) (<insert Space Balls Ludicrous Speed Meme here>) assigned to them, of more than 500 km/h. I am not sure if this is vandalism or unit conversion errors (probably a bit of both), but I currently don't have the time to look into this and fix them, so maybe somebody else has a few minutes to spare.

Here is the query that returns the 10 items in question: https://w.wiki/55Lt .

The currently fastest roller coaster in the world is Formula Rossa (Q25002) with a top speed of 240 km/h (149.1 mph), and Euthanasia Coaster (Q610172) is also correctly modelled with its 360 km/h, as this is a theoretical/satirical concept only.

Thanks, Frog23 (talk) 16:15, 20 April 2022 (UTC)[reply]

Your query gives only the numeric values and ignores the given units for the speed, so the values cannot be compared as they can have different units. I suggest using normalized values in m/s by changing ?rc wdt:P2052 ?speed to ?rc p:P2052 / psn:P2052 / wikibase:quantityAmount ?speed in the query. If you prefer you can then multiply with a constant to get e.g. km/h or mph instead. But still, you are right that the speeds are too high. --Dipsacus fullonum (talk) 16:38, 20 April 2022 (UTC)[reply]

One item had been vandalised; the others were errors caused by using a comma as a decimal point. Q3604202 (talk) 13:37, 22 April 2022 (UTC)[reply]

Global Species List Working Group

I have made a post on Wikispecies to request information from Wikispecies, Wikidata, and Wikipedia editors who work with species taxonomy. I am aware of WMF policies, but this is a crucial gathering of information and I believe its important that editors here on WMF have their say as you are producing checklists. Thanks everyone, cheers Scott Thomson (Faendalimas) ^talk 18:23, 20 April 2022 (UTC)[reply]

Bus stops

Considering adding a bunch of bus stops for a city with coordinates, from a source that is available under an open license. The examples I've looked at doesn't connect one stop to another, so I was wondering how these are modelled on Wikidata, is a pair of bus stops, each going the opposite direction of the other considered one bus stop, or should I add one bus stop for each direction? Also are bus stops considered notable without sitelinks? And third is there a property like adjacent station (P197) that can be used for bus stops? I wasn't able to find one. If this doesn't exist, should it be added? Infrastruktur (talk) 21:35, 20 April 2022 (UTC)[reply]

Depends on how much it buggers up coordinates to use only one item. Train stations with multiple directions of railway line tend to be modelled in single items. Bus stops in my experience - (e.g. transmodel eurobus as NT stop space) - tend to be modelled as discrete records.
IMO yes, they're notable per WD:N criteria 2 and, arguably, criteria 3.
Use adjacent station (P197), which has the useful alias 'next stop'. --Tagishsimon (talk) 21:52, 20 April 2022 (UTC)[reply]

We could extend the definition of P197 to include all transport routes (train, bus, tram, ferry, etc.). However, there is the problem that it would be nice if we could also indicate the direction of traffic. Where I live, there are both bus routes where the buses go both ways, and bus routes where they only go in one direction. For the latter case, you would need separate properties for "previous station" and "next station" or equivalent qualifiers. If the bus stops for each direction are in different places (e.g. on opposite sides of the road) it would be most accurate to have items for each direction, but it also happens that buses in both directions stop at the same place. --Dipsacus fullonum (talk) 22:00, 20 April 2022 (UTC)[reply]

Do I use the connecting line (P81) qualifier for adjacent station (P197) to denote which "line" or rather route number the statement applies to? It could be very tricky adding the routing, so I guess I'll start with just the stops, pun intended. Edit: I guess I could use the the towards (P5051) qualifier to specify direction, I saw it used on some french metrobus service. Infrastruktur (talk) 18:58, 21 April 2022 (UTC)[reply]

I understand P5051 as indicating the direction to a particular terminus, not whether the trains (or buses) are heading to the neighbouring station or coming from it or both. Trains usually always run in both directions (if there are exceptions, I don't know them), while buses (where I live) often only run a route in one direction. --Dipsacus fullonum (talk) 03:40, 22 April 2022 (UTC)[reply]

PS. There is also the problem that bus routes are unstable and often change as it is easy to change a bus route and move stops (compared to moving a railway). --Dipsacus fullonum (talk) 03:48, 22 April 2022 (UTC)[reply]

I would rather use connecting service (P1192) to model the "transport line" (be it tramway/service/train/bus etc). Sometimes P1192 is better for metro lines (it happens there are single physical train track that are serviced by diffent "metro passenger lines") Bouzinac ^{💬●✒️●💛} 12:08, 22 April 2022 (UTC)[reply]

Do we really want to have all bus stops on Wikidata? Sounds more like something for OpenStreetMap. They also have a good system to connect stops and lines. Multichill (talk) 11:06, 23 April 2022 (UTC)[reply]

P16 How to retrieve data from Wikidata

Hi 😊 Friends I am Monica Please 🥺🙏 Tell me how i can retrieve data from Wikidata. Because I am New and I really need to know some Stuffs From here and I need to know Your names Thanks Please don't delete my Chat Thanks ❤️❤️❤️❤️❤️😍

Please check out this page Monica https://www.wikidata.org/wiki/Wikidata:Data_access Germartin1 (talk) 11:44, 22 April 2022 (UTC)[reply]

Wikidata:Project chat

Contents

taxon common name (P1843)

"has use" qualifier for P31 values

Germans have invaded city hall

Wikisource Sitelinks Policy

Global unicode attack

Help needed for merging

Wikidata weekly summary #516

Merge plant synonyms?

Donation of Bibliographic Info from a Journal

Name for Swinton Community School (Q16900993)

Can checksum (P4092) be used for software?

WikiProject Clinical Trials for Wikidata - the paper

Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines

How to proceed

Roller Coasters with unrealistically high speeds

Global Species List Working Group

Bus stops

P16 How to retrieve data from Wikidata

Navigation menu

Wikidata:Project chat

taxon common name (P1843)

"has use" qualifier for P31 values

Germans have invaded city hall

Wikisource Sitelinks Policy

Global unicode attack

Help needed for merging

Wikidata weekly summary #516

Merge plant synonyms?

Donation of Bibliographic Info from a Journal

Name for Swinton Community School (Q16900993)

Can checksum (P4092) be used for software?

WikiProject Clinical Trials for Wikidata - the paper

Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines

How to proceed

Roller Coasters with unrealistically high speeds

Global Species List Working Group

Bus stops

P16 How to retrieve data from Wikidata

Navigation menu

Search