### Text:
Earth is the third planet from the Sun and home to all known life.
While large volumes of water can be found throughout the Solar System, only Earth sustains liquid surface water.
Approximately 70.8% of Earth's surface is made up of the ocean, dwarfing Earth's polar ice, lakes, and rivers.
### N3 triples using Wikidata entities:
Q2 P31 Q3504248
Q2 P527 Q42762 (comment: preset, GPT-3 continuation follows)
Q2 P361 Q8
Q2 P361 Q8
Q2 P361 Q8
...
when i try to add Category:Asura on Asura (Q624083) it shows "The link commonswiki:Category:Asura is already used by Item Q28747950. You may remove it from Category:Asura (moth) (Q28747950) if it does not belong there or merge the Items if they are about the exact same topic. If the situation is more complex, please see Help:Sitelinks.". how do i proceed? —Gunyam (talk) 02:33, 2 February 2023 (UTC)
you've stepped in a messy conflict on wikidata. the short answer is that a page can be linked only to one item. In this case it's already linked to an item for the category. So instead what you can do is link it via the property Commons category (P373). This is already the case for this item so there's nothing to be done. 2601:647:5F01:F510:F0BF:4467:2C58:BA9A06:17, 2 February 2023 (UTC)
Ancient Egyptian for the "Language (mandatory)" seems impossible
I'm unable to add "Tutankhaten" as Tutankhamun (Q12154)'s birth name because I can't figure out how to use either "Middle Egyptian language" or "Late Egyptian language" or even just "Egyptian language" as qualifiers. This is very frustrating.StarTrekker (talk) 01:00, 2 February 2023 (UTC)
Disclaimer: I know next to nothing about ancient egypt or language. Language tags on Wikidata doesn't seem to include ancient egyptian. I would use birth name (P1477) and the language code "mul" with qualifer language of work or name (P407) and the Q-item for the language here, and feel free to make a guess as to which language to specify. Chronologically it's probably middle egyptian, but I'm guessing "egyptian" acts as a macro-language, in the same way that "norwegian" is a macro-language for the written forms "Bokmål" and "Nynorsk" as well as referring to the various spoken dialects. In other words "egyptian" is the safer choice. Infrastruktur (talk) 13:29, 2 February 2023 (UTC)
Reality check: P560 'direction' versus P564 'direction relative to location'
Can I get a reality check on the meaning, label and descriptions for direction (P560) and direction relative to location (P654), please. In particular, the parenthetical segment of each description seems to me to conflict with the main part of the description.
direction (P560) - "qualifier to indicate the direction of the object relative to the subject item (for direction to the object, see P654)" So if my subject is the Mediterranean Sea and object is Africa, am I right in thinking P560 should take a value of 'south'? And if so, "(for direction to the object, see P654)" south is the "direction to the object", so why am I being directed to P654?
direction relative to location (P654) has the equal and opposite issue; and in addition, what does 'location' mean in the label? Location of the object or location of the subject? Why does the label not say object or subject?
Unsourced, and apparently wrong, data from a Wikipedia article
We've just had a query at the English Wikipedia help desk from an editor claiming to be Peppino D'Agostino and complaining that his age is showing as 72 when it should be 66. I checked the English WP article and found no birthdate or age in it, and said so, directing him to Google. But another editor pointed out that Google may well have got the date 1951 from Q3899403, where it was imported from it-wiki, having been inserted by an IP in 2011 with no source. Looking at w:it:Peppino D'Agostino, I see that the date was updated to 1957a couple of weeks ago, still unsourced.
Of course, the WD item was not updated accordingly, so I've just updated it. But this is clearly not satisfactory: it seems odd that it should have been imported from WP in the first place, particularly without checking for a source. WP is not regarded as reliable by WP: why should it be by WD?
So I started posting this to ask how we handle it.
Then I realised a further complication: the original post on the help desk claims that his DoB is 1956, not 1957 (again, we have no guarantee that this is D'Agostino). I thought I would edit the item again, and remove the reference; but it objects to a DoB without a reference (reasonably) so I reverted myself.
Thanks. He has now provided a reference, so I have corrected the date and added the reference. I've never done referencing on WD before, so I'd be grateful if somebody would check that what I've done is satisfactory. Q3899403. ColinFine (talk) 21:56, 2 February 2023 (UTC)
I've made a page about Arthur Edward Wade in Wikipedia and there's now a Wikidata item for him (Q116505152). However, I've now realised he is undoubtedly the same man as Arthur Edwin Wade who is in Wikispecies and Wikidata (Q21388511). Same birth & death years, lichenologists, same part of the world, Edwin often a short-form of Edward. He must have been referred to as Edwin somewhere, but I havn't come across that usage yet. How do I get them all matched up, and his alternate second names noted. (I can do a redirect in Wikipedia but how does it work in Wikidata and Wikispecies?) MerielGJones (talk) 10:14, 31 January 2023 (UTC)
He definitly is "Arthur Edward Wade" in his birth record and the 1911 census. "Edwin" must have crept in by mistake at one point and been repeated. --RAN (talk) 06:44, 5 February 2023 (UTC)
Permission to update population of Hungarian municipalities
Dear Users! I'm asking permission to update the population of Hungarian municipalities. You can see examples here. Please support my request here. With thanks, --Bean49 (talk) 10:35, 5 February 2023 (UTC)
Could we get to the bottom of the issue? One of the disputed P31s is described as "municipality with market privileges in Germany" and the other as "municipality without town privileges in Germany". 1) can a municipality be both of these 2) is there a source - we're dealing with unreferenced statements. --Tagishsimon (talk) 11:30, 1 February 2023 (UTC)
This is a very complicated topic because Germany is a federal state which consists of sixteen states with different rules for each state. In Bavaria (one of the states) there is the concept of having municipalities with market privileges (see de:Liste der Märkte in Bayern). Some municipalities in Bavaria have this privilege others do not. In some other state there are similar concepts also called "market", however they mean something different. Luckely, there is one global concept in Germany which applies to every municipality. Either it is a "Stadt" or it is not. I try to represent this in Wikidata by non-urban municipality in Germany (Q116457956) and urban municipality in Germany (Q42744322) (see also de:Gemeinde (Deutschland) and de:Liste der Städte in Deutschland). To answer your questions:
1) Yes, a municipality can be both: non-urban and a market. Historically however, the concept of a market is much older than Germany in its current administrative form.
2) Sources are provided in the German Wikipedia articles I linked above.
Some IPs change quickly others don't. In Germany, most people have dynamic IPs that change every day because ISPs historically wanted to upsell the feature of having a stable IP to people who run their own server and need a stable IP for that. In the US it's more common to have stable IPs where you can actually talk to people and ban IPs to remove a persons ability to access a site. The IP in question is a German one. ChristianKl ❪✉❫ 15:25, 1 February 2023 (UTC)
It is completely impossible to communicate with anyone behind an IPv6. Unless steps are taken on the ISP end to make the Interface ID stable, the Interface ID will change rapidly and unpredictably. A person/device with the same /64 but a differing Interface ID is 99% of the time the same person, with an altogether new and unconnected User Talk page. If a person's IPv6 has changed sufficiently that they no longer see their old User Talk, there is no way for us to sustain a conversation or even notify such a user of anything. Worse yet, it is similarly impossible to aggregate these User Talk pages for admins or vandal fighters to examine an audit trail of discussion or warnings during block decisions.
WMF is working on privacy enhancements that appear to rely more on browser/device fingerprinting rather than IP addresses to identify editors. So until that day comes, we will simply need to bring all IPv6 issues before admin noticeboards rather than vainly attempting to engage the user who will never hear us. (The same issues apply to all mobile users regardless of IPv4/IPv6.) Elizium23 (talk) 18:00, 1 February 2023 (UTC)
@Vojtěch Dostál: By the way: Edits of this form have taking place a few times already. A very annoying thing. If it was a logged in user, one could talk to him. Unfortunately, those edits are performed by an IP (each time another one). However, this time the situation is a bit different. Before my introduction of the item non-urban municipality in Germany (Q116457956) the item municipality in Germany (Q262166) was used and I understand the thought process of those people: Namely, market municipality of Germany (Q100341898) is a subclass of municipality in Germany (Q262166). However, there are still good reaons to use both. Nevertheless, now with the new item the situation has changed and the subclass argument does not work anymore (and if it would, I have still good reasons for the other solution). --Jobu0101 (talk) 16:02, 1 February 2023 (UTC)
I have blocked Special:Contributions/2003:C6:F700:0:0:0:0:0/40 from editing main namespace for 6 months, and left a link to this discussion so that the IP user can participate here. There is topically similar activity from this range for years, and it does not seem to be obvious vandalism to me so a discussion involving all editors seems appropriate.
If we find that these removals should be undone (or the IP editor remains silent), I have a script to revert their actions relatively easily using undo or rollback. —MisterSynergy (talk) 00:04, 2 February 2023 (UTC)
@Elizium23: Sure, I know that and this is actually very good: These mass IP delete edits happened a few times in the past and every time with a different IP but within that IP range. Hence, this range block will force the person to login and I can talk to him if it happens again. --Jobu0101 (talk) 09:34, 4 February 2023 (UTC)
Everything is fixed now. Let us see how long it holds. I guess the IP range blocking could help to extend the period. --Jobu0101 (talk) 00:03, 5 February 2023 (UTC)
Yeah, I keep an eye on the municipalities and I defintely will let you know. But with your range block you catched all recent occurrences of those edits. Hence, if the person wants to do it again I guess he has to login or use a VPN. But hopefully he will try to find out why he is blocked and then read this discussion here. I don't think that it is intentional vandalism. --Jobu0101 (talk) 08:47, 6 February 2023 (UTC)
Given the news that the free Twitter API will soon be shut off it looks like User:BorkedBot's tasks to 1) populate the X user numeric ID (P6552) (And a few related properties) and 2) the social media follower counts on Twitter will stop working. As far as I know nobody is actually relying on this data (though I think it's cool to have). Not doing the former task will cause constraint violations. It's possible I could continue to have it work via scraping but my guess is they will start trying to restrict that given their desire for money. If it's some nominal amount of money ($10/yr) should I just pay it? In preparation I'm rerunning the import of social media follower counts now. BrokenSegue (talk) 15:34, 2 February 2023 (UTC)
I would certainly discourage paying anything -- if the (deeply unreliable) current owner of Twitter wants the promotion of updated data on Wikidata, he can operate (and pay) for it himself. I think letting it die is fine; make sure to update the various relevant pages to mark them as "deprecated because the platform stopped being sensible" or some such. JesseW (talk) 03:27, 3 February 2023 (UTC)
I think it’s neat, too. But you shouldn’t pay for this. Can’t WMF or one of their many subsidiaries pay for API rights? --Emu (talk) 13:09, 5 February 2023 (UTC)
I could file a grant application for it? If any Wikipedia used this data live I would feel more comfortable with that use of money. There's also the ethics of giving Musk money to be considered. BrokenSegue (talk) 19:27, 5 February 2023 (UTC)
There is the ethical questions. I think if Elmo wants to destroy his £44B website by making serial bad decisions, we should help him along by abandoning support for it. Although WMF is richer than Croesus, I don't think it should be subsidising Mr. Tweet. --Tagishsimon (talk) 12:57, 6 February 2023 (UTC)
list of items where subclass trees is clearly broken
In theory wikidata has a structured ontology so you can check what given item represents - is it a specific tree? Group of trees? Taxon? Event? Human? Mathematical term?
Sadly, Wikidata is currently quite unreliable for that purpose. For example, many things that are not events at all - are anyway indirectly classified as events. I was unaware that subclass tree is so borked when I tried using it. In effect I accidentally created detector of invalid subclass tress on Wikidata (while trying to create something else).
en: public–private partnership (government service or private business venture which is funded and operated through a partnership of government and one or more private sector companies) [5]
en: income (consumption and savings opportunity gained by an entity within a specified timeframe) [7]
en: increase (enlargement or increase of an entity; increase in size, number, value, or strength; an amount by which a quantity is increased) [8]
en: occurrence (occurrence of a fact or object in space-time; instantiation of a property in an object) [9] this was unexpected here as it indicates an event !
en: electrical interconnector (power connection between two electricity grids) [10]
en: interconnector (structure enabling energy to flow between networks) [11]
en: assembly (object consisting of multiple parts) [12]
en: merge (entity resulting from the act of combining several entities to form one) [13]
en: occurrence (occurrence of a fact or object in space-time; instantiation of a property in an object) [14] this was unexpected here as it indicates an event !!!!!!
User:Mateusz Konieczny/failing testcases has many such cases, more than I can process. If anyone is interested in fixing such broken classifications then help is welcome. And maybe if that tool exists anyway then maybe such report may be useful to someone?
(I post such cases to this page, I post limited number of cases to Wikidata talk:WikiProject Ontology and no more than once a year I post about this list to Wikidata:Project chat - let me know if that is too much and I should not post about it)
Being simultaneously instance and subclass of another entity seems not ideal, but at least for my use case would not result in outright false data Mateusz Konieczny (talk) 23:25, 2 February 2023 (UTC)
I've now fixed this particular mess (it was the incorrect presence of "occurrence" on "merge"). But your broader point is still very well made. I think the main thing that would help with this is if such errors were highlighted directly in the interface, at the time that the incorrect changes are made, and they required an extra confirmation. That wouldn't address all the existing problems, but it would at least decrease the speed at which new problems are introduced. I don't know how difficult it would be to add that feature. JesseW (talk) 03:34, 3 February 2023 (UTC)
Partial problem is that changing item can affect thousands or millions of items below it in subclass hierarchy - creating thousands or millions of violations at once. No idea how to do handle that live. Mateusz Konieczny (talk) 07:09, 3 February 2023 (UTC)
The warning could come up when toggling any item between being an event and not being an event, and other similar pairs. That wouldn't require checking further down the tree, just alerting editors that they should be sure of what they are doing. JesseW (talk) 15:46, 3 February 2023 (UTC)
Would it help to protect or semi-protect items that are a superclass of >1000 items? We really need stability, and for discussion to occur before making changes to ontology of well used items. At the moment a single editor can change these things on a whim which has a massive impact on many other items. — Martin (MSGJ · talk) 11:52, 5 February 2023 (UTC)
Re-breaking items is a part of problem and a bit irritating but relatively small - and even if it affects many items then unbreaking requires a single change Mateusz Konieczny (talk) 14:10, 6 February 2023 (UTC)
Help needed to create language codes
I managed to find a way to create a regional fr-CA Wikimedia Code, so that I could state as a value for language of work or name (P407) qualifiers. However it's not working. I cannot use it for that purpose and I cannot use it in descriptions and labels either (which would be useful for concepts that are more commonly known by a different name in Canada than in France).
I also have a need to describe works in Wəlastəkwey (colonially known as Malecite-Passamaquoddy and described in Wikidata under Malecite-Passamaquoddy (Q3183144)), an Indigenous language that is said to be "severally endangered" but is undergoing a revival thanks notably to artists such as Jeremy Dutcher (Q55092446) and Dave Jenniss (Q60835290). The language code in ISO 693-3 is pqm.
@ChristianKl Thanks for your help. I opened a first ticket for the Wolastoqey language: T328890. I won't open a ticket for Canadian French (fr-CA) just yet. I will first ramp up my use case. Fjjulien (talk) 04:09, 6 February 2023 (UTC)
Hi @BrightSunMan, These could not be merged because they both have articles in at least Danish and Russian. If articles is some of the languages belong to a wrong item, you can move them to where they must belong. Michgrig (talk) 11:52, 6 February 2023 (UTC)
Change English labels from “scope” to “usage” (or similar) in constraint lingo
I am fine with the re-wording if it helps clarify things. Maybe for me, 'scope' is not a problem, but neither is 'usage', so I have no objection. Josh Baumgartner (talk) 06:45, 1 February 2023 (UTC)
Agreed with "entity types this property is allowed on". Neither "property scope" or "property usage" explain what the property is intended to be used for. Dhx1 (talk) 04:15, 3 February 2023 (UTC)
FWIW: in projects like English Wiktionary "usage" can mean a description of actual practice, not allowed or permitted or recommend, just "here's what people are actually doing", even if it's considered bad form. OR "usage" can mean recommended practice, best practice. I'm not sure whether this information helps, but "usage" does have two very different meanings in English. --EncycloPetey (talk) 04:49, 3 February 2023 (UTC)
best practice for the representation of quantitative data and their metadata
I would appreciate some help in figuring out how to best represent quantitative data records on WikiData taxon pages. I mean things like average body mass or minimum/maximum body length for organisms with a particular sex & life stage. We have looked around for examples on WikiData taxon pages but couldn't find anything that had the metadata we're looking for. After looking around and trying different things, we've created a preliminary example of a body length data record using sex or gender for sex, biological phase for life stage, and property constraint for the statistical method. However, we're getting a property scope constraint warning for the biological phase metadata record and a one-of constraint warning for the statistical method metadata. So this is clearly not the way to do it. Can somebody please advise on how to properly represent these metadata using WikiData properties?
@Sylverfysh: I believe you are doing something "new" on wikidata so it's not surprising that things you are doing violate existing constraints. that doesn't mean they are wrong though. the constraints can be changed. I would suggest you put together a proposal of how you want to model this information (which you seem to have decided on) and then ask for comment from a relevant wikiproject. Most probably you'll get little pushback and you'll have checked the "sought guidance" checbox and can go ahead. The only question I can see people raising with hot you're doing this is whether you should create new properties to represent this information. Are you planning on linking this information to Wikipedia? That might decide how best to represent it. BrokenSegue (talk) 04:23, 4 February 2023 (UTC)
Thanks @BrokenSegue. I was actually hoping we weren't trying to do something new and just hadn't found the right parallel use case yet. I'll follow your advice and take this to the Wikidata:WikiProject Biodiversity project for discussion. We definitely want to create data records that are suitable for linking to Wikipedia, but I'm not sure we'll do the linking ourselves. We'll have to discuss that with relevant projects, too. Sylverfysh (talk) 18:51, 4 February 2023 (UTC)
Hello. Could someone please run a bot over Wikidata and replace kategorija Wikimedije -> kategorija Wikimedie in item descriptions for Slovenian (sl)? This is the correct declension (the same as e.g. oboa>oboe, Gaia>Gaie). This would be much appreciated. TadejM (talk) 20:03, 6 February 2023 (UTC)
Wikidata weekly summary #558
Here's your quick overview of what has been happening around Wikidata over the last week.
Discussions
New requests for permissions/Bot:
BiodiversityBot 3 Task/s: TreatmentBank (Q54857867) is a CC0 resource that contains data on taxonomic treatments, treatment citations, figures, tables, material citations and bibliographic reference. It contains valuables links mapping scholarly articles, taxa and taxonomic treatments. This bot task involves linking research papers on taxa to taxa and related taxonomic treatments.
Closed request for permissions/Bot:
Bean49Bot 4 Task/s: Add Springer Nature person ID and Springer Nature article ID by moving from exact match property.
Next Linked Data for Libraries LD4 Wikidata Affinity Group call February 7, 2023: We thought we'd try something different next week, in honor of Valentine's Day month: What's Your Wikidata Passion? What is your central Wikidata interest right now? It can be a work or personal project or just what you like to edit when you have time. We'd love to have an open mic session, completely informal. Please add yourselves to the list on our agenda here if you would like to talk for 5 minutes or so and share your screen, with no need for formal slides. Or just show up and talk on the spur of the moment. This will be a community session where we welcome all to participate! Agenda
Let's Quiz is a game that generates random quizzes to test your knowledge & learn something new every day.
User:Nikki/AddTermboxLanguage.js - makes it easier to add/edit labels to an item in a language other than the ones shown by default.
Other Noteworthy Stuff
Building cool apps and services on top of Wikidata's data but running into ontology issues? We'd love to hear from you in this survey to make things better for you.
General datatypes: Happy Planet Index score (The Happy Planet Index (HPI) is an index of human well-being and environmental impact that was introduced by the New Economics Foundation in 2006), credits URL (URL of an official webpage with a list of credits and roles attributed to various people, organizations or applications that contribute(d) to this item's existence), digital equivalent of (the subject is the digital equivalent of what?)
General datatypes: precedes/follows various things (this lexeme form appears only when preceding another lexeme form with this phonological feature), footnote (for use in the references section of statements: to state which footnote of the source material supports the claim in question), agent of action (thing that does the action), natural enemy (One of the causes of death of this living creatures referred to in this item, which is eaten by that creature), change of (property this process changes), object of action (thing an action is done to), variety of sense (dialect, variety or register of language that the sense applies to), bust/waist/hip measurements (chest measurement; aliases: bust measurement), usage label (list of sets of context label property (Q116547761) (language style (P6191), field of usage (P9488), has quality (P1552), variety of form (P7481), location of sense usage (P6084)). Other individual context label property (Q116547761) statement will be treated as and with this statement.), thesaurus' properties (primary topic of the subject Wikimedia thesaurus)
REST API: adding a new GET /entities/items/{item_id}/descriptions endpoint (phab:T327881)
Lua: added two Lua functions, getDescriptionByLang (phab:T230839) and getBadges (phab:T305378) that make it easier to get this data on Wikipedia and co
Action API: fixed a bug that prevented the wblistentityusage API module from being used as a generator (phab:T254334)
Dates: working together with Matěj Suchánek to fix date parsing issues in Czech (phab:T221097)
Constraints: working on showing constraint clarification messages to make it easier to understand why a constraint violation is happening and how to fix it (phab:T219037)
In the English Wikipedia it was a disambiguation page until 2015. Please correct me, but i think this object was quite wrong from the beginning. --Alex42 (talk) 15:57, 7 February 2023 (UTC)
Cambiar el temaño de un escudo en ficha persona wikipedia
Buenas tardes querida comunidad, soy nueva en esto de aprender a crear artículos en wikipedia y me gustaría saber cómo se le puede cambiar el tamaño de un escudo a una "ficha de persona" en modo código. ya que he buscado en internet y no me aparece nada al respecto.
Este es el campo: | escudo = EjemploLogos.jpg y se visualiza muy pequeño en la ficha me gustaría que se viera más grande.
I've been developing a new website application to display Wikidata, tailored to two of my hobbies, fortifications and science fiction, and its written in a way to allow others to develop special interest websites. Its nearly ready to launch. Is there a good place to discuss best practice and promotion with other application developers? Vicarage (talk) 08:32, 6 February 2023 (UTC)
They all sound notable to me. I'd expect any individual map pre 1900 to be notable, and any map series before and afterwards, if done by a country mapping agency or major publisher. I'd wonder about the structural need for individual maps in a series just to record the area covered, but even then a rolling update campaign could mean dates are best stored that way. Vicarage (talk) 22:51, 6 February 2023 (UTC)
generally the links should be retained if a good number of them are archived. unfortunately it looks like web.archive.org has bad coverage of these URLs. A real shame. Fortunately it seems that the data is being released and archived "All metadata will remain accessible via SpringerNature OA & Meta API and downloadable at Figshare SN SciGraph research repository.". So I think we should keep them for posterity. BrokenSegue (talk) 20:45, 8 February 2023 (UTC)
True item size limits?
What are the true item size limits? Making a naive call via the API says the limit is 2.93 MB or 3,072,000 bytes. However, I have been able to get up to 3,270,000 bytes on both the Wikidata Sandbox and on the Test Wiki. However, I have seen as much as 3,546,336 bytes on COVID-19 pandemic in Brazil (Q86597695) and my bot has gotten as high as 3,648,688 bytes on gatsby-cli (Q95972606). Either this is a bug by Wikidata to enforce the strict 2.93 MB item size limit or the true limit is undocumented. RPI2026F1 (talk) 01:53, 6 February 2023 (UTC)
I don't know the answer to this question but we should not be doing anything that puts us close to this limit. wikidata becomes nonfunctional before this point. BrokenSegue (talk) 02:38, 6 February 2023 (UTC)
The problem is that I'm trying to copy version data from NPM and the bot ran into a package with well over a thousand versions. It's' further complicated by the fact that the bot adds 5 qualifiers and 2 reference groups with a total of 5 references to each version that's added, meaning that a single version leads to about ~4KB of data. The only thing I can possibly think of is to exclude alpha/beta versions from the final version list but there are packages with a crazy number of stable versions, such as nightly builds. The other alternative is to drop all qualifiers and simplify references down to the bare minimum, but that would require any consumers to have to lookup data on the registry anyways which makes the entire goal of importing data from the registry moot. Unfortunately this starts to approach the realm of "big data", which is absolutely not what Wikidata is built for. Hypothetically we could build items for each version but considering that there are at least 10 thousand packages on NPM with over 100 versions each this becomes very costly (1 million new items which is 1% of Wikidata), not to mention in the case of a thousand versions we are still going to run into the limit eventually if we have the parent item link to the version items. RPI2026F1 (talk) 03:53, 6 February 2023 (UTC)
yeah I think unfortunately the answer is "you can't do this with wikidata". It's not likely very useful if a package has thousands of versions. can we import only stable versions? or major versions? some people sometimes suggest only keeping the most recent value around. it really depends what the "use case" is which is often undefined on wikidata. BrokenSegue (talk) 04:10, 6 February 2023 (UTC)
The main issue I've ran into so far is that too many packages have nonstandard version schemes. First of all, a lot of apps use "calendar versioning" and it's impossible for a bot to know which of those are major updates or not. Another issue is that there are multiple "latest versions" (such as latest stable release, latest beta release, etc.). Some packages also have support for multiple major versions, further complicating things (Postgresql is a good example). A third issue I've run into is that packages are released on different platforms at different times, and there's still no elegant solution to display that data yet. A last resort would be to add only the most recent 10 versions, but then it's not a complete record and could be misleading. RPI2026F1 (talk) 13:27, 6 February 2023 (UTC)
I'd be very wary of being completist here. Even if WD can store the data, can the web interface still usefully show the item to humans, and can SPARQL return sensible levels of data without timing out. WD isn't really designed for large volumes of tabular data. It might be more work to define a subset policy for versions, but it will pay off long term. Vicarage (talk) 07:37, 6 February 2023 (UTC)
Perhaps a point here is that wikidata should be designed such that we do not have to be parsimonious. WMDE have been asked many times to address UI and tabular data issues, but they choose not to. --Tagishsimon (talk) 13:34, 6 February 2023 (UTC)
I have done some testing on test Wikidata and it's a type to a property that can be used to link to a Data file on Commons. Unofrtunately this does not make the tabular data queryable so there's no easy way to work with data from multiple items, and it requires a new property to be made. Unofrtunately this won't work well for storing time series data of existing properties. RPI2026F1 (talk) 17:05, 8 February 2023 (UTC)
Why not do both? Full version data as tabular data will work fine if you only want to query one package. But like you mentioned initially, to be able to query many packages you will probably have to limit the amount of versions that are stored somehow. This could be complicated as every software does versioning differently. I would suggest to count the amount of versions from the NPM DB and only if it exceeds a certain threshold apply a manual filter to it, for instance storing only major and minor version, but not the bugfix release number. Infrastruktur (talk) 19:45, 8 February 2023 (UTC)
This does seem like a good idea, where I can select the latest stable and non-stable version. Now the question is how I'd link that data file back to the item and if I need to apply for a botflag on Commons. RPI2026F1 (talk) 22:06, 8 February 2023 (UTC)
I've seen the 2.93 MB complaint before, but history and other UI services show sizes up to about 4 MB - see for example Special:LongPages, which claims the largest one is 4,413,904 bytes. I suspect the issue might be slightly different file formats. The way we store reference data in Wikidata in particular I think is very size-inefficient. If the same reference is used thousands of times on a page it could potentially be stored very efficiently once with small cross-reference entries, but I don't think we're doing that. Maybe we should focus some thought on better ways to handle large items? There are a number of high-energy-physics papers I can no longer update because they've hit the size limit and anything I try to do adds to it (in particular I was trying to restore a missing author to one the other day - no luck). ArthurPSmith (talk) 19:31, 6 February 2023 (UTC)
Deduplicating references and qualifiers would be a good start. However I feel like this is only going to make it harder for the backend to present the data since it has to do a bunch of subqueries to resolve everything. RPI2026F1 (talk) 21:08, 6 February 2023 (UTC)
If the item pages get too large, they will be sluggish in the webbrowser. Is there any reason the data-series can't be stored as tabular data on Commons? Infrastruktur (talk) 22:15, 6 February 2023 (UTC)
I'm not really sure how to store data on Commons as of yet. Furthermore the data I'm importing is already available in its entirely at a different place, so the only advantage to adding it to Wikidata is being able to use the Query Service on it. RPI2026F1 (talk) 23:30, 6 February 2023 (UTC)
editing not accepted
Hi!
I edited a text regarding an NGO but I was told my update has not been validated. How can I ensure that this does not happen?
I also have a problem including media links to support the new updates. Any assistance?
Thank you Pretor2ada (talk) 15:19, 7 February 2023 (UTC)
I updated the text with the latest information and names of the board members, new bay members and removed those which are no longer part of the Association. I also included a charter that was adopted lately. All of this was not accepted. Since it's my first contribution, I probably didn't respect the guidelines. Pretor2ada (talk) 16:05, 7 February 2023 (UTC)
My mistake, the problem occur on the french version of "Club des plus belles baies du monde"
I did some editing yesterday but it was rejected. I managed this morning to update the board members. You'll see in the history all the changes I tried to introduced. I also have some links to media articles and to a UN conference but I hope you can assist me in including as credible "sources".
Wikidata is not text focused. If you want to know why a text in the change of one of the Wikipedia's that have articles for an item isn't accepted you have to ask at the actual Wikipedia instead of here.
First, the item claims to be an instance of a heavy machine gun, not a subclass of a heavy machine gun. Second, it's possible to set the constraint relation to ' instance or subclass of'. So fixing either or both of those solves the problem. I've implemented both. --Tagishsimon (talk) 19:32, 9 February 2023 (UTC)
Is there any way to query this error status? (Does it appear in the data model?) Is it thus possible to query and generate a list of any affected items? Andy Dingley (talk) 21:10, 9 February 2023 (UTC)
Hola, tengo un proyecto de la escuela en donde debo crear un articulo de una biografia de artista o personaje publico, me gustaria contar con su apoyo por favor ya que ha sido muy dificil para mi debido a que no puedo entender el proceso 2806:10B7:3:9E2A:DCF9:1EF7:17C9:F4C16:13, 9 February 2023 (UTC)
Como puedes ver, el enlace ese no tiene nada qua hacer con el cantante y compositor: es un elemento de Wikidata por un ciclista.
Aquí en Wikidata no hay articulos: es una base de datos. Es posible representar ciertos datos sobre un suyecto (fecha de nacimiento, nacionalidad, et cetera), pero no es posible contstruier un una verdadera biografia. ¿Quizás buscas la Wikipedia en español? - Jmabel (talk) 05:08, 10 February 2023 (UTC)
Modeling that someone was Mayor of Everett, Washington
@Jmabel: I added Mayor of Everett, Washington (Q109302642) with no problem. I've noticed that sometime there is a lag that prevents items from appearing in the property: I think it's more often on the Wikidata end, but I have rather slow internet connection so who knows. Refreshing the page or coming back after a few minutes usually solves the problem. -Animalparty (talk) 05:02, 10 February 2023 (UTC)
A workaround when the main UI is found to be wonky, is to use a simple QuickStatements batch - Q886900 tab P39 tab Q109302642. --Tagishsimon (talk) 10:33, 10 February 2023 (UTC)
HowTo reference screenshots in different languages?
Do you know of wikidata uses, where screenshots in different languages are referenced to the appropriate language only or how to do that? EoNy (talk) 11:21, 10 February 2023 (UTC)
Haven't seen such technology in any template, even though it is not difficult to implement on Lua (and as for modeling, there are no problems). However almost all templates in Wikipedia editions still have an ability to redefine value from Wikidata. --Lockal (talk) 17:35, 11 February 2023 (UTC)
I noticed the bot that creates constraints reports gave up in cases where it found an allowed-entity-types constraint (Q52004125) with a constraint scope (P4680) qualifier on it, with an error message like: ERROR: Error while Q52004125 constraint parameters loading: Constraint Entity types does not accept qualifier P4680. This results in no constraint report being generated (!). See https://w.wiki/6K57 for a list of occurrences.
@Infrastruktur: What value does the robot try to set for constraint scope (P4680)? I tried adding constraint checked on main value (Q46466787) to Dehkhoda ID (P11328) manually but the web interface didn't even allow me to publish that edit (probably because that qualifier value was already present on the statement; it has been since the property was created on December 20), while adding constraint checked on qualifiers (Q46466783) on the same statement worked fine. Maybe the robot doesn't check whether the scope value is already in place, receives an error response similar to mine, misinterprets it, and skips trying to add the remaining checks or something? Disclaimer: I have no robot experience myself. --SM5POR (talk) 20:59, 8 February 2023 (UTC)
It's a limitation of the bot. The bot owner has been aware of the issue for years but is not willing to fix it. - Nikki (talk) 00:07, 13 February 2023 (UTC)
is there a standard way wikidata stores info about how the national flag of a specific country changed over time? i can think of three most basic info: design of the flag, start date, end date. like the usa flag, how it changed by adding stars over the years, how each version came into force, etc. RZuo (talk) 19:03, 10 February 2023 (UTC)
one related issue that I've never seen addressed is that commons images can be updated but wikidata assumes things are static. so like if we set the flag for a country to image A and then the flag changes and image A is updated what we would want to do is have wikidata also point at the old version of image A. But as far as I can tell there is no way to do this? Does commons have a policy about when uploading new versions is ok versus uploading a whole new image? BrokenSegue (talk) 20:42, 10 February 2023 (UTC)
i think it's essential to document how certain graphic concepts (flags, logos, coats of arms...) changed over time.
with that info recorded systematically, it's possible to, given a specific time, deduce the image of the graphic concept at that time. for example, "flag of canada on 1904-02-29" = File:...svg . "logo of nintendo on 1200-11-11" = invalid/non existent (because nintendo as well as its logo first came into existence after 18xx).--RZuo (talk) 15:52, 12 February 2023 (UTC)
Tried to do it myself, but there are multiple conflicts preventing an automatic merge. The automatic method really needs to be easier to use… - dcljr (talk) 00:53, 13 February 2023 (UTC)
There should be two items here, one for Shixia Culture (the subject of the DE article) and one for the Shixia site, a specific human settlement excavated as an archaeologial site (the subject of the ZH article). --Tagishsimon (talk) 15:19, 9 February 2023 (UTC)
[Significant change] Heads-up: Upcoming fixes for date parsing
Hello!
We will soon deploy some fixes for date parsing that especially affect Czech and possibly other languages as well.
Wikidata’s parsing of dates in the Czech language has long been affected by some issues (T221097), where some reasonable representations couldn’t be parsed (e.g. 01.02.2023), while others were parsed incorrectly: for example, 11.12.2023 (11 December 2023) was parsed as 12 November 2023, and 07.05.1997 (7 May 1997) bizarrely became 30 June 1997.
Matěj Suchánek has investigated these errors and implemented a solution, which will be deployed on February 15. As far as we can tell, all the changes it produces are positive: that is, if the way a date is parsed changes, then the old behavior was bad, and the change is an improvement. Nevertheless, it’s possible that some users expected the old behavior, or that some external programs might even be broken by the change. Users who add time data to Wikidata should make sure that the date shown to them as a result of their edit is correct. If you want to test the behavior changes, the new code is already live on Beta Wikidata.
We are currently looking into other languages that may be affected as well.
If you have any questions or want to provide feedback please leave us a comment on this ticket.
@Matěj Suchánek You're right. I thought it was also addressing this issue. Too bad!
@Nikki Thanks. Done! (But I still don't understand why such basic improvements (in terms of UX, not dev complexity) are not addressed by WD development team...) Ayack (talk) 08:24, 13 February 2023 (UTC)
Coordinates of streets
What are the best practices of adding coordinates to streets? What I usually do is just to add Property:P625 and take an arbitrary point. It would be much better if instead I would add the northernmost and the southernmost points (assuming the street is approximately oriented south-north) using qualifiers such as the northernmost point, however, this violates the constraint that in this case also eastern-, western-, and southernmost points should be all added. But most streets only have two ends, not four. Ymblanter (talk) 21:03, 11 February 2023 (UTC)
None of the ends on a road like this are most northern or souther Northernmost and southernmost point should only be used for the ends if that is also true. While they may be for many straight streets, for curved ones they might not be. Ainali (talk) 21:11, 11 February 2023 (UTC)
Sure, for this one I would use westernmost and easternmost points (we would come into problems with for example a straight line running at 45 degrees, or a line running east and then north, but lest us solve simple things first). Do we have something which would just denote an end of a curve? Would also be relevant for rivers for example. Ymblanter (talk) 21:16, 11 February 2023 (UTC)
For rivers there is applies to part (P518)=river source (Q7376362)/river mouth (Q1233637). The problem with streets it that not just that they are sometimes curvy, streets are often bifurcated and contain discontinuities. Even OSM was not able to solve this problem (I mean, there are no "links to street", streets are represented there as multiple separate segments, each one has its own identifier). Lockal (talk) 08:06, 12 February 2023 (UTC)
Not sure how to model or if we want to model more advanced usage. Maybe better to make a relation in OpenStreetMap and link to it? Or make a GeoShape file and use geoshape (P3896) to link to it? Multichill (talk) 12:20, 12 February 2023 (UTC)
If a proposal gets more discussion than here yes, but my instinct is that we already have the properties, and its matter of just using them correctly Vicarage (talk) 12:26, 13 February 2023 (UTC)
How should we represent external identifiers where there is both a permanent ID and a human-friendly ID?
Many websites have two IDs to represent an entity: what I call a permanent ID and a human-friendly ID. The classic example is Twitter. Each Twitter account has a permanent ID (represented by X user numeric ID (P6552)) e.g. 57320656 and a human-friendly ID (represented by X username (P2002)) e.g. @wikidata.
Both these values are important to us. The permanent ID is useful because even if the human-friendly ID changes, it's still possible to reference the entity and obtain the new ID. The human-friendly IDs, on the other hand, are easier to add (and sometimes for deleted accounts it's not possible to find the permanent ID). As such, the convention so far is to have two separate properties for these two kinds of ID for each service. Some examples:
We can see that some of the human-friendly IDs are usernames and some are the slugs from the URL. Usernames can be changed by the user, and slugs can change if the entity is renamed on the external website.
Some permanent IDs are numeric, but some also contain letters and symbols. The actual format is not relevant here.
The current approach raises some issues, however:
Each entity type on each service needs two properties, and they both need to go through the property proposal process. There are many properties in existence where we only capture the human-friendly ID. Currently, Facebook has Facebook username (P2013), intended for human-friendly IDs, which is why a property for the permanent ID is being proposed. Similarly, Patreon has only has Patreon ID (P4175) for the human-friendly ID, which is why I have proposed a property for the permanent ID. There's also no version of Internet Game Database franchise ID (P11573) for the permanent ID, so I might have to propose a new property for that. Is this really the best way of doing this? There's always the risk that a property does not get created and therefore we can't record the permanent ID, which is a shame.
You get some odd situations where, for example, the two YouTube properties are allowed to be top-level properties. Sometimes the human-friendly ID is a qualifier of the permanent ID, sometimes the permanent ID is a qualifier of the human-friendly ID, sometimes they're both top-level properties and you can't associate the two.
So, there are a few options I can think of:
Option 1
No change. Continue requiring two properties for each entity type on each service.
Note that this last option does pose a problem where the Twitter user has changed their username, since we can't then add qualifiers to state the dates between which the username was valid.
There are probably other potential solutions than these. What does everyone think?
The most important consideration to me is making sure it's easy for new users to add information. This means the human readable identifier has to be a property that you can just add without thinking. The next important consideration is that the permanent identifier needs to also be encoded on Wikipedia. This should probably be a qualifier on the first. Should it be a generic property or something like "URL for permanent ID"? Well the main issue with that is that we use X user numeric ID (P6552) as a qualifier on social media followers (P8687) statements. I don't think that use case would be well captured by a generic property. So at least for Twitter I say we stick with option 1. If some new identifier doesn't have that constraint? Then sure make a new property (though it's possible we would have a fixed identifier that doesn't have a corresponding URL which this wouldn't work for). BrokenSegue (talk) 07:07, 8 February 2023 (UTC)
Thanks for moving the discussion here. I can't see 'URL for permanent ID' being repeated vast numbers of times across WD, but the format could be a property of the Twitter entry itself, so a query could extract it once and apply it multiple times. Vicarage (talk) 08:15, 8 February 2023 (UTC)
A 'solution' that requires the URL formatter to be repeated on each property statement would be an insane way to go. If WD needs two properties to cater for a link to someplace, WD should be capable of accommodating property proposals which lead to the formation of both as a single proposition. --Tagishsimon (talk) 08:57, 8 February 2023 (UTC)
I think it would be great if the "permanent ID" property I suggested could be hyperlinked based on the parent property. Is this possible?
I feel it's important to have a hyperlink so that people can easily access the entity on the external website via its 'permalink'.
By the way, the reason why I suggested a brand new property (instead of P2699) for the URL is that it should clearly relate to the "permanent ID" qualifier, rather than the main statement.
The property proposal process probably can accomodate two properties at the same time, but the need for two properties isn't always apparent at first. Someone creates a Twitter username property to start with, and it's only later that someone realises we should probably have one for the numeric ID. Which leads us to this very discussion. Yirba (talk) 10:44, 8 February 2023 (UTC)
There was no support for a generic numeric ID property.
In the long term, a new datatype could solve this.
The question remains of what we do in the short term. Can we build a consensus of using two properties (human-readable username and persistent ID) for the time being? Yirba (talk) 09:45, 13 February 2023 (UTC)
I think we have to use two properties because regex validation of both is per-site, and URL formatter of both is per-site. (And as Tagishsimon says, capturing full URLs is insanity.)
I also think both should be top-level since it happens that you know only one of them, so you can't add it if it's declared as qualifier of the other one. Vladimir Alexiev (talk) 19:08, 13 February 2023 (UTC)
Thanks for your thoughts on this. I get your point, however I think it makes most sense to have one property as a qualifier for two reasons:
It's important to be able to relate the username to the numeric ID. What happens if someone has two Twitter accounts? They would have two usernames and two numeric IDs. The only way to know which matches which is for one property to be a qualifier of the other.
For data access it makes things a bit more complicated to have two top-level statements. Currently, both YouTube channel ID (P2397) and YouTube handle (P11245) are allowed to be top-level statements. This means if I want to retrieve someone's YouTube channel, I need to look for both properties, which might actually be duplicates.
So I think it's better to have the human-readable username (e.g. X username (P2002)) as the main statement and the persistent ID (e.g. X user numeric ID (P6552)) as the qualifier.
What happens if you know the persistent ID but not the username? You can always set the username to unknown value and then set the persistent ID as the qualifier to that. Yirba (talk) 21:11, 13 February 2023 (UTC)
mwapi full-text search seems to miss results
If I execute this query (very similar to the first full-text search example query) for "leder", I get 50 results. None of them includes the term "lederfabik" (e.g., Aachener Lederfabrik (Q107072166). This is strange, because the example search query for "cheese" also returns The Cheesecake Factory (Q1045842). My best guess is that some pagination limits the number of results returned, and no "lederfabik" item occurs within the first 50 results. The API doc however reads differently to me, and attempts with different combinations of wikibase:limit and wikibase:limitContinuations did not bring up the "lederfabrik" items. Have I misunderstood something, or is there a known way to get the complete results? --Jneubert (talk) 17:18, 10 February 2023 (UTC)
Thank you, @Lockal: for hinting to the prior discussion and for your solution. Some superfluous results are not a problem. My aim is to search a small subset of items (< 10,000) for an arbitrary string. So I tried to restrict the mwapi search to this subset. However, I am not sure if my adapted query works correctly: First, the execution time is still higher than expected (10-12 sec, while the subset-building part of the query takes only 3 sec). Second, I get a different number of results (31, 34, 37, 33) with each execution of the query (with formal changes to avoid cache). --Jneubert (talk) 15:54, 13 February 2023 (UTC) (fixed query URL)
Wikidata weekly summary #559
Here's your quick overview of what has been happening around Wikidata over the last week.
Discussions
New requests for permissions/Bot:
CJMbot (CJMbot lets users upload a CSV file in a certain format. The data inside this file is then validated and processed. New items wil be created based on the data in the CSV file and existing items wil updated by adding statements and references).
RPI2026F1Bot 5 Task/s: Import dependency and version data from PyPi
Next Linked Data for Libraries LD4 Wikibase Working Hour February 13, 2023. The February Working Hour will feature a presentation by Steve Baskauf on using VanderBot with Wikibase: The Wikibase API provides a mechanism for programmatic control of uploads, and its behavior is consistent across instances (Wikidata, Structured Data in Commons, and those that are established privately). In this session, Steve will discuss basic interactions with the API and demonstrate using the VanderBot Python application to rapidly upload tabular data to a wikibase.cloud instance. After performing a mass deletion, Steve will conclude by describing how he's used the Wikibase API to facilitate addition of structured data to Commons. Registration link
Wikidata Graph Builder released a major update, introducing new layouts and visualization ideas. You can read the full changelog here.
The new Service Level Objective for the Wikidata Query Service has been implemented: the current aim is to maintain a 95% uptime based on a 90 day rolling window. You can read the full announcement here.
a.gup.pe provides group features for Mastodon. @wikidata@a.gup.pe is a group about Wikidata in general. @querywikidata@a.gup.pe is a group about Wikidata queries. Anyone can join those groups simply by following them in Mastodon. Anyone can share a message with all members of those groups by mentioning them in a publication in Mastodon or any other application of the Fediverse.
The hashtag #Wikidata can be used to tag all publications related to Wikidata in Mastodon. Anyone can find recent publications using this tag using the search feature: https://wikis.world/tags/Wikidata.
Went over the feedback on the first release and deciding on the next routes to add
Added a new endpoint for getting descriptions (phab:T327881)
Worked on throwing exceptions when something goes wrong (validation failed, Item not found, etc.) instead of returning an error response object (phab:T327527)
Entity Schemas: Finished the technical exploration that will unblock the next steps for actual development
Query Service: Changed URLs with URL-encoded characters to be shown un-encoded for better line-breaks and readability (phab:T327514)
Query Builder:
Adding support for a few additional datatypes (phab:T328528)
Adding a basic language selector to make it easier to switch the language of the page (phab:T328764)
Constraint checks: Working on showing constraint clarification messages to make it easier to understand how to fix a violation on a statement (phab:T219037)
Search: Exploring design options for how to make it easier to search for entities other than Items (phab:T327507)
After 3097 voters from 146 Wikimedia communities voted, the results are 76% in support of the Enforcement Guidelines, and 24% in opposition. Statistics for the vote are available. A more detailed summary of comments submitted during the vote will be published soon.
From here, the results and comments collected during this vote will be submitted to the Board of Trustees for their review. The current expectation is that the Board of Trustees review process will complete in March 2023. We will update you when their review process is completed.
A French user has registered Dunkirk as a commune of the department Nord - which is correct, technically speaking, but then the person went on to register the "inception" of Dunkirk as being the date I wrote in the header here, and the fun part is then that this gets reported in "my" wikipedia as the "founding" of the city, which is ...rather out of actual date. So, what do we do ? In my view, inception doesn't work at all here, as the field can't be associated with the city itself, making it too young, but rather associated with the legal status of the city within the French Republic. But how do we do that ? I am primarily a Wikipedian, and I am certainly not a database expert. So, anyone ? Autokefal Dialytiker (talk) 21:29, 13 February 2023 (UTC)
Ah ok, I thought it was a different tool. I'm still in need of something that really rearrange values in a semi automatical way (that is : no need to tick one by one) Bouzinac💬●✒️●💛20:12, 8 February 2023 (UTC)
And the gadget seems not working : I change some values in a chronological way, save, it says "successful" but when you reload the page, weird order still appears. Bouzinac💬●✒️●💛06:07, 14 February 2023 (UTC)
Automation of replaces= and replaced_by in a sequence
Automation of replaces= and replaced_by in a sequence. See Talk:Q99627141, is there any way to automate the process? The manual work is tedious and prone to error by cutting and pasting by hand. Once I have added the ordinals, the rest should be automated. Can it become part of the PositionHolderHistory|id= automation? RAN (talk) 03:24, 15 February 2023 (UTC)
Generally, it seems like a quickstatements task. PHH provides the SPARQL which generates the table and so all of the information in the table can be munged via CSV download in a spreadsheet to produce the QS required. --Tagishsimon (talk) 09:48, 15 February 2023 (UTC)
It opens a wiki pop-up (not a browser pop-up), so newly created or changed articles, which are not yet connected to a wikidata object can be connected to an object.
It is the romanization of his Japanese name. transliteration or transcription (P2440) and its subproperties can be used for all transliterations/romanizations. In this instance, a specific transliteration property Revised Hepburn romanization (P2125) exists, therefore the statement can be set as something like
it's not uncommon for people to have names in languages that are neither their native languages nor official languages of these people's countries. for example, many sinologists have a chinese name: https://home.uni-leipzig.de/clartp/ChineseNamesWesternScholars.html .
i think it's important to record references for these names, rather than simply entering "aliases" without anything to back them up. but wikidata doesnt have a way to include references for the "aliases".
nickname (P1449) doesnt solve the problem. most of these are not nicknames. i think the most appropriate phrase to describe them is "alternative names", aka "aliases" in wikidata terminology. RZuo (talk) 13:44, 15 February 2023 (UTC)
name (P2561) can be used if none of the existing name properties suffice. Otherwise you could make a proposal for a new property. If you make a new proposal it would be worthwhile to research first how librarians call these kind of names. ChristianKl ❪✉❫ 01:12, 18 February 2023 (UTC)
@PhotographyEdits: Before you merged them, one item was for a disambiguation page, and the other was for an insurance business. The two items should not have been merged. I will now revert the merge. It is the case that the disambiguation item has a sitelink on it pointing to an article about the insurance company. That sitelink should be moved from one item to the other. --Tagishsimon (talk) 20:47, 17 February 2023 (UTC)
Bonnie-and-Clyde cases for physical places
I have created two items to enable external matching where the external site (OSM in this case, but the matter is generic) has one item but we have two:
and, for now, made each an instance of amenity (Q867393). That does not feel right, but neither does suggesting (for example) that there are three railway stations, where only two exist. How should these items be modelled? Should they have coordinates, and other geographic properties? Do we have, or need, an item to represent such cases, internally? Do we have model item for such cases, or other examples? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:01, 15 February 2023 (UTC)
I'd be inclined to find or create items which represent what the item is; for Santander, "adjoined railway stations", or somesuch, with those definitional items having parts of the class pointing to their components - railway station, and subclass of e.g. group of structures or buildings (Q18247357). I would include P131 / P625 for the items. I think we have quite a few sets of parent/children items of this sort, notably <<church+churchyard, church, churchyard>>; and <<set of listed buildings under a single ID, each component building individually>> arising out of the way in which WD has imported Historic Environment Scotland listing data. --Tagishsimon (talk) 12:16, 15 February 2023 (UTC)
For me the key question here is notability. What's the case for those items being notable according to our categories? ChristianKl ❪✉❫ 14:54, 18 February 2023 (UTC)
It seems that in dewiki there is no special surname page type similar to English "surname" template or in other languages. Surname lists in dewiki are classified as "Begriffsklärungsseite " ; see eg. w:de:Olschanski. Therefore when a German surname list is crated first, it is classifiead as "disambiguation page" in wikidata and considerably screws up classification of subsequent addition of other wikis with the same surname list, because wikidata specifically demands that "family name" entries are distinct from "disambiguation pagees. What is the recommended course of action? Surely I would want to see lists of the same surname in all wikipedias under the same wikidata entry. Lokys dar Vienas (talk) 00:13, 18 February 2023 (UTC)
It seems that it is you who does not undersstand the situation. In most wikipedians the pages simular to the ones tagged with en:template:surname contain both description of the surnmme and the list of peoplee with the surrname. Sometimes there is nothing to say about the surname itself (or wikipedians are lazy) and it "says nothing aboyut family name itself". dewiki does not have such template. Surnames (with description aand name list) are in category de:Kategorie:Familienname (see eg de:Açıkgöz) and if nothing is written about surnamme then it is tagged by {Begriffsklärung} template. This produces discrepancy in interwikilinks. Lokys dar Vienas (talk) 19:39, 19 February 2023 (UTC)
I've been developing Expounder, a mediawiki system that displays Wikidata and Wikimedia Commons in hopefully a clear and easily filtered manner. It is particularly strong on buildings, as I set it up to act as a gazetteer for fortifications aimed at enthusiasts, not only showing what is worth visiting in a particular area, but linking to heritage listing sites. . An example project, covering military sites in the UK, Denmark and Poland, is available at https://military.johnbray.org.uk/Main_Page. I will release the software under a CC licence, and would be delighted if people wanted to use it for their own projects. I would be interested in feedback from people here both on presentation and performance. Vicarage (talk) 16:52, 19 February 2023 (UTC)
Use of imported from Wikimedia project (P143) English Wikipedia (Q328) and similar statements as references
Current there are many old items that reference claims as being imported from Wikipedia. Per a talk page conversation, there is the claim to make that these statements really do not count as a reference on its own. I would like to start a discussion about using this statement as the sole reference for a claim, and if it needs more supplementary data (maybe a permalink to the revision that was used to import the statement) or if it needs a whole separate reference group that isn't from Wikipedia as well. RPI2026F1 (talk) 14:15, 13 February 2023 (UTC)
The entire references section is useful to provide information where the data was taken from (i.e. track data provenance), or even how it was generated/inferred if not directly taken from a source (e.g. using machine learning). Thus, if something is being imported from Wikipedia, it should be explicitly noted using P143 reference qualifiers. A permalink using Wikimedia import URL (P4656) improves the reference, but standalone imported from Wikimedia project (P143) is also okay-ish if the data is taken from a Wikipedia page that is/was directly sitelinked from that item. Re-users may want to ignore all references that use any of these reference qualifiers if only "serious" references should be used: P143, P4656, P887, P3452, (and possibly a few others). IMO, P143 references can be removed if serious external sources are present on the same claim. However, that is not really an important cleanup procedure since those references do not really hurt anyways. —MisterSynergy (talk) 14:29, 13 February 2023 (UTC)
One odd thing I have been seeing is that spammers add references of this type to items that have never had a sitelink. Bovlb (talk) 17:17, 13 February 2023 (UTC)
So instead of trying to improve these, you should replace them with real references. Replacing a reference with another with a robot is much harder than adding reference to a statement that has no sources at all. Not adding the imported from Wikimedia project (P143) makes it more likely it will get a real source. Multichill (talk) 17:40, 13 February 2023 (UTC)
If the data provenance is that it's important from the English Wikipedia why would it be a problem for external identifiers? ChristianKl ❪✉❫ 12:57, 14 February 2023 (UTC)
Does imported from Wikimedia project (P143) actually get used anywhere/by anyone? I know with the on-wiki work I've done in the past to reuse Wikidata information in cases where references are needed, it's just thrown out (and if references aren't needed, then it makes no difference). And as a Wikidata editor, it's mostly just frustrating to see that a fact has a reference, only to check it and it turns out just to be to a Wikipedia. If it is actually useful, it would be good to document that somewhere. Thanks. Mike Peel (talk) 21:10, 14 February 2023 (UTC)
I use it in several of my data quality reports. Geodata imported from Ceb and SV wikis has a regular pattern of P625 error. Geodata imported from CY wiki has a regular pattern of label errors, &c&c. It's useful to be able to segment items based on their import vector. --Tagishsimon (talk) 21:16, 14 February 2023 (UTC)
Hello Mike, in my opinion P143 is useful for easier "debugging" for wrong values. When a wrong value is found in a object (e.g. a wrong ID or a wrong date) and the object has a lot of sitelinks, it is not necessary to check every sitelink to correct the information, but only the one sitelink where the wrong value came from to correct this article. M2k~dewiki (talk) 21:19, 14 February 2023 (UTC)
Here's your quick overview of what has been happening around Wikidata over the last week.
Discussions
New requests for permissions/Bot:
Cmtqwikibot 2 (Task/s: Add credits (cast and crew) for audiovisual work produced in Quebec based on the Cinémathèque québécoise's catalogue data. Adds reference. Deletes redundant, more general existing statements in certain circumstances.)
Gabrabot (Bulk upload Maltese lexeme data to wikidata from Gabra.)
Next Linked Data for Libraries LD4 Wikidata Affinity Group call February 21, 2023: Jim Hahn and John Mark Ockerbloom will be presenting on Penn Libraries' Linked Data Vision. They will discuss their framework for activities and goals around linked data, which includes both existing standards and new functionality. Additionally, they will share successes and areas where progress has not yet been made. The presentation will cover projects with Wikidata tie-ins, such as the Digital Scriptorium Wikibase project and the Deep Backfile copyright information project. The presenters also plan to have ample time for conversation with those interested in using linked data to bring new functionality to their libraries. Agenda
Wikidata and Wikibase - SEMIC workshop 2 physical hands-on workshop in Brussels on the 23rd of February (Register here)
If you are interested in organizing or joining the Wikimedia Hackathon 2023 satellite events, you can apply for funds by March 20 via the Rapid Grants maintained by the Wikimedia Foundation.
I run a custom js that makes statements boxes for a particular property scrollable if it is too tall. You can see it at User:BrokenSegue/shorten.js. Is there interest in making this default? I think having a single property box being incredibly tall (say with 10 different subscriber counts or population counts) is a bad user experience. If not at least anyone interested can enable it with importScript( 'User:BrokenSegue/shorten.js' ); in their common.js BrokenSegue (talk) 19:13, 19 February 2023 (UTC)
Is there a reason you're using Javascript for it? Doing it directly in CSS seems to work fine for me. It doesn't work very well with the compact items gadget though. I would suggest .wikibase-statementlistview-listview{max-height:35em;overflow-y:auto;} instead. That excludes the add statement toolbar and makes the maximum height proportional to the font size (35em is 490px at 14px). - Nikki (talk) 14:52, 20 February 2023 (UTC)
I tried it with just CSS at first and it didn't work as well. It was a while ago though so I don't recall what the issue was. I think it had something to do with adding new statements and things getting cutoff. BrokenSegue (talk) 22:25, 20 February 2023 (UTC)
I'm not sure about your exact CSS but by using the fragment provided above, whenever I make a new statement it will scroll down to the new statement in the box, so there's no issues there. RPI2026F1 (talk) 02:19, 21 February 2023 (UTC)
I had to make an edit to the code: .wikibase-statementlistview-listview:not(:has(div.wb-new)){max-height:35em;overflow-y:auto;} because otherwise it would hide the box where you type in the property name when making a new property. It seems the overflow-y: auto chunk breaks the box that shows the property we are adding in a new statement. Broken without modifierWorking with modifierRPI2026F1 (talk) 17:41, 21 February 2023 (UTC)
OK the CSS code also totally breaks constraint error modal boxes. I think this is going to need a lot more debugging before it gets implemented in live. RPI2026F1 (talk) 18:46, 21 February 2023 (UTC)
If you decide to go ahead with this, at least add a small button in the UI to toggle this on/off for each oversized statement list, this button will also serve as a visual indicator that a statement list has overflow. Without this it is hard to spot, which is a big problem. The "Compact items" gadget is also trying to address the issue of vertical real estate, perhaps this functionality should be put there? Some effort will be required to make it compatible in any case. Edit: I'm on Firefox by the way, it doesn't render a scrollbar until you mouse over. Infrastruktur (talk) 06:22, 21 February 2023 (UTC)
Item Q113484166 has only photos and a few descriptions, no links to external databases, no Wikipedia page. Would this be an item to be deleted? I (a Commons volunteer) would be glad to ask for deletion of the photos, but that is only possible if they are not used in for instance Wikidata. JopkeB (talk) 15:28, 21 February 2023 (UTC)
The Terms of Use are the legal terms that govern the use of websites hosted by the Wikimedia Foundation. Feedback on the draft proposal will be gathered from February through April.
A proposal for better addressing undisclosed paid editing
Bringing the ToU in line with current and recently passed laws affecting the Wikimedia Foundation including the European Digital Services Act
Regarding the Universal Code of Conduct and its enforcement guidelines, we are instructed to ensure that the ToU include it in some form.
Regarding CC 4.0, the communities had determined as the result of a 2016 consultation that the projects should upgrade the main license for hosted text from the current CC BY-SA 3.0 to CC BY-SA 4.0. We’re excited to be able to put that into effect, which will open up the projects to receiving a great deal of already existing CC BY-SA 4.0 text and improve reuse and remixing of project content going forward.
Regarding the proposal for better addressing undisclosed paid editing, the Wikimedia Foundation intends to strengthen its tools to support existing community policies against marketing companies engaged in systematic, undisclosed paid editing campaigns.
Finally, regarding new laws, the last ToU update was in 2015, and that update was a single item regarding paid editing. The last thorough revision was in 2012. While the law affecting hosting providers has held steady for some time, with the recent passage of the EU’s Digital Services Act, we are seeing more significant changes in the legal obligations for companies like the Wikimedia Foundation that host large websites. So with a decade behind us and the laws affecting website hosts soon changing, we think it’s a good time to revisit the ToU and update them to bring them up to current legal precedents and standards.
As part of the feedback cycle two office hours will be held, the first on March 2, the second on April 4.
The ToU update seems about welcoming the totalitarian governments in the world to allow them to censor content on Wikimedia that they previously couldn't censor. ChristianKl ❪✉❫ 13:28, 22 February 2023 (UTC)
Specifying the temperature in structured data on Commons
Question 1: Is there an intended way to add temperature information to structured data on Commons? (Perhaps adding this kind of data is generally discouraged?)
While trying to investigate the intended use of temperature (P2076), I found many items (mostly onsen and celestial objects) with temperature statements, which violate the property scope constraint of temperature (P2076) by not being qualifiers. Only James Webb Space Telescope sunshield (Q28233367) is for some reason listed as an explicit exception to that constraint. Unfortunately I don't know the syntax for finding a use of temperature (P2076)as a qualifier.
Question 2: Is temperature (P2076) over-constrained, or should the items with temperature statements be changed, or is it okay to have all these warnings?
I believe Q30606020 and Q75295912 are both Isabelle princess of Salm-Salm but Special:Merge Items says Failed to merge Items, please resolve any conflicts first.
Error: Conflicting descriptions for language en. 38.134.105.1015:04, 22 February 2023 (UTC)
To puncture the suspense, Estopedist1 has proposed on the admin board that IP users should be wheeled out & shot. Suggest we keep the discussion in one place; there. --Tagishsimon (talk) 18:48, 22 February 2023 (UTC)
Seconding what Andy has written. A really lovely guy. I only got to know him when he was hugely supportive and encouraging with efforts to try to get 10,000 medieval manors into wikidata sensibly and effectively as part of WD:WikiProject EMEW, and then when he organised a wonderful weekend workshop and hackathon on the manors data last year in York, but he had been an engaged and active editor and supporter of Wikimedia and for all the possibilities from institutions like UK National Archives (Q392703) building links with Wikimedia for years. Will be very much missed. Jheald (talk) 20:08, 23 February 2023 (UTC)
I don't think the title is what matters. Special lexemes has the infobox that says "Lexemes don't contain general data (date of birth, opening date, author, country, coordinates, website, etc.) about the entity or concept to which they refer. If you want to submit general data, you need to create an Item instead". If someone doesn't know what a lexeme is (which is going to be most people who aren't linguists), that infobox has the job to tell them. If special lexemes does not the job of explaining what a lexeme is in the Greek version, that's an issue. I just did the job of actually checking and it seems like the infobox isn't translated. ChristianKl ❪✉❫ 10:47, 26 February 2023 (UTC)
There are a bunch of messages (such as wikibaselexeme-newlexeme-info-panel-lexicographical-data) that are not translated yet. @Μητσίκας: If you wanted to, you could translate these on TranslateWiki.net (although it does sound like there's uncertainty about what 'lexeme' is in Greek!). SamWilson02:01, 27 February 2023 (UTC)
I haven't used Wikidata for a while and nearly forgot how it works. And since I barely know what it means, it made thinks worse. Thanks guys.--Μητσίκας (talk) 15:06, 26 February 2023 (UTC)
Link Wikidata item/Wikipedia articles to Commons category
There is a Wikidata item that links to articles on several Wikipedias, but doesn't have its own category on any Wikipedia. Is there some way to link this to the Commons category? Lights and freedom (talk) 00:44, 26 February 2023 (UTC)
Hi, I'm working on filling out data for Human Rights Film Festival in Croatia, and I have relevant data about partners, financial donors and media supporters, but I am unsure which statements would be proper to use in this case?
I saw some Festivals used "partnership with" (P2652) for Festival partners, but I am still unsure if that would be the right call. And if it would be right for partners, what about donors and supporters?
Hi there,
I'd like to cite information from the documents of a specific US patent infringement court case on Wikidata:
Case Name: Caliper Life Sciences, Inc. v. Shimadzu Corporation et al
Date: 2009
Court: Texas Eastern District Court
Docket Number: 4:2009cv00034
But I can't figure out how to do. There isn't a publicly accessible URL for this court case so I can't just use reference URL. Alternatively, I guess I could put the court documents on Wikisource or something & cite those, since they are public domain(?), albeit not currently accessible from a public URL? Photocyte (talk) 19:52, 26 February 2023 (UTC)
Hi, can anybody help me regarding OpenRefine: How can I set the confidence interval (lower and upper bound)? I would like to enter data like 40.2 +/- 2.7. Is this possible at all with OpenRefine? I already asked here. Thank you! Yellowcard (talk) 09:32, 27 February 2023 (UTC)
Wikidata weekly summary #561
Here's your quick overview of what has been happening around Wikidata over the last week.
ScikingBot (Task/s: The bot is going to fix interwiki links for the Lombard Wikipedia)
fromCrossrefBot (Task/s: Importing licenses for 1.45 million CC licensed papers from the Crossref April 2022 dump.)
Closed requests for permissions/Bot:
Cmtqwikibot 2 (Task/s: Add credits (cast and crew) for audiovisual work produced in Quebec based on the Cinémathèque québécoise's catalogue data. Adds reference. Deletes redundant, more general existing statements in certain circumstances.)
Bug Triage Hour on dates input, March 13th: Following up on an issue on date parsing in the Czech language (T221097), fixed earlier in February, we would like to look at the changes induced by this fix together, check how the date input parsing works in your language, and identify some possibly remaining issues.
Eager to discover the potential of Wikidata and Wikibase for semantics? SEMIC is organising a series of workshops that are very much hands-on. Join the first workshop online on 24 January 2023 from 14:00 to 16:00 (CET) via Webex. Register for the first event via this link!
Wikibase Suite Survey is now open! The goal is to understand what role Wikibase plays in your organization and identify what you need from Wikibase based on how you currently make use of it.
rebuilt (year or date when the structure was reconstructed, rebuilt, repurposed or replaced by similar one (if the new and old structures have separate items, use P167/P1398 links instead))
The Wikimedia Foundation tests the switch between its first and secondary data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.
All traffic will switch on 1 March. The test will start at 14:00 UTC.
Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.
You will be able to read, but not edit, all wikis for a short period of time.
You will not be able to edit for up to an hour on Wednesday 1 March 2023.
If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.
Other effects:
Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.
This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. A banner will be displayed on all wikis 30 minutes before this operation happens. Please share this information with your community.
At Q7591807, the name of this church is given as "St Swithun's", with "St Swithin's" listed as an "also known as" alternative. While both these spellings have apparently been used, the one actually used on their website, https://www.stswithin.co.uk/, is "St Swithin's", so I wonder if the spellings at Q7591807 should be switched round, so that "St Swithin's" is shown as the main one, and "St Swithun's" as an alternative. ITookSomePhotos (talk) 18:33, 27 February 2023 (UTC)
Notified participants of WikiProject GermanyVojtěch Dostál (talk) 16:32, 2 February 2023 (UTC)
WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. ―BlaueBlüte (talk) 06:40, 1 February 2023 (UTC)
, I'll let native English speakers decide, but if there's a problem with comprehension, why not name the property more explicitly, as @Lectrician1: writes. ―Eihel (talk) 07:58, 1 February 2023 (UTC)
under property name. Ayack (talk) 15:14, 8 February 2023 (UTC)
Added by user:Rima H (WMID) Estopedist1 (talk) 06:51, 20 February 2023 (UTC)
Merged RVA2869 (talk) 21:16, 24 February 2023 (UTC)