Wikidata:Project chat

From Wikidata
Jump to: navigation, search
Shortcut: WD:PC
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Requests for deletions and mergers can be made here.
IRC channel: #wikimedia-wikidata <IRC-connect>
 Start a new discussion
Edit
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at June.


Administrators'
noticeboard

Translators'
noticeboard

Bureaucrats'
noticeboard

Requests
for permissions

Requests
for deletions

Properties
for deletion

Requests
for comment

Project
chat


Contents

Trademark discussion[edit]

Hi, apologies for posting this in English, but I wanted to alert your community to a discussion on Meta about potential changes to the Wikimedia Trademark Policy. Please translate this statement if you can. We hope that you will all participate in the discussion; we also welcome translations of the legal team’s statement into as many languages as possible and encourage you to voice your thoughts there. Please see the Trademark practices discussion (on Meta-Wiki) for more information. Thank you! --Mdennis (WMF) (talk)

UnconnectedPages and touch.py[edit]

There is a client side special page (examples w:en:Special:UnconnectedPages [not fixed], w:no:Special:UnconnectedPages [fixed]) that lists all pages without correct setup of the article-item relation. This page also lists a lot of spurious pages due to how the relation was created earlier. To fix this bot operators can run the script touch.py (part of pywikipediabot) for all pages at the project. It should be noted that only one bot should be used for this as it will trigger a rerendring of the page, which is a slightly heavy operation and when a lot of pages are rerendered it creates a fairly big load on the client servers. So please do run touch.py, but only one per project. After this is done only the unconnected pages should remain in the list. Most of them will be without langlinks, but some will have weird colliding langlinks. Jeblad (talk) 11:40, 4 June 2013 (UTC)

It works! --Ricordisamoa 13:44, 4 June 2013 (UTC)
Jeblad, did you only implement the special page and not the corrosponding api part? If the api part is implemented it's just another api call and you don't have to rerender all the pages on a Wikipedia..... bug Multichill (talk) 15:50, 4 June 2013 (UTC)
Ok, just did some queries (SELECT COUNT(page_title) FROM page LEFT JOIN page_props ON page_id=pp_page AND pp_propname = 'wikibase_item' WHERE page_namespace=0 AND page_is_redirect=0 AND pp_propname IS NULL ORDER BY page_title ASC ;). At nlwiki it's 325830 out of 1.574.030 and enwiki it's 430084 out of 4,248,565. That's a lot of pages to touch. Maybe better to do this serverside? Run the query once and submit the pages (slowly) to the jobqueue for invalidation? Multichill (talk) 16:09, 4 June 2013 (UTC)
@Multichill first part make sort of sense (yes a special page can be made into an API call), but last part doesn't (always touch the page? ..eh?). I didn't put any effort into making this callable through the API. Perhaps its a good idea, I don't know. A lot of the articles do not have registered page properties even if they do have associated items, and thats the reason why they are listed now, not because the item relation is missing. That is a fault that can be easily rectified by a nulledit. This is not something that shall not be done in the future, it is so because we didn't do it like that when we started and it will take months before all articles are updated. It does not make sense to touch articles from the special page itself, the special page simply report a state for the article and this state is now wrong for a lot of pages. Jeblad (talk) 16:17, 4 June 2013 (UTC)
I am happy to purge everything with 'forcelinkupdate' (which seems to do the job) if it is really needed? ·addshore· talk to me! 18:24, 4 June 2013 (UTC)
Just throwing some numbers together, this would take days. ·addshore· talk to me! 18:33, 4 June 2013 (UTC)
...And we finally got rid of all "(12345) ..." Asteroids! --Ricordisamoa 21:18, 4 June 2013 (UTC)
O_o? ·addshore· talk to me! 08:45, 5 June 2013 (UTC)
What I'm saying is that it would be a waste of resources to nulledit all the pages in a Wikipedia. If the api would have been implemented it could be used as input for the bot so that only 325830 instead of 1.574.030 need to be touched. Now I just did this query and my bot is now running on this list (touch.py -lang:nl -file:articles_not_wikidata.txt). I'm not proud of it, but it works. It sure beats running touch.py -start:! . Judging from the numbers it looks like someone already did de, fr and it. Multichill (talk) 21:04, 9 June 2013 (UTC)
Awesome, well I doubt the 'touches' will cause any drastic effects anywhere :) so keep it up! :D ·addshore· talk to me! 13:37, 12 June 2013 (UTC)
I'm instead using some sort of screen-scraping (with BeautifulSoup) to get en:Special:UnconnectedPages; also, done some from it:Special:UnconnectedPages. --Ricordisamoa 22:59, 13 June 2013 (UTC)

Problem in Wikidata:Administrators/Timeline[edit]

Hi, When I enable Persian language in wikidata, the administrators timeline gets a error and doesn'n show correctly.(see image)

WikidataAdminsTimeline.png

Javad|Talk (19 Khordad 1392) 12:32, 9 June 2013 (UTC)

Unicode support in the Timeline extension hasn't been fully enabled yet. Please see mw:Extension:EasyTimeline#Unicode. --Ricordisamoa 14:17, 9 June 2013 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. "RESOLVED WONTFIX" --Ricordisamoa 22:26, 9 June 2013 (UTC)
This was the case with Gujarati and Bengali also I pointed that out and User:Byrial solved it.--Vyom25 (talk) 06:33, 10 June 2013 (UTC)
Unfortunately this is not the same. I prevented the current date used by the chart from be localized. What gives errors here, is translation of the legend, and I guess that you also will have problems if you translate the legend to Gujarati. Byrial (talk) 07:17, 10 June 2013 (UTC)
Well, I looked some more at the Persian translation, and it seems that the error messages was caused by something as simple as having spaces instead of underscores. I replaced the spaces and now the error message has disappeared, but the legend is rendered in the chart as empty boxes. The chart is a PNG image, and I cannot fix that the program making the image cannot render Persian letters. Byrial (talk) 08:05, 10 June 2013 (UTC)
I think I messed something...I see Gujarati legend on English page of Admin timeline and I see English legend on Gujarati page. But you are right about underscores. At least Gujarati text is visible.--Vyom25 (talk) 17:30, 10 June 2013 (UTC)
No, it was not something you did. The legend followed the selected interface language independent of the language of the viewed page. I changed that at Template:AdminsChart so the legend will now depend on the language version of the page which includes the template (that will normally be Wikidata:Administrators/Timeline or one the translations of that page). Byrial (talk) 20:44, 10 June 2013 (UTC)
It's only Persian. Beside Germanic languages and Indic languages; Japanese and Korean doesn't have the legends translated. Is it a right to left script thing? Because that's the only thing different between Persian and others.--Vyom25 (talk) 10:35, 11 June 2013 (UTC)
It may be. I don't know. We will see which works when more translation is done. Byrial (talk) 10:45, 12 June 2013 (UTC)
please see this this bug leaves more than 6 years!188.159.203.75 05:02, 13 June 2013 (UTC)
This appears to be irrelevant to this particular discussion.--Jasper Deng (talk) 05:09, 13 June 2013 (UTC)
may be this one is relevant188.158.216.225 13:14, 14 June 2013 (UTC)
Yes, It looks relevant and looks quiet unsolved. From reading comments there my suspicion about right to left scripts was partially correct.--Vyom25 (talk) 06:21, 15 June 2013 (UTC)

New reports for Wikidata[edit]

As you might know we have been maintaining a central report repository on the Toolserver for quite some time. Today we added two new reports:

Have fun. Multichill (talk) 21:13, 9 June 2013 (UTC)

These reports have the same false positives as Speciel:UnconnectedPages. Also connected pages are on the list until they are edited next time. Byrial (talk) 08:14, 10 June 2013 (UTC)
True, this will be corrected over time. The second one is a duplicated of the unconnected pages so it will probably disappear. Instead of that one we now have "Old pages that are not linked to from WikiData": Lists (max 1000) pages that were not created recently and that do not have a linked WikiData page yet. See for example this report. We should be able to reduce this report to no pages over time. Multichill (talk) 12:42, 15 June 2013 (UTC)

Geocoordinates are here![edit]

Heya folks :)

We've just deployed new code here. We fixed a few bugs, most notably:

  • bugzilla:45244 - Shows statements from "oldid" version, not "diff" version
  • Fixed a number of issues in translatable messages that made it hard to translate them

In addition to that there is also shiny new stuff:

  • Bene* wrote a new special page to set language links without JavaScript enabled (Special:SetSiteLink)
  • Made first version of the geocoordinates datatype available \o/ This means that you will be able to enter the coordinates of a city for example as soon as someone created the necessary property for it. (There are a few waiting on Wikidata:Property proposal.) It's still a bit wonky so please do let me know about any issues you find. We're already aware of:
    • bugzilla:49385 - cardinal directions in geocoordinate datatype are not localized
    • bugzilla:49386 - apostrophe issue in geocoordinate UI
    • bugzilla:49387 - property parser function needs to support geocoordinate datatype

Please subscribe to these bugs to stay up-to-date and please vote on the ones you care about most to help us prioritize. (You can find a list of all open bugs here.)


Cheers --Lydia Pintscher (WMDE) (talk) 18:48, 10 June 2013 (UTC)

coordinate location (P625) have been created. See, as example, KV1 (Q778902). Tpt (talk) 19:06, 10 June 2013 (UTC)
That's great ! Any idea about when (if ever) we will get the geoshape datatype ? I suppose this will affect how we use point coordinates. --Zolo (talk) 19:10, 10 June 2013 (UTC)
+1. If we are going to get geoshapes, then things like New York probably shouldn't be given point coordinates. Actually, point coordinates would probably be somewhat rare, as few things are so small that they can't be given a shape on a map. --Yair rand (talk) 19:31, 10 June 2013 (UTC)
They're on the list but not on the short-term list if that helps. --Lydia Pintscher (WMDE) (talk) 19:33, 10 June 2013 (UTC)
What happened to being able to specify a coordinate system, per m:Wikidata/Development/Representing_values#Coordinate? Was that idea abandoned, or is it planned for a later release? --Yair rand (talk) 19:14, 10 June 2013 (UTC)
This is an initial version. More elaborate things will follow. --Lydia Pintscher (WMDE) (talk) 19:34, 10 June 2013 (UTC)
Special:SetSiteLink allows to set links which are already in use on another item. (Example, this is already here: Q467402). --Stryn (talk) 19:17, 10 June 2013 (UTC)
Urgh. Not good. Bene* is looking into it. --Lydia Pintscher (WMDE) (talk) 19:34, 10 June 2013 (UTC)
This should be fixed now. Thanks for noticing this so quickly. --Lydia Pintscher (WMDE) (talk) 10:07, 11 June 2013 (UTC)
I don't think en:Selenographic coordinates, etc. should be a different datatype than geocoordinates. Is someone working on this issue? And what about elevation? —★PοωερZtalk 19:24, 10 June 2013 (UTC)
They are not a different datatype. As I wrote above this is a first version. More will follow. --Lydia Pintscher (WMDE) (talk) 19:35, 10 June 2013 (UTC)

I tried to copypaste coordinates from Geohack in DMS format, but it does not understand them. If I copypaste coordinates in decimal format, it understands.--Ahonc (talk) 19:49, 10 June 2013 (UTC)

Does it use apostrophes or single quotes? --Rschen7754 19:51, 10 June 2013 (UTC)
It was 50° 27′ 0″ N, 30° 31′ 25″ E (copied from [1]). It does not recognized. But if copy 50.45°, 30.523611° it is recognized.--Ahonc (talk) 20:21, 10 June 2013 (UTC)
This should be the bug I mentioned in the initial post here? --Lydia Pintscher (WMDE) (talk) 10:13, 11 June 2013 (UTC)
Hi Lydia! Thanks to all developers! In future elaboration will be possible to use also astronomical coordinates? --Paperoastro (talk) 21:01, 10 June 2013 (UTC)
The info I have on that is that it is still undecided. But I'll check with Denny when he's back from vacation. --Lydia Pintscher (WMDE) (talk) 10:13, 11 June 2013 (UTC)

With pyrev:11636, geocoordinates can now be used in pywikibot's rewrite branch. I'm also working on implementing the GeoData API, so it should be 4-5 lines of code to import coordinates from a Wikipedia :) Legoktm (talk) 21:15, 10 June 2013 (UTC)

Nice :) --Lydia Pintscher (WMDE) (talk) 10:13, 11 June 2013 (UTC)
There are problems with GeoAPI: it does not allow to get precision. For example {{coord|56|0|N|190|0|E}} have precision 0.0166667, {{coord|56|N|190|E}} have precision 1. But GeoAPI returns equal results for these cases. Another problem is hi-precision values: GeoAPI truncates it. There is solution: analyze page`s source, but this is not 4-5 lines. — Ivan A. Krestinin (talk) 09:15, 16 June 2013 (UTC)

When should we use point coordinates ?[edit]

We hopefully are about to get a working datatype for point coordinates (see above). Later on, we will get a geoshape datatype, so that we can add not just one coordinate point for an object, but a detailed specification of its boundaries. We do not know yet when it will be implemented, I presume it is a matter of months. In the mean time, we should decide in which case using the point-coordinate datatype is acceptable :

for single points, like the North Pole, or the highest point of a mountain ?[edit]

  • Symbol support vote.svg Support of course -Zolo (talk) 15:44, 11 June 2013 (UTC)
  • Symbol support vote.svg Support Ajraddatz (Talk) 15:50, 11 June 2013 (UTC)
  • Symbol support vote.svg Support Filceolaire (talk) 20:00, 11 June 2013 (UTC)
  • Symbol support vote.svg Support can't make a polygon out of a mathematical point --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)
  • Symbol support vote.svg Support clearly. Sven Manguard Wha? 22:26, 12 June 2013 (UTC)
  • Symbol support vote.svg Support pretty much by definition -- The Anome (talk) 09:25, 13 June 2013 (UTC)

for small objects, like a statue or a famous tree ?[edit]

  • Pictogram voting comment.svg Comment how small ? -Zolo (talk) 15:44, 11 June 2013 (UTC)
  • I'd be OK with this, with the "how small" question being answered by common sense until an issue comes up with it. It's hard to predict what those issues will be (for me anyway), so we could deal with that at a later time. Ajraddatz (Talk) 15:50, 11 June 2013 (UTC)
  • Symbol support vote.svg Support unless the object has a notable shape it should be a point. --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)
  • Symbol support vote.svg Support clearly. Realistically a point works perfectly well for a building; if you drop the point right in the middle of a building, or even in its front yard, we're all going to know what is being pointed to, and I'd still consider it perfectly accurate. Sven Manguard Wha? 22:28, 12 June 2013 (UTC)
  • Symbol support vote.svg Support Definitely. The easiest definition would be anything that is unshapable and/or the shape of which would be of little interest. Alexander Doria (talk) 22:37, 12 June 2013 (UTC)
  • Symbol support vote.svg Support as per Alexander Doria and Sven Manguard -- The Anome (talk) 09:25, 13 June 2013 (UTC)

for large objects like Berlin or the Atlantic Ocean ?[edit]

  • Pictogram voting comment.svg Comment we have this in Wikipedia, but geoshapes may make it obsolete. --Zolo (talk) 15:46, 11 June 2013 (UTC)
  • Pictogram voting comment.svg Comment, I think it has some uses, like creating a Wikidata layer in map services, but we should have clear rules on how we choose the point (the object center of gravity, or whatever). --Zolo (talk) 15:44, 11 June 2013 (UTC)
  • Depends on how you would like to describe "Berlin". Is it a set of real estates within a geographic area or an administrative unit with an office located somewhere? The second case can give strange results since the administrative center can be located outside the geographic area. -- Lavallen (block) 16:00, 11 June 2013 (UTC)
  • I guess it would be something like the territory over which the mayor of Berlin has authority or this sort of thing. Sure, if we use just one point for coordinates, it cannot always be the center (it would look funny for ring roads ;). --Zolo (talk) 08:41, 13 June 2013 (UTC)
  • I make some calculations and get that distance between two degree seconds is ~31 metres (40000/360/60/60, where 40000 is Equator length) and between two degree minutes is 1,8 km. So, for cities and big villages we may add only degree and minute without seconds.--Ahonc (talk) 20:47, 11 June 2013 (UTC)
  • I think this should be discusses with Wikipedia:WikiProject Geographical coordinates (Q10948883). A task force and guidelines are needed. --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)
  • I have left messages at the English and French project pages. --Zolo (talk) 08:41, 13 June 2013 (UTC)
  • ,Although accurate shapes should always be preferred if possible, I think this makes some sense for even features a few hundred km across, provided an approximate feature size can be provided. Something as big as an ocean or a large country is far too big -- but there are very few features on this sort of scale, and providing shapes for each one is quite feasible in the near term -- The Anome (talk) 09:25, 13 June 2013 (UTC)

For everything we have coordinates right now.[edit]

  • So also for country, we can just have both. In some cases you just want the point and in other cases the shape. Multichill (talk) 19:53, 11 June 2013 (UTC)
  • Symbol support vote.svg Support. How small to be decided on a case by case basis. I would encourage point coordinates wherever we don't have shape info. If we get shape info later we can update. Filceolaire (talk) 20:00, 11 June 2013 (UTC)
  • Symbol support vote.svg Support Per Multichill and Filceolaire. We can refine later with shapes or whatever will come. Raymond (talk) 20:30, 11 June 2013 (UTC)
  • Something to think about: After we get the geoshape datatype are we going to be duplicating the entire OpenStreetMap project here? --Yair rand (talk) 21:10, 11 June 2013 (UTC)
  • There is not much overlap. Openstreetmap is about navigation and the current network of streets and buildings. Wikidata on the other hand could have historical maps (Roman empire) or geologic information (extent of the San Andreas Fault). In my opinion Wikidata is the ground work for Wikipedias own spatial information project. --Tobias1984 (talk) 09:18, 12 June 2013 (UTC)
  • Yes, and the overlap does not extend too well the other way around : numerous practical informations of OSM are probably not sufficiently encyclopedic to be included on Wikidata (shops, supermaket, post office, phone booth…). Alexander Doria (talk) 23:35, 12 June 2013 (UTC)
  • Symbol oppose vote.svg Oppose shapefiles are better at representing linear or polygon objects. We already have a lot of shapefiles here: w:en:Template:Attached KML. --Rschen7754 21:22, 11 June 2013 (UTC)
  • Symbol support vote.svg Support On Wikipedia this works well for now. I guess shape forms will be harder to create anyway. HenkvD (talk) 21:36, 11 June 2013 (UTC)
  • Symbol oppose vote.svg Oppose Simply because it is not correct and wrong data, we need shapes, it is easy to import from OSM, UN ect. it is useful to check Items (is in) lets do things right. --FischX (talk) 22:48, 11 June 2013 (UTC)
  • Symbol support vote.svg Support - Work with what we got. --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)
  • Symbol support vote.svg Support Indicating the global position of a country/region is still better than nothing. For instance, I'm working on ancient greek administrative subdivision. Nobody can know their shape for sure — if they even had a definite shape, as during the antiquity, borders were seldom clearly determined. Yet, their general location remains an interesting data. Alexander Doria (talk) 22:42, 12 June 2013 (UTC)
  • We could allow for polygons with a margin of error for the outlines. What would you say is the uncertainty for ancient Greek borders? Even borders today have a margin of error as seen in numerous territorial disputes. I hope the polygons will allow us to capture that kind of complexity. --Tobias1984 (talk) 22:53, 12 June 2013 (UTC)
  • It depends on the geographical features. Some ancient athenian demes are sufficiently known to be drawn with a good deal of margin of error. For many others, we only have the vague notion that it's in the whereabouts of some location (for instance, thanks to some set of epigraphic mentions). So that we cannot draw anything. Alexander Doria (talk) 23:31, 12 June 2013 (UTC)
  • Symbol support vote.svg Support It is anyway a useful information. --Paperoastro (talk) 10:19, 13 June 2013 (UTC)
Symbol oppose vote.svg Oppose On Wikipedia we do this because there's no other option, but I don't think we should rush to fill in Wikidata with misleading data that will have to be fixed later. At the very least, I would prefer some kind of annotation or scale for points that don't represent an object at the specific point. That way a machine consumer of the the data can know that there is not actually an object at the specific point, e.g. that "Greece" is not located on a specific city block. --Delirium (talk) 14:20, 13 June 2013 (UTC)

More than one interwiki per language ?[edit]

Would it be possible to allow the addition of more than one interwiki link in a given language? The only reason I see for not having this already is that the majority of Wikipedias have only one article per subject, but what if a Wikipedia allows to have more than one article for the same subject? Amqui (talk) 18:05, 11 June 2013 (UTC)

Huh? Why would they want to have more than one article about one subject? Are you thinking of any specific Wikipedia, or is the question purely hypothetical? Byrial (talk) 19:03, 11 June 2013 (UTC)
There are situations when different Wikipedias have differents sets of articles (many of the situations mention, e.g., here are of this category). But allowing more than one interwiki link will result in a mess. You talk about situations with one article - two articles. But there can be situations with two articles in one language correspond to three articles in another language (and one article in the third language). It would be simply unbearable. --Michgrig (talk) 19:27, 11 June 2013 (UTC)
The articles in different Wikipedias may have all variations of overlaping subjects, and that has been discussed numerous times. But that is different than one Wikipedia allowing two articles about the same subject. Byrial (talk) 19:40, 11 June 2013 (UTC)
I thought that 'no forking' is one of the basic rules in every Wikipedia. So I didn't even think about this possibility :) Am I not right? --Michgrig (talk) 19:47, 11 June 2013 (UTC)
I call this the Bonnie and Clyde (Q219937) problem. Some wikipedias have an article on Bonnie and Clyde while others have separate articles on Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282). We have agreed that the devs will amend the software so we can link to redirect pages as well as linking to articles. This should, in most cases, solve this problem. Filceolaire (talk) 19:55, 11 June 2013 (UTC)
There is a property for this case, but some people want to delete it.JAn Dudík (talk) 20:09, 11 June 2013 (UTC)
It's reciprocal and therefore redundant, no information would be lost. —★PοωερZtalk 20:25, 11 June 2013 (UTC)
The question isn't hypothetical. Some Wikipedias in small languages where the language isn't as codified as bigger languages like English may have the exact same subject in different dialects, or even only for languages that use different scripts, they may have the same subject written in each script. An example of that is w:cr:ᒥᒋᓯᐤ and w:cr:Mikisiw ka wapictikwanetc, both are about the bald eagle. Amqui (talk) 21:20, 12 June 2013 (UTC)
Also similar to the problem of Incubator. --MF-W 21:26, 12 June 2013 (UTC)
Maybe a solution would be to allow to use more than one "language name" per project. It would work for the Incubator problem as well as Wikipedias with more than one dialect or different scripts. We would use different "language names", but the interwiki links themselves would point to the same project. Using the above example, the interwiki table for "bald eagle" could contain "ᒥᒋᓯᐤ" for "Iyiyiw-Ayimuwin (syllabics)" and "Mikisiw ka wapictikwanetc" for "Atikamekw", but both would point to crwiki. It wasn't really doable with the previous way to handle interwikis, but with Wikidata I think it is implementable. Amqui (talk) 19:36, 13 June 2013 (UTC)

Need qualifier for indicate 'acting president'[edit]

I added some of the past head of governments of New York City, based on W:List_of_mayors_of_New_York_City. However, there was multiple time an acting president. I didn't know how I could indicate that, so I took the qualifier/property 'role' for the moment. Is there already a more appropriate qualifier or should we create one? In my opinion something like "as" would be good. --Nightwish62 (talk) 22:30, 11 June 2013 (UTC)

  • Please do not use "role" for things other than to specify actors. It doesn't make any sense in non-English languages. --Yair rand (talk) 00:24, 12 June 2013 (UTC)
  • Is office held (P39) not an option? Otherwise we have to think of a new property that can be broadly applied to such cases. --Tobias1984 (talk) 16:43, 12 June 2013 (UTC)
    • Thank you. I changed it to 'office held'. Hoever, I notice I did another fault. I entered "acting president", but it should be "acting mayor". But "acting mayor" didn't have any sitelink/item W:Acting_Mayor. I know there was a discussion if we could also use redirects, but I don't no what's the conclusion was? So what should I do? --Nightwish62 (talk) 21:00, 12 June 2013 (UTC)
  • I think in this case it would be best to create a new item "acting mayor", set main type to "term", subclass of = "political office" or "mayor" and whatever else might look appropriate. For sources you can probably look for an "introduction to political science" text book, by searching "acting mayor" on a book search platform.
    By the way: You could create a task force page and write up some guidelines for political science. I'm sure more people would be interested. --Tobias1984 (talk) 21:26, 12 June 2013 (UTC)
  • Ok, I created "acting mayor". But then I got confused about the term "acting". I'm a non-native English speaker and now I struggle with this word. dict.cc says "acting" means (in german) "amtierend" AND (!!) "stellvertretend". It also says "acting major" = "amtierender Bürgermeister" and "deputy mayor" = "stellvertretender Bürgermeister". So what's the right term for a mayor which takes the lead for a short time when the official mayor dies? Acting or deputy mayor? Wouldn't be the term "acting mayor" fit to all entries in this list (both: regular elected and as representative of)? On the other site, [W:Mayor#Acting_mayor]] explains exactly what I'm looking for, but the word "acting" didn't explicit tell it is in representative of someone else (stellvertretend)? --Nightwish62 (talk) 22:07, 12 June 2013 (UTC)
  • Also auf Deutsch nennt man sowas doch Interimsregierung (i.d.F. Interimsbürgermeister). Die Übersetzung in Dict ist in dem Fall sogar falsch. Auf Englisch hab ich gesehen, dass man auch "provisional government" sagen kann. Man könnte also wahrscheinlich auch "provisional mayor" sagen, damit die Sache etwas klarer als mit "acting mayor" ist. --Tobias1984 (talk) 22:29, 12 June 2013 (UTC)
  • Noch besser: Das Wort "Interim" wird auf Englisch auch verwendet. Ich mach das mal zur primären Beschreibung von interim mayor (Q13436054), dann sollte es auch keine Verwechslungen geben. mfg --Tobias1984 (talk) 22:38, 12 June 2013 (UTC)
  • Tricky! I can imagine five or six different words in Swedish depending on time, circumstances and type of office. "acting mayor" would normally be "tillförordnad borgmästare". "acting king" would be "riksföreståndare". -- Lavallen (block) 15:17, 13 June 2013 (UTC)
  • Danke für die Hilfe. Also welche der Übersetzungen genau auf dict.cc findest du falsch? Wenn man einfach mal googlet und die Begriffe in Anführungszeichen setzt, so ist "acting mayor" am meisten verwendet, dann kommt "interim mayor" und ganz am Schluss "provisional mayor". Ich denke, "interim mayor" ist am deutlichsten, aber verwendet wird wohl "acting mayor", den so lautet ja auch der Abschnitt in der Wikipedia (siehe Link oben). --46.255.169.80 18:54, 13 June 2013 (UTC)
  • Ich denke die Übersetzung "acting mayor" zu "amtierender Bürgermeister" ist falsch. Es stimmt zwar, dass der Interimsbürgermeister auch amtierend ist, aber an erster Stelle ist er aus einer politischen Notsituation zu dem Amt gekommen. Wenn du willst kannst du den Titel ruhig auf "acting mayor" ändern. --Tobias1984 (talk) 19:24, 13 June 2013 (UTC)
That is a different thing, but still I think the value of "head of government" for New York City should be Mayor of New York City (Q785304), rather than a list of people who were mayors of New York. --Zolo (talk) 21:24, 13 June 2013 (UTC)
You said something I already thought too. It's an important question and one of the hundreds of how we should collect data. I'm not sure which way is the better one at moment. However, doing it your way, we could create about 10 millions+ new items for every city or municipality of the world. --Nightwish62 (talk) 14:12, 16 June 2013 (UTC)

Working guidelines for Wikidata:Properties for deletion[edit]

As one of the few people that's been closing properties for deletion in the past few weeks, I've been making up the rules pretty much as I go. It's not that I want to be doing it, it's just that there's never been any real effort to set up a deletion policy for properties. Therefore I propose that the following guidelines be put into place:

  • Whomever nominates a property for deletion must inform the property creator and the property proposer (the person that suggested it at Wikidata:Property proposal) that the property is up for deletion. While it would be considered a courtesy to inform relevant task forces, that is not required.
  • Property for deletion discussions are closed whenever a consensus is reached, or when the closing admin determines that it would be impossible for consensus to develop (usually if after several weeks, opinions are still split). If the closing admin determines that it would be impossible for consensus to develop in the deletion session, they can suggest an RfC be held to resolve the issue.
    • As a general statement, discussions should run for a minimum of three days, even when there is a clear consensus for keeping or deleting an item, however discussions can be closed earlier if a property is in the wrong datatype, was created in error (and creator nominates for deletion immediately after creating it), or if the property creation guidelines were unambiguously not followed (if, for example, a property was created with no prior discussion or the property's proposal had no support).
    • Unlike deletion discussions on other projects, there is not a set cut off date at which point the discussion is supposed to end. If it takes six weeks for the discussion to pan out, it takes six weeks for it to pan out.
  • There is no formal appeals process for property for deletion discussions. If someone contests a "keep" result, they can always renominate it for deletion, however they are discouraged from doing so without a strong reason or immediately following a previous discussion's closing. If someone contests a "delete" vote, and it has only been a few days since the deletion, they are encouraged to explain their reasoning for keeping the item (having it restored) below the closed discussion, and then bringing their post to the closing admin's attention. The closing admin can then make a decision to reopen the discussion. If the closing admin chooses not to reopen the discussion, or if significant time has passed since the deletion, the property can always be proposed again, through the Wikidata:Property proposal process.

I believe that this is a reasonable set of guidelines for the area. Property deletion discussions are often some of the most complex discussions on the project, and sometimes can be highly impactful. I believe this strikes a good balance between giving people a framework to work from and not constraining the process too much in red tape.

Thoughts? Sven Manguard Wha? 20:34, 12 June 2013 (UTC)

Personally I agree with all but perhaps the notice about nomination for deletion could be more centralised rather than tracking the property creator and proposer? John F. Lewis (talk) 20:40, 12 June 2013 (UTC)
Symbol support vote.svg Support - Clear and well written. I would personally inform task forces if it looks like it is an important property for them. --Tobias1984 (talk) 21:32, 12 June 2013 (UTC)
Notification on property talk page is required. And we need some idea how to trace and fix property usage in Wikipedia. — Ivan A. Krestinin (talk) 21:45, 12 June 2013 (UTC)
Looks good, I do wish there was a way we could properly notify Wikipedia's that are using properties before they get deleted. Legoktm (talk) 22:08, 12 June 2013 (UTC)
I'd be willing to settle for being able to see where properties are being used off of Wikidata. I don't know how to do that. Sven Manguard Wha? 22:24, 12 June 2013 (UTC)
Symbol support vote.svg Support with the suggestions of Ivan A. Krestinin and Tobias1984. --Paperoastro (talk) 10:12, 13 June 2013 (UTC)
Symbol support vote.svg Support, too. I'm planning a bot script to notify the creators of such properties. --Ricordisamoa 22:52, 13 June 2013 (UTC)

Wikipedia Category Items which do not have wikipedia articles[edit]

I found an item which corresponds to a Wikipedia category ( Category:Religious buildings (Q5655238) ) which seems really fine (not surprisingly) to be used with subclass and instance of relationship. The problem is that I do not know of a policy related to using those items which seems to be competing with items which corresponds to aticles on the main wp namespaces. This one does not seem to be (and even if it has the question deserve an answer). What do we do in those cases ? TomT0m (talk) 09:18, 13 June 2013 (UTC)

I would use place of worship (Q1370598) instead of the category item. I have added the alias "religious building" to the item so it can be found more easily.--Micru (talk) 17:27, 13 June 2013 (UTC)
Ok, but as I said the question remains for other examples, for example there is a Catholic religious building category. or (no label) (Q13328939). There is a main article template in wikipedia to link categories to their main articles. Can we use items for catégories whithout a main articles ? I'm starting to think that actually wikipedias categories with a main article and this wikipedia articles should be linked to the same items. So we could have, per item and per language link zéro or one wp article plus zéro or one categories. TomT0m (talk) 20:14, 13 June 2013 (UTC)
It may convenient to be able to have one article per namespace per language, but absent software changes, I do not think we should ever use "category-items" the same way as "main-items, as it is messy, and tedious to update if the main-item gets created afterwards. --Zolo (talk) 21:35, 13 June 2013 (UTC)

Lua calls to Wikibase give Script Errors[edit]

See mw:Thread:Extension talk:Scribunto/Lua calls to Wikibase give Script Errors. Helder 18:40, 13 June 2013 (UTC)

The problem isn't Wikibase, it's his code. To start with, in the functions m.id, m.label and m.page he needs to change the global variable p to m (p.entity should be m.entity, p.id should be m.id and so on).--Snaevar (talk) 10:32, 14 June 2013 (UTC)

Request for split?[edit]

I know there is a site "request for merge". But is there also one for splitting request? I found that Q125348 is about two different persons. But I'm not able to fix it by myself. --Nightwish62 (talk) 20:17, 13 June 2013 (UTC)

In a case like this where there aren't many pages linked, it's easy to manually. I created Q13445660 and moved the nl.wiki individual to that item. As far as I understand, this solves the problem. Cheers, Pichpich (talk) 21:23, 13 June 2013 (UTC)
Where the pages are complicated, you should list the item at WD:IC in my opinion. --Izno (talk) 21:34, 13 June 2013 (UTC)
Thank to you both. --Nightwish62 (talk) 19:52, 14 June 2013 (UTC)

The need for a BLP policy[edit]

I know the idea has been thrown around before but I think it's time to get a proper policy about biographies (or in our case items) of living people. Way back in March, the bot request Wikidata:Requests for permissions/Bot/Dexbot 2 green-lighted the importation from en.wiki of statements about a person's sexual orientation and thousands of such claims were added, including for items of living people. Obviously, bots cannot check that a claim on en.wiki is properly referenced and although (thank god) sexual orientation is not as controversial as it was even a few years ago, it's still a delicate matter and a potential breach of privacy. On de.wiki, nobody would allow a claim about someone's sexual orientation (in particular if it's a living person) when the only reference is en.wiki. So we shouldn't allow a similar statement on Wikidata that is blindly imported from en.wiki and it would be nice to codify this a little bit. Pichpich (talk) 22:33, 13 June 2013 (UTC)

I agree that we need this. Should we start by copying from the Wikipedia:Biographies of living persons (Q4663389) pages from the various wikipedias and then edit them here? Filceolaire (talk) 20:16, 14 June 2013 (UTC)
From what it sounds like, the issue here is how various Wikipedias have different standards for what is and isn't includable around living people. We could take the easy route out and thus model a BLP policy based on the strictest one present on a Wikipedia, but IMO a better route would be to create another long winded RFC for our own community to decide for itself. I would personally be OK with any claims added, so long as there is an appropriate reference for them on at least one project. Unfortunately, that isn't possible to do via bot right now, but that could at least be a starting point for human-added claims. In the mean time, perhaps bots could stop adding such potentially controversial claims? Ajraddatz (Talk) 23:29, 14 June 2013 (UTC)
A prerequisite for a BLP policy is a verifiability policy, because BLP is all about verfiability with specific regard to living people.--Jasper Deng (talk) 23:35, 14 June 2013 (UTC)
Also, there exists a draft at Wikidata:Living people.--Jasper Deng (talk) 23:39, 14 June 2013 (UTC)
Well, we already have a notability policy which covers that. That draft looks pretty good - I'm a bit busy right now, but I'll take a more in-depth look in a bit. Ajraddatz (Talk) 23:47, 14 June 2013 (UTC)
@Jasper. Thanks for the pointer to the draft. It's true that we also need something resembling a verifiability policy but until we codify all that, we could still have a basic agreement along the lines of "adding controversial statements about living people without a solid reference = bad bad bad". Pichpich (talk) 03:34, 15 June 2013 (UTC)

Determination of sex from pronoun usage in Wikipedia[edit]

Pichpich have suggested to use the occurrences of sex specific personal pronouns in Wikipedia articles to determine the sex of items of type person. I worked a little on that, and made User:Byrial/Use of he and she in enwiki‎ which shows the distribution of articles in English Wikipedia about persons with known sex after the difference between the number of occurrences of the words "he" and "she". The result is that this difference is a good indication of the sex of the person. I listed some of the cases where articles about male persons have most occurrences of "she", and where female persons have most occurrences of "he", and many of these cases is due to a wrong indication of the sex here at Wikidata. I made a similar analysis for articles at the Danish Wikipedia at da:Bruger:Byrial/han-hun which show similar results.

So now the question is if it would be acceptable to set a bot to automatically add sex statements to many thousands items where the difference between the numbers of "he" and "she" (or similar pronouns in other languages) is largest? Byrial (talk) 09:40, 14 June 2013 (UTC)

Nice work. One interesting feature is that this can help identify mistakes. If one looks at your list of paradoxes (males with too many 'she' and females with too many 'he'), you see the following
  • list articles (these could easily be filtered out by removing any article whose title contains words like "characters", "list")
  • articles about a couple or duo of some sort (again, can be filtered out by skipping articles with "and" in the title)
  • articles about people whose name contains "he" or "she" (can be filtered out)
  • articles who are currently labeled as male on Wikidata but who are actually female! In other words, your data isn't paradoxical, it's just identifying mistakes.
Out of the 36 articles which are currently tagged as male despite having more "she" occurrences, you find 1 list, 1 article about a couple, 1 person whose name contains the word "she", 25 people who are indeed women but are listed as male on Wikidata and 8 people who are indeed male. The second list is similar and I think this shows two things: first, this method is probably excellent if we set the threshold for being conclusive high enough (say |diff| >25). Second, this method could be very useful in identifying current mistakes and I think that's a nice feature. We know that the method of classifying using the first name is not perfect and we know the he/she method isn't perfect either but if we can manually check the few cases where the two methods disagree, the overall error rate will be excellent. Pichpich (talk) 15:06, 14 June 2013 (UTC)
If you are going to analyze a text for the subject's sex, to check for things like occupation sounds more promising to me. While in English, there's only a few cases where you can decide the sex from the occupation (like actor/actress), other languages like German or French do have that for almost any occupation, and often this can be detected without having a complete dictionary, as often typical suffixes like -in oder -euse are used. However, false positives still are possible, even if you just check the persondata etc. (like being "the son of the famous actress XYZ" doesn't make you a woman). But, when analyzing an rticle text like described, this should be considered, too. --YMS (talk) 15:29, 14 June 2013 (UTC)
True but only if you look at the first sentence or two. The fact that the word "actrice" appears in the second paragraph probably correlated pretty poorly with the subject's sex. I'm also skeptical about checking only for suffixes. For instance, the number of German words ending in -in (including the word "in" itself!) is too large to avoid tons of false positives. In any case, the method you suggest doesn't need to replace the he/she method. As I noted, having a variety of pretty good methods and using them simultaneously is the best way to get to 0% error. Pichpich (talk) 15:44, 14 June 2013 (UTC)
Using the genus for the occupation from Swedish can be misleading, since it can be the neutral genus. -- Lavallen (block) 17:08, 14 June 2013 (UTC)
The German Wikipedia has de:Kategorie:Mann or de:Kategorie:Frau in every biographical article. So no need to guess there. --91.67.136.169 01:50, 15 June 2013 (UTC)
This is true for 99% of biographies on de.wiki and IIRC there are already bots importing that info. The above is one of many plan Bs for the rest (including all the biographies that are not on de.wiki). Pichpich (talk) 01:57, 15 June 2013 (UTC)
Czech wikipedia have cs:kategori:Muži and cs:kategorie:Ženy too, and my bot imported these statements to all involved articles. JAn Dudík (talk) 19:22, 15 June 2013 (UTC)

Merge.js[edit]

Is it just me or has the gadget merge disappeared from wikidata. I dont know if a recent update of the gadget may be the cause of this - Foxie001 (talk) 17:03, 14 June 2013 (UTC)

Nope, still appears for me. Ajraddatz (Talk) 23:31, 14 June 2013 (UTC)
There was an error, but now it is ✓ fixed and working. --Ricordisamoa 02:45, 15 June 2013 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Ricordisamoa 02:46, 15 June 2013 (UTC)

Property image (P18) bug[edit]

Hi! on this page, the file name in the title bar of the preview image overlaps with the X to close the preview.--Kky (talk) 10:26, 15 June 2013 (UTC)

Yes, but the X button still works. I don't know if there's a good solution, other than to replace the name of the image with "image preview" or something like that, which I'm not sure is a great idea. Sven Manguard Wha? 17:26, 15 June 2013 (UTC)
I don't understand what you're talking about. Which "preview images"? Do you use any gadget? --77.239.41.207 22:11, 15 June 2013 (UTC)
See the little grey boxes right next to "HeatherGrahamByDimitriSarantis2011.jpg" at Q224026? Click those. Sven Manguard Wha? 22:36, 15 June 2013 (UTC)
That little grey box is made by the CommonsMedia gadget. There is no way to view the image directly by default. So any bugs in the way the image is shown, must be a bug in the gadget. Byrial (talk) 22:46, 15 June 2013 (UTC)
In IE10 I didn't have this preview button, in chrome it works? Is this bug also reported already? --Nightwish62 (talk) 13:47, 16 June 2013 (UTC)

How to handle new pages?[edit]

Hi everyone, not sure if this is brought up already: How to handle new pages being created at the Wikipedia's? We have batch imported most existing pages, but of course new pages get created on a daily basis. How are we going to keep up with this? I would propose to do this with a bot keeping an eye on the newly created pages. For every real page (not redirect):

  1. Does the page have an item? If so, we're done
  2. Does the page contain interlanguage links? If these are valid, an item is found and no conflicts: Link to the item and we're done
  3. For the pages which don't have an item and no interlanguage links we should probably have a period of 7 (?) days before creating a new item. This gives users the time to add a link.

Is this the right approach? This could of course be more detailed, for example with reporting of pages that are in a conflicted state or automagically merging two items, but that's something we can always add on later. Is someone willing to work on this or maybe already has the code? It would be nice to have this in Pywikipedia so we can have multiple bots working on this in different languages. Multichill (talk) 14:31, 15 June 2013 (UTC)

I definitely agree that some time should spent before going and creating an item for a new page. But I'd suggest 8 days instead of 7. Here's my reasoning: We don't want to create items for WP:PRODed pages, so I'm suggesting 1 day to tag a PROD and 7 days for it to be deleted (or not) should pass before the item is created here. Needless to say, CSDs would be deleted in that timespan, so they would also not be imported here. I'd also say that human editors should be allowed to create items for newer pages at their discretion.
@Multichill, the reason I'm not mentioning anything about giving the creators of pages time to create items is because I just had a look Special:NewPages on ENWP, and I'd say 1/4 to 1/3 of the users creating pages were newbies, meaning they would be unlikely to know (how) to create an item on Wikidata. --Jakob Scream about the things I've broken 15:26, 15 June 2013 (UTC)
We should have an item creation wizard that looks for existing items and assists people with filling in necessary information. The wizard should only create the item after all the steps are completed (Similar to commons-upload-wizard). The quick creation should be hidden from users until they created e.g. 25 items. --Tobias1984 (talk) 15:33, 15 June 2013 (UTC)
Time for deletion is important yes, for the Dutch Wikipedia this is 14 days so this should probably be decided on a per Wikipedia basis.
I don't expect newbies to link up their pages, but others might be monitoring it. Multichill (talk) 16:21, 15 June 2013 (UTC)
Waiting long enough (whatever that means on each local Wikipedia) makes perfect sense. Another simple idea is to avoid creating an item for an article that is currently part of a deletion process (whatever those processes are on each local Wikipedia). Pichpich (talk) 20:02, 15 June 2013 (UTC)
Some ideas:
  • auto-notify page creator if the page doesn't have a linked item after 3-4 days
  • auto-link persons with same name and birth/death dates
  • Real-Time Unlinked Pages (JS tool?) --Ricordisamoa 03:13, 16 June 2013 (UTC)

Idea to improve the input box[edit]

Anyone who has added many claims to items knows that the input box can be pretty frustrating when there's lots of things with the same name. If someone wants to input "George Washington" into an item, chances are they mean George Washington (Q23) (the U.S. president), not George Washington (Q586680) (a television miniseries), or George Washington (Q2366114) (a businessman), but President Washington doesn't even appear in the first page of results from the dropdown. A simple way to resolve this would be to have the dropdown sort the items by the number of other items that link to them, since if an item has been linked to by many other items, it's probable that the user will be wanting to add another link to the same item. Since this isn't something that needs to be exactly up to date at all times, the count list could be cached and regenerated at some regular interval, perhaps once a week or so. It's probably not the ideal solution, but it's better than whatever method the box uses now. Thoughts? —Scott5114↗ [EXACT CHANGE ONLY] 00:44, 16 June 2013 (UTC)

I (or someone else) could write a JS patch for this, but I'd prefer to discuss it on bugzilla. --Ricordisamoa 02:38, 16 June 2013 (UTC)
I've been thinking the same and this would be particularly helpful when adding statements manually. For instance if one tries to add the statement that XYZ is an album, it's necessary to scroll down to "more" before finding Q482994 despite the fact that it has tens of thousands of incoming links. (In fact I'm curious: exactly how are those lists of items ranked? ID number?) Pichpich (talk) 03:03, 16 June 2013 (UTC)
I don't think it's ID number, since President Washington has an ID number of only 23, and yet he ends up way down the list (in fact, at the very bottom of the plain "George Washington"s before things that have other things behind "George Washington"). I can't discern any pattern at all from the ID numbers, actually, either ascending or descending by numerical value or alphabetical value of the digits, so I have no idea what order the box sorts them in. Whatever it is, the items do at least stay in a consistent order from day to day. I had considered opening a bug on Bugzilla for this, but figured it'd be a good idea to get input from Wikidata users behind it first so we can demonstrate to the devs that this is a desired change. —Scott5114↗ [EXACT CHANGE ONLY] 06:55, 16 June 2013 (UTC)
I support this idea 100%. A couple days ago I was updating the items for all of the U.S. states. I distinctly remember the item for the actual state of California being the very last "California" item before other things popped up, and it was like the third page of dropdowns. TCN7JM 07:18, 16 June 2013 (UTC)
Symbol support vote.svg Support too. I also think this could avoid wrong edits, since not every item has a description. Sure, I know in this situation I've to check up the right item beforehand, but a new Wikidatia user could just pick the first one of the list. Even this is a wrong behavior, when sorting as descripted above, the chance is bigger he picks the right one by accident. --Nightwish62 (talk) 13:55, 16 June 2013 (UTC)
Guys, it'd be better if you added descriptions and proper aliases to items. It did work for me in my language and now I run into such problems way more rarely :) Infovarius (talk) 20:16, 16 June 2013 (UTC)
Aliases and descriptions are not a panacea. In the case of George Washington above, every one of the items in question is properly labeled "George Washington" since that is the name of all of them, and they all bear descriptions. It's just that Q23, the most prominent item with that name, is sorted to the bottom of the list, meaning one has to click "more" several times to get to it unless you just happen to know the item number. In fact, I've had to commit west (Q679) to memory because I use it so frequently and it's such a pain to get to in the dropdown. —Scott5114↗ [EXACT CHANGE ONLY] 22:16, 16 June 2013 (UTC)
That's inpiring, the item suggester should take into account our recent history of edition (and maybe its neighborhood). Another thing, what about a "bookmark item" gadget which would make some chosen items always available ? TomT0m (talk) 10:29, 17 June 2013 (UTC)

We have bugzilla:45351 for this issue. --Lydia Pintscher (WMDE) (talk) 09:34, 16 June 2013 (UTC)

tool for adding article to existing Wikidata item[edit]

Hello, I have used several times the tool which helps adding an article from el.wikipedia to an existing Wikidata item. The tool works fine and thank you to the developers.... however... it does not update the title of the item.

An example: I used the tool to add the el article to Wikidata, but then I had to come to Wikidata and also change the label. Since these are in principle the same, why not allow the tool to do it automatically and save us some time? --FocalPoint (talk) 07:10, 16 June 2013 (UTC)

Symbol support vote.svg Support. I don't see any reason why not to make it automatically add the label also. --Stryn (talk) 08:35, 16 June 2013 (UTC)
For now you can use autoEdit. --Ricordisamoa 09:47, 16 June 2013 (UTC)
Symbol support vote.svg Support I agree this should be automatic. --Napoleon.tan (talk) 16:16, 17 June 2013 (UTC)

Next data type?[edit]

I hardly dare to ask it, because I already asked the same question in the past several times already. But now as we have geocoordinates, what is the next data type we could expect? I'm also missing the development roadmap which was promised since about Easter. --Nightwish62 (talk) 14:16, 16 June 2013 (UTC)

There is this blog entry from a while ago which I already linked here as well. As it says the priorities for the near future are more datatypes, queries and sisterprojects. They're all being worked on. Currently geocoordinate parsing is being improved and we're working on allowing to link to Wikivoyage as a first sisterproject. As for which datatype comes next: I hope URL but since that is a bit more complicated because of the needed input validation another one might come first (number probably). --Lydia Pintscher (WMDE) (talk) 10:11, 17 June 2013 (UTC)
Thank you. --Nightwish62 (talk) 12:28, 17 June 2013 (UTC)
And what about numeric datatype? It is also well-needed.--Ahonc (talk) 10:58, 17 June 2013 (UTC)
They're all needed ;-) Currently URL and number are the ones with the highest priority. --Lydia Pintscher (WMDE) (talk) 12:01, 17 June 2013 (UTC)
What's the difference between number and numeric? --Nightwish62 (talk) 12:28, 17 June 2013 (UTC)
There is none afaict. --Lydia Pintscher (WMDE) (talk) 12:30, 17 June 2013 (UTC)
Is there a unit of measurement for the numeric? like KM, mg, liter, etc? --Napoleon.tan (talk) 16:18, 17 June 2013 (UTC)

Unable to edit with Firefox[edit]

Wikidata firefox error.png

For some reason I've lately been unable to edit items with Firefox. The [edit] links show up for the page title and description, but not for the actual interwiki links. Otherwise the page is loaded fine and there's nothing in the error console. I'm using Firefox 21.0. Anyone know how to fix this? Thanks. Jafeluv (talk) 10:37, 17 June 2013 (UTC)

I am just updating my version of firefox to see if I also have the issue. Do you have a screenshot? ·addshore· talk to me! 14:11, 17 June 2013 (UTC)
Added a screenshot displaying the issue. Jafeluv (talk) 06:31, 18 June 2013 (UTC)
I have not had any problems. Also FF 21.0. --Stryn (talk) 14:21, 17 June 2013 (UTC)
I also saw this in my firefox, the entity sometimes show up but sometimes stays as entity ID. I also saw a lot of javascript error in my firebug --Napoleon.tan (talk) 16:22, 17 June 2013 (UTC)
It works for me. This looks like a caching error, or something else messing your Javascript and CSS.--Jasper Deng (talk) 06:32, 18 June 2013 (UTC)
Hmm... Tried blanking my vector.js and CSS but that didn't help. Editing works fine with Chrome, just not with Firefox for some reason. Jafeluv (talk) 07:50, 18 June 2013 (UTC)
Other than clearing your browser cache, there's not much I can suggest - except that it might be a browser add-on.--Jasper Deng (talk) 08:03, 18 June 2013 (UTC)
I should have replied here sooner, I updated and nothing seems broken for me. Also after looking at your screenshot it would seem that you are also missing the sorting arrows for the columns. Could you perhaps load the page in firefox, got to view the source (right click view source), and paste it somewhere for us to see? (perhaps http://pastebin.ca/). If you want to try something extreme you could try reinstalling the whole browser! ·addshore· talk to me! 22:12, 18 June 2013 (UTC)

Coordinates for streets[edit]

I'd notice that in some Wikipedias infoboxes for streets have two coordinates values: coordinates of beginning of street and coordinates of end of street (see uk:Хрещатик or ru:Крещатик). How to add them in WD? Create new properties or use qualifiers?--Ahonc (talk) 11:02, 17 June 2013 (UTC)

  • I think new properties is better. Something like "coordinates of the beginning" and "coordinates of the end". Its can be used for rivers too. coordinate location (P625) will be used in {{coord|...|display=title}}. This construction does not allow multiple values. Property 625 is used for geometric center of such objects as settlements. I think it must be used for streets in the same context (geometric center of street is used in ruwiki, for example Северный проспект). — Ivan A. Krestinin (talk) 12:43, 17 June 2013 (UTC)
  • I think it is the same of another usecase: we need one property (street coordinates) which value is an item to which are attached too coordinates properties. Of course it is the same as the editions items for books : we need to wait for user interface improvement related to handling nested items. TomT0m (talk) 15:47, 17 June 2013 (UTC)
  • Interesting idea. But is there this idea in developer`s roadmap? If there is no then I suggest use two properties currently and convert its to nested properties then its will be available. — Ivan A. Krestinin (talk) 17:32, 17 June 2013 (UTC)
  • Just to remark that this concerns all extended objects (e.g. rivers) as well as areas. Ideally, we should be able to track the whole object which does not have to be straight.--Ymblanter (talk) 17:47, 17 June 2013 (UTC)
  • Whole object storing is another task as I think. River`s source and mouth are two very specific and very important points for example. If we will have all river`s points we must highlight and make easy data access to these two points anyway. / In Russian: Думаю, что сохранение всего объекта - немного другая задача. Исток и устье реки, например, - это очень специфичные и важные точки. Даже если мы будем иметь описание всего объекта, то нам всё равно нужно будет выделить эти две точки и обеспечить лёгкий доступ к ним потребителей информации. — Ivan A. Krestinin (talk) 18:38, 17 June 2013 (UTC)
  • Indeed it is on the developers roadmap, I understood Denny and others had a talk to solve the problem of books and editions, users saying it would be tedious to create an item for all editions although it would match the logic around this kind of semantic database, and a better interface to edit items linked in the same page was cited as an interface improvements that would benefit not only this usecase but also the whole project, see [2]. TomT0m (talk) 17:59, 17 June 2013 (UTC)

This is not a very good idea to represent streets with coordinates - it's better to use geographic shapefiles for them in order to accurately represent the object. See the thread a ways up. --Rschen7754 08:48, 18 June 2013 (UTC)

FYI: I am not aware of any plans to do nested properties. --Lydia Pintscher (WMDE) (talk) 08:23, 18 June 2013 (UTC)

Final vote on the Guidelines for sourcing statements[edit]

Final vote on the "Guidelines for sourcing statements" till June 24. Note that the guidelines are just a recommendation about how to source statements. The discussion whether bots should be required to source statements is a different matter and it will be discussed independently.--Micru (talk) 14:09, 17 June 2013 (UTC)

Links to freebase ?[edit]

Hello, Google has asked us about crosslinking with Freebase (Q1453477). Comments should go to Wikidata:Property proposal/Authority control#Freebase identifier. --Zolo (talk) 15:17, 17 June 2013 (UTC)

Coordinates gadget[edit]

Hello, can maybe one of the JS programmers write a gadget which displays next to coordinate statements a link to OSM and maybe other online maps displaying this coordinate? --Pyfisch (talk) 18:13, 17 June 2013 (UTC)

Restriction of sexual orientation (P91)[edit]

In my opinion some property (e.g. sexual orientation (P91)) have a restriction which are contrary to the purpose of Wikidata, as they demand (e.g.): "use IF AND ONLY IF they have stated it themselves, unambiguously, or it has been widely agreed upon by historians after their death".

But, this isn't what Wikidata was designed for. Wikidata is collecting statements, not facts! They don't have to be true, see this blog entry:

[...] Fortunately some of the roots of Wikidata lie in an EU research project called RENDER. The goal of this project is to explore and support the diversity of knowledge on the Web. RENDER discards the assumption of a simple, single truth – and this was inherited by the Wikidata data model. Instead of collecting facts, we collect statements. We define statements as claims that can have references. A reference supports the claim. [...] Without the ability to express a plurality of statements about an item – even if they are considered truths only by some and lies by others – Wikidata would fall short of one of the major pillars of Wikipedia, the Neutral Point of View and the possibility of integrating conflicting points of view. [...]

So I think we should remove the restriction and handle it like every other property too. --Nightwish62 (talk) 21:58, 17 June 2013 (UTC)

See various discussions about BLPs including WMF's relevant policy on it. It's also a bit odd that you're saying that our statements don't need to be true - we obviously want them to be. No, better to keep the restriction on P91. Ajraddatz (Talk) 22:01, 17 June 2013 (UTC)
I think you didn't read the blog. It's no odd opinion of myself, it's (as I mentioned) the purpose of Wikidata to collect statements, whatever they are true or not. Which BLP are you referring? this? They was written for Wikpedia and/or other sister project, but Wikidata has strong other requirements. --Nightwish62 (talk) 22:20, 17 June 2013 (UTC)

Ok, even better, I found this part on the Wikidata requirements:

The following requirements are not negotiable: [...]

  • 7.Wikidata will not be about the truth, but about statements and their references. These can be contradictory.

So, the property restriction counteracts to the Wikidata policy! --Nightwish62 (talk) 22:33, 17 June 2013 (UTC)

I agree that we need to do a better job on documenting claims that are not necessarily true, which is why I proposed the "according to" property. However, I think that as we move forward in this regard, we should specifically set aside statements involving living or recently deceased people; to quote the WMF Board: "we have affirmed the need to take into account human dignity and respect for personal privacy when publishing biographies of living persons." I've strongly advocated against the deletion of the sexual orientation property, but I think it's important we maintain a policy of not stating things about living people that they've made it clear they don't want to be said. (For some things, like the "killed by" property, this can be circumvented if an unambiguous finding is made by a trustworthy institution [like a judgment by a court of law], but there's no real correlate of that in terms of sexual orientation). — PinkAmpers&(Je vous invite à me parler) 00:47, 18 June 2013 (UTC)
Nightwish, that "Wikidata requirements" document that you cite was written 6 months before Wikidata ever existed and was never approved by anyone in the Wikidata community. If you read the much more relevant Wikidata:Introduction, you'll find the much much more nuanced sentence "Wikidata will record not just statements, but their sources, thus reflecting the diversity of knowledge available and supporting the notion of verifiability". Now verifiability is not explicitly defined but in every wiki, it assumes reliability of the sources. Pichpich (talk) 04:08, 18 June 2013 (UTC)
  • See also Wikidata:Living people. This is one property that will likely be a magnet for violations of that.--Jasper Deng (talk) 00:53, 18 June 2013 (UTC)
    • I should also add that BLP concerns take precedence over that requirement. It's a foundation-level policy, and a common sense one. That one is non-negotiable.--Jasper Deng (talk) 01:03, 18 June 2013 (UTC)
  • I personally interpret that line about Wikidata to mean what can be cited, not what people would consider the truth. Ultimately, unless we're coming from the standpoint of some post-modernists, there should be a truth to things, such as what someone's sexual orientation is. But I sidetrack. Jasper is right; the BLP issue overrules Wikidata's requirements. Ajraddatz (Talk) 03:48, 18 June 2013 (UTC)
  • That blog post is phrased so poorly that it's hard to take seriously. I don't feel particularly bound by one dev's opinion and his blog post is prefaced with "The essays represent my personal opinion, and are not to be understood as the official opinion of Wikidata." Yes, we want to avoid debates about truth to some extent by using qualifiers and precise sources, but only to a certain extent. We do not want (and I'm sure Denny Vrandecic doesn't want) to have the statement "Justin Bieber is a moron" with the qualifier "according to TMZ", the statement "Barack Obama is a communist" with the qualifier "according to Sarah Palin" or the statement "Vladimir Putin is Santa Claus according to my own ass". So there will be a filter and this filter, as in other Wikimedia projects is the reliability of the source. Reliable sources can still disagree and we can reflect that. However if one takes the extreme "truth, who knows what is true?" attitude, we might as well hand over the keys of the project to every conspiracy theorist (JFK was murdered by the CIA), pseudo-scientist (Bigfoot is part of the fauna of the USA) and militant (Social security in the USA is a Ponzi scheme). All these statements have been made by various crackpots and if Wikidata decides that it can't make a distinction between crackpots and credible analysts, it will be laughed out of existence and more importantly it will never be used by Wikipedia because Wikipedia doesn't treat them equally. Pichpich (talk) 03:53, 18 June 2013 (UTC)
    • Heh, funny you should mention that, since currently JFK is listed as being killed by either Oswald or "unknown value" (and yes, I'm to blame for that). That's a good piece of why I think we need an "according to" property: There's a case where two major reliable sources (the Warren Commission and the House Select Committee on Assassinations, respectively) have reached totally contradictory conclusions, and it would be disingenuous and unreliable to only list one. Anyways, I think you make a very good point on the limits of entertaining multiple POVs, but it's worth noting that there are some legitimate (IMHO) applications. — PinkAmpers&(Je vous invite à me parler) 07:13, 18 June 2013 (UTC)
  • On a slightly different topic, I think sexual orientation is a perfectly legitimate property but I agree that it should be sourced properly (as the property's definition recommends), especially when dealing with living people and that Wikipedia itself shouldn't be considered as a sufficiently reliable source in such a case. Pichpich (talk) 03:58, 18 June 2013 (UTC)

It's no fair. Here some response of you:

  • The blog is blog post is phrased so poorly that it's hard to take seriously
  • The "Wikidata requirements" document was written 6 months before Wikidata ever existed and was never approved by anyone in the Wikidata community

But the "BLP issue overrules Wikidata's requirements", even if they are also wrote before Wikidata exist and they never consider Wikidata and the new requirements / difference to the other projects. Sure we shouldn't collect every statement, otherwise we could also import data directly from Stupipedia. "Vladimir Putin is Santa Claus according to my own ass" -> No. "JFK was murdered by CIA" -> Yes, as it even has an own Wikipedia article and is widely accept. Don't forget we'll have the possibility to rank statements. Those are not only to indicate old values, but for situation like this. --Nightwish62 (talk) 05:45, 18 June 2013 (UTC)

The theory that the CIA killed JFK is not widely accepted and it's important to note that the article you point to is called "CIA Kennedy assassination conspiracy theory" and not "CIA assassination of Kennedy". The line between Stupipedia and Conspiracypedia is very thin. Pichpich (talk) 10:56, 18 June 2013 (UTC)
In the long term I see us as having three sources of data, each of which has to be approached separately:
• Other databases that are open-source: Things like IBDb are going to have lots of useful information, but the veracity might get called into question. I don't think that publicly editable databases should ever hold the top ranking in statements, but they should be included. I'd love to see the ability to have both the source URL and the retrieval date accompany anything that comes from an online source, and especially think it applies here.
• Other databases that are privately curated (such as the CIA World Factbook or Wisertrade) and other "reliable third party sources" (bread and butter Wikipedia sources): I am of the mind that we pull together the large Wikipedias' policies on reliable third party sourcing, look at what works best from each of them, and create our own reliable third party sources guideline. I am also of the mind that, when available, information from up to date, reliable third party sources should be given top billing in statements.
• First party statements: If Ford Motors states in a press release that their new 2013 Pinto Hybrid gets 37 miles to the gallon, and a reliable third party source pegs it at 34 miles to the gallon, we should include the first party claim and the third party claim. Unlike Wikipedia, there should be no issue with using first party information, so long as it's clear that it is indeed first party information.
One thing that I deliberately didn't include in this is "imported from XX Wikipedia". I'd love to reach the point where we're bypassing that (useless) statement and directly citing the source that the Wikipedia article is using, and I think that the sooner we make that changeover, the better.
With all that in mind, I think that the current restriction might be a little bit harsh; If reliable third party sources say someone is homosexual, that can be listed, but it's important to make sure that people know that the utterances of Perez Hilton and the spewings of tabloids are not reliable sources. If the person in question self-identifies, that'd be a first party statement instead. Both have a place here (but again, Globe and co are not sources that should be used in statements on this project). Sven Manguard Wha? 06:15, 18 June 2013 (UTC)

Some clarification on Denny's blog post: He was writing about the general idea behind Wikidata and it being able to accommodate many different points of view. That does not mean we have to put everything into Wikidata just because it is out there. Common sense and resolutions by the board still hold. --Lydia Pintscher (WMDE) (talk) 08:11, 18 June 2013 (UTC)

Some more clarification on the requirements: Those are requirements for the development and what Wikidata needs to be capable of - not for what we actually put into it. --Lydia Pintscher (WMDE) (talk) 08:15, 18 June 2013 (UTC)

One big problem that people seem to be happy to ignore is the impact of this on queries and on the ability of Wikipedias to include info automatically taken from Wikidata. If queries about American communists start returning Obama and other Democrat politicians or if queries about murderers start returning everyone who has ever been accused of murder, we are screwed (and in the second example, we are completely irresponsible). A few people have pointed out that eventually queries will make Wikipedia's category system obsolete but this is only true if we distinguish reliable and unreliable sources. Pichpich (talk) 10:56, 18 June 2013 (UTC)
there are no reliable sources for nothing, there are trusted sources and less trusted sources and different opinions. But everything is Data and can be stored, searched and queried. --FischX (talk) 11:35, 18 June 2013 (UTC)
As Denny laid out here the plan is to at least initially only include statements marked as preferred in query results. I'd assume these would not include conspiracy theories and similar things. --Lydia Pintscher (WMDE) (talk) 11:53, 18 June 2013 (UTC)
@FischX This post-modern nonsense will kill Wikidata because it will be considered as, at best, a poor source of information and at worst the best place to find laughable data. There are objective truths. The Protocols of the Elders of Zion is an antisemitic hoax, Elvis is dead, man has walked on the moon but has never co-existed with dinosaurs. Opening the door to statements that argue otherwise drowns legitimate data into a sea of noise. Pichpich (talk) 11:58, 18 June 2013 (UTC)
This "post-modern nonsense" is simply best practice of administering data since ages. If or if not "There are objective truths" is not interesting at all for providing data - there are only relations, thats a fact - an objective truth for everyone seriously dealing with data. What kind of Data sourced by UN or Infowars or Stupidedia or what ever are allowed to query should be up to the wiki projects. Of course we should not allow people to import from stupid sources just for practical reasons and state of the software but technical there is no reason for not allowing a query "communist persons by opinion of Tea Party rednecks" --FischX (talk) 12:21, 18 June 2013 (UTC)
Best practice since ages? Come on... And if you want to disallow stupid sources, aren't you going against your own principles? From a practical perspective, we will never get sufficiently fine-grained sourcing to allow queries that distinguish statements made by Tea Party rednecks and of course there's the issue of defining what a redneck is. Maybe we need queries like "all people labeled as communists by someone labeled as a Tea party redneck by a person labeled as a communist." Pichpich (talk) 13:46, 18 June 2013 (UTC)
Yes, best practice - according to "Datenbanken, Konzepte und Sprachen" (Andreas Heuer 1995, Page 19) it dates back to the 70ies :-) and according to our devs they can do it in a user friendly way without knowing SQL. --FischX (talk) 21:41, 18 June 2013 (UTC)

@Nightwish. I think P91 is a bad Example fo your point because the restrictions are no restrictions, because the listed conditions are the only ways the sexual orientation of person can be established.--Saehrimnir (talk) 16:17, 18 June 2013 (UTC)

But that's Nightwish's point: we don't need to establish sexual orientation, we just need to establish that someone has stated something about the sexual orientation. There's no need to distinguish rumor from fact because Wikidata doesn't care about facts. Pichpich (talk) 16:44, 18 June 2013 (UTC)
Tell me the part where I've said we shouldn't distinguish rumor from facts. --Nightwish62 (talk) 18:03, 18 June 2013 (UTC)
The direct quote is "the purpose of Wikidata to collect statements, whatever they are true or not". Pichpich (talk) 19:11, 18 June 2013 (UTC)
Aha, either it's my English skill or your reading comprehension which doesn't let you understand. --Nightwish62 (talk) 20:04, 18 June 2013 (UTC)
I'm guessing it's your English. If Wikidata doesn't care whether a statement is true or not, then it must treat rumors and facts as valid statements. Pichpich (talk) 20:25, 18 June 2013 (UTC)
Pichpich and Nightwish62, if you cannot keep this conversation civil, I will ask you both to stop contributing to this discussion. I don't like the way you two are heading. Sven Manguard Wha? 20:32, 18 June 2013 (UTC)
I'm sorry, but to allege I'm not interested to a trustable database and assume statements I never made, makes me angry. --Nightwish62 (talk) 20:51, 18 June 2013 (UTC)
(my statement): Wikidata to collect statements, whatever they are true or not <-> (your "quote"): Wikidata doesn't care whether a statement is true or not --Nightwish62 (talk) 20:51, 18 June 2013 (UTC)
Both of you are at fault here. Two wrongs don't make a right.--Jasper Deng (talk) 20:58, 18 June 2013 (UTC)

Wikidata:Requests for comment/Personal names[edit]

^ New RFC, please comment. --Yair rand (talk) 01:38, 18 June 2013 (UTC)

Sockpuppetry RfC[edit]

The RfC is not merely a proposed policy, but an attempt to develop a policy. See Wikidata:Requests for comment/Sockpuppetry guidelines.--Jasper Deng (talk) 04:18, 18 June 2013 (UTC)

GSoC Properties[edit]

Time sensitive request
The molecular biology task force needs 3 number-properties for GSoC which we could create as string-properties for now. I am still a little uncertain if those three properties could be merged into a single property with 3 qualifiers for the position in the sequence and 1 qualifier for the species. Can a few people vote on Genloc chapter, Genloc start and Genloc end? Thank you for helping out! (Link)--Tobias1984 (talk) 10:11, 18 June 2013 (UTC)
Two more properties
Link, and thank you for helping out. --Tobias1984 (talk) 15:11, 18 June 2013 (UTC)

Gadget to insert property-value pair from clipboard[edit]

I think will be good idea to have gadget which allows to insert roperty-value pair from clipboard (for example in Property | Value format, numerical values could only be supported to avoid ambiguity). May be without saving. Such gadget will allow small scale automation where time to do thing manually is smaller then time to create bot. --EugeneZelenko (talk) 13:29, 18 June 2013 (UTC)

Subclass or part-of ?[edit]

<mathematical logic (Q1166618)> was a subclass of (P279) if <mathematics (Q395)>. Imho it is a subfield which studies logics, not a class of logics whichs has instances as particular logics, so it should be a part of (P361) of maths. Am I right ? And if so, we probably need to be clearer about the part-of semantics. TomT0m (talk) 15:53, 18 June 2013 (UTC)

I wouldn't have used subclass of (P279) in this case but rather part of (P361). I think it's a better option but one could argue that it's still unsatisfactory. Do we want a ""subfield of" property? Pichpich (talk) 17:29, 18 June 2013 (UTC)

Similarly I'm not sure that mathematics (Q395) are subclass of science (Q336) (the labels in french of english are respectively science is a set of knowlegde (facts) and study and knowledge of the universe, and the answer might be different if we choose the former and the latter :) ) Anyway I do not know what would be an instance of science if it is not maths or physics. Science experiments might be part of science, scientific theories might be either. But if we choose a science as a set of scientific theories and physics as well, then physics is indeed a subclass of science. But a science is more than that. TomT0m (talk) 17:48, 18 June 2013 (UTC)


Anyway these questions are probably classical in ontologies science, where could we find existing ontologies that solves theses questions and source those statements ?

How to express several periods through qualifiers?[edit]

I'd like to express that the Port Ellen Distillery (Q203404) was founded in 1820, closed in 1929, re-opened in 1966 and definitely closed in 1983. So, I added to instance of (P31) = whisky distillery (Q10373548) the qualifiers start date (P580) = 1820, end date (P582) = 1929, start date (P580) = 1966 and end date (P582) = 1983. But after saving, the chronological order is not respected :

Is there another way to do it? Ayack (talk) 18:06, 18 June 2013 (UTC)

Check it now. I did two instances of whisky distillery, one with one set of dates, the other with the other set of dates. Sven Manguard Wha? 18:40, 18 June 2013 (UTC)
Perfect! I didn't know it was possible to add the same item twice to a same property. Thanks! Ayack (talk) 18:55, 18 June 2013 (UTC)

Fictional calendars?[edit]

Will fictional calendars (like the one of Tolkiens legendarium) also be implemented one day to the time datatype or should we create something like "fictional date (start/end)" with string datatype? There are many fictional events which should also have a time statement, e.g. when the One Ring (Q19852) was forged, destroyed or who was carrying it at which moment. --Nightwish62 (talk) 21:15, 18 June 2013 (UTC)

I have no clue if it will be, but that would certainly be an interesting and useful feature. Ajraddatz (Talk) 21:52, 18 June 2013 (UTC)

Blocking people[edit]

Can you unblock me? – The preceding unsigned comment was added by 203.184.53.105 (talk • contribs).

The English Wikipedia block, which you probably mean, is not under Wikidata's jurisdiction.--Jasper Deng (talk) 21:45, 18 June 2013 (UTC)
As above, you are not blocked here (this is shown by the fact that you can edit this page). The IP that you are editing from has been blocked from the English Wikipedia for Vandalism. Please see the talk page en:User_talk:203.184.53.105 for further details. ·addshore· talk to me! 22:08, 18 June 2013 (UTC)
Retrieved from "http://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=51419488"