User talk:MB-one/Archive/2020/01

From Wikidata
Jump to navigation Jump to search

P17: Estonia

Your latest patch of adding this statement includes many organizations that are not of Estonia. For example, this category is for organizations of Estonian diaspora, i.e. organization operating in countries other than Estonia, and organizations in this category are embassies of Estonia operating in other countries. Hopefully you can fix this. 2001:7D0:81F7:B580:78DE:B944:B791:CC1C 21:01, 4 January 2020 (UTC)

Can you provide examples? --MB-one (talk) 03:02, 5 January 2020 (UTC)
That is all items that articles in given two categories (and subcategories) are attached to: Q31276220 (Sweden), Q65261911 (Israel) etc. 2001:7D0:81F7:B580:40F3:255A:F6E6:4404 08:39, 5 January 2020 (UTC)
I see that two days ago you fixed P17 to P137 for embassies. "P17: Estonia" statements originating from this category (and its subcategories) are still wrong, though. 2001:7D0:81F7:B580:F599:652D:4AA0:1516 11:05, 7 January 2020 (UTC)

Wikidata weekly summary #397

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • Resolver allows you to quickly find an item based on a property+value string pair. It is especially useful for checking whether an external identifier such as a VIAF ID (P214) or Getty AAT ID (P1014) is already in use in Wikidata.

Wikidata weekly summary #398

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • Tabernacle creates a tabular view of a set of data items from a SPARQL query, PagePile list, or manual list of items. You can select which languages and properties to display. The tool lets you drag-and-drop statements from one item to another, and manually add or edit statements without leaving the page. Tabernacle is great for harmonizing a set of related items or identifying items that need their labels and descriptions translated.
  • Development
    • More work on finishing the migration of wb_terms table
    • Don’t check constraints on “Wikidata property example for media” statements (phab:T227865)
    • Warn users that they're not nogged-in before performing restore or undo (phab:T234430, thanks to Matěj Suchánek)
    • Remove edit link from Special:NewPages if page is not directly editable (phab:T240561, thanks to Matěj Suchánek)
    • Introduce MwEraParser and improve i18n of dates BCE (phab:T140541, thanks to Matěj Suchánek)
    • Bridge: show error dialog if the user isn't allowed to edit Wikidata (phab:T235154)
    • Bridge: ask the user if the change is a fix or an update (phab:T237333)
    • Enabled tainted references on test.wikidata.org

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.


Wikidata weekly summary #399

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
  • Other Noteworthy Stuff
    • New gadget added to Preferences, "Show UnpatrolledEdits" (see discussion): it shows if the last edit to the item has not been patrolled
    • Pywikibot deprecates Python 2 support. Any scripts running via Python 2 should be migrated soon, see more at [1]
    • The next Weekly Summary (January 27) will be the issue #400. Please help us collecting interesting Wikidata-related facts around the number 400!
  • Development
    • More work on wb_terms table migration: information about property terms is no longer updated and removed from wb_terms table.
    • Add "wikibase-statementsection-identifiers i18n message key to Wikibase (phab:T240356)
    • Stop using $wgUser in Wikibase (phab:T241947)
    • Document possible configuration options for Wikibase Repository and Wikibase Client installations (phab:T165973)
    • Document Wikibase Usage Aspects (phab:T236772)
    • Document Wikibase tables (phab:T124603)
    • Wikidata Bridge: add the RadioButton to the component library (phab:T239799)
    • Showing error dialogs if users can’t edit on the repo wiki (phab:T235154)
    • Tainted references: work on keeping the warning visible when users cancel an edit

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Ships

Just to note that we seem to be running in parallel, e.g., see Turmoil (Q83640160). :-) Thanks. Mike Peel (talk) 19:46, 25 January 2020 (UTC)

Starry Sky (Q83632335) and others: why fill in "also known as," and leave the label blank? Seems if we have only one known name, we should make it the label. (If responding, please ping me, I don't maintain a watchlist on Wikidata, thanks.) - `~`` – The preceding unsigned comment was added by Jmabel (talk • contribs).
Hi Jmabel,
the idea behind that is, to fill in the respective ships current name from a different source (maybe it could even be done from Commons data somehow, but I don't have the solution for that currently). From experience, I know that QuickStatements sometimes fails to overwrite a label, so I figured, it's best to not set a label at all upon creation to avoid this, when I fill in the name and other data und the second step.
Cheers --MB-one (talk) 07:58, 29 January 2020 (UTC)
I was thinking about adding them using the category for ship name (P7782) labels, just stripping the "Category:" and "(ship, YYYY)" parts. Would that be easy for you to do in QuickStatements? If not I can figure out some pywikibot code to do the job. Thanks. Mike Peel (talk) 08:41, 29 January 2020 (UTC)
If the category for ship name (P7782) statements are set, I guess, I should be able to set the labels from that. However my progress with the other data is significantly slower, than I planned. It could be a week before I get to the label business for the ships, I don't have technical data for. --MB-one (talk) 10:16, 29 January 2020 (UTC)

Wikidata weekly summary #400

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • Duplicate Item copies the current item (without descriptions or sitelinks) to a new item. This tool is useful for splitting items and for making sets of similar items. Recommended for experienced users.
  • Development
    • More work on wb_terms migration
    • Units support for quantity datatype (phab:T239474)
    • Fix the link to rawgraphs.io from WDQS (phab:T222257)
    • More work on showing messages related to permissions on the Wikidata Bridge
    • Tainted references: fix minor alignment issues (phab:T243269, phab:T242212)
    • Add a "remove warning" button to confirm a correct reference (phab:T234789)
    • Preparing the ground for a unified component library for the Wikidata UI

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Importing ship data

I have observed that you have been running batches which adds data to ship elements. This is normally appreciated, but it seems that you did not consider that many elements already contain data. Now we have a situation with thousands of double entries, i.e. Wilson Humber (Q52338856) which has double entries in length (P2043), draft (P2262) and official name (P1448). In another example, Svealand (Q52513211) a wrong IMO number is imported together with values from the wrong ship. You are also using mass (P2067) to express the value usually entered at payload mass (P4519). I will ask you to immediately stop importing more batches, and start reverting the ones you already have run. If you consider running the batches over again after revising your script, please start with some tests and discuss the result with other contributors. --Cavernia (talk) 08:05, 30 January 2020 (UTC)

Hi Cavernia,
Regarding the mass (P2067) values, I was following an existing practice. Reconsidering, I do agree with you, that payload mass (P4519)xxxcriterion used (P1013)deadweight (Q1332978) is a more elegant way to go. Will therefore revise my code to change that. I am also aware, that the reconciliation failed for some ships and therefore data of different vessels is written onto the same item. Luckily the error rate is very low and it is more efficient to fix those items manually. Any pointers there are much appreciated.
About double entries: Rest assured, that I have well considered, that some items already contain data. Multiple values for a statement are not necessarily a problem and the values, that were added are in most cases either more precise than the existing values or different to the prior values but properly sourced. In either way, there is no need to remove these new values. --MB-one (talk) 17:15, 30 January 2020 (UTC)
To locate IMO values used more than once, use this query.
To locate ships with more than one IMO value, use this query.
You might not be aware that Wikipedia in several languages collects and presents data directly from Wikidata in infoboxes. Examples: [2] [3]. This functionality will soon be expanded, and that is why the multiple values must be removed. --Cavernia (talk) 18:22, 30 January 2020 (UTC)
Also note that the existing River Barrow entry was about the River Barrow, and not a ship named after the River Barrow, so I've added such an entry and moved your ship related data there. Bogger (talk) 23:39, 30 January 2020 (UTC)
Also, please use more specific references - helpful vs unhelpful. Bogger (talk) 23:50, 30 January 2020 (UTC)
Using IMO ship number (P458) as the unique identificator is a good way to avoid picking wrong elements. I also agree about the references. --Cavernia (talk) 08:34, 31 January 2020 (UTC)
At the moment there are:
- 410 duplicate values for length (P2043)
- 16 duplicate values for width (P2049)
- 42 duplicate values for draft (P2262)
It might be less timeconsuming to remove these duplicate values manually compared to reverting the batches. --Cavernia (talk) 21:16, 1 February 2020 (UTC)
Seoul Express (Q12601154) is a bus company not a container ship, so I undid your edits there - is it easy for you to create a new item instead, which we could then link to commons:Category:IMO 9193305 please? Thanks. Mike Peel (talk) 11:11, 2 February 2020 (UTC)

@MB-one:I think that all the passenger ships have gotten there passenger number transcribed to 2261 and those values should be corrected we have MS Fram (Q747160) that is suddenly 318 meters wide and another MV Viking Sky (Q17014761) was suddenly 1400 meters wide Andber08 (talk) 16:28, 2 February 2020 (UTC)

@Andber08: You are correct. Somehow, the passenger numbers have been written as beam value. Will check and correct those. --MB-one (talk) 17:23, 2 February 2020 (UTC)

After going through about 100 of the items you have updated, I found several more mismatches (Saturn (Q52375512), NoCGS Bergen (Q52378073), Evita (Q56199411), Snow Star (Q58427821)). It's obviously a bad idea to match the items against an external database using the ship name, as this seems to be the reason why so many items are not matched to the correct ship. Please stop immediately to import more data until you find a better solution here! --Cavernia (talk) 22:17, 2 February 2020 (UTC)

@Cavernia: It would be a bad idea to match against just the ship's name. But luckily that's not the case. I'll fix the mismatches. However, Snow Star (Q58427821) is correctly matched. --MB-one (talk) 23:02, 2 February 2020 (UTC)
My concern is not the mismatches mentioned here, but the mismatches not yet detected. It could be hundreds based on the relatively small number of items I have gone through so far. How your script is made is unknown to me, the important thing is that it does not work properly as ships (or other elements) with similar names are mismatched. Again, my advice is to use IMO number as the unique identifier. If Snow Star (Q58427821) is correctly matched, then your data is wrong. --Cavernia (talk) 08:02, 3 February 2020 (UTC)
@Cavernia: Thanks to your query I could identify and fix all IMO mismatches. There is a slight chance, that some items without any IMO have been mismatched. These would be harder to identify. Regarding Snow Star (Q58427821), the sources supply conflicting measurements, but it's hard to say, which source is wrong. The current values are from Fleetmon (Q84310793), which is a crowdsourced database. I guess, values coming from Hafen Hamburg Marketing (Q84311050) should be at least equally reliable. --MB-one (talk) 12:04, 3 February 2020 (UTC)
@Cavernia: Delta Sailor (Q52354547) is an odd one, it has two IMO numbers. It's an item you created, and MB-one hasn't edited it, but I think it's the same as Delta Sailor (Q83597895), which he has. We also have commons:Category:IMO 9288643... Thanks. Mike Peel (talk) 21:18, 3 February 2020 (UTC)
@Mike Peel: Strange, seems like QuickStatements has skipped a "CREATE" line. I have removed the wrong IMO number and merged the new item into the old one. This is something that we'll have to do with a lot of items as they are created with Commons category reflecting the IMO number but the IMO ship number (P458) set. I'll make a query to detect those items, and then merge them by a script. BTW, should we discuss this somewhere else? A project discussion only for shipping nerds?
@Cavernia: Wikidata:WikiProject Ships comes to mind. --MB-one (talk) 10:34, 4 February 2020 (UTC)
Ach so... I'll start a new topic on the discussion page there. --Cavernia (talk) 11:16, 4 February 2020 (UTC)
@MB-one: Susana Santiago Neri (Q58274287) is a person with ship data recently added. Can you check this entry as well? --Cavernia (talk) 08:11, 4 February 2020 (UTC)
✓ Done fixed. --MB-one (talk) 10:34, 4 February 2020 (UTC)

Hi MB-one,

you added data from a SHIP named "Puelo river" to the RIVER named "Puelo river". Q3458759. Please, correct that. Beste Grüsse, --Juan Villalobos (talk) 22:48, 3 February 2020 (UTC)

I've restored the old version in that item, as well as Hyundai Dynasty (Q486109) (nominally a car model), which also needs investigation. Thanks. Mike Peel (talk) 22:54, 3 February 2020 (UTC)
Another bad one, Charleston Express (Q55665325) is a newspaper, I've removed the ship additions. Thanks. Mike Peel (talk) 19:03, 5 February 2020 (UTC)
Also Tren internacional (Q12221066). I'm not sure what to make of CSCL Globe (Q18018931), it's simultaneously a ship and a class? Thanks. Mike Peel (talk) 19:31, 5 February 2020 (UTC)
Also Q31174701, Linah (Q12237929), Liverpool Express (Q6658445), and Cape Reinga / Te Rerenga Wairua (Q1034494). Thanks. Mike Peel (talk) 20:46, 5 February 2020 (UTC)

doppel moppel

ahoi matti

(Q32661130) könnte gelöscht werden; es gibt jetze (Q82512467)

liebe grüße --90.187.22.233 11:25, 31 January 2020 (UTC)

✓ Done Wurde jetzt zusammengelegt. --MB-one (talk) 11:55, 31 January 2020 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=User_talk:MB-one/Archive/2020/01&oldid=2037094727"