User talk:Vahurzpu

From Wikidata
Jump to navigation Jump to search
Logo of Wikidata

Welcome to Wikidata, Vahurzpu!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

  • Introduction – An introduction to the project.
  • Wikidata tours – Interactive tutorials to show you how Wikidata works.
  • Community portal – The portal for community members.
  • User options – including the 'Babel' extension, to set your language preferences.
  • Contents – The main help page for editing and using the site.
  • Project chat – Discussions about the project.
  • Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, please ask me on my talk page. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards!

--Liuxinyu970226 (talk) 12:09, 10 May 2019 (UTC)

Wikidata:Project chat/Archive/2019/06#Import global warming potential (P2565) from a PDF table[edit]

Hi Vahurzpu, I only noticed now that you extracted the wrong column, i.e. GTP 100-year instead of GWP 100-year. Would it be possible you to update de:User:Leyo/GWP, where I manually assigned the respective WD items to the substances in order to import them to WD? --Leyo 12:52, 24 July 2019 (UTC)

@Leyo: It should be fixed now. I guess my eyes just scanned to the last column, since it looked almost like what I was looking for. Let me know if there's anything else from that table that would be useful; I have an inconveniently-structured but machine-readable spreadsheet of the entire thing. Vahurzpu (talk) 02:09, 25 July 2019 (UTC)
Great, thanks a lot! I don't think I need anything else from that table. --Leyo 20:20, 25 July 2019 (UTC)


Hi there! Thank you for supporting the proposal. TBH, I'm quite curious of the information you've been working with :) could you give me a little details? Best, Nomen ad hoc (talk) 22:49, 8 August 2019 (UTC).

@Nomen ad hoc: A bunch of articles on US high schools have sections for alumni in a semi-structured format, and many of them include the graduating class. While a bunch of them are unreferenced, it doesn't seem like it would be too difficult to screen those out. Right now I've been bogged down with mwparserfromhell issues, but I just think I found a workaround and will probably return to the import soonish. Vahurzpu (talk) 22:54, 8 August 2019 (UTC)

Community Insights Survey[edit]

RMaung (WMF) 17:37, 10 September 2019 (UTC)

Reminder: Community Insights Survey[edit]

RMaung (WMF) 19:53, 20 September 2019 (UTC)

Verb senses[edit]

Hi, i saw you added senses to verbs erroneously. Please make sure the q item describes an action before adding.--So9q (talk) 08:29, 5 December 2019 (UTC)

@So9q: Yeah, sorry about that; I was trying out MachtSinn and didn't pay close enough attention to the lexical categories at first. I have something to do today, but I'll run through my contributions tomorrow and fix anything I screwed up. Vahurzpu (talk) 22:42, 6 December 2019 (UTC)
Perfect! 😃--So9q (talk) 07:54, 7 December 2019 (UTC)

Url and language[edit]

Hello. I trying to make a query like your example. Hello. I want to find all items that have a reference with reference URL (P854) ->$file/POP_CEN_76-POP&HH_PLACE_RESID-140115.xls?OpenElement with also (at the same reference) language of work or name (P407) -> English (Q1860) and Greek (Q9129). Is the query correct? Base on the results, I think is OK, but I need a second opinion.

SELECT DISTINCT ?item ?itemLabel {
  ?item ?prop ?statement.
  ?statement prov:wasDerivedFrom ?ref.
  ?ref pr:P854 <$file/POP_CEN_76-POP&HH_PLACE_RESID-140115.xls?OpenElement>.
  ?ref pr:P407 wd:Q1860.
  ?ref pr:P407 wd:Q9129.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }

Try it!

Xaris333 (talk) 16:21, 4 January 2020 (UTC)

@Xaris333: That looks correct to me. Vahurzpu (talk) 16:24, 4 January 2020 (UTC)
Thanks! Xaris333 (talk) 17:52, 4 January 2020 (UTC)

One more thing please. I want to find all items that have a reference with reference URL (P854) ->$file/POP_CEN_11-POP_PLACE_RESID-EL-171115.xls?OpenElement with also (at the same reference) title (P1476) -> Απογραφή πληθυσμού 2011 (Greek language) and title (P1476) -> Census of population 2011 (English language). Xaris333 (talk) 02:25, 5 January 2020 (UTC)

Removing "women in STEM fields" (Q86379016) from entities[edit]

Hi! Last fall several colleagues and myself were working on Wikidata entries for women in STEM and added the property "instance of" with "women in STEM fields" to 7 or so people in Wikidata. It seems that you removed that claim from all of the entities despite the fact that the usage is correct for both P31 and Q86379016. I plan on adding them back to the records, could you please let me know why the changes were made? Thank you. Emiraglia85 (talk) 23:18, 4 March 2020 (UTC)

@Emiraglia85: Sorry for interfering with your project. I reverted the changes because, per Help:Modelling/Other domains#People, "There is a consensus that an individual person has only one instance of (P31) value: human (Q5)." This is done to avoid cluttering instance of (P31) with every possible combination of traits. The item for a woman in STEM will have three traits:
The following query would get you a pretty broad list of women in STEM:
SELECT ?person ?personLabel WHERE {
  ?person wdt:P31 wd:Q5.
  ?person wdt:P21 wd:Q6581072.
  wd:Q1881523 wdt:P527 ?basefield.
  ?field wdt:P279* ?basefield.
  ?field wdt:P3095 ?occupation.
  {?person wdt:P101 ?field} UNION {?person wdt:P106 ?occupation}
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} LIMIT 100 # Increase this if you want more results

Try it!

If you're going to use this query, know that it uses a relatively broad definition of "science", including some pretty humanities-y social sciences, as well as including people who have a STEM occupation listed alongside some non-STEM one. It might be more useful to look for female physicists, female chemists, etc. rather than trying to get all STEM at once. You might want to check out Wikipedia:WikiProject Women in Red (Q23875215), especially their Redlist index; they have a fairly comprehensive look at this.
If you're trying to mark women in STEM generally, just make sure to add sex or gender (P21) as well as setting field of work (P101) and/or occupation (P106) to the most specific applicable entry.
If you have any further questions, don't hesitate to ask. Vahurzpu (talk) 02:25, 5 March 2020 (UTC)

Thank you![edit]

Thank you for getting back to me so fast! It's a shame that we can't use it since like you said it's a bit harder to pin down and since it's technically allowed by the property but it's helpful to know where it went wrong and I greatly appreciate the query. We have another Women in STEM Edit-a-thon coming up and this will help us create better entries.

Emiraglia85 (talk) 04:26, 5 March 2020 (UTC)


Hi. I noticed that you have removed a lot of information from Q5229533.[1] Is there a reason for such a drastic change? If the identifiers are against the wrong item, shouldn't they be deprecated to prevent accidental reinsertion? From Hill To Shore (talk) 22:15, 29 April 2020 (UTC)

@From Hill To Shore: Just went back and marked things as deprecated. I'll often delete identifiers such as this, because I'm pretty sure I saw somewhere (though now I can't find the source, so I'm not entirely sure) that VIAF ignored ranks, and so would erroneously keep the Wikidata item in the cluster. Vahurzpu (talk) 23:19, 29 April 2020 (UTC)
Hi again. It looks like a bot added the VIAF again even though it was still there as deprecated. I've since found that Help:Conflation of two people explains the correct way to deal with these. I've split the item into David N. Parsons (Q96200543) and Dave Parsons (Q96200722). From Hill To Shore (talk) 01:16, 11 June 2020 (UTC)

Your recent batch of National Academy of Sciences member ID (P5380)[edit]

Following the links from the formatter URL seem to return "The page that you tried was not found." for many (all?) values added in #temporary_batch_1590383626560. --Haansn08 (talk) 06:23, 25 May 2020 (UTC)

@Haansn08: This is a known problem. The basic problem, as laid out on the property talk page, is that there are different URL patterns for living and dead people. It's possible to programmatically figure out which one is which (see if there's a date of death (P570) statement and choose the appropriate URL formatter), but that's too complex for the URL formatter, and, as far as I know, for the wikidata-externalid-url tool that usually deals with complex URL formats. While the URL formatter for the item I added fails (, NAS does have a page at that ID: . Vahurzpu (talk) 13:32, 25 May 2020 (UTC)

Interview Invitation[edit]

Hi Vahurzpu,

I noticed your editing stats on Wikiscan statistics, which led me to look up your profile. Thank you for all the hard work!

I’m reaching out to you because I’m working on a research project about understanding what motivates editors like you to contribute to Wikidata. We’re also interested in learning about how you feel your contributions are being used outside of Wikidata. Since you are such an active community member, I thought you might also be interested in helping to build the broader community’s knowledge about Wikidata, and why it matters.

If you’re interested, let’s schedule a time to talk over Zoom, or whichever platform you prefer. You could leave a direct message or fill in a questionnaire. The conversation should take about 30 min.

Hope you have a great day,

Chuankaz (talk) 22:37, 10 June 2020 (UTC)

FamilySearch form[edit]

Thank you very much indeed for creating this form. It is nice to have an easy way of assembling QuickStatements batches. But there are a few bugs and yeah I have lots of suggestions for rearranging it ...

  1. Bugs. The P19 and P119 statements have their elements in the wrong order. The P20 statement isn't even being created for some reason.
  2. Dates don't allow for specifying precision or entering less than the full day, month, and year. Plus, the format mm/dd/yyyy is US-centric, probably better to go with the international yyyy-mm-dd.
  3. Gender isn't always relevant so no reason to include it in every single batch of statements. Maybe you could handle the inverse statements for children as -- "Children (this record is their ◯ Father ◯ Mother)"
  4. Marriages. You don't have much for that yet, and it should have a separate section. Here's an example of all the statements-with-qualifiers I create for a married woman (there's redundancy, but no rules on Wikidata say you can't include the same information several ways): spouse, family name (at birth), family name (married), birth name, married name. A man of course is much simpler, just spouse with start time and place.
  5. I have more thoughts but those are the biggest things! Levana Taylor (talk) 21:18, 22 June 2020 (UTC)
@Levana Taylor: Okay, I've addressed most of these. Point-by-point:
  • I fixed the issue with P20; I mixed up death and baptism
  • What exactly do you mean by "The P19 and P119 statements have their elements in the wrong order"? I don't see any obvious issues in the output.
  • You should now be able to enter dates with multiple precisions. Particularly, YYYY-MM-DD gets you day precision, YYYY-MM gets month, and YYYY gets year. If decade or century precision would be useful, let me know and I can add that in, though I'd need to come up with some input format.
  • Gender is now just a mother/father toggle; if you add children without selecting either, it doesn't add reciprocal statements for them.
  • I don't think this is working. I set the toggle but reciprocal statements weren't created. Levana Taylor (talk) 05:51, 23 June 2020 (UTC)
  • I added a marriage section. There were a few places where I made non-obvious decisions about filling in things:
    • There are family names in both the names section and the marriage section. If you fill out the generic family-name box and then fill out either the birth or married name, but leave the other blank, it will assume that the generic family-name box contains the other of the two names, unless the two filled-in boxes have the same name. If that behavior is counter-intuitive, let me know and I'll remove that logic.
    • Right now you have to explicitly fill in the "birth name" and "married name" or neither of those statements are added. There are a few possible behaviors I could use; if not #1, let me know which one makes the most sense:
      1. The current behavior: if you don't put anything in the boxes, nothing will be added
      2. Get rid of the text boxes; just concatenate all the given and family names in order to deduce the birth name / married name
      3. Keep the text boxes, but automatically add the name strings based on concatenating labels if they're left blank
      4. Automatically fill in the text boxes based on the given/family names, but allow tweaking it.
  • From my point of view the current behavior is brilliant -- it's totally intuitive to fill in all the names except for the one I already entered above if I want name statements, and to leave those rows empty if I don't want name statements. Explicit is better than concatenating, since things can get complicated on occasion. But I am not sure that other people will find things so obvious! Should ask for test volunteers on the community chat. (BTW the "married full name" statement doesn't get created currently)

Further thoughts:

  • Please add age at event (P3629) as another qualifier to "spouse" in the marriage section.
  • "Residence" should have point in time (P585)
  • The vital dates section can be much condensed. I've never seen age at baptism stated, have you? Nor is baptism ever an approximate date. Here's how I imaging the section looking:
    • title: "Vital dates"
    • Note below title: "Date format yyyy, yyyy-mm, or yyyy-mm-dd"
    • Birth date row: Date of birth , circa, earliest date, latest date
    • Additional birth data row: place of birth, Date of baptism
    • Death date row: Date of death, circa, earliest date, latest date
    • Additional death data row: place of death, age at death
    • Burial row: Place of burial, Date of burial (I don't think there's a need to include the "circa" for this one, probably people simply wouldn't use this statement if they don't know the information)
  • Could you also for reference somewhere on the page include the list of the dates of censuses: England & Wales, US? As dropdowns or whatever. Levana Taylor (talk) 05:51, 23 June 2020 (UTC)
  • Also one tiny little adjustment: in the "Family" section, please swap the Mother and Father rows, since not having them in the order they inevitably appear in genealogies increases the chance of entering data in the wrong spot. Levana Taylor (talk) 00:14, 27 June 2020 (UTC)

Note on property creation[edit]

Please see my comment at Wikidata:Property_proposal/NPG_ID, in case you didn't get the ping. --- Jura 08:16, 13 February 2021 (UTC)

Wikidata:Property proposal/Virginia House of Delegates ID[edit]

Hello! As the importer of Virginia House of Delegates ID to Mix & Match, your input is welcome at Wikidata:Property proposal/Virginia House of Delegates ID. Cheers, -Animalparty (talk) 18:45, 3 April 2021 (UTC)