Wikidata:Edit groups/OR/4a49c29df68
Edit group OR/4a49c29df68
| Summary | adding aliasꓹ creatorꓹ titleꓹ inceptionꓹ and location where applicable | Author | Qono |
|---|---|---|---|
| Number of edits | 572 (more statistics) | Example edit | Q2146810 |
Discussion[edit]
@Qono:@Multichill:
Notified participants of WikiProject Visual arts
This massive edit has interesting data but contains a lot of bad claims, especially with location (P276) and bad precision for inception (P571). For the location, the contributor did not take in consideration existing location (P276) with more precision and admits there was confusion with the city or country of origin of the creator; but he didn't do any corrections, despite he was notified of the problem . One example on many : Pastoral Concert (Q3686086) where it is claimed that the painting is in Venice. The bad impact on the data quality of the items is significative. They are reused, especially in Wikipedia infoboxes. Same example: Le Concert champêtre (Titien) on Wikipedia FR. This is a serious issue and imho a massive revert is the best solution. Best regards. --Shonagon (talk) 19:11, 12 October 2020 (UTC)
- @Shonagon: Can we identify the imprecise redundant locations and dates with a query, and just remove them? Or do the problems with this upload go deeper? Jheald (talk) 19:14, 12 October 2020 (UTC)
- Jheald It would be possible to identify the issue on date, but I don't know how to fix it, because there is often other dates. For the location (P276) claims, it is not possible to identify with a query what is good or not. In both case, there are often already claims. I don't how to remove those precisely those claims with the contribution tools (as I know it is not possible to have such precision with Petscan) and without impacting the existing data. Best regards --Shonagon (talk) 19:27, 12 October 2020 (UTC)
- @Shonagon: A query like this https://w.wiki/gbT can identify imprecise redundant location (P276) statements that are referenced to Make Lists, Not War (Q97309629). The statements can then be removed with eg wikidata-cli. Not sure whether that finds all of the bad location statements in the upload, but it may get many of them. They could also be removed with QuickStatements (-<?item> P276 <?loc1>) Jheald (talk) 20:27, 12 October 2020 (UTC)
- Thanks Jheald for the query. Concerning the location (P276) edits, from the method used, they are unfortunatly all supicious, not only those where there is already a claim. Wikidata-cli is more a framework than a tool. Do you have an idea how to use it for removing precisly those location (P276) edits? For the date precision issue, it is possible to identify the cases: https://w.wiki/gbe . --Shonagon (talk) 21:01, 12 October 2020 (UTC)
- If you have got the statement-ids from a query, then you can just write a shell script with lots of lines
wb rc <guid>(as per [1]), and then execute it. (You may need to experiment with changing the first '-' to a '$' in the statement-id, I can't remember). But it is much gentler on the servers to use batch mode [2], so that wikidata-cli only has to log in once. To do that, put the statement-ids in a file, one per line, thencat stmt_ids.txt | wd rc --batch. Jheald (talk) 21:15, 12 October 2020 (UTC) - With the dates, are we sure that the source is definitely wrong in giving these ranges? Are we sure that other sources, that just give a single year, are more correct? Jheald (talk) 21:20, 12 October 2020 (UTC)
- @Jheald: Given that the source on this edit seems to have provided the creator's nationality for a handful of work location statements, I support removing the location claims where there is another referenced location claim. I think it would be better to identify the incorrect statements and deprecate the rank, but I don't think it is practical to verify every statement with a second source.
- That said, I dispute that there are issues with the inception dates. The source generally did not provide imprecise dates (as in 1950s or 13th century), but instead provided date ranges. In this case, I believe it is appropriate to record the source's claim by setting the inception date as the earliest date in the range while providing earliest date and latest date qualifiers, which is how these edits were entered. If this is incorrect, I think that Wikidata's documentation needs to clarify how to record dates in these cases. Qono (talk) 15:43, 13 October 2020 (UTC)
- If you have got the statement-ids from a query, then you can just write a shell script with lots of lines
- Thanks Jheald for the query. Concerning the location (P276) edits, from the method used, they are unfortunatly all supicious, not only those where there is already a claim. Wikidata-cli is more a framework than a tool. Do you have an idea how to use it for removing precisly those location (P276) edits? For the date precision issue, it is possible to identify the cases: https://w.wiki/gbe . --Shonagon (talk) 21:01, 12 October 2020 (UTC)
- @Shonagon: A query like this https://w.wiki/gbT can identify imprecise redundant location (P276) statements that are referenced to Make Lists, Not War (Q97309629). The statements can then be removed with eg wikidata-cli. Not sure whether that finds all of the bad location statements in the upload, but it may get many of them. They could also be removed with QuickStatements (-<?item> P276 <?loc1>) Jheald (talk) 20:27, 12 October 2020 (UTC)
- Jheald It would be possible to identify the issue on date, but I don't know how to fix it, because there is often other dates. For the location (P276) claims, it is not possible to identify with a query what is good or not. In both case, there are often already claims. I don't how to remove those precisely those claims with the contribution tools (as I know it is not possible to have such precision with Petscan) and without impacting the existing data. Best regards --Shonagon (talk) 19:27, 12 October 2020 (UTC)