Contact me on English Wikipedia: User talk:RexxS

Check me?Edit

Would you check Special:Contributions/WhatamIdoing on the vaccine items and tell me if that looks right to you? WhatamIdoing (talk) 23:11, 6 November 2017 (UTC)

Hi WAID. That looks fine to me. I usually check descriptions against the opening sentence of the enwiki article: Varicella vaccine, also known as chickenpox vaccine, is a vaccine that protects against chickenpox. That confirms both the alias and description that you added. If you're at all worried about the instance of (P31) then you can check the description and the discussions at Property talk:P31. But don't worry too much: if it's not optimal, one of the pedants here will soon fix it.
I've added a couple of references (pmid:10617719 and as examples of how you might improve the entry further. As before, somebody will probably come along eventually and add extra info. Hope you're enjoying adding info to Wikidata. If you haven't seem Magnus' YouTube video on Drag'n'drop Wikipedia references to Wikidata, it's well worth the 22 seconds – as is his companion piece Drag statements from Wikipedia into Wikidata. Regards --RexxS (talk) 23:48, 6 November 2017 (UTC)
We can add refs just by adding PubMed id numbers?! This is awesome! I figured that I'd have to mess with a complicated series of entries for author, title, date, etc., and it just didn't seem worth it for something so sky-is-blue.
I may look at the drag-and-drop, but PMIDs are likely to be more than sufficient for most of my needs. WhatamIdoing (talk) 04:57, 7 November 2017 (UTC)
@WhatamIdoing: Well, the drag-and-drop only works for url references at the moment anyway. However, you should go to your Preferences → Gadgets → Wikidata-centric and tick the box for DuplicateReferences. It will then allow you to copy an existing reference from a statement and insert it as a reference on other statements. That's also very handy. --RexxS (talk) 14:03, 7 November 2017 (UTC)

Wikidata:Requests for comment/Privacy and Living PeopleEdit

You are receiving this message because you commented at the above RFC. There are additional proposals that have been made there that you are welcome to comment on. MediaWiki message delivery (talk) 03:50, 9 April 2018 (UTC) (for Rschen7754)

Staffordshire (Q21694786)Edit

I've undone your edit on Staffordshire (Q21694786) (diff).

Staffordshire (Q21694786) has to be located in the administrative territorial entity (P131) Staffordshire (Q23105), otherwise the chain fails and one can't give the ceremonial county of England (Q180673) for anywhere in the present county council area (Q21272231). Jheald (talk) 04:00, 21 June 2018 (UTC)

cf this query:, to compare with this listing from en-wiki. Jheald (talk) 04:11, 21 June 2018 (UTC)
@Jheald: That's quite wrong. An administrative county logically cannot be located in the administrative territory of a ceremonial county, because a ceremonial county is not an administrative territory entity. Otherwise, when you come to use the data, you have the nonsense of a chain like:
Staffordshire is located within the administrative territory of Staffordshire? How can anyone make of use data linked like that? See c:Module talk:WikidataIB #Function to return location chain.
The chain clearly should be:
Of course, a ceremonial county can still be located in the administrative territory entity of a region:
but that's not part of the chain for Codsall (Q2313618).
Note that county council area (Q21272231) is "Area administered by a county council in England, if this is different from the ceremonial county". If there are cases where you need to find the ceremonial county of England (Q180673) for a location within it, you need to use a different property from located in the administrative territorial entity (P131) because that is not the correct relationship.
Please revert yourself. --RexxS (talk) 09:55, 21 June 2018 (UTC)
Don't get too hung up on labels, such as that for P131. They're only ever approximate.
This is what has been in place for two years with nobody complaining. It was also run past the UK geography en-wiki project when it was first put in. It's straightforward, and people find it useful.
So no, I'm not going to cause huge confusion and inconsistency, plus upset to existing published queries, whereby sometimes you can get to the ceremonial county by following the P131 chain, and sometimes you can't.
It's easier all round just to by fiat decide that the ceremonial counties are going to be in the P131 chain, all of them, and be done with it; that's what was done two years ago, has worked well since then, is now well-established embedded and accepted, and I have no absolutely no intention of upsetting it or altering it. Jheald (talk) 12:18, 21 June 2018 (UTC)
If your module needs to filter out items that are instance of (P31)ceremonial county of England (Q180673) but not non-metropolitan county (Q769603) or metropolitan county (Q769628) then that shouldn't be too hard to manage. Jheald (talk) 12:23, 21 June 2018 (UTC)
But alternatively it might make more sense for your module to quietly skip over the county council area (Q21272231)s, since it is the ceremonial counties that are more likely to be wikilinked, and to be represented by a much more substantial article. Jheald (talk) 13:00, 21 June 2018 (UTC)
Nobody found a problem with the chain previously because nobody's been able to make use of cheap arbitrary access to make such chains until recently, so the issue has never shown up. But now it is an issue. I agree I can have a list of values for instance of (P31) that could be skipped, although that would make the code less efficient. For English Wikipedia, that would probably include all counties of whatever description, especially in the USA. Nevertheless the point is that having misconfigured data puts a burden on every single re-user who wants to use the data. It is far better to keep to proper constraints, such as only allowing the value of located in the administrative territorial entity (P131) to be an administrative territory. That is not semantics but a genuine constraint that has value for everyone who interrogates the data. If the Wikidata community fails to consider the legitimate concerns of the users of the data, it will eventually find that Wikidata just won't be used by other projects or re-users. It's already heading that way on enwiki. --RexxS (talk) 17:15, 21 June 2018 (UTC)
"It's been wrong for two years, so let's keep it that way for eternity" doesn't seem like such a good plan. Why not set up a property that is parallel to "located in the administrative territorial entity" for things that are "located in non-administrative territorial entities" and use that instead? In fact, now that I think about it, doesn't such a thing already exist, possibly in multiple flavors? WhatamIdoing (talk) 17:18, 21 June 2018 (UTC)
@RexxS, WhatamIdoing: Because the inconsistencies you introduce by doing that are deeply confusing for people writing queries. It would mean that for almost all counties, your query using P131 returning a list of places, people born within them, whatever, would work; the same way that it would work for districts, cities, regions, countries etc -- but for a handful of counties it would silently fail. That's a really bad 'gotcha'.
I would rather a couple of people taking time writing modules had to put in an extra couple of lines to give their users flexibility and fine-control of what to return and what not to return, rather than to digging pits all over the place for any number of naive and not-so-naive query writers to fall into -- possibly without even realising the gaps in their retrieved data. Jheald (talk) 17:33, 21 June 2018 (UTC)
If located in the administrative territorial entity (P131) really is meant to be both administrative and non-administrative territorial entities, then it should probably be renamed, and the disambiguation note that tells people to "Use P276 (location) for specifying the location of non-administrative places" should definitely be removed. In the meantime, it sounds like these are supposed to be in location (P276), and query writers need to search within both items if they want everything.
I looked at the conversation you had previously about this, and it does not seem to say that non-administrative items should be included, even for the convenience of query writers. WhatamIdoing (talk) 18:41, 21 June 2018 (UTC)
Counties have been the principal administrative units for a thousand years, and are probably still the geographical division people most fundamentally identify with, beyond their town or village. location (P276) tends to be used for much more local areas, eg villages and towns, that are smaller than the lowest level on the P131 chain. I haven't seen it used within that chain, and I don't think people would expect it.
Again: it becomes deeply confusing for people if for some ceremonial counties we use P131, whereas for others we don't. You can't expect people to apply that systematically when adding statements, or to expect it when writing queries. It's a lot more straightforward and creates fewer unexpected bear-pits to slot all the counties into the P131 chain -- which they all pretty well do. It also means the P131 chain mirrors the hierarchy at Commons, which is also a bonus. Jheald (talk) 21:11, 21 June 2018 (UTC)
Again: It becomes deeply confusing for people when non-administrative territories are classified as administrative territories, instead of being properly classified as non-administrative places. It is not "more straightforward" to say that Staffordshire is located inside itself.
I agree that we need a good system for this. The system that you are recommending may be better than some, but it does not seem to be the best we could do. If you need a chain that ends up tracing to England, then lets make a way to trace it up through West Midlands, without stuttering at Staffordshire. Or we can come up with a different system that actually accounts for this kind of situation. WhatamIdoing (talk) 20:52, 23 June 2018 (UTC)

Merging itemsEdit

Hallo RexxS,
When you merge items, you may want to use the merge.js gadget from help page about merging. It helps with merging, gives the option to always keep the lower number (which is older, so preferable in most cases) and removes the need to file a request on Wikidata:Requests for deletions.
With regards,- cycŋ - (talkcontribslogs) 13:35, 27 August 2018 (UTC)

Thanks, User:Cycn. The standard interface I use starts up the merge wizard, which offers those features directly (in fact, I think it uses merge.js), so I don't have any real problems with merging, other than when editors have removed sitelinks from one entity and used them in another duplicate (such as happened with Wan Ling Temple (Q56254989)) which will cause the merge to fail. As I'm coming across these problems by looking at the Wikidata vandalism dashboard, I don't usually have any background to the edits when they are simply unexplained removals of sitelinks or changes to labels, so I can't easily tell if sitelinks have been reused elsewhere. Cheers --RexxS (talk) 15:21, 27 August 2018 (UTC)

Reverting vandalismEdit

Hi RexxS, I see you've been reverting some vandalism around here. Thanks for helping out - we definitely don't have enough reviewers (or admins) to keep up with this. Would you like rollback permissions here? -- Ajraddatz (talk) 01:43, 7 August 2019 (UTC)

Hi Ajraddatz (talkcontribslogs), I do miss Twinkle when I'm working here. Although the interface makes it straightforward to restore a previous version, having rollback rights would make the job simpler, and I'd be grateful for having them. I assume that the use of rollback here is subject to the same conditions as on en-wiki? --RexxS (talk) 09:39, 7 August 2019 (UTC)
Done. I'm also going to look into Twinkle being used here, because that would be very useful especially for people who only stop by once and a while. And yes, the conditions are the same as enwiki. It's written briefly at WD:ROLLBACK. Thanks again! -- Ajraddatz (talk) 11:44, 7 August 2019 (UTC)