Wikidata:Project chat/Archive/2013/10

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.


New milestone: Category:Sternorsidis (Q15000000) --Tobias1984 (talk) 06:12, 30 September 2013 (UTC)

Apparently about a genus of longhorn beetle, containing a species found in Borneo.[1] --Avenue (talk) 10:34, 30 September 2013 (UTC)
I was thinking that since there are a lot of duplicate item which were later deleted or skipped number, we should change the milestone from the latest number to the actual total item count. --Napoleon.tan (talk) 02:36, 1 October 2013 (UTC)

cebwiki / svwiki / warwiki category sitelinks

I noticed that many categories on cebwiki / svwiki / warwiki with the same name are scattered in different items. These category names are usually biological genus names, thus no many ambiguities are expected / possible. I guess we can bot-merge them.

Liangent (talk) 07:22, 1 October 2013 (UTC)
Most likly, User:Lsjbot is active on all of these three projects, and is probably the creator of most of them. -- Lavallen (talk) 11:06, 1 October 2013 (UTC)
At least a taxonomic categories should be merged. --Emaus (talk) 18:07, 1 October 2013 (UTC)

Historical societies

I'm pretty sure historical society (Q5774403) (eg.) California Historical Society (Q14053) a duplicate of something, but what ? What are their relations to Archivo Nacional (Q12177437) for example ? TomT0m (talk) 10:55, 1 October 2013 (UTC)

de:Geschichtsverein was linked to list of historical societies (Q1517774). I moved it.  — Felix Reimann (talk) 12:57, 1 October 2013 (UTC)

Government shutdown in the US vs Government shutdown

Hi there, I think that Q5589429 and Q15015282 should be merged, but I am not sure about how to do it. Could someone merge those two items? Thanks and greetings --Manjel (talk) 11:39, 1 October 2013 (UTC)

They're not the same. Q15015282 is one type of United States government shutdown (Q5589429). Pikolas (talk) 14:54, 1 October 2013 (UTC)
Off topic: Somebody should investigate if edits across all Wikimedia projects will increase this week. We potentially have a few thousands Wikipedia-contributors that suddenly have a lot of free time on their hands :) --Tobias1984 (talk) 14:59, 1 October 2013 (UTC)
Are you sure? Both en: and vi: are redirects, and de: and fa: are specifically about the US. The only one about government shutdown in general is ja:, and it only uses the US as an example. The Anonymouse (talk) 15:14, 1 October 2013 (UTC)
The second maybe should be free from sitelinks today, but that doesn't mean they are the same. -- Lavallen (talk) 16:04, 1 October 2013 (UTC)

commons category links

When adding a commons category to an item i can either use the property commons category or i can link to it in the "Wikimedia Commons page linked to this item" section. Which should i prefer? I mean a category is also a page, so either the property could be any page instead of just categories or it's not needed at all anymore now that we have the section? Mutante (talk) 19:38, 28 September 2013 (UTC)

Adding commoncs as langlink have one problem - these links must be 1:1. For many cases there is Commons category (P373) useful, because we can link to more pages on commons or we can link to one page from multiple items. Typically in WP are many articles and less articles, but on commons are many categories and less articles. And you can link to one category from article, category and e.g. wikiproject using Commons category (P373). JAn Dudík (talk) 05:21, 30 September 2013 (UTC)
Currently the main function of the "Wikimedia Commons page linked to this item" field is to centralise interwiki links. So whether a Commons category belongs there depends on whether this item contains the interwiki links we want to appear on the category page in Commons. If you aren't familiar with Commons interwiki linking practice (which can vary), I'd suggest the best thing to do is respect the links that on the Commons page already (if any) or leave it unlinked. If there is a gallery that also links to the same pages, then there is a conflict. I don't believe an approach for resolving such conflicts has been agreed yet, for either the short-term or the long-term, although a few ideas have been put forward.
P373 is much less problematic, and is quite independent of the "langlink" issue. Go ahead and add it if it seems to fit. --Avenue (talk) 10:59, 30 September 2013 (UTC)

New RfC is starter on related theme: Wikidata:Requests for comment/Commons links. — Ivan A. Krestinin (talk) 17:37, 2 October 2013 (UTC)

Chess games

I wonder if we are allowed to store chess games (presumably in Portable Game Notation) in Wikidata. Right now, almost all Wikipedia articles refer to sites similar to if needed but this approach has some disadvantages, namely 1) any external database can be down eventually 2) it doesn't provide references to sources like books or other publications. So basically we have two questions here: 1) can we have a corresponding property for those chess games that have separate articles like Immortal Game, and 2) should we allow storing of chess games that most likely would not have separate articles but are played by notable people. --DixonD (talk) 08:43, 30 September 2013 (UTC)

The problem is that it may not be fully within the scope of Wikidata, especially with regards to notability. I would rather use a separate datatype for denoting chess moves (PGN contains a lot of other information better-stored as separate claims).
Another issue though is that if we start storing chess games, we would have to be fair and store other games' notations too.--Jasper Deng (talk) 08:55, 30 September 2013 (UTC)
At least some chess games are notable for sure, thus it would be logical to store moves for them in some special format. But I don't see a problem with storing other chess (and not chess, actually) games as well, as somehow it is a kind of sources. And currently we allow any books to be stored in separate items, not only notable ones. So in my opinion, it wouldn't harm to store chess games but only if references to reliable sources are provided for them. --DixonD (talk) 09:09, 30 September 2013 (UTC)
As I understand it chess games in PGN format are stored in a file with the .pgn extension. The appropriate way to link to this, in my opinion, is with the proposed full text available at property with a link to the URL for the .pgn file wherever it is stored. Filceolaire (talk) 19:36, 1 October 2013 (UTC)
Actually, my whole point is that we need to store this data here, in Wikidata, not somewhere else. --DixonD (talk) 21:54, 1 October 2013 (UTC)
This would need a new datatype, you should ask developpers for that. But would probably not be verry high on their list, so you might want to code that yourself, and the API to manipulate the Datas :) Or we could create a model, with a chess move class, a chess game class; which would be a sequence of moves, it's also possible to do this in WIkidata, an would be directly accessible in Wikipedia articles, but would need a lot of statements. TomT0m (talk) 22:13, 1 October 2013 (UTC)
Yes, I'm realizing that a new datatype for such task clearly is not of the first or second or even third importance for developers with all those other things to be going on. Currently I just want to seek input from the community if such data would be welcomed at all in Wikidata. If it is welcomed, than possible ways of implementing it will be the other, next thing to consider. --DixonD (talk) 08:53, 2 October 2013 (UTC)

Permanent claims

Let's assume, for example, that we have an element of a person which has a birth date claim with a (or more) trusted source. Why should anyone be able to change this statement? Why do we have to let people change/vandalize it, if we all know that it's a true statement? Proposal: introducing trusted users who can "block" a specific claim after a verification of the sources. In case of errors, we could always ask for edit. -- 09:29, 2 October 2013 (UTC)

The software feature to tackle this problem has been called protection of individual statements by Denny (from devteam at the time). I don't know when it will be implemented, but you can ask the question on Wikidata:contact the development team. TomT0m (talk) 09:38, 2 October 2013 (UTC)

Litteral data and import tools

I've been looking into how we could massively import lots of data and how a tool for this should work. It seems like at least one such tool exist and it is probably a lot better than those we are using now when it comes to big datasets. I leave the name out for now, a lot of work is necessary to make it work properly in our context.

The tool is based upon an idea of transforming source XML by small code snippets, and then we could use the generated target XML to make the necessary API requests and JSON structures for upload to Wikidata. One of the methods for importing the source XML is to use OAI-PMH, which means a lot of data is available. Some libraries publish their complete catalogs with this protocol, not to forget that Europeana uses this protocol so a lot of data is available. Some such feeds can contain millions of records.

The tool act as a collaborative repository for transformation rules, so if some user set up the rules an other user can reuse the rules weeks or months later to update our imported version. One small note, we must be careful to update what we know is the specific source idea about correct data and not mess it up with data from other sources.

That is all the fun facts. The problem is that we (the community) do not have any clear understanding about what kind of information we do want and where to stop. This will not only be the preferred name of a book author, but it could very well be complete lists libraries that have a specific book. Likewise it could be data about lakes that not only contain various cross-sections and coverage, but also water level as time series in hour intervals for the last 200 years. The amount of data could be very big, and in fact so big that if we run such a "bot" it will overload everyone. We need some rules on what kind of data we should import and what we should just link to at external sites.

As a very coarse rule of thumb I propose we (nearly) only import literal data that can be used in our sister projects. We do not import data just to create a lot of statements in Wikidata. If we import data we should always add sufficient references to the source, if necessary both as machine readable and human readable pages. That includes links that double as identifiers, but also those cases where we chose to use identifiers that is not uris by themselves.

Does this make sense? Or should we disallow tools like this? Jeblad (talk) 15:34, 24 September 2013 (UTC)

I recall a discussion on the mailing list about a tabular data datatype (csv file for example), who could be used to store water level of different places at different datatype, so we don't have to create statements about that. TomT0m (talk) 15:42, 24 September 2013 (UTC)
See meta:DataNamespace or [2], possibly more. TomT0m (talk) 15:49, 24 September 2013 (UTC)
Ripping the structured feeds apart and storing the data as static files doesn't really make sense. I think we should build on linked data structures like Wikidata itself, and link out to other machine readable sources. The question is where do we draw the line and what kind of literal data do we store locally in Wikidata. Jeblad (talk) 15:57, 24 September 2013 (UTC)
Tabular data is not unstructured datas, it's a structure to store datas that can be stored as a table and could be useful in certain cases. It's structured if the metadata about the column and lines of the tabular datas are well defined, which does not seem to be a problem into Wikidata framework. TomT0m (talk) 16:06, 24 September 2013 (UTC)
There are currently no plans to do this and I don't see this changing anytime soon. --Lydia Pintscher (WMDE) (talk) 17:33, 24 September 2013 (UTC)
Thanks for the insight, of course the dev team did not say it was on any list, just pointing the link. TomT0m (talk) 17:42, 24 September 2013 (UTC)
Why do we need tables ? We have a structure property:value, no need of table: tables can be built from the property:value structure, it is just an extraction problem to solve and this is what will be done in phase 3 to create lists from Wikidata. Snipre (talk) 00:20, 25 September 2013 (UTC)
One reason would be to simplify the management of sources (and licenses, if it comes to that). If we have a hundred data values, all from the same 25x4 table, and some detail of the cited source for the table needs correction, it would be better to be able to do that once for the whole table than having to do it 100 times. Another reason would be to enable easy editing of row or columns as a whole. If some qualifier should be added to a column, it would better to be able to do this once for the column than having to do it for every value in the column. This is not just because doing it for each value is more work, but also because it's more error-prone. --Avenue (talk) 02:33, 25 September 2013 (UTC)
If you have a table to import use a bot and you avoid the error of manual import. There are some bots ready for that job. My problem is about use of only one piece of data from that table: you will need an extra tool which will specific to table format in order to digg into the table. Snipre (talk) 07:46, 25 September 2013 (UTC)
It's not just about importing, it's about maintenance too. Yes, bots can help, but I think tabular data is common enough that native Wikidata support would be worthwhile. Regarding data access, I think the advantage of being able to simply access entire rows or columns would outweigh a little more complexity in accessing individual values, but I take your point. --Avenue (talk) 15:43, 25 September 2013 (UTC)
In RDF this makes sort of sense if the relations are known, but in Wikibase it dos not make sense… It would be very error prone to establish the necessary relations. Perhaps if it was only limited to literal data, that is as a column of similar datatypes. Jeblad (talk) 14:17, 2 October 2013 (UTC)
Not if the format is specified, ie. we know what is in column and rows. We ca even imagine that with that knowledge, Wikidata automatically translates the table into a set of statements qualified by relevant values of row and colums, ie. that a table of population of a countries city at specific year is translated into statements with the city as subject, the population property, and the year as qualifiers, and that these statements could be antively accessible by the query engine. TomT0m (talk) 15:50, 25 September 2013 (UTC)
Jeblad External data sets can in XML, cvs, html,... there is no unique tool but for each data set you have to create a tool which is specific to the data set. Each data set is different so an unique tool is necessary. And once you have the adapted tool you can start creating statements: we have the necessary structure to source so no need to ask something. Just a detail: discuss with persons having a strong knowledge in the field of the data sets about the quality of the data sets. There are plenty of free databases which are bulls**t. Snipre (talk) 00:29, 25 September 2013 (UTC)
This is about data sets published with OAI-PMH which is basically XML with some constraints. That makes it possible to create a standardized tool for mapping the data sets to new forms like the one we are using in Wikidata. But to do so require some basic rules on what kind of literal data we want. We obviously don't want to store everything, we want to store enough for our purpose and to facilitate reuse. Jeblad (talk) 05:58, 25 September 2013 (UTC)
A tool for that would be great. I think we should then discuss what to import dataset by dataset, at least until things are clearer on Wikidata, just like for any other source. --Zolo (talk) 07:15, 25 September 2013 (UTC)
I assume from this that there is no constraints on the literal data for now, except for missing properties that may depend on missing types. There are also no limit on the overall quantum uploaded from a source. There can be constraints in the future on type, value and quantum, but no one has made any attempt on specifying any such constraints as of this writing. Jeblad (talk) 13:41, 28 September 2013 (UTC)
Constraint based class definition is extensible to do that, it is actually a feature of class definition in OWL. I saw also a proposal by Ficeolaire to restrict values based on the class of the object, by it does not apply to litterals. TomT0m (talk) 17:43, 28 September 2013 (UTC)
That would be rather far into the future as it would imply transitive (sub)classes, and we don't even have transitive properties yet. What I'm writing about is constraints given by the community. Jeblad (talk) 12:48, 29 September 2013 (UTC)
I also speak of constraints given by community. As the software has nothing to do with their checks, it's up to community to implemement that and it does not rely on the implemenation of transitive properties. If we want to do that as gadget, for example, it would rely on the simple query engine and on javascript or Lua, and it's definitly short term. TomT0m (talk) 21:10, 2 October 2013 (UTC)

Casuariidae Cassowary

en:Cassowary -> fr:Casuariidae ? ; JLM (talk) 10:14, 3 October 2013 (UTC)

I moved the French article to Q201231. Now, en and fr are linked.  — Felix Reimann (talk) 09:33, 4 October 2013 (UTC)

Wikipedia and Commons links in Wikivoyage

I noticed that links to Wikipedia articles and Commons categories is still enclosed on pages in Wikivoyage. May be JavaScript gurus could take a look and automate extraction of links from Wikidata item there? May be same thing could be done for geographical coordinates and links? See wikivoyage:en:New York City as example. Then bots could clean-up Wikivoyage pages. --EugeneZelenko (talk) 02:50, 2 October 2013 (UTC)

We have voy:ru:Template:External, which extracts Wikipedia and Commons.--Ymblanter (talk) 05:56, 2 October 2013 (UTC)
At German Wikivoyage, the voy:de:Modul:Basic and derived templates are used to present both links and coordinates. --RolandUnger (talk) 06:42, 2 October 2013 (UTC)
Looks like these templates are not always used or don't rely on Wikidata. At least in articles about New York City :-) However, I think template-less method make sense too, since it'll simplify editors job as well as pages layout. --EugeneZelenko (talk) 14:22, 3 October 2013 (UTC)
Portuguese WV uses voy:pt:Predefinição:Sites irmãs in all articles, which does rely on links from Wikidata. Texugo (talk) 23:00, 4 October 2013 (UTC)


Notifications inform you of new activity that affects you -- and let you take quick action.

(This message is in English, please translate as needed)


Notifications will inform users about new activity that affects them on this wiki in a unified way: for example, this new tool will let you know when you have new talk page messages, edit reverts, mentions or links -- and is designed to augment (rather than replace) the watchlist. The Wikimedia Foundation's editor engagement team developed this tool (code-named 'Echo') earlier this year, to help users contribute more productively to MediaWiki projects.

We're now getting ready to bring Notifications to almost all other Wikimedia sites, and are aiming for a 22 October deployment, as outlined in this release plan. It is important that notifications is translated for all of the languages we serve.

There are three major points of translation needed to be either done or checked:

Please let us know if you have any questions, suggestions or comments about this new tool. For more information, visit this project hub and this help page. Keegan (WMF) (talk) 19:25, 4 October 2013 (UTC)

(via the Global message delivery system) (wrong page? You can fix it.)

question about change number in watchlists

Hi, I'm confused by the change number to wikidata items that are being reported on my watchlist on Wikipedia. For instance, with this change to Q7735675, my watchlist says "3 changes". Is that correct? All I see is one change: the addition of a new data value (entity), or perhaps two changes if the property was also added. I've seen the same behavior many times. Am I misunderstanding this or is it a bug? Should a bug report be filed? Jason Quinn (talk) 01:30, 5 October 2013 (UTC)

It's strange because on Wikipedia it shows three changes, but on Wikidata there were only two changes made. The first one was adding a property [3], and the second one was adding a source [4]. History The Anonymouse (talk) 04:06, 5 October 2013 (UTC)
It is a bug (bugzilla:47309). It counts one too many changes. Aude (talk) 06:40, 5 October 2013 (UTC)

Pushing Wikidata to the next level

(crossposting from

In early 2010 I met Denny and Markus for the first time in a small room at the Karlsruhe Institute of Technology to talk about Semantic MediaWiki, its development and its community. I was intrigued by the idea they'd been pushing for since 2005 - bringing structured data to Wikipedia. So when the time came to assemble the team for the development of Wikidata and Denny approached me to do community communications for it there was no way I could have said no. The project sounded amazing and the timing was perfect since I was about to finish my studies of computer science. In the one and a half years since then we have achieved something amazing. We've built a great technical base for Wikidata and much more importantly we've built an amazing community around it. We've built the foundation for something extraordinary. On a personal level I could never have dreamed where this one meeting in a small room in Karlsruhe has taken me now.

From now on I will be taking over product ownership of Wikidata as its product manager.

Up until today we've built the foundation for something extraordinary. But at the same time there are still a lot of things that need to be worked on by all of us together. The areas that we need to focus on now are:

  • Building trust in our data. The project is still young and the Wikipedia editors and others are still wary of using data from Wikidata on a large scale. We need to build tools and processes to make our data more trustworthy.
  • Improving the user experience around Wikidata. Building Wikidata to the point where it is today was a tremendous technical task that we achieved in a rather short time. This though meant that in places the user experience has not gotten as much attention. We need to make the experience of using Wikidata smoother.
  • Making Wikidata easier to understand. Wikidata is a very geeky and technical project. However to be truly successful it will need to be easy to get the ideas behind it.

These are crucial for Wikidata to have the impact we all want it to have. And we will all need to work on those - both in the development team and in the rest of the Wikidata community.

Let's make Wikidata a joy to use and get it used in places and ways we can't even imagine yet.

Cheers --Lydia Pintscher (WMDE) (talk) 14:30, 1 October 2013 (UTC)

Sounds great, I'm in :). TomT0m (talk) 16:24, 1 October 2013 (UTC)
Lydia, this is great, and I am sure you will be doing quite well as the boss of the project. You are a pretty responsible person, and you will never forget to ask colleagues and community advise before taking complicated decisions. And yes, I spent two very enjoyable years at Karlsruhe Institute of Technology at some stage of my career.--Ymblanter (talk) 16:43, 1 October 2013 (UTC)
Congratulations Lydia.
Thanks folks! --Lydia Pintscher (WMDE) (talk) 08:09, 2 October 2013 (UTC)
I'm afraid I have a slightly different opinion from yours on what our priorities should be. Is there likely to be a forum created anytime soon where priorities can be discussed? Filceolaire (talk) 19:50, 1 October 2013 (UTC)
There is Wikidata:Contact the development team and this page that I will be monitoring for input as we have done before. And of course the things I mentioned will need to be tackled in addition to moving the project forward on a technical level. That being said I will not be able to make everyone happy. The whole point of this position is to say no to a large number of requests to create a coherent product. YSou all need to be aware of this. I will of course do my best and I will listen to reasoned arguments. --Lydia Pintscher (WMDE) (talk) 08:09, 2 October 2013 (UTC)
Lydia and I also exchanged emails about priorities on the wikidata email list. Filceolaire (talk) 13:52, 5 October 2013 (UTC)
/me confused… I thought Wikibase had a product manager from WMDE as that is the product they develop. Wikidata as a service is managed by WMF, while the content is more or less "unmanaged". It could also be interesting to know if there is anyone with the role as product owner and if there are any thoughts on getting user representation during demo time. Jeblad (talk) 07:12, 2 October 2013 (UTC)
I am the product owner. Getting more user representation is on my list of things to do but there are no concrete plans yet. If there are any other issues/questions let's discuss those between the two of us. --Lydia Pintscher (WMDE) (talk) 14:24, 2 October 2013 (UTC)
This is good news! Congratulations Lydia. Emw (talk) 23:40, 4 October 2013 (UTC)

Label, name and properties ...

When something, say an organisation, changes its name, we could express this by a generic name property, and start and end date qualifier. But the name of an organisation is usually set in the label of the item, and not in the statements ... should we create that generic name property ? TomT0m (talk) 14:00, 2 October 2013 (UTC)

I guess it's something a bit different. The label of the item could be not the official name for organization but the most well-known name which is not necessarily the same (even it is true in 99%, let's say, cases for organizations). --DixonD (talk) 14:50, 2 October 2013 (UTC)
There is aliases for that :) but it's a different question, and we cannot put qualifiers on labels. TomT0m (talk) 15:22, 2 October 2013 (UTC)
I guess the label will be used when we create links on WP et al. It will look like: [[sitelinke|label]] if we not explicitly choose to use any other property like [[sitelink|nameproperty]] or any other designed text in the link. -- Lavallen (talk) 17:54, 2 October 2013 (UTC)
Wikidata:Property_proposal/Pending#Official_name_.2F_Name_.2F_Nom_.2F Liangent (talk) 21:04, 2 October 2013 (UTC)
Organisations can have several "official names", the main one being the full registered legal name, e.g. John Smith & Sons Limited, plus any trading names, e.g. J.S. & Sons. One possibility is for 2 properties full legal name and trading name. This data, along with dates, is usually freely available on company registrar websites. This is part of the reason why I have proposed this Wikidata:Property_proposal/Organization#UK_company_no._.28en.29 UK company no. (en). We have to have company numbers (for all countries) in place, before we can reliably source other details. This is the way to uniquely ID companies. Names alone, don't cut it, due to some names being very similar, e.g. John Smith & Sons Limited compared with John Smith and Sons Limited (2 different companies). --Danrok (talk) 01:25, 3 October 2013 (UTC)

-- 10:59, 3 October 2013 (UTC)-- 10:59, 3 October 2013 (UTC)== Casuariidae ==

We already have P513 (P513) (datatype string). Among the Pending properties is official name (datatype monolingual text) and under consideration is name (datatype being discussed). I think these should all be replaced with one 'name' property with a qualifier to tell if it is an instance of (P31):birth name, official name, pseudonym, nickname, stage name, art name or whatever. That way all these names have exactly the same structure: property:'name' + qualifier:'instance of' which should make it much easier for infoboxes or queries to find this data. Filceolaire (talk) 14:13, 5 October 2013 (UTC)

Countries ranked

As many folks enjoy country rankings, I have generated a list of countries ranked by number of coordinates in Wikidata. Note this data is from the September 22 database dump. There are a total of 737,271 coordinates in Wikidata.

Top countries are....

  1. US
  2. Russia
  3. UK
  4. China
  5. France

See the full list at User:Aude/countrystats (which also has a few items entered for P17 that are not really countries). Cheers. Aude (talk) 21:27, 4 October 2013 (UTC)

See also Wikidata:Bot requests#P625 and Swedish localities, I am still missing P625 in many items. -- Lavallen (talk) 06:45, 5 October 2013 (UTC)
It should be possible for my bot to work on Sweden / Swedish Wikipedia soon. According to my information, there are 36,325 geocoded articles in Swedish Wikipedia that are located in Sweden. Only a very small percent have Wikidata coordinates and it also appears that a lot of the place articles are not in Wikidata at all. (e.g. no items) The bot should be able to add them with coordinates. Aude (talk) 07:48, 5 October 2013 (UTC)
Put some questions on the bot request page about Swedish Wikipedia. Aude (talk) 07:54, 5 October 2013 (UTC)
Fun, but what proportion of items with coordinates have their country property set ? I guess a more reliable count could be a made by checking to which country the coordinates correspond, as you seem to have done for detecting errors. --Zolo (talk) 15:30, 7 October 2013 (UTC)

Geocoding errors

I have all the coordinates loaded in to PostgreSQL / PostGIS to allow spatial queries, etc. I found numerous items (see User:Aude/coords-us) that have Property:P30 (country) = US but are geocoded in China or elsewhere. Probably confusion about east / west when adding coordinates to Wikipedia and then the errors got imported to Wikidata. Some might be outlying US territories and be okay. If anyone wants to help check and fix these, it would be appreciated. I would like to make more such reports and ideally make this into a tool to help check for errors. Cheers. Aude (talk) 19:57, 6 October 2013 (UTC)

Thanks for compiling the list. There is a surprisingly high share of the National Park items with east and west confused (and ok in Wikipedia). Could it be a systematic error of the script?--Ymblanter (talk) 07:12, 7 October 2013 (UTC)
There could be a systematic error at some point. Many of the errors I found are sourced to Russian Wikipedia. Spanish Wikipedia is also problematic for coordinates (e.g. they sometimes define coordinates like -33.87230 N, 151.19896 E for Australia) and there are error in other Wikipedias or due to errors in import scripts or human error, perhaps. Aude (talk) 08:14, 7 October 2013 (UTC)

List of none exist links

Hi, How can I find list of items which have none exist links (Red links or deleted pages) to fa?

for example I came across with this , in this item the first link was moved and deleted but in wikidata they didn't update it. by sure many of categories which are moved by in locale wikis have this problem! please make this list especially for category name spaceYamaha5 (talk) 13:57, 7 October 2013 (UTC)

Wikidata API and article in full text format

Hello, for some coding courses, I would like to use raw texts from wikipedia articles using the Wikidata API. I heard there is a way to get a whole article, or section of it, or sentences of it in raw text format without wiki sysntaxe nor html syntaxe. I already looked in the API for keywords "article", "content", "raw", "text", but found nothing. Does someone knows either the api url to get such raw text (for let's say article Cat / Q146), or some hints/keywords so I may find in the API by myself. --Yug 13:17, 7 October 2013 (UTC)

Not quite shure what you need but wbgetentities [5] is perhaps what you want. You can choose different formats for the representation of the plain information of an item, see [6] for Q42.  — Felix Reimann (talk) 05:05, 8 October 2013 (UTC)

Problem with adding property

It seems there is no Help desk for Wikidata contributors, but I would like to ask a little help on adding a property. I tried to merge Q3798581 into Q1753397, but on the first page there is a property "BNCF Thesaurus code" and when I tried to add this to the second page, it did not show up as a link like it should. Also I was not able to add the source of the property (Q460907 or Biblioteca Nacional Central de Florencia), I just couldn't click on 'Save'. I have had this last problem nearly always when I tried to add sources but in this case it is necessary to complete the merge.

Can you explain to me how to add a property like this above? Best regards, Bever (talk) 21:50, 7 October 2013 (UTC)

I've add the "imported from National Central Library of Florence" to Q1753397. You needed to type in "imported from" as a property first, then once you enter "National Central Library of Florence" press enter. Delsion23 (talk) 22:19, 7 October 2013 (UTC)
Thank you. It might be nice if there were a "sandbox item" to try things like this. :-) The other problem I mentioned was apparently because I had to refresh the page (F5) to see the link correctly. Bever (talk) 23:54, 7 October 2013 (UTC)
Wikidata Sandbox (Q4115189). --Yair rand (talk) 00:02, 8 October 2013 (UTC)
The reason it didn't make a link is because the link is created by a Javascript file. You simply need to refresh the page next time after you've added the new claim to get the link to show up. --Izno (talk) 00:13, 8 October 2013 (UTC)

Perieges merging

Both these items refer to the same genus of bugs (Perieges):

Please help in merging. Many thanks in advance.--Paracel63 (talk) 14:37, 8 October 2013 (UTC)

  Merged See Help:Merge for more info. The Anonymouse (talk) 14:49, 8 October 2013 (UTC)

Speak up about the trademark registration of the Community logo.

Adding a page

I wanted to add this page which does not have any language links, but it says it already has language links but when I go there it only has itself and noone else. How do I merge them?  – The preceding unsigned comment was added by Is in the 1sie (talk • contribs).

If you would provide the links in question, we might be able to help merge them. The complete information about merging is at Help:Merge. The Anonymouse (talk) 03:41, 9 October 2013 (UTC)

Location subclasses

Please take a look at this tree [7] there is a big big confusion on location subclasses --Rippitippi (talk) 01:48, 4 October 2013 (UTC)

I'm not suprised, do you have any ideas?
My opinion is that "administrative division" first have to be divide by country (and in fedral states often by state) instead of on what kind of word is used to describe them in one language. (Like parishes in Louisiana compared with parishes of anywhere else.)
Something like
administrative division
     administrative division in United States (US is a federal state and smaller entites are subjects of the State, not of US)
          administrative division in Alaska 
               bouroughs in Alaska
          administrative division in California
               counties in California
     administrative division in Sweden (Sweden is a unitary state and smaller entities are not subjects of larger)
          counties in Sweden (two kinds of counties)
               counties in Sweden (1634-) 
               castle fiefs in Sweden (-1633)
          provinces in Sweden
          municipalities in Sweden (several kinds of municipalities)
               county counsils in Sweden (yes, they are municipalites, it's only in English they have "county" in their label)
               municipalities in Sweden (1971-)
               rural municipalities in Sweden
               köping-municipalities in Sweden
               city-municipalities in Sweden
               municipalsamhällen in Sweden
               city/town in Sweden (-1862)
          urban areas in Sweden
               urban areas (1960-)
               urban areas (1950)
               weekend homes
               minor urban areas
               administrative urban areas
               city/town (1971-)
          parishes in Sweden (a semi-clergal division until 1999)
          districts in Sweden (2016-)
     administrative division in Italy
-- Lavallen (talk) 06:56, 4 October 2013 (UTC)
I agree, it is not a very trustful/useful tree at this moment (chaos). I think each country should have an item "Administrative division of <country>" and all subdivisons of the country should be a subclass of that item. Michiel1972 (talk) 11:49, 4 October 2013 (UTC)
I tried to list all the relevant classes on the Property_talk:P132 page. Most countries don't have an "Administrative divisions of Foo" as a separate article - mostly it's a section of the country article - but I did find a few. Note that many items appear more than once on this tree. 23:09, 4 October 2013 (UTC)
Is there any plan to assign the administrative divisions automatically, based on the geographical coordinates of the item? -- Jeromeflipo (talk) 12:32, 4 October 2013 (UTC)
I guess you then have to make it three-dimensional (lat, long and time), since borders change all the time, and can be unclear or disputed. -- Lavallen (talk) 13:15, 4 October 2013 (UTC)
For a bot to assign items to an admin division it needs to know the boundaries of that division and the 'geographical shapes' datatype is not available yet and seems unlikely to be available for some months, though the OSM relation ID (P402) property can be used to link to GeoShapes on Open Street Maps. You can of course have multiple GeoShapes border maps with qualifiers for 'start date' and 'end date' to track the changes to borders over time. Filceolaire (talk) 14:24, 5 October 2013 (UTC)
I agree with Lavallen, but i think we need also add to item istance of administrative division and/or is a populated place since wipediadia in most case merge it in one voice --Rippitippi (talk) 16:28, 9 October 2013 (UTC)


en:Sebakh is the closest thing to fr:Sebakhin, although not exact. I tried to link them, but it didn't work. Y-barton (talk) 05:17, 9 October 2013 (UTC)

Looks like it has been   Done: sebakh (Q907879). The Anonymouse (talk) 16:14, 9 October 2013 (UTC)

Complex queries

Would wikidata support complex queries for obtaining items (to provide features of reference database), like "All references of subject 'X' but not sub-subject 'XX' from 1990 till 2010 from German authors"? --AS (talk) 09:56, 9 October 2013 (UTC)

I think that it will be supported when the query feature is implemented. The Anonymouse (talk) 16:18, 9 October 2013 (UTC)

About high and low level classification

I just saw that a bot added a classification statement to Modern Language Association Style Manual (Q8014), saying it's a creative work. I think creative work is a hard notion and that it's much easier to determine what a manual of style is ... It's not really much of an improvement from the GND main type classification. What can we infer from the fact that it is a creative work ? TomT0m (talk) 12:26, 9 October 2013 (UTC)

The close of the RFC was not well done. The bot operators were advised (for whatever reason) simply to copy GND main type into the instance of claim for further refinement. --Izno (talk) 00:13, 10 October 2013 (UTC)

Lang Link confilicts

According to #List of none exist links:

I developed a code which can report wrong interwiki conflicts between two local wikis. most of these conflicts should solve in local wiki by removing old (wrong) interwiki and some of them should be solve in wikidata. solving these conflicts needs many Local users and bots.

The code is User:Yamaha5/ConflictBot. it will report pages which are like these

  • fa:foo > en:foo > fa:otherpage
  • fa:foo > en:foo > nopage or deleted page
  • fa:foo >en:category:foo or other namespaces

The code should be run on labs. I run it for fa and en wikis and we had more than 500 conflicts for category and more that 2000 conflicts for main space! (Now most of them are solved) :) Yamaha5 (talk) 20:21, 9 October 2013 (UTC)

Help the development team prioritise!

All of the bugs that are found on wikidata are reported to All current open bugs can be seen on this list (ranked by the number of votes each bug has)!

We want to try and tackle the bugs which matter most to you! To help us identify which bugs you would like to see fixed go the the list and vote! To vote simply click on the bug and click the vote button next to the header labeled "Importance".

We can't promise that we will always tackle bugs according to the number of votes as it will not be the only datapoint used to prioritise but we will take them into account. So if there is a bug that is really important to you go and vote for it!!

Adam Shorland (WMDE) / ·addshore· talk to me! 13:22, 8 October 2013 (UTC)

Hmm, those are currently 650 bugs you want us to review. What about the Wikidata:Paper cuts, where 12 issues have been classified as "real paper cuts" ("easy to fix but have a large impact on making Wikidata more enjoyable to use") by Lydia since weeks, but almost none has been fixed since? (Actually, three of the linked bug cases are marked as fixed, but none of the issues has been moved to "already fixed", I did not check whether those fixes are live yet.) --YMS (talk) 13:54, 8 October 2013 (UTC)
No you don't need to look at all of them obviously. (This is what I am doing right now... -.-) But if you know about some you care about please do vote. The list is there to make it easier for you to do a search. As for the paper cuts: We've been working on some of them over the past week. I'll need to take the time to update the page. --Lydia Pintscher (WMDE) (talk) 13:59, 8 October 2013 (UTC)
Also if the bugs are marked as fixed they should be deployed / live on Monday 14th October which is our next deployment date :) Adam Shorland (WMDE) / ·addshore· talk to me! 17:28, 8 October 2013 (UTC)
Add a vote from me to "47930"! -- Lavallen (talk) 18:24, 8 October 2013 (UTC)
Tillsattes :) --Stryn (talk) 19:27, 8 October 2013 (UTC)
Vote for Support transitive properties in SPARQL queries (bug 50911) if you're interested in using Wikidata to build family trees, find out what towns / cities are in a certain country, or build type hierarchies with 'instance of' and 'subclass of'. Being able to efficiently make deductions from transitive properties is a core feature of querying in the Semantic Web. Having this feature would enable really compelling applications. Emw (talk) 21:29, 8 October 2013 (UTC)
Can I vote for more than one proposal, or do I have to stick with just one? --Jakob (Scream about the things I've broken) 21:54, 8 October 2013 (UTC)
You can add votes to as many bugs as you want. --Lydia Pintscher (WMDE) (talk) 21:56, 8 October 2013 (UTC)
as long as you don't want to vote for more than 1000 bugs. --YMS (talk) 06:26, 9 October 2013 (UTC)
I could reiterate my could old request which may be trivial to fix, but will simplify life of users like me: item reference in "Add links" (bugzilla:49105 is marked as fixed, but item reference is not there) and Wikidata address prefix/suffix removal during property value adding. --EugeneZelenko (talk) 01:45, 9 October 2013 (UTC)
Can you please elaborate what's still missing for you? I don't think I understand it yet. --Lydia Pintscher (WMDE) (talk) 08:09, 9 October 2013 (UTC)
I believe the fix for this bug is the link in the toolbox to the wikidata item named 'data item' and also the ID of the data item in the page info. (These are both deployed). Potentially they are not quite what you were expecting? Adam Shorland (WMDE) / ·addshore· talk to me! 09:21, 9 October 2013 (UTC)
No, I meant URL for adding interwikis ("Add links"). See w:ru:Ткач, Татьяна Дмитриевна as example - it doesn't refer to existing item. For second thing I want to copy URL from "Edit links" (<Item ID>#sitelinks-wikipedia) and insert it as property value and I'd like prefix and suffix to be removed automatically. Same as File: prefix removed for media files. --EugeneZelenko (talk) 14:23, 9 October 2013 (UTC)
Some infos:
  • bugzilla:52916: implementation of number datatype. I think the most important step to reach the critical state which can attract new contributors.
  • bugzilla:47930: In wikipedia articles access items which are not connected to the current page. Critical to developp lua modules for infoboxes.
  • bugzilla:44678: Possibility to change statements order. The list of statements can be very long in some items: a better statements organization can help to visualize missing properties. Snipre (talk) 07:50, 9 October 2013 (UTC)
+1 for bugzilla:47930: The taxobox requires a mw.wikibase.getEntity('Q662672'), see Vipera berus on testwiki.  — Felix Reimann (talk) 08:19, 9 October 2013 (UTC)
All of those are high on my list. Numbers is getting close as well as ordering. Access to arbitrary item data is important but a tough one so it'll take a bit longer. --Lydia Pintscher (WMDE) (talk) 09:27, 10 October 2013 (UTC)
You have your own schedule, so go at your speed. Just be aware that use of wikidata in Wikipedia is dependent on that feature to developp infoboxes. 11:45, 10 October 2013 (UTC)

a redundant feature

When adding a new commons interwiki link for an item, you'll be asked to enter a language code. It seems to be unnecessary, because you can not choose any languages except En for wikimedia commons links.--دوستدار ایران بزرگ (talk) 14:57, 9 October 2013 (UTC)

This is a known issue. According to this, it might be fixed around October 14. I thought there was a bug report for the issue, but I can't seem to find it at the moment. The Anonymouse (talk) 16:30, 9 October 2013 (UTC)
Yes the situation will improve with the next deployment. However it'll not be quite what you're asking for sine the long-term plan is to add the other projects that do not have several language editions in the same group. --Lydia Pintscher (WMDE) (talk) 09:36, 10 October 2013 (UTC)


Can someone merge German article Richard Fiedler with English article Richard Fiedler. 13:01, 10 October 2013 (UTC)

I don't understand German (just few words), but I think that Richard Fiedler (Q1756198) and Richard Fiedler (Q1377322) are not about the same person. --Stryn (talk) 13:36, 10 October 2013 (UTC)
They are different persons. --YMS (talk) 13:49, 10 October 2013 (UTC)

List of qualifiers

Is there a list of all qualifiers currently available, and a page to propose new one for existing properties?  – The preceding unsigned comment was added by Freedatum (talk • contribs).

Technically, qualifiers are no different than properties; the only difference is their usage. Currently, there isn't a list of qualifiers, but qualifiers are mixed with properties at Wikidata:List of properties. Wikidata:Property proposal is the place to propose new qualifiers (as well as properties). The Anonymouse (talk) 16:43, 10 October 2013 (UTC)

Ig Nobel Prize winners

Hi all. I'd like some community feedback on this. I've recently been adding the statement award received (P166) to some Ig Nobel Prize winners, along with the qualifiers point in time (P585) and field of work (P101). But field of work (P101) doesn't seem like a perfect match, such as for people who won the award in categories such as Peace. That's the closest fit though. What do you guys think? Pikolas (talk) 16:36, 10 October 2013 (UTC)

Destination banners: Shared between Wikivoyages, could they eventually belong to WikiData?

(low-priority) In April, the English Wikivoyage started adding "banners" at the top of each article for esthetic reasons, see for instance Ubud. Other languages have followed trend, and are adding the banners to their articles, copying Commons file URLs back and forth. That strikes me as a task where WikiData could help. Each place would have a "banner" Commons file URL. Is it something that WikiData could do in the far future? Or is it fundamentally unacceptable because it is kind of "artistic/editorial" instead of being pure data? Nicolas1981 (talk) 03:57, 9 October 2013 (UTC)

See Wikidata:Property proposal/Place#Wikivoyage banner. --EugeneZelenko (talk) 14:28, 9 October 2013 (UTC)
And now see page banner (P948). John F. Lewis (talk) 18:51, 9 October 2013 (UTC)
Wonderful! Nicolas1981 (talk) 01:46, 11 October 2013 (UTC)

Apocalyptic and post-apocalyptic fiction / Utopian and dystopian fiction

These two items, utopian and dystopian fiction (Q358998) and post-apocalyptic fiction (Q197949), represent four genres. Would it be best to create four new items, which can be used with genre (P136)? --Danrok (talk) 20:01, 10 October 2013 (UTC)

I believe that's the way to go. I actually just created Q15058013 & Q15058009 since in French wiki (and a few others) the articles specifically address post-apocalyptic fiction only, yet they were linked to post-apocalyptic fiction (Q197949); also, Category:Post-apocalyptic fiction (Q7112371) is now linked to Q15058009. - LaddΩ chat ;) 22:08, 10 October 2013 (UTC)

Recent changes

why in recent changes page there are many bots? --Rippitippi (talk) 23:11, 9 October 2013 (UTC)

Bots do lots of changes, it is not unexpected to me.
I rather got another question : why do we still see a large number of bot changes when we set "Hide bots" in Recent changes ? LaddΩ chat ;) 02:23, 10 October 2013 (UTC)
this is the question since default setting is hide bots --Rippitippi (talk) 02:37, 10 October 2013 (UTC)
I think that it's just User:ValterVBot. I left a note on the operator's talk page. The Anonymouse (talk) 04:51, 10 October 2013 (UTC)
Thanks for the note. I stopped the bot for now. --ValterVB (talk) 05:48, 10 October 2013 (UTC)
I think I spoke too soon... User:CalakBot is also flooding Special:RecentChanges. Perhaps this an API issue? The Anonymouse (talk) 05:53, 10 October 2013 (UTC)
I guess not since most bots are still only showing here. The Anonymouse (talk) 05:57, 10 October 2013 (UTC)
I guess it maybe is, since the Wikidata-api have a possibility to opt-in/out for flaged bots. That is not possible for bots in other projects, as far as I know. -- Lavallen (talk) 06:26, 10 October 2013 (UTC)
I don't know what is the problem. My bot has bot flag here and I don't have this problem on other projects. Probably this is a bug of Wikidata. I try to get global flag for solving this problem. Thank you.--Calak (talk) 08:28, 10 October 2013 (UTC)
Are you using &bot= in your api? If you look into action=wbsetlabel for example, there is a option to set &bot= into your api-requests. If you do not use this, your edits will be visible as an ordinary user in RC. -- Lavallen (talk) 08:48, 10 October 2013 (UTC)
No, with this api, I run my bot on other projects and I don't have any problem.--Calak (talk) 14:13, 10 October 2013 (UTC)
The other projects have other api. -- Lavallen (talk) 14:22, 10 October 2013 (UTC) s
Checked, sorry for the problem, I have modified my bot and I have forgot to add &bot= --ValterVB (talk) 17:49, 10 October 2013 (UTC)
My problem resolved.--Calak (talk) 10:38, 11 October 2013 (UTC)

Bot request not appearing in requests list

I wrote this bot request.

It did not appear in the requests list, is it normal? I added the paragraph manually but it still does not appear in the TOC. Maybe because I mistakenly called it "Nicolas1981Bot 1" at first? Nicolas1981 (talk) 09:35, 11 October 2013 (UTC)

Just wait more I think. It is updated by bot, and it takes some time. Correcting: It's in the TOC, but not in the table on the bot requests page, which is updated by bot. --Stryn (talk) 09:52, 11 October 2013 (UTC)

Linking problem in article Q12813509

I have tried to link our hu:Adórendszer (Q12813509) to de:Steuersystem (Steuerrecht) (Q1468865) unsuccessfully. Maybe because both has already item code. So I think Q12813509 should be deleted before linking together but I am not too sure and I gess I do not have permit deleting. Could someone help please? Ato 01 (talk) 10:27, 11 October 2013 (UTC)

  Merged It is not possible to add the same link to two entries at the same time. So one has to be removed and added to the another. This is done at Wikidata all the time. See WD:M --Glaisher [talk] 12:08, 11 October 2013 (UTC)
Thank you. Ato 01 (talk) 12:23, 11 October 2013 (UTC)

Languages for Joseph J. Sandler



should be merged. It is the same person.  – The preceding unsigned comment was added by (talk • contribs).

Done. Thanks for the report. If you want to do that yourself next time, see Help:Merge. --YMS (talk) 16:59, 11 October 2013 (UTC)

Guidelines for coordinates

When the item is not a simple point, multiple locations could be chosen for the coordinates property. I think we should have guidelines to insure consistency and easier reuses in WIkipedias. As a small first step, would you agree with the following guidelines for line-like object.

  • use applies to part (P518): "midpoint" (Q1645406) to mean the point of the line that is at equal distance of the beginning and the end, when following the line (that is for a mouth the mid-point is the point of the river that is at equal distance of the source and the mouth when following the river, not the mid point of the straight line joining the source and the mouth and that is most likely not located on the river).
  • for rivers: use P518: Q1233637 (river mouth) for the mouth, and P518: Q7376362 (river source)
  • for directed lines (like streets with house numbers). Use P518; Q15053706 (starting point) and Q15053716 (end point)
  • for lines with no clear direction (perhaps canals), use Q15053716 (end point) for both points. Actually I am not completely sure it makes sense to use the same item for directed and undirected lines.

Of course that does not mean that we cant have other points, nor necessarily that all these points should always be used, just that when they are provided, they should be provided this way; --Zolo (talk) 15:44, 7 October 2013 (UTC)

Why so complex guidelines ? For a river, a street or canal use Q15053706 and Q15053716 to describe both ends. And to offer a way to define Q15053706 from Q15053716 use flow or elevation. Street ends can be defined according to the houses numbering. So one unique way to describe which simplify the data extraction in client.
And I don't think that midpoint is useful. Better add extreme coordinates like the extreme north, south, east and west positions, this will give you a surface which is a better information about the line you want to describe. Snipre (talk) 18:36, 7 October 2013 (UTC)
The reason for using "source" and "mouth" is that it sounds more natural. It may have some advantages for the client (for instance, if it does not know the particular of Wikidata's conventions, it could would show it as "coordinates (source)" instead of the rather clumsy "coordinates (starting point)".
I think we need some central point, even though I do not know whether it should be the midpoint of something else. The coordinates displayed at the top of en:Champs-Élysées should be more or less at the center of the Champs Elysées, not at one end. In many cases, the midpoint can be computed from extremities, but that is more complicated than just extracting one coordinate, and if the street does not go straight, it would give a point that is actually not located in it. --Zolo (talk) 19:28, 7 October 2013 (UTC)
Why not implementing geoshapes on our own ? A geoshape is usually no more than a list of points. We need a class Geoshape and a model for it, that's all. TomT0m (talk) 19:47, 7 October 2013 (UTC)
Even with geoshapes, I think that some dedicated statements for notable points would be useful (and we would still need statements for the points that cannot be covered by the geoshape, like the highest point, so that would not really add a layer of complexity).
The development team planned a geoshape type, and I would not "try it at home" unless it is clearly and irrevocably abandonned. That sounds like a hell to manage cleanly. --Zolo (talk) 20:12, 7 October 2013 (UTC)
We have tons of geoshapes on the English Wikipedia already: see w:en:Template:Attached KML. --Rschen7754 21:33, 7 October 2013 (UTC)
I think that at the moment, Wikipedia and better equipped than Wikidata for that. In Wikidata, if you need to add a qualifier or a source to the geoshape, you need to do it to all of its potentially hundreds of points. And it may become very confusing when we need several geoshapes for the same item (say, because there are several different version of the borders of Israel). That is not totally impossible, but if we can get a proper datatype for that in a few months that seems much better to wait until then. --Zolo (talk) 07:18, 8 October 2013 (UTC)
No, the best solution would be to have an item for the geoshape itself, and to source the statement in the geobject that it is its geoshape, sounds quite simple, and easy to migrate later. Of course a proper datatype would be probably better, especially because it might have geoshape operations implemented in the query engine, but I don't know if this is planned :) TomT0m (talk) 09:15, 8 October 2013 (UTC)
Previous discussion: Wikidata:Property proposal/Place#coordinates of the beginning (en) / координаты начала (ru)/ координати початку (uk). Are you sure that infoboxes can handle multiple P625 values correctly? Scheme with tree properties is more simple to use and support: P625 for middle point + property for mouth + property for source. — Ivan A. Krestinin (talk) 20:35, 7 October 2013 (UTC)
You need some Lua, but it is rather simple. In fr.wikipedia, this you can use {{#invoke: Wikidata| formatStatements|property=P625|qualifier=P518|qualifiervalue=Q15053706}} to get the coordinates of the starting point. --Zolo (talk) 21:04, 7 October 2013 (UTC)
P625 is already used in many templates. Currently its do not contain some code for multiple values handling. I am not sure that rewriting all these templates is good idea. Another sample: somebody wants link his geo-service with Wikipedia (like Google in the past). Currently he must extract all P625 values and sitelink for required language. This one-to-one table can be easily extracted and easily handled. Another situation: you allows multiple P625 values. Most part of objects will have one coordinate value, but some object will have two, three or possible more. Programmer must additionally find answers to questions: what multiple coordinate values mean? what is qualifier? how to extract and handle qualifiers? what qualifier values are used with P625? why some items contain multiple P625 values without qualifiers? what to do with unexpected qualifier value? and etc. We must think about data users. It is bad approach to create complex data scheme when simple scheme is possible. — Ivan A. Krestinin (talk) 22:30, 7 October 2013 (UTC)
It's not more difficult to handle one property with several values with qualifiers than one value in several properties. This far has I only added this property to templates where I only expect one value and I then collect that from the first instance of that property. The difficult situation to handle in both cases (with one or several properties), is when one WP require one value, while another require two or more. -- Lavallen (talk) 05:26, 8 October 2013 (UTC)
There are cases where we cannot use a separate property anyway. For instance, if the item position changes with time, a date qualifier certainly makes sense. As long as it is possible to have several values for the same propertiy, Wikipedias need to be able to deal with that. That said, I think we should really try to have more centralization of sister-project transclusion tools. When everyone does it on its own, it is very difficult to keep it up to date with Wikidata data-structure. --Zolo (talk) 07:18, 8 October 2013 (UTC)
Svwp has no tradition of having several coordinates in one infobox. (In one article, yes, but not in one infobox.) I do not think it would be simple to change such traditions, only because users on another project (i.e. Wikidata) think it should. Au contraire, I think it would be contra-productive for the goodwill of Wikidata to try to force any change of that kind to the wp-projects, especially to a such technique-sceptical project like svwp. And of course, we have to handle cases when the property changes by time. This far, it hasn't been necessary. -- Lavallen (talk) 07:35, 8 October 2013 (UTC)
Actually, you cannot have more than one "main" coordinate par article (the coordinates extension - or whatever - shows a "primary tag" error). How to display data is up to the individual projects, but I think that whenever possible, we would benefit from common tools to extract relevant data, instead of restricting the range of data acceptable in Wikidata just because Wikipedias do handle them properly. In this case, that would be a few lines in a module, telling that when there are several coordinates and we need only one, it should be by default the one with the most recent date qualifier, and with P518 = "midpoint", or "centre of gravity" etc.. --Zolo (talk) 07:54, 8 October 2013 (UTC)
Yes, and we maybe want to have something like "mayors office" for municipalites/cities etc. Me, personally, I think that is more accurate for a municipality than the "midpoint", a midpoint that can be located in a place where no man has set his foot for decades. -- Lavallen (talk) 08:01, 8 October 2013 (UTC)
I was only proposing guidelines for line-like objects like roads and rivers because it is relatively simple. We should also have guidelines for surface-like objects. For administrative divisions, it seems that the French Wikipedia more often uses the administrative center than the geometric center, but it is almost never made explicit. Wikidata would be an occasion to change that. --Zolo (talk) 08:39, 8 October 2013 (UTC)
It's not very meaningful to have only one point for something that is really not a point. Plus there is already convent EDIT: oops I messed up sending this, I wanted to drop the post TomT0m (talk)
The only thing I know, who really is a point, are black holes, and I doubt, that is the only thing that should use the coordinates-datatype. -- Lavallen (talk) 09:26, 8 October 2013 (UTC)
Exactly; we really should be waiting for the geoshape datatype rather than trying to add coordinates to linear or polygon objects. --Rschen7754 08:56, 9 October 2013 (UTC)
I think this is an excellent idea. Use coordinate location (P625) for the coordinates and applies to part (P518) as a qualifier to tell what type of coordinate it is. This same data structure can be used for many types of item. Infoboxes don't even have to understand the items referenced by P518 - they can just copy the item label and put that label in brackets after the coordinate it refers to. Excellent idea. Filceolaire (talk) 17:31, 8 October 2013 (UTC)
My unfinished not supposed to have been posted post was up to be finished by something like "there is already conventions, for city for example a GPS or google maps uses the coordinates of the mayor office for routing to a city." But there might be an item for the mayor office. TomT0m (talk) 09:15, 9 October 2013 (UTC)
Thanks, in some cases, infoboxes need to understand the meaning of the P518 though. For instance, fr:Template:Infobox Canal shows the coordinates of the endpoints of a canal. --Zolo (talk) 07:37, 9 October 2013 (UTC)
  • I guess we all agree that geoshape would be a useful datatype. The last dev team comment I hear on it was "planned but not a high priority". So we still have some time to wait, and even then coordinates points would still be useful for some purposes. If you want to get the coordinates of a river source, a point coordinate is much more convenient than a geoshape (or any other type of multipoint datatype). So we will still need point coordinates, but we need to use them in such a way that there is no ambiguity about their meaning. Some cities have their coordinates at the mayoral office, but New York City (Q60) and Paris (Q90) have theirs at an apparently unremarkable place that seems to be near their geographic center. London (Q84) has it in Charing Cross, that is the point from which distances are caculated. We can hardly avoid having several statements per property, as it is built into the data structure, and their is no undisputable reason why one point should be chosen over the others. But we should document the various possibilities to help clients make the most of our data. I have just created Wikidata:Geodata task force/Data structure, with that purpose in mind. Please comment there. --Zolo (talk) 15:00, 9 October 2013 (UTC)

--Zolo (talk) 15:00, 9 October 2013 (UTC)

bugzilla:55549 - go vote! --Rschen7754 08:14, 10 October 2013 (UTC)
We don't use voting on bugs. #Help the development team prioritise! 10:54, 12 October 2013 (UTC)
A datatype for w:en:Well-known text should be easy enough. But note the difference between giving the approximate location of something and giving the outline of something. Present datatype is the first, and it is important for searching and lookups. The second is important when we want to visualize something. We can add WKT as a string type, without actually being able to do anything useful with it inside Wikidata, but still being able to reuse it in Wikipedia (for example creating overlays on maps on the fly). Also note that it could be important to use Extended Well-known text and then we must include additional information. Jeblad (talk) 11:06, 12 October 2013 (UTC)

Question about the migration away from P107

Hello, I'm working with my bot User:Dexbot to migrate away the P107, as you know we add "creative work" and "book" as instance of items like Q47598 because book is not a subclass of creative work, and after that we remove P107, but my question is What about films and music products (single, song, album)? is P31 = song is enough to remove P107? or we need to add P31 = creative work to them too? BestAmir (talk) 13:11, 9 October 2013 (UTC)

I would say you can remove "instance of creative work" as long as it is an instance of a subclass of creative work. As tomT0m remarks above, "creative work" is vague anyhow.
By the way, even though it is the current recommendation, I do not think "instance of book" is the right way to define an edition of a book. To me "instance of book" should be for material books like Codex Argenteus (Q129906).--Zolo (talk) 15:07, 9 October 2013 (UTC)
I think instance of (P31):literary work (Q7725634) is better but literary work (Q7725634) only has one sitelink. literature (Q8242) has 160 site links. Maybe instance of (P31):literature (Q8242) would be better. Filceolaire (talk) 18:20, 9 October 2013 (UTC)
That depends, it can be an instance of novel (Q8261) or other kind of lifterary work. Plus the reference should not be the number of sitelinks, it should be the item definition or scope. Literature may be a field, not a set of works for example. TomT0m (talk) 18:30, 9 October 2013 (UTC)
What about instance of (P31):literature (Q8242) plus genre (P136):<appropriate genre>. Filceolaire (talk) 18:20, 9 October 2013 (UTC)
Classes can do the same thing in a more consise way. We can associate a number of implicit properties to a class, for example in owl it can be implied that the class novel, and subclasses of it, are associated with a genre property which has novel value, it's powerful. And novel can be a subclass of literature. Plus I don't really know what's behind the genre, but is it not supposed to be something like fantasy ? (Side note: we could also create a fantasy novel class later, and a bot could set properly the statements later consistently with the model we choose.) TomT0m (talk) 19:12, 9 October 2013 (UTC)
I think "literature" is a somewhat ambiguous concept. I guess that if we want a semantically correct generic terme, that should be text (Q234460) (ok that may be a bit too generic, but that seems to be the only one that does not leave out anything - and even then, image books?). --Zolo (talk) 19:47, 9 October 2013 (UTC)
<thing printable on a piece of paper> ? /o\ TomT0m (talk) 21:18, 9 October 2013 (UTC)
"I do not think "instance of book" is the right way to define an edition of a book. To me "instance of book" should be for material books like Codex Argenteus (Q129906)"
I strongly agree. Emw (talk) 04:17, 10 October 2013 (UTC)
In Bot requests for conclusions of 'Migrating away from GND main type' RFC, the fact that phonebooks are not creative was noted, and supported by a reference to Feist v. Rural. Thus, not all books are creative works, so 'instance of book' does not entail 'instance of creative work'. On the other hand, has a high-level CreativeWork entity, and aligning our hierarchy with theirs would be useful.
What are others' thoughts on mapping 'instance of creative work' claims to simply 'instance of Q15056842' -- a "work" which is not necessarily "creative" in the sense of copyrightabilty? This would be able to capture all books, paintings and other things in's CreativeWork without making any assertions about whether it passes a threshold of originality. "Work" would be superclass for things like "book", "painting", "song", "single", "album", "film", etc. Emw (talk) 00:03, 10 October 2013 (UTC)
A phonebook often have prewords, instructions and of course lots of ads, which often is copyrighted, even if the list of names and numbers isn't. So I guess it does make sense. -- Lavallen (talk) 05:40, 10 October 2013 (UTC)
I would be against using 'instance of (P31):Q15056842'. I think we should link to more specific items - instance of (P31):novel, biography, history, text book and other things which are a subclass of 'literary work'. Filceolaire (talk) 11:12, 10 October 2013 (UTC)
I think we agree. More precisely, I'm suggesting that we should replace P107 'creative work' with P279 'work' when there is no P31 or P279 subclass-of-work claim. In other words, P279 'work' would only be applied if the item had a P107 'creative work' claim and none of the items 'instance of' or 'subclass of' values were a subclass of Q15056842. Since 50911 isn't implemented, we can draw up a list of subclasses of 'work' by hand and compare the target items' P31/279 values against that. We already have a decent list: book (Q571), painting (Q3305213), song (Q7366), single (Q134556), album (Q482994), film (Q11424), novel (Q8261), biography (Q36279), history (Q309) (maybe a new item with the same label would be better, to separate works in the field from the field itself), textbook (Q83790).
Does that seem reasonable? Emw (talk) 13:09, 10 October 2013 (UTC)
I think it is, but we still dont know what we should use instead of of "instance of book". --Zolo (talk) 14:03, 10 October 2013 (UTC)
In which cases is instance of book used currently ? It should be used in actual book concrete objects. Otherwise that depends, and we have plenty of type of books that can be used : dictionaries, textbooks, which should be subtypes of the class book themselves. TomT0m (talk) 14:59, 10 October 2013 (UTC)
It is mostly used for things that are not instances of books, see[31:571]. I dont think that using "instance of textbook" or so would make it any more accurate . --Zolo (talk) 15:33, 10 October 2013 (UTC)
It's always the same discussion than in Help:basic membership properties. In that case, the textbook object is as instance of textbook for sure. It can be considered as an instance of a particular work, let's say Classification for newbies. In that view, Classification for newbies is a subclass of textbook, all of its instances (on the same editions) have the same text. So if we want to be precise, we also must find a way to say that all of the instances of Classification for newbies have the same text. So maybe classification for newbies should be an instance of printable work, or edited work. TomT0m (talk) 15:43, 10 October 2013 (UTC)
"we still dont know what we should use instead of of 'instance of book'"
We should use 'subclass of book' for virtually all items that currently have 'instance of book'. The same goes for all subclasses of book (e.g. novel, textbook, etc.) -- the items describe the properties of a set (class) of things (i.e. the book as an abstract object), each element (instance) of which has the properties defined in the class's item. This enables a very meaningful distinction between 'subclass of' and 'insta.nce of' for things that have physical manifestations. For example, Codex Argenteus (Q129906) is an instance of book (Q571), more specifically an instance of Bible (Q1845). Thus Bible (Q1845) is not an instance of book (Q571); instead, Bible (Q1845) is a subclass of book (Q571). Emw (talk) 00:32, 11 October 2013 (UTC)
Actually we should also class the classes. Let's say the novel, essay, ... for example are classed defined academically. Then they should be instances of academically defined literature classes. Those classes would be part of academic literature. This would allow different classifications to coexists in WIkidata, and the database to be queried with respect to a specific classification system. And every class is happy and have a lot of child instances mixing with other classes /o\. TomT0m (talk) 10:12, 11 October 2013 (UTC)
If we define a book as a material object made of paper, I would agree that a particular print edition of the Bible is a subclass of book, but not that the Bible itself is a subclass of book. If we define the Bible as a text, it is irrelevant whether it has ever materialized as a book or only as a computer file and letters on a screen. --Zolo (talk) 10:36, 11 October 2013 (UTC)
That's true but a lot of texts have been written with some form of printing or formats in mind. Short stories are published in set in books or in newspaper, novels are edited as books, comic books, and so on. We should not lose those informations. The Bible is an exception as it's at first a story transmited by voice, not by paper, and has a long story. TomT0m (talk) 11:07, 11 October 2013 (UTC)
When discussion sources, we have settled on making the distinction between "work" and "edition" (the text and its materialization). Even though most texts are designed for book publication, we have two distinct concepts. I think we should also have two separate subclass trees. One would be the subclassese of "text", perhaps things like "novels" or "handbook", and the other would be the subclasses of "written document", and its most useful member would probably be "edition". This way "Hamlet" is a subclass of text, not of book and "first edition of Hamlet" is an instance of book, not of text.
There may be a couple of problems here. For instance, it probably does not make sense to have two items for every single journal article. But I think it is ok to conflate an instance of text and a subclass of printed material in the same item, as long as we can easily tell that the item belongs to both trees at the same time. --Zolo (talk) 11:35, 11 October 2013 (UTC)
we have settled on making the distinction between "work" and "edition" (the text and its materialization). I don't agree, if we needed different editions it's because the texts is not always the same beetween editions, so it's not really the same distinction. An edition is something printable (and printed). We can not make that a subclass of texts either because it has illustration. Maybe we are more talking of a document, editions are different versions and concretisations of the same document evolving in time and in technical ways to edit it. The concrete objects, which should ideally be instances of an editions, will be pretty few. TomT0m (talk) 11:55, 11 October 2013 (UTC)
Yes, there were other reasons why we needed to make the distinction. But still, it makes it easier to distinguish between the two concepts. Perhaps all editions, are always, at the same time, subclasses of texts (or whatever the more general concept should be) , but still the two concepts are distinct in that editions should be in some subclass of "concrete object" while texts the sense of Hamlet or the Bible should not. --Zolo (talk) 12:04, 11 October 2013 (UTC)
Editions are a specific class of their parent work. Editions are not concrete objects; physical copies of the edition are. The fact that something has a paper copy or letters on a screen doesn't change the fact that it has particular instances; both the paper and the digital copy are physical objects. So I would support having an edition be a subclass of the parent work, and 'instance of' being reserved for physical copies of that work. Emw (talk) 12:34, 11 October 2013 (UTC)
I agree, but a physical copy of a work is not an instance of book because it is an instance of the work: it is an instance of book because of its material form. If a digital copy of the Bible is an instance of the Bible, but not an instance of book, then the Bible cannot be a subclass of book. So the question is what do we do with the Bible ? --Zolo (talk) 13:01, 11 October 2013 (UTC)
Since it's a collection of very different types of texts, how about: instance of anthology (Q105420)? -- Lavallen (talk)
I'll say it's exact and noncontroversial to say it's a religious text (Q179461). TomT0m (talk) 16:16, 11 October 2013 (UTC)
@Emw There is very good reasons to also use instance of on classes, as Markus Krötzsch noted on Wikidata:Requests_for_comment/Typing_:_class_⇄_instance_relationship_in_Wikidata. Actually it is not a problem for a reasoner and queries structure : it just add information, and there is no decidability problem if that is used well. TomT0m (talk) 15:36, 11 October 2013 (UTC)

An example : Snow White (Q11831)

Let's try a complex concrete example Snow White (Q11831). It's both a popular story, one of which has been written and edited by the Grimm brothers, probably a lot of editions, ... What can we do with this ?

Can we express all of this ?

I think it makes sense. We still need to figure out what the root of the tree containing all types of texts like "sacred text" or "fairy tales". We should probably replace most current "instance of book" by "instance of <this root>". Really I am afraid that we do not have many other solutions than "text". When possible, I think we can use more specific value, like "instance of novel" but it seems to conflict with genre (P136). Is P136 redundant with P31 ? I am not sure. It seems so when used with values like "novel", but not for values like "fantasy". Perhaps we should define P136 more precisely. And of course we also have the usual problem of finding all things that are instances of things given that we have no built-in solution to handle transitive properties, but that seems more a technical than a data problem. --Zolo (talk) 09:32, 12 October 2013 (UTC)
Is P136 redundant with P31. Yes and no. In owl, a class [owl 1] can be defined with respect to the fact that its instances have a property, and wrt. the value of those properties. For example, if an item is an instance of the class fairy tale, we can entail that its genre (P136) is indeed fairy tales. In wikidata this would allow both consistency checking and database reports, a we do with properties definition such as domain and ranges, or automatic property filing by a bot or a gadget who knows that and could go after a user who just markes the item as an instance of fairy tale and files the entailed properties, so less work for the user. If we have facts to express the model of Wikidata and adds statements to classes items, instead of hardcoding a gadget for a restricted set of class, we can have a gadgets which understands the statements of the classes item and does that for any class for which we have those statements. TomT0m (talk) 10:24, 12 October 2013 (UTC)
For me fairy tale (Q699) is not instance of (P31) anything because fairy tale (Q699) is a class. It refers to a whole set of items. There is a case for saying that Snow White (Q11831) is both an instance (because it is a particular story) and is also a class (because it refers to a whole set of variants on that story) but 'fairy tales' is definitely a class and should be described using subclass of (P279) not instance of (P31).
To me genre (P136) is redundant with part of (P361). For example <Star trek> is instance of (P31):television series (Q5398426) and genre (P136):science fiction (Q24925). Filceolaire (talk) 15:42, 12 October 2013 (UTC)
@Filceolaire. "'fairy tales' is definitely a class and should be described using subclass of (P279) not instance of (P31)" Imagine you are a literature teacher, and you want to teach to children that there exists different kinds of stories. For example, fairy tales and superhero stories. Each of these have different kind of main characters, princes and princesses for the former, superhero and super bad guys for the latter. That we can express using statements on both of the types of story items. Now these two items have some stuffs in comon : they both have statements about the type of their main characters, in both cases ... In OWL, we can express that using a type of story class, and by stating in OWL languages that all instances of the type of stories instances will have items about the type of the main characters. And that makes perfect sense. TomT0m (talk) 16:02, 12 October 2013 (UTC)

Merging Q1660508 without updating links

Apparently Q1660508 has been merged with university teacher (Q1622272), but a lot of statements still link to it. These should be updated. Is there a bot that can handle this? HenkvD (talk) 10:29, 12 October 2013 (UTC)

I'll do this. But we need a better solution for that problem. TomT0m (talk) 12:14, 12 October 2013 (UTC)

Jus docendi

da:privatdocent on the Danish wikipedia redirects to Jus docendi. So I tried to set Privatdozent (Q1402736) here to point to that page but it won't let me do that because it already has an entry here. Anyone know how to resolve this? Someone coming from Niels Bohr on the English wikipedia to pirvatdozent might like to find the Danish page without googling for it. Hawkeye7 (talk) 02:58, 12 October 2013 (UTC)

Does / Did anybody contribute to LibraryThing? Today or in the past?

Hi! Just wondered if some users are contributing / did contribute to LibraryThing. Regards לערי ריינהארט (talk) 18:45, 12 October 2013 (UTC)

Sure some editors do. Stuartyeates (talk) 07:26, 13 October 2013 (UTC)

Thanks for the answer! Please search in your browser for the "" string at the LibraryThing link log for the last 7 days. I added links from wikidata as Wikipedia type links. The pages contain some information about authority control identifiers (added some time ago) as well as siblig relations etc. Regards לערי ריינהארט (talk) 09:06, 13 October 2013 (UTC)

Please help at a regex and UTF-8 showstopper

Dear fruends! Since last night I am puzzled about some javascript lines in my clone version of Magnus Manske's authority_control.js tool.
I tried to expand it to detect AC datas at WMF projects where the template name is using UTF-8 characters. Please look at my clone version and please serach for the following lines:

// else if ( lang == 'it' ) st = t.match ( /{{Controllo di autorità(.+?)}}/i ) ;
// else if ( lang == 'ro' ) st = t.match ( /{{Informații bibliotecare.+?)}}/i ) ;
// else if ( lang == 'ru' ) st = t.match ( /{{Библиоинформация.+?)}}/i ) ;
// else if ( lang == 'yi' ) st = t.match ( /{{ביכער(.+?)}}/i ) ;

As far as I know regex supports only some (ASCII) characters. Reffering to control characters and or UTF-8 requires another coding.

Thanks for any help! Regards לערי ריינהארט (talk) 18:57, 12 October 2013 (UTC)

This is fixed at [8] now. Regards לערי ריינהארט (talk) 12:46, 13 October 2013 (UTC)

interoperability questions

[The following is somewhat anonymised due to the fact that a bunch of techies were discussing this informally and I’m sounding out wikidata based on that informal discussion. I have no authority to speak for any of these institutions. I have no doubt that based on my edit history and disclosed affiliations editors can have a good guess of the institutions involved, but that would not necessarily help with the questions at hand.]

If the national library, national archive, national museum and significantly digital text archive in a relatively small nation were looking to improve their interoperability by mapping their authority control systems (which need remain under their institutional control) to a shared common system, could that shared common system be wikidata?

I've read and reread Wikidata:Notability and if I understand correctly 3. It fulfills some structural need, for example: it is needed to make statements made in other items more useful. applies only to internal wikimedia structural need rather than external structural need, so in what follows, I’ll avoid relying on it.

If I understand correctly 2. It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references. If there is no item about you yet, you are probably not notable. covers:

  1. published works in the national bibliography, their creators, publishers subjects and etc
  2. museum items in the public-facing catalog of the national museum, and their creators and subjects, etc (but not necessarily persons mentioned in the chain of provenance data: donors, assessors, references, museum employees, etc.)
  3. published works in the digital text archive, their creators, publishers, subjects and etc
  4. organisational units covered by archival material and the office holders in those units as identified in the public-facing website of the national archives.

t My understanding is that clause two doesn’t cover:

  1. entries in non-public catalogs, even if these are national indexes or of international importance.

Other questions:

  1. One of the institutions is indelibly committed to the Getty thesauruses for place names and terms-of-art. The Getty thesauruses are available on the web, but use a license that I don’t really understand the consequences of in this kind of context. Has anyone looked at this? I suspect that it’s an important issue in terms of interoperability with the GLAM sector.
  2. If I understand correctly, we would need to create properties linking wikidata items with institution-specific identifiers. Would we need one identifier per institution or one per institution per class (person, place, book, etc)?
  3. Are there existing frameworks for matching large datasets against wikidata that are likely to be useful in this case?
  4. I’m concerned about the potential to create ‘leaves’ ---entities which are known due to their relationship to a single clearly notable entity and which we know to exist but which we don’t have thorough information on, so we can never be certain enough about their identities to merge them with identically named entities which may or may not map to the same real-world entity. Are there any policies around these?

Stuartyeates (talk) 07:24, 13 October 2013 (UTC)

Wow really interesting problem. First, for a start, Wikidatas Notability rules (I'll would prefer Admissibility) have been written about 6 months ago, and that's very young for a project who is about only live for a year, so they are not totally stables.
My understanding : tr
  1. Wikimedia's project are more or less in the spirit of "we offer the tools, a few rules, and we let community use it and decide the other rules. One of the principle is that the informations must not be extracted totally out of nowhere, so we must know fro where the information is.
  2. We knows that from ... institutions, authorities in the knowledge of the domain, ...
  3. You are one of these institutions who got the legitimity so that we source the informations with ... you, so if Wikidata works with you, we have to be very careful not to create loops which could ask existential questions : you take informations from Wikidata, we take informations to you.
  4. That said, I think we can for sure import your datas if we know their origins, and if we use ranking or other mechanisms so that it reflects your own trust on the datas, and if anyone can not edit those claims. The question is "why, is this useful ?" so I would say "it fulfils the tracability rules of Wikimedia projects, but what's the gain for the community ?"
I got one partial answer : it would allow some information crossing, claims sourcing about authority tracable entities, so it could be beneficial for both projects as it adds information to the "not so trustful information you know almost nothing about", allowing to improve trust and a little data cleaning in some cases. But in some sense, it's not so much Wikidata's problem to do this job, as long as we know where the information come from and that it is accurate according to the sources. After that it's the responsability of the editors to know what to do with these, resulting in some cases to improve trust : it the entity is real in the real world, maybe we will have some sourced claim about it. There is a "Wikidata trust number" to create there :) TomT0m (talk) 11:17, 13 October 2013 (UTC)
At the moment, many things in Wikidata are Wikimedia-centric, because it was the most natural starting point for a Wikimedia project, but I guess that things will change as the project grows. It seems that your concerns intersect with the recent discussion at Wikidata:Project chat/Archive/2013/10#Litteral data and import tools. As for the more specific question about non-public catalogs, I am a bit sceptical, because verifiability is central to the Wikiworld, but that should probably be discussed with more concrete examples. --Zolo (talk) 13:14, 13 October 2013 (UTC)
Putting those catalog on Wikidata is the equivalent of a publication, technically, so those catalogs would not be non public anymore. I guess it's enough to publish the datas on the organisation platform one way or another to make a clean publication step and to have something to cite to settle the question. TomT0m (talk) 13:37, 13 October 2013 (UTC)
There are at least two well-renowned systems for handling large datasets, and both can be adapted to publish to Wikidata. Main problem is that some data should only live in internal systems, while only some data can be uploaded. Also, not all descriptions will fit in Wikidata, simply because people will have no idea how to curate them. The way around this is to create local descriptions on some external (or internal for the institutions) service and place curated descriptions there. Let that local repo be based on linked open data (could be as simple as OAI-PMH) and publish links to the repo at some of the central archive servers. Let the curated descriptions on that repo contain owl:sameAs links to other descriptions, including items on Wikidata. Then try to argue for a real implementation of owl:sameAs on Wikidata and prey to the God of Internet that all of your described entities will be deemed worthy as items on Wikidata. One well known problem is that on Wikipedia classes of things are described while museums hold instances of such things. If there is a owl:sameAs for items on Wikidata, then you can point the correct item to your description. Hopefully at some point Wikidata will be able to deliver data from not only internal items in Wikidata itself, but also from referenced external descriptions. Up until then you must use the common properties and whatever interpretation they have in the community at any given moment. Do not assume that a value for a specific property in Wikidata will be identical to whatever you want to save for a similar property in your domain – not even if the predicate is marked with a owl:sameAs. The difference between what you publish and what Wikidata publish is very important, even if Wikidata republish with sources that is claimed to be "your description". Then you have the problem with aligning such datasets, which is difficult at best. There are numerous attempts to make some fancy solutions, but to me it seems like most of them need a lot of guidance and verification. Jeblad (talk) 14:24, 13 October 2013 (UTC)

Link to other Wikipedia language

I tried to link the article "perch" to the Italian corresponding one "pertica" but this was not allowed as "pertica" is already linked to another English article.

This is the message I got:

Site link Pertica is already used by item Q1210831. Perhaps the items should be merged and one of them deleted? Feel free to ask at Project chat if you are unsure.

I don't wish to argue about deleting one of the items, because the topic is beyond my knowledge. But I do maintain that "perch" and "pertica" define the same unit.

It should be possible to reflect that in the links.Pan Brerus (talk) 14:25, 13 October 2013 (UTC)

"Pertica" is a disambiguation page on both enwiki and itwiki and linked from Q1210831. They are not related in any way to the fish "perch" you probably mean. The corresponding articles about this topic are already linked in Q600262. Regards, Vogone talk 15:26, 13 October 2013 (UTC)
If you mean the plant, you can find it in Q3900572. Vogone talk 15:29, 13 October 2013 (UTC)

Infoboxes items properties

It occured to me that we can map infoboxes items to the class of items they renders in Wikipedia. We can also map properties to infoboxes that uses them. Does it seem like a good idea ? TomT0m (talk) 15:38, 13 October 2013 (UTC)

I think some people have already tried to do some of that, that seems useful but difficult to organize. I would support an "infobox for" property to be used on template items. --Zolo (talk) 16:09, 13 October 2013 (UTC)

Bot requests for conclusions of 'Migrating away from GND main type' RFC

The Migrating away from GND main type RFC has been closed. The conclusions drafted by John F. Lewis are:

  • All statements with term can simply be deleted and substituted with instance of when appropriate.
  • Human beings are to be classified with instance of: human (Q5). Fictional characters such as Han Solo or Mickey Mouse (used as examples below) should now be classified as fictional characters using the instance of property. Similar with Gods, they should now be classified as deity as opposed to the current use of person.
  • No consensus has gathered over all other existing uses of GND and their transfer. Existing uses should be able to be migrated over to instance of using their current P107 values.

These seem like reasonable, actionable conclusions to me. It would probably be worthwhile to have a separate RFC for how we want to structure data for fictional entities, using the discussions in Fictional entities as a starting point. For now, though, using simply instance of (P31) fictional character (Q95074) is a good temporary solution that can be refined later.

Detecting P107 'person' claims in non-human persons seems like the only notable obstacle for the migration, but a few good techniques for that were proposed in the RFC. Proposed solutions for generating a list of valid instance of (P31) human (Q5) items include:

I'd be interested how many distinct items there are using the above approaches. There are roughly ~1.2 million P107 'person' claims on Wikidata -- I would be surprised if the above approaches listed anywhere near that many items.

For now, though, I think it would make sense to P107-to-P31 map other than those with 'person' or 'term' to simply use P31 and their current P107 values. Once mapped to P31, the P107 claim can be deleted. These P31 values can be refined later; the important part is to migrate them to a non-'main type' property. P107 'term' values can be summarily deleted. Does this P31 mapping and P107 'term' deletion proposal make sense for others? If so, we should give external users of P107 notice of our intent to massively remap and delete P107 claims before we begin executing related bot requests.

What are others' thoughts? Emw (talk) 01:23, 5 October 2013 (UTC)

I want to help, but some simple (and stupid-sounded) questions:
  • Assume Q47598: Is it okay to add P31 = Book to the item? what about book and novel at the same time(P31 accepts two or more values)? and what about creative work too? (I mean my bot adds book, novel and creative work as P31 values at the same time) and when can you call it appropriate to delete P107, when it has just P31 and one value (no matter what) or needs to be imported creative work (as P31) to get the permission of deleting P107?
  • If item of one person already has person as value of P31, what about that? I think it is still needed to add Q5 as P31 value but my bot overrides it or add it simply? and if an item has P31=Q5, is it okay to delete P107?
Best Amir (talk) 01:51, 5 October 2013 (UTC)
Great questions. Answering in order:
Using simply 'instance of creative work' to replace P107 'creative work' claims is the best approach for bots right now. The answer to your specific question is "yes", but adding P31 = book claims is outside the scope of the migration away from GND main type. The bot request would ask that the item simply create the claim instance of (P31) work (Q386724) (unless the item already has a P31 or P279 value) and remove the claim P107 (P107) work (Q386724).
  • "what about book and novel at the same time (P31 accepts two or more values)? and what about creative work too? (I mean my bot adds book, novel and creative work as P31 values at the same time)"
book (Q571) is a subclass of work (Q386724), so 'creative work' should not be used as a P31 value on an item if 'book' is already used. That's because an item being a book entails that the item is also a creative work. This is a central benefit of using P31 and P279. book (Q571) is not a subclass of work (Q386724) (see below), so P107 'creative work' claims should be replaced by P31 'creative work' claims even if the item already has a P31 'book' claim. The item would then have P31 'book' and P31 'creative work' claims.
novel (Q8261) is not a subclass of work (Q386724), so having both 'instance of book' and 'instance of novel' seems technically valid. (However -- why isn't novel (Q8261) a subclass of book (Q571)? To my understanding all novels are books.) I would hold off on using both P31 'book' and P31 'novel' until my parenthetical questions are resolved. Using 'instance of creative work' is the best approach for bots right now.
  • "when can you call it appropriate to delete P107, when it has just P31 and one value (no matter what) or needs to be imported creative work (as P31) to get the permission of deleting P107?"
I think P107 claims should be deleted on an item whenever the item has a P31 or P279 value. P107 values are very general, and in many cases items with P31 and P279 values have already been used to give a deeper (and more informative) classification than P107.
  • "If item of one person already has person as value of P31, what about that? I think it is still needed to add Q5 as P31 value but my bot overrides it or add it simply? and if an item has P31=Q5, is it okay to delete P107"
Per the RFC, I think instance of (P31) person (Q215627) claims should be overwritten (i.e., replaced) by instance of (P31) human (Q5). If an item has P31=Q5 already, then the P107 claim should be deleted.
Hope this helps! I'll be happy to try to answer any follow-up questions. Thanks, Emw (talk) 04:06, 5 October 2013 (UTC)
Nitpicking a bit, I think not all books are creative works - e.g. a telephone directory. --Avenue (talk) 04:57, 5 October 2013 (UTC)
Fair point. Since a creative work is "a manifestation of creative effort such as artwork, literature, music, paintings, and software" and phone books are books that are not creative works (see Feist v. Rural), books are not a subclass of creative work.
This means that P107 'creative work' claims should be replaced by P31 'creative work' claims even if the item already has a P31 'book' claim. I've updated book (Q571) and my reply to Amir. Emw (talk) 13:39, 5 October 2013 (UTC)
I have revised Wikidata Useful to these new classifications. See User:Filceolaire/filceolaire_useful.js. I think we need to move this out of user space but when I tried it didn't work - Wikidata:Useful.js. I would be grateful to anyone who could help test this or suggest any further changes that need to be done. Filceolaire (talk) 14:34, 5 October 2013 (UTC)
I notice your script still uses P107 in several places. Given that the property is slated for deletion, I think it would make sense to update Useful.js so that it doesn't add P107 claims. Regarding a move out of userspace: that's probably not possible. The documentation up top has a usage note about importing User:Magnus Manske/wikidata useful.js. If Magnus's script is in userspace, then I imagine all non-official scripts are also in userspace. Emw (talk) 14:45, 5 October 2013 (UTC)
Oops. Missed a few. I think i've got them all now. Filceolaire (talk) 22:33, 5 October 2013 (UTC)
There's one more in the 'isDisambiguation' method. I wonder how Magnus feels about making these changes to his version of the script. Emw (talk) 22:38, 5 October 2013 (UTC)
I couldn't find that. I did leave a comment on Magnus's Useful talk page but got no response. Filceolaire (talk) 07:05, 6 October 2013 (UTC)
You should be able to see it by doing an in-page search (Ctrl+F / Cmd+F) for 'p107'. Emw (talk) 14:35, 6 October 2013 (UTC)

My bot started on infobox Person items from English Wikipedia (you can see it here) I'll start working on creative works two or three days later. Amir (talk) 17:42, 5 October 2013 (UTC)

Hi Amir, I see Dexbot is adding P31 'human' claims but not removing P107 'person' claims as expected. Could that be fixed? The purpose of this effort is to remove all P107 claims and replace them with appropriate P31 and P279 claims. Thanks, Emw (talk) 18:05, 5 October 2013 (UTC)
Is it okay now? Special:Contributions/DexbotAmir (talk) 10:45, 6 October 2013 (UTC)
Yes, I've looked over about a dozen examples and things look good. Emw (talk) 14:36, 6 October 2013 (UTC)
But it still does not remove the P107 ?! See again Special:Contributions/Dexbot - LaddΩ chat ;) 22:28, 6 October 2013 (UTC)
It is removing P107 claims, but not as you might expect. It seems as though Dexbot is adding sets of large batches of P31 'human' claims as needed, then, after the batch is done, removing P107 'person' claims from those items. See for example Dexbot's edits from 10:00 UTC today, and the edit history for Ornella Muti. Amir's approach works. Emw (talk) 23:55, 6 October 2013 (UTC)

Please see #Question about the migration away from P107 Amir (talk) 13:23, 9 October 2013 (UTC)

Person vs Human

Can someone please explain me why person (Q215627) is replaced by human (Q5)? Person is widely used and replacing it with human looks rather weird. Multichill (talk) 18:51, 7 October 2013 (UTC)

Because consensus developed on the above-linked RfC for that. See the arguments presented there. Ajraddatz (Talk) 18:55, 7 October 2013 (UTC)
It isn't always. Person is only changed to human when the person is human. If the person is not human then use another item (Deity for example). It is useful to be able to limit a search to humans only so we need to have a property which distinguishes humans from non-humans. Filceolaire (talk) 18:21, 8 October 2013 (UTC)
Hi Multichill, the term "person" was defined by P107. Since this popular property has been removed against all reason I'm looking forward for the discussion which gods are human etc. --Kolja21 (talk) 14:47, 11 October 2013 (UTC)
To say that 'person' was defined by P107 is an overstatement. In fact, the ill-defined nature of P107 'person' was one of the property's biggest problems. P107 considered fictional characters, gods, spirits, collective pseudonyms and such to be persons, but the fact remains that those things are far outside the common understanding of 'person'. The standard reply to this glaring issue -- "person should not be interpreted literally" -- is inadequate. Having Harry Potter (Q3244512) and Thor (Q42952) returned in a query for 'person' would be a huge bug.
I don't much fault P107 or the GND Ontology for not giving a reasonable definition for 'person'. Formally defining the term is difficult, as the pretty-much-empty Wikidata item person and the nebulous Wikipedia article Person indicate. The formal definition of 'person' is not only nebulous and historically variable, it is also laden with philosophical, legal and moral controversy. This is covered in more detail in the Coco Chanel discussion in the 'Migrating away from GND main type' RFC.
We all know that the informal, colloquial definition of 'person' is much less ambiguous. When folks think 'person', by default they're really thinking specifically about human beings, i.e. human (Q5). If you look in that item you'll see that 'person' is an alias of 'human' -- this captures that colloquial usage. Emw (talk) 18:58, 12 October 2013 (UTC)
You are insisting of „common understanding of 'person'“ and declare by default they're really thinking specifically about human beings. Without any prove. I feel individuums like Q (Q15857) fit an abstract „Person“ very well. --Succu (talk) 19:17, 12 October 2013 (UTC)
Alternatively, Q is a fictional character, regardless of whether he/she (it? :) is a person. --Izno (talk) 19:28, 12 October 2013 (UTC)
Q is a fictional person. Did you know he/she/it acting in other cirumstances? But thats not my point. --Succu (talk) 19:37, 12 October 2013 (UTC)
Succu, the fact that the humanoid Star Trek character Q fits your abstract understanding of 'person' does not contradict the assertion that the common understanding of 'person' maps specifically to human beings. I know people for whom dolphins and corporations fit an abstract understanding of person, but that does not change the fact that those things are not persons as commonly understood by the overwhelming majority of people.
The same rationale applies for Q, Thor, Harry Potter, Pikachu, etc.: they are anthropomorphic and in some cases fictional human beings, but they do not fit the common understanding of persons. If someone asks "how many people do you know?", including Harry Potter, Romeo and Juliet in the count would obviously be ridiculously. This is one of many examples of how the common understanding of "person" maps specifically to human (Q5) -- i.e. a non-fictional human being.
If users query "people born in United Kingdom in 1980" and get back Harry Potter (Q3244512) among the results, then Wikidata is doomed. This topic is discussed in more depth in the Fictional entities section of the 'Migrating away from GND main type' RFC. Emw (talk) 20:52, 12 October 2013 (UTC)
For the sake of reference, Brazilian law makes a distinction between "physical person" (Homo sapiens) and "legal person" (companies). Pikolas (talk) 20:22, 12 October 2013 (UTC)
This distinction is also made in US law: see natural person, corporate personhood. It is one of the stronger examples of why it helps to be a bit more explicit and classify items like Coco Chanel (Q45661) as human (Q5) instead of person (Q215627). There are numerous other reasons to prefer 'human' to 'person', as discussed here. Emw (talk) 21:19, 12 October 2013 (UTC)
And what? --Succu (talk) 21:24, 12 October 2013 (UTC)
What? Emw (talk) 21:45, 12 October 2013 (UTC)
To make a distinction.... --Succu (talk) 21:53, 12 October 2013 (UTC)
Please elaborate. I don't know what you're saying. Emw (talk) 21:58, 12 October 2013 (UTC)

P107 migration update

To get an idea on how the P107 migration is going, I've added a table below showing counts for various P107. Counts for P107 claims are available for August 25 (source). Counts for October 13 are from Magnus Manske's WikiDataQuery tool (; the counts have the cavaet that "results are based on a dataset that may be a few days old".

P107 value Count as of 8/25 Count as of 10/13 Count as of 10/18 Link
person (Q215627) 1,270,164 1,219,184 1,208,863[107:215627]
organization (Q43229) 82,813 83,086 83,084[107:43229]
event (Q1656682) 3,690 4,898 4,899[107:1656682]
work (Q386724) 303,564 186,279 228,800 (?)[107:386724]
term (Q1969448) 257,592 257,790 257,700[107:1969448]
geographical object (Q618123) 1,701,341 1,708,631 1,708,608[107:618123]
Q11651459 610,697 608,284 608,261[107:11651459]

To my knowledge, bots have only been working on P107 'person' and 'creative work' claims. I'm aware of work by Dexbot and KrBot, with Dexbot doing the majority.

Since P107 'person' claims seem to have the clearest migration plan, I'd like to focus on that while questions about 'creative works' claims are worked through elsewhere. The change in the number of P107 'person' claims has so far been pretty minimal: it's gone down only 4% since 8/25. To speed up that pace, I've entered a couple of bot requests at Wikidata:Bot_requests#Migrate_P107_person_claims. Please take a glance over that request and comment there with any questions or concerns. Emw (talk) 23:29, 13 October 2013 (UTC)

I will work on Q11651459. --ValterVB (talk) 11:41, 14 October 2013 (UTC)

"bad" property type instead of "geocoordinate"

Hi. I found the following four items have a value type of "bad" instead of "geocoordinate" for their "coordinate location". If you navigate to their pages, then you will see "The value does not comply with the property's definition." under "coordinate location".

I looked at the history and the revisions were made by different users. However, the time period seems to be the same: 2013-07-02.

Are these to be corrected individually by re-entering the data?

Also, on a somewhat unrelated note, Japan has a snakvalue type of "somevalue" for its "named after". I believe it should be "value". The page shows "unknown value".  – The preceding unsigned comment was added by Gnosygnu (talk • contribs) at 17:12, 12 October 2013‎ (UTC).

Hi Gnosygnu, that's because the "globe" (Earth (Q2)) is missing for these items, see the api. One bot imported a lot of coordinates without globe, that still needs to be fixed. Multichill (talk) 15:34, 12 October 2013 (UTC)
Full list of "bad" coordinates: Wikidata:Database reports/Constraint violations/P625#"Bad value" violations. — Ivan A. Krestinin (talk) 15:43, 12 October 2013 (UTC)
Okay. Thanks Multichill / Ivan. The "bad" coordinate doesn't affect me, but I thought it should be reported. If someone is working on it, that's great.

The snakvalue seems to be unrelated to the above. Again, it doesn't affect me directly, but I thought someone might want to investigate.

Let me know if you need anything else.

Thanks. Gnosygnu (talk) 05:05, 14 October 2013 (UTC)



  1. Are there statistic for wikidata?
  2. Are there statistic for a specific language on wikidata?
  3. Are there statistic for users in wikidata?

Xaris333 (talk) 16:31, 12 October 2013 (UTC)

  1. Special:Statistics, Wikidata:Statistics, Wikidata:Database reports & Statistics on
  2. User:Byrial/Language statistics for items
  3. Wikidata:Statistics contains statistical data for users.
Hope this helps. --Glaisher [talk] 16:49, 12 October 2013 (UTC)

Thx! For the point 3 i want statistics for a specific user. Xaris333 (talk) 17:39, 12 October 2013 (UTC)

Try X!'s Edit Counter. Replace name= with the name of the user. The Anonymouse (talk) 14:39, 14 October 2013 (UTC)

I have been blocked from editing?

Please assist When I try to edit database entries, all of the edit buttons are greyed out and a tooltip explains that my username or IP address has been blocked. What? —Justin (koavf)TCM 16:42, 14 October 2013 (UTC)

Answered at Wikidata:Administrators' noticeboard#I have been blocked from editing?. Please don't start the same topic in multiple locations. Multichill (talk) 18:15, 14 October 2013 (UTC)

site id codes

just a thought, but it SURE WOULD BE NICE if it was easier to find the correct site id codes, when you need them (to fill in an entry).

i just found the new commons' section for the first time, & when i wanted to add an item, it was a HUGE PAIN to find out what the correct site id for commons was.

in the case of "commons" it might be nice if the page just filed it in automatically, since it's being kept as a distinctly separate section; but for "general use" it would be awfully nice to have a code-list "on hand" somewhere handy. (i.e.: i have better things to do, than to memorize all this crap... (no offense intended) other people have better things to do, as well.)

Lx 121 (talk) 03:12, 15 October 2013 (UTC)

Many term properties await promotion

There are a bunch of properties in Wikidata:Property_proposal/Term that have had unanimous support for months. Could someone with property creation permissions please promote them? Thanks, Emw (talk) 03:24, 15 October 2013 (UTC)

US coordinates map to China

There seems to be a problem when viewing some coordinates on interactive maps : USA locations are displayed in China, as if the longitude "W" was processed as "E", see for example in United States Supreme Court building (Q1579670) [38°53'25.8"N, 77°0'16.2"W]. Moreover, just removing the final decimal fixes the issue !? Saw it also in CN Tower (Q134883). As if the final W was misinterpreted when the overall coord string is too long. Bug? - LaddΩ chat ;) 00:35, 15 October 2013 (UTC)

It's a bug in Bene*s Script maps.js. I reported it here. --Pasleim (talk) 11:23, 15 October 2013 (UTC)
OK, thanks for pinpointing the source - LaddΩ chat ;) 22:51, 15 October 2013 (UTC)

New code deployed

We have deployed new code to Wikidata.

Changes of note include:

  • Item ID is displayed next to the item label (see paper cut)
  • Improved appearance of Wikimedia Commons site link section

In the API:

  • EditEntity module allows editing / adding claims and creating entities with claims.
  • API has a new merge items module.
  • Precision for time values is now validated. The API no longer accepts time values more precise than a day, as such values are handled inconsistently in the UI. (see bug 54939)
  • Coordinate values with null precision are no longer accepted by the API for new claims. Existing data in Wikidata that has null precision can still be displayed and items edited.

In the clients (Wikivoyage/Commons now, Wikipedia on Thursday):

  • The Wikidata flag 'D' on watchlist and recentchanges is styled.

If you have any issues with the JavaScript, please try to clear your JavaScript cache.

Cheers. Katie Filbert (WMDE) (talk) 18:19, 15 October 2013 (UTC)

  • Phew, I was concerned. Thanks for the clarification Lydia. (And thank you developers :).) Emw (talk) 00:37, 16 October 2013 (UTC)

Language link for Strawberry

In two articles (Poziomka and Truskawka) refer to the same English article, Strawberry. The link in English version of Strawberry is Poziomka. The links should look like this: Truskawka = Strawberry Poziomka = Fragraria I would change it myslef, but when I try to do this, I am always denied, because "Site link Fragaria is already used by item Q13158. Perhaps the items should be merged and one of them deleted? Feel free to ask at Project chat if you are unsure." This is curious for me, since there are already two Polish articles linking to the same English article.

This thread is missing a date for the archive-bot. -- Lavallen (talk) 16:24, 16 October 2013 (UTC)

Chemical elements

w:en:WikiProject Elements on the English Wikipedia currently giving some thought to its infoboxes. There is a wealth of standard information about the 100+ chemical elements, so this could be a pretty big thing to bite off. But to start off simply, one of our editors is working on a repository to contain the melting points and boiling points for each element. Each data point has up to four different sources, which don't always agree for a variety of reasons. If the wikidata project is ready for start on infobox stuff, this seems like it could be a manageable thing to do, but I don't readily find instructions on (a) how to put this information into wikidata or (b) how one would get the stuff out of wikidata. Could someone point me to some explains some of this? Also, if this is not the appropriate place for this to be posted, someone please point me in the right direction. YBG (talk) 00:14, 15 October 2013 (UTC)

Currently, Wikidata does not support a number type. That's coming soon. Coming afterward will be number with unit type. Until those are supported, supporting chem infoboxes doesn't make a lot of sense. Property proposals is the place to make proposals for properties. You might also start a task force here to support the Wikidata side. --Izno (talk) 00:47, 15 October 2013 (UTC)
Actually, I'm dumb. Wikidata:Chemistry task force may hold more answers. :) --Izno (talk) 00:48, 15 October 2013 (UTC)
And apparently an Wikidata:Elements task force. --Izno (talk) 00:50, 15 October 2013 (UTC)
And Wikidata:Property_proposal/Pending lists the properties which have been approved but are on hold waiting for these datatypes to be available - including 'melting point' and 'boiling point' (2.35 and 2.36). Once the number with temperature datatype is available these peoperties will be created and can be used. Where sources disagree the property can have more than one value. Each value added should have a reference to a source, or sources, for that value. Filceolaire (talk) 18:09, 15 October 2013 (UTC)
Before any import of data think about which data you want to have in your infobox. For that use Wikidata:Chemistry task force/Properties or Wikidata:Physics task force. Then if you have the data ready with their sources I can propose you to put all that information in a excel files and to ask a bot to import the data. Get in touch with me if you want to automatize this import: I already develop a bot for that (see user:Chembot). Snipre (talk) 11:24, 16 October 2013 (UTC)

Mess in wikidata pages about punctuation

I observed that there are 2 wikidata pages about punctuation. It causes quite a mess because for almost every language there is only 1 article which is pretty randomly localized either as a part of first wikidata page or second one. Here they are:

A) (title "punctuacion", contains 53 languages including English)
B) (title "punctuation mark", contains 22 languages NOT including English)

When I look at the titles, it seems to me that A should be about meaning and use of punctuation in general and B should be a list of punctuation marks. On the other hand, I don't see a reason why should they be splitted in separete articles.

Reality is, that articles in A and even majority of articles in B seem to cover both topics or doesn't differ between "punctuacion" and "punctuation mark" at all. For example first words of english "Punctuation" article are "Punctuation marks are symbols that indicate...". There is a small group of 8 languages, which have articles in both groups, but even in some of these languages, the second article has just few sentences, for exemple German (Deutsch). These are the languages:

Azərbaycanca; Български (Bulgarian); Deutsch; Eesti; 日本語 (Japanese); Nederlands; Русский (Russian); Українська (Ukrainian)

So my question is, is this normal? Is it splited because of some reason or is it just a misunderstanding? Probably it's worth of some better investigation :) I'm just an observer, not an editor, just wanted to point it out.

PS. While I'm "here" I would also like to ask two other questions, that bother me :)
1) How is it possible that for some languages from B group (Walon, Greece, ...), language links includes also a major part of links into articles from A group?
2) Why are language links somtimes sorted alphabeticaly and sometimes they appear in semi-random order - the same in whitch they are in wikidata page (when you click on "edit links")? Fatus (talk) 08:40, 15 October 2013 (UTC)

0) Yes, it's quite normal. Some Wikipedias have different articles on these topics, some have only one article on one topic, and some have one article that somehow mixes up both topics. Wikidata:Interwiki conflicts is full of cases like this. The only solution to cleanly clean up this is to introduce the same article grouping in all affected Wikipeias (which is not very realistic, though). In the future, it should be possible to add redirects to the Wikidata item, so e.g. en:Punctuation mark could be added to Q10617810, which will enable better visualisation of the split, and allow some interwikilinking even with no exact match in some languages.
1) Those articles still contain local interwiki links (the old system: jusat adding links like [[en:Punctuation]] somewhere)
2) Here, the languages always are sorted by their language code, so e.g. the Finnish language ("Suomi", fi) will appear before "French" (fr). This allows proper sorting of languages in different writing systems. I'm not sure if all or only most Wikipedias also follow that system. --YMS (talk) 10:59, 15 October 2013 (UTC)
Thank you for a clear explanation. I will try to contribute. Fatus (talk) 12:40, 15 October 2013 (UTC)
Personally, I don't think these slight differences in meaning are a bad thing. On the contrary, they make Wikidata richer as we have more terms to describe something. Also, language links are usually in order when a bot created the item, as human editors don't bother so much in organising them alphabetically. Pikolas (talk) 15:21, 15 October 2013 (UTC)
This is what we call the "Bonnie and Clyde problem". It's a basic principle here that Wikidata does not tell Wikipedias how to organise their articles. Wikidata reflects the arrangement of articles in the wikipedias, even if some have separate articles on Bonnie Parker and Clyde Barrow and others have one article on Bonnie and Clyde. Filceolaire (talk)

Some explaining: in russian we have clear distinction between пунктуация (en;punctaiton? de:Interpunktion?) which is the science about rules and tradition of using punctuation marks and знаки препинания (en:punctuation marks) which are a set of characters. They can be used everywhere, not only for punctuation. For example, point can be used for truncation of words, as record operator in programming language C and as current directory in Unix. Emoticons also consist of punctuation marks but have arguable relation to punctuation. Infovarius (talk) 14:17, 16 October 2013 (UTC)

the Bonnie and Clyde-problem

Speaking of our friends Bonnie and Clyde: When I look into Fanbyn (Q3290993), I see in svwiki an article about two statistical entities with the same name laying very close to each other. The no/nn/nl/en-articles are, as far as I can see, only about the larger entity.

My question: Are we going to solve the Bonnie and Clyde-problem in the same manner as the Bonnie and Clyde-problem? I do not care very much about the interwiki-problem here. It can always be solved in the old style if we have to. It's the problem with two entities in the same item that confuses me. When the parts has more or less equal wp-notability, it looks simple. In this case, when one is much larger than the other, it's not as obvious. -- Lavallen (talk) 18:23, 15 October 2013 (UTC)

There are lots of cases where an administrative unit named 'Foo district' contains a settlement known as 'Foo' (alias 'Foo village'). If we have the data needed to create a complete item for 'Foo village' (population, mayor, coat of arms etc. specific to 'Foo village') then we should have an item for 'Foo village'. If we don't have such specific data then (in my opinion) we can get away with just having an item for 'Foo district' and treat 'Foo village' as part of that, at least until we get such specific data or a wikipedia or wikivoyage creates a separate articles about 'Foo district' and 'Foo village'. That's what I think. It's all about this: Are there any statements we can make if we have two separate items which we could not make if we only had one item. Filceolaire (talk) 12:09, 16 October 2013 (UTC)
In the case Domback (Q1879056) (a village), I have used has part (P527) to point to two statistical units. The main entity will in this case carry very little information. (Just like a typical Bonnie and Clyde with more or less equal wp-notability.) The main information will in that case be in it's two parts (Dombäck north and Dombäck south). But in cases like "Fanbyn", my thought is that it could be an alternative to use Q3290993 as a carrier of the "population", "location" etc of the larger entity and let the smaller be in a separate item. They need two items, no doubt, otherwise will the integrity of the content be in danger, but the question is if it needs two or three items to describe it. -- Lavallen (talk) 12:32, 16 October 2013 (UTC)

What is going on with Q325180?

I can't seem to open it. I get:

Unexpected non-MediaWiki exception encountered, of type "Wikibase\Lib\FormattingException"

Texugo (talk) 11:59, 16 October 2013 (UTC)

Again some issue with the coordinates. The last revision from the history that can be opened is also the last one without coordinates. --YMS (talk) 12:12, 16 October 2013 (UTC)
Thanks. I am unfamiliar with this issue. Is it being resolved? Texugo (talk) 12:23, 16 October 2013 (UTC)
We are looking into it. We had a similar problem a week or so ago, though not sure yet if this is the same thing. Aude (talk) 15:28, 16 October 2013 (UTC)
We found the issue and patched it. This should be deployed soon! :) Adam Shorland (WMDE) / ·addshore· talk to me! 17:34, 16 October 2013 (UTC)
The bug fix is deployed and fixes the issue. Aude (talk) 17:58, 16 October 2013 (UTC)

Another paper cut

Can we still propose Paper cuts ? The page does not seem to be maintained anymore. Any other place? In Bugzilla? I'd appreciate if the precision on coordinates could also be displayed in length (e.g. for Earth ±1' ≈ ±1.8km; ±1" ≈ ±31m...) so that it would be easier to identify the right precision for a house, a building, a village or a city. - LaddΩ chat ;) 23:55, 15 October 2013 (UTC)

Yes I will continue to monitor the paper cuts page. I just need to get to actually updating it when I am back from traveling. It's on my list but I didn't get to it yet. Sorry about that. If you're able to use bugzilla please do use that. In the end all the bugs need to go there anyway. The wiki page is mainly an offer for everyone who doesn't want to bother with bugzilla and of course to get more input. --Lydia Pintscher (WMDE) (talk) 03:15, 16 October 2013 (UTC)
OK, added to both Paper cuts and Bugzilla - LaddΩ chat ;) 22:13, 16 October 2013 (UTC)


now that wikidata has (finally) added commons-capabilities (which is wher i do most of my editing, these days), there is a point i'm not clear on:

@ commons, CATEGORIES are the primary unit of organization; commons is a catalogue of media files & pages are, at best, a "sampling' of available files for a topic, & curating page-contents is a decidely low-priority activity.

so how are we handling the 'interface' with other projects on here? because, having tried out adding a couple of items on here, i find that i am unclear on how exactly this is supposed to work...

is there a page and/or discussion for this?

Lx 121 (talk) 17:33, 17 October 2013 (UTC)

Wikidata:Requests for comment/Commons links--Ymblanter (talk) 17:52, 17 October 2013 (UTC)

Showcase items

Wikidata is a project that is still hard to understand for a lot of people. One thing I noticed that helps significantly is showing people a really nice and complete item. At the moment for a random person to find such an item is really hard though without guidance. The "Random item" link in the sidebar is basically useless for this as it is very likely to lead to an item with 0 statements and maybe one or two Wikipedia links. The other thing is the very small and well hidden link on the main page. This leads to the item on Wikipedia. I don't consider this a very good example as it is too self-referential and also not a very good item tbh. So can we have something like a show-case item on the main page? I know there was previous discussion about a featured item that people opposed because back then Wikidata was still too young and we didn't have sourcing. Both of these arguments are now invalid imho. The other argument was that Wikidata is only about data and therefor shouldn't have a featured item thing or something like that. I can't agree less. Yes it is data but we need showcases for people to understand what we want all the rest of Wikidata to be like. We need to make the data in Wikidata better and we need to make Wikidata more understandable. IMHO this is a critical step to get us there. Opinions? --LydiaPintscher (talk) 13:34, 13 October 2013 (UTC)

I was one of the people who opposed the idea of a "featured item" a few months ago. But now that items are more complex, I support this idea. --Jakob (Scream about the things I've broken) 13:40, 13 October 2013 (UTC)
+1 I think that a good example have more value than a lot of help pages :) -ValterVB (talk) 14:13, 13 October 2013 (UTC)
{{S}} -- Lavallen (talk) 14:16, 13 October 2013 (UTC)
  Strong support. Great idea. Pikolas (talk) 15:16, 13 October 2013 (UTC)

@LydiaPintscher Examples are indeed cool and really important to help users to understand, and I strongly support anything that can give good example in a case (for example, we could associate featured items to any class). But what is also cool is to have some kind of assistant while you edit the database, like "OK, now you have a scientist, in which university does he works ? On what field, and so on ...", and we can in a generic way with models. It's pretty cool that we will be able to express statements on classes and properties, but will the devteam exploit it themselves or will it be up to community to develop gadget or interfaces that could serve as those assistant ? TomT0m (talk) 14:54, 13 October 2013 (UTC)

At first it definitely needs to be a gadget or similar. Later after we see how it is being used we can see if and how to build it into the software directly. I definitely wouldn't want to do that without getting something to experiment with first. After that I am currently leaning to not integrating but this is not set in stone right now. --Lydia Pintscher (WMDE) (talk) 11:40, 14 October 2013 (UTC)
  • Support as long as it is done as some sort of temporary exhibition rather than a permanent label, given that what looks like a good item now may be badly outdated in six months. --Zolo (talk) 15:25, 13 October 2013 (UTC)
Well said, this is precisely my concern. I would conditionally support showcase items as long as it is understood (and preferably stated somewhere) that best practices on Wikidata are very much evolving. Emw (talk) 15:46, 13 October 2013 (UTC)
There is ways to handle that, by doing consistency checks wrt. some constraints, for example if the domain of a property changes, and a claim become out of this range because of that, the information should be displayed when the page is loaded to encourage people to keep the datas aligned with best practices if possible. TomT0m (talk) 15:52, 13 October 2013 (UTC)
Consistency checks can be helpful, but best practices on Wikidata concern much more than domain and range. My point is that we need to be careful of how we frame featured items to avoid facilitating the is-ought fallacy, which crept up incessantly in discussions about P107. There is no mechanism for detailed review of featured items as there is for featured articles, so it would be nice to have some mild cavaets in how we present these items. Emw (talk) 16:17, 13 October 2013 (UTC)
That's why we need to extend the number of checks that can be done, we could do much more than just checking domain and range to capture more accurately the best practices. TomT0m (talk) 16:25, 13 October 2013 (UTC)
I'm not sure I agree. For reasons that User:Silver hr outlined in User_talk:Emw#W3C_standards_for_property_.22domain.22_and_.22allowed_values.22, I am somewhat concerned about the domain and range constraints being implemented across Wikidata. Emw (talk) 16:37, 13 October 2013 (UTC)
I'm not sure I agree with silver_hr arguments, as we don't have to make the models totally aligned with owl, and keep the informations about the model as guidelines, and not strong constraints (alternatively we can adopt a weaker consistency definition than the all or nothing database consistency definition.), and it is still useful. Another way t say it : we don't have to follow strictly the owl semantics, and use other properties which do not have a stronh logic semantic and just serve as guidelines for editors, and for which inconsistencies is are heuristics to check if our guidelines are appropriates or if we should look at them a little more closely. TomT0m (talk) 16:53, 13 October 2013 (UTC)
If we're going to use terminology from RDF, then I think we should use RDF definitions for those terms. If for some reason we don't want to use RDF definitions for terms like 'domain' and 'range', then in my opinion we shouldn't call them 'domain' and 'range'. These particular terms are core components in W3C recommendations for the Semantic Web and as such have specific meaning: i.e., as rdfs:domain and rdfs:range. How they're used effects the results of SPARQL queries, which are likely to be a major feature of Wikidata in the future (see
Whether we decide to flout W3C recommendations or adhere to them is actually independent of my original point, which was that we should explicitly state somehow that showcase items are not set in stone, that Wikidata best practices are evolving. As long as we do that somewhere, I think showcase items are a good idea. Emw (talk) 02:24, 14 October 2013 (UTC)
We have two pages Help:Editing and Help:Statements where we can put a new table with the list of showcase items:
But we can already discuss here about the format of the table below Snipre (talk) 08:43, 14 October 2013 (UTC)
Field Class Showcase item(s) Discussion/questions/rules definition
Chemistry Chemical compound ethanol (Q153) Wikidata talk:Chemistry task force
Person Sportman Example Example
Art Opera Example Example
Art Song Example Example
Example Example Example Example
Just pointing two previous discussions: Wikidata:Project chat/Archive/2013/04#Featured Items and Wikidata:Project chat/Archive/2013/05#Featured items. --Ricordisamoa 10:38, 14 October 2013 (UTC)
I think it's better to avoid "featured" term: the main idea is to show an example of properties use and this is not relevant with good or "bad" item. By definition wikidata items are all good or featured items because the principle of improvement is not applicable. Snipre (talk) 11:22, 14 October 2013 (UTC)
How is it not applicable? Adding more sources, more qualifiers, more statements, more labels and descriptions in different languages all improve an item. --Lydia Pintscher (WMDE) (talk) 11:32, 14 October 2013 (UTC)
Theoretically once you add a statement you have to add all qualifiers and sources relevant to the value at the same time. This is an on-off process. If you add only value without adding the corresponding qualifiers or sources nobody will be able to improve your data: people won't be able to add missing data without information from where is the value coming or without access to the source. Even in the case of source defined as "imported from wikipedia": if you have 3-6 documents defined under the reference section of the article but no link between them and the data in the text or the infobox do you really try to find the documents and to search which document contains a specific data ? People will take their own sources and will include new statements deleting the previous unsourced ones.
And about labels and descriptions or for the number of statements, you have only a degree of completion. Can you really rewrite a better description once you have one ? And for statements in some cases you have few statements but this doesn't mean that the items is a stub but only that data are not available.
Wikidata items are like shelves with empty boxes: you can fill the boxes so you can measure a degree of filling but you can't do the filling in a good or bad way. So you can speak about completeness not more than that. Snipre (talk) 14:40, 14 October 2013 (UTC)
This theory only exists in your mind, or in another universe. Practically I have other theories, one of which is that this theory is neither reallistic nor something good for this project. TomT0m (talk) 16:40, 14 October 2013 (UTC)
Don't worry I know that you are a master in theory ;) Snipre (talk) 20:07, 14 October 2013 (UTC)

Related idea

What about a featured instances property for classes ? TomT0m (talk)

I   Support the proposal of Lydia: I learned how work Wikipedia looking at articles rather than reading help pages. I like the idea of TomT0m: Wikidata works using properties. --Paperoastro (talk) 18:19, 13 October 2013 (UTC)

Some good items

Here some items that can serve as example:

There are many more.--Micru (talk) 17:12, 14 October 2013 (UTC)

Good starting point, however, I have reservations about some items:
  • Mona Lisa (Q12418): incomplete (see talk:Q12418)
  • Drosophila melanogaster (Q130888) I do not like the properties like "class", "rank" etc. but even if we want to keep them, we should also use parent taxon (P171). Some data here but I do not add it myself, because it seems that it may require someone more knowledgable than me to sort it out the right way. --Zolo (talk) 18:02, 14 October 2013 (UTC). Someone has added it now, but it may stil benefit some more details. I see that there are several intermediate taxons between drosophila and drosophia melanogaster in the NCBI taxonomy. As a side note: I have added "instance of: taxon" I think it is correct and that would seem a convenient convention to follow for all taxons (like "instance of: human" for all people). --Zolo (talk) 20:51, 14 October 2013 (UTC)
  • Diary of Anne Frank (Q6911). I do not think that "World literature" can be considered a literary genre, as it seems to be something like a label for "universal masterpiece", but does not say anything about the content. If we need to put "world literature somewhere, that might be in "instance of". I do not think that "autobiography" is very accurate either. As I understand it, an autobiography is a book where someone attempts to recount her past life in a somewhat organized and distanciated manner. "genre: diary" is certainly more accurate, and I think it is sufficient. --Zolo (talk) 19:29, 14 October 2013 (UTC)
I have some reservation about Hubble Space Telescope (Q2513): COSPAR ID (P247) has as source imported from Wikimedia project (P143); instance of (P31) has too much claims; the source of some statements (Jonathan's Space Report (Q6272367)) has not any statements (e.g., authors, editors, etc.), so it is incomplete. This discussion is really going to end up in something... ;-) --Paperoastro (talk) 21:29, 14 October 2013 (UTC)
P31 can have as many claims as are the truth (and some that aren't—Wikidata isn't about the truth but about claims that can be made!). --Izno (talk) 23:01, 14 October 2013 (UTC)
Depending on the point of view: all the instances specify some different characteristics of the Hubble Space Telescope; space observatory is "a position", optical telescope and infrared telescope are the working wavelengths, Ritchey–Chrétien telescope is the "optical configuration". It is as we defined a person not human, but P31 -> person with <some colour> hair, P31 -> person with <some colour> eyes, P31 -> <his job>. As Pikolas told below, we need a standard to uniform the use of P31. This discussion, imho, is a good starting point. --Paperoastro (talk) 09:24, 15 October 2013 (UTC)
  • We ought to create standards, I believe. Ideally, all statements must be appropriately sourced (unless it is self-evident or self-sourcing). Also, "imported from Wikimedia project (P143) Wikipedia" should not be considered a valid source. Pikolas (talk) 22:21, 14 October 2013 (UTC)
Have you checked out the Source items and supporting Wikipedia sources RFC? Emw (talk) 22:56, 14 October 2013 (UTC)
I have not, thanks for the heads up. Pikolas (talk) 20:21, 15 October 2013 (UTC)
I have a problem with Mona Lisa: chassis (Q1068107), linked from Mona Lisa, is a bad set of links--some disambiguations, some not. That item should be split, and a more correct link should be found on top of that. --Izno (talk) 23:18, 14 October 2013 (UTC)
Thanks for pointing out, I have corrected the link. I am not sure what to do with Q1068107, actually "chassis" seems to have a general meaning in all linked languages, but more specialized meaning are more interesting so that some languages tag the generic page as a disambiguation page and some don't). Actually there is still something missing. What we have is an oak panel that was later affixed to a canvas, and the canvas was in turn propped onto an oak stretcher. I do not know how to express that clearly. --Zolo (talk) 07:10, 15 October 2013 (UTC)
I'd prefer to take a less controversial painting than Mona Lisa (Q12418) to show best practice – at least for now. --Marsupium (talk) 11:27, 18 October 2013 (UTC)

Some guidelines

Possible guidelines (not requirements, but aids in determining the quality of an item) for featured items:

  1. Label
    1. The label is accurate in at least all languages that the item links to
  2. Description
    1. The description is accurate in at least all languages that the item links to
    2. Most or all descriptions conform to the description guidelines
  3. Aliases
    1. The list of aliases are accurate and complete in at least all languages that the item links to
  4. Statements
    1. There are at least 5 statements
    2. The information in the statements is accurate and supported by a reliable Source
    3. The list of statements is reasonably complete
  5. Links
    1. There are at least 5 sitelinks
    2. The links are all accurate; the item does not need to be merged or split.

I think that anyone should be able to nominate an item for featured item status and anyone else can approve it. --Jakob (Scream about the things I've broken) 20:35, 15 October 2013 (UTC)

My 2 cents : I would be happy with an item that can serve as a model for the others of the same kind and fits in the models and best practices defined by vommunity, are correct in the sence that they have no structural problems such as constraint violations themselves and by their neighboor items, and are well defined. Having description is cool but that's not imho the most important point. TomT0m (talk) 20:54, 15 October 2013 (UTC)
  • What's a "common language"? We should definitely not discriminate against languages with smaller Wikipedias. Also, I think a featured item should have all possible statements that could be added to it, likewise for sitelinks. Pikolas (talk) 21:11, 15 October 2013 (UTC)
  • I just assumed it would be too demanding to have labels, descriptions, and aliases in 287 languages. I've changed the common language thing anyway. --Jakob (Scream about the things I've broken) 22:38, 15 October 2013 (UTC)
While I support the idea, it should be clear that we soon have millions of items which fulfill the guidelines above. Thus, I propose we should select items as featured which are good examples for modelling their type. We should select as few as possible. For example, it is enough to have one species item featured and only feature a second species item if it has different (not a subset) claims. Eg one extinct species and one monotypic (if properly sourced) - if we find a third item which is extinct and monotypic, the latter should be featured and the former two unfeatured. Thus, we gain a selection of items which are examples for "all" modelling questions.  — Felix Reimann (talk) 05:01, 16 October 2013 (UTC)
I agree, but there is two problems here : have good examples, and feature items. Example are importants, but featured items should be broader and serve as a quality reference, as featured articles does in WIkipedias. The latter is also important for contributers. TomT0m (talk) 10:38, 16 October 2013 (UTC)

Sugestion: creation of items about microprocessors

Hi. I suggest that a robot access the Intel site and gather information about microprocessors, than, create items for them here, on Wikidata.--MisterSanderson (talk) 22:36, 17 October 2013 (UTC)

Merge of properties

Shouldn't we merge member of political party (P102) and member of sports team (P54) to member of (P463)? I think we could use this "member of" property as a qualifier of properties like "occupation -> singer, qualifier: member of -> Metallica" or something like this. -- 19:03, 16 October 2013 (UTC)

+1 for merging — Felix Reimann (talk) 21:33, 16 October 2013 (UTC)
When doing such things please keep in mind that it will be harder to query for things that are in qualifiers. Initially for example you will only be able to query for one property with one value. So for example "give me the items that have musicbrainz identifier foobar". --Lydia Pintscher (WMDE) (talk) 21:37, 16 October 2013 (UTC)
In general qualifiers should apply to the statement, not to the item. 'member of:GOP' does tell us more about 'occupation:politician' but it is more about the item so it makes sense to have it as a property rather than a qualifier. I think that in general we try to have the property provide useful information on it's own with the qualifier providing additional information so a railway station can have 'station code:NXGATE' with qualifier 'instance of:British rail station codes'. Filceolaire (talk) 22:10, 16 October 2013 (UTC)
OK for the merge,   Strong oppose for using member of (P463) as qualifier. "member of" IS the relationship; a qualifier is only meant to supply secondary information on a relationship. I believe that "member of" should never be used as a qualifier. LaddΩ chat ;) 22:23, 16 October 2013 (UTC)
In all of this, no one stopped to question whether even "member of" is necessary --> the "part of" relation is even broader and makes the "member of" relation superfluous. My two cents on the way to world domination. --Izno (talk) 22:59, 16 October 2013 (UTC)
While it is true that member of is semantically the same as 'part of' nevertheless this is unlikely to cause problems for us as 'member of' can be used across a broad range of items - all people, all organisations - in a uniform way so it will not cause problems for infoboxes.
If anyone can show that there would be any benefits from using 'part of' instead then we can press the devs to create the 'subproperty of' relationshipso we can do searches of 'part of plus subproperties'. 09:23, 17 October 2013 (UTC)
The difference between "member" and "part of" is that "part of" is transitive, while "member" of is not. --Zolo (talk) 08:54, 18 October 2013 (UTC)
I would rather see a "split" of member of political party (P102). Membership of a political organisation is sometimes hard to find a source for. Adding such statements without a real source can be very problematic. The national railway company here, for example, has been sued for listing people who traveled at the expense of a political party. And it still happens today that somebody "represents" a political party in a legislative body without being a member of that party. -- Lavallen (talk) 10:20, 17 October 2013 (UTC)
This is true for both, the extra property as well as for "member of X" with "X instance of political party". Hopefully, it is as easy to check if phase III is here. Currently, you need third party tools for validation - for both systems.  — Felix Reimann (talk) 15:17, 17 October 2013 (UTC)
I think "member of" is fine when we want to say that the person is a member of sense that it pays it membership fee or whatever, but we may need an additional property to state that someone represents a party somewhere. In this case, I the simplest solution would seem something like "member of: Laketown municipal council. / on behalf of: Some Party". --Zolo (talk) 08:54, 18 October 2013 (UTC)
I would rather deal with usch cases with qualifiers and sources. Filceolaire (talk) 16:17, 19 October 2013 (UTC)
That exactly, is our proposal! -- Lavallen (talk) 16:56, 19 October 2013 (UTC)
+1 for merging -- Freedatum (talk) 08:26, 18 October 2013 (UTC)

Problem with hand warmer which is a disambig in German Wikipedia


The english wikipedia has an article Hand warmer which describes various types of hand warmers - fuel, charcoal, air actived and so on. This article has interwiki links to the german, italian, japanese, polish and chinese wikipedia. The latter four articles do indead also describe the various types of hand warmers, as I conclude from the article's pictures despite my missing language skills.

However, the german wikipedia has one disambig page Handwärmer saying that hand warmers exists with various working principles, then giving a list of four different articles, each of them only describing one type of warming device (not necessarily for hands only). One of these four is the article Aktivkohlewärmer that describes a warming device of the type "air activated".

Now, I think that the interwiki link should led to the German disambig page "Handwärmer" and not the page "Aktivkohlewärmer". I tried to change this but it's saying me: "Site link Handwärmer is already used by item Q1575313. Perhaps the items should be merged and one of them deleted? Feel free to ask at Project chat if you are unsure" - ok, here I am in the Project chat!

I'm not shure, but it seems that the reference to item Q1575313 means that it's not possible to make an interwiki to a disambig page? I understand somehow the arguments for that, but in this particular case, it should be done, or what do you think?

Best regards --Cyfal (talk) 12:37, 18 October 2013 (UTC)

As we can see de:Handwärmer is an example of "topical disambig" so it can be linked with articles. I exchanged de-links between items so they now corresponds to right notions. Infovarius (talk) 18:14, 18 October 2013 (UTC)
(I knew your opinion), and I disagree with you. --Stryn (talk) 18:20, 18 October 2013 (UTC)
Also you should not change the original meaning of item, like you did here. --Stryn (talk) 18:21, 18 October 2013 (UTC)
To me, it looks now fine after Invorvarius' modifications. However, I don't understand the technical details of Stryn's second posting. Would a translation of the german article help you - I noticed none of you speaks German? Here it is, self-created - the italics denote the links.
Hand warmers as a portable heat source do exist using very different physical and chemical principles:
  • Heating pads or heating pads with regeneratable latent heat storages
  • Disposable hand warmers, generate heat by the oxidation of iron powder
  • Pocket ovens, metal containers that generate heat by burning coal or gasoline
  • Heat ball, an early form of pocket ovens
  • Charcoal warmers
Best regards --Cyfal (talk) 21:37, 18 October 2013 (UTC)
We should never link together article and disambiguation page. It makes harder to use statements. Everyone who is working with Wikidata should read Wikidata:Disambiguation pages task force/guidelines. --Stryn (talk) 09:59, 19 October 2013 (UTC)
And to my second post: if some item is named to "cat", and there is links to pages with the name "cat", we can't delete all links from the item, and then add there links like "dog". Choice is to delete the item, if it's without links, not to replace it. --Stryn (talk) 09:59, 19 October 2013 (UTC)
Wikidata items linked to Wikipedia disambiguation pages with links to items which have similar names but are otherwise unrelated are not treat as normal items since they do not relate to any instance or class of real world things.
Wikidata items linking to wikipedia pages which list related items can usefully be linked to other articles, even if the version in certain languages is tagged as a disambiguation page. This german article is a good example. It describes a 'class' of items. Items which are members of this class can link to this item using the instance of (P31) property. A similar situation arises with 'name' articles. Often you will find some languages have articles which list people with that name while other languages have articles which include such lists but also discuss the etymology and use of the name. This is discussed on the help page that Stryn linked too above. I will be proposing some changes to Wikidata:Disambiguation pages task force/guidelines to come inline with my comment above. Anyone interested should discuss this on the talk page there. Filceolaire (talk) 16:14, 19 October 2013 (UTC)
Thank you both for your explanation and your work. I tried to resolve the problem now by changing the german page from a disambiguation page into an normal article page[9]. In fact, it was not realy a disambig in the strict sense of the word, as it become clear to me after your discussion. I hope my changes in the German Wikipedia will not be reversed again...
Best regards --Cyfal (talk) 13:58, 19 October 2013 (UTC)

Kendo on Danish wiki

The old article on Danisk wiki will be deleted. A new article entitled "Kendo" has been made.

Please make the change also on interwiki. beste regards Rmir2 (talk) 08:26, 19 October 2013 (UTC) (from Danish wiki)

  Done as it seems that w:da:Kendo efter Meiji-restaurationen is not the same as Q170931 --Glaisher [talk] 08:34, 19 October 2013 (UTC)

Property Metadata

I was speaking to Lydia a few moments ago about several property metadata property proposals. The development team has had plans to allow storing of metadata. Lydia asked me to start a Project Chat thread for her about this and she is asking the community how the community feels metadata should be stored on pages (wikitext, templates, statements etc.) and what type of data should be stored. Feedback from the community on this is greatly appreciated and will be considered by the development team when metadata for property pages is eventually started. John F. Lewis (talk) 19:12, 6 October 2013 (UTC)

Can you describe what are property metadata ?Because there are different kind of information: constraints, description of use, example of use,... Snipre (talk) 00:23, 7 October 2013 (UTC)
I suppose that he is talking about all kinds of property metadata (contraints, description of use, example of use...). Personally, I think that statements is the best way to store them because it will makes these metadata easily machine readable and will follow the Linked Data spirit (we would have equivalent of rdfs:subPropertyOf, rdfs:domain, rdfs:range and maybe even of owl:sameAs in order to do automatic mappings). Tpt (talk) 07:27, 7 October 2013 (UTC)

How should property metadata be stored

as statements
I favour this as it matches what is done on items so my little brain can easily understand it. Filceolaire (talk) 17:55, 8 October 2013 (UTC)
  Support. See above. Tpt (talk) 19:12, 9 October 2013 (UTC)
  Support, for consistency and machine readability. When the query engine, metadata will be available by querying, which will make easyier to develop tools to use them. TomT0m (talk) 12:43, 12 October 2013 (UTC)
  Support. We should use statements to extend Wikidata's strong structure. There may still be a need for templates (on the talk page) for info statements can't handle (particularly during the transition), but I don't think templates should be the primary mechanism. Superm401 - Talk 06:01, 13 October 2013 (UTC)
  Support, for consistency and machine readability. That seems like the most gadget-and-tool-friendly solution. All the uses for metadata suggested below would fit well within statements using already existing datatypes. --Zolo (talk) 21:14, 11 October 2013 (UTC) (fixed on 13 october)
  Support, as Zolo (as I posted in my "deleted" comment below). I like the current solution (templates on Property:Talk pages), but Wikidata works with properties, and imho this is the best solution. --Paperoastro (talk) 18:29, 13 October 2013 (UTC)
  Support of course as statements, only this way it keeps machine-readability. -- MichaelSchoenitzer (talk) 14:41, 14 October 2013 (UTC)
  Support. This is how OWL deals with property metadata; see Emw (talk) 14:53, 14 October 2013 (UTC)
  Support Thieol (talk) 19:53, 15 October 2013 (UTC)
  SupportΛΧΣ21 03:04, 20 October 2013 (UTC)
as templates
  Support, for consistency and machine readability. That seems like the most gadget-and-tool-friendly solution. All the uses for metadata suggested below would fit well within statements using already existing datatypes. --Zolo (talk) 21:14, 11 October 2013 (UTC)
I don't follow. You say it "would fit well within statements" (I agree), but your 'support' is under 'as templates'. Superm401 - Talk 06:01, 13 October 2013 (UTC)
Uh, apparently I posted I posted it under the wrong header. --Zolo (talk) 11:43, 13 October 2013 (UTC)
This matches what has been done on Property:Talk pages Filceolaire (talk) 17:55, 8 October 2013 (UTC)
  Support for Zolo and Filceolaire. --Paperoastro (talk) 12:30, 12 October 2013 (UTC)

  Comment I don't agree with Zolo, templates are harder to read with a machine than templates, who needs to be parsed. In wikidata it's much easier to query for metadata than parsing the templates. For human readability, metadata statements should be formated by templates and so on. Statements are more robusts to syntactics errors, can be checked by the same tools as the other statements in Wikidata, it's much more consistent. TomT0m (talk) 12:43, 12 October 2013 (UTC)

As Wikitext
Not sure how this would work. Filceolaire (talk) 17:55, 8 October 2013 (UTC)

  Comment It would be possible to use somthing as Turtle syntax or Manchester syntax, who would be easier to write for humans, but would need to be integrated in the software if we want an efficient use and checks.

As appropriate controls on property page

For example:

RegExp pattern: [_\d{8}________________________________]
URL fomat:      [_$1_______]
I don't see how these control would be stored. Could you explain it for people like me? Tpt (talk) 19:12, 9 October 2013 (UTC)
Same way as property label or property description. — Ivan A. Krestinin (talk) 19:25, 9 October 2013 (UTC)

What type of data should be stored

datatype Property
useful for identifying properties which are semantically the same as other properties e.g. instance of (P31) and P132 (P132).
Also matches rdfs:subPropertyOf. Filceolaire (talk) 17:55, 8 October 2013 (UTC)
  Conditional support. I would support storing subproperty claims only if the semantics matched those of rdfs:subPropertyOf. As an aside, I'd also like to point out that I have concerns about applying subproperty claims to instance of (P31), which is defined by rdf:type. Those concerns are outlined in Wikidata:Contact_the_development_team/Archive/2013/08#Subproperty_relation. Emw (talk) 16:13, 14 October 2013 (UTC)
datatype item
links to a class-item (an item which subclass of and instance of properties link to). The property should (mostly) only be used on items which are an instance of (P31) of items which are subclasses of the class-item specified by this property.
matches the rdfs:domain property Filceolaire (talk) 18:06, 8 October 2013 (UTC)
  Conditional support. I would support storing domain claims only if the semantics matched those of rdfs:domain. This implies constraints that can be leveraged by semantic reasoners to do type inference, as summarized in These are "strong" constraints. User:Silver_hr made some informative comments on this in W3C standards for property "domain" and "allowed values". Emw (talk) 15:56, 14 October 2013 (UTC)
@Emw : I doubt we can seriously align the semantics to those of owl like that, as we would have to ckeck the consistency of the whole wiki and of the database all the time. I'm pretty sure considering the size and perimeter of the database it would be kind of really hard, and that it would be all the time inconsistent, so anything could be logically deduced ... We need something weaker, and try to achive all ontology consistency and zero constraint violation with the tools we have. TomT0m (talk) 18:05, 14 October 2013 (UTC)
Having the definition of 'domain' match rdfs:domain is independent of how we ensure consistency in the knowledgebase. It simply means that for a property P that has the domain C, "resources denoted by the subjects of triples whose predicate is P are instances of the class C." Whether we want to prevent inconsistent statements though measures in the UI or simply detect inconsistent statements after the fact as we currently do is an independent matter -- we can still use rdfs:domain as the formal definition of 'domain'. Emw (talk) 19:36, 14 October 2013 (UTC)
Formal definitions in owl is useful if we want to prove that the onlogy is consistent and the datas are consistent. If there is inconsistencies, then by en:explosion principle then anything becomes virtually inferable, that makes inferences pretty useless, so we lose the advantages of having strong and well defined semantics. If a kitten can become a mayor, then we can't decently say the range of the mayor property is a subclass of human in those conditions. Or we need to make a special case in the ontology just for that, or to weaken the constraint insanely. That means if we do a owl export of that, the database will have to be badly curated before we actually can use it in a reasoner. TomT0m (talk) 20:23, 14 October 2013 (UTC)
Using rdfs:domain as the definition of domain does not in itself prove that the ontology is consistent. It simply provides one of multiple criteria to show that. Consistency enforcement is a distinct, independent matter, as explained above.
Furthermore, citing exceedingly rare counterexamples as a reason to abandon the idea of property domain and range constraints is in my opinion a red herring. First, we should ask ourselves if such counterexamples are actually valid. Can a kitten be a mayor, or can a horse be a senator? No, they can't -- by default, considering such things to be invalid subjects of properties conventionally restricted to humans is entirely reasonable. It is completely sensible to assert that kittens cannot be mayors. Second, if there is a compelling reason to expand the domain or range of properties beyond their conventional values, then we have a viable option in the case of crazy office holders or other subjects of properties conventionally restricted to humans: expand the domain from human (Q5) to person (Q215627). As described in the Wikipedia article Person, that term is quite the catch-all. Third, the fact that some properties might have unintuitively broad domains and ranges does not negate the fact that other properties actually do have well-defined domains and ranges. The domain of encodes (P688) is subclasses of gene (Q7187), and its range is subclasses of protein (Q8054) or RNA (Q11053). The statement Q14862218 encodes (P688) kitten (Q147) is always wrong. Emw (talk) 22:05, 14 October 2013 (UTC)
Domain-property + Class-item
datatype property for 'Domain-property'. datatype item for property 'Class-item' used as a qualifier to 'Domain-property'.
property should only be used on items which have the specified property linking to an item in the specified class. This is more flexible than rdfs:domain as you can use other statements besides instance of (P31):item. Filceolaire (talk) 18:06, 8 October 2013 (UTC)
  Leaning oppose. This idea is unclear to me. It seems novel and independent of W3C standards, so I think it requires extra justification. Emw (talk) 15:56, 14 October 2013 (UTC)
datatype item
links to a class-item (an item which subclass of and instance of properties link to). The property should (mostly) only only link to items which are an instance of (P31) of items which are subclasses of the class-item specified by this property.
matches the rdfs:range property Filceolaire (talk) 17:55, 8 October 2013 (UTC)
  Conditional support. I would support storing range claims only if the semantics matched those of rdfs:range. See comments in Domain section above. Emw (talk) 15:56, 14 October 2013 (UTC)
Equivalent property
datatype url
links to equivalent properties in other ontologies. Filceolaire (talk) 18:06, 8 October 2013 (UTC)
  Support It would allow us to do automatic mapping. It's similar to owl:sameAs. Tpt (talk) 19:12, 9 October 2013 (UTC)
  Comment. Since we're talking about properties, we should call this 'equivalent property' and have its semantics match those of owl:equivalentProperty. ('Same as' should match owl:sameAs and thus apply only to individuals, i.e. items that have 'instance of' claims.) As with other property properties here, I would support storing 'equivalent property' claims only if the semantics matched those of owl:equivalentProperty. A 'same as' property proposal (permlink) recently garnered significant discussion from Wikidata developers and Semantic Web researchers. A relevant excerpt:
The property owl:sameAs is used to say that two things are exactly equal. One could also say that sameAs declares two identifiers to be synonymous. So anything that was said for the one identifier could also be said for the other. In particular, this means that both things have the same properties. It is a very strong statement of absolute and unlimited identity.
Even though Markus isn't referring to this specific property, I have a hunch that he would issue similar cautions about this property. Emw (talk) 15:56, 14 October 2013 (UTC)
  Comment Per my comment immediately above, I've changed the name of this proposed metadata field from 'Same as' to 'Equivalent property'. Emw (talk) 13:19, 19 October 2013 (UTC)
  Conditional support I would support storing 'equivalent property' claims only if the semantics matched those of owl:equivalentProperty. Emw (talk) 13:19, 19 October 2013 (UTC)
URL format
where a property links to a string which is a code used on another website then this property would specify how to convert the code to a url that links to the item on that website. This is for Authority Control and other similar properties. Filceolaire (talk) 18:10, 8 October 2013 (UTC)
+1, MediaWiki:Gadget-AuthorityControl.js must be integrated to Wikidata directly. — Ivan A. Krestinin (talk) 18:54, 9 October 2013 (UTC)
  Support Tpt (talk) 19:12, 9 October 2013 (UTC)
Pattern (for string properties)
Integrate {{Constraint:Format}} with wikibase. Engine must validate value format before saving it. Validation is needed for API edit requests too. — Ivan A. Krestinin (talk) 18:54, 9 October 2013 (UTC)
One of
Integrate {{Constraint:One of}} with wikibase. This allows to replace value editor to combo-box. This will be very usable at least for sex or gender (P21). — Ivan A. Krestinin (talk) 18:54, 9 October 2013 (UTC)
  Oppose It is going to be unavoidable that however we model our data we will produce some systemic bias. That is why it is important that we allow users to break out of that constraining model if they feel they have a rare value that needs to be placed. sex or gender (P21) is a good example of why we shouldn't have Acceptable items. The way we encourage users characterise sex is very European - essentially Binary Male/Female, with an intersex conecssion. However some other cultures would argue more categories, or even a spectrum of sex. If we push a list of acceptable items we are limiting from having richer multi-cultural perspectives. And its not just sex, anytime there is a rare value for a property it we would be missing that if we enacted acceptable items. Maximilianklein (talk) 00:52, 17 October 2013 (UTC)
That would not completely prohibit values that are not in the list - it has been made clear that restricting possible values is not on the dev team agenda anyway. But for properties like sex, using an unusual value is likely to be an error, so such a property seems useful to me. It could be used to make constraint violation reports, just like the current {{Constraint:One of}}, and conceivably to make javascript to warn users that they are entering unusual values. --Zolo (talk) 07:21, 17 October 2013 (UTC)
  Conditional support I would support storing domain claims only if the semantics matched those of owl:oneOf. 'One of' can be a useful constraints -- see the examples in That said, we need to be careful to not oversimplify the acceptable values for a property by applying 'one of' constraints too zealously. Emw (talk) 00:31, 18 October 2013 (UTC)
  Comment I've changed the name of this quasi-section from "Acceptable items (for some item properties)" to "One of". The latter is more succinct and commonly understood. Emw (talk) 00:31, 18 October 2013 (UTC)

Sorry Lydia. I was trying to help by giving the discussion some structure but I seem to have killed the discussion stone dead. :( Filceolaire (talk) 18:43, 9 October 2013 (UTC)

Heh thanks for bringing in some structure. Everyone: Please keep giving input. This is useful. It's important for me to see how you'd want to use this to make sure it's actually useful. --Lydia Pintscher (WMDE) (talk) 09:30, 10 October 2013 (UTC)
Statements with properties as valued.

To express statements like owl:asAttr, which I think would be really a good thing to improve user experience, we would need to use properties as values for this property. TomT0m (talk) 12:43, 12 October 2013 (UTC)

Bloc québécois

Hi people, w:es:Bloc Québécois was moved to w:es:Bloc québécois. I want to update the link, but I can't. If I write québécois it changes it for a capital letter. What can I do?... See the item here, Jmvkrecords Intra Talk 19:50, 14 October 2013 (UTC).

Looking in the history it seems that you properly updated it... is there still a problem? Ajraddatz (Talk) 19:51, 14 October 2013 (UTC)
No, now is ok, maybe it was a problem with my CPU cache. Thank you, Jmvkrecords Intra Talk 22:57, 14 October 2013 (UTC).
  • just out of curiosity, why is "québécois" not capitalized in spanish wiki? it is a proper name Lx 121 (talk) 03:15, 15 October 2013 (UTC)
I guess that the user who moved the page decided to follow French spelling rules instead of Spanish spelling rules. This make sense in a French name, although most wikipedias capitalize trailing words in French names - except for French wikipedia.--Pere prlpz (talk) 14:18, 16 October 2013 (UTC)
Hi. Québécois is an adjective and adjectives in French do not write in capitals. In Spanish references uses three ways (or more) to name this political party: Bloque quebequés, Bloque quebequense, or Bloc québécois. Moreover references in Spanish don't prioritize any form over another, then I used this term in French based in this reference, and this one, in accordance with local policy. Regards, Jmvkrecords Intra Talk 07:05, 20 October 2013 (UTC).

P856 and language

Looks like official website (P856) needs a language-qualifier. We have more than one, which is the most appropriate in this case? -- Lavallen (talk) 14:37, 20 October 2013 (UTC)

Original language, if there is one. But if all language versions are equally original, then I suppose we'd have to include them all. Pikolas (talk) 18:00, 20 October 2013 (UTC)

Author abbreviations in taxonomy

[restored from archive]

Our botanist author abbreviation (Property:P428) duplicates and is a subset of author citation (Property:P835). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:31, 9 October 2013 (UTC)

Please read the descriptions of botanist author abbreviation (P428) and author citation (zoology) (P835). --Succu (talk) 16:49, 9 October 2013 (UTC)

I read both before posting here. For the benefit of others, they are;

botanist author abbreviation 
standard form (official abbreviation) of a personal name for use in an author citation (only for names of algae, fungi and plants)
author citation 
standard abbreviation of an author's name, used to cite the first description of a new species

(and they each have "Data type: String") so I'm not sure how your comment addresses the issue I raised. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:10, 19 October 2013 (UTC)

P428 is the official abbreviation of an authors name as given by IPNI. P835 is for all other cases as for example in zoology, there is no official abbreviation. Carl Linnaeus (Q1043)'s abbreviation according to IPNI is "L.", while in zoology "Linnaeus" is typically used. The Module:Taxobox uses P428 if given and the taxon is a plant, algae or funghi, otherwise P835 is used, if none of both are given, the last name is shown.  — Felix Reimann (talk) 09:43, 21 October 2013 (UTC)

Queries problem

I've recently noticed how many tools that involve queries aren't working properly, like GeneaWiki, Ancestry viewer, and Consistency Check. Is this a problem with Wikidata or is it just me? --Wylve (talk) 09:58, 20 October 2013 (UTC)

They are broken since the "upper-case ID" update. I know nothing about javascript, but my corrected version of ancestry.js works. Pyb (talk) 09:01, 21 October 2013 (UTC)
I see, thanks. --Wylve (talk) 10:23, 21 October 2013 (UTC)

Changing Interwiki selection priority

Now the interwiki priority for Mediawiki is:

  1. Transcluded tempate's local interwiki
  2. locale interwiki (old style [[en:foo]] in the wiki text)
  3. wikidata's lang links

Would you please change it's priority inverse? 1-wikidata 2-locale interwiki 3-Transcluded tempate's local interwiki

I mean if the page had Transcluded template or old style interwiki it check the wikidata's at the first after that the old style interwiki and at the end Transcluded template

Now this bug cause: If the page has locale interwiki or Transcluded template (which has locale interwiki) the changes in wikidata doesn't have effect on wikipedia!

Also many of the Interwiki conflicts will be solved automatically (because they were solved in wikidata)!Yamaha5 (talk) 08:17, 21 October 2013 (UTC)

Template talk:ProjectChatLanguages

Hi! I posted there: "Is it possible to add a link to the proper language versions of Project:Embassy (Q1197883) ?"
This might be useful for the chat type pages. Maybe it would be helpfull in other situations as well. Regards לערי ריינהארט (talk) 13:29, 21 October 2013 (UTC)

WMF Wikimaps grant proposal : produce thousands maps done right for Wikidata !

Hello wikidata,
Arun Ganesh/Planemad and myself (Hugo Lopez/Yug), who collaborated to create the WikiAtlas demo: the wikidata-binded, dynamically translated map of India, are pushing SVG map making forward. We just publicly announced a grant request on the Map Workshop talkpage (French announcement). The project aim to learn from cartographer map making practices, automatize the process, to programmatically provide administrative location_maps and physical relief_location_maps for all countries (level L0), all provinces (L1), and maybe all subdivisions (L2). The project being centralized, and based the current location_maps and relief_maps color schemes. This projects will produce well coded stand alone maps, opening the way to interactive maps, wikidata-data binding and translations. It is also a doable on short term, ~6 months, while OSM / Sharemape approach need more time to deploy, and will satisfy different needs. Please take a look, and support us on meta untill Oct. 22th ! Cheer ! Yug (talk) 12:25, 19 October 2013 (UTC)

Please also spread the word to notable Wikidata users, that will help ! Yug (Diskussion) 19:12, 19. Okt. 2013 (CEST)
Despite the great work we made with your data and our maps (WikiAtlas demo: the wikidata-binded, dynamically translated map of India), none of the Wikidata community expressed his/her support yet. We could do greater. Please come and endorse our Wiki Atlas project --Yug (talk) 16:24, 22 October 2013 (UTC)


how did you extract data from wikipedia to wikidata

Mostly be taking information from templates and from categories. A lot of work for bot, but a substantial amount of manual checking for humans as well ! --Zolo (talk) 16:40, 22 October 2013 (UTC)

User contributions

This user also was me, before i created my wikidata account. Can you move all contributions from IP address to my username? Thx.XXN (talk) 16:13, 22 October 2013 (UTC)

Hi, It is not possible to change the author of contributions to Wikimedia projects. John F. Lewis (talk) 16:20, 22 October 2013 (UTC)
While this is not technically possible, you can link to those contributions on your userpage if you would like. — PinkAmpers&(Je vous invite à me parler) 22:28, 22 October 2013 (UTC)

turkish page

Psödoefedrin is the turkish page of Pseudoephedrin (german)... please link  – The preceding unsigned comment was added by (talk • contribs) at 22:58, 22 October 2013‎ (UTC).

  Done (  Merged Q6063548 to Q263958). For future reference, you can move the link yourself, and request deletion of the emptied item. Perhaps it's none of my business, but that article looks like it needs some serious love. Basically just an ingredients list; even includes the creator's signature. — PinkAmpers&(Je vous invite à me parler) 23:11, 22 October 2013 (UTC)

Merge Dorji Wangchuk in de and en

Dorji Wangchuk appears to be the same in both wikis. Djembayz (talk) 04:09, 23 October 2013 (UTC)

  Merged by Pikolas (talkcontribslogs); Q5298029   Deleted by myself. For future reference, you can move the link yourself, and request deletion of the empty item. See Help:Merge for more information, or ask me on my talk page if you have any questions. — PinkAmpers&(Je vous invite à me parler) 04:58, 23 October 2013 (UTC)

Question/suggestion re template items

Is there a way to add a hatnote, if you will, to Q-items referring to Wikipedia templates? I'm thinking specifically of cases where the template actually also exists here (like {{Usertalkback}} or {{Talkback}}). Right now, the only way to find something like that by search is to do an advanced search, unchecking the main space. It would be useful if a hatnote saying something like:

A version of this template resides on this wiki and can be found at Template:Talkback.

appeared on the corresponding Q-item page. I'd appreciate people's thoughts on this. StevenJ81 (talk) 15:44, 22 October 2013 (UTC)

I believe there's currently a bug for us to be able to link to ourselves in the database. Obviously, it's not fixed yet. :D --Izno (talk) 00:00, 24 October 2013 (UTC)

Cross namespace issues

Hi everyone, I compiled a list of items with cross namespace issues. Who helps with fixing these issues? Items should link to either articles, categories or templates, not a mix of these. Multichill (talk) 20:10, 22 October 2013 (UTC) :Yes; these are items which have sitelinks to wikipedia pages which are intersections of two classes.

  1. We don't tell Wikipedias how to organise their articles
  2. Wikidata items reflect the wikipedia articles
  3. If a wikidata item is the intersection of class A and class B then it can be classified as a 'subclass of:A' and a 'subclass of:B'
so Australian architects is classified as 'subclass of:architects' and 'country:Australia' and so on. Filceolaire (talk) 00:15, 23 October 2013 (UTC)
Sorry Filceolaire, how does your response relate to the page I just linked? Articles link to articles, categories link to categories and templates link to templates is the well established interwiki practice for more than 10 years. Are you disputing this? Multichill (talk) 08:12, 23 October 2013 (UTC)
Oops. Sorry; I misread your comment and misunderstood it. You are talking about wikidata items which have sitelinks to articles in some languages and categories in other languages. Rereading this morning it's obvious that is what you were saying but for somereason I didn't see it last night.
Looking at the first item. The odd one out is arabic. Googletranslating it suggests the arabic page is trying to do the same as the templates on the other languages but hasn't got it right yet.
The next one has a strange german infobox for a book linked to the en article for that book. Again looks like some mistake on the de:WP.
A lot of the items have lists and categories which do need to be on separate items but linked using the 'category main topic' property.
Who helps with fixing this? You do by making the list. Others do by moving the extraneous sitelinks one by one by hand. I'll do some. Filceolaire (talk) 09:02, 23 October 2013 (UTC)

Don't let bots working continuously

Just a small remark for bot owners: don't let your bot working on the same data import script continuously. I explain: once you did the data import stop your script in order to give a chance for manual correction. If I did a correction for example by deleting a wrong statement (I don't correct the error in wikipedia) by letting your bot active my deletion will be useless.

Wikidata needs a statrting database, Ok, but after the first import, bots have to stop import in order to avoid to erase previous correction. The goal of wikidata is to attract contributors to work in wikidata not to extract what people are adding in wikipedia articles. Thank you Snipre (talk) 17:32, 24 October 2013 (UTC)


Hoi, Could someone please give Rezabot the bot flag? Thanks, GerardM (talk) 17:06, 25 October 2013 (UTC)

He already has the bot flag, he is not just using it. I asked him to fix the issue. --Stryn (talk) 17:20, 25 October 2013 (UTC)

Need merger 13:22, 27 October 2013 (UTC)

merged by User:Izno and deleted empty item Q7708636. -Nizil Shah (talk) 21:34, 27 October 2013 (UTC)

Accessing Wikidata sitelinks on Meta

Hello. Is it possible to get a specific sitelink of a specific Wikidata item using ParserFunctions or Lua? πr2 (tc) 14:40, 27 October 2013 (UTC)

Not yet, but it will, in due time. The header with a sitelink to Commons, will sooner or later also include links to meta and other multilanguage-projects. -- Lavallen (talk) 15:00, 27 October 2013 (UTC)
Let me clarify. I don't think Meta should get a sitelink. I meant is there a way to get e.g. the French sitelink of some item e.g. Q100 on Meta? Meta is supposed to be multilingual, so we could fix many Wikipedia articles links on Meta to be Wikidata links that forward to Wikipedia in the user's language. Not sure if that makes sense. πr2 (tc) 15:45, 27 October 2013 (UTC)
Query the API ? --Zuphilip (talk) 16:09, 27 October 2013 (UTC)
When phase II is activated on meta, you can use the parser and Lua. Until bug 47930 is solved, the metapage have to have a sitelink here. -- Lavallen (talk) 16:18, 27 October 2013 (UTC)
Will you be able to do so for multiple items in one page, and refer to one item in multiple pages? πr2 (tc) 00:41, 28 October 2013 (UTC)

Merging Categories (Water parks)

Please somebody merge categories

Jaceknow (talk) 22:09, 27 October 2013 (UTC)

  Done - In the future, you can use merge.js to merge items yourself. --Jakob (Scream about the things I've broken) 22:12, 27 October 2013 (UTC)

spilt birth date(P:P569), death date (P:P570) and coordinates (P:P625)?

Shouldn't we spilt

  1. a new property "birth date of animal" from date of birth (P569)? because there're articles with instance of (P31)=dog (Q144)/house cat (Q146)/...
  2. a new property "death date of animal" from date of death (P570)?
  3. a new property "coordinate outside Earth" from coordinate location (P625)? there're a lot of article with coordinate location (P625) which globe isn't Earth, but "the place" is on Denny's map.

--GZWDer (talk) 12:25, 21 October 2013 (UTC)

For coordinates "outside Earth" we should record not just the body (Moon, Mars, etc.) but the coordinates reference system in use (whatever is used instead of WGS84) - though the latter may imply the former. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:48, 21 October 2013 (UTC)
It looks silly to me to make a birth property specific to animals, birth is birth, and we can know it's an animal by the class it's instance of. Or we should have a birth property for all things ... why not a birth property for every specied or dog breed ? it does not really make sense. TomT0m (talk) 15:19, 21 October 2013 (UTC)
The API already supports to enter to globe. It is an extra field in the database. If coordinate from e.g., the moon is shown on a map of the earth, this specific coordinate was entered incorrectly or the map does erroneously not respect this attribute.
What's the difference between "death date" for a human and "death date" of a horse?? Nothing. After this point in time, the subject is dead. Use "death date" for both.  — Felix Reimann (talk) 15:41, 21 October 2013 (UTC)
I think the reason for the proposal was that property talk:P569 as a "human" constraint. We should replace it with something better. "Instance of living thing" ? Can we express ? And should we allow this properties for non-living things ?
On the face of it, a different "coordinates" property for other planets does not need really needed but I am a bit worried about data usability if even Wikidata developers do not think about filtering by globe when developing their tools.. If that is much more convenient, or signficantly more efficient to separate betwen a "coordinates on Earth" and a "coordinates on another globe" propertiy, I am fine with it. --Zolo (talk) 16:01, 21 October 2013 (UTC)
The only use of constraints I'm aware of is constraint violation reports, and that's all. It's kind of informal. So yeah, as many other constraints, we should relax the constraint, and we should ask ourselves how important they are in the community process. As you know I'm for using them to build tools who suggest properties, and to associate constraint to classes to do sophisticated suggestions. TomT0m (talk) 16:53, 21 October 2013 (UTC)
The most appropriate domain of date of birth (P569) and date of death (P570) is organism (Q7239). In other words, if an item fulfills the claim instance of (P31) organism (Q7239) -- whether it be a particular human, cat, dog or horse -- then it is a valid subject for 'birth' or 'death' properties. If a user is looking to do something with birth and death dates for people, then (when necessary features are available, e.g. queries and bug 50911) they should query along the lines of "find all items that fulfill instance of (P31) human (Q5) and date of birth (P569) after 1980". Emw (talk) 00:28, 22 October 2013 (UTC)
Per comments from several users above, I have changed the constraint on date of birth (P569) and date of death (P570) from human (Q5) to organism (Q7239). Emw (talk) 01:12, 22 October 2013 (UTC)
That seems to make sense but that has me wonder: do we need to add "sublcass of organism" on every taxon-item ? --Zolo (talk) 06:42, 22 October 2013 (UTC)
No, it's transitive, so we should just add it's a subclass of its upper taxon, and the upper one will be organism. It's not a problem that it is not implemented in the database as consistency checks are based on external tools. TomT0m (talk) 10:23, 22 October 2013 (UTC)
It seems plausible that any instance of an instance of taxon is an organism, but an individual human is not an instance of taxon: taxa are sets of individuals sharing common features, not individuals. So how does the inheritance work ? -Zolo (talk) 10:50, 22 October 2013 (UTC)
I think, parent taxon (P171) is a subproperty of subclass of (P279) (unfortunately, this cannot be expressed currently). Thus, human as well as sheeps are subclasses of organism. Barack Obama is instance of human, Dolly is instance of sheep. Besides that, human, sheep, and mammals are all instance of taxon (a group of organisms which are related closer among themselves than to any other organism).  — Felix Reimann (talk) 11:27, 22 October 2013 (UTC)
Possibly, but if we want Dolly to inherit its "instance of organism" from taxon, we need to things:
  1. Taxon is a subclass of organism
  2. Dolly is an instance of taxon.
If we consider that Dolly is also the set consisting of a single element, that is the sheep Dolly, #2 seems logically defensible, but I am not sure that biologists would agree with calling individuals taxa. I do not think that #1 is true: taxon is a subclass a "group of organism" but I do not think it is a subclass or "organism". If it were, "mammal is an instance of taxon" would imply "mammal is an instance of organism". --Zolo (talk) 17:02, 22 October 2013 (UTC)
And if taxon == "group of organism" ? Then if organisms is an instance of taxa and human is a subclass of organism, then human is also an instance of group of organism, because it inherits the properties of organisms. TomT0m (talk) 17:25, 22 October 2013 (UTC)
Yes, if "instance of instance of group of organism" is exactly equivalent to "element of a set of organisms", that would work nicely. But then, how do we express that ? taxon: subclass of set (Q36161) of (P642) organism (Q7239). ? Or a new property "subclass of group of", which would avoid qualifiers and would seem easier to deal with. --Zolo (talk) 22:51, 22 October 2013 (UTC)
No, taxons are special kind of group of organisms, so taxon is subclass of group of organisms, as monophiletic taxon for example. It works as well, everithing we can say about groups of organisms is true for taxons. The converse is not true, so it's not a real equality as in my post, but a specialization.. TomT0m (talk) 23:28, 22 October 2013 (UTC)
Not sure of what you mean, as it seems to be the same thing as what I was trying to say ;). But I am wondering how we should say "subclass of group of organism". There are various possiblities:
  1. taxon: subclass of: "group" of (P642) organism
  2. taxon: subclass of: "group of organism". Group of organism: subclass of: group of (P642): organism
  3. taxon: subclass of group of: organism. So a specialized property for "subclass of group of"
I would guess that the third solution is simpler than having to rely on qualifiers for ineferences. --Zolo (talk) 07:48, 23 October 2013 (UTC)
The second solution, which is closer to what we would call a upper ontology in spirit if I understand well what it is, is a great help for building generic tools. What I think would be really great for Wikidata is that we could achieve to build gadgets that can adapt to different situations. And adding two statements and a property instead of just a property can be a small price for that if we can build tools that can help a user to find what he should use as a property in any goup of things cases ...
The third solution is bad in this goal in that a tool would have to embed a specialization to handle group of organisms property, and make another case for group of tool. It implies more work to build tools around Wikidata reasoning, so in the worst case the new Wikidata user interested in that domain would have absolutely nothing to help him. It's trading effort into building powerful modeling expressivity and a few generic code, versus a little more flexible modeling expressivity to more code and help page. That is if we make the effort to model things and build the generic tool of course, so it's not obvious which of them could work, but I think the second versus the third solution is not really a high cost and has potential much higher reward. TomT0m (talk) 10:43, 23 October 2013 (UTC)
Solution 3 would be a generic "subclass of group" property. I don't see how it would require more specialized tools than the other two. In all cases, we need a tool that knows that subclasses of groups call for a special treatment.
With solution 3, the tool would only need to know: 'if Item is an instance of a "subclass of group of X" then Item is an instance of X.' With solution 2, the tool would follow the subclass chain until it finds the value "group", and it would have to know that when something is a subclass of group, we need to check the value of the "of" qualifier. That seems much more complicated (not mentioning that I am not sure that adding an "of' qualifier to a subclass really makes sense). --Zolo (talk) 12:18, 23 October 2013 (UTC)
I don't like the idea, they are nevertheless subclasses. and the name is really ... horrible, scary ? If we really not want to have to use transitive properties, there probably are better solutions. Subgroup of seems a better name for example, but I don't think we need another property. TomT0m (talk) 15:43, 25 October 2013 (UTC)
I don't think the main problem is the transitivity in itself, it is that the transitivity would be dependent on a qualifier (I last I don't see how it can work otherwise, any idea how it works elsewhere ?) I dont like the name "subclass of group of" but "subgroup of" would seem to mean "instance of group", and I do not think that would be correct: mammal is an instance of group but taxon (Q16521) is a subclass of group. --Zolo (talk) 08:04, 26 October 2013 (UTC)
What would be dependant on a qualifier, I don't follow you (but maybe I'm just tired). Let's say <taxon> is a subclass of <group>. We can entail, one way or another, that any <group> instance (and taxon) has a subgroup of property (which upper taxon could actually be a subproperty of). What do we need more ? TomT0m (talk) 17:02, 27 October 2013 (UTC)
If we want to know that instances of instances of taxon are organisms, we do not just need to know that "taxon" is a group, we need to know that it is a group of organisms. If we use taxon: subclass of group", I do not see how we can do without a qualifier: "subclass of: groupof: organisms. --Zolo (talk) 17:56, 27 October 2013 (UTC)
We probably need a special semantics for groups, that's true, and a semantic of specialization, but that's true with a qualifier or with a property, it's not that much of a qualifier versus property problem, it's that maybe we are really starting to build something new. I don't see a real problem as we as for now are just not starting to align on owl for example, and the rdf export will work anyway. And in that export, classes are just relations, nothing else. TomT0m (talk) 11:36, 28 October 2013 (UTC)
The subclass relationship is transitive, not the instance relation. So being an instance of an instance of taxon do not imply to be an instance of taxon, whereas being an instance of a subclass of organism imply being an instance of organism. So if human is a taxon, and human is a subclass of organism, then I am an organism. but I am not a taxon. TomT0m (talk) 17:04, 22 October 2013 (UTC)
Exactly. If I am a human then I am a hominid and a primate and a mammal and an animal and an organism but I am not a species or a family or an order or a kingdom or a taxon.
It looks like we need to say that only items with 'Parent Taxon:Biota' (that is where you end up if you follow 'Parent Taxon' all the way) should have a date of birth or death Filceolaire (talk) 00:45, 23 October 2013 (UTC)
There is provision for each coordinate to have a 'globe' but you cannot edit it through the UI yet.
It is possible for the globe parameter to be set to celestial sphere (Q12134) to give the location of stars in the night sky but that globe does not seem to have been used yet. You would of course have to specify the distance to the star as well in order to completely specify its location - or at least it's location when last seen. Filceolaire (talk) 00:55, 23 October 2013 (UTC)
It is a good idea, Filceolaire, and I like to know if it is technically feasible: celestial coordinate systems need also an "epoch" for the position of stars! In addition the equatorial coordinate system expresses the right ascension (i.e. the longitude) in hours instead of in degrees (1h = 15 degrees)! I have just asked the developers what they think. --Paperoastro (talk) 16:01, 24 October 2013 (UTC)

Thinking a bit more about the set/element problem. We basically saying:

  • W (<->taxon) is a subclass of group of X (<->organism) and
  • Y (<-> mammals) is an instance of W and:
  • Z (<->Einstein) an instance of Y, then

-> Z is an instance of X We are not saying that Z has to be an instance of Y in order to be an instance of Z, but still, the following case may be worth pondering:

  • Archipelago is a subclass of group of islands and
  • the Antilles is an instance of archipelago and
  • Barbados is an island

But I think we will agree that Barbados is "part", not "instance" of the Antilles, That is a problem: if subclass = set, instance = element and part = subset, "instance" is the property that would make logical sense. I think the difference is that when we are speaking about mammals, we are mostly describing features that are common to all mammals (elements), while we we are speaking about the Antilles, we are describing the whole archipelago, not the individual islands. I am wondering how much pratical importance can have this sort of things. --Zolo (talk) 17:56, 27 October 2013 (UTC)

part is not subset of, it's the inverse of composed of. Barbados is a part of the Antilles as the Antilles are composed of Barbados and the other islands. The subset relations would imply that all the subsets of Island of the Antilles would be part of the Antilles, where we should only take the individuals islands. Subset of is subclass of, as the set of all taxons are a subset of all groups. TomT0m (talk) 23:10, 27 October 2013 (UTC)
Yes, this is exactly my point: an archipelago seems to be a group of islands, just like a taxon is a group of organisms, yet the inner structure is different (in one case "part", in the other "instance"). That might be a problem. --Zolo (talk) 09:37, 28 October 2013 (UTC)
A part of the answer maybe : an archipel is a token in the sense we discussed in membership properties : it is located in time and space, whereas a taxon is something more abstract. Maybe the key is that a token cannot have instances, just can be splitted in parts ? If the islands are instance of something it's as they are instances of islands of <this> archipel, a subclass of islands, and this would entail that they are part of this archipel. This would allow consistency checks. TomT0m (talk) 11:06, 28 October 2013 (UTC)


Q5626735, Template:Infobox, is for Wikipedia templates that present quick information about a topic at the top of a page. Wikivoyages also have a Template:Infobox, but on Wikivoyage, it's a template for tangential trivia information and is usually displayed as a simple sidebar box. Some Wikivoyages also have a template for quick information at the top of a page, but it's called Template:Quickbar (Q14395495).

So voy:en:Template:Quickbar and its ilk should be associated with Q5626735 (wikipedia:en:Template:Infobox and its ilk), while voy:en:Template:Infobox and its language-versions should have their own separate Wikidata item. But I'm not sure the best way to straighten out that tangled mess.

-- LtPowers (talk) 13:41, 22 October 2013 (UTC)

Anyone? LtPowers (talk) 13:54, 27 October 2013 (UTC)
Just do it and see whether anyone objects.--Ymblanter (talk) 17:47, 28 October 2013 (UTC)

Commons category (P373) vs. sitelink to commons

I found several edits, when experienced user (often admin) added link to commons and then removed the same link from Commons category (P373). It seems like duplicate, but property is used by several languages in {{Commonscat}}, and after removing some articles lost their connection to Commons - there is special monitoring category Category:Commons category without a link on Wikidata (Q11925744). Thanks. JAn Dudík (talk) 09:02, 24 October 2013 (UTC)

P373 is used not only in {{commonscat}} now. Many infoboxes use this property too. Migration is sequential process:
Stage 1: define sitelinks structure (discussion);
Stage 2: add sitelinks to items with P373 and import existing interwiki links from Commons;
Stage 3: migrate {{commonscat}} and infoboxes form P373 to sitelinks;
Stage 4: remove P373 from items.
Currently stage 1 is incomplete, so it is too early to start stage 4. — Ivan A. Krestinin (talk) 19:37, 24 October 2013 (UTC)
If even experienced users are screwing things up, perhaps Commons sitelinks should be turned off until Stage 1 is complete. Once we reach that point, we can develop a plan to implement the agreed structure (which might be just Ivan's stages 2-4 above, or might involve more extensive restructuring of Wikidata items and software). Currently there is a lot of confusion/disagreement about what to do, and different people are doing different things. This is not ideal. --Avenue (talk) 21:13, 24 October 2013 (UTC)
You forgot Stage 5: delete P373.--GZWDer (talk) 06:04, 25 October 2013 (UTC)
I haven't followed this RfC and now is it a 100k-talk. Is it solving cases where there is no 1:1 relation between Commons and Wikipedia? See the header of commons:Category:Blekinge as an example? -- Lavallen (talk) 07:15, 25 October 2013 (UTC)
No, that's not the issue. The main issues being discussed are which Wikidata items should have sitelinks to which Commons pages, and how the interwiki links in the sidebar of Commons pages should be maintained. Most of the discussion (and the !voting) has focussed on the first issue, not the second, although they are clearly linked.
The Wikidata model used so far for Wikipedia and Wikivoyage involves storing just one sitelink from each project language edition in each item, with separate items for pages on the same topic but in different namespaces, but this doesn't apply easily to Commons. Apart from pages in the File namespace (which Wikidata doesn't want to cover), most Commons pages are categories, and over 80% of the categories with interwiki links point to Wikipedia articles.
Meanwhile Commons galleries, which are much less numerous than categories, also have interwiki links to Wikipedia articles. Around half of those galleries with interwiki links share their targets with categories (i.e. both the category and gallery link to Wikipedia articles on that topic), although these amount to only about 10% of categories with interwiki links. So we do need to support a kind of non-1:1 relationship, but (a) these are quite different from the non-1:1 example you give, and (b) such relations are only a small part of the wider problem at present. --Avenue (talk) 09:24, 25 October 2013 (UTC)
Using Commons category (P373) is the accepted method for cross-namespace linking between a article/item in Wikipedia/Wikidata and a category on Commons. As long as there are no concensus at Wikidata:Requests for comment/Commons links there is no other accepted way of linking to commons. /Esquilo (talk) 13:36, 28 October 2013 (UTC)

Mango Article


I tried to add a language link between the English page "Mango" and the Arabic page "مانجو" several times, but it never worked. It always gives me the error "Site link Mango is already used by item Q169."

The 2 pages are not linked together now. Please let me know how to solve this.

"مانجو" ist linked to Mangifera indica (Q3919027) an article about the tree Mangifera indica. mango (Q169) is about the fruit of this tree. --Succu (talk) 15:17, 28 October 2013 (UTC)

Contribute a link to your local job coding system (1 minute)

As part of the Wikidata:Occupations_and_professions_task_force, we're adding properties for national job codes (ROME in France, SOC Codes in the US, NOC Codes in Canada…). Those are generally numbers and letters that code for a job or an occupation. Can you look if your country has such a system in place, and add it to our discussion page so that we can integrate it into Wikidata ? More generally speaking, we're also looking for technical and non-technical contributors to get the ball rolling. --Teolemon (talk) 15:23, 28 October 2013 (UTC)


I was planning around with adjacent station (P197) today. Wouldn't it be nice to have this for every railway station (Q55488) so we get an interconnected network spanning from Aberdeen railway station (Q2665551) to Beijing railway station (Q285141)? I started Wikidata:Railways task force to see if that's possible. Who wants to help? Multichill (talk) 16:44, 27 October 2013 (UTC)

My guess would be that a bot could look at items, and if a station lists an adjacent station, it could add that station to the adjacent station item. Also, on frwiki, some lines plans haven't been imported. The job seemed done for the Paris Metro, but not for smaller lines that have the proper markup (look at the bottom of this page: So much could be automated, and a visualisation would be awesome.  – The preceding unsigned comment was added by Teolemon (talk • contribs) at 15:36, 28 October 2013‎ (UTC).
Yes, for some sources a bot could probably be used to import the data. Would be nice. Multichill (talk) 22:45, 28 October 2013 (UTC)

Werner Motors duplicates

Q2830612 should be deleted and nl:Werner (motorfiets) should be linked to Q7983456 where the German and English articles are. — Brianhe (talk) 21:39, 28 October 2013 (UTC)

  Merged. All 3 links are now in Q2830612. --Stryn (talk) 22:08, 28 October 2013 (UTC)

Another question about migrating away from P107

Hello, I have some question about migrating away from P107
1-about organization (Q43229), how we can migrate away? I checked the RFC and there wasn't something useful there. It was suggested in my talk page that we use instance of (P31) = organization (Q43229) and remove the P107 (P107). Is it okay? what do you think?
2-about term (Q1969448), I want to be sure there is no problem removing all of them by my bot. is it okay to remove it? I'll start it if there is no objection.
3- Q11651459 is it okay to just instance of (P31) = Wikimedia disambiguation page (Q4167410) an remove this? Amir (talk) 11:50, 19 October 2013 (UTC)

Hi Amir, answering your questions in order:
  1. Yes. Per Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type#Organization, I think it's OK to simply replace P107 (P107) organization (Q43229) claims with instance of (P31) organization (Q43229) claims. The discussion regarding the appropriate subclass hierarchy for work (Q386724) demonstrates that it is difficult to arrive at consensus for a subclass hierarchy for some GND main types. In my opinion, at this point, further postponing the migration away from P107 until we arrive at consensus subhierarchies for GND main types would not be helpful. This means that we may well have redundant or partially redundant P31 claims for 'organization' items -- at least until there is consensus on an 'organzation' type hierarchy. Emw (talk) 12:59, 19 October 2013 (UTC)
  2. Yes. Per Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type#Term, it's OK to remove P107 (P107) term (Q1969448) claims outright, even if there is no P31 or P279 claim on the item yet. There was suggestion that 'term' claims should be deleted last, but as one of the two people who supported that notion, I think it's fine to delete P107 'term' claims at any time.
  3. Yes. Per Wikidata:Requests_for_comment/Migrating_away_from_GND_main_type#Name_.28disambiguation.29, P107 (P107) Q11651459 claims should be replaced by instance of (P31) Wikimedia disambiguation page (Q4167410) claims.
Please wait for at least 24 hours before initiating this round of bot work. That way we can hopefully catch any last minute questions or comments on these mappings. Thanks again for your help with this. Emw (talk) 12:59, 19 October 2013 (UTC)
instance of (P31):organization (Q43229) is better than using P107 but better still is 'instance of':'band' or 'political party' or 'football club' or other more specific organisation type. You might be able to use the categories that articles are in to help your bot find these relationships. Filceolaire (talk) 15:09, 19 October 2013 (UTC)
As mentioned above, I am concerned that developing a consensus subclass hierarchy for 'organization' will unnecessarily bog down the P107 migration effort. That's precisely what happened with the discussion about a subclass hierarchy for 'creative work'. If others want to commit to developing a consensus subclass hierarchy for 'organization' then I would support such an effort. However, what I want to avoid is an exceedingly tedious discussion that comes to no clear resolution. In other words, unless a group of committed people want to come up with a well-thought-out proposal for 'organization' subclasses in the immediate future, then I think it would be best to simply map all P107 'organization' claims to P31 'organization' claims now, temporarily accept the redundancy in some items that that implies, and defer a more sophisticated, non-redundant mapping until such a proposal is available. Does that sound reasonable? Emw (talk) 15:48, 19 October 2013 (UTC)
I would tend to be confident that community will come to something good by collaboration without too much tedious discussions. subclass / instance are flexible enough to have several way to class things, and I think that if a user wants to express that a live performance, for example, is a subclass for performance, he does not have to go through a tedious process he just does it. TomT0m (talk) 16:12, 19 October 2013 (UTC)
"if a user wants to express that a live performance, for example, is a subclass for performance, he does not have to go through a tedious process he just does it."
Of course, but this thread is not about such one-off hand-mapped hierarchies. It's about determining which P31 values are redundant with a P31 value of 'organization'. To do that we'd need to determine many of the subclasses of 'organization'. My assertion is that such an effort is not worth halting the migration of P107 'organization' claims. We can clean up redundant P31 claims later, after an appropriately detailed discussion produces a well-thought-out class hierarchy for 'organization'. Emw (talk) 13:23, 20 October 2013 (UTC)
Yeah, I was agreeing with Ladsgroup behind, as soon as we have an instance of something we can drop the organisation GND main type as the item will not leave unconnected for very long (plus we do not really exploit the claim in Wikibase ...) TomT0m (talk) 13:29, 20 October 2013 (UTC)

I have a general proposal: If the item has P31 and the target of P31 has "subclass" property (I can't recall the property number) let's delete P107 anyway! how that sounds? Amir (talk) 18:25, 19 October 2013 (UTC)

Support. If that is doable, I think an even better solution would be to check whether the subclass used is itself a subclass of organization. If it is, remove "term: organization", otherwise, put the value on a list, and let users have a look at it so that they can fix the subclass tree and/or erroneous values. --Zolo (talk) 07:41, 20 October 2013 (UTC)
Ideally we should have database reports about the classes structure : no loops, maybe check that all classes are reasonably integrated into the hierarchy (they all are subclasses of a few gerenral concepts at the same level of the GND main type roughly). TomT0m (talk) 09:56, 20 October 2013 (UTC)
Even very basic checks of classes structure gives huge number of violations. Please see Wikidata:Database reports/Constraint violations/P279, Wikidata:Database reports/Constraint violations/P31. Currently the structure is far from hierarchy. — Ivan A. Krestinin (talk) 10:28, 20 October 2013 (UTC)
It's not supposed to be a hierarchy, but a directed acyclic graph (Q1195339) :) . Plus if you looks like your constraint report, you will see that you will correct several errors just by one edit, so it's not really scary. TomT0m (talk) 11:05, 20 October 2013 (UTC)
"Ideally we should have database reports about the classes structure."
This isn't possible without resolving bug 50911 or hacking together code to recursively go "up the chain" of an item's P279 values. Emw (talk) 13:11, 20 October 2013 (UTC)
As for any other database reports like constraint violations. TomT0m (talk) 13:29, 20 October 2013 (UTC)
I would oppose this idea. This assumes the current high-level classifications derivable from P279 are roughly equal to or better than P107 classification. I think that's a naive assumption and quite possibly incorrect. We have no tools to usefully examine the P279 class hierarchy, so it's pretty much opaque to us.
Mapping P107 claims to corresponding P31 claims was the original proposal of the Migrating away from GND main type RFC and ultimately the conclusion of that RFC. We can't simply radically alter the migration plan for a property with 4+ million claims while we're in the middle of remapping those claims. Let's stick to the plan from the migration RFC. It implies some redundancy, but that's resolvable later, after we have devoted time to developing consensus on subclass hierarchies for each of the GND main types. Emw (talk) 13:43, 20 October 2013 (UTC)
Alternatively we can take the better of both by adding the presumed fact that the class the item is an instance of is a subclass of organization in the case it is an instance of something. TomT0m (talk) 14:08, 20 October 2013 (UTC)
We could do a lot of alternative things. Each of those alternatives would likely require weeks of additional discussion, and would have a significant chance of simply fizzling out and becoming lost to the archives without actionable results -- as many of these brainstorming sessions do.
Or we could stick to the plan that was discussed for months in RFCs, and preserve a modicum of order in the migration of what until recently was Wikidata's most popular property. That plan had input from a good number of contributors and is in the middle of being executed. In my opinion the time to make significant changes to the migration plan was before the RFC closed -- not now, especially not without specific, well-presented arguments for how the current plan has major problems. I think we should now focus on implementing the plan that's already been worked out. Emw (talk) 14:42, 20 October 2013 (UTC)
I would agree with you if we had a plan, I'm afraid the RfC conclusion do not really say the same thing. Anyway, I think it's not really important because there is not that many applications right now that rely on the fact we have a stable structure, so I'll back and continue the work. I'm not opposed to map to this class as long as it is true. We can remove the statement if it is redudant with a more precise class, or deduce that the class is a subclass of organization as well, and do all that as the same time. This just needs to be done, we discussed enough. TomT0m (talk) 15:01, 20 October 2013 (UTC)

Hello, I have another question about migrating away from P107
4-about geographical object (Q618123), how we can migrate away? I checked the RFC and there wasn't something useful there. In Wikidata talk:Country subdivision task force/Germany#Gliederung der einzelnen Verwaltungseinheiten mit Verwendungshinweisen we wonder, if we have to remove P107 (P107) and simply replace it by instance of (P31) = geographical object (Q618123), as we not at all have to deal with astronomical object (Q6999). Would this be okay? Or should we remove both P107 (P107) and geographical object (Q618123), and replace the latter by instance of (P31) together with a lower-level classification like municipality of Germany (Q262166) . What do you think? --Brühl (talk) 12:51, 24 October 2013 (UTC)

P.S.: Wikidata:Requests for comment/Migrating away from GND main type#Place discussion does not really give a clear answer to my request. --Brühl (talk) 23:11, 25 October 2013 (UTC)

Brühl asked me to write a comment here. I don't understand all the discussion, but I think an item for "this is a geographical feature" makes sense in addition to "state" and "coordinates", like we have "this is a human" in addition to "male" or "female". I don't really care about the kind of property. Holger1959 (talk) 12:05, 26 October 2013 (UTC)

For example it would be possible for a municipality X in Germany to add
  1. "X instance of (P31) municipality of Germany (Q262166) and X instance of (P31) geographical object (Q618123)"
  2. only "X instance of (P31) geographical object (Q618123)"
  3. only "X instance of (P31) municipality of Germany (Q262166)"
  4. nothing
In all cases there would also be the statement "X P132 (P132) municipality of Germany (Q262166)". I would prefer no. 3 and add directly or indirectly that "municipality of Germany (Q262166) subclass of (P279) geographical object (Q618123)".
There are subjects with P21 male, which are no instance of a person, e.g. Jack Bauer (Q24) is male but no instance (P31) of a person, also he had GND-type person before. --Zuphilip (talk) 11:32, 27 October 2013 (UTC)
This is because Jack Bauer (Q24) is a fictional character (Q95074). See the outcome of RfC Wikidata:Requests_for_comment/Migrating_away_from_GND_main_typeJFG talk 16:29, 30 October 2013 (UTC)
Yes, exactly. But every municipality of Germany (Q262166) is also a geographical object (Q618123) (altough there is not (yet?) a connection over P279). Therefore the comparison between persons and geographical features by Holger1959 is not really applicable. What are the migration plans for geographical objects, like municipalities? I haven't found any clear information in the cited discussion. --Zuphilip (talk) 20:13, 30 October 2013 (UTC)
Administrative divisions are probably never going to link to geographical feature, simply due to the fact that they aren't geographical. The assertion that they ever were is puzzling to me. But aside from that, most cases of 'geographical feature' aren't needed whatsoever for the subclasses, and for the instances, it's likely we can just move that over to P31. --Izno (talk) 22:24, 30 October 2013 (UTC)
Hm.. I have to admit that it sounds wrong to say that "municipality of Germany (Q262166) subclass of (P279) geographical object (Q618123)", but on the other hand it sounds okay to say that "Dresden (Q1731) instance of (P31) geographical object (Q618123)". Language is strange! Izno, you suggest no. 2, to replace P107 geographical feature simply by P31 geographical feature, right? --Zuphilip (talk) 12:30, 31 October 2013 (UTC)
Sorry Zuphilip, I just read your Jack Bauer (Q24) question and didn't check the broader context you were referring to. Regarding places, the RfC is indeed a bit vague. My opinion would be to use your third solution: Place X is an instance of (P31) the closest city type you can find, and get rid of the geographical object (Q618123) attribute. Note that Dresden (Q1731) is not even a municipality of Germany (Q262166) at this time, just a city (Q515), big city (Q1549591) and state capital in Germany (Q14784328)… Lots of work ahead! — JFG talk 23:57, 30 October 2013 (UTC)
Okay, thank you. Yes, there is some work ahead, but note that Dresden has the value Q3559083 in P132. --Zuphilip (talk) 12:30, 31 October 2013 (UTC)
Mmhh, are we supposed to deduct P31 from P132 then?? Smells fishy. — JFG talk 16:25, 31 October 2013 (UTC)

Happy Birthday, Wikidata!

Heya folks :)

Today is Wikidata's first birthday. One year ago Q1 was created. This is time for a lot of celebration and a bit of reflection. Join us over at Wikidata:First Birthday for an editorial on Wikidata's accomplishments and challenges by Sven, some notes by me, a great interview and some cupcakes ;-)

Cheers --Lydia Pintscher (WMDE) (talk) 00:03, 29 October 2013 (UTC)

Today Oct 29 is wikidata's birthday! look the logo! I specially thanks to our admin group, WMDE staffs and All editors! You guys make the wikidata:D--DangSunM (talk) 00:05, 29 October 2013 (UTC)
Wow! I can't believe it's been a year. Wikidata has certainly matured quite a bit since last year. πr2 (tc) 00:08, 29 October 2013 (UTC)
Happy Birthday (Q412055), ▌█ █ ▌▌█ ▌█ ▌▌ . --Yair rand (talk) 00:15, 29 October 2013 (UTC)
Wikidata has certainly come a long way!
  The Wikidata Barnstar
This is for all Wikidatans! --Jakob (Scream about the things I've broken) 00:58, 29 October 2013 (UTC)
Selamat hari jadi yang pertama buat Wikidata! Salam sukses selalu! Wagino 20100516 (talk) 04:59, 29 October 2013 (UTC)
One year. Wow. You know, at the start of the project, one really couldn't tell how things were going to turn out; for all we knew, the community could have become a bunch of incapable semitrolls and the dev team could have been unable to get the software to a usable state, and the project could have crashed and burned to a crisp before having a good chance to get off the ground. But it really didn't take that long before it was pretty clear that pretty much everyone involved was extraordinarily competent. I've never seen a community as capable of handling things as this one. The devs outperform anything I've ever seen the WMF do, getting the software actually working well, in quite a short period of time. From here, to my overly optimistic viewpoint, it seems fairly apparent that Wikidata is going to become of immense importance to the world, and incredibly successful in its mission of delivering loads of free structured data. So, let me take this opportunity to leave a brief message to any future wiki-historians looking into the early history of this tremendous project:
The megadatabase behind everything is awesome, and the inevitable "Nobody early on could possibly have predicted Wikidata's incredible success" comments are wrong. Neener neener.
Somebody do me a favor and link to this comment when 29 October 2022 comes around. --Yair rand (talk) 22:05, 29 October 2013 (UTC)
<3 --Lydia Pintscher (WMDE) (talk) 22:30, 29 October 2013 (UTC)
Wake me up in 2032 then! — JFG talk 04:01, 31 October 2013 (UTC)
Just to note that Wikidata was open for editing October 30 (at least my first edit is Oct 30, and I am pretty sure I started on the first possible day), so that tomorrow is also a kind of a birthday. We may want to keep the birthday logo for one more day.--Ymblanter (talk) 22:48, 29 October 2013 (UTC)
Back for another 24 hours :) ·addshore· talk to me! 12:57, 30 October 2013 (UTC)
Well I made my first edits 29th day, but let us celebrate more ;P --Stryn (talk) 13:14, 30 October 2013 (UTC)
Yeah, me too :P πr2 (tc) 14:33, 30 October 2013 (UTC)
A very happy birthday to wikidata… I began to contribute on the 31th, so quite early too… and am very proud to be a small (a very small) part of that big, very BIG project :D --Hsarrazin (talk) 17:37, 30 October 2013 (UTC)

All you base are belong to everyone! Congratulations to everyone around! --NaBUru38 (talk) 21:43, 31 October 2013 (UTC)

how to add taxonomic synonyms?

RDB (imho one of the best sources for reptiles) uses not Coluber andreanus but Hierophis andreanus as binomen. I learnt how to merge items manually - but some bots added statements and I have no idea how to proceed according to Wikidata's rules. Any help is appreciated :) Rbrausse (talk) 10:01, 29 October 2013 (UTC)

You should use the "Merge" gadget in your preferences to merge items that describe the same thing. Where there are conflicts between the interwikis (as in, multiple pages on a particular project describing the same thing), you need to use good judgement about which links should go where. In the case of organism taxonomies, it's usually fairly clear what needs to go where and whether the various projects' pages duplicate information or not. For the links that are "duplicate" (see e.g. User:Soulkeeper/dups, it's good practice to add merge tags to the projects' pages which should be merged. Izno (talk)
so far so good - but I still don't know how to add synonyms to the properties of a taxon item. Merging would suppress the Coluber andreanus binomen, still widely used as Hierophis andreanus was defined only 3 years ago. Rbrausse (talk) 07:50, 30 October 2013 (UTC)
At present unfortunately we have no working solution (see: Wikidata talk:Taxonomy task force#synonyms). --Succu (talk) 08:52, 30 October 2013 (UTC)
okay, thanks - and the taskforce link is very helpful! Rbrausse (talk) 09:38, 30 October 2013 (UTC)
'Coluber andreanus' should be an alias (if it is now obsolete) with 'hierophis andreanus' as the label (if it is currently preferred). Once we have the 'monolingual text' datatype we can create the 'official name' property and can list both names with appropriate dates and creators for each. Filceolaire (talk) 13:19, 30 October 2013 (UTC)
I disagree. But here is the wrong place to discuss this matter in depth. Please discuss at Wikidata talk:Taxonomy task force#synonyms. --Succu (talk) 13:47, 30 October 2013 (UTC)

Modelling horses

I have requested Legobot to add "instance of horse" to items about indvidual racehorses. That sounds simple enough, and consistent with "instance of human". But yet, how do we state "stallion Thoroughbred racehorse" ?

--Zolo (talk) 10:11, 29 October 2013 (UTC)

For stallion / gelding I think we can say it's a male: sex property doesn't mean it can reproduce.
For the activity of the horse occupation (P106) seems good and for the thoroughbred characteristic I will say : do you really need to save athat information in Wikidata at the moment ? Is it an used information currently displayed in infoboxes ? I know that the final objective is to have as much data as possible but I think we have to go step by step. The interest of wikidata is to have the same level of details for a whole class of items: to many details in some items doesn't help because this is no possibility for comparison, for listing,...
I think here we have a typical problem which can be solved only by creating a list of properties for a class and to keep that list as short as possible at the begining but this insuring that you can find all these properties in the items belonging to the class. Then once most of the properties are filled you can think to extend the property list.
Why a step-by step approach ? Because it already now quite difficult to know which properties exist to describe an item: we are losing the overall view of the description possibilities and different ways to describe an item of a specific class can be created. Snipre (talk) 12:47, 29 October 2013 (UTC)
My main concern with using "occupation" is that is seems to make sanity checks more complicated. Occupation, like several other properties, is mostly useful for items about people. That makes for relatively easy santiy checks: if the property is used on a non-human item, this is likely to be a mistake. I suppsoe it would be possible to have a more sophisticated system like "usually, the item should be a human, but if the value is "racehorse" it should be a horse, but I am not entirely clear on how that should be organized. --Zolo (talk) 06:55, 30 October 2013 (UTC)

thoroughbred seems to be a subclass of horses, and also an instance of horse race ... I think we could (should ?) have a race property and a class. the horse class might entail an optional race property, the thoroughbred class should imply a value to this property. TomT0m (talk) 18:27, 29 October 2013 (UTC)

It would make a lot of sense to ask en:Wikipedia:WikiProject Equine (and in fact all local horse-related projects). They understand the needs better than we (or at least I) do. Mergehappy (talk) 21:04, 29 October 2013 (UTC)
It would make sense to ask them what data are useuful, but I think we also have a more Wikidata-specific problem, which is how should we structure things so that data are consistent are relatively easy to retrieve. --Zolo (talk) 06:55, 30 October 2013 (UTC)
The good project is w:en:WikiProject Horse racing and if we take an example like w:en:Allez France, the parameter thoroughbred is not include in the infobox. Better use this information with property instance of (P31). Snipre (talk) 08:06, 30 October 2013 (UTC)
I think that for horses (and dogs and other domesticated animals) people usually refer to 'breeds' not 'races'. A 'horserace' is a competition to see which horse is the fastest.
I think that in the cases of horses we could have instance of (P31) refer to the breed (pony, appaloosa, shire, thoroughbred etc.) rather than directly to 'horse'. Each of these breeds would of course be linked to 'horse' by the 'parent taxon' or the 'subclass of' properties. Filceolaire (talk) 13:13, 30 October 2013 (UTC)

Language statistics

Let's say 40% of people in some city speak English natively, and 60% speak French natively, according to a census. How can that be stored in Wikidata? πr2 (tc) 15:05, 30 October 2013 (UTC)

This will have to wait for a numeric datatype. --Tobias1984 (talk) 18:08, 30 October 2013 (UTC)


Hi there!

I tried to add pl_wiki:Chloroza to the Chlorosis page here and did not succeed. Can someone please do the merge? Thanks.

ValJor (talk) 18:01, 30 October 2013 (UTC)

The link was in another item. I merged them: Chlorosis (Q1075317). --Tobias1984 (talk) 18:08, 30 October 2013 (UTC)

Arabic speaker wanted to help map relevant articles on Jesus Christ (Q302)

I am reviewing the interwiki mappings of various articles about Jesus Christ (Q302): details are in Wikidata:Interwiki_conflicts#Jesus. I need help from a native Arabic speaker to determine the appropriate item described by page ar:تاريخية_المسيح, which I have determined not to be quest for the historical Jesus (Q1284211), but is it about historicity of Jesus (Q13588125), historical Jesus (Q51666) or something else entirely? — JFG talk 22:53, 30 October 2013 (UTC)

I'm not Arab and I'm Persian so I know a little Arabic but I'm sure the translation of the title per the first sentences of the article is "Historicity of Jesus". P.S. the only reference of the article is "The New Testament"! How natural and verifiable this article is, I don't say anything :| Amir (talk) 13:12, 31 October 2013 (UTC)
Thanks Amir, I have matched this page to historicity of Jesus (Q13588125) as suggested. — JFG talk 13:16, 31 October 2013 (UTC)

Problem with Interwikimedia links

I have the same problem with articles related to it:Tarantismo / de:Tanzwut (or better de:Tarantismus) linking them back and forth. Since it is an Italian phenomenon the italian page should be referenced in the other foreign language pages

Site link Tanzwut is already used by item Q2140711. Perhaps the items should be merged and one of them deleted? Feel free to ask at Project chat if you are unsure.

the German also links to an as:Arab entry which should be propagated to the other languages

Thanks for helping out

I can't put the Interwikimedia links of the italian page Palazzo del gran maestro to the versions of other languages (Grandmaster's Palace, in -- 15:18, 31 October 2013 (UTC)

  Done: the article of the Italian Wikipedia was already in Wikidata (Q3891300), so you could not add it to Grandmaster's Palace (Q1368885). I merged the two items in Grandmaster's Palace (Q1368885). --Paperoastro (talk) 17:36, 31 October 2013 (UTC)

Problem saving pages

There is a technical issue related to saving pages and the new search system (Elastic) that is being enabled (as secondary search option) on Wikidata. Ops staff are aware and trying to resolve it. If you get an error when saving, this is why. Aude (talk) 17:59, 31 October 2013 (UTC)

The problem should be resolved now. Aude (talk) 18:49, 31 October 2013 (UTC)

Mouseover in "Languages"

Hello! I'm looking for the elements I would have to edit to translate the mouseovers in the "Language"-area on the left side. In the English wikipedia, the mouseover says something like "Articlename – German", when moving the cursor over the interwiki-link. In our Sorbian wikipedia the languagenames are still in German, so I suppose they haven’t been translated yet. I'd like to do that, but I don’t know where. Regards, J budissin (talk) 23:31, 31 October 2013 (UTC)