Wikidata:Contact the development team/Archive/2017/11

From Wikidata
Jump to navigation Jump to search

Editing statements

Tracked in Phabricator
Task T179045

Sometimes it is easier to remember the "number" of a property than its label. Such example are "P31" and "P1313". I therefor usually write 'p31' when I want to add such a claim. But since some days, I cannot use this method. I can still add "P31", but it does no longer recognize "p31". Why? -- Innocent bystander (talk) 10:45, 28 October 2017 (UTC)

New search backend, see phab:T179045. Matěj Suchánek (talk) 11:26, 28 October 2017 (UTC)
High priority, thanks a lot for that. I just discovered that, as mentioned in the ticker, this also affects Q-namespace. "Q5" does not even work as a search pattern, since there is an item with that label. -- Innocent bystander (talk) 12:34, 28 October 2017 (UTC)
I just noticed that typing https://www.wikidata.org/wiki/Q80711 to pick Q80711 doesn't work anymore as well (it's useful when copying a link to an item). ChristianKl (talk) 09:30, 30 October 2017 (UTC)
Should be ✓ Done now, 'p31' works for me. Smalyshev (WMF) (talk) 23:44, 1 November 2017 (UTC)

Problem with SPARQL query

I ran the query https://query.wikidata.org/#%23defaultView%3ALineChart%0ASELECT%20%3Fyear%20%28COUNT%28%2a%29%20AS%20%3Fcount%29%20%7B%0A%20%20wdt%3AP619%20%3Fdate%20.%0A%20%20BIND%28%20STR%28%20YEAR%28%20%3Fdate%20%29%20%29%20AS%20%3Fyear%20%29%20.%0A%7D%20GROUP%20BY%20%3Fyear . For some reason it doesn't display any year past 1976. ChristianKl (talk) 19:15, 1 November 2017 (UTC)

@ChristianKl: your query is broken... --Succu (talk) 19:34, 1 November 2017 (UTC)
http://tinyurl.com/y989ulga should work. Interestingly the query does now what it was supposed to do. ChristianKl (talk) 20:35, 1 November 2017 (UTC)
As https://query.wikidata.org/#%23defaultView%3ALineChart%0ASELECT%20%3Fyear%20%28COUNT%28%2a%29%20AS%20%3Fcount%29%20WHERE%20%7B%0A%20%20%3Fitem%20wdt%3AP619%20%3Fdate.%0A%20%20BIND%28STR%28YEAR%28%3Fdate%29%29%20AS%20%3Fyear%29%0A%7D%0AGROUP%20BY%20%3Fyear does. Whatever the problem was.:( --Succu (talk) 20:40, 1 November 2017 (UTC)

How do decisions about our modeling effect the efficiency of the query service?

In the discussion on Wikidata:Properties for deletion#P2837 Jura noticed that it seems to take less time to run certain queries when we have a special property for Wikidata month number (P2837). This seems to be an important consideration when making decisions about creating properties. I think it would be great to have a document from the development team that specifies the performance implication of various modeling choices, so we can make decisions that are better informed. ChristianKl (talk) 17:13, 30 October 2017 (UTC)

@Smalyshev (WMF): Is this something you can help with? --Lydia Pintscher (WMDE) (talk) 17:20, 30 October 2017 (UTC)
If we need to query something by month number (such as: who was born in February?) right now there is no good (i.e. well-performing) way to do it, since dates are store as full date value in the index. Which means, we can query efficiently by full date value, but not for the parts of it. The query for parts of the data would essentially scan all otherwise matching values (which could be millions), fetch the date, evaluate part of it (e.g. month) and compare to given value. That could take a lot of time. If we plan to query these a lot (such as run "who's birthday is today" query) we need some way to have such values (i.e., month, day, etc.) directly in the data. One of the ways can be having specialized properties for it. Smalyshev (WMF) (talk) 23:43, 1 November 2017 (UTC)
@Smalyshev (WMF): I don't think your answer has something to do with P2837 (P2837) and the purposes it has or the performance implications of using series ordinal (P1545) in it's place in queries. It useful to know whether subproperties like this are benefitial from a performance perspective and should be enouraged. ChristianKl (talk) 19:04, 2 November 2017 (UTC)

Merge requested.

I am not familiar with WikiData, and there is no "village pump"/"pub" here, nor any sort of helpdesk but the items Q39087224 and Q16077912 should be merged, I'm planning on writing that one for Dutch Wikipedia sometime this month (or the next) and these entries are by accident a duplicate of each other, also note that the English Wikipedia page does link 🔗 to the Mandarin Wikipedia page (as I added the interwiki link locally as at the time I didn't know Wikidata existed), but not vice versa. I hope that someone can fix this as I don't see a "merge button" anywhere. -- 徵國單  (討論 🀄) (方孔錢 💴) 09:48, 2 November 2017 (UTC)

I am not sure if this should be placed here or at the administrators' noticeboard but since my only experiences with admins is getting blocked abd being told to "get out" for 6 🕕months I am placing it here, not 🙊 sure if there is a helpdesk as searching it only brings me to the interwiki item. -- 徵國單  (討論 🀄) (方孔錢 💴) 09:51, 2 November 2017 (UTC)
Merge done, see also Help:Merge. The central help desk is at Wikidata:Project chat. —MisterSynergy (talk) 10:04, 2 November 2017 (UTC)

Articles not searchable

Tracked in Phabricator
Task T179815

Now that Harej et al. built us such a nice article database, I just noticed that we can't actually search it by author. Author strings are not indexed. Could you do something about it?
--- Jura 22:45, 5 November 2017 (UTC)

Hello Jura, this type of search would require to search in the labels of the value of a statement, and it's not planned so far. You can search by creating a list with the Query Service, and then search inside the results. Lea Lacroix (WMDE) (talk) 09:41, 6 November 2017 (UTC)
I think it is or was planned and is being done for P31/P279. Could you investigate and prioritize it, because I don't think query service is suitable for string search and the large amount of items this concerns make it more important. The property that needs to be added to the search index is author name string (P2093).
--- Jura 09:50, 6 November 2017 (UTC)

Paste QID no longer working

Tracked in Phabricator
Task T179061

I used to be able to paste full URLs (e.g. "https://www.wikidata.org/wiki/Special:EntityPage/Q18709313" or "https://www.wikidata.org/wiki/Q18709313" instead of just "Q18709313") as values for properties with item propertytype. Some time ago, this stopped working. What happened? Could it be fixed?
--- Jura 08:06, 8 November 2017 (UTC)

It is being. Matěj Suchánek (talk) 08:33, 8 November 2017 (UTC)
Good to see. Still, the ticket is closed but it doesn't work yet. I think it would be preferable if things were checked and ensured to be working on the live site before a bug is closed.
--- Jura 09:02, 10 November 2017 (UTC)

ORES not working

Tracked in Phabricator
Task T180450

After deployment of "New filters for edit review" ORES stopped working for me (no matter if new filters are activated). Legend in the watchlist is still there, but all edits (including blatant vandalism) are marked as "very likely good" and "very likely good faith", so there is nothing to highlight. Any workaround? As result it is much harder to spot and fix vandalisms.--Jklamo (talk) 10:47, 10 November 2017 (UTC)

@Jklamo:It seems that the marks are developed alternative to "ORES".Thank you David (talk) 11:25, 10 November 2017 (UTC)
Thanks for reporting this, I'm checking and will fix it soon. Amir Sarabadani (WMDE) (talk) 11:40, 14 November 2017 (UTC)

Before the introduction of elastic search copypasting an item has easy. "Rightclick/Copy link" gives for example "https://www.wikidata.org/wiki/Q5010594". This could be easily pasted to select CFD-ACE+ (Q5010594). The switch in the search broke this feature and that makes certain workflows that need copypasting harder. ChristianKl (✉) 13:30, 12 November 2017 (UTC)

Hey :) That was fixed in phabricator:T179061. It is not deployed yet. I am not 100% sure if we deploy this week or next. Need to get up-to-speed again after vacation. --Lydia Pintscher (WMDE) (talk) 15:13, 13 November 2017 (UTC)

Property and values confused

Filter 101 proofed fairly efficient. In the meantime, it captures frequently edits that try to edit a property instead of its value on some item [1][2]. Maybe there are ways to improve this reoccurring problem.
--- Jura 09:02, 10 November 2017 (UTC)

Ufff. Yeah. If anyone has ideas how to make this less likely to happen please let me know. --Lydia Pintscher (WMDE) (talk) 15:15, 13 November 2017 (UTC)
I tried adding an explanation on MediaWiki:Abusefilter-warning-101, but some users don't seem to find the item they came from.
--- Jura 22:05, 15 November 2017 (UTC)

Parameter: Medical specialty (P1995)

Topic moved in Wikidata:Project chat. --ValterVB (talk) 20:19, 16 November 2017 (UTC)

Articles not searchable

Tracked in Phabricator
Task T179815

Now that Harej et al. built us such a nice article database, I just noticed that we can't actually search it by author. Author strings are not indexed. Could you do something about it?
--- Jura 22:45, 5 November 2017 (UTC)

Hello Jura, this type of search would require to search in the labels of the value of a statement, and it's not planned so far. You can search by creating a list with the Query Service, and then search inside the results. Lea Lacroix (WMDE) (talk) 09:41, 6 November 2017 (UTC)
I think it is or was planned and is being done for P31/P279. Could you investigate and prioritize it, because I don't think query service is suitable for string search and the large amount of items this concerns make it more important. The property that needs to be added to the search index is author name string (P2093).
--- Jura 09:50, 6 November 2017 (UTC)
what's the progress on this?
--- Jura 19:36, 21 November 2017 (UTC)

hif.wiktionary

Now Fiji Hindi Wiktionary is active, but is not possible to add links to Wikidata or connect with another language... JAn Dudík (talk) 21:19, 15 November 2017 (UTC)

@aude: Can you have a look please? --Lydia Pintscher (WMDE) (talk) 19:34, 21 November 2017 (UTC)

Paste QID no longer working

Tracked in Phabricator
Task T179061

I used to be able to paste full URLs (e.g. "https://www.wikidata.org/wiki/Special:EntityPage/Q18709313" or "https://www.wikidata.org/wiki/Q18709313" instead of just "Q18709313") as values for properties with item propertytype. Some time ago, this stopped working. What happened? Could it be fixed?
--- Jura 08:06, 8 November 2017 (UTC)

It is being. Matěj Suchánek (talk) 08:33, 8 November 2017 (UTC)
Good to see. Still, the ticket is closed but it doesn't work yet. I think it would be preferable if things were checked and ensured to be working on the live site before a bug is closed.
--- Jura 09:02, 10 November 2017 (UTC)
I think it's still not working.
--- Jura 19:37, 21 November 2017 (UTC)
Yes because unfortunately the deployment last week ran into unrelated issues and this week there are no deployments because of thanksgiving. So it looks like it will go live next week only. Sorry about the delay :/ --Lydia Pintscher (WMDE) (talk) 19:43, 21 November 2017 (UTC)
It works again. Thx for fixing it.
--- Jura 15:35, 22 November 2017 (UTC)


Get diff between two revisions in a parseable format?

Is there a way to get the diff between two revisions in a format that is NOT html? For example using this API call: https://www.wikidata.org/w/api.php?action=compare&fromrev=596908112&torev=576008574&format=json, I'd like to get the content of the '*' field in a json format or similar. Is this possible? Thank you Gstupp (talk) 00:35, 23 November 2017 (UTC)

No that's not possible currently. --Lydia Pintscher (WMDE) (talk) 10:00, 23 November 2017 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2017/11&oldid=609959251"