Wikidata:Bot requests/Archive/2018/06

Import formatter URL (P1630) from templates

It might worth importing formatter urls from Wikipedia templates, e.g. as on Q54806191 or Q26119624.

Templates that are already linked with corresponding template (P2667) could be skipped.

Ideally, {{{id}}} would be converted to $1, but I can do a cleanup after import.
--- Jura 09:25, 5 June 2018 (UTC)

Some links above. Please use with care.
--- Jura 09:54, 19 June 2018 (UTC)

This section was archived on a request by: Did some manually. Might still be worth doing more.
--- Jura 07:15, 23 June 2018 (UTC)

Some LCCN statements to be deprecated

Request date: 16 June 2018, by: Jheald

Link to discussions justifying the request
Task description

I would be grateful if somebody could change the rank to "deprecated" for 2714 statements for property Library of Congress Control Number (LCCN) (bibliographic) (P1144).

These are LCCN values that are given on the Biodiversity Heritage Library (Q172266), but on the LoC website turn out to be either not recognised; or to refer to a different book altogether; or to be redirects pointing to a preferred new value.

I have added the statements with Quick Statements, with an appropriate reason for deprecated rank (P2241), but QS is unable to change their rank to 'deprecated', so I would be grateful if somebody could do this for me, and finish the job.

Note that some of the statements aren't being returned reliably by WDQS (thread), so I have uploaded the full list to this Wikimedia pastebin: https://tools.wmflabs.org/paste/view/d4beab96

Thanks in advance! Best regards, Jheald (talk) 17:30, 16 June 2018 (UTC)

Request process

@Jheald: should be done. If you can re-check (via query), it wouldn't hurt. --Edgars2007 (talk) 15:05, 15 July 2018 (UTC)

@Edgars2007: Thanks! WDQS found two more, so I have done those by hand. It's possible there may be a handful more -- WDQS only finds 2705 statements with reason-for-deprecation at the moment tinyurl.com/ybdsnbtx, and the same number with deprecated rank tinyurl.com/yd8yy9tm whereas there were 2714 in the pastebin; but it has been a bit flaky all the way through on this set of edits. I'll see if I can identify the remaining nine, and check them manually. Thanks again! Jheald (talk) 15:51, 15 July 2018 (UTC)
There were some already removed Library of Congress Control Number (LCCN) (bibliographic) (P1144), so it probably could be ok. --Edgars2007 (talk) 15:56, 15 July 2018 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:13, 1 September 2018 (UTC)

The following lack P301 http://petscan.wmflabs.org/?psid=4625759 . Most have an English Wiktionary category page with a description that includes a link to an English Wikipedia article, a language code or even the QID to use. This is mostly added through a series of templates there.
--- Jura 11:08, 3 June 2018 (UTC)

Rank P150 (sub-admin regions) as preferred

Request date: 31 January 2018, by: Yurik

Link to discussions justifying the request
  • This was mentioned to me by @Jura1:. I'm not sure if this is controversial enough to warrant a big discussion.
Task description

Set rank=preferred on all contains the administrative territorial entity (P150) statements that do not have end time (P582) qualifier if some of the entity's P150 have end time, and some do not. Without this, querying for wdt:P150 returns both the old and current results together. In some cases, P150 with q:P582 were set incorrectly as deprecated, leaving the current ones as "normal rank". These should also be fixed. CC: @Laboramus:.

Discussion
Request process

Labels for Wiktionary categories

I am running into a multitude of Wiktionary categories which has sitelink in language A but not label in A. Can anyone please add labels automatically? And please don't omit expressions in parentheses! @ValterVB:? --Infovarius (talk) 13:22, 30 May 2018 (UTC)

Even AutoEdit doesn't work for Wiktionary sitelinks... --Infovarius (talk) 13:31, 30 May 2018 (UTC)
And labelless items are created by PetScan (can it be changed?) so their number is constantly increasing and there is need in a regular work. --Infovarius (talk) 13:35, 30 May 2018 (UTC)
@Infovarius: The dumps have become too big (too much time to download and unzip), so I stopped to download them and update label description, or do other weekly task that using dump. If differential dump will be available, probably I restart my periodical task. Alternatively, I can do it with a SPARQL query (if I find a suitable one) --ValterVB (talk) 17:25, 30 May 2018 (UTC)
@ValterVB: Can you please run along ru-pages without ru-label? 3750 now:
SELECT ?item ?sitelink ?itemLabel ?title WHERE {
  ?sitelink schema:isPartOf <https://ru.wiktionary.org/>;
     schema:about ?item; schema:name ?title 
    SERVICE wikibase:label { bd:serviceParam wikibase:language "ru,[AUTO_LANGUAGE],en" } .
   FILTER(NOT EXISTS {
   ?item rdfs:label ?lang_label.
   FILTER(LANG(?lang_label) = "ru") #with missing Russian label
 })
} ORDER BY ?itemLabel
Try it!

 – The preceding unsigned comment was added by Infovarius (talk • contribs).

All   Done except for 4 item for conflict label+description:

--ValterVB (talk) 09:39, 3 June 2018 (UTC)

Thanks for work, Jura and Valter! May I ask for harder task: to add aliases from Wiktionary page titles if they are different from the item label? --Infovarius (talk) 21:07, 3 June 2018 (UTC)

Copy taxon common name to alias

We need a bot, please, to copy values from taxon common name (P1843), to aliases in the appropriate languages, like this edit. A periodic update would be good, too. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:00, 15 November 2017 (UTC)

At least two steps should happen before this:
  1. copy to labels where missing
  2. update labels/aliases with different capitalization (upper to lowercase)
At the moment, there are around 300,000 (!) aliases to be added. Matěj Suchánek (talk) 18:14, 14 December 2017 (UTC)
This is not a good idea at all. Please don't. - Brya (talk) 17:35, 27 December 2017 (UTC)
Yet another vague, negative comment, with no justification offered. Meanwhile, here's a quote from Help:Aliases (emboldening added): "The label on a Wikidata entry is the most common name that the entity would be known by to readers. All of the other common names that an entry might go by, including alternative names; acronyms and abbreviations; and alternative translations and transliterations, should be recorded as aliases". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:13, 27 December 2017 (UTC)
This Help:Aliases was written a very long time ago, at a time when Wikidata was envisioned as just a depository of sitelinks. - Brya (talk) 18:23, 27 December 2017 (UTC)
Indeed it was written a long time ago - and it remains current. But Wikidata was never "envisioned as just a depository of sitelinks". Still no justification offered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:21, 27 December 2017 (UTC)
Plenty of users still envision Wikidata as just a depository of sitelinks, even today. And clearly Help:Aliases was written from that perspective. - Brya (talk) 05:08, 28 December 2017 (UTC)
"Plenty of users..." While you appear to be making things up, or at the very least making claims without substantiating them, there can be no useful dialogue with you. And please stop double-indenting your comments; as explained to you previously, it breaks the underlying HTML markup. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:44, 28 December 2017 (UTC)
To anybody sane, HTML is a tool to be used towards a purpose. Regarding HTML as a purpose onto itself is going beyond mere idiosynchrasy. - Brya (talk) 17:53, 28 December 2017 (UTC)
Sounds like a good idea to me. I think it's important to link the common names to the proper species name. I am not sure about the specific implementation. For example, I don't have a strong preference to have the taxon name or the common name as label, but the other should be an alias for sure. That makes it a lot easier to recognize the proper entry. --Egon Willighagen (talk) 14:34, 29 December 2017 (UTC)
Just to cite a current problem involving the "interpretation" of a common name: Wikidata:Project_chat#Xantus's_Murrelet. As far as I know we had a major import from Wikispecies without any references and some referenced additions via IOC, IUCN or Wörterbuch der Säugetiernamen - Dictionary of Mammal Names (Q27310853) done by my bot. I object to add any unreferenced common names as aliases. If have no problem with the latter onces, if there is an agreement here to do so. --Succu (talk) 21:33, 29 December 2017 (UTC)
Yes, there are at least two problem sets of common names
  • those moved from Wikispecies {by Andy Mabbett). After this had been done, at Wikispecies they did not want common names from Wikidata imported into Wikispecies because of the dubiousness of this content.
  • those from ARKive; proposed by Andy Mabbett as a property as being a "repository of high-quality, high-value media" but used by some user to "import common names" from. Many of these are not just dubious, but outright bogus. - Brya (talk) 05:39, 30 December 2017 (UTC)
Your indentation fixed, again. The idea that Wikispecies did not want to use content from, er, Wikispecies is, of course, laughable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:39, 30 December 2017 (UTC)
Laughable? I doubt you can show us a discussion where people at Wikispecies are eager to drop there content related to taxon common name (P1843) and reimport it from here. --Succu (talk) 20:15, 30 December 2017 (UTC)

No cogent reason why taxon common names are not aliases has been given; can someone action this, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 25 February 2018 (UTC)

Two prerequisites are given by Matěj. Do you agree with them? --Succu (talk) 22:32, 25 February 2018 (UTC)
The former, certainly; the latter could be done, but otherwise we already have bot which does that on a regular basis. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 1 March 2018 (UTC)

The taxonomy and what common names difine are are not necessarily the same. Your assumption is that you can retrofit common names on what science thinks up. Do you have prove for that? Or does it take a single example to undo this folly? Thanks, GerardM (talk) 07:23, 2 March 2018 (UTC)

Oh go on: please show us an example of an item with a valid entry for taxon common name (P1843) that is not valid as an alias for that item. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:40, 5 April 2018 (UTC)
No example? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 9 April 2018 (UTC)

Can someone action this request, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:26, 16 June 2018 (UTC)

Fetch coordinates from OSM

We have many items with an OpenStreetMap relation ID (P402), and no coordinates:

SELECT ?item ?itemLabel WHERE {
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  ?item wdt:P402 ?OpenStreetMap_Relation_identifier.
  MINUS { ?item wdt:P625 ?coordinate_location. }
}
LIMIT 1000
Try it!

Can someone please fetch the coordinates from OSM? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 27 November 2017 (UTC)

an OSM relation id sometimes denotes a rather big area (a municipality, a nature reserve, etc.). What coordinates to take? --Herzi Pinki (talk) 19:19, 27 November 2017 (UTC)
The centroid. If that's not possible, the centre of the bounding box. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:39, 27 November 2017 (UTC)
@Pigsonthewing: It's a bit late to comment and I'm sure you're aware of this, but this won't work for public transport and route relations because they're either lines or made up of other relations, and won't work for objects with multiple locations like Toys R Us (Q696334). It's probably not a good idea to add coordinates to those with an automated process unless the resulting coordinates accurately represent a point that is actually on the line, or represent all points of a multiple-node relation (and neither of these may be desirable). Jc86035 (talk) 13:06, 27 December 2017 (UTC)
Sets of objects with multiple locations should not be in an OSM relation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:38, 27 December 2017 (UTC)
What about ODBL license of OSM data? Mateusz Konieczny (talk) 14:45, 27 December 2017 (UTC)
From what I checked: importing from OSM would be violation of its license, therefore I propose to reject this proposal and remind importers to check copyright status of imported data Mateusz Konieczny (talk) 09:34, 10 May 2018 (UTC)
You assume that OSM is correct to assert copyright ownership over individual facts, or that its database rights in the EU apply to Wikidata as a US-hosted initiative; it is far from clear that this is the case for either scenario. See also Wikidata:Project chat#‎OpenStreetMap. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:56, 10 May 2018 (UTC)
It appears that Wikimedia legal team disagrees with you For EU databases, bots or other automated ways of extracting data should also be avoided because of the Directive’s prohibition on “repeated and systematic extraction” of even insubstantial amounts of data from https://meta.wikimedia.org/wiki/Wikilegal/Database_Rights#Conclusion Mateusz Konieczny (talk) 08:18, 11 May 2018 (UTC)
I suggest you read the many disclaimers at the start of that page; and always refer to them when citing it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:32, 16 June 2018 (UTC)