User talk:Thisismattmiller

Hallo, I've just reverted two of your edits. This is not the church in the link (different town) and this identifier does not refer to the building but to the garden. Please be sure to read the help pages and ask for help if something is not clear before making to quick edits, thank you :-) --Civvì (talk) 20:58, 9 March 2019 (UTC)[reply]

Hi again, I noticed you made the exactly same edits again. I reverted them again. --Civvì (talk) 08:39, 12 March 2019 (UTC)[reply]

Ah! Sorry about that, these are automatic matches from VIAF, which this one is obviously wrong, and snuck back into the batch, I'll make sure it doesn't happen again. Thanks for catching it. Thisismattmiller (talk) 10:19, 12 March 2019 (UTC)[reply]

Hi! I stumbled upon this edit of yours; that's not the same church, so I removed the link. --Syrio posso aiutare? 22:35, 14 March 2019 (UTC)[reply]

Thanks for catching that! Thisismattmiller (talk) 23:18, 14 March 2019 (UTC)[reply]

Also Gloucestershire (Q939536). This should never have been matched.

What are you doing to identify cases when there are multiple different Q-items that each match your target string? Jheald (talk) 19:59, 16 March 2019 (UTC)[reply]

Sorry, I understand better now. Not a bad string match, but a bad cross-reference from VIAF. Not so sure what to do about that. Jheald (talk) 20:06, 16 March 2019 (UTC)[reply]

Difficult to know if anything can be done to catch these. I was wondering if we could look for items that now have a Library of Congress authority ID (P244) but no outbound VIAF ID (P214); but it seems there are 125,000 of them (tinyurl.com/y2uf25l6); with a few glitches but not a huge number in the sample I looked at (tinyurl.com/y4fgejfu).

Sorry if I barked earlier. Can I just say by way of amends that I really appreciate what you're doing. I'm going to be working soon on some images with metadata in MARC records using LCSH headings, and it's going to be hugely helpful to be able to easily match those back to Q-items. I'll just have to be careful about strays! Jheald (talk) 20:49, 16 March 2019 (UTC)[reply]

Thanks for investigating the problems. Yeah these are just bad matches VIAF had created. I am trying to reduce them especially for geographic entities. Cases like this where there is a homonym for a place but VIAF thinks it is the city. I've been excluding types of instance Of where there would not likely be a bibliographic authority record, for example, streams, roads, etc. I could exclude constituency of the House of Commons as well to prevent any other bad matches. I will also soon be adding 30,000 LCSH mappings (done by hand! so no errors) very soon, so there will be even more LCSH terms to connect to. Best, Thisismattmiller (talk) 14:36, 17 March 2019 (UTC)[reply]

Are you sure that Sai Wan Ho (Hong Kong, China) (n2012009907) is the same as Sai Wan Ho station (Q838777)? I'm fairly sure that Sai Wan Ho (Q7399828) (locality) or even Sai Wan Ho (Q15913169) (constituency) would be a better match. I don't know enough about the database to be sure, though. Jc86035 (talk) 08:57, 18 March 2019 (UTC)[reply]

Thanks! This was incorrect on VIAF so was added to the metro station entity incorrectly. I fixed it and made sure any VIAF matches to metro stations are excluded to prevent this particular error in the future. Thisismattmiller (talk) 15:45, 18 March 2019 (UTC)[reply]

Setterich (Q31520972) was wrongly linked as well - the link belonged to Setterich (Q2274928). Interestingly both Wikidata-ID are mentioned in the VIAF-Entry, but both as deleted - but the wrong one was deleted in 2017 already, the correct one oddly deleted just recently. But adding deleted links here isn't a good idea, that way you imported wrong matchings already recognized as being wrong. Ahoerstemeier (talk) 22:22, 28 May 2019 (UTC)[reply]

Thank you, the authority is for the city not the mountian, so I removed it from Setterich (Q31520972) thanks for catching that. Thisismattmiller (talk) 23:54, 28 May 2019 (UTC)[reply]

You initially added this ID to the Wikidata item for the building Q836007, so I moved it to the Wikidata item for the company Q61460498, where it seemed more appropriate. Some of the other IDs on the page for the building probably should also be moved. Do we really need to have this ID for both items? --Robert.Allen (talk) 08:33, 29 March 2019 (UTC)[reply]

I think you are right, n50052276 is a CorporateName authority record and not a Geographic one. So in the case of the LC identifier it probably should not be on the theater building Q836007 only on the troupe. Plus the troupe page has all the associated sitelinks as well. I removed it from the theater record. Thanks very much for catching this! Thisismattmiller (talk) 12:20, 29 March 2019 (UTC)[reply]

I wonder whether it's worth tagging any of the LoC IDs with a subject has role (P2868) qualifier, to identify the nature of the object (according to the LoC) that the LoC ID is an ID for. Then anomalies could be identified by a query.

Alternatively, one might use qualifier broader concept (P4900). This is really intended to identify upward items according to an external thesaurus, to allow sanity-checking queries of the external ontology vs the local ontology on Wikidata; but where external entities are typed, like the LoC IDs, using this to record that type (or, strictly speaking, its Wikidata nearest match) could also be appropriate. Jheald (talk) 15:34, 8 April 2019 (UTC)[reply]

Thanks for the feedback! I do have some mappings that are not one to one, so this could potentially be very useful for those. Thisismattmiller (talk) 21:03, 10 April 2019 (UTC)[reply]

Just to clarify: the qualifiers above are not for mappings that are not one-to-one, they are for annotating mappings that are one-to-one with further information. Jheald (talk) 21:42, 10 April 2019 (UTC)[reply]

I found some other inconsistencies in LCCN identifiers which I've fixed here on Wikidata and which you may wish to try fixing elsewhere you are able to do so. Each pair "X → Y" below should be interpreted as "the P244 value added to X has been moved to Y":

• Munger (Q36796) → Munger district (Q77452)
• Munger Vidhan Sabha constituency (Q6936004) → Munger (Q36796)
• Muzaffarpur Vidhan Sabha constituency (Q6944364) → Muzaffarpur (Q1453196)
• Thiruvananthapuram State Assembly constituency (Q24262092) → Thiruvananthapuram (Q167715)
• Kottayam State Assembly constituency (Q24297589) → Kottayam (Q659887)
• Darjeeling Vidhan Sabha constituency (Q5223068) → Darjeeling (Q169997)
• Deganga Vidhan Sabha constituency (Q5251752) → Deganga (Q55609293)
• Sumerpur Vidhan Sabha constituency (Q7637083) → Sumerpur (Q2720796)
• Karimnagar Assembly constituency (Q6370776) → Karimnagar (Q25563078)
• Mahbubnagar Assembly constituency (Q6733644) → Mahabubnagar (Q2768192)

There is another constituency item (Meerapur Vidhan Sabha constituency (Q25241205)) whose P244 I'd like to move, but that will have to wait pending an import of data about Uttar Pradesh villages into Wikidata. Mahir256 (talk) 19:09, 7 April 2019 (UTC)[reply]

Thank you very much for updating these. I will incorporate logic to look for this type of mismatch with any future work. Thisismattmiller (talk) 20:54, 10 April 2019 (UTC)[reply]

RMaung (WMF) 17:38, 10 September 2019 (UTC)[reply]

RMaung (WMF) 19:54, 20 September 2019 (UTC)[reply]

Hello. Unfortunately, Peter Müller is a very common name in Germany and the Peter Müller described at http://id.loc.gov/authorities/names/n2002113416.html is not the same Peter Müller as Peter Müller (Q62333). See the diff here. When bot runs make mistakes like this, it is probably better to let only users edit entries as the authority data of wikidata is sufficient already. --Christian140 (talk) 21:32, 7 June 2020 (UTC)[reply]

Here you added the wrong LoC id leading to problems downstream. Can you please explain your matching strategy used? Ontario (company) != Ontario (province in Canada). --Hannes Röst (talk) 20:55, 11 August 2020 (UTC)[reply]

https://lccn.loc.gov/n89119120

The coordinates there match a really small village de:Liederbach (Alsfeld) but the text seems to describe the ten times larger de:Liederbach am Taunus. Is there some way to clarify such possible mismatches? Sending a mail with the web formular is not really satisfying, I never got a feedback and I also need to copy/paste the sent text, otherwise it is lost. Thanks. --Wurgl (talk) 10:47, 1 October 2020 (UTC)[reply]

I will ask someone in the policy group at LC what the best approach to correcting something like this and let you know what I hear back. Thisismattmiller (talk) 06:46, 2 October 2020 (UTC)[reply]

https://lccn.loc.gov/n84168998

30°46ʹN, 2°42ʹE is wrong (deep in the Sahara desert), 39°46ʹN, 2°42ʹE is correct: Spain, Baleares. --Wurgl (talk) 08:55, 6 October 2020 (UTC)[reply]

https://lccn.loc.gov/n89625704

The coordinates match de:Bunde but the name matches de:Bünde --Wurgl (talk) 09:59, 8 October 2020 (UTC)[reply]

Your edit: Hi Matt, do you have any prove that the researcher ORCID ID 0000-0002-1560-0258 Denise Hunter is an American writer of contemporary love novels and Christian romance and / or identical with Hunter, Denise, 1968- (LoC)? --Kolja21 (talk) 23:55, 28 June 2021 (UTC)[reply]

Hello, no I do not, that mapping was made based on the conflation of the authority records in VIAF. Thank you for identifying it is incorrect. Thisismattmiller (talk) 00:04, 29 June 2021 (UTC)[reply]

In spanish wikiquote exist one page of Edmund Hillary, do you can add please to wikidata. Thanks.

the link is Dirección URL permanente: https://es.wikiquote.org/w/index.php?title=Edmund_Hillary&oldid=468776 Elamar76 (talk) 04:43, 9 February 2024 (UTC)[reply]

https://www.wikidata.org/w/index.php?title=Q5518554&diff=prev&oldid=878654143 - please take more care. The error was in WD for more than 5 years. @Kolja21: fyi. [1] did add another error "withdrawn identifier value" ISNIplus (talk) 13:11, 6 September 2024 (UTC)[reply]