Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
(Redirected from Wikidata:Bybrunnen)
Jump to navigation Jump to search

Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Please use {{Q}} or {{P}}, the first time you mention an item, or property, respectively.
Requests for deletions can be made here. Merging instructions can be found here.
IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2018/11.






a query

for deletions

for comment


for permissions


for deletion

and imports




problem with softcover (Q990683)[edit]

Viswaprabha (talk)
Maximilianklein (talk)
Jane023 (talk) 08:21, 30 May 2013 (UTC)
Alexander Doria (talk)
Ruud 23:15, 24 June 2013 (UTC)
Jayanta Nath
Yann (talk)
John Vandenberg (talk) 09:14, 30 November 2013 (UTC)
Danmichaelo (talk) 19:30, 16 February 2014 (UTC)
Ravi (talk)
Mvolz (talk) 08:21, 20 July 2014 (UTC)
Hsarrazin (talk) 07:56, 9 August 2014 (UTC)
PKM (talk) 19:58, 10 October 2014 (UTC)
Revi 16:54, 29 November 2014 (UTC)
Giftzwerg 88 (talk) 23:36, 1 January 2015 (UTC)
Almondega (talk) 00:17, 5 August 2015 (UTC)
Jura to help sort out issues with other projects
Skim (talk) 13:52, 24 June 2016 (UTC)
Marchitelli (talk) 12:29, 5 August 2016 (UTC)
BrillLyle (talk) 15:33, 26 August 2016 (UTC)
Alexmar983 (talk) 23:53, 28 August 2016 (UTC)
Finn Årup Nielsen (fnielsen) (talk) 10:44, 29 August 2016 (UTC)
Chiara (talk) 14:15, 29 August 2016 (UTC)
Thibaut120094 (talk) 20:31, 14 September 2016 (UTC)
Ivanhercaz | Discusión Plume pen w.png 15:30, 31 October 2016 (UTC)
YULdigitalpreservation (talk) 17:35, 10 November 2016 (UTC)
PatHadley (talk) 21:51, 15 December 2016 (UTC)
Erica (ohmyerica) (talk) 19:26, 1 January 2017 (UTC)
Mauricio V. Genta (talk) 05:38, 12 March 2017 (UTC)
Sam Wilson 09:24, 24 May 2017 (UTC)
Sic19 (talk) 22:25, 12 July 2017 (UTC)
MartinPoulter (talk) 09:21, 20 July 2017 (UTC)
ThelmadatterThelmadatter (talk) 01:11, 13 September 2017 (UTC)
Zeroth (talk) 15:01, 16 September 2017 (UTC)
Beat Estermann (talk) 20:07, 12 November 2017 (UTC)
Shilonite - specialize in cataloging Jewish & Hebrew books
Elena moz
Oa01 (talk) 10:52, 3 February 2018 (UTC)
Maria zaos (talk) 11:39, 25 March 2018 (UTC)
Wikidelo (talk) 13:07, 15 April 2018 (UTC)
Mfchris84 (talk) 10:08, 27 April 2018 (UTC)
Mlemusrojas (talk) 3:36, 30 April 2018 (UTC)
salgo60 Salgo60 (talk) 12:42, 8 May 2018 (UTC)
Dick Bos (talk) 14:35, 16 May 2018 (UTC)
Marco Chemello (BEIC) (talk) 07:26, 30 May 2018 (UTC)
 徵國單  (討論 🀄) (方孔錢 💴) 14:35, 20 July 2018 (UTC)
Alicia Fagerving (WMSE)
Louize5 (talk) 20:05, 11 September 2018 (UTC)
Viztor (talk) 05:48, 6 November 2018 (UTC)
Pictogram voting comment.svg Notified participants of WikiProject Books

softcover (Q990683) started as "paperback binding" (the bookbinding used by paperback books) but now it is a mix between "paperback binding" and paperback (Q193934).

I could merge it with paperback (Q193934) and create a new item about "paperback binding" or move all the statements about "paperback" in paperback (Q193934), but the problem is that:

Can I safely substitute all the instances of distribution (P437)  softcover (Q990683) with distribution (P437)  paperback (Q193934)?--Malore (talk) 02:14, 27 October 2018 (UTC)

As for ru-sitelink, paperback (Q193934) is about part of book, book cover (not about distribution method) so distribution (P437)  paperback (Q193934) looks very strange. --Infovarius (talk) 13:53, 30 October 2018 (UTC)
At least the German labels/descriptions refer to two distinct types of books/book formats/bindings. Although I would have expected de:Taschenbuch to be connected to paperback (Q193934) istead of pocket edition (Q17994250). This seems to be one of these problems where different languages/cultures have slightly different concepts that aren't necessarily 100% congruent. And then people try to add labels in other languages resulting in overlaps and mixups of concepts. Trying to fix something like this can be hard because you don't know which language/labels the users saw/used when they used these items in statements - which means you don't know for certain what exactly they were refering to. --Kam Solusar (talk) 05:32, 1 November 2018 (UTC)
@Infovarius: I checked the russian wikilink and it talked about "book cover", not paperback. I fixed the mistake.
@Kam Solusar: In fact, the most correct German translation is "Taschenbuch". Thank you for pointing it out. It was my fault. I read the automatic translation of the German article and it says that the word "Paperback" is used in German with a slightly different meaning that the English one. Maybe it has the same meaning of trade paperback, but it's only a conjecture--Malore (talk) 03:52, 8 November 2018 (UTC)

Some fundamental questions about modeling properties for statistical data[edit]


Dear all, before I make more requests for permissions to import more statistical data using User:WDBot, I think that there are issues about data modeling that need to be discussed. I would give you some example to make it clearer.

Nominal GDP Property: P2131:

  • The value is usually listed in US Dollar but also in the local currency.
  • Even for the same currency there are different sources with different values - for example for values in USD there are different estimates from the IMF and the World Bank for the same point in time.

There are actually two ways to model this:

  • Use separate properties for different data, that are structurally different - this means here that we would have two separate properties from GDP in USD and Local Currency. If we want two additional sources we should have different properties for each issuer.
  • Use only one property for different data.

The first option is easier to browse and is consistent to the ranking concept - the more actual value will be shown in queries. Browsing the data using the interface is also easier because the user moves in the same structure and methodology of data among one property. The second option is more pragmatic regarding the fact that we use only one property. Otherwise it makes the use of the data and the query more difficult because the user does not know which data is he seeing, especially in queries and I suppose in wikipedia. If the user queries the data on 3 dates and on each of these dates different values are the most actual - and thus preferred (USD from the World Bank, USD from IMF and EUR from Eurostat etc.) - then the user gets every time systematically different values.

I think this is some fundamental data modelling issue, where we need a good discussion and consensus before we begin to import large amount of statistical data.

In which way should we model this sort of statistical data? Maybe we could start a discussion in two directions - short term (using the actual structure of wikidata) and long term consensus (proposing some further changes probably in the modelling, use and visualization of properties). Cheers! Datawiki30 (talk) 09:48, 27 October 2018 (UTC)

@Datawiki30: Nothing prevent you to build queries with several conditions: data about nominal GDP WITH currency in dollar WITH sourced from World bank for example. If all the required data (unit, source,...) are provided, you only need to build the corresponding data you want. But this means you have to know what ou want before writing the query. There is no modelling issue, just query definition issue. Snipre (talk) 05:28, 29 October 2018 (UTC)
@Snipre: Thank you for your comment. Indeed this is possible, but the query builder does not support this. Users that do not have advanced skills in SPARQL will have some difficulties to do this. What do you think the other questions:
1. Is the ranking concept applicable to properties with two or more values for the same point in time (for example nominal GDP for 2017 from IMF, World Bank, CIA Fact Book, Eurostat...)?
2. If I want to use the most actual value for the nominal GDP with reference "stated in" = "World Bank database" on the wikipedia page of the country (infobox), how do I do this?
3. When we add more data with different sources, then we have wild mixed values in the same properties on the wikidata GUI. What do you think about this usability issue? Datawiki30 (talk) 13:34, 29 October 2018 (UTC)
This never really was a problem. We always went with one property for a specific use case, say "nominal GDP", which is nominal GDP (P2131) in this case. I can’t remember that we ever started to create properties such as "CIA Fact Book nominal GDP". Thus, all claims regardless of their value, source, rank, qualifiers, etc. use this single property. If you want to restrict data retrieval to a particular subset of the claims, you need to add additional criterial to the data retrieval process. Either by elaborating a more specific SPARQL query that for instance only considers one particular source, or by some kind of post-filtering (e.g. in Wikipedia: loop over all P2131 statements and ignore all which do not fulfill the desired criteria). Both approaches are not overly complicated to implement.
Ranks are more a tool to manage multiple value situations (as in this case), but due to the very limited number of ranks and the many scenarios how to use them, there is not always a clear consensus how exactly to do it, and thus the outcome might be varying for different items. I strongly recommend not to model anything crucial around the usage of ranks.
The Wikidata UI is basically a tool for editors, not really an interface to retrieve data, or to "read some data". What you see there is indeed a bit unpolished, disordered, and so on, but this does not really matter. Mind that there is no intrinsic order of statements in an item, or multiple values of a statement in an item defined in the data model. Consider that they just appear in a random order (although they technically aren’t fully randomly displayed). If you want ordered data, this is something you need to do as a data user once again, after data retrieval. You can for instance order your nominal GDP data by date, by source, by nominal GDP, alphabetically by state name, or by whatever.
MisterSynergy (talk) 15:00, 29 October 2018 (UTC)
  • Multi-valued fields are tricky to use in Wikidata. I don't think it has been done yet, but I think it could worth considering having separate properties for local currency values. The problem with many of these economics properties is that people kept creating them despite the proposer not using them and quantity datatype not being entirely functional. It could also be that some additional properties should be created and some existing ones deleted. --- Jura 17:11, 29 October 2018 (UTC)
@Datawiki30: The ranking is not an appropriate tool to distinguish between different sources. The main role of the rank is to define is the value is valid or not.
For the retrieval of WD data in WP using specific sources, the French WP developed the lua functions (see here in French). But when I looked at the corresponding English module, I don't find a similar function (see [1] here). A function getValueBySource is missing in the toolbox of the lua functions. Better ask the English community about this possibility. Snipre (talk) 10:14, 30 October 2018 (UTC)
Thanks to all the users for the comments. Before I make a summary I would just like to let make a test, if we can easily retrieve the proper GDP value in Wikipedia. @Snipre: At the Sandbox Q4115189 you can find examples for nominal GDP: 1) values in USD from the World Bank, 2) values in USD from the IMF and 3) Values in the local currency (here Euro) from the World Bank (@Jura1: I know that you would prefer new property for nominal GDP in local currency, but just for the case that we don't get the property support). The data are from France. I've set the preferred rank for the most actual value of each source. This should be done by a bot and should ensure, that only the actual value is retrieved in Wikpedia - automatically even when we have new data for a new point in time. In this example we (still) don't have data from the IMF for 2017. @Snipre: Can you please try to retrieve the preferred values from the each of the sources in Wikipedia separately (or can you ask someone to do this for us)?
- 2,582,501,307,216.42 United States dollar for 2017 (World Bank)
- 2,466,152,225.25 United States dollar for 2016 (IMF)
- 2,291,705,857.98 euro for 2017 (World Bank) Datawiki30 (talk) 00:03, 31 October 2018 (UTC)
@Laboramus: operates a bot that sets preferred ranks. Maybe it can be fine tuned for this. --- Jura 12:05, 31 October 2018 (UTC)
@Jura1: Thank you for the tip. The PrerefentialBot already operates the ranks for the nominal GDP. @Laboramus: If we have different sources, the most actual values from these sources have different actual point in time values (see example above) and the most actual value of each source should be preferred, then we need a slight change in the bot script for the property nominal GDP. Right?
We are now trying to retrieve each value separately according to the different source in Wikipedia (see here). @RexxS: Thank you for the support. If you need some additional information just write us. Datawiki30 (talk) 14:56, 31 October 2018 (UTC)
There are some results on display in the en-wiki thread linked above. --RexxS (talk) 18:12, 31 October 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Using an extended function we can now retrieve the preferred values from nominal GDP (P2131) using a filter on the source "stated in" and the unity (for example USD, Euro etc.). @RexxS: Thank you for your engagement. This allows the user to retrieve each of the values separately - for example in the infobox of the country etc. Take a look here. I think this should be sufficient to retrieve the data. There are also other properties that could use this function.

  1. Any concerns about accessing the data (with different sources and units) this way in Wikipedia?
  2. The values are in trillions and this too long for the infobox. I think that we need some function to truncate the values in Wikipedia. For example using a 10⁹ power and taking the value 2,582,501,307,216.42 USD would get truncated value 2,582 billion USD. What do you think about this?
  3. Can we use a SPARQL query to replicate the table here with source World Bank in Wikipedia?

Cheers! --Datawiki30 (talk) 13:34, 3 November 2018 (UTC)

@Datawiki30: When you indicate 2,582 billion USD, did you intend that the value displayed be rounded to an integer? If so, then I have a solution in the sandbox. See en:Module talk:WikidataIB/sandbox/testing #Scaling quantities. --RexxS (talk) 15:38, 3 November 2018 (UTC)
Thank you @Datawiki30: - that's fantastic! That looks for me very good - I have now upadted the sandbox table on wikipedia. I esitated to use the automatic scaling, because it would round trillion-values "too much". Maybe the automatic approach could be something like trying to get at least 4 digist:
  • 19,390,604,000,000 -> 19,391 (actual value for the United Stated) instead of 19
  • 3,677,439,129,776.6 -> 3,667 (actual value for Germany) instead of 4
@Jura1:, @Snipre:, @MisterSynergy: and all the other users interested in this topic: Do you think that we need some improvement of the automatic approach to get at least for example 4 digits in Wikipedia? What about the other two points mentioned above? Cheers! --Datawiki30 (talk) 22:45, 3 November 2018 (UTC)
Only providing a SPARQL query here: link. It lists 2017 data for nominal GDP (P2131) with a reference stated in (P248): World Bank database (Q21540096) and sorts descending by GDP. Can be tweaked further if necessary, but generally it is not that complicated to collect such results sets with SPARQL. —MisterSynergy (talk) 22:59, 3 November 2018 (UTC)
@Datawiki30:. The automatic facility now retains a minimum of 4 digits. I may need to tweak that, but try it out first. Sadly we can't run SPARQL queries in Wikipedia pages. --RexxS (talk) 23:52, 3 November 2018 (UTC)

@RexxS: - thank you for the implementation. You're faster than the light :). I think this is now perfect. @Jura1:, @Snipre:, @MisterSynergy:: After the discussion here I would like to start votings about some of the topics to try to get consensus. --Datawiki30 (talk) 18:30, 4 November 2018 (UTC)

Voting for consensus[edit]

Property with different sources for the same Topic[edit]

There is consensus, that different values from different sources on the same topic should be edited in the same property. For example if there are different estimations for the nominal GDP in US-Dollar from the World Bank and the IMF with different estimates for the same point in time, then the values should be edited in the same Property P2131. Arguments:

  • All the values with the same informative value are consistently in the same property.
  • There is a Lua function to retrieve values depending on the source in Wikipedia (for example statement with preferred rank fromthe source World Bank database).
  • SPARQL-queries can handle multiple values from different sources.

Symbol support vote.svg Support-- Datawiki30 (talk) 18:30, 4 November 2018 (UTC)

Pictogram voting comment.svg Comment "edited in the same property" isn't really the way Wikidata works. What I think you mean is that if there are different estimates from different sources for a quantity, it is appropriate to add statements for each one. I doubt anyone would contest that -- it was envisaged in the design for Wikidata from the start. Jheald (talk) 18:01, 5 November 2018 (UTC)

Better structure of the statements in the Wikidata UI especially for statistical properties with multiple values[edit]

There is consensus, that the random visualisation of statements for statistical properties with multiple values in the Wikidata UI is not adequate and that there is need for further development. For example (according to the implementation in

  • deprecated statementes should be vizualized separately from nomal and preferred statements
  • statements with preffered rank should be vizualized more highlighted
  • statements with point in time qualifier should be sorted on this qualifier

Arguments for this consensus:

  • statistical properties could have many statements (for example more than 50 edit for different years) with different sources. With the actual (not sorted) vizualisation it is difficult for the Wikipedia user to find and comprehend a value, that is retrieved from Wikidata.

Symbol support vote.svg Support-- Datawiki30 (talk) 18:30, 4 November 2018 (UTC)

Symbol support vote.svg Support Sorted statements would be a dream come true. I consent! Moebeus (talk) 01:15, 5 November 2018 (UTC)

Pictogram voting comment.svg Comment In my view Wikidata is not well-suited to time-series data. If one has a time-series, IMO better to upload it to Commons in the data: namespace, and link it with some appropriate property from here. Jheald (talk) 18:03, 5 November 2018 (UTC)

@Jheald: Thank you for your comment. What is the argument, that Wikidata is not well-suited for time-series? Performace?
Can you give me some example for your alternative? For me Commons means media files like pictures, audio and video files... Cheers! --Datawiki30 (talk) 20:30, 5 November 2018 (UTC)
@Datawiki30: See c:Help:Tabular_Data. The Wikidata user interface doesn't scale very well with lots and lots of statements -- multiple individual atomic statements are not the best way to store tabular data such time-series with lots of data-points. Better to store it as a whole dataset. Jheald (talk) 21:06, 5 November 2018 (UTC)
  • Pictogram voting comment.svg Comment Please bear in mind that non-current value wouldn't have deprecated rank, but normal rank. --- Jura 21:59, 5 November 2018 (UTC)
  • I actually agree that deprecated statements should be much easier to identify in the Wikidata item pages. I wonder if there is an HTML class on those claims. --Izno (talk) 20:30, 6 November 2018 (UTC)
    • Yes, there is. I use .wb-deprecated { background-color: mistyrose } and .wb-preferred { background-color: lavender } in my common.css to make the different ranks easier to see. There's also a ticket at phab:T198907. - Nikki (talk) 09:35, 9 November 2018 (UTC)

Cross-referencing similar / closely-related things?[edit]

The two entities Yoni mudra (Q2655354) and Vulva hand-sign (Q30899302) probably shouldn't be merged (they have separate articles on Italian Wikipedia for one thing, and they occur in different contexts: yoga practice vs. lesbianism / feminist spirituality), but is there any way of indicating that the two are very similar (probably physically identical in at least some cases, though done with different intentions and interpretations...)? Thanks. AnonMoos (talk) 20:40, 28 October 2018 (UTC)

I found "partially coincident with (P1382)", but I don't know if that would be the most appropriate one to use... AnonMoos (talk) 08:29, 29 October 2018 (UTC)

I went with "partially coincident with", which should imply difference (not sure whether it formally does...) AnonMoos (talk) 01:58, 7 November 2018 (UTC)

Place of residence (P551) of accused witches[edit]

Hi, prepping place of residence data (P551) for an import of accused witches into Wikidata. We have 4 columns of information (settlement, parish, presbytery, county) and the accused witches in the Survey of Scottish witchcraft database have an entry under at least one of these with the settlement being the most specific and county the least specific. To replicate as close as possible the original database information, could we use a qualifier to specify that the place of residence we have is listed as either (1) the settlement (2) the parish, (3) the presbytery or (4) the county the accused witch stayed in? If so, which qualifier would be the best fit? If not,what would be the best way of working this? Stinglehammer (talk) 14:58, 30 October 2018 (UTC)

The places of residence towards which you link should have instance of (P31) that's filled with human settlement (Q486972), parish (Q102496) or county (Q28575). When it comes to presbytery there's clergy house (Q607241) but using that means the implied claim that the person actually lived in that clergy house (Q607241) and not just that the clergy house (Q607241) was the clergy house (Q607241) for the area in which the person lived.
Do you see problems with representing your information in this way? ChristianKl❫ 10:21, 31 October 2018 (UTC)
@ChristianKl: FWIW, "presbytery" here is a group of parishes, not a physical building - eg Presbytery of Glasgow (Q7240820). I don't think we have a Wikidata item for the concept itself at the moment (it's not a very significant thing these days), but it would fit in the religious administrative territorial entity (Q20926517) hierarchy. I'll try and knock something together for this.
@Stinglehammer: On the original question, I'm not sure quite what you're trying to do. If you want to say "we've listed Argyll because we don't know anything more specific than Argyll", then you could use something like sourcing circumstances (P1480) to clarify that, but it's usually implicit that "this value is the most precise information available" so it's not really necessary. If you want to say "this indicates Argyll as a presbytery not Argyll as a county", then it's best to explicitly link to the presbytery not the county, creating an item for the presbytery if need be - otherwise it'll get confusing. Andrew Gray (talk) 13:20, 31 October 2018 (UTC)
@Andrew Gray, ChristianKl: Thanks both. It's actually five columns (settlement, parish, presbytery, county, burgh) - one was in another spreadsheet. The columns are not all full (some might only have the county listed) but we should have some indication of place of residence for most if not all of the 3,219 accused witches even if sometimes we have to use the county level instead of something more specific like settlement or parish. Hence, I was proposing using the most specific place of residence information as possible for P551 from the 5 columns so that we do have at least some indication of residence for each accused witch but also not losing the fact we have the information divided up in this way. Thought a qualifier stating whether the residence was listed as a settlement, parish, presbytery, county, burgh etc. might be one way of doing this. But do concede linking to correct Q number as an instance of a presbytery, parish etc. may be preferable. Concern would be understanding co-ordinate locations, boundaries etc. for creating new items for these historic locations so it may be something I have to work with National Library of Scotland on in terms of mappings these locations. Stinglehammer (talk) 23:08, 5 November 2018 (UTC)
@Stinglehammer: It wouldn't be necessary to have coordinates to have new items. If you can simply fill located in the ecclesiastical territorial entity (P5607) or located in the administrative territorial entity (P131) that would be enough information to allow you to add your links and if in the future another person is interested in those places they could add coordinates. ChristianKl❫ 19:07, 8 November 2018 (UTC)


As I am leaving Wikimedia Germany I would like to say goodbye with this account. I really want to thank you all for your support and the great time and experience I had during my time working on the project. I am very thankful that I had the possibility to improve the software behind Wikidata and get in touch with the great community and all the wonderful people behind the project! I hope that I could help you with what I did and that I could help to bring the project forward.

I am very proud that I could help with improving the existing UI and showing the beauty of Wikidata with my work on I am also very happy that I could help with making constraint violations visible on the item page, allowing to query them and creating constraint suggestions.

I hope that in the future I will still have the possibility to work with you and improve the software, but for now I would like to say thank you and goodbye.

Please disable this account. If you like to connect or stay in touch here are some possibilities:

Jonas Kress (WMDE) (talk) 13:08, 31 October 2018 (UTC)

All the best to you, Jonas. Thanks for your contributions to the project! --Micru (talk) 13:20, 31 October 2018 (UTC)
Thank you Jonas, and all the best from the Wikidata team! The work you have done has helped shaping the project as it is now, and you can be sure that it will be reused and improved in the future. Lea Lacroix (WMDE) (talk) 13:35, 31 October 2018 (UTC)
I thank you as well for the great job you have done. Tschüss. Pamputt (talk) 13:56, 4 November 2018 (UTC)
Thank you for all the great work you've done. Hoping to see more of your work in the future. --Yair rand (talk) 05:10, 8 November 2018 (UTC)

Instance of ?[edit]

Please help me to find the best instance of (P31) for these two items (you can read about them here in English):

Thanks! Bencemac (talk) 13:00, 4 November 2018 (UTC)

That's an odd use of eosin. The use of eosin in English I'm familiar with is for a histological stain (en:wikt:eosin, from a very definite group of similar chemical dyes. --EncycloPetey (talk) 13:55, 4 November 2018 (UTC)
Sorry, but after reading article I still don't know what is eosin and pyrogranite. Type of ceramics? Some sort of ceramic glaze? Material used for producing this type of ceramics or maybe material used for preparation the ceramic glaze? Unfortunately, I don't speak Hungarian, so I can't say what the article is about. Wostr (talk) 23:37, 5 November 2018 (UTC)

@EncycloPetey, Wostr: Thanks for trying to help me! It is hard for me to describe them in English, that is why I asked help. Please read this and this official websites; do they help? Bencemac (talk) 08:59, 6 November 2018 (UTC)

@Bencemac:, I think the first (eosin) may be a 'subclass of' glaze (Q335404) and the second a 'subclass of' ceramic (Q45621). Wostr (talk) 14:24, 6 November 2018 (UTC)
Thank you very much, I added them. Bencemac (talk) 18:16, 6 November 2018 (UTC)


Hi, how can i merge no label (Q56696625) with Habik'a War Memorial (Q1703712)? Talmoryair (talk) 19:42, 4 November 2018 (UTC)

@Talmoryair: See Help:Merge. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:20, 5 November 2018 (UTC)
✓ Done --Liuxinyu970226 (talk) 15:14, 7 November 2018 (UTC)

"song" or "single"?[edit]

Hi, some times ago I started to notice (especially for well known ones) some odd things about items being "instance of" "song" and "single" (Ex: Love of the Common People (Q3837833) or The House of the Rising Sun (Q478928)): These are a mix-up of song and single:

Q478928 please see its Talk-page
Q3837833 has much the same disorder, under "performer" are listed 5 persons and/or bands, but you have to guess who has performed on the single ("part of = No Parlez"), who covered the song an who first sung the song. The "publication date" has 2 entries one for the song and one for the single, ok this is easy to guess, but a database query would not work with that.

So, has this been discussed here earlier? And if not, somebody else thinks that's real issue? DanSy (talk) 19:53, 4 November 2018 (UTC)

@DanSy I feel you. User:Jc86035 will probably sympathize as well ;-) We're working though it, one song and single at a time... Moebeus (talk) 01:31, 5 November 2018 (UTC)

@DanSy: I guess this is just an unplanned effect of most Wikipedia infoboxes not having that distinction, and import scripts assuming that there is a one-to-one relationship between articles and items. Of the online music databases which we have identifiers for, MusicBrainz and Discogs have the most comprehensive identifiers for sorting out this information.
(Incidentally, AllMusic is also fairly comprehensive but doesn't seem to have well-organized data; for example, if a song is on 20 different albums then the composition will have 20 different identifiers, even if some of the recordings are duplicates. Classical compositions are also separated from songs, with classical/"art music" recordings sometimes given performance IDs and sometimes given song IDs.) Jc86035 (talk) 10:19, 5 November 2018 (UTC)
@Moebeus: Have you done QuickStatements runs before? I think if imports were done semi-automatically, one artist at a time (i.e. mass-creating new items for compositions, singles and album tracks, linking them, and then cleaning up the original items and moving the sitelinks), then progress would be made much faster. Adele might be a good place to start, since she only has three albums and some scattered EPs (e.g. iTunes Festival), and most online data about her music is probably going to be complete.
If you know how to use regular expression searches (e.g. with BBEdit, Notepad++, grep/sed or similar) then importing might be even easier, since it would then be easier to vacuum data from the various HTML pages into a nice tidy spreadsheet. Jc86035 (talk) 10:19, 5 November 2018 (UTC)
Well, and how should I handle it? Lets say I walk across Love of the Common People (Q3837833) how do I correct it? Separating single from song and put a "part of" and "has part"? DanSy (talk) 14:45, 5 November 2018 (UTC)
@DanSy: You would probably have to create one item for each distinct track, one item for each distinct single (possibly including multiple different singles including the same song) and one item for each music video, and separate them out from the composition, as Moebeus seems to have done. I find it's quite time-consuming so I would probably avoid fixing it for now unless you're importing an artist's entire discography. Jc86035 (talk) 17:23, 5 November 2018 (UTC)
@Jc86035:. I have seen Without Me (Q57393247),BTW: "vocal track"? *confused* I know things like "MIDI Track", "Multitrack recording" or "album track" so in this sens is the "vocal track" the separate track with the voices... at least for my understanding. What about vocal music (Q685884) or musical work (Q2188189) instead?. You have made the song part of a single, ok, I understood why, but now how do I link the singles (or whatever) from different performers to that song-item, with "part of" in the single-item too? DanSy (talk) 21:13, 5 November 2018 (UTC)
@DanSy I had a go at Love of the Common People (Q3837833) , take a look and see if that helps. Feel free to hit me up at my talk page with any questions Moebeus (talk) 22:57, 5 November 2018 (UTC)
@DanSy: I think changing the label to "track with vocals" might work.
As Moebeus has done it, the track is linked from the single with tracklist (P658), and from the composition with a statement is subject of (P805) qualifier to performer (P175); the track's item links to the single with part of (P361)/published in (P1433) and to the composition with recording or performance of (P2550). Jc86035 (talk) 04:10, 6 November 2018 (UTC)
Thanks a lot, really appreciate your help! I would just propose to use (additional to "instance of" > "cover version"/"original") > "of" > "Love of the Common People" instead of "recording or performance of". At least for me, this would be more intuitive. DanSy (talk) 15:39, 6 November 2018 (UTC) ==> I see what you mean but the problem with that approach is that "cover version" is kind of a soft term, meaning that it's not always clear which version is the cover and which is the "original". And that's if an original recording even exists, for many traditional/folk songs that won't be the case, and the best we can strive for is to locate the first known recording. Moebeus (talk) 16:27, 6 November 2018 (UTC)

Can we merge Q7216841 and Q30747696 on Russian Wiktionary[edit]

I don't know where differences between two links of ruwiktionary, but both are having same translation in Bosnian, Danish, Finnish, Hebrew, Croatian, Hungarian, Japanese, Korean, Georgian, Lithuanian, Macedonian, Norwegian Nynorsk, Romania, Simple English, Serbian, Swedish, Ukrainian, and Urdu. How are same in these 18 languages not able to change the different from (P1889)? -- 22:33, 4 November 2018 (UTC)

If you think two items at Russian Wiktionary are the same, then you need to have that discussion at Russian Wiktionary. Wikidata does not control what is separate or merged at the other Wikis. --EncycloPetey (talk) 02:48, 5 November 2018 (UTC)
Note: This pair of "duplications" were reported to WD:IC, and I'm still waiting explanations from @Infovarius:. --Liuxinyu970226 (talk) 04:28, 5 November 2018 (UTC)
I was downgrade to said to be the same as (P460) but recently undid by @Infovarius:, still I'm waiting for response from him. --Liuxinyu970226 (talk) 00:29, 11 November 2018 (UTC)

System change at[edit]

Hi, I posted this on the property-talk-page but didn't get any comments (No I'm not in a hurry, but 10 days, I suppose no one is actively watching it).

I think they have changed there page naming system:
Some weeks ago a result returned something like But now it shows up with And I can't find the id#. Is this a Problem others do have too? BTW: lookup with "...?id=45292" still seems to work~. DanSy (talk) 15:01, 5 November 2018 (UTC)
@DanSy Yes. They changed from a numerical id to a text-string a few weeks back, as did Songwriters Hall Of Fame. Maybe someone could send a mail to their developers and see if we could sort it out? Moebeus (talk) 23:00, 5 November 2018 (UTC)
@Moebeus what do you mean with "if we could sort it out"? DanSy (talk) 16:10, 6 November 2018 (UTC)
@DanSy If they're made aware that a lot of links are left broken then maybe they would be interested in helping with fixing it, e.g. setting up a relay page or maybe even updating the links themselves. It means traffic and search rankings to them so they might very well be interested in helping out. Moebeus (talk) 16:18, 6 November 2018 (UTC)
@Moebeus I think thats not an issue, the lookup with ID still works. The problem is to insert new ones into the items, because calls will automatically add "" and I can't figure out the ID nor do I know how to fix the template. DanSy (talk) 16:35, 6 November 2018 (UTC)

Dividing objects into items with example Aichach (Q55133909), Aichach station (Q57174619)[edit]

There is a train station called "Bahnhof Aichach" Aichach station (Q57174619) which all its train station related properties. In Bavaria there is a term called "Gemeindeteil" - this term stands for any named place in a municipality like towns, villages, hamlets, hermitages and sometimes castles, sanatoriums, mills, forester's houses, train stations and so on. These "Gemeindeteil" are named by the municipality and sometimes it revokes some of the names too.

Aichach (Q55133909) is a train station too per source, proved as train station (Bhf.) for example in the "Amtlichen Ortsverzeichnis von Bayern" (official gazetteer from Bavaria) 1964 page 9 [2] under the municipality "Algertshausen". From the same gazetteer, page 6* [3] I cite "Die Bahnhöfe sind mit ihren bahnamtlichen Bezeichnungen und der Höhenlage über Normalnull in den Gemeindeteilen angegeben, in denen sie liegen. In manchen Gemeinden bilden sie eigene Gemeindeteile." (The train stations are specified with their train-official name and absolute altitude in the Gemeindeteilen, in which they are. In some municipalities they form own Gemeindeteile). So the train station themself is a Gemeindeteil.

User:MB-one divides this train station in two items. His reason is, that train station and the other item subject two different concepts. Is this the idea of wikidata, to create concepts and divide one physical existant object in more items? I cant't follow this. He distributes the properties to the two items and ignores the sources. Why is inhabitants a property of his created "Gemeindeteil" but not of his train station? Like the source of 1964 shows, there live 11 inhabitants in the train station (perhaps the station master with his family and so on). Why is located in the administrative territorial entity (P131) with Algertshausen municipality value only in the "Gemeindeteil", the train station is there until first of January 1974, too. Why he deletes the alias name "Bahnhof Aichach" from the "Gemeindeteil" I don't know - you can see at [4] that the "Gemeindeteil"/train station is named so at 1980.

I'm importing for a long time many information from the Bavarian official gazeteers from 1877 to 1987 and there are many such objects (train stations, castles, mills, even powerhouses, and so on). I don't think, it's a good idea to divide all of them into more items without any need.

Is it really reasonable to create concepts and then divide real objects in more items? Where are the limits? And how you can distribute the properties? Or don't do so and make large quantities of redundancy? What are the concepts of my example: one is "train station"? The other? If you think of a train station as part of a timetable, then I would say, it's another concept. But train station also have properties of a geographical object located in the administrative territorial entity (P131) or coordinate location (P625). Is it then a geographical object too. But what's with the other object Aichach (Q55133909)? What is it then? Only a geographical object? What else? --Balû (talk) 03:22, 6 November 2018 (UTC)

@Balû: I can't comment on MB-one's edits aside from the edits to the Aichach items, but I would think in most places (particularly urban areas) it is standard for every railway station to get its own item and its own Wikipedia articles (and both Aichach and its station have English Wikipedia articles). Usually Wikidata items are only about one distinct concept; perhaps it would even be appropriate to separate the building from the station (e.g. Pennsylvania Station (Q14707174) is the demolished station building of Pennsylvania Station (Q54451)) if it is desirable to indicate that people lived in it, although I'm not sure if this would be necessary. Jc86035 (talk) 17:27, 6 November 2018 (UTC)
@Jc86035: you didn't read it correctly: both items Aichach (Q55133909), Aichach station (Q57174619) are for the railway station - the town Aichach has its own item Aichach (Q251678). I agree with you to separate even the building from the railway station. But what should be the concept behind Aichach (Q55133909)? It's the railway station Aichach station (Q57174619) but mentioned in a source in another way. --Balû (talk) 03:43, 7 November 2018 (UTC)
de:Aichach#Ortsteile seems to list Q55133909 as part of Q251678.--- Jura 03:53, 7 November 2018 (UTC)
@Jura1:: no, it lists the chef-lieu (Q956214) Aichach (Q31872780) - it's the former town Aichach and now one of the Ortsteile of the municipality Aichach Aichach (Q251678). The older "Gemeindeteilname" (name of municipality part) "Aichach Bahnhof = Aichach (Q55133909)" was revoked at 1980 but is furtheron the railway station. But there is also the railway station Aichach station (Q57174619), which shall be another item because of concepts I can't see. --Balû (talk) 18:17, 7 November 2018 (UTC)
You can read it in the "Amtlichen Ortsverzeichnissen". All railway stations are listed there, too. Namely at the town the station is located. Look at page 9. There is the the town "Aichach" and in the text stands "railway station Aichach see municipality Algertshausen". There then stands "Aichach, railway station, 11 inhabitants". It is the railway station of Aichach. --Balû (talk) 18:31, 7 November 2018 (UTC)
Complicated. Sounds like @MB-one: might have missed the cebwiki bot item. Not sure if we should also have two "A. station", one for the station and another one for the locality (pre-1980). --- Jura 21:02, 7 November 2018 (UTC)
@Jura1: Aichach (Q31872780) (connected to cebwiki) seems to be different from Aichach (Q55133909) (the item in question here; which probably needs a better label). --MB-one (talk) 09:07, 8 November 2018 (UTC)
@Jura1: a station isn't a locality? What then? What about castles, mills, forester houses, and so on. Aren't they localities, too. And what about farms, solitudes, hamlets? All of them are sometimes in the gazeteer "Gemeindeteile". --Balû (talk) 05:49, 10 November 2018 (UTC)

Species kept for protected areas[edit]

There had been a discussion to widen the scope of species kept (P1990) to include protected areas. Often, a protected area has a list of species which are specifically protected there, or which are the reason to establish the protected area. There is however the big difference that in the original scope of the property, only species actively kept by humans are meant, which not fits how it is done in protected areas. As there was no consensus there yet - shall I a be bold and propose a new property "species protected", or would it be better to extend the original scope? Ahoerstemeier (talk) 09:49, 6 November 2018 (UTC)

Thanks, wasn't aware of that. Ahoerstemeier (talk) 20:52, 6 November 2018 (UTC)

Inclusion of redirects[edit]

Note that I closed an old RFC, Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata. The close is lengthy and is posted there, I am not going to repeat it. In short, there is consensus that redirects should be allowed, but we are not yet close to actually starting adding them, and other discussions should happen.--Ymblanter (talk) 16:49, 6 November 2018 (UTC)

Thanks. As I understand, there is need for further discussion to have an actual improvement at some time. Ideally we involve @Lydia Pintscher (WMDE) & team from the beginning this time, in order not to discuss a proposal that lacks consideration of several important aspects of the problem (i.e. unlike the RfC itself). Any idea where we should start a discussion? —MisterSynergy (talk) 16:57, 6 November 2018 (UTC)
I would think we need to identify crucial issues for discussion here (possibly even in this thread) and then see may be some of them are obviousl and for others we might need another RfC (which I hope will not stay open for another two years).--Ymblanter (talk) 17:02, 6 November 2018 (UTC)
If we look at the past RfC on a more abstract level (i.e. without considering any specific solution such as “give us redirects”), I think we can conclude that the community requests a more sophisticated sitelink management to improve interwikilinking. The current situation is a consequence of a conflict of goals: Wikidata as a knowledge base vs. Wikidata as a sitelink hub for Wikimedia projects, with the latter goal being somewhat constrained by the former goal. In most situations this works out, but sometimes not and this needs to be improved (Bonnie and Clyde problem). The original proposal of the RfC is pretty dangerous for the knowledge base goal, which is why substantial opposition was raised as well, but I think we have already seen several good ideas in the proposal. What does Lydia think meanwhile? —MisterSynergy (talk) 17:15, 6 November 2018 (UTC)
She posted an extensive comment on that RfC, and i would be surprised if she thinks differently. In any case, to implement the RfC we ultimately need to change the interface, which she must directly approve.--Ymblanter (talk) 17:17, 6 November 2018 (UTC)
Hey :) Yeah it still represents my thinking pretty well I'd say. And I still believe we should explore the option of generating some of the sitelinks from statements further. Don't get me wrong. I understand the current situation sucks for some cases. I am just not convinced that the other option sucks any less. So we need to get creative somehow. --Lydia Pintscher (WMDE) (talk) 12:38, 9 November 2018 (UTC)
@Ymblanter: Thanks for finally closing this! Here are my responses to your queries regarding further issues, I wonder if perhaps we need another RFC to settle these though? Anyway - (1) "only those redirects which help to solve existing problems are welcome" - I think this is simply a matter for the notability policy. A redirect item should only be created if it describes a concept or entity that is clearly distinct from the item the redirect points to, and otherwise notable. In particular, redirects that are simply alternate names or aliases of the primary entity should never have their own items (instead they could be added as alternate labels on the item). (2) "constraint violations are not created" I don't think we are at all talking about automatic creation of redirect items; only editors should be creating redirect items, and they should satisfy constraints just as they do now. In particular when a page is moved on a client wiki, that should NOT automatically create a redirect item. (3) "must be clearly visible and discriminated" - sure we should discuss how to do this, but I agree it's useful. User interface design can be proposed and hashed out as part of implementation, I don't think it needs to be specified in detail up front. (4) "other items" - well, we already had a very long discussion about it, do you really think there's more that could be an issue? ArthurPSmith (talk) 19:01, 6 November 2018 (UTC)
My experience shows that if smth is not on the policy there will always be users pushing it through. If the policy does not say that redirect can not be added en masse and does not specify when the can be added next week there is a user adding thousands per day and claiming it is allowed per policy.--Ymblanter (talk) 19:13, 6 November 2018 (UTC)
I agree we should have a policy - do you think we would need a whole section on redirects in Wikidata:Notability, or something else? I was thinking just a sentence or two there would be sufficient. ArthurPSmith (talk) 19:51, 6 November 2018 (UTC)
I do not particularly mind, as soon as it is clear enough. But I am not really an interested party. I merely summarized what I read on the RfC.--Ymblanter (talk) 20:14, 6 November 2018 (UTC)
  • Oddly, editors at Wikipedia aren't actually interested in implementing already existing solutions to the problem. Sometimes, it seems they just come to Wikidata as they haven't bothered solving the problem at Wikipedia. --- Jura 17:09, 7 November 2018 (UTC)
    Some editors at Wikidata are unable to accept that there are those of us who are interested in both projects. Quite often we find that bashing editors who are active on Wikipedia is considered acceptable here. It should never be. Sitelinks on Wikidata are designed for use on Wikipedia projects and when you are told that artificial restrictions on Wikidata – such as the inability to programmatically read a sitelink to en:Archeologist from archaeologist (Q3621491) – are causing unnecessary problems, you ought to be taking those issues seriously, not blaming other projects for deficiencies here. --RexxS (talk) 20:08, 7 November 2018 (UTC)
    I don't understand your inability to link archeologist to w:archeology programmatically. Where do you want to do it and what approaches have you tried? --- Jura 20:52, 7 November 2018 (UTC)
    Jura are you being deliberately obtuse? The problem is linking from all the other wikipedias to an enwiki page; there is nothing enwiki can do to allow that, and so for all those languages that have a page for archaeologist (Q3621491), it looks like there is nothing relevant in enwiki. Creating a redirect link is what solves the problem. What else do YOU propose to do such a thing? ArthurPSmith (talk) 21:41, 7 November 2018 (UTC)
    Can you provide a sample use case and explain how you attempted to solve it? --- Jura 22:01, 7 November 2018 (UTC)
    @Jura1: It seems to me he just did. He's suggesting that archaeologist (Q3621491) ought to be able to sitelink en:Archeologist, even though the latter is a redirect. - Jmabel (talk) 00:30, 8 November 2018 (UTC)
    I've manually added the sitelink by temporarily blanking the page. Jc86035 (talk) 16:35, 8 November 2018 (UTC)
    @Jmabel: I don't see how this would be a usecase of enwiki one tries to solve, but maybe it's just theoretical one. --- Jura 04:06, 8 November 2018 (UTC)
    I don't want to ventriloquize User:ArthurPSmith, so he should probably step back in here, but from what he wrote, he seems to be saying that it is an existing case, and proposing this as the solution. How is that "theoretical"? - Jmabel (talk) 16:35, 8 November 2018 (UTC)
    Thanks Jmabel. I think Jura was asking for in what way implementing a redirect link would actually help an enwiki user in a case such as this one. To me the important use case here is for users of other language wikis, if somebody who speaks both languages happens to go to the archaeologist (Q3621491) page in that language, the interlanguage links do not indicate there is an English-language article that is closely related. Allowing a redirect link in Wikidata would enable that interlanguage link to appear, and so the bilingual user could easily look at both and perhaps understand better the topic than from just looking at one language page. However, the interlanguage link to those other languages does NOT appear on the enwiki page right now, and it would presumably require some development work to allow that in one form or another. It would be nice to do that in the long run, but this first step does at least fulfill a real purpose. ArthurPSmith (talk) 16:58, 8 November 2018 (UTC)
    @Jmabel: I think it would still be good to see an actual usecase for enwiki. Some like "I'm an English Wikipedia user and I have built an infobox for biographical articles about archeologists and want the word "archeologist" in the infobox to link to "archeology" (if there is no article for archeologist)". --- Jura 16:03, 9 November 2018 (UTC)
    @Jura1: I'm an English Wikipedian (as well as being active on other Wikimedia projects) and I have built an internationalised module used on 50+ wikis that contains functions to read Wikidata into infobox fields. If I want to use it to create a Wikidata-aware infobox for en:Howard Carter, I want each of his occupations to link to the relevant English article. On Wikidata he has three occupations: anthropologist (Q4773904), archaeologist (Q3621491), egyptologist (Q1350189). The first one has a sitelink to the English article en:Anthropologist and the other two need to have sitelinks to the English redirects en:Archaeologist and en:Egyptologist. Now multiply that by hundreds of occupations and by dozens of other properties (such as educated at (P69)) that may point to Wikidata entities that correspond to redirects; and then multiply that by the number of wikis that use the module or some similar module. I hope you're not going to suggest that I blank the redirects, then create the sitelink, then put the redirect back for thousands of items on Wikidata. Why not simply allow egyptologist (Q1350189) to link to en:Egyptologist? There's a user case – and it's not the first time I've expounded it here – now it's time for you to do some work as well and explain why forbidding those sitelinks makes any sense to folks re-using Wikidata in the other projects. --RexxS (talk) 23:38, 10 November 2018 (UTC)
  • Thank you so much! Implementing that decision will enable enwiki to remove lots of existing errors, and should enable Wikipedias to use Wikidata in places where they currently avoid using Wikidata because of the errors caused by the lack of redirects. There is a one-to-one correspondence here. For the field: archaeology (Q23498) = en:Archaeology. For the profession: archaeologist (Q3621491) = en:Archaeologist. The problem has been that Wikidata did not permit the second link to be recorded because en:Archaeologist is a redirect. (enwiki has no article on the profession; it's covered in the article on the field.) In many cases, such as infobox templates, enwiki editors have coded workarounds which link to the enwiki page whose title matches the Wikidata label in English, and hope that that page is an article on a relevant topic. This works in the case of archaeology. However, it regularly causes problems elsewhere in enwiki. The title may match an article on a different topic with a similar name (en:Michael Jackson when the link intended en:Michael Jackson (writer)) or a disambiguation page (a list of en:John Smiths). It will be wonderful to be able to start recording accurate links instead of guessing and hoping. Certes (talk) 16:51, 8 November 2018 (UTC)
  • I reread Lydia post and want to say that it confuses the interests of data consumers. Say a data consumer or example wants to host data about mental illnesses and identifies those internally with IDC codes. We have Wikipedia pages that discuss multiple IDC codes and saying that it's bad for the data consumer to be linked to the page that discusses the illness that corresponds to the IDC code, because that page also discusses other IDC codes misidentifies the interests of that data consumer.
For all data consumers who want to be able to link to information if information is available in Wikidata, linking to redirects is good. It's only bad if a data consumer doesn't want the link if they don't like that other subjects get discussed as well at the linked page.
@MisterSynergy: suggestion that the RfC is a result of conflicting goals between Wikidata as a knowledge base vs. Wikidata as a sitelink hub is misleading. As the other of the RfC I think it's useful for both the knowledge base because it allows better discription of entities that don't have their own Wikipedia page but that are described in a paragraph on a page, the otherwise couldn't be linked. The conflict is more between inclusionism and exclusionism.
As far as the points by ArthurPSmith go:
(1) I agree that it makes sense to change the notability policy in a way to explicitely say that redirect don't produce notability via #1 of the notability policy. Given that this is clarification of existing policy I don't see a need for an RfC to do that.
(2) Redirect creation should be done with attention to detail and as such I support to limit it to human editors and forbid bots from doing so. I don't think that anybody specifically argued for the ability of bots to create redirects and as a result I don't think we need to start an RfC for that.
As far as redirect creation through moving, it's already the status quo that moving creates redirect links today. There are good arguments that we might want to handle that differently, but I they are a separate issue from this RfC.
(3) Having a user interface where the redirect is highlited is a good idea. I also think that the details shouldn't be decided via a discussion but should be hashed out by a WikimediaDE UI person. ChristianKl❫ 18:55, 8 November 2018 (UTC)
  • @Ymblanter: I very much welcome your close, and your decision which seems to me to make a lot of sense. However, the following line is not correct: Given that we currently have no mechanism of redirect addition (except for twice moving articles on the projects, which is a clear disruption and I am sure will be perceived as such on the projects).
All that is required to sitelink to a redirect is to temporarily comment out the #REDIRECT on the wikipedia page, then create the sitelink, then restore the #REDIRECT. I don't think any wikipedias would see this as disruption; I doubt that many would even notice.
Alternatively, when a redirect page does not yet exist, it is easy to create it with some holding text, sitelink it, then finally add the #REDIRECT that turns it into a fully functioning redirect.
It would be nice to have a better interface for doing this; but the lack of such an interface is not a blocker, neither for humans nor for bots.
Given the community decision, two further priorities stand out (at least IMO): Firstly, to distinguish sitelinks connecting to redirects that are good targets for sitelinks (ie en:archaeologist -> en:archaeology) from sitelinks connecting to bad targets for sitelinks (eg most redirects caused by page moves). On en-wiki and many others, "good" redirects for sitelinks can/should be marked after sitelinking by Template:Wikidata redirect (Q16956589). This template should be spread to more wikipedias; existing uses should be reviewed and confirmed; and sitelinks to redirects that don't have the template should be investigated. These are all things the community/communities can do.
The second thing is to mark on Wikidata and in the sidebar of Wikipedia articles when a sitelink goes to a redirect. This is something we need the developers to do; but now the community has decided that sitelinks to redirects can be okay, and we are going to start creating them for certain types of cases more systematically, the developers should understand that the community now want such redirect badges as a priority. However this is a desideratum not a requirement; there is IMO no need for the community to hold off and wait for this before creating redirects, now that the RFC has been closed and the community has actualised its decision. Jheald (talk) 12:40, 9 November 2018 (UTC)
#2 now suggested at m:Community Wishlist Survey 2019/Wikidata/Indicate when Wikidata sitelink is to a redirect Jheald (talk) 16:36, 9 November 2018 (UTC)
Indeed, technically there are also other means to insert redirects, but I am sure none of them would be really accepted on the projects. A user mass-moving pages twice solely to create Wikidata redirects, or a user mass-removing and readding redirects solely to add them to Wikidata items, on English Wikipedia will likely be first dragged to ANI and warned, and eventually blocked.--Ymblanter (talk)
Sorry @Ymblanter:, but I simply don't think that's true. As noted above, enwiki even has a template, en:Template:Wikidata redirect, to mark redirects created to accommodate incoming wikidata sitelinks. It currently has 25,000 uses. A user running a mass scheme of removing #REDIRECT lines, adding a Wikidata sitelink, then restoring the #REDIRECT line, each done in perhaps less than a minute, wouldn't be warned, blocked, or dragged to ANI. They would simply be seen as going through the hoops that need to be gone through to do something useful.
As for mass-moving pages twice, why would anyone do that, when they could simply edit the page? Jheald (talk) 20:57, 9 November 2018 (UTC)
Well, we obviously have different perception and different experience concerning the relation of the English Wikipedia and Wikidata.--Ymblanter (talk) 21:01, 9 November 2018 (UTC)
If one was adding wikidata-based content to an actual reading page then that might ruffle some feathers.
But adding a sitelink to a redirecting page that no-one on en-wiki is going to see anyway? No, unlikely that anyone would even notice; still less likely that they would care. Jheald (talk) 21:57, 9 November 2018 (UTC)

Rename official website (P856) to "homepage" or "official URL"[edit]


Pictogram voting comment.svg Notified participants of WikiProject Properties

This property says to refer to the "URL of the official website of an item". To me, this is the domain name of the website.

However, this property seems to points to "official homepage" rather than "official website":

Another question is that "" and "" are listed between the equivalent properties, but they seems to be equivalent to URL (P2699) rather than official website (P856).--Malore (talk) 18:30, 6 November 2018 (UTC)

I don't mind if its called official website or homepage, the meaning is the same. About your other question, is exemplified with a "home page" and vcard urls are also used for home pages. -- JakobVoss (talk) 21:50, 6 November 2018 (UTC)
@JakobVoss: Currently, is stated as equivalent of official website (P856) and URL (P2699). Since they are two different properties, one of the two equivalences is wrong. Given that is described as "URL of the item", I think it's "more equivalent" to URL (P2699).
As regards the naming, I think the difference between homepage and website is as follows:
  • Symbol support vote.svg Support I've thought that for quite some time already, was just too lazy to bring it up. --Marsupium (talk) 16:34, 9 November 2018 (UTC)

Script request - links from labels/aliases of Q-items to lexemes[edit]

If someone is able to program it, it would be nice to have a script that converts the labels/aliases of a Q-item into links to L-items that are connected with item for this sense (P5137). So basically what it should do is to see if the text of any of the forms of the linked L-items matches 1-to-1 with any of the label/aliases of the Q-item for that language, and if it does, it should convert the text of the label/alias into a link to the L-item. Normally there should be only one exact match per label, but there is at least a known exeption: both gwenn (L30900) (noun) and gwenn (L30901) (adjective) link to white (Q23444). For cases like this it would be nice if the additional L-items are linked with superindex if possible, if not then it is ok to just link one of them for a first version.--Micru (talk) 22:53, 6 November 2018 (UTC)

The use of "Structural reasons"[edit]

I am raising the concern of adding persons for structural reasons and may not be deleted as an item linked as the spouse of a notable person, with references, and mentioned in multiple Wikipedia article. I am afraid that this will lead to the start of adding childrens and fathers/mothers as well. Is there any opinion about this?
As an example I do have abt. 800 notable persons from the Norwegian wikipedia with references to cencuses. And in these cencuses I can also find the spouses, children and parents of the notable person. I do not find those spouses, children or parents notable. I have made a suggestion for deletion on Alexander Borodin (Q164004) wife Ekaterina Protopopova (Q57975541). Please have a look at that proposal also. Pmt (talk) 19:59, 6 November 2018 (UTC)

Items are allowed to be just containers for labels. It's information on the notable person, the subjects of the individual items don't need to be notable in their own right. (I think we should rename Wikidata:Notability to something like "Inclusion criteria", really.) --Yair rand (talk) 20:33, 6 November 2018 (UTC)
@Yair rand: By this you mean that I can create items for a notable persons children, parents and spouses? Pmt (talk) 21:24, 6 November 2018 (UTC)
@Pmt: You can create items for almost any dead person if you provide scholarly sources as References These are missing for Alexander Borodin (Q164004) at the moment! -- JakobVoss (talk) 21:57, 6 November 2018 (UTC)
@JakobVoss: and @Yair rand: I am still a bit confused and would like to have some further advises. As a scolary source I have the Norwegian 1801 census. And if I then can create an item for an person with described by source (P1343) in no label (Q11969384). Example no label (Q58333479) (not completed, but have all references). I am focusing on persons but what about say, individual ships, found in different (Norwegian) Archives or in Lloyds register? And again sorry for insisting but I find it usefull to have this discussed before doing wrong Things. Pmt (talk) 19:24, 7 November 2018 (UTC)
Generally yes. If you however want to enter all people in the whole Norwegian 1801 census you should first create a bot approval request. ChristianKl❫ 21:09, 7 November 2018 (UTC)
  • Is there a way to indicate that somebody was married / divorced etc., on a particular date without naming their spouse? I omit such information because I don't want to create another item just to hold a spouse name. I suppose significant event (P793) could be used. Death of a spouse would also be a significant event. Ghouston (talk) 21:39, 7 November 2018 (UTC)
    • I think there are cases where one should make an item for the spouse, even if one doesn't know their name: wife of St. Peter (Q22340337). --- Jura 05:40, 8 November 2018 (UTC)
  • Often I do know the name of the spouse, but if they don't seem to be notable for anything it doesn't seem worth creating an item. Ghouston (talk) 08:43, 8 November 2018 (UTC)
  • Part of the way Wikidata is designed that if the information about the spouse is worth recording, then that's ground for the person being notable under our rules. This way the data structure is much easier to work with for people who work automatically with it. This way querying for the name of the wife of a given person works the same in every case. ChristianKl❫ 20:03, 8 November 2018 (UTC)

How to connect occupation and employer?[edit]


She is a columnist for the Evening Standard. I entered both of those things, but how can I connect them? She has more than one occupation and she isn't a chef for the Evening Standard. Face-wink.svg Alexis Jazz (talk) 11:15, 7 November 2018 (UTC)

I thought of Lee Manjai (Q21263395) item way of doing this, but this example has missing property (date for each employer), and maybe something else I missed. — regards, Revi 13:12, 7 November 2018 (UTC)
"Employer" can be qualified with "position held", which may help. - PKM (talk) 22:31, 9 November 2018 (UTC)

Qualifiers representing relationships[edit]

For C major (Q55706505) (the musical chord), and similar items, would it be appropriate to use object has role (P3831)perfect fifth (Q12372854) on the statement has part (P527)G (Q1440231), or would new items have to be created for e.g. "higher note of a perfect fifth" to represent this (or should another qualifier be used)? "Perfect fifth" would describe the relationship formed by C and G, but not G on its own. Jc86035 (talk) 12:15, 7 November 2018 (UTC)

Country of citizenship and Place of birth and Place of death[edit]

These fields give a warning if the birth and death dates of the person do not coincide with the creation date and dissolution date for the country. Can we please have the warning suggest the correct political entity: For Germany suggest Wiemar Republic or Nazi Germany or whatever the correct answer is, since it can be easily calculated, but no readily found in a search. RAN (talk) 14:29, 7 November 2018 (UTC)

Problem in merging[edit]

I am trying to merge two items but can't do it because some property P17 is not matching. Can please someone tell me about it. Items, I am trying to merge are Q62943 and Q29950602.☆★Sanjeev Kumar (talk) 14:42, 7 November 2018 (UTC)

@संजीव कुमार: The problem is Q29950602 points to Q62943 via it's P17 value (country). You have to remove that relation before merging. ArthurPSmith (talk) 16:01, 7 November 2018 (UTC)
Thanks.☆★Sanjeev Kumar (talk) 08:33, 8 November 2018 (UTC)

Add data relating to the GDPR about companies[edit]

The General Data Protection Regulation obliges companies to provide some information publicly, such as a privacy policy and a contact person. Different organisations have started mapping out this data, but there is little joint work organising this data into a coherent whole, or even initial organisational effort into making sure this gets mapped the right way. My organisation, PersonalData.IO, would like to work on this. What is the best way to get started on this effort? This is the core of the data that would need to be mapped: organisation name, organisation id elsewhere (Open Corporates), organisation website, organisation privacy policy, contact information. An example data source would be here.

Accessory questions: the UK Information Commissioner's Office has a register of fee payers, or in fact it had one publicly downloadable, now only searchable. Assuming it is under the [5], is this something Wikidata would want? Pdehaye (talk) 14:45, 7 November 2018 (UTC)

The Open Government Licence is not directly compatible with CC0. ChristianKl❫ 20:54, 7 November 2018 (UTC)
Thanks! This link says "The other Wikimedia hosted projects including Wikipedia, Wikibooks and Wikiquote may also find new material they can incorporate into their projects". Shouldn't it be changed then? Pdehaye (talk) 22:02, 7 November 2018 (UTC)
If that is the case then yes it sounds like that page should be updated ·addshore· talk to me! 12:30, 8 November 2018 (UTC)
I don't see any mention of Wikidata in that quote. Wikidata is licensed with a more permissive license then Wikipedia and as such not everything that can be used in Wikipedia can also be used in Wikidata. ChristianKl❫ 18:41, 8 November 2018 (UTC)
It says "The other Wikimedia hosted projects including...", and there was also the prior quote "It is considered a free content licence and compatible with the requirements of all Wikimedia projects including Wikipedia, Wikisource and Wikimedia Commons". This is a clear contradiction to what you were claiming. I dug a bit deeper, and indeed you seem to be correct. I made some changes over there, please do have a look. Pdehaye (talk) 08:35, 9 November 2018 (UTC)

Differentiate between primary sources and other sources in references[edit]

Is there a way to point out that a particular reference is the primary source of a statement (e.g. "" is the primary source for Windows 10 (Q18168774)inception (P571)  1 October 2014)?. Maybe something like a "reference type" property is sufficient, maybe it's better something more integrated in the Wikibase software like ranks or badges.--Malore (talk) 15:44, 7 November 2018 (UTC)

@Malore: There is type of reference (P3865).--Micru (talk) 15:50, 7 November 2018 (UTC)
Wikidata:Property proposal/reference has role could also be relevant. —MisterSynergy (talk) 15:54, 7 November 2018 (UTC)
Thank you, they are both interesting.--Malore (talk) 16:57, 7 November 2018 (UTC)
I think the wording of this discussion is very confusing. When discussing references, "primary" is most often used in contrast with "secondary". A primary source is a source written by someone or some organization directly involved in the subject matter, or written close to the time of an event. "Secondary" is a source written by someone who was not directly involved in an event, not the proposer of some idea, etc., and who consulted a number of sources to come up with a description of the matter. The Windows 10 example would be a primary source because it was written by Microsoft.
But this discussion is about identifying the reference that actually contains or directly supports the statement. We should find some other word than "primary" to describe this source.
Perhaps a better example would be geographic coordinates where the reference gives the coordinates in a system not supported by Wikipedia. So the containing reference would be the one that contains the coordinates, and an explanatory reference could be a website that can convert from the coodinate system in the containing reference to Wikidata's coordinate reference system. Jc3s5h (talk) 17:53, 7 November 2018 (UTC)
@Jc3s5h: No, maybe I didn't explain it right but I was referring to "primary" sources as opposed to "secondary".--Malore (talk) 04:04, 8 November 2018 (UTC)
I don' understand what you mean by primary and secondary. I understand what w:Wikipedia:Identifying reliable sources means by those terms, but I don't understand your meaning. Jc3s5h (talk) 12:56, 8 November 2018 (UTC)
@Malore:, what Jc3s5h wrote above is certainly the normal distinction of a primary and secondary source in English. (Wikipedia and other encyclopedias would be tertiary, because they are, at least in principle, drawn from a survey of secondary sources. If you mean something else, what exactly do you mean? - Jmabel (talk) 16:38, 8 November 2018 (UTC)
@Jc3s5h, Jmabel: I mean exactly what Jc3s5h means for primary, secondary and tertiary sources: in particular, what I mean by primary source is "the original source, the source the information comes from" and what I mean by other sources is secondary and terziary sources--Malore (talk) 18:58, 8 November 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────In that case, I don't think we should seek to designate the source the information comes from. Secondary sources are normally considered the best sources to use in English Wikipedia, and I think the same should normally apply to Wikidata. I think the circumstances where it would be better to use a primary source over a secondary source would be too complex to convey with any of the usual Wikidata properties, qualifiers, etc. The only place I can imagine where you could explain such a situation would be the item's talk page. Jc3s5h (talk) 19:07, 8 November 2018 (UTC)

"Principal" source might be a useful phrase in English to indicate the key source supporting a particular fact. A principal source might be a primary source, secondary source, or tertiary source. Which of the latter groups a source belongs to can often be inferred from what it is -- for example if the cited source is a general history, that's likely to be a secondary source; if it's a letter or a personal memoir, that's quite likely to be a primary source. So in many cases the instance of (P31) statement on the item for the source, or a genre (P136) statement if available, should give quite a strong clue. Jheald (talk) 12:06, 9 November 2018 (UTC)
I think Wikidata should contain as many sources as possible (primary, secondary and tertiary). IMO, pointing out which are the primary sources is useful if someone is looking for the original source of the information.--Malore (talk) 13:43, 10 November 2018 (UTC)
The problem with the word "primary" as used in this discussion and w:Wikipedia:No original research#Primary, secondary and tertiary sources is that it does not correlate well with being the original source of the information. A source could have been written close to an event, and perhaps involved, but not viewed as the definitive source on the matter. For example, a newspaper published on or just after the day of a death might quote a police chief, who stated the death occurred on a certain date. But the definitive source for a date of a death in a modern first-world country would be the birth certificate. If it's available to the public, later authors of secondary sources would probably examine the death certificate to say when the death occurred. Jc3s5h (talk) 17:37, 10 November 2018 (UTC)
@Jc3s5h: A primary source doesn't have to be reliable or official. Often, secondary and tertiary sources are more reliable than primary ones. As regards your examples, the death certificate is both a primary source and an official source, while the newspaper article quoting the police chief is a secondary source. The unedited video interview of the police officer would be a primary source, but not an official one. Your example made me think it would be good if we'll identify also "official sources" of statements (e.g. the death certificate in the case of the date of a person death).
@Jheald: It's not automatic that a personal memoir is a primary source and a general history is a secondary source.
A personal memoir is a primary source only where it talks about the personal experience of the author, but it may report also other information about events that he didn't experienced. Likewise, a general history can be a primary source of the author opinion or the book itself.
Regarding the "key source supporting a particular fact" there is already statement supported by (P3680).--Malore (talk) 20:03, 12 November 2018 (UTC)
I disagree that a newspaper article written within a few days of an event can ever be a secondary source for the event; it is too close in time to be a secondary source, even if the reporter did not witness the event. It's certainly true that primary sources are not always reliable or official, but ones that are not reliable have no place in Wikidata. Primary sources that are unofficial but reliable could be cited. Jc3s5h (talk) 21:00, 12 November 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The idea that secondary sources are superior to primary sources is a concept peculiar to Wikipedia. Other Wikimedia projects, such as Wikiquote, Wiktionary, Wikisource, and Wikispecies place emphasis upon primary sources. We want the first place a quote was published, or original text demonstrating the definition of a word, or the first publication of a text. On Wikispecies, the primary literature, where a new scientific name or new combination was first published, and the supporting scientific for the name, is desirable over a secondary source interpreting or reviewing previous studies. --EncycloPetey (talk) 21:25, 12 November 2018 (UTC)

As regards the newspaper article, even an edited video of an event is considered a secondary source because it somehow modifies a primary source (the video of the event).--Malore (talk) 05:47, 13 November 2018 (UTC)

Clinical Trials[edit]

Has there been any attempt to automatically add (clinical trial (Q30612) data from (Q5133746)? The required properties are descriped here by @Daniel_Mietchen: Mahdimoqri (talk) 03:03, 8 November 2018 (UTC)

Internal error[edit]

I got this error while previewing the creation of Talk:Q170439 with {{Item documentation}}:

[W@QEJApAME0AAD4NY6sAAACM] 2018-11-08 09:38:44: Fatal exception of type "UnexpectedValueException"

Is this a bug or a server error? Jc86035 (talk) 09:43, 8 November 2018 (UTC)

This was a bug in the TwoColumnConflict feature which various people have experienced on different wikis over the past hours (T205942, T208840, T209012, T209036, possibly others). It should be fixed for now (the feature was temporarily disabled). --Lucas Werkmeister (WMDE) (talk) 11:22, 8 November 2018 (UTC)

Consensus is needed for Q48928408[edit]

Some people misunderstand the definition of located in the administrative territorial entity (P131). The present "protected" version of Q48928408 is swearing black is white.

The description of location (P276) stated that: "In case of an administrative entity use P131". It is clear that the Mainland Port Area is an administrative entity, and it is a common knowledge that the Mainland Port Area is located in the Hong Kong SAR. 09:46, 8 November 2018 (UTC)

@Deryck Chan, Jc86035: if they know how to handle this. --Liuxinyu970226 (talk) 10:48, 8 November 2018 (UTC)
@Liuxinyu970226: I think the property doesn't really work for this particular item. The port area is administratively part of Futian District but is physically located within Yau Tsim Mong District. The English description of the property refers specifically to the "territory of the following administrative entity", which would imply the value should be Yau Tsim Mong if the area is not truly an enclave in every respect (Shenzhen Bay Port (Q5972370) is in Nanshan District). Jc86035 (talk) 10:55, 8 November 2018 (UTC)
That's why I re-changed its Chinese translations as "位于行政领土实体/位於行政領土實體" as "行政领土实体/行政領土實體" (administrative territory entity) do not necessarily same as "行政区/行政區" (administrative area). --Liuxinyu970226 (talk) 10:58, 8 November 2018 (UTC)
Could we not have two statements with qualifiers (e.g. applies to part (P518))? - Nikki (talk) 12:23, 8 November 2018 (UTC)

This is a problem Wikidata isn't equipped to solve. Normally located in the administrative territorial entity (P131) works because a geographical location or a physical artefact is both located inside and administered by the same territorial administrative entity. But this breaks down when the item itself is about a enclave (Q171441) - by definition a enclave (Q171441) is "located in" and "administered by" two different entities. This isn't a translation problem, but rather that located in the administrative territorial entity (P131) can't cope with this edge case unambiguously. We can list both values (Yau Tsim Mong and Futian) and qualify each with either object has role (P3831) or nature of statement (P5102) = geographic location (Q2221906) and administrative territorial entity (Q56061); or we can avoid using located in the administrative territorial entity (P131) altogether. At any rate we need a bespoke solution for this bespoke problem. Deryck Chan (talk) 13:12, 8 November 2018 (UTC)

The different ways subdivisions can be related to countries and each other is very complicated. See Wikidata:Project_chat/Archive/2018/10#Countries_and_their_subdivisions_and_territory, where I tried to outline some of the issues involved. Also note the existence of the properties exclave of (P500) and enclave within (P501). --Yair rand (talk) 19:21, 8 November 2018 (UTC)

According to this government notice, "《国务院关于同意广东广深港高铁西九龙站口岸对外开放的批复》(国函〔2018〕33号)明确规定,广深港高铁西九龙站内地口岸区由深圳市人民政府负责管理". That means the Mainland Port Area is managed by the government of Shenzhen City, not Futian District. It is solely managed by the city level government. It is not a part of Futian District. 03:03, 9 November 2018 (UTC)

In this aspect, it seems that Shenzhen is more accurate than Futian. Also, I think Mainland jurisdiction is what need to be emphasized here. CommInt'l (talk) 11:29, 12 November 2018 (UTC)

[Consultation] Using Q-items for senses[edit]

To link between equivalent senses of different language lexemes we have translation (P5972). This works quite well when the number of linked senses is small, however as the number grows, it becomes harder to maintain. For an example of this you can check Lexeme:L12912#S1, where each one of the linked senses with translation (P5972) is linked to the others; if I would add a new translation I would have to update at least 20 other lexemes. To make it simpler, in this case it is possible to link from each equivalent sense to the Q-item Tuesday (Q127) using item for this sense (P5137), then it is superfluous to add translation (P5972). In this case it is very straightforward because the item already exists, however we don't have an item to represent the senses of other words like but (L1387) or important (L4147). On en-wiktionary you can see the translations of "but" and "important". If we would create items for those senses, then it would be possible to link all lexemes to them. Even if the senses could be considered clearly identifiable conceptual entities that can be described using serious and publicly available references (and as such notable), this is a novel application of the Q-items, that is why I would like to invite more colleagues to express their view on this. On the previous discussion about this topic, ArthurPSmith estimated that we would need under 100,000 new Q-items. Another possible way to estimate the number of items could be to count the transclusions of Template:trans-top, considering that we might already have items that represent the senses of the nouns.--Micru (talk) 13:41, 8 November 2018 (UTC)

@Micru: To me it seems a bit of an oversight to not allow items to share glosses from a centralized item (since many words can be translated exactly), although the situation is somewhat similar for labels and descriptions. I think it would be sensible to use items to indicate translations, although perhaps it would be more suitable to use a new property to indicate items about senses, separate from the items about concepts which the senses describe. Jc86035 (talk) 14:09, 8 November 2018 (UTC)
I think "sense" == "concept", no? I'm not clear on the distinction you're trying to make here anyway. Certainly the current arrangement works well for nouns (for almost all of which we already have Wikidata items representing at least some of the different concepts associated with those nouns). The problem is for verbs, adjectives, adverbs, and other parts of speech, which aren't "entities" in the usual sense, but their conceptual meanings are actions or qualities or modifiers of some sort. ArthurPSmith (talk) 16:28, 8 November 2018 (UTC)
@ArthurPSmith: Somewhere up the page, white (Q23444) is used as an example of an item linked to from both noun lexemes and adjective lexemes. I thought it would be potentially messy if multiple groups of senses would be linked to the same item. Jc86035 (talk) 17:00, 8 November 2018 (UTC)
@Jc86035: I think it's ok. Many nouns are used as adjectives with the same conceptual meaning, but of course a differing syntax and meaning within the sentence. "This white" vs "white table" seem to me little different from "This garden" vs "garden table". I think it would be fine to link both noun and adjective senses to the same Q item, I don't think that would hurt translation. But descriptive adjectives like "important", "long", "deep", etc. don't have that close relation to nouns and I think would need their own items. If we proceed with this approach... ArthurPSmith (talk) 18:33, 8 November 2018 (UTC)
@ArthurPSmith, Jc86035: It all depends what we want to achieve. If we want to be able to support wiktionaries in a way that when a translation is updated it shows up in all wiktionaries, then the most pragmatic approach is to follow their practices and create as many items for senses as needed.--Micru (talk) 20:35, 8 November 2018 (UTC)
Not all words have senses referring to some concept. There is no concept that "but" refers to, its meaning is functional rather than conceptual. —Rua (mew) 18:13, 8 November 2018 (UTC)
@Rua: The conceptual meaning of conjunctions is not something I've really thought about, but maybe one could argue for it? There aren't so many of them, anyway. ArthurPSmith (talk) 18:33, 8 November 2018 (UTC)
For "and" there is logical conjunction (Q191081) I suppose. Probably we'd want to add a conceptual form that wasn't purely focused on logic though. ArthurPSmith (talk) 18:39, 8 November 2018 (UTC)
@Rua: Even if the meaning of a lexeme is functional, it still has meaning which perhaps some day we will be able to capture with statements. On a more practical level, it reduces complexity to link all translations to a central Q-item instead of linking them between them.--Micru (talk) 20:35, 8 November 2018 (UTC)
FWIW, "but" has the same literal meaning as "and", with the additional connotation that the fact that both conjoined statements are true might go counter to expectations (or other similar connotations of contrast). - Jmabel (talk) 21:10, 8 November 2018 (UTC)
I wouldn't worry so much about conjunctions and more functional lexical categories. The real question is whether verb, adjective and adverb senses should be added as Q Items to the Main namespace of Wikidata, since these categories undoubtedly contain conceptual entities, each with many synonyms and translations. Once we have decided on that, perhaps there could then be more discussion about taking it further with more lexical categories. Liamjamesperritt (talk) 01:02, 9 November 2018 (UTC)
Another point to consider: many languages have things like frequentatives, passives and other verb-to-verb derivations that don't change the overall conceptual meaning of the verb, but add a semantic nuance or change how the verb behaves grammatically. For nouns, languages might have diminutives or augmentatives. Handling such variations will need some thought: do we consider them all to have the same sense item, or different ones? The former would allow terms to be more easily found, since finding the basic meaning is enough, but would make translations less specific because potentially many verbs in such a set could translate a single English (or other language) verb. The latter would be more specific, but then you end up with a lot more sense items, which are harder to search through. —Rua (mew) 18:41, 10 November 2018 (UTC)
@Rua: The wiktionaries have faced that problem long ago, and they have found consensus around translation lists that we can import. There is no need to overthink this, we'll do our best in our capacity, and we can discuss individual cases. For now I think it is just enough to follow the steps of what others have done in the past, and create the senses where there is a consensus. For the rest there is no need to create items, the senses in the lexemes might be enough for those.--Micru (talk) 23:13, 11 November 2018 (UTC)

Instances of term[edit]

Is instance of (P31)music term (Q20202269) correct on items? It seems unnecessary and possibly incorrect to me, since it's usually used on items which describe concepts which aren't words (e.g. human voice (Q7390), tonality (Q192822), big band (Q207378)). Jc86035 (talk) 13:57, 8 November 2018 (UTC)

  • In English, at least, a "term" is not necessarily a single word. I can't speak for how the cognates of "term" are used in other languages. - Jmabel (talk) 16:42, 8 November 2018 (UTC)
    @Jmabel: Notwithstanding terms often not being single words, it seems to me that if the item describes a concept rather than the term itself, then it shouldn't be classified as a term (but perhaps the relevant senses of lexemes should be; e.g. tonality (L36186)). Jc86035 (talk) 16:54, 8 November 2018 (UTC)
  • I agree that the "term" should be avoided in the Q-namespace and terms should be modeled in the lexeme namespace. ChristianKl❫ 18:04, 8 November 2018 (UTC)
  • It is permitted for items to have instance of (P31) → term, but only where the term is the actual topic. (See for example, Q18352004.) None of the three examples mentioned above are about terms, they are about the concepts and should not have the statement. --Yair rand (talk) 21:22, 8 November 2018 (UTC)
There are lots of these for legal concepts whose EN wiki articles start off like "xxxx is a legal term for yyyy". They should be fixed. - PKM (talk) 22:41, 9 November 2018 (UTC)

Can every wikibook(regardless of language) have a wikidata item?[edit]

Can every wikibook(regardless of language) have a wikidata item or should only notable items or items which already had a wikidata item get one(or be attached to one, in case one already exists)? I've read Wikidata:Notability and it says that "An item is acceptable" if it contains at least one sitelink to a Wikibooks item, is that true? Is that enough to add a wikidata item for a wikibook? With that logic could I add a wikidata item for Aspies Book, an item for Titta på himlen and an item for Linux για αρχάριους? Dbfyinginfo (talk) 18:38, 8 November 2018 (UTC)

  • Yes, a single Wikibook item is enough. ChristianKl❫ 19:16, 8 November 2018 (UTC)

Family / Ancestor Data[edit]

I want to create a family history database for my own Family/Ancestors and also for others. I believe that i can get access to a data source which can have this information available which is not digitized yet. Please suggest if this will be good project or not, what kind of technical challenges can come up eg. Sharing some one's personal information can be objectionable but i think this will help people connect to their families in their family tree and after a few decades and centuries this data will be very valuable.

Such data can be very useful in carrying out any type of research in future. Please suggest.  – The preceding unsigned comment was added by Dalbirmaan (talk • contribs) at 2018-11-09 05:41 (UTC).

  • Are you saying you want to do this within Wikidata (I'd oppose that) or just in general (lots of such things already exist, such as at - Jmabel (talk) 06:00, 9 November 2018 (UTC)
  • @Dalbirmaan: Wikidata items have to be based on public sources. In this case this might mean publishing the data source that isn't yet digitalized. I'm not sure whether or not WikiSource is open to publishing the kind of document you want to publish but otherwise you would need to find another space online to publish it.
After that step is done, I think it's great to add the data to Wikidata. Having sourced data on Wikidata that's not available elsewhere is great. ChristianKl❫ 16:00, 12 November 2018 (UTC)
  • @Dalbirmaan: -- you shouldn't reinvent the wheel; there are existing genealogy database formats (most famously/notoriously GEDCOM (Q667761)) and genealogy websites that would be glad to incorporate your data... AnonMoos (talk) 07:55, 13 November 2018 (UTC)

Category or article?[edit]

I have a category of pictures on Commons. On Wikidata, should i link it to the category on wikipedia or to the article itself? --Guérin Nicolas (talk) 07:50, 9 November 2018 (UTC)

  • @Guérin Nicolas: If Wikidata already has an item for the category, then link to that. Otherwise, link to the item connected to wikipedia articles, unless that is already linked to a Commons gallery. Jheald (talk) 11:32, 9 November 2018 (UTC)

Reminder: Community Wishlist Survey is open until November 11th[edit]

Hello all,

Just a reminder that the Community Wishlist Survey is open until November 11th. You can add your ideas about Wikidata here. This is a great opportunity to let us know what are your ideas and priorities in term of improvement of the software. Feel free to add your input to other discussions as well.

Cheers, Lea Lacroix (WMDE) (talk) 14:46, 9 November 2018 (UTC)

Railway - platform height, floor height - people with disabilities[edit]

How to store

  • platform height of railway station
  • floor heigth of trains

? Both are important for many people with certain disabilities if they want to enter or leave a train. 14:58, 9 November 2018 (UTC)

What do you mean by "store"? I've searched items with these titles but I did not find results. Esteban16 (talk) 23:19, 9 November 2018 (UTC)
I think that person means which properties to use to store that information. I don't think we have any way at the moment. Where could we find the sources of that data? The only property we have for people with disabilities is wheelchair accessibility (P2846).--Micru (talk) 23:48, 9 November 2018 (UTC)
@Micru: I think this would need several new properties (for rolling stock, probably from the parameter list of w:en:Template:Infobox train); and might require the creation of items for individual platform edges, especially for stations where platforms have had their height changed, or where platforms serving a single train type have different heights. Jc86035 (talk) 07:07, 10 November 2018 (UTC)

Presentation of property pages[edit]

I really suggest changing the presentation of Wikidata pages to help distinguishing immediately that we are on a "Property" page (Pnnn), whose creation is restricted (and where there should be no other wiki article associated to them), and not on an entity page (Qnnn), whose creation is free (and can list wiki articles about roughly the same topic as the item described in Wikidata).

There are frequent errors where properties of properties are added/modified/deleted that should instead be done in properties of the associated item.

A "Property" page (Pnnn) should have a distinguishing background color (e.g. light blue instead of white), and its "associated Wikidata item" property should be at top of the list of properties (it should be ranked highest within the set of properties we should give to any well-defined property "Pnnn"), just below the translated labels, then followed by constraints (that should be ranked second within the set of properties we can give to a property).

Ranking properties of defined "Pnnn" properties can be based on a specific Wikidata item "Qxxx" (labelled "Wikidata property") describing how Wikidata properties can be specified (i.e. the list of properties each property must, should, or may have). "Qxxx" should have itself the "nature of item"="property" (qualified with "of"="Wikidata") where "property" is also another Wikidata item (not a property), or "Qxxx" can be a "subclass of"="property" (another Wikidata item whose "nature of item"="entity" or one of the subclasses of "entity" which is more specific)

All the other properties of properties "Pnnn" are just informative (but may be checked) to subclassifies the set of all properties (i.e. for handling metaclasses as entities, whose properties are refereing to the "Pnnn" properties that indicate which "Qnnn" item can use that property and which value we can assign to them).

Verdy p (talk) 15:20, 9 November 2018 (UTC)

@Verdy p: Distinguishing property pages might be easily done by adding something like this CSS to MediaWiki:Common.css, although I'm not sure whether it would help or whether there would be consensus for it. Jc86035 (talk) 10:14, 11 November 2018 (UTC)
.ns-120 .mw-body {
	background-color: #e8f2ff;

This info should be made visible also in the search engine when it gives results we can select from, when entering new declarations, or in the interface presenting the data (notably in properties). Some icons/coloring would help also (we should be able to distinguish properties that are imperative, and must be respected, from those that are indicative. As well we should be able to distinguish constraints that are just "suggestions" (best available choices) from those that are exhaustive (allowing no exception to the constraint without a formal discussion to extend it or add new cases as it can severely break the rest of the infered semantics).

Presentation of results in Wikidata is the only thing that can help users creating new contradictions (or solving them by adding new redundancies that will be maintained separately and will later introduce contradictions/aberrations in inferences) because Wikidata is extremely permissive and in fact allows storing any declaration in the dataset, and can also itself make false inferences (too many "automatic guesses" when entering data where some entered data is automatically replaced by something else; a famous example, in the "easiest" part of Wikidata: enter a valid unique language code, press TAB to enter the name of an article on a wiki, the code is immediately replaced by another language whose name in the current user's language contains that code, so "es" may be instantly replaced by another language than Spanish; the same thing happens everywhere you enter a label name to select an entity: when there are several choices, Wikidata arbitrarily chooses the first one it finds, without asking the user, and without even informing it correctly in the choice list to allows the user to choose correctly). Verdy p (talk) 11:51, 11 November 2018 (UTC)

Imperial State of Iran[edit]

Can someone with the proper expertise disentangle Imperial State of Iran (Q207991)? The country and the Pahlavi dynasty should be two separate items. Thanks. - PKM (talk) 22:38, 9 November 2018 (UTC)

Donating data[edit]

Before starting a process? From the National Archival Services of Norway (Q6516420) there is an Excel spreadsheet listing all archive actors/creators of the The National Archives of Norway With names of the dcreator, ID and URI. The list contains about 27000 actors/creators. The property Archiveportal archive ID (P5888) already exist as an identificator. As an example the Archive of The Norwgian Garrison on Saoth Georgia has Archiveportal archive ID (P5888) no-a1450-01000001366069 and as URI. Should this data be donated as a whole to Wikidata? Pmt (talk) 23:03, 9 November 2018 (UTC)

@Pmt: I would add it to Mix'n'Match. That way it can easily be linked up. You can do that yourself at . For these kind of sets we generally don't import just everything because you'll just end up with a ton of orphaned items. Multichill (talk) 12:12, 10 November 2018 (UTC)
@Multichill: @Jeblad: Of course! Thank you. Seems reasonable. Pmt (talk) 12:18, 10 November 2018 (UTC)
@Multichill, Pmt: I'm not sure Mix'n'Match will work in this case, as the names can diverge quite much from what you expect. It is often not the formal name of the creator, but a short description of the creator. Often the creator has a relation to the archived material, and not an equivalence. Jeblad (talk) 14:32, 10 November 2018 (UTC)

Merge problem[edit]

I have been attempting to merge Q1196915 and Q18393795, which are clearly about the same play. No matter what I try, there is always some kind of error. The cause seems to be that Q1196915 is linked to "The Son" in the English Wikipedia, which is incorrect ("The Son" is a redirect to a disambiguation page), but I get an error when trying to remove the link. Q18393795 is linked to the correct page. How can this be resolved? Kevinsam2 (talk) 13:02, 10 November 2018 (UTC)

✓ Done. I removed the enwiki sitelink in Q1196915 first before merging. --Bluemask (talk) 13:11, 10 November 2018 (UTC)
@Bluemask OK, thanks. Did I not have permission to do that for some reason? That's exactly what I tried to do. Kevinsam2 (talk) 13:15, 10 November 2018 (UTC)

Adding coordinates[edit]

Elementary question; Commons has the easy Locator-tool in the editor, or I can paste coordinates in DMS or DD format into the Location template (with a little more editing). I don't see a way to do either here, so what are the usual or best ways, and is there a page about this? Jim.henderson (talk) 19:01, 10 November 2018 (UTC)

@Jim.henderson: You can use coordinate location (P625). Pasting coordinates in as they are displayed should work; the software will try to autoformat them (even "11.2222 -33.4444" will work). Jc86035 (talk) 10:02, 11 November 2018 (UTC)

First World war causes[edit]

(About this claim)

Am I the only one to think that a formulation like is weird and that would be far better ? Does anyone really understand the rationale of the first formulation ?

Imho we should focus of how to represent the fact that causes of World War I (Q310802) is a composite item, which consist of several events. The fact it’s a compound item implies that the causes are multiple on his own and make the claim more direct.

author  TomT0m / talk page 12:52, 11 November 2018 (UTC)

single-value constraint with title property[edit]

Hello. Some months ago I have asked "Why title (P1476) should only contain a single value?" Wikidata:Project chat/Archive/2018/04#Title. I have removed the single-value constraint (maybe I was wrong). Today a user (@Jura1: undo that. What we should do? Have the single-value constraint or not? Xaris333 (talk) 15:16, 11 November 2018 (UTC)

  • Thanks for the link to the discussion. There are 20 million uses of this property. Do we know many may have several titles?
In any case, the constraint isn't and wasn't mandatory (having several statements is a potential issue, but isn't an issue as such). --- Jura 17:11, 11 November 2018 (UTC)

Incorrect interpretation of dates in Q1165538 leading to persons still alive getting P570 by Reinheitsgebot invoked by Mix'n'match[edit]

For a number of items related to still living people, Reinheitsgebot has added a date of death (P570). It seems various dates in the source Nationalencyklopedin (Q1165538) have been incorrectly used as date of death (P570). I have undone these 19 edits.

Is there anything else that needs to be done in order to prevent these faulty Mix'n'match statements/changes to be reinserted? --Larske (talk) 22:53, 11 November 2018 (UTC)

@Larske: Best is probably to notify @Magnus Manske: about the parsing issue with this code mentioning examples like this one, so that he can fix it. I'm not very familiar with entries for that encyclopedia and swedish language, but it may be worth swapping the logic to give precedence to dates actually labelled as birth/death rather than unspecified date ranges that may be anything else than life span.--Nono314 (talk) 18:03, 12 November 2018 (UTC)

Wikidata weekly summary #338[edit]

Amanda Vickery: different versions?[edit]

When I look at the data item Amanda Vickery (Q4739786) for w:Amanda Vickery on an iPad and on a laptop I see two different occupations in the statements. On the iPad it shows up as Sociologist, but on the laptop it is historian.

I have been known to miss the obvious, so I hope I am not wasting anybody’s time.

Thanks in advance, Ottawahitech (talk) 16:11, 12 November 2018 (UTC)

Someone changed the label for "historian" to "Sociologist". The edit was undone, but pages are cached for a while, so edits to linked entities don't always show up immediately. - Nikki (talk) 10:27, 13 November 2018 (UTC)

Mix-n-Match failures[edit]

I'm not sure what's causing this particular failure, but twice now (1 & 2) a Swedish translation of Euripides' play Orestes has been added to Orestes (Q663886).

All translations of works must have their own separate data items, like this: Orestes (Q58487976). They are never placed on the data item for the work as a whole. --EncycloPetey (talk) 19:15, 12 November 2018 (UTC)


These two look the same to me: Cloyne Round Tower (Q28196048) and no label (Q30161055). Can they be merged somehow? DeFacto (talk) 21:34, 12 November 2018 (UTC)

It looks like they've been merged now, thanks to @&beer&love:. DeFacto (talk) 07:11, 13 November 2018 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 13:36, 13 November 2018 (UTC)