About this board

Previous discussion was archived at User talk:Dhx1/Archive 1 on 2017-07-21.



Oronsay (talkcontribs)

Thank you for proposing this Identifier. I just saw it in Wikidata weekly summary #543. I've noted my support for this proposal and tweeted to Wikimedia Australia as the Ping had not worked, or at least I didn't notice it. Hopefully, that will draw more response. ~~~~

Dhx1 (talkcontribs)

Thank you @Oronsay:. I'm not sure why the project ping didn't work this time.

Reply to "Bureau of Meteorology Location ID"
Summary by Dhx1

New formatter URL now in place. IDs haven't changed.

Leyo (talkcontribs)
Dhx1 (talkcontribs)

Thanks @Leyo: the link rot is impacting other property JECFA number (P9557) as well. It looks like all three properties had formatter or source URIs that are now dead, and seemingly don't have equivalent databases replacing them. JECFA number (P9557) is not a database identifier (an ID that is largely useless when the database dies) but rather a number similar to CAS Registry Number (P231) that is used and referred to elsewhere.

Dhx1 (talkcontribs)

I have marked the old URIs as dead (link rot) and updated property descriptions to make it clear the properties are for former identification schemes.

Leyo (talkcontribs)
Dhx1 (talkcontribs)

Perfect, thanks for finding that new page! I've updated JECFA database ID (P4852) to use the new URL structure. The property lives on!

Leyo (talkcontribs)

Thanks for updating! Could you please also have another look at JMPR database ID (P4853)? The original URLs seem to work again.

Dhx1 (talkcontribs)
Summary by Dhx1

Bug resolved

Metamorforme42 (talkcontribs)
Dhx1 (talkcontribs)
Wdpp (talkcontribs)
Dhx1 (talkcontribs)

Thanks for the reminder. I used to run RfcBot manually every few weeks but have obviously forgotten to do so recently. I'm currently running it again right now. RfcBot needs to be rewritten as it is years old and very slow to run as it doesn't use batch processing or any other features to make it run quickly.

Wdpp (talkcontribs)
Chuankaz (talkcontribs)

Greetings,

I noticed your editing stats in Wikidata, which led me to look up your profile. Thank you for all the great 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. If you are interested, please fill in a questionnaire or reply to me directly. The conversation should take about 30 min.

Hope you have a great day,

Charles

Alexmar983 (talkcontribs)

Hi, can i ask why? I have been using P18 as a support for the references since June after a discussion at the village pump months before, all my insertions of Wiki Loves Monuments ID and their (productive) use as references are based on this discussion and those previously existing uses. It's very useful in general to put it as a clear link to a document, a grave, a plaque. I therefore disagree with this constraint, where was it discussed?

Dhx1 (talkcontribs)

It was just based on usage statistics at Property_talk:P18 where as main value (Q54828448) is the overwhelming use of image (P18). It is possible to add as qualifiers (Q54828449) and as references (Q54828450) if there is a use case for this. You've mentioned a few use cases where more applicable properties exist though. For documents, I suggest using described by source (P1343), for plaques commemorative plaque image (P1801), place name signs place name sign (P1766), and graves/tombs image of grave (P1442).

Alexmar983 (talkcontribs)

I Know they exist, I said "in general" for that reason, I was referring to the fact that you need to use an image as a reference. As a result, you simply cannot create always a set of specific properties for that, the general one has an intrinsic value per se. My images for example are letter of consents, for example. it looked to me that P1343 was designed to link to an item, not a file on commons.

Dhx1 (talkcontribs)

The ideal approach would be creation of a new item which is instance of letter of consent (Q88798846) and then using document file on Wikimedia Commons (P996) on this new item to link to the Commons file. Alternatively or additionally a WikiSource item can be linked and/or Wikisource index page (P1957) used. Then in references, described by source (P1343) item-which-is-instance-of-letter of consent (Q88798846) would be used.

That doesn't rule out the need for use of image (P18) for use as a reference. A fact on Wikidata could be verified by observing a photo hosted on Wikimedia Commons. For example, what colour an object is, the name of a building on a sign in an old photo, etc. I generally support adding "as reference values" to the property constraint of image properties (and subproperties thereof).

MediaWiki message delivery (talkcontribs)

Hello Vunj909or4n2btrv,

Really sorry for the inconvenience. This is a gentle note to request that you check your email. We sent you a message titled "The Community Insights survey is coming!". If you have questions, email surveys@wikimedia.org.

You can see my explanation here.


Call for participation in the interview study with Wikidata editors

1
Kholoudsaa (talkcontribs)

Dear Dhx1,

I hope you are doing good,

I am Kholoud, a researcher at the King’s College London, and I work on a project as part of my PhD research that develops a personalized recommendation system to suggest Wikidata items for the editors based on their interests and preferences. I am collaborating on this project with Elena Simperl and Miaojing Shi.

I would love to talk with you to know about your current ways to choose the items you work on in Wikidata and understand the factors that might influence such a decision. Your cooperation will give us valuable insights into building a recommender system that can help improve your editing experience.  

Participation is completely voluntary. You have the option to withdraw at any time. Your data will be processed under the terms of UK data protection law (including the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018). The information and data that you provide will remain confidential; it will only be stored on the password-protected computer of the researchers. We will use the results anonymized (?) to provide insights into the practices of the editors in item selection processes for editing and publish the results of the study to a research venue. If you decide to take part, we will ask you to sign a consent form, and you will be given a copy of this consent form to keep.

If you’re interested in participating and have 15-20 minutes to chat (I promise to keep the time!), please either contact me on kholoudsaa@gmail.com or use this form https://docs.google.com/forms/d/e/1FAIpQLSdmmFHaiB20nK14wrQJgfrA18PtmdagyeRib3xGtvzkdn3Lgw/viewform?usp=sf_link  with your choice of the times that work for you.

I’ll follow up with you to figure out what method is the best way for us to connect.

Please contact me using the email mentioned above if you have any questions or require more information about this project.

Thank you for considering taking part in this research.

Regards

Kholoud

Summary by Dhx1

Mistake fixed

Hannes Röst (talkcontribs)
Dhx1 (talkcontribs)

Fixed, thanks for finding the error!

Adam Harangozó (talkcontribs)

Hi, I created a new page for collecting sites that could be added to Mix'n'match and I plan to expand it with the ones that already have scrapers by category. Feel free to expand, use for property creation. Best, Adam Harangozó (talk) 22:47, 3 November 2019 (UTC)