Wikidata

Wikidata:Contact the development team/Archive/2013/08

< Wikidata:Contact the development team‎ | Archive‎ | 2013
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Any chance of getting a response from the development team?

Nearly a month ago I asked three questions on this page. Is there any chance of getting a response from the development team to any of these before they get archived? Even a 'don't know' would be helpful. Filceolaire (talk) 14:31, 3 August 2013 (UTC)

Sorry. I'll get you responses as soon as I can. But currently I am traveling and so are many others on the team. I hope to get everything here next week. --Lydia Pintscher (WMDE) (talk) 08:16, 4 August 2013 (UTC)
Thanks. Have a good Wikimania. Filceolaire (talk) 12:15, 5 August 2013 (UTC)

Multiling datatype and allowed languages

What set of languages will be possible to use with the multiling datatype? This is related to the Q about languages not supported by MediaWiki, for example some of the Sami-languages, like Lulesami. -- Lavallen (block) 08:50, 7 August 2013 (UTC)

This should be the same languages you can choose here on Wikidata when changing your language at the top of your page next to your username. --Lydia Pintscher (WMDE) (talk) 09:40, 7 August 2013 (UTC)
Ok! -- Lavallen (block) 10:41, 7 August 2013 (UTC)

{{NUMBEROFARTICLES}} gives too low count

Tracked in Bugzilla
Bug 52621

What is the {{NUMBEROFARTICLES}} magic word supposed to show? Now it gives the number 109,420,393, but the fresh database dump from 2013-07-27 contains 13,355,707 items. Why are more than 400,000 items not counted in {{NUMBEROFARTICLES}}? Byrial (talk) 16:43, 28 July 2013 (UTC)

They have most likely been deleted via RfD and other avenues.--Ymblanter (talk) 20:11, 28 July 2013 (UTC)
So 400,000 items was deleted since the dump started two days ago? No, I don't believe that. The item counter at Wikidata:Main Page is just more than 400,000 items too low. Byrial (talk) 20:45, 28 July 2013 (UTC)
13,355,707 as in items namespace?? As this may include translations and policy and other namespace pages.--Vyom25 (talk) 13:52, 1 August 2013 (UTC)
Yes, there is 13,355,707 pages in the item namespace, which all are items. This does not include other namespaces. Byrial (talk) 14:03, 1 August 2013 (UTC)
Is it possible that 12,993,990 are items with a link to wikipedia or wikivoyage? and difference are used in statements and without a link.--Vyom25 (talk) 12:52, 2 August 2013 (UTC)
I've reported it at bugzilla:52621. Thanks for bringing it up. --Lydia Pintscher (WMDE) (talk) 02:23, 8 August 2013 (UTC)

neuer Bug: Interwikis ändern (ohne JS!) und auch hinzufügen

Seit heute (oder gestern oder auch letzte Tage bereits), also recht aktuell und vorher nicht, bekommt man (ohne JS!) nicht mehr die richtigen Links zu den entsprechenden Spezialseiten, wenn man einen Interwikilink ändern will (bei den Aussagen funzt das Hinzufügen/Ändern ja ohne JS weiterhin gar nicht, das ist aber bereits bei Bugzilla bekannt, während es bei Bezeichnung und Beschreibung wie bisher auch richtig funzt). Bislang war es so, dass beim Klick auf „Bearbeiten“ eines Interwikis (hier im Beispiel dewiki und Q14337849) dieser richtige Link mit dem bereits eingetragenen Interwiki erschien: Special:SetSiteLink/q14337849/dewiki. Nun ist es aber neuerdings so, dass man stattdessen einen falschen Link bekommt: Special:SetSiteLink/q14337849/de-ch/dewiki, also je nach persönlichen Einstellungen, die ich auf de-ch gesetzt habe (vorher auch). Da hat sich also irgendwas geändert. Entsprechend sieht der Link bei Klick auf „Bearbeiten“ des enwiki-Interwikis so aus: Special:SetSiteLink/q14337849/de-ch/enwiki, neuerdings also immer mit diesem de-ch davor, sodass man beim Ändern des Interwikis nicht mehr sehen kann, welcher Link vorher eingetragen war, da das Feld entsprechend leer ist. Man muss also immer das „de-ch“ aus dem Feld „Websitekennung:“ entfernen und dann unten bei „Websitelink:“ den Interwiki neu eintragen, statt dass man den bereits dort vorher eingetragenen sehen kann.

Ähnlich ist es auch beim Hinzufügen neuer Links, wo man den Link Special:SetSiteLink/q14337849/de-ch erhält, also im Feld „Websitekennung:“ standardmäßig immer „de-ch“ eingetragen ist und zusätzlich oben in Rot diese Fehlermeldung erscheint:

  • „Die Websitekennung „de-ch“ ist unbekannt. Bitte verwende eine vorhandene Kennung, wie „dewiki“.“

Daran hatte ich mich ja bereits gewöhnt, da dies auch vorher schon so war, nur beim Ändern war es bisher richtig. Hat sich also statt verbessert nun verschlechtert. Zumindest aber bekommt man durch die Fehlermeldung direkt angezeigt, in welcher Form man das Feld abändern muss. Könnte man den Link unter „Bearbeiten“ zumindest wieder zurückändern, so wie es letzte Tage noch war? Das würde das Ändern von Interwikis wieder erleichtern. Und anschließend bitte auch den Link unter „Hinzufügen“ noch verbessern.

Beim Hinzufügen von Wikivoyage-Seiten ist es übrigens ähnlich, ebenfalls ein solcher Link Special:SetSiteLink/q14337849/de-ch und die zugehörige rote Fehlermeldung oben auf der Seite. Dort gibt es gerade keine existierenden Einträge, also keine Bearbeiten-Links. Mal sehen, anderes Beispiel mit Wikivoyage-Links, die Hauptseite: Q5296. Da gibt es zwar keine aktivierten Hinzufügen-Links, da Interwikis vollständig, dafür aber Bearbeiten-Links. Selbe Chose auch hier, beim Ändern des dewikivoyage-Links kommt Special:SetSiteLink/q5296/de-ch/dewikivoyage, beim en-Link Special:SetSiteLink/q5296/de-ch/enwikivoyage. Da sieht man also auch die existierenden Einträge beim Ändern nicht mehr. Bitte wieder zurückändern, danke. Und weiß jemand, was daran in den letzten Tagen verändert wurde? – Geitost diskusjon 14:14, 31 July 2013 (UTC)

Mit Fallback hängt das nicht zusammen, denn wenn ich die Einstellung von „de-ch“ in „de“ ändere, bekomme ich stattdessen alle Links mit „de“ statt „de-ch“, also z. B. Special:SetSiteLink/q14337849/de/dewiki. Hilft also auch nix. – Geitost diskusjon 14:21, 31 July 2013 (UTC)

Zur zeitlichen Einordnung: Am 18.07. hatte ich jedenfalls per Klick auf „Bearbeiten“ noch den richtigen Link erhalten, um einen Interwikilink entfernen zu können. Und ist die ‎automatisch erzeugte Zusammenfassung „Fügte einen Link zu [enwiki] hinzu:“ beim Ändern eines Interwikis nicht auch missverständlich bzw. irreführend? Sollte es nicht besser heißen: „Link zu [dewiki] geändert“ analog zu „Link zu [dewiki] entfernt“ beim Entfernen und analog zu „Bezeichnung für [de] geändert:“ und „Beschreibung für [de] geändert:“ beim Ändern von Bezeichnung bzw. Beschreibung? – Geitost diskusjon 14:45, 31 July 2013 (UTC)

Urgh. Nicht gut. Ich habe es als bugzilla:52622 eingetragen. --Lydia Pintscher (WMDE) (talk) 02:28, 8 August 2013 (UTC)

Only some Wikivoyage links use https

Tracked in Bugzilla
Bug 52311

I always use a secure connection (https) when logging in to any Wikimedia site. After looking at some items that have Wikivoyage links, I realized that not all Wikivoyage site links use https links. For example, in United States of America (Q30), here are the results:

Uses https (when using https on Wikidata)
  • de
  • en
  • fr
  • it
  • nl
  • ru
  • sv
Uses only http (regardless of using https on Wikidata)
  • es
  • he
  • pl
  • pt
  • ro
  • uk

The Wikivoyages that only use http links seem consistent among other random items; it does not seem random. Does anyone know why this is the case? The Anonymouse (talk) 05:30, 31 July 2013 (UTC)

I created a bug report for this issue on Bugzilla. The Anonymouse (talk) 05:48, 31 July 2013 (UTC)
As Denny said on the bug, "Weird, but confirmed." Rather odd issue! ·addshore· talk to me! 20:27, 10 August 2013 (UTC)

"Bytes after change" gives wrong number

Tracked in Bugzilla
Bug 37753

In this edit, when added a new link, it shows -623 (see history), when it should be positive sum. --Stryn (talk) 07:28, 1 August 2013 (UTC)

In the 2013-7-27 database dump Q465883 have 32 aliases for Persian (fa), but they only with 22 different values. Now it only was 22 aliases for fa. The edit may have caused the server to remove 10 aliases with repeated values, and that way reducing the size of the item. Byrial (talk) 12:02, 1 August 2013 (UTC)
I agree; but then, why hasn't the server avoided adding 10 duplicate aliases? --Ricordisamoa 02:04, 3 August 2013 (UTC)
New version of the server with better checks than before? Byrial (talk) 10:14, 3 August 2013 (UTC)
  --Ricordisamoa 12:44, 4 August 2013 (UTC)
Hey! I found quite a few small bugs in the aliases of wikidata, including being able to add blank aliases which would be stored in the database. As every character in the structure is counted as a byte in the change of the size of the page removing a blank alias can remove some bytes (as an example). Also currently if the internal structure ever changes this will currently be reflected in the change in bytes. There is a bug somewhere open tracking a change to 'more accurate page size changes'. ·addshore· talk to me! 16:49, 10 August 2013 (UTC)

HTML line break

Tracked in Bugzilla
Bug 52706

Here, the label containing <br/> is shown correctly in the edit summary and in the diff row, but it actually breaks the line in firstHeading.

All HTML tags should be properly escaped. --Ricordisamoa 01:59, 3 August 2013 (UTC)

There is about 663 labels with HTML line break codes. They should be changed, but of course the codes should also be escaped when present. Byrial (talk) 10:20, 3 August 2013 (UTC)
Can you publish a list of them, please? --Ricordisamoa 12:46, 4 August 2013 (UTC)
I have made this bug to track the issue! As far as I can tell this title still parses wikitext, which is why the linebreak gets parsed. This was fixed in other parts of the UI a few weeks ago but it seems no one has spotted this! ·addshore· talk to me! 17:05, 10 August 2013 (UTC)

Multilingual datatype

In a Wikidata:Project chat discussion Lydia asked about use cases for the Multilingual text datatype.

Since then three use cases have come up:

It has occurred to me that, instead of creating the multilingual datatype for these cases we could, instead, create a wikidata item for each picture on Commons and import the file metadata (including licensing, categories etc.) from Commons to wikidata. The Label or the Description for the item could be used for the Description, Caption and ALT text for that picture.

Could we use the 'Q' namespace for these or should we have a new 'F' namespace for commons files? Filceolaire (talk) 22:38, 3 August 2013 (UTC)

Another proposed use case: IUPAC name. Personally I think this could use string datatype with language qualifier. Filceolaire (talk) 12:19, 5 August 2013 (UTC)
Another proposed use case: Comment property. This one really does need the multilingual text datatype. Filceolaire (talk) 12:29, 6 August 2013 (UTC)
This one basically implements the 'annotations' property which seems to have been promised in Help:Statements#Qualifiers for a long time. Filceolaire (talk) 23:30, 8 August 2013 (UTC)

labels in P_talk and Q_talk

Tracked in Bugzilla
Bug 52672

In Special:RC and Watchlist I see the label of a property, instead of the number if there has been edits in the P- and Q-namespace. But if there has been edits in the corresponding talk-page, I only see a number, a number I do not always recognise. Would it be possible to see the label also for the talk-namespaces? -- Lavallentalk(block) 06:50, 9 August 2013 (UTC)

I don't know if there are any technical issues preventing it but I've filed it as bugzilla:52672. Let's see :) --Lydia Pintscher (WMDE) (talk) 16:10, 9 August 2013 (UTC)
Seems like a great idea! ·addshore· talk to me! 17:06, 10 August 2013 (UTC)

"Add links" resulting in orphaned items

Lydia, in an admin board discussion, we have identified a serious problem. When someone on a Wikipedia pushes "Add links", in cases when this results in merging two Wikidata items, there are several problems: Labels and statements are not moved, and the orphaned item is not deleted – and there are thousands of such cases.

We think a solution is to add the orphaned item automatically to RfD, with a generated text along the lines of Merged by [[User:Xxx]] from [[xxwiki]] to item [[Q12345]]. Hopefully it's just a small tweak, and can be done easily?

Thanks, Littledogboy (talk) 12:22, 9 August 2013 (UTC)

I'll ask Marius who developed it to have a look and comment. --Lydia Pintscher (WMDE) (talk) 16:12, 9 August 2013 (UTC)
As I'm in the Hong Kong for the Wikimania right now I sadly don't have the time to write up a big and complete reply, but I think I've already answered most of this here. I can of course answer further questions, if needed. Cheers, Hoo man (talk) 02:35, 10 August 2013 (UTC)
Don't worry about doing it right now, but the short answer seems to be: Nothing can be done?! Littledogboy (talk) 09:10, 10 August 2013 (UTC)

Well that's not true, the short answer is: Not now, but of course we know about the problem and will fix it as soon as the underlying functionality which we need exists. - Hoo man (talk) 10:50, 10 August 2013 (UTC)

Український переклад інтерфейсу Wikidata

Дуже перепрошую, що пишу тут українською, але іншими мовами я володію гірше. Однак, відсутність завершеного українського інтерфейсу створює для мене такі ж незручності, як і моя українська писанина тут для тих, хто ще не оволодів українською мовою на достатньому рівні. Український переклад, звісно, є, але він незавершений. Зокрема, проблему я бачу в формах, заповнених англійською й чомусь російською мовою, що може створювати незручності для тих, хто погано знає ці мови — а отже, й вести до помилок, інструкція до виправлення яких, знову ж, далеко не завжди доступна українською мовою. Отже, питання: Коли нарешті інтерфейс Wikidata буде повністю українізовано? За чим затримка? Чи можуть до цього перекладу, при бажанні, долучитися всі, хто володіє на достатньому рівні українською й іноземними мовми? З повагою, P.Y.Python (talk) 11:52, 10 August 2013 (UTC)

https://translatewiki.net/ Littledogboy (talk) 14:42, 10 August 2013 (UTC)

Important probleme since 2 weeks

Since 2 weeks as long as I am logged in I cannot add any new interwiki link in wikidata, but all other modifications are workin. As soon as I am logged out the adding is possible without any problem! This is really a very strange bug! With best regards/Ek de du semajnoj mi, kiam mi estas ensalutinta, ne povas aldoni ligilon al nove kreita artikolo en alia lingvo. Simple kiam oni selektas "aldoni" aperas kampo por la lingvo sed ne kampo por la aldonajxo. Se mi elsalutas kaj anonime faras la redakton, tio tamen tute bone funkcias. Tio estas absoluta strangajxo. Cxiuj aliaj modifoj cetere eblas tute senprobleme. Sxajnas, ke aperis iu tre stranga eraro en la softvaro! DidiWeidmann (talk) 19:03, 5 August 2013 (UTC)

I have the same problem. Clicking on 'Add' there is only one box, for the language. There is no box for the name of the link. Everything goes ok when I log out (then there are two boxes). Hobbema (talk) 23:35, 5 August 2013 (UTC)
I think that your talking abou this (with solution): Wikidata:Project_chat/Archive/2013/07#.22edit.22_instead_of_.22save_.2F_cancel.22. Is anybody tracking this in bugzilla yet? --Tobias1984 (talk) 07:20, 7 August 2013 (UTC)
No I don't think this is in bugzilla yet. Can someone add it please? (Sorry, network connection is pretty bad at the moment otherwise I'd do it.) Also has anyone been able to figure out which setting is responsible for this? Is it some gadget or some other setting? --Lydia Pintscher (WMDE) (talk) 09:37, 7 August 2013 (UTC)
If I want to add a page, I see also only the box for the language and not the box for the name of the page. --SteEis. (talk) 12:37, 7 August 2013 (UTC)
In my case the problem is still going on! In the meantime almost the field for the modification reappears, but it doesnot help as the modification cannot be saved as long as I am logged in. As soon as I am logged out the modification can be saved! The problem still needs to be resolved. I do not know how many user are affected by this same problem, but I am not the only one!DidiWeidmann (talk) 16:46, 7 August 2013 (UTC)

So I talked about this with Denny and he's seen a few people with this problem as well on IRC. In all cases it was some gadget they had enabled but it is not clear which one. Could you please try to disable your gadgets one-by-one and see which one of them is the offender so we can try to fix this for everyone? --Lydia Pintscher (WMDE) (talk) 03:24, 8 August 2013 (UTC)

And what is a "gadget" and how can I disable them?DidiWeidmann (talk) 18:00, 10 August 2013 (UTC)
Preferences (which should be linked to in the top right somewhere), Then select the 'Gadgets' tab! Everything ticked is enabled! Although If you haven't added or enabled any extra gadgets this may not be your problem! ·addshore· talk to me! 20:25, 10 August 2013 (UTC)
Thanks for the answer: There are practically no gadgets activated on my account! This is evidently not the reason! The bug is important - as the connection of a articles to other language versions is the most important feature of Wikidata - If that does not work properly the the goal of the Wikidata-project is missed! So I hope that the problem will be resolved soon! It is just absurd that I have to log out to make the most important edits as it is the case now! It is as if you by a mobile phone and you can do every thing with it (films, photos, games) but not make as simple phone call!DidiWeidmann (talk) 20:52, 11 August 2013 (UTC)
"There are practically no gadgets enabled on my account." Does this mean there are really none enabled or just a few? We understand this is important and we want to fix it but without knowing what is causing it this is really hard. So we really need to figure out which setting is the reason for this issue. --Lydia Pintscher (WMDE) (talk) 00:53, 12 August 2013 (UTC)
I unabled no all the remaining gadgets - without any result. This is definitively not the reason for the problem. The bug seems to be in context with the centralized logging as it appeared exactely with its introduction about 3 weeks ago! I remember: Before this date it was necessary to loggin for Wikidata and for Commons separately. So this is the update where the bug is to be verified! I repeat, the problem desapears afet logout and reappears after loggin! And as the different comments show I am not the only one with this problem.DidiWeidmann (talk) 21:31, 12 August 2013 (UTC)
Please try clearing your browser cache after disabling all widgets. Also it would be great if you could take a screenshot of the problem so that we can see it as we can't reproduce it! ·addshore· talk to me! 09:21, 13 August 2013 (UTC)

The problem seems to be resolved - in any case the redaction now works again properly. Thanks to that person who solved it.DidiWeidmann (talk) 19:03, 21 August 2013 (UTC)

Tyvan Wikipedia

The Tyvan Wikipedia is now live, tyv.wikipedia.org. --Rschen7754 04:34, 11 August 2013 (UTC)

And according to bugzilla:49432 it's already enabled here as well :) --Lydia Pintscher (WMDE) (talk) 09:48, 11 August 2013 (UTC)
It does. I guess this is the first link. Byrial (talk) 11:02, 11 August 2013 (UTC)
Indeed :) ·addshore· talk to me! 15:09, 11 August 2013 (UTC)
Hope you're firing up your bot :D --Rschen7754 15:45, 11 August 2013 (UTC)
It must wait until the next full set of db dumps :) ·addshore· talk to me! 18:16, 11 August 2013 (UTC)

Vietnamese Wikivoyage

On the same note, Vietnamese Wikivoyage has also recently been added to the system. I hope that links from there can be added to Wikidata as smoothly as possible, and hopefully without the thousands of duplicates that the WYImporterBot left us with :( Del♉sion23 (talk) 19:35, 13 August 2013 (UTC)

Heh! I actually have written a little script which can merge such duplicates (to a degree) ·addshore· talk to me! 20:56, 13 August 2013 (UTC)
Wow, that would be really useful :) I look forward to seeing it! Del♉sion23 (talk) 23:41, 13 August 2013 (UTC)

Subproperty relation

In the Wikidata:Requests_for_comment/How_to_classify_items:_lots_of_specific_type_properties_or_a_few_generic_ones? RFC there was a suggestion that a 'subproperty' relation could be used to link property instance of (P31) with all of the specialised properties which could be seen as synonyms for this. This would mean that you could query 'P31 plus subproperties' and get all of these synonyms. This relation is apparently part of Semantic Mediawiki.

  1. Could this be developed as part of the stage 3 Query development?
  2. Is it a problem that we have properties such as P132 (P132) and vessel class (P289) instead of using instance of (P31) throughout? Does it make queries more difficult?
  3. Would a 'Subproperty' relation fix this problem?

--Filceolaire (talk) 16:13, 12 July 2013 (UTC)

While I think support for declaring subproperties per rdfs:subPropertyOf would be useful, I'm not aware of any examples on the Semantic Web of a project that supports subproperties for rdf:type and rdfs:subClassOf (which are the basis of instance of (P31) and subclass of (P279)). Saying that 'wife' and 'husband' are subproperties of 'spouse' as in the linked SMW documentation seems categorically different than saying vessel class (P289) is a subproperty of instance of (P31).
I think this nascent feature request would benefit from examples of other Semantic Web projects supporting hyponyms of 'instance of' or 'subclass of' via subproperties. Or, if such examples don't exist, is this kind of thing supported in theory by RDFS, OWL or the querying specification SPARQL? Emw (talk) 11:50, 13 July 2013 (UTC)
Before I request this feature I would like to get a feel for whether it is useful or practical. That is why I asked the three questions above. Could a developer who will be working on Queries try to answer these questions? Filceolaire (talk) 01:32, 27 July 2013 (UTC)
Would you be requesting the ability to make subproperties of instance of (P31) and subclass of (P279) -- i.e., rdf:type and rdfs:subClassOf? If so, can you point to any examples of this being done on other ontologies that use RDFS or OWL? I'm not aware of any. Without such examples, or some explanation for how Wikidata's vocabulary is sui generis among those in the Semantic Web, I'm inclined to think it would not be useful to develop support for subproperties of P31 and P279.
That said, I think W3C-compliant support for subproperties -- i.e., support for rdfs:subPropertyOf -- would be very useful. Emw (talk) 12:31, 27 July 2013 (UTC)
In the RFC referenced above TomT0m provided a link to the implementation of this property in SMW. Filceolaire (talk) 14:50, 27 July 2013 (UTC)
Right, and as noted above the implementation of subproperty relations in Semantic MediaWiki doesn't seem to support creating subproperties of P31 (rdf:type) and P279 (rdfs:subClassOf). Your original comment seems to suggest we should. Is my interpretation of your request incorrect? If not, can you point to any specific examples of a "subproperty of" feature enabling subproperties of "instance of" and "subclass of"? Emw (talk) 02:22, 29 July 2013 (UTC)
No I can't. That is why I asked the three specific questions above before I proposed this feature via bugzilla. I am very disappointed that I haven't had a response to any of these three questions from the development team. Filceolaire (talk) 14:28, 3 August 2013 (UTC)

SO I just talked this through with Denny and the answer is: It's not off the table but it will definitely not happen anytime soon as it's complicated and other things are more pressing. --Lydia Pintscher (WMDE) (talk) 02:20, 8 August 2013 (UTC)

Thanks Lydia (and Denny)! Emw (talk) 02:36, 8 August 2013 (UTC)
OK. That answers question 1.
Now for question 2 above. Could you get someone who knows about queries to tell us if having various properties which are synonyms of each other will be a problem?
Then there is question 3 above. Filceolaire (talk) 23:16, 8 August 2013 (UTC)
Well it depends on what kind of queries you have really. If you want to query for the whole thing then it is of course easier to query for something that includes everything. If you want to query for only a subset then it is of course easier to query for the thing that only holds the subset because you don't need to restrict it. Do you envision any other issues than the ease of formulating a query? --Lydia Pintscher (WMDE) (talk) 12:12, 14 August 2013 (UTC)
That answer doesn't really help much Lydia.
We have organised wikidata in a certain way. Some people have said this way does not comply with W3C recommendations and will create problems.
  • I would like an expert opinion on whether or not it will create problems.
  • If yes then what sort of problems it will create and whether the existence of a "SubProperty" relation will solve those problems.
  • I want to then use that expert advice to see if, where, how we need to change the way we organise wikidata.
Who is developing queries? Can they provide the users with the advice we need to make the decisions we need to make? Filceolaire (talk) 04:01, 15 August 2013 (UTC)
Can you please clarify what "it" is in your first point? Or point me to discussions where the potential problems are discussed? --Lydia Pintscher (WMDE) (talk) 16:15, 15 August 2013 (UTC)

Property inheritance

There have been two RFCs on property P107 (P107) and it has become clear as the discussions proceeded that the issue depends on the technical characteristics of the wikidata query mechanisms.

  • The advantage of having P107 (P107) in most items is that it makes it easy for a query to limit a search to a certain type of item.
  • The alternative is to use instance of (P31) to assign each individual instance (thing/object) to a class and then use subclass of (P279) to define a hierarchy of classes. This, apparently, is the way recommended in the W3C semantic web standards.

Using subclass of (P279) avoids duplicating information but it means that if you want to find out if something is an administrative territorial entity (Q56061) (for instance) then you have to follow the "subclass of" hierarchy up from the item and see if it links to administrative territorial entity (Q56061) eventually.

  1. Can the development team tell us if it is practical to do this search up the hierarchy?
  2. Can the development team tell us if it is planned to implement this functionality?

I would be very grateful if we could avoid all philosophical discussions of whether this should or should not be used on Wikidata. This section is purely about practicalities. Filceolaire (talk) 15:12, 3 August 2013 (UTC)

I'm not a developer, but as far as I can see, if a "search up the hierarchy" not will be possible in the future, then the use of Wikidata on Wikipedia and other projects will be of very little value other than as a repository for interwiki. This not only for your example, but to extract any kind of data out of Wikidata. Bots can of course do a search, so also humans, but derived values can in that case never dynamicly be added to Wikipedia. For example: I would not be able to search for which state a town in USA is located inside, and I would not be able to know if X, who is married to Y, if it is a gay-marriage or not. And I would not be able to know in which country Z was born or died. -- Lavallen (block) 05:52, 4 August 2013 (UTC)
This could be done using en:Lua and mw:Extension:Scribunto when we will be able to access any items in a Wikipedia page. TomT0m (talk) 12:56, 5 August 2013 (UTC)
As I wrote above already subproperties will not be possible anytime soon. I hope that helps making the needed decisions. --Lydia Pintscher (WMDE) (talk) 02:30, 8 August 2013 (UTC)
I'm afraid that is not what I asked here. Could you get someone who knows about queries to have a look at this and confirm that the way we are doing hierarchies will not be a problem for queries. If they don't understand what I am asking then feel free to ask for more info. Filceolaire (talk) 23:23, 8 August 2013 (UTC)
Tracked in Bugzilla
Bug 50911
This question is ultimately about whether Wikidata will support transitive properties. Denny has spoken to this:
Basically, you are looking for Wikidata to calculate the transitive closure of a property. This kind of reasoning is likely to be very much requested, and we have to figure out if and how we can deal with it, but it not likely to happen to soon: we first need to get the basics -- i.e. queries against the explicit statements -- working and understand their implication on the infrastructure, before we can seriously start working on supporting features like transitivity
—denny, Wikidata query development talk page -- Transitive properties
Ticket 50911 tracks this. Note that this is not support for subproperties per se; it's support for transitive deductions for queries involving special properties like instance of (P31) (i.e. rdf:type) and subclass of (P279) (i.e. rdfs:subClassOf), and other properties a la owl:TransitiveProperty. Emw (talk) 00:11, 9 August 2013 (UTC)
Without transitive properties the Template:Infobox_settlement won't work. This allows for 4 levels of administrative subdivision and we have only got one level in the current wikidata data model. There are a number of ways of getting round this but we will need input from the development team to figure out what is best. Filceolaire (talk) 00:42, 9 August 2013 (UTC)
Tracked in Bugzilla
Bug 47930
Support for transitive properties in client wikis -- which would enable the kind of thing you're talking about with Template:Infobox_settlement -- would be enabled by making it possible to access data from an item not connected to the current page. That's being tracked in ticket 47930. I would recommend that anyone wanting to get these features implemented sign up for a Bugzilla account and vote for ticket 47930 and ticket 50911 (in the 'Importance' section). Emw (talk) 01:48, 9 August 2013 (UTC)
Jep. What Emw says. Thanks Emw :) --Lydia Pintscher (WMDE) (talk) 16:06, 9 August 2013 (UTC)
Thanks Lydia. To summarise my understanding of your reply:
  • Although Wikidata may have the information needed by an infobox we will not be able to use that info in an infobox unless it is on the page linked to that infobox page by a sitelink.
  • This will be fixed when bug 47930 is cleared.
  • You haven't given us any prediction of when bug 47930 will be cleared.
Is that right? Filceolaire (talk) 09:46, 15 August 2013 (UTC)
Correct. Access to data from arbitrary items is obviously important but the scalability issues involved are not trivial. We're working on it. --Lydia Pintscher (WMDE) (talk) 16:18, 15 August 2013 (UTC)

the mystery of the development team

I don't want attack anybody, but this site should be renamed "contact Lydia Pintcher". I really don't know who this mystery development team is and where they do their work. Lydia do a awesome job here, convey between the community and the developers. But if the development team really would participate in this site, there wouldn't be any forwarding necessary at all. For nearly all questions here Lydia promise to check this up with the development team, but it seems sometimes even she didn't get any answer.

Generally I feel bad informed here. Like the most users/editors here, I'm very interested for new data types. But it's very hard to get any information. First they say, URL data type should be available at the latest of Wikimania (Wikidata:Project_chat/Archive/2013/06#Short_update_on_URL_datatype). Wikimania starts tomorrow and perhaps I'm wrong, but I don't think the URL is available tomorrow, since there isn't any URL data type on the test servers as far as I saw. (BTW: Yet another question which wasn't answered: Wikidata:Project_chat/Archive/2013/07#URL-Datatype_on_Test-Wikidata).

Even the roadmap didn't get any update ([[1]]): URL data type is still listed for July.

I'm sorry, but I feel like the developers doesn't much care about this community. They also didn't give any opinions on any RfC, some of them was very important and the technical appreciation of someone of the development team would help us much in some questions and problems. I accept the intention that the development team don't want interfere and let community make decisions about data modeling and so on, but I think we need some supporters of the development team which could tell as advantage or disadvantage of an option or the technical limits of a specific topic.

Again: Thanks to the work of Lydia and also many thanks to the work of the development itself, but the communication could be much better. --Nightwish62 (talk) 17:45, 6 August 2013 (UTC)

+1 Information should be available without having to ask questions + most questions are directly forwarded to the dustbin anyway = bad, bad communication. Ljubinka (discussion) 07:23, 7 August 2013 (UTC)
Let's please cool down a bit. You are seeing me here and not much of the other development team members because this is exactly my job. They should be spending time on writing code and I am here to make this possible. This is very much in all of your interest ;-) If you want to know who is currently on the development team then please check here under Wikidata: https://www.wikimedia.de/wiki/Mitarbeiter
As for information about datatypes: I just talked to Daniel and he said it is mostly ready and will be in the next deployment or the one after that unless he finds more issues.
As for discussions: If you need input on particular discussions then please alert me to them and I will get you an answer (that might sometimes be "we won't influence the decision one way or another").
This development team is actually caring a lot about the community. And I think this is visible in many places over the last year and some. I understand you're frustrated today but let's please not blow it up to more than it is. --Lydia Pintscher (WMDE) (talk) 09:31, 7 August 2013 (UTC)
Could you please make a list of this "many places"? Not a detailed one with all references to all pages of course, but some overview of what they are would help a lot. Ljubinka (discussion) 11:48, 7 August 2013 (UTC)
I would really appreciate an answer. Ljubinka (discussion) 07:00, 14 August 2013 (UTC)
I was actually hoping we'd be a project where we do not need to play games like this. But fine. Basically everything of importance that the team has done has gone through extensive discussions. This started with the proposal for the project itself. The latest large discussions are the proposals for Wiktionary and Commons. All of them have a large amount of comments from the development team to adapt it come to a point where most people are happy with the proposal. I'm considering this topic closed now. Let's move on to actually moving Wikidata forward ;-) --Lydia Pintscher (WMDE) (talk) 12:09, 14 August 2013 (UTC)
Just wondering: Are they fulltime employee for Wikidata or doing they the work beside a 'regular' job in their leisure? --Nightwish62 (talk) 10:06, 15 August 2013 (UTC)
It's a mix of full and part time. --Lydia Pintscher (WMDE) (talk) 16:19, 15 August 2013 (UTC)

Max dimension

There are some limits to the dimension of a page or to the number of properties for one page? If yes, how is better split a page? --ValterVB (talk) 12:42, 14 August 2013 (UTC)

It'll probably become too slow at some point if a page has too many properties. There's no hard-coded limit however. If you find pages that are especially slow compared to others please let me know. So far this doesn't seem to be a huge issue but in the future we'll need to optimize. --Lydia Pintscher (WMDE) (talk) 12:50, 14 August 2013 (UTC)
First items of Special:LongPages start to be slow, so maybe is better thinking about it. For developers side, is better to create something of specific or simlpy we create item List of xxxxx (ex. list of administrative division of Turin) and add it to the property (contains the administrative territorial entity (P150) in this example)? --ValterVB (talk) 07:35, 15 August 2013 (UTC)
P150 has the merit of being symmetric. The lists of officeholders (e.g. on Q30) might be better elsewhere. In both cases, support for queries and other interface enhancements might make it easier to convince people that they can get the equivalent differently. --  Docu  at 09:59, 15 August 2013 (UTC)
'contains the administrative territorial entity (P150)' should only be used to link to items which are instances of administrative territorial entity (Q56061) or subclasses of this. It should not link to lists.
The easiest way round this problem is not to use 'contains the administrative territorial entity (P150)'. Use 'located in the administrative territorial entity (P131)' instead, on the page for the smaller unit. If you only use it to link to the next largest unit then in most cases you will only have it once on a page and we will still capture all the information.
Similarily use 'position held (P39)' on the page for each president rather than listing them all on United States of America (Q30). That way you capture all the information without having hundreds of links on a page. We do need to have a link to President of the United States (Q11696) from United States of America (Q30) so you have a trail back to all the officeholders (since position held (P39) links to President of the United States (Q11696) not to United States of America (Q30)). Filceolaire (talk) 15:47, 15 August 2013 (UTC)
Maybe wrong page for the subject, but how would it work if not all 'chief of states of USA' are 'Presidents of USA'? For example is the 'king/queen of Sweden' chief of state in Sweden, but you also have to add a few other titles to that list like the regent (Q477406) of Sweden. But not all regent (Q477406) of Sweden have been chief of state. For example in the 1980's we had one, who is not counted in the list of chief of states. -- Lavallentalk(block) 15:57, 15 August 2013 (UTC)
That's why I said you need a link from United States of America (Q30) to President of the United States (Q11696) and as appropriate for other countries. I'm not sure what the property making this link should be called. 'head of state - official title'? Filceolaire (talk) 16:56, 15 August 2013 (UTC)
And here we back to my second question: we can do as we like or is better that developers say wich is the best soluion? --ValterVB (talk) 18:05, 15 August 2013 (UTC)

Number datatype

Is there any way one could get some details on how the number datatype will look like? I would like to know:

  • If there will be 2 datatypes one for number and one for number + physical unit?
  • Will non-SI units be accepted when entered. Will they be converted to SI? Will there be an option to switch between non-SI and SI units for displaying? Will there be an indicator that a value was entered in non-SI units because that could indicate that it is not really a primary source?
  • How will the margin of error be included with the measurement? Can it be entered relative or absolute? Will there be an option to say it is sigma-1, sigma-2... ? Sometimes the margin of error is asymmetrical. How will this be entered?
  • Does the property creator decide on what kind of physical units that are allowed (e.g. a property could be limited to volumes and another could be limited to length measurements?)
  • Apart from the 7 SI units, how many derived units will be supported. E.g. mol/litre, µg/g (commonly called 'weight/mass part per million'), ml/l (The units cancel out but it is the only way to distinguish weight-% from volume-%, etc...).
  • Will there be a way to enter e.g. the value for the gas constant once and then convert it to other units (How many properties do we need to store all the values of the en:Gas_constant? Ideally a dropdown menu couls say "display the value with other physical units" which would allow the user to switch from J/(molK) to m³Pa/(molK)). --Tobias1984 (talk) 11:02, 15 August 2013 (UTC)
Last I checked we've not made final decisions on those questions. I'll try to find out the current state but it'll take a bit. --Lydia Pintscher (WMDE) (talk) 16:24, 15 August 2013 (UTC)

Other comments

I am not involved in the development of the datatypes but I propose clearly to forget about SI units for the unit parameter. For the development team I can only give the advice to use a string parameter and users will have to format correctly their inputs according to a convention defined by the community.
Conversion have to be managed by lua code in the client side. Keep wikidata as simple as possible.
For the precision better keep the same system as for the time datatype. Something like "precision": 1 = absolute, 2 = percent, "before" (or minus) and "after" (or plus). But from a GUI point of view, in order to keep the interface simple, the best is to choose one solution. In that case the absolute mode is better because the significant digits can be defined according to the value stored in the DB. Snipre (talk) 12:19, 15 August 2013 (UTC)
I am not in the DEV-team either. But in the Coordinate-datatype is there a possibility to define what globe the coordinates are valid for. It isn't visible in the user interface, but you can choose an item about any planet, or theoretically any kind of globe. The default is naturally mother Earth. Linking to items about different units would be a good solution, and let the Lua do the calculations. -- Lavallentalk(block) 13:20, 15 August 2013 (UTC)
Ok, this solution is better: use of an item for the unit. This will avoid typing problems. But we need to create an GUI for this datatype. Snipre (talk) 13:32, 15 August 2013 (UTC)

API: wbremovequalifiers

Tracked in Bugzilla
Bug 50570

I am trying to use the function wbremovequalifiers and according to the API documentation (http://www.mediawiki.org/wiki/Extension:Wikibase/API or http://www.wikidata.org/w/api.php), we need to provide a hash tag for the qualifier but I don't find such parameter in the code of an item. Can someone give some explanations ? Thank you Snipre (talk) 12:03, 15 August 2013 (UTC)

MediaWiki:Robots.txt

The message doesn't seem to work. Lines there don't get added to the global list. --  Docu  at 15:44, 15 August 2013 (UTC)

http://wikidata.org/robots.txt has the lines there for me. But also the syntax highlighting tag. Those should probably be removed from the message? --Lydia Pintscher (WMDE) (talk) 16:26, 15 August 2013 (UTC)
Now I see it too. Maybe just a cache issue. The version on the talk page should fix the syntax tag. Would you update it? --  Docu  at 16:29, 15 August 2013 (UTC)
Cool. I shouldn't do the update with my rights. Can someone else do it please? --Lydia Pintscher (WMDE) (talk) 16:30, 15 August 2013 (UTC)

Century-precise dates in French

Hello,

When we have a date that is only precise to the century level (eg RandomRomanCitizen was born in the 1st century and dead in the 2nd), dates appear as "1. Century", "2. Century in French, it should be "1er siècle", "2e siècle" and so on. -Ash Crow (talk) 23:29, 15 August 2013 (UTC)

Please provide a link to an example so I can have a look at it in detail. --Lydia Pintscher (WMDE) (talk) 16:38, 16 August 2013 (UTC)
I can find 66 time values with precison = century in the latest database dump. Examples: Q25445 (137th c. BC), Q42887 1st c., Q72 (15th c., qualifier (takes very long time to load at my computer)) Q3204226 (18th c., qualifier), Q4503364 (16th c., source (mistake which should be corrected). Byrial (talk) 17:32, 16 August 2013 (UTC)

Property of a property

There is a proposal to create a property for formatter urls of properties as a replacement of the list on MediaWiki:Gadget-AuthorityControl.js. That would require unblock property pages to be able to enter properties. Is that possible? Desirable? --Micru (talk) 22:17, 17 August 2013 (UTC)

Or is there some other way to convert authority code IDs into urls which can be edited easily when some web site changes their url format? Do we need a special 'database ID' datatype? 23:00, 18 August 2013 (UTC)

What's wrong with the current gadget? --Lydia Pintscher (WMDE) (talk) 11:04, 19 August 2013 (UTC)
One problem is that it is not easily reached from the client. -- Lavallentalk(block) 11:35, 19 August 2013 (UTC)
Good point. Ok. I'll bring it up. --Lydia Pintscher (WMDE) (talk) 13:17, 19 August 2013 (UTC)
Relying on gadgets to get something usable is imho a short term answer, but I must admit having something so important as item merging as a gadget surprises me. Community can handle of course but due to the number of messages we get (at least one per week) on different discussion pages I wonder how many users just go away with a feeling I don't understand this project, it's way too complicated. Of course I understand that it's a way for the dev team to get contribution but it would be good to make this code more easily usable for everyone. TomT0m (talk) 13:12, 19 August 2013 (UTC)
Agreed. Merging needs to be in the core of the software and it is being worked on. But it takes time because it isn't trivial and working with the gadget for now. The question wasn't about the merge gadget hawever. --Lydia Pintscher (WMDE) (talk) 13:17, 19 August 2013 (UTC)
See the 'Change Request' on Wikidata:Property_proposal/Creative_work#Catalog_number_.2F_Numero_di_catalogo for a new idea for dealing with databases that could get round this problem. Filceolaire (talk) 21:20, 19 August 2013 (UTC)
Are people happy with this in general? This seems easier than the other way. --Lydia Pintscher (WMDE) (talk) 10:26, 21 August 2013 (UTC)
No idea if people are happy with this in general. It has only just been proposed and it could lead to the deletion of all of the (hundreds of) database properties. This will take a while to resolve - if it will even work. Filceolaire (talk) 11:43, 21 August 2013 (UTC)

URL property

Is this coming soon? Filceolaire (talk) 11:43, 21 August 2013 (UTC)

We're waiting for bugzilla:51621 to be merged. I really hope this will happen this week so we can deploy it next week but it is not in our hands in this case. --Lydia Pintscher (WMDE) (talk) 12:38, 21 August 2013 (UTC)
Thanks Lydia. Filceolaire (talk) 11:04, 23 August 2013 (UTC)

Century-precise dates in French

Hello,

When we have a date that is only precise to the century level (eg RandomRomanCitizen was born in the 1st century and dead in the 2nd), dates appear as "1. Century", "2. Century in French, it should be "1er siècle", "2e siècle" and so on. -Ash Crow (talk) 23:29, 15 August 2013 (UTC)

Please provide a link to an example so I can have a look at it in detail. --Lydia Pintscher (WMDE) (talk) 16:38, 16 August 2013 (UTC)
I can find 66 time values with precison = century in the latest database dump. Examples: Q25445 (137th c. BC), Q42887 1st c., Q72 (15th c., qualifier (takes very long time to load at my computer)) Q3204226 (18th c., qualifier), Q4503364 (16th c., source (mistake which should be corrected). Byrial (talk) 17:32, 16 August 2013 (UTC)

API: Problem with time datatype

Using a bot I tried to add a date for a death of a person. My source said 363 BCE. So I used this piece of code to add data: action=wbcreateclaim&entity=q711577&property=p570&snaktype=value&value=%7B%22time%22%3A%22-00000000363-01-01T00%3A00%3A00Z%22%2C%22timezone%22%3A0%2C%22before%22%3A0%2C%22after%22%3A0%2C%22precision%22%3A9%2C%22calendarmodel%22%3A%22http%3A%2F%2Fwww.wikidata.org%2Fentity%2FQ1985727%22%7D&baserevid=66583112&token=40fc117b916c0f640ee6b9201ca1c728%2B%5C. The result is here but the final display of the data gives 364 BCE. Can someone explain me why I don't have 363 BCE ? Thank you Snipre (talk) 16:04, 23 August 2013 (UTC)

I think I have read that the time-datatype have year 0, while it in real life does not exist. BCE-time therefor have to be recalculated. -- Lavallentalk(block) 07:10, 25 August 2013 (UTC)
Thanks for the info. Can you say me where you read this info ? Snipre (talk) 21:04, 25 August 2013 (UTC)
No, but try the pages about datatypes on meta. -- Lavallentalk(block) 13:08, 27 August 2013 (UTC)
m:Wikidata/Data model#Dates and times gives some details. The year 0 is 1 BCE, the numbers always represents Gregorian time ISO8601 etc etc.
Observe that astromical data are normally written in the same way as the datatype here. (I.E. there is a year 0 in astronomical calendars.) -- Lavallentalk(block) 14:06, 27 August 2013 (UTC)

wikispecies

Instead of wikitionary why you don't give priority at wikispecies is more simple add it, and project can be a good source for taxonomy Rippitippi (talk) 13:56, 24 August 2013 (UTC)

Heu, wikispecies doesn't need any particular development: it is already in deployment in Wikidata, see Wikidata:Taxonomy task force. Snipre (talk) 15:39, 24 August 2013 (UTC)
and where you can add link to wikispecie article?species is a wiki this is a database it's quite different Rippitippi (talk) 21:29, 24 August 2013 (UTC)
(I think Rippitippi is talking about actually linking items to WikiSpecies pages, while Snipre is talking about integrating taxon data in Wikidata statements.) The Anonymouse (talk) 06:54, 25 August 2013 (UTC)

For now, we could use MediaWiki:Gadget-AuthorityControl.js to link to WikiSpecies via taxon name (P225). I made a test script here — feel free to check it out. The Anonymouse (talk) 06:54, 25 August 2013 (UTC)

If the taxanomy of each specie is defined in wikidata we don't need abymore the connection to wikispecies. Snipre (talk) 14:54, 26 August 2013 (UTC)

No-one said we're not giving Wikispecies priority over Wiktionary ;-) Wikispecies will happen before Wiktionary. It's just that you read more about Wiktionary atm because it is a lot more work while Wikispecies is not. So yes. It will come as one of the next sister projects. --93.220.81.151 09:42, 26 August 2013 (UTC)

Thanks I presume you are Lydia Rippitippi (talk) 13:54, 26 August 2013 (UTC)
Yes that was me. Randomly getting logged out lately -.- --Lydia Pintscher (WMDE) (talk) 09:42, 27 August 2013 (UTC)

Zurück-Funktion im Browser führt auf alte Version

Tracked in Bugzilla
Bug 53466
  • Wenn ich ein Objekt bearbeite, beispielsweise Bezeichnung und Beschreibung eingebe, dieses speichere und dann einem Link folge, z.b. einer Eigenschaft oder einem Seitenlink, anschließend die "eine Seite zurück" Funktion im Browser bediene, komme ich nicht auf die Seite zurück, die ich bearbeitet habe, sondern auf eine frühere Version dieser Seite ohne die erfolgte Bearbeitung. Es wäre wünschenswert dass auf die letzte bearbeitete Version zurückgeführt würde. (Verwende XP und FF 23.0.1)
  • Desweiteren wenn man dann dieses Objekt weiter bearbeiten will, z. B. wenn ich irrtümlich eine Beschreibung nochmal eingebe, kommen unspezifische Fehlermeldungen, die ihre Ursache haben in dem Versionskonflikt zwischen alter und neuer Version. Es wäre wünschenswert, dass die Fehlermeldung deutlicher die Ursache benennen würde.

--Giftzwerg 88 (talk) 09:52, 25 August 2013 (UTC)

Schau ich mir an. Danke dir :) --Lydia Pintscher (WMDE) (talk) 10:04, 27 August 2013 (UTC)

Diff inconsistence

Tracked in Bugzilla
Bug 39189

This diff only changed a single character, but in the history it shows up as "(+20)". How is that possible? --Ricordisamoa 00:53, 26 August 2013 (UTC)

I've noticed this too with reverting - an edit can add 40, but rollbacking it only removes 20 (as a general example). Ajraddatz (Talk) 05:20, 26 August 2013 (UTC)
This is to do with internal structure changes and the way the data is actually stored. These changes are often not visible through the UI but the character count will indeed make them more obvious! ·addshore· talk to me! 08:18, 27 August 2013 (UTC)

Number datatype

Tracked in Bugzilla
Bug 52916

Archive bot send my inquiry to the archive. Just posting this so it doesn't get forgotten. Wikidata:Contact_the_development_team/Archive/2013/08#Number_datatype --Tobias1984 (talk) 12:35, 26 August 2013 (UTC)

Sorry. Those slipped through :( I've now added them to the bug that is tracking this. --Lydia Pintscher (WMDE) (talk) 10:07, 27 August 2013 (UTC)
This is a very exciting development, I hope that it is possible to select items both for the units and the precision type, but at the same time I am worried that such a mix of units will make queries difficult, especially if the conversion is done externally with scripts... --Micru (talk) 20:06, 27 August 2013 (UTC)

Phase 4

There are a number of different things which have been discussed - things that we could do with Wikidata once the current programme is complete.

Is there likely to be any consultation with the Wikidata users on the priorities for follow on activities?

For instance my priorities would be:

  1. Wikidataisation of the Wikipedia reference tools so new references to books and articles automatically create a wikidata item and a link to that item from Wikipedia.
  2. Edit in place tool so infoboxes in Wikipedia can be created or edited apparently in Wikipedia but in fact editing the wikidata info behind the infobox. This will need a tool to help the editor select the appropriate infobox template. Once selected it will present a preselected group of properties for the editor to assign values to.
  3. Extention of this tool so it can be used to create and edit infoboxes linked to wikidata items not linked to the current wikipedia page (e.g. infoboxes for 'Bonnie Parker' and 'Clyde Barrow' on the 'Bonnie and Clyde' page).
  4. Integration of books metadata from wikisource books and from wikibooks into wikidata. This should mostly follow from the work already done on book metadata in wikidata.
  5. Tool to create and edit Wikivoyage listing items integrated with wikidata. As these will use the wikidata Q items it should not require any great extention to the Wikidata software.
  6. Conversion of Commons data to semantic structured data and integration with wikidata. This will require a new entity type for files - F#####. There are some design issues to resolve with this - is the data stored in wikidata or in commons? If the data is stored in commons then will it still use the wikidata properties? Nevertheless it would seem that it should mostly be able to reuse the design solutions already in wikidata.
  7. Integration of Wiktionary with wikidata. There are a number of unresolved social and technical issues here: Many Wiktionarians are uncertain about how this would benefit them. How would this work technically? In view of this I would put this one off till we have done the easier tasks.

I am a bit worried that the development team seems focused on Wiktionary - the most difficult problem both socially and technically - rather than starting with the tools needed to enable us to actually use wikidata. Personally, I think items 1, 2 and 3 above are more urgent than 'Queries'.

I am making lots of assumptions as to how the technology works and what the developers are doing and planning. Have I completely misunderstood what you are planning? Filceolaire (talk) 10:46, 23 August 2013 (UTC)

We're always taking discussions and requests we see into account. There are a lot of stake-holders we have to take into account (all the individual Wikimedia projects for one) and we're trying to do this as best as possible and weighting everyone's interest. We're however still in the process of getting the basics done. So have not put any work into really planning the details of all of the stuff building on top of it. We have however already put some stuff into planning the larger parts (Commons and Wiktionary for example) of the work we want to do in the future as that's needed to discuss with donors and so on. As for your individual points:
  1. No concrete plan when/how at the moment but also not out of the question.
  2. Same.
  3. Access to data from arbitrary items is being worked on.
  4. Details need to be figured out. I guess it'll be similar to Commons once that is solved.
  5. Those are the same as templates on Wikipedia? Then same answer applies.
  6. Planned but a lot of work. The discussions are happening already. Proposal is public and all.
  7. Same.
As to your worry about focus: Wiktionary is simply the one thing that needs the most planning and discussion so we obviously have to start it now. That doesn't mean other things are not getting attention. In general the whole planning we are doing is very agile. It's not a long-term plan but deciding what is needed in short intervals so we can react to changes instead of having to stick to a strict plan made a year ago. Hope that clarifies it a little. --Lydia Pintscher (WMDE) (talk) 11:57, 23 August 2013 (UTC)
Nice list but what are the priorities ? Commons, Wikibooks, Wikisources and Wikitionary are not a priority because they need a lot of development. For import of source data, this can be done by bots but as bot operators prefer data imports to sources imports we have to wait until someone does the job. For wikidata use in wikipedia the key factor is the development of lua template for infoboxes. So for me this discussion has to take place on the project chat in order to find persons who can do the above tasks and to let the development team managing their priorities as function of the development difficulties and of their ressources. We only need 3 things from the development team: url datatype, number with unit datatype and possibility to retrieve data from different items in a wikipedia article. And by the time we can start to add sourced statements to items: there are really few collaborative actions in that field at the moment. Snipre (talk) 12:48, 23 August 2013 (UTC)
Thanks Lydia. Is there any way I can convince you that items 1, 2, 3 are urgent? These are needed (in my opinion) to bring the teams on Wikipedia and other projects to contribute to Wikidata and make it their own - make sure that all new infoboxes and references on Wikipedia are created in Wikidata at the same time. Filceolaire (talk) 03:16, 28 August 2013 (UTC)
Access to arbitrary items is already being worked on and considered high-priority. It's taking a while though because the caching and updating mechanisms involved are tricky at this scale. Other than that the next priority is the numbers datatype and querying. We need to get those done. --Lydia Pintscher (WMDE) (talk) 09:27, 28 August 2013 (UTC)

Open end-range for numbers

Looking in some statistics-reports. Things like: Population: 4720 <sex: male> can of course be added. So also Population: 384 <age-range: 40-44> But open ranges like Population: 131 <age-range: 85- > Any ideas how do describe that? -- Lavallentalk(block) 05:50, 25 August 2013 (UTC)

This can probably solved with a no-value there. --Lydia Pintscher (WMDE) (talk) 14:38, 28 August 2013 (UTC)
So the number datatype will allow numbers like Pi: 3,14151 from=3 to='novalue'
-- Lavallentalk(block) 17:32, 28 August 2013 (UTC)

incr/wikidatawiki/20130824/ failed

Tracked in Bugzilla
Bug 53392

Please see http://dumps.wikimedia.org/other/incr/wikidatawiki/20130824/ --  Docu  at 21:19, 25 August 2013 (UTC)

And http://dumps.wikimedia.org/other/incr/wikidatawiki/20130825/ :-( — Ivan A. Krestinin (talk) 22:20, 25 August 2013 (UTC)
Thanks for the poke. I'll see what I can find out. --93.220.81.151 09:49, 26 August 2013 (UTC)

Same might have happened today: http://dumps.wikimedia.org/other/incr/wikidatawiki/20130826/ and Ivan can't update the constraint reports. --  Docu  at 22:21, 26 August 2013 (UTC)

And likely the same today http://dumps.wikimedia.org/other/incr/wikidatawiki/20130827/ ·addshore· talk to me! 08:26, 27 August 2013 (UTC)
Normally it finished around 20:00 GMT only. --  Docu  at 16:50, 27 August 2013 (UTC)
Today's was created. Hopefully it didn't skip three days. --  Docu  at 20:58, 27 August 2013 (UTC)
The missing days have been rerun. You can tell which revisions are covered by checking the max revid text file in the given day's directory and in the previous day's directory (or the most recent earlier directory that has such a file). The run from the 27th only contains revisions from 66883214 through 67099529, as it should. See the bug... -- 2A02:214D:8200:7900:21A:80FF:FED7:4F75 20:53, 28 August 2013 (UTC)

Century-precise dates in French

Hello,

When we have a date that is only precise to the century level (eg RandomRomanCitizen was born in the 1st century and dead in the 2nd), dates appear as "1. Century", "2. Century in French, it should be "1er siècle", "2e siècle" and so on. -Ash Crow (talk) 23:29, 15 August 2013 (UTC)

Please provide a link to an example so I can have a look at it in detail. --Lydia Pintscher (WMDE) (talk) 16:38, 16 August 2013 (UTC)
I can find 66 time values with precison = century in the latest database dump. Examples: Q25445 (137th c. BC), Q42887 1st c., Q72 (15th c., qualifier (takes very long time to load at my computer)) Q3204226 (18th c., qualifier), Q4503364 (16th c., source (mistake which should be corrected). Byrial (talk) 17:32, 16 August 2013 (UTC)

Please do not send that to the archive. Ljubinka (discuter) 19:07, 31 August 2013 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2013/08&oldid=1102549160"