Wikidata:Project chat
Shortcut: WD:PC|
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc. Please take a look at the frequently asked questions to see if your question has already been answered. Requests for deletions and mergers can be made here. IRC channel: #wikidata connect |
||
- Afrikaans
- العربية
- беларуская
- беларуская (тарашкевіца)
- Bahasa Banjar
- বাংলা
- brezhoneg
- bosanski
- català
- کوردی
- čeština
- словѣньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
- dansk
- Deutsch
- Zazaki
- dolnoserbski
- Ελληνικά
- English
- Esperanto
- español
- eesti
- فارسی
- suomi
- føroyskt
- français
- Nordfriisk
- galego
- Alemannisch
- ગુજરાતી
- עברית
- हिन्दी
- hrvatski
- hornjoserbsce
- magyar
- Հայերեն
- Bahasa Indonesia
- interlingua
- Ilokano
- íslenska
- italiano
- 日本語
- ქართული
- қазақша
- ಕನ್ನಡ
- 한국어
- Kurdî
- Latina
- lietuvių
- latviešu
- Malagasy
- Baso Minangkabau
- македонски
- മലയാളം
- मराठी
- Bahasa Melayu
- مازِرونی
- Nedersaksies
- नेपाली
- Nederlands
- norsk bokmål
- norsk nynorsk
- occitan
- ଓଡ଼ିଆ
- polski
- português
- Runa Simi
- română
- русский
- sámegiella
- srpskohrvatski / српскохрватски
- සිංහල
- Simple English
- slovenčina
- slovenščina
- shqip
- српски / srpski
- svenska
- தமிழ்
- తెలుగు
- ไทย
- Tagalog
- Türkçe
- українська
- اردو
- oʻzbekcha
- Tiếng Việt
- Yorùbá
- 中文(简体)
- 中文(繁體)
- 粵語
| 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 March. |
Please give input for the Wikidata user interface redesign[edit]
Hey everyone :)
We're getting started on the redesign of the user interface of Wikidata now. As a first step we're gathering a lot of input on the current user interface until the end of the month. It'd be great to get your ideas on what you think is working well and what is not. Please leave your comments on Wikidata:UI redesign input. – The preceding unsigned comment was added by Lydia Pintscher (WMDE) (talk • contribs).
- Adding comment with timestampso this section is archived at some point. --Lydia Pintscher (WMDE) (talk) 12:01, 16 March 2014 (UTC)
Extension:GuidedTours[edit]
Hi all, I would like to propose that mw:Extension:GuidedTour gets enabled on Wikidata because in my opinion it would be a great benefit to have such tours. Our user interface has become quite difficult to understand and I want to create some tours to simplify the introduction to Wikidata. With such tours we could get lots of new editors who don't understand at the moment how Wikidata works exactly. To enable the extension, community consensus is needed, so this discussion will be open for at least one week and if there aren't any objections I will request to enable the extension on this wiki. Best regards, -- Bene* talk 19:16, 7 March 2014 (UTC)
- If it is stable enough to use, then definitely! Ajraddatz (Talk) 20:06, 7 March 2014 (UTC)
- I'm in favour of this. Filceolaire (talk) 20:21, 7 March 2014 (UTC)
- Good idea. --ValterVB (talk) 20:28, 7 March 2014 (UTC)
- Very good idea. Tpt (talk) 20:30, 7 March 2014 (UTC)
- Very good idea if possible.--GZWDer (talk) 05:39, 8 March 2014 (UTC)
- Sure, why not. --Rschen7754 06:17, 8 March 2014 (UTC)
- I'm new here, but I'm hosting a hackathon in April, introducing a ton of people to Wikidata, and I think this would be useful for them. I'm assuming we could customize this for Wikidata-specific functions. Harej (talk) 06:40, 8 March 2014 (UTC)
- Go for it! --Ainali (talk) 06:49, 8 March 2014 (UTC)
- Good idea TomT0m (talk) 09:13, 8 March 2014 (UTC)
- +1 --Goldzahn (talk) 09:43, 8 March 2014 (UTC)
- Sure. --Stryn (talk) 10:52, 8 March 2014 (UTC)
- Nice idea and will be of help for non-regulars, if it is well integrated with the interface. I hear even from experienced Wikimedians that they get lost what to do on Wikidata. whym (talk) 13:52, 8 March 2014 (UTC)
- I am in favor of enabling GuidedTours on wikidata.--Snaevar (talk) 14:45, 9 March 2014 (UTC)
- This is a very good idea and will help new comers to have a better understanding on contributing.--Sandaru (talk) 03:56, 10 March 2014 (UTC)
- Reading the above discussion - there seems to be consensus for enabling it. Filed bugzilla:62654 and assigned to myself. Will
do. John F. Lewis (talk) 18:48, 14 March 2014 (UTC)
- And was deployed earlier today by Hoo John F. Lewis (talk) 17:35, 18 March 2014 (UTC)
- Reading the above discussion - there seems to be consensus for enabling it. Filed bugzilla:62654 and assigned to myself. Will
Content (ideas)[edit]
The tour has to mentions some tools of the ecosystem, especially {{Reasonator}} (he tool, not the template) ! TomT0m (talk)
- I feel like it's not the most important thing for new editors who wants to know how Wikidata works. --Stryn (talk) 10:53, 8 March 2014 (UTC)
- It's a trivial thing to do, a one liner in the tutorial, and it's interesting for everyone as Reasonator is way better at displaying information and even have some limited but efficient ways of editing Wikidata. It's order of magnitudes better than Wikidata at these tasks, so it's a good way of navigating in Wikidata and show the Wikidata page only when we have to edit it. It's a Win for everyone. Tools like autolists proved to be very powerfools to edit the database on several items at once, they are really important to show in a tutorial. TomT0m (talk) 11:20, 8 March 2014 (UTC)
- It is a lot of work setting up a guided tour. If anyone has a proposal for developing content and needs support then consider starting a conversation at meta:Grants:IdeaLab, which is a channel for sharing ideas, soliciting for Wikimedia Foundation staff support, and requesting funding to do projects with community backing. Projects will be reviewed for funding this round beginning 1 April. It would be great to have the Wikidata community have presence in this space. Blue Rasberry (talk) 15:13, 20 March 2014 (UTC)
- We will hopefully have someone work on it as part of the outreach program for women. --Lydia Pintscher (WMDE) (talk) 15:27, 20 March 2014 (UTC)
Internationalisation[edit]
Last time I looked into this (when we enabled GuideTours on Wikimedia Commons), it was complicated to have proper internationalisation for GuidedTours − I think it is not possible for on-wiki tours, and I am not sure how it was to be done for extension tours. Just something to keep in mind. :-) Jean-Frédéric (talk) 18:29, 9 March 2014 (UTC)
- Althought English is in favour at the moment, we will also have to take care of how to translate the tours. However, I think we can solve this problem, too. -- Bene* talk 21:08, 14 March 2014 (UTC)
Structure for prizes/awards[edit]
After a workshop on Female Nobel Prize Winners we realised that there seemed to be two separate structures going on:
and
- award received (P166): 2011 Nobel Peace Prize (Q4622018) (these objects only exist for a few of the years).
Additionally there might also be some which follow a scheme like thet for the Ignobel prize
- award received (P166): Nobel Prize (Q7191)
- field of work (P101): peace (Q454) (or some similar property)
- point in time (P585): 2011.
My question, in short is which of the structures would be the recommended one? Guessing there might have been similar discussions for Olympics etc. /Lokal Profil (talk) 11:11, 10 March 2014 (UTC)
- The first one is better because it use less qualifier. But Before any generalization be sure that we have an element for each kind of nobel prize. 141.6.11.17 12:13, 10 March 2014 (UTC)
- As long specialised items like 2011 Nobel Peace Prize (Q4622018) contains the field of work (P101): peace (Q454), point in time (P585): 2011-statements (or simlair), then both methods can be used. -- Lavallen (talk) 12:27, 10 March 2014 (UTC)
- I don't think that's a correct use of field of work (P101). --—Wylve (talk) 14:34, 10 March 2014 (UTC)
- I don't think either of the uses (as a qualifier or as a property for awards) are correct uses of field of work (P101). --Yair rand (talk) 21:01, 10 March 2014 (UTC)
- I don't think that's a correct use of field of work (P101). --—Wylve (talk) 14:34, 10 March 2014 (UTC)
- @Lavallen: I'm in favor of more regularities in the datas. I'm for "always the first solution", it's easier to find later and will make simpler code and queries later. TomT0m (talk) 19:19, 10 March 2014 (UTC)
- @Yair rand: But the properties in the item about "Nobel Peace Price 2011" have to tell that it is related to "Nobel", "Peace" and "2011"! If somebody sets up an item about "Weird Al Yankovic's price for most creative use of a cupholder 2009", we normally have no article to connect that item with. To be able to understand what Qrandom_number means in the client, we need relations to "Weird Al Yankovic", "Cupholder" and "2009". -- Lavallen (talk) 06:29, 11 March 2014 (UTC)
- As long specialised items like 2011 Nobel Peace Prize (Q4622018) contains the field of work (P101): peace (Q454), point in time (P585): 2011-statements (or simlair), then both methods can be used. -- Lavallen (talk) 12:27, 10 March 2014 (UTC)
- I recommend 2011 Nobel Peace Prize (Q4622018) and such where the items exist. These items should have statements associating them with Nobel Peace Prize (Q35637) which in turn has a statement associating it with Nobel Prize (Q7191). point in time (P585) is necessary, even when the year is mentioned in the label of the prize's item. --Yair rand (talk) 21:01, 10 March 2014 (UTC)
- I would go with :award received (P166): Nobel Peace Prize (Q35637) with point in time (P585): 2011 Filceolaire (talk) 16:57, 11 March 2014 (UTC)
- +1 with Filceolaire Keep the data searchable: by mixing the date with the event it becomes impossible to perform a search by year. Snipre (talk) 17:58, 11 March 2014 (UTC)
- That would only be the case if the date were omitted. Using the more specific item doesn't mean that the point in time (P585) is no longer necessary. --Yair rand (talk) 19:23, 11 March 2014 (UTC)
- But it means you can't do a search on the simple Nobel Peace Prize (Q35637) item plus the year - you have to do a search accross the various Peace prize year items. Filceolaire (talk) 07:01, 16 March 2014 (UTC)
- No, you can search entities which are instance of (P31) the relevant prize. As a general rule, it would probably be even better to do searches also on items which are subclass of (P279) (or a chain of multiple subclass of (P279)s) the prize as well. --Yair rand (talk) 04:55, 17 March 2014 (UTC)
- But it means you can't do a search on the simple Nobel Peace Prize (Q35637) item plus the year - you have to do a search accross the various Peace prize year items. Filceolaire (talk) 07:01, 16 March 2014 (UTC)
- That would only be the case if the date were omitted. Using the more specific item doesn't mean that the point in time (P585) is no longer necessary. --Yair rand (talk) 19:23, 11 March 2014 (UTC)
- +1 with Filceolaire Keep the data searchable: by mixing the date with the event it becomes impossible to perform a search by year. Snipre (talk) 17:58, 11 March 2014 (UTC)
- For Olympics and other sporting events I would go with 'participated in:2014 Winter Olympics' with qualifiers 'sport:downhill slalom', 'time:5min 3 sec', 'place:gold medal' We will need some new properties for that. Filceolaire (talk) 16:57, 11 March 2014 (UTC)
- I would add the point in time (P585): 2014 in order to always have the possibility to perform time query. Snipre (talk) 17:58, 11 March 2014 (UTC)
- I would go with :award received (P166): Nobel Peace Prize (Q35637) with point in time (P585): 2011 Filceolaire (talk) 16:57, 11 March 2014 (UTC)
- I agree with Filceolaire and 141.6.11.17 that the first option is best. It keeps the data simple and uniform. --Jakob (talk) 19:03, 11 March 2014 (UTC)
fwiw, I have a bot request to populate this data for the ongoing Paralympics. Wikidata:Requests for permissions/Bot/MedalBot. I am happy to follow the consensus of this discussion (and fix all existing items which dont follow the agreed upon structure). For sports events, it would be nice to include a link to the item which represents the deepest node of the 'Wikipedia' tree. e.g. The award on Henrieta Farkašová (Q5715883) should link to Alpine skiing at the 2010 Winter Paralympics – Women's Super-G (Q4735586) - Q4735586 is useless for most data queries, and the depth in Wikipedia is different for World Competitions vs O/Paralympics vs other competitions, but it is the node which will contain the most useful prose about the award granted, and it is the link found in the infobox on en:Henrieta Farkašová. John Vandenberg (talk) 22:53, 11 March 2014 (UTC)
- Ok what I take from this is that there is no clear answer as to whether award received (P166): Nobel Peace Prize (Q35637) - point in time (P585): 2011 or award received (P166): 2011 Nobel Peace Prize (Q4622018) should be used. If the second is used though then it should be ensured that 2011 Nobel Peace Prize (Q4622018) in itself has instance of (P31): Nobel Peace Prize (Q35637) - point in time (P585): 2011 (or possibly an alternative to P31).
- field of work (P101) is a sidetrack in this case. I only used it as an example since it was used for some of the people awarded the ig-nobel prize. /André Costa (WMSE) (talk) 09:59, 13 March 2014 (UTC)
Category namespace[edit]
As far as I know this project does not havee a namespace called Category. Is it possible to create one? Greetings and salutations, 151.40.249.210 07:57, 11 March 2014 (UTC) (KlaasV)
- There is a category namespace here: see Special:AllPages/Category:. --Jakob (talk) 12:04, 11 March 2014 (UTC)
- Seems they are all administrative. I mean categories like we have in Wikipedia and (nearly?) all other projects of Wikimedia, e.g. Wikidata:Category:Borough of New York etc. 151.40.249.210 12:35, 11 March 2014 (UTC)
- Why? What would you use it for? The proposal is for Wikidata to have a 'Query' namespace which will provide most of the functionality you are probably looking for but this is still under development. 86.6.107.229 13:04, 11 March 2014 (UTC)
- Category:Boroughs of New York City (Q8307446)? Multichill (talk) 22:20, 11 March 2014 (UTC)
- Why? What would you use it for? The proposal is for Wikidata to have a 'Query' namespace which will provide most of the functionality you are probably looking for but this is still under development. 86.6.107.229 13:04, 11 March 2014 (UTC)
- Seems they are all administrative. I mean categories like we have in Wikipedia and (nearly?) all other projects of Wikimedia, e.g. Wikidata:Category:Borough of New York etc. 151.40.249.210 12:35, 11 March 2014 (UTC)
Potentially useful database with uncertain copyright status[edit]
I've found this database, seems like it could be quite useful. It claims that it's copyrighted (see the bottom of the page), but it also claims that the data is taken from National Bridge Inventory (Q6971123), which was compiled by Federal Highway Administration (Q800112), which is a division of the United States government and should thus be in public domain. Hopefully someone here knows what to make of this... --Jakob (talk) 17:50, 11 March 2014 (UTC)
- Don't use this website to source data but directly the Federal Highway Administration (Q800112) database. Snipre (talk) 09:19, 12 March 2014 (UTC)
- @Snipre: The original data is not exactly readable (example). --Jakob (talk) 11:54, 12 March 2014 (UTC)
- @Jakec: Just use the manual (see here) to extract the informations. This is a good example for bot work: just identify the existing birdge articles in wp and link each article with the ID in the database and after defining the data extraction code, it is possible to extract and directly import in wikidata everything. That's typically the main objective of wikidata through its machine readable structure. Snipre (talk) 18:18, 12 March 2014 (UTC)
- @Snipre: The original data is not exactly readable (example). --Jakob (talk) 11:54, 12 March 2014 (UTC)
Infobox mappings[edit]
I created this collection of infobox mappings mostly for users of the harvest_template script, but others might find the pairings of properties/parameters useful for other kinds of bots as well. An example: death_cause P509 for Template:Infobox person (Q6249834). There aren't many of them yet but I plan to add more in the coming days.--Underlying lk (talk) 08:27, 12 March 2014 (UTC)
Undeletion redux[edit]
I see that the Wikidata notability guidelines have been revised, and now include "refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references". Accordingly, I request that Q15136093 be undeleted and restored in full. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 12 March 2014 (UTC)
- Don't mean to be rude, but if you're notable then why are there no Wikipedia articles in any of the 270 or so languages? There's a bit of a conflict of interest in this request seeing as the item is about you, so I've restored it (so others can see it) and would like others to give feedback on whether it should be kept and whether it is actually notable. Either way, it can't contain the user page links that were there as they are specifically forbidden in criteria 1. Also the fact that the item would then look like it breaks bullet point 4 of criteria 1 may be a problem. Cheers. Del♉sion23 (talk) 08:48, 13 March 2014 (UTC)
- I was given to understand that the criterion I quoted obviated the need for a Wikipedia article; also, that Wikidata does not have a CoI requirement like (en.)Wikipedia's. Furthermore it's clear that only one of the criteria need be met, not all of them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 14 March 2014 (UTC)
- «main goals: to centralize interlanguage links across Wikimedia projects and to serve as a general knowledge base for the world at large.» Why do you think that Andy Mabbett (Q15136093) is notable? --ValterVB (talk) 18:54, 13 March 2014 (UTC)
- I'm a fan of Andy and I think he's a great Wikipedian, but I'd be loth to establish a precedent for anyone who wants to create an item about himself. He might indeed be notable, but the revised policy requires "serious and publicly available references", and the item currently doesn't include any.--Underlying lk (talk) 21:03, 13 March 2014 (UTC)
- Strictly; the criterion does not say they must be included; merely exist Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 14 March 2014 (UTC)
- I'm terribly sorry, but authoring one book on Pink Floyd does not make someone notable unless it has been found important enough to warrant an article on any Wikipedia. ElfjeTwaalfje (talk) 19:27, 14 March 2014 (UTC)
- Nowhere did I claim that (and incidentally I've authored two, half of a third (in three editions), and sections to two others). I refer to you to my comment about Wikipedia, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 14 March 2014 (UTC)
- While I appreciate your efforts for Wikipedia, this seriously looks like a en:WP:POINT action to prove that the current guidelines are not watertight. ElfjeTwaalfje (talk) 19:48, 17 March 2014 (UTC)
- Not in the least. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 18 March 2014 (UTC)
- While I appreciate your efforts for Wikipedia, this seriously looks like a en:WP:POINT action to prove that the current guidelines are not watertight. ElfjeTwaalfje (talk) 19:48, 17 March 2014 (UTC)
- Nowhere did I claim that (and incidentally I've authored two, half of a third (in three editions), and sections to two others). I refer to you to my comment about Wikipedia, above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 14 March 2014 (UTC)
- Because "[it] can be described using serious and publicly available references". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 14 March 2014 (UTC)
- I'm a fan of Andy and I think he's a great Wikipedian, but I'd be loth to establish a precedent for anyone who wants to create an item about himself. He might indeed be notable, but the revised policy requires "serious and publicly available references", and the item currently doesn't include any.--Underlying lk (talk) 21:03, 13 March 2014 (UTC)
I see no problem with this item. TomT0m (talk) 20:25, 17 March 2014 (UTC)
- While I was initially suspicious, the authority control statements (VIAF et al) would qualify him in my mind. They are serious and publically available, and show that he's listed on other, authoritative databases. They also confirm that Andy really exists as a material entity (for the sake of precedence rather than doubting the reality of his existence). - AdamBMorgan (talk) 13:46, 18 March 2014 (UTC)
This is not a unique case at all. People create items about themselves constantly. I think that it is a serious problem with criterion 2 that we never defined what we consider to be a "serious and publicly available reference" (see e.g. Wikidata talk:Notability#Criterion 2). As there are some "publicly available references" about everybody who has e.g. a Facebook account and every garage band there once was an article about in the local indie music magazine, we'll probably have to find some way to easily and clearly measure what we consider to be a "serious reference" and how many how serious references we need to have an item. --YMS (talk) 14:00, 18 March 2014 (UTC)
-
- You seem to be under the misapprehension that the article in question relies on "e.g. a Facebook account" to satisfy our notability criteria; as others have noted above, it does not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 26 March 2014 (UTC)
- Furthermore, the user really wants to add the interwiki. I told him to stop edit warring and wait for this discussion to be over, but he does not seem to care about it. I consider this another case of self promotion that could turn into a bad precedent. Unfortunately, right now I have no time to do a proper follow up. Andreasm háblame / just talk to me 18:25, 25 March 2014 (UTC)
- I'm not sure. There do appear to be links to GND and other databases, so perhaps this isn't a WP:HOLE case, but I strongly oppose this apparent self-promotion. Just because we don't have a COI guideline doesn't mean that people should make COI pages. I've also removed the user page link as self-promotion and an invalid link per WD:N and also replaced the commons link with Commons category (P373) in the statements section. --Jakob (talk) 21:51, 25 March 2014 (UTC)
- As I've just asked you on your talk page (before seeing this); please cite the exact text from WD:N which prohibits such a link (as a statement, which is how it is used in this case, and not as evidence of notability). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 26 March 2014 (UTC)
- Your first edit summary didn't say which discussion (and this discussion was not about the matter over which you reverted me); and you ignored each of my two attempts to raise the matter with you, on your talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 26 March 2014 (UTC)
- I'm not sure. There do appear to be links to GND and other databases, so perhaps this isn't a WP:HOLE case, but I strongly oppose this apparent self-promotion. Just because we don't have a COI guideline doesn't mean that people should make COI pages. I've also removed the user page link as self-promotion and an invalid link per WD:N and also replaced the commons link with Commons category (P373) in the statements section. --Jakob (talk) 21:51, 25 March 2014 (UTC)
New RFC: Organizing statements, sitelinks, and external identifiers[edit]
I have started a Request for Comments on how to organize statements, sitelinks, and external identifiers. Hopefully the feedback gathered can help with the UI redesign.--Micru (talk) 12:12, 13 March 2014 (UTC)
Obama is not African American?[edit]
I'm adding a link to the talk page of Barack Obama (Q76) here since this is one of the showcase items: some time during the last few weeks, the ethnic group (P172) of Obama was changed from 'African-American' to 'Irish American' and 'Luo people of Kenya and Tanzania'.--Underlying lk (talk) 21:51, 13 March 2014 (UTC)
- Removed the second. The first is interesting; the source does say that Barrack Obama's great-great-great-great grandfather was Irish. That could remain there, but African American should be added with a higher ranking. Ajraddatz (Talk) 21:54, 13 March 2014 (UTC)
- He does not have Afro American ethnicity. Afro American are a specific group descended from africans and europeans and living in the USA since before the civil war. Michelle Obama and her family are Afro Americans. Barack Obama has very little connection with this group.
- Neither of his parents are from this ethnicity.
- He was not brought up nor attended school in an Afro American area (First he lived in Indonesia, then in Hawaii with his white mother and grandmother).
- The Irish American ethnicity is sourced. The Luo ethnicity is well established for his father. His effort to establish a connection with his family in africa (described in his book 'Dreams of my Father') could support this. The only support for calling him Afro American seems to be the habit in the USA of applying this label to anyone who looks a bit black and the fact that he lived in an Afro American area of chicago after graduating from Harvard Filceolaire (talk) 01:04, 15 March 2014 (UTC)
- Just checked the talk page of Barack Obama (Q76) and I see Underlying Ik has a source for Obama self identifying as Afro American so I accept that that is a good source for ethnicity. Source added to the statement. Marked 'preferred'. Filceolaire (talk) 01:14, 15 March 2014 (UTC)
- Thanks for the insight. Could you find any source for the Luo ethnicity? If they exist then that could definitely be there at a normal rank. Ajraddatz (Talk) 01:31, 15 March 2014 (UTC)
- I'm sure I could get a source for his fathers ethnicity but I think I would have to get hold of 'Dreams of my Father' to get a source that Pres. Obama sees himself as a Luo. Maybe some day. Filceolaire (talk) 10:17, 15 March 2014 (UTC)
- Thanks for the insight. Could you find any source for the Luo ethnicity? If they exist then that could definitely be there at a normal rank. Ajraddatz (Talk) 01:31, 15 March 2014 (UTC)
- Just checked the talk page of Barack Obama (Q76) and I see Underlying Ik has a source for Obama self identifying as Afro American so I accept that that is a good source for ethnicity. Source added to the statement. Marked 'preferred'. Filceolaire (talk) 01:14, 15 March 2014 (UTC)
- Is there a source supporting the requirement that Afro-Americans be descended from people living in the USA before the civil war? English Wiktionary defines the term as "A native or resident of the United States (an American) who is of African heritage," and the en:WP article has similar wording, notwithstanding the article's correct emphasis on the long history of African Americans. Peter Chastain (talk) 01:32, 19 March 2014 (UTC)
- He does not have Afro American ethnicity. Afro American are a specific group descended from africans and europeans and living in the USA since before the civil war. Michelle Obama and her family are Afro Americans. Barack Obama has very little connection with this group.
Proposed optional changes to Terms of Use amendment[edit]
There is no non-JavaScript facility to remove site links[edit]
Hello, recently I have some difficulty moving incorrectly-assigned Wikipedia page sitelink from old (incorrect) Wikidata entry to the correct one. In order to do that, I have to remove the sitelink at the original entry first.
When I clicked [edit] at the sitelink entry on Wikidata page of the article, it links to Special:SetSiteLink page. But there's no "Remove site link" button on that page, submitting the form with an empty sitelink field also have no effect.
How to reproduce:
- Visit https://www.wikidata.org/wiki/Q79746 with JavaScript turned off (as either logged-in or anonymous user).
- Click [edit] on the "thwiki" sitelink entry.
- This will link to https://www.wikidata.org/wiki/Special:SetSiteLink/Q79746/thwiki
- You'll see that there's no option to remove the sitelink entry. If you just cleared the sitelink textbox and clicked submit ("Set the site link") button, it will simply redirect back to the Wikidata entry page and that sitelink entry was still left intact.
Nvtj (talk) 11:44, 14 March 2014 (UTC)
- I can confirm that this bug exists. Unfortunately, this page is not the best to report bugs. WD:DEV is better. Ping: Lydia Pintscher (WMDE). Matěj Suchánek (talk) 20:16, 14 March 2014 (UTC)
- I've filed it at bugzilla:62707. --Lydia Pintscher (WMDE) (talk) 12:06, 16 March 2014 (UTC)
Error when adding commonscat[edit]
Hi. I frequently get the error Malformed input: xxx when adding a commonscat to an item. Someone who knows why? Trijnstel (talk) 22:02, 14 March 2014 (UTC)
- I get this error often too when trying to add Commons category (P373). --Infovarius (talk) 18:41, 15 March 2014 (UTC)
- I can reproduce it by adding a trailing space after the category name. If I remove the space after the category name, then I can save it without any error.--Micru (talk) 18:47, 15 March 2014 (UTC)
- Can you two confirm please if the issue Micru mentioned is also the case for you? If so please open a bug on bugs.wikimedia.org. Thanks! :) --Lydia Pintscher (WMDE) (talk) 12:07, 16 March 2014 (UTC)
FOSS Outreach Program for Women Summer Project Idea[edit]
Hi all, I’m putting together a proposal for the FOSS Outreach Program for Women project, and I’m hoping to get some feedback from the community before I finalize my submission next week. I’d like to look at ways to improve outreach and understandability for new users to the site, particularly through use of visuals and diagrams. The one diagram available in the glossary page for claims and statements (File:Wikidata statement.svg) clearly presents the terminology and shows how the different parts fit together. I propose to create similar diagrams to explain the concepts such as entity, item, property, query, page, namespace, and similar terms defined in the Glossary page. These could also convey how these concepts relate to other websites, people, places, and hopefully help to explain the difference between structured and unstructured data. My idea for now is to focus on the basics, so that someone with limited background in structured data can understand what’s going on.
For example see the sample diagram to show the pages, different namespaces, and relation to wikipedia articles, following the example of London.
Other areas which I’d like to look at throughout the summer include use case scenarios for access, editing, exporting/use of data, creating infographics for use case scenarios to guide a new user through the steps. Ideally I’d like to then test these with some sample users, and revise as necessary.
Please let me know if you have any advice on what else could be a good project to work on!
thanks,
Emily 00:41, 15 March 2014
- Better documentation with pretty pictures always get a +1 from me :-)
- I don't really get File:Wikidata glossary - pages.svg. The Wikidata namespace here is a meta namespace not part of Wikidata as a database. This diagram confuses me.
- Maybe this can be part of a bigger documentation improvement? I don't like how part of the documentation is on meta and part of the documentation is on this wiki. Multichill (talk) 12:57, 15 March 2014 (UTC)
-
- Thanks, that is really helpful! The diagram definitely needs more work - I was trying to show the relationship between the pages about database entries and other namespaces, but maybe there needs to be a whole other diagram to describe different namespaces. Emaemura (talk) 14:50, 17 March 2014 (UTC)
Relationships between Wikimedia category pages in Wikidata[edit]
While waiting for comment/approval of user:MedalBot, I have been working on a tool to monitor Wikipedia activity related to an international event (e.g. the Paralympics). The current code is at User:JVbot/wikipedia-sync.py (If you want to see it 'working', I suggest running "wikipedia-sync.py -qid:1045816 -once" as I have been working on the related Wikidata items for a week now, on and off).
It currently suggests when a new Wikipedia category should be created, based on category membership of the same category on other languages. For example, on Category:Alpine skiers at the 2014 Winter Paralympics (Q15909926), it reports that Christoph Kunz (Q1085367),Philipp Bonadimann (Q14530680),Markus Salcher (Q15919654) would all be suitable members of a category on German Wikipedia. However, there are two issues:
- it doesn't yet guess whether German Wikipedia wants Category:Alpine skiers at the 2014 Winter Paralympics (Q15909926) ; the category system on each Wikipedia is slightly different, and the community has different goals.
- it cant (easily) guess what the new Wikipedia category for Category:Alpine skiers at the 2014 Winter Paralympics (Q15909926) on German Wikipedia should be called.
Both of those could be 'solved' by linking Category:Alpine skiers at the 2014 Winter Paralympics (Q15909926) to Category:Alpine skiers at the 2010 Winter Paralympics (Q6989544). If German Wikipedia did have that category for the 2010 Paralympics, they probably want the same category for the 2014 Paralympics, and replacing '2010' with '2014' in the category name is a easy solution to the second issue above.
I could solve this problem by adding a lot of per-Wikipedia category knowledge to the bot, but it would be nice if the link between Category:Alpine skiers at the 2014 Winter Paralympics (Q15909926) to Category:Alpine skiers at the 2010 Winter Paralympics (Q6989544) was recorded in Wikidata in a consistent manner. John Vandenberg (talk) 00:51, 15 March 2014 (UTC)
-
- Maybe category combines topics (P971) is useful for you. I added it to the two categories. Multichill (talk) 12:46, 15 March 2014 (UTC)
- You could also take a look to Catgraph, which could help you find out the category structure. At the moment there is nothing relating categories other than p971 since those kind of relations are project specific. A nice feature would be to aggregate the upper and lower categories of all Wikipedias on each Wikidata category item.--Micru (talk) 13:17, 15 March 2014 (UTC)
- category combines topics (P971) is useful, but it isnt a good solution. Ideally we should be able to say that
- Category:Alpine skiers at the 2014 Winter Paralympics (Q15909926) and Category:Alpine skiers at the 2010 Winter Paralympics (Q6989544) are both instance of (P31) Category:Paralympic alpine skiers by year (Q8713614);
- Category:Alpine skiers at the 2014 Winter Paralympics (Q15909926) is a part of (P361) Category:Alpine skiing at the 2014 Winter Paralympics (Q15925239), and is part of Category:Competitors at the 2014 Winter Paralympics (Q15915754);
- Category:Competitors at the 2014 Winter Paralympics (Q15915754) is an instance of Category:Paralympic competitors by year (Q8713879); etc.
- It would be great to record, in Wikidata, the structure of Wikipedia categories across all languages. John Vandenberg (talk) 15:38, 15 March 2014 (UTC)
- I would better use subclass of (P279) for 1 and 3. --Infovarius (talk) 18:49, 15 March 2014 (UTC)
- Categories are neither subclasses nor instances (options 1 and 3) of other categories (as is trivially evidenced by the fact that they are instances of categories). What should be done is by connecting the categories to their actual topics.
- As for the structure of all categories (option 2), I'd oppose this--category structures will differ across the wikis. It also induces a ton of maintenance upkeep, trying to agree with the wikis on which categories are subcategories of others. category combines topics (P971) combined with the relations established by topic's main category (P910)/category's main topic (P301) and instance of (P31)/subclass of (P279) would seem to do the job that you want with option 2. --Izno (talk) 19:31, 15 March 2014 (UTC)
- I would better use subclass of (P279) for 1 and 3. --Infovarius (talk) 18:49, 15 March 2014 (UTC)
- I think we should get rid of most of the Category items by combining them with their main topic items - both deal with the same topic. This will require changes to the software (See bugzilla 52971) so in the meantime we should link the main topic items, using 'subclass of' etc., and link the categories to these main topic items, using 'Category main topic' etc. IMHO Filceolaire (talk) 07:30, 16 March 2014 (UTC)
- I don't think that's going to happen. Multichill (talk) 19:32, 20 March 2014 (UTC)
Sitelinks to closed wikis[edit]
Do we want to keep links to existant articles in closed wikis or do we plan to remove them? --Infovarius (talk) 18:55, 15 March 2014 (UTC)
- @Ladsgroup: Why are you removing those links? The wikis are no longer editable, but that should not impact whether we keep links for those wikis. --Izno (talk) 19:36, 15 March 2014 (UTC)
- Ladsgroups answer in hir user_talk. -- Lavallen (talk) 19:42, 15 March 2014 (UTC)
- It is unfortunate that his bot breaks from it, but IMO those links should stay if possible. They are closed to editing but the content is still there. Ajraddatz (Talk) 22:58, 15 March 2014 (UTC)
- It's better to have a clear policy about it, Isn't it? Amir (talk) 01:25, 16 March 2014 (UTC)
- There is a clear policy. It's an article on a wikipedia so it can have sitelinks. If it crashes your bot then the solution is to fix the bot, not to break the sitelinks. Filceolaire (talk) 07:20, 16 March 2014 (UTC)
- Also see Talk:Q6293548, especially the "angwikisource, htwikisource" section. Though Special:RecentChanges (Q6293548) is a bit of a special case, as this special page exists on every Wikimedia project, but hardly has any use in a closed project. --YMS (talk) 14:07, 18 March 2014 (UTC)
- There is a clear policy. It's an article on a wikipedia so it can have sitelinks. If it crashes your bot then the solution is to fix the bot, not to break the sitelinks. Filceolaire (talk) 07:20, 16 March 2014 (UTC)
- It's better to have a clear policy about it, Isn't it? Amir (talk) 01:25, 16 March 2014 (UTC)
- It is unfortunate that his bot breaks from it, but IMO those links should stay if possible. They are closed to editing but the content is still there. Ajraddatz (Talk) 22:58, 15 March 2014 (UTC)
- Ladsgroups answer in hir user_talk. -- Lavallen (talk) 19:42, 15 March 2014 (UTC)
[edit]
Hey :)
I had announced that we'll be making changes to how ranks influence the property parser function, Lua and in the future query results. (See Wikidata:Project chat/Archive/2014/03#rank related changes for more details.) The changes are ready for deployment now. We plan to have them go live on Wikisource and Wikivoyage on 25th of March and on Wikipedia on 27th of March.
Cheers --Lydia Pintscher (WMDE) (talk) 14:10, 16 March 2014 (UTC)
Calendar systems annotations[edit]
Why on some items, like John B. Calhoun (Q4251066) Gregorian annotation on dates are present and for example in Lukas Pawlikowski (Q15284485) not? --Rezonansowy (talk) 11:42, 17 March 2014 (UTC)
- Probably because by 1997 the Julian calendar was no longer being used anywhere, so it would be redundant to specify that it is a Gregorian date.--Underlying lk (talk) 12:03, 17 March 2014 (UTC)
- But, on Barack Obama (Q76) we have the same appearance. --Rezonansowy (talk) 12:18, 17 March 2014 (UTC)
- Underlying lk is correct. It is displayed whenever there could be doubt about it. Julian is not display before a specific data, and Gregorian is not displayed after a specific date. In the time in between, both are displayed. If someone uses Gregorian calendar before its introduction, Gregorian will be displayed though (this is used as a calendar for precolumbina history usually, IIRC). I hope that makes sense. --Denny (talk) 15:59, 18 March 2014 (UTC)
- @Underlying lk, Denny: Just take a look on Barack Obama (Q76) birth date, it's August 4 1961 and there's no such annotation, so it's confusing. --Rezonansowy (talk) 12:58, 19 March 2014 (UTC)
- There shouldn't be one, if you read the article w:Julian calendar, the last country to use it switched to Gregorian on 1 March 1923, so after that date there is no need to point out that a date is Gregorian.--Underlying lk (talk) 13:30, 19 March 2014 (UTC)
- I see, but see Sandbox (Q4115189), even on March 2 1929 we have this annotation, only after the 1930 it disappears, so that's not 1923 I think. Maybe it's a bug? --Rezonansowy (talk) 15:56, 19 March 2014 (UTC)
- There shouldn't be one, if you read the article w:Julian calendar, the last country to use it switched to Gregorian on 1 March 1923, so after that date there is no need to point out that a date is Gregorian.--Underlying lk (talk) 13:30, 19 March 2014 (UTC)
- @Underlying lk, Denny: Just take a look on Barack Obama (Q76) birth date, it's August 4 1961 and there's no such annotation, so it's confusing. --Rezonansowy (talk) 12:58, 19 March 2014 (UTC)
Bot for items descriptions[edit]
Have you heard about Reasonator? This fancy tool automatically generates a description for desired item, example: Johann Sebastian Bach (Q1339) - Reasonator output. We can setup a bot to filling empty descriptions with Reasonator. What do you think? --Rezonansowy (talk) 12:15, 17 March 2014 (UTC)
- You probably have something mixed up. Reasonator is just a tool that accesses the data that is already on Wikidata. Bots don't need a visual interface to edit the data. But you are right. It is certainly a most "fancy" tool. And in the case of Mr. Bach we have even surpassed Wolfram Alpha (especially because we are multilingual) (https://www.wolframalpha.com/input/?i=Johann+Sebastian+Bach). --Tobias1984 (talk) 17:01, 17 March 2014 (UTC)
- For a little while now, Reasonator is able to create texts based to the Wikidata statements, which is a great feature. User:Magnus Manske heavily extended his Autodesc approach there, but the original script is still available and able to automatically add descriptions in search results etc. These Auto-descriptions could be inserted permanently by bots. User:Bene* once planned to do something like this. However, I don't think it should be done fully automatically, as the results sometimes are great, and sometimes crap. I introduced a similar feature in my Label Collector tool, so an description that is automatically generated from the statemenents is proposed for many items (in the "[d]" line of the preview section), but it has to be actively reviewed by a human (who can also edit it) before saving. --YMS (talk) 17:24, 17 March 2014 (UTC)
- For now, we can use just only for items about persons (with instance of human), so it shouldn't be a problem. I post this proposal because the appearance of Reasonator is very predictable. Just test this with other items. In some cases additional data in description would be welcomed, but the basic info is better than nothing. --Rezonansowy (talk) 22:27, 17 March 2014 (UTC)
- I'd like to bring to the table the notion that "static" descriptions should only be added to items where an automatic one would fail, for example, when the significance of the item cannot (yet) be encoded in statements. The default case should be an automated description, dynamically generated. IMHO that will cover >90% of cases nicely. City in China? County of Texas? U.S. geneticist? Why type those in, bot-assisted or not! An automated, dynamic description will not only prevent thousands of mind-bogglingly dull work be human editors, but also improve with changes to both algorithms and statements. In fact, I use the absence of an autodesc-generated description as an indicator for missing essential statements. Just because items may have a manual, static description doesn't mean we absolutely have to fill them in everywhere. --Magnus Manske (talk) 23:23, 17 March 2014 (UTC)
- This page indicates how to add
autodesc.jsto your common.js to enable that capability in a user environment. LaddΩ chat ;) 01:00, 18 March 2014 (UTC)- autodesc.js is extremely useful, both for readers and editors. Can we add it to MediaWiki:Common.js?--Underlying lk (talk) 04:34, 18 March 2014 (UTC)
- I totally agree with you that autodesc is extremely useful (and I like Magnus' idea to have something like this by default and only write static descriptions where necessary). However, it's a very expensive script, easily resulting in several hundred API requests on a search result page, which may completely block your internet connection or other browser resources for quite a while. This is why I don't think it should be automatically enabled for everybody. Having it as an (optional) gadget would be an idea, as long as no similar solution is implemented in Wikidata itself. --YMS (talk) 10:28, 18 March 2014 (UTC)
- autodesc.js is extremely useful, both for readers and editors. Can we add it to MediaWiki:Common.js?--Underlying lk (talk) 04:34, 18 March 2014 (UTC)
- @Magnus Manske: Could you add an option in
autodesc.jsto always show automatic descriptions in search please? Thanks. — Ayack (talk) 09:34, 18 March 2014 (UTC)-
-
- @YMS: Then it should definitely be a gadget because it makes a huge impact on the user experience. I created a proposal to that effect on Wikidata talk:Tools.--Underlying lk (talk) 12:36, 18 March 2014 (UTC)
-
-
- This page indicates how to add
- I'd like to bring to the table the notion that "static" descriptions should only be added to items where an automatic one would fail, for example, when the significance of the item cannot (yet) be encoded in statements. The default case should be an automated description, dynamically generated. IMHO that will cover >90% of cases nicely. City in China? County of Texas? U.S. geneticist? Why type those in, bot-assisted or not! An automated, dynamic description will not only prevent thousands of mind-bogglingly dull work be human editors, but also improve with changes to both algorithms and statements. In fact, I use the absence of an autodesc-generated description as an indicator for missing essential statements. Just because items may have a manual, static description doesn't mean we absolutely have to fill them in everywhere. --Magnus Manske (talk) 23:23, 17 March 2014 (UTC)
- For now, we can use just only for items about persons (with instance of human), so it shouldn't be a problem. I post this proposal because the appearance of Reasonator is very predictable. Just test this with other items. In some cases additional data in description would be welcomed, but the basic info is better than nothing. --Rezonansowy (talk) 22:27, 17 March 2014 (UTC)
- For a little while now, Reasonator is able to create texts based to the Wikidata statements, which is a great feature. User:Magnus Manske heavily extended his Autodesc approach there, but the original script is still available and able to automatically add descriptions in search results etc. These Auto-descriptions could be inserted permanently by bots. User:Bene* once planned to do something like this. However, I don't think it should be done fully automatically, as the results sometimes are great, and sometimes crap. I introduced a similar feature in my Label Collector tool, so an description that is automatically generated from the statemenents is proposed for many items (in the "[d]" line of the preview section), but it has to be actively reviewed by a human (who can also edit it) before saving. --YMS (talk) 17:24, 17 March 2014 (UTC)
@Ayack: Option added, see (and use) here. --Magnus Manske (talk) 14:08, 19 March 2014 (UTC)
- @Magnus Manske: Great! Thanks a lot! — Ayack (talk) 14:59, 19 March 2014 (UTC)
@Magnus Manske: But in case of >10% we should add an option to allow users to edit this. Could you support my proposal? Automatic descriptions would be very handy, but should be bot-assisted. --Rezonansowy (talk) 16:05, 19 March 2014 (UTC)
ask for technical support for multlilingual MediaWiki pages[edit]
Heya,
can somebody give us some technical support für our project page Wikipedia:Neiße on commons please? The page should be in czech, polish, german and upper sorbian in the way pagetranslations are organized here in Wikidata. If german version gets changed, there should the automatic system inform people, that there are outstanding translations and so on :) (I know it here with seperate fields). That would be very nice. Base language is german. Thank you for every hint, Conny (talk) 19:31, 17 March 2014 (UTC).
- @Conny: Wikidata doesn't have anything to do with that, that is handled on Commons. You will find the instructions here: Commons:Preparing a page for translation. I hope it helps!--Micru (talk) 23:46, 17 March 2014 (UTC)
What is the difference in the Commons site and Commons Category?[edit]
I am wondering what is the difference with setting the commons category as a property and setting the wikisite for commons? --Napoleon.tan (talk) 02:07, 18 March 2014 (UTC)
Wikiquote notability[edit]
I am proposing that we add Wikiquote to Wikidata:Notability criterion 1:
"It contains at least one valid sitelink to a Wikipedia, Wikivoyage, Wikisource, or Wikimedia Commons page."
Unlike Wikisource, Wikiquote is much more straightforward (see Wikidata:Wikiquote for details). --Rschen7754 04:32, 18 March 2014 (UTC)
Support Filceolaire (talk) 12:01, 18 March 2014 (UTC)
Support I don't know it's really necessary to make an RFC for this, anyway I support it Amir (talk) 12:17, 18 March 2014 (UTC)
Support of course. Tpt (talk) 12:58, 18 March 2014 (UTC)
Support --Paperoastro (talk) 13:06, 18 March 2014 (UTC)- I don't like the idea of going through this every time we get support for a new project. Unless anyone objects, I'll be bold and replace this sentence with "It contains at least one valid sitelink to a page on a Wikimedia project." in the notability policy. --Jakob (talk) 13:19, 18 March 2014 (UTC)
- Yay for straight-forward. I agree with Jakec - there are special cases with Wikisource, but the suggested wording already says one valid sitelink on a Wikisource page and then specifies exemptions. Instead of adding each project to the notability policy, we should have a general statement (as worded by Jakec above) and then specify the exceptions. Kind of like what we already do, but without the need for a vote to expand the policy wording every time. Ajraddatz (Talk) 17:33, 18 March 2014 (UTC)
- Well, considering our track record with sister project deployments, we should be forced to re-evaluate our notability policies every time we have a new project. Keep in mind that we barely got anything passed last time; I had to send out at least 2-3 rounds of spam messages before we got anything. And going forward, looking at the projects left, the exceptions will soon become the norm. --Rschen7754 17:36, 18 March 2014 (UTC)
- Then perhaps we should be discussing the exceptions, rather than the current system of voting on every new project name that is added. It is the exceptions that are the important part, and the discussions should reflect that imo. Ajraddatz (Talk) 17:44, 18 March 2014 (UTC)
- Well, half of those plans haven't been written yet, see Wikidata:Sister projects. Of course, you and anyone else are more welcome to participate in drafting the actual guidelines for inclusion and mapping, which is where the real need for input is, before the community approves the guidelines. And considering that all the projects left are now Wikinews, Wikibooks, Wikiversity, Meta, MediaWiki, Incubator, Wikispecies... where all but one will need to have special mappings... --Rschen7754 18:16, 18 March 2014 (UTC)
- If those discussions were organized in any comprehensible way then I gladly would. As it is, I don't think it's worth the limited time I spend on Wikimedia trying to figure out just what those long, disorganized pages are trying to say. But you're missing my point - I just want to remove the need to add each new project to the first line of the policy individually. We can still discuss exceptions, but this when when an obvious project comes along we don't need to vote to add another name to the list at the start, which is just as broad with or without it. Ajraddatz (Talk) 20:00, 18 March 2014 (UTC)
- Well, the only obvious project left is Wikispecies. And to reply to your comment here, I would have to strongly oppose anything of that form. Wikispecies will be straightforward, but the next project after Wikiquote is Wikinews. Yes, some stories will have a clear mapping to events, but what about others? Do we create items for those? Do we know that stories are consistent across language versions? For example, en.wikinews on the front page doesn't mention Crimea, or the Malaysian Airlines plane. Do we link the Portals regarding specific topics to the items in question, even though it's cross-namespaces? How about Wikibooks and Wikiversity? Do we create items for all of their subpages? How do we handle the conflict across language versions, since there is no form of standardization across language versions? These are the questions that we must answer BEFORE we deploy to projects, NOT AFTER. This sort of enwiki-centered proposal is definitely not we want to pass at all. It is hard enough to get people to STOP, and THINK before they start running the IW link remover bots on all sorts of wikis (as happened with even the Wikisource deployment, as well as the Commons one), and doing some blanket approval crap like you are proposing gives us no means whatsoever to do anything against it. When we make proposals like this, we must not think of "oh, these discussions are a PITA" but we must think of what is best for the project, and think of the future, not of the "now" and what is "most convenient". --Rschen7754 00:00, 19 March 2014 (UTC)
- I can't say I agree, but if you think that individually adding each project name to the first line of the page will prompt discussion and people actually following the rules... then I hope you're right. IMO it's not too much of an enwiki-centric perspective either. I am rarely (never?) accused of having one of those. Ajraddatz (talk) 05:26, 20 March 2014 (UTC)
- Well, the only obvious project left is Wikispecies. And to reply to your comment here, I would have to strongly oppose anything of that form. Wikispecies will be straightforward, but the next project after Wikiquote is Wikinews. Yes, some stories will have a clear mapping to events, but what about others? Do we create items for those? Do we know that stories are consistent across language versions? For example, en.wikinews on the front page doesn't mention Crimea, or the Malaysian Airlines plane. Do we link the Portals regarding specific topics to the items in question, even though it's cross-namespaces? How about Wikibooks and Wikiversity? Do we create items for all of their subpages? How do we handle the conflict across language versions, since there is no form of standardization across language versions? These are the questions that we must answer BEFORE we deploy to projects, NOT AFTER. This sort of enwiki-centered proposal is definitely not we want to pass at all. It is hard enough to get people to STOP, and THINK before they start running the IW link remover bots on all sorts of wikis (as happened with even the Wikisource deployment, as well as the Commons one), and doing some blanket approval crap like you are proposing gives us no means whatsoever to do anything against it. When we make proposals like this, we must not think of "oh, these discussions are a PITA" but we must think of what is best for the project, and think of the future, not of the "now" and what is "most convenient". --Rschen7754 00:00, 19 March 2014 (UTC)
- If those discussions were organized in any comprehensible way then I gladly would. As it is, I don't think it's worth the limited time I spend on Wikimedia trying to figure out just what those long, disorganized pages are trying to say. But you're missing my point - I just want to remove the need to add each new project to the first line of the policy individually. We can still discuss exceptions, but this when when an obvious project comes along we don't need to vote to add another name to the list at the start, which is just as broad with or without it. Ajraddatz (Talk) 20:00, 18 March 2014 (UTC)
- Well, half of those plans haven't been written yet, see Wikidata:Sister projects. Of course, you and anyone else are more welcome to participate in drafting the actual guidelines for inclusion and mapping, which is where the real need for input is, before the community approves the guidelines. And considering that all the projects left are now Wikinews, Wikibooks, Wikiversity, Meta, MediaWiki, Incubator, Wikispecies... where all but one will need to have special mappings... --Rschen7754 18:16, 18 March 2014 (UTC)
- Then perhaps we should be discussing the exceptions, rather than the current system of voting on every new project name that is added. It is the exceptions that are the important part, and the discussions should reflect that imo. Ajraddatz (Talk) 17:44, 18 March 2014 (UTC)
- Well, considering our track record with sister project deployments, we should be forced to re-evaluate our notability policies every time we have a new project. Keep in mind that we barely got anything passed last time; I had to send out at least 2-3 rounds of spam messages before we got anything. And going forward, looking at the projects left, the exceptions will soon become the norm. --Rschen7754 17:36, 18 March 2014 (UTC)
- I think we should start to think of subsidiarity (Q466938) in notability matters, rather than centralizing everything at one point where very few have full understanding of all the problems in every project. (I know for example almost nothing about Wikiquote.)
- I do not think we should discuss this around Wikidata:Notability, but rather around pages like Wikidata:Wikiquote.
- An example of an issue: I think subpages in Wikisource main namespace should be included, when we are ready for it. (Today, we are obviously not even ready for Phase I.) I do not think it is a good idea to discuss when we are ready here at WD:PC or even worse, in a RFC. It's better to discuss that at WD:WS. -- Lavallen (talk) 17:18, 20 March 2014 (UTC)
Support, though I would prefer m:Structured Wikiquote over the current system with local projects + Wikidata. Vogone talk 17:58, 26 March 2014 (UTC)
Topic of work[edit]
Is there a property I can use to provide the topic of a work? E.g. to provide the information that the topic of the book The Mammals of Australia (Q7749829) corresponds to the item Mammals of Australia (Q6745759).
I'd like to link items about city chronicles with the respective items about the cities for example.
If there is no property for this yet, what should it be called? "Topic of work" or "Work documents" or something like that?
One more question: do you think it is a good idea to have a reverse property too? Let me give you an example: The "Chronik von Hechthausen" documents the history of the municipality of Hechthausen. So the item about "Chronik von Hechthausen" should have a property "topic of work: Hechthausen (Q13188396)". But Bornberg (Q893942) is also part of the municipality of Hechthausen and to cover the information that the history of Bornberg (Q893942) is detailed in "Chronik von Hechthausen" too, we would need a separate property. On the other hand that could lead to extremely large amounts of properties on items that are more important than Bornberg (Q893942) or Hechthausen (Q13188396) and are thus described in dozens or hundreds of books. Opinions? --Slomox (talk) 10:00, 18 March 2014 (UTC)
- I'm not sure what these items are. Villages? Could you give them an 'instance of' or 'type of administrative unit' statement so we can generate some automatic descriptions? Filceolaire (talk) 12:07, 18 March 2014 (UTC)
-
- Would subject heading (P921) work for the main query? - AdamBMorgan (talk) 12:52, 18 March 2014 (UTC)
- (edit conflict) @Slomox: for "topic of work" we have subject heading (P921). As for the second question you can use the pair is in the administrative-territorial entity (P131) / contains administrative territorial entity (P150), and then also add type of administrative entity (P132) to each one as Filceolaire suggested. If your book to refers to two items that are part of a third one (the municipality), I would refer only to the main one (since it is implicit that you are referring to the sub-items too), but it is just my personal opinion, there are no guidelines about that.--Micru (talk) 13:01, 18 March 2014 (UTC)
-
- We also have subject of (P805) which is the reverse property of subject heading (P921). Filceolaire (talk) 13:21, 18 March 2014 (UTC)
- @Filceolaire: Please note that subject of (P805) is strictly a statement qualifier, see its creation discussion. It is not the inverse of subject heading (P921). I have clarified its property documentation. LaddΩ chat ;) 22:46, 18 March 2014 (UTC)
- We also have subject of (P805) which is the reverse property of subject heading (P921). Filceolaire (talk) 13:21, 18 March 2014 (UTC)
- Looking at the property, subject heading (P921) looked like a good match of what I searched for at first. But then I looked at the items this is used in and they are almost all fictional works and P921 is used to give subjective statements about the subject of the fictional work. Arrested Development (Q11598) is about incest (Q127683) for example? That's a very awkward and limited "subject heading". But I guess I shouldn't worry about those awkward use cases. The original proposal was about non-fiction works, so the property fits my use case. Thank you!
- Thank you too to Filceolaire and Micru for adding properties on the two items.
- @Micru: If your book to refers to two items that are part of a third one (the municipality), I would refer only to the main one (since it is implicit that you are referring to the sub-items too) That's problematic because this cannot be automatically assumed. Let fictional municipality X contain the four fictional places XA, XB, XC, XD. It's possible that "chronicle of X" describes the history of X, XA, XB and XC but not XD, because XD is detailed in a separate book. Or "chronicle of X" is only about X and not about any of the places at all. But I guess the P921 solution is good enough for me at the moment and I shouldn't worry about this for now.
- Thanks for all answers. --Slomox (talk) 09:35, 19 March 2014 (UTC)
Crimea history[edit]
Crimea would be a good model item to test our historical capabilities. We have:
- The history: history of Crimea (Q2629621)
- The present-day item (but also some history): Autonomous Republic of Crimea (Q756294)
- The soviet item: Crimean Autonomous Soviet Socialist Republic (Q139671)
- The oblast: Crimean Oblast (Q2677944)
- Roman time: Roman Crimea (Q7361934)
- The cherson: Cherson (Q1070397)
- The khanate: Crimean Khanate (Q160440)
and probably some more. How do we model such a complex history? Where should information be stored? --Tobias1984 (talk) 13:24, 18 March 2014 (UTC)
- Thank you for starting this discussion! you missed the current Republic of Crimea (Q15925436) in your little list.
- i think it is best to store informations focussing on the actual topic and not beyond. For example for the current "Russian de facto regime" Republic of Crimea (Q15925436) we should only store information (like population, government info etc) beginning in 2014. All older information go to the Ukrainian Autonomous Republic item (Q756294) and to other items. Wikipedias are of course more free to extent their content with paragraphs about history and future and so on, but on Wikidata we must be more strict. We should try to be as clear as possible. This means not to duplicate data in several more or less related items. It also means not to store information where it does not really belong to (like pre-foundation data). i already sorted out mixed information (like currency, flags, country codes) from the geographical Crimean penisula item Crimean Peninsula (Q7835) to the political items.
- For older Crimean items I don't see many possible problems. But data consistency problems are likely especially for Autonomous Republic of Crimea (Q756294) and Republic of Crimea (Q15925436) because of their "official coexistence" in the next years i think. Holger1959 (talk) 14:57, 18 March 2014 (UTC)
- It is more of a technical question. How should we structure the data across so many items, so that queries (and the Reasonator) can make a sensible timeline of the whole history. Do we create an item for each historical political system? What is the threshold for new items? The most recent change is in itself questionable. Do we really need a separate article for the Republic of Crimea (Q15925436) and perhaps another item for when (or if) they become a part of Russia. On Wikipedia the two periods of soviet membership are grouped together as Crimean Autonomous Soviet Socialist Republic (Q139671). It does seem like it is time to draft even the most basic outline for this. --Tobias1984 (talk) 20:12, 18 March 2014 (UTC)
- My feeling is that Crimea is a geographical area with a long geopolitical story. We want to tell the story of this area geographically speaking, which is mainly a sequence of political status. If we got an item for the goepolitical area, we can create this sequence and used properties like
<Cherson (Q1070397) (. (see the property proposal in generic properties proposal for in sequence qualifier) TomT0m (talk) 21:08, 18 March 2014 (UTC)
)> succeeded by (P156) <Crimean Khanate (Q160440) (
)>
(no label) (Pin sequence) <history of Crimea (Q2629621) (
)>
- My feeling is that Crimea is a geographical area with a long geopolitical story. We want to tell the story of this area geographically speaking, which is mainly a sequence of political status. If we got an item for the goepolitical area, we can create this sequence and used properties like
- It is more of a technical question. How should we structure the data across so many items, so that queries (and the Reasonator) can make a sensible timeline of the whole history. Do we create an item for each historical political system? What is the threshold for new items? The most recent change is in itself questionable. Do we really need a separate article for the Republic of Crimea (Q15925436) and perhaps another item for when (or if) they become a part of Russia. On Wikipedia the two periods of soviet membership are grouped together as Crimean Autonomous Soviet Socialist Republic (Q139671). It does seem like it is time to draft even the most basic outline for this. --Tobias1984 (talk) 20:12, 18 March 2014 (UTC)
Crimea: Ukraine/Russia changes[edit]
we will presumably see some trouble with Ukraine vs Russia changes in regard to country (P17) in a lot of minor topic items for the next time (months/years…)
in the last days I edited some Crimean items which did not have any country property yet. I intentionally did not add P17 (like I usually do for other items), but instead used located on terrain feature (P706) = Crimean Peninsula (Q7835) (Crimean peninsula), and in addition is in the administrative-territorial entity (P131) for more precise location (district/city/town). This way we at least have location data which is 100 % correct and non-controversial, and which can stay independent of political status changes. (I know that clear P17 information would be optimal, but as long as the real situation is unclear …)
Maybe this is a useful idea for other users too. Holger1959 (talk) 14:57, 18 March 2014 (UTC)
- It should be possible to simply add the POV of both sides, and include appropriate sources. I.e. Crimea would be a part of the Russian Federation according to recent proclamations of Russian government bodies, but is a part of the Ukraine according to the Ukrainian constitution or some sources in the Ukrainian government. We certainly don't want to import the discussion about this topic into Wikidata, and should be happy about simply displaying both claims with the appropriate sources.
- If we make a step back, the situation is not unclear. We do not have to decide on the veracity of to what country Crimea belongs. We merely report both sides and their strongest sources. --Denny (talk) 16:07, 18 March 2014 (UTC)
-
- yes, the other possibility would be to add P17 = Ukraine and P17 = Republic of Crimea, both with some clarifying qualifiers, to all items with location Crimea (except some historic items maybe). Maybe you can work this out for Perevalne (Q4350000) as an example? i don't have an idea yet which qualifiers would be good, and if or how this would render. how many items are affected? I guess we have more than 10,000 items with location Crimea (not all with P17 at the moment, many without any statements). and what is needed to not run into constraint violation problems? Holger1959 (talk) 16:23, 18 March 2014 (UTC)
- It might make sense to add both as you say, and use something like country (P17) -> Republic of Crimea (Q15925436) as (P794) list of states with limited recognition (Q199683).--Underlying lk (talk) 16:29, 18 March 2014 (UTC)
- yes, the other possibility would be to add P17 = Ukraine and P17 = Republic of Crimea, both with some clarifying qualifiers, to all items with location Crimea (except some historic items maybe). Maybe you can work this out for Perevalne (Q4350000) as an example? i don't have an idea yet which qualifiers would be good, and if or how this would render. how many items are affected? I guess we have more than 10,000 items with location Crimea (not all with P17 at the moment, many without any statements). and what is needed to not run into constraint violation problems? Holger1959 (talk) 16:23, 18 March 2014 (UTC)
I think currently only Russia has accepted the Referendum. Which property to use for that? approved by (P790)? Probably good to gather that information at Wikidata:Political geography task force. --Tobias1984 (talk) 20:19, 18 March 2014 (UTC)
significant event (P793) and usability[edit]
There are many properties with potentially ambiguous usage, but as far as I'm aware significant event (P793) is the only property that requires reading an extensive talk page documentation before it can be used at all. There are rules for ships, rules for buildings, rules for cars or computers, all with a matching list of items to be used as qualifier, and just explaining them requires extensive examples. I understand the need to avoid the proliferation of countless time properties, but pushing the approach too far in the other direction can make the use of properties even more confusing than it already is. Having significant event (P793) as a catchall property might be unavoidable for cases with a limited number of applications, where creating a dedicated property would be impractical, but a time property for production or construction for example would see use on tens of thousands of items, certainly far more than spacecraft docking/undocking dates (P622) or even first performance (P1191) and it would not be wasteful to create them.--Underlying lk (talk) 18:44, 18 March 2014 (UTC)
- I do not see what extra properties could be created to improve this situation; there are multiple existing date properties to document the occurrence of the most common key events: service entry (P729), date of foundation or creation (P571), discovery date (P575), service retirement (P730), date of disappearance (P746), date of dissolution (P576)... I will try to clarify its use and possibly use the new
Template:Constraint:Conflicts withto forbid its use with values like foundation (Q157031) or construction (Q385378). LaddΩ chat ;) 23:07, 18 March 2014 (UTC)- @Laddo: I'm thinking of properties like production start/end date or the date something was officially adopted for example (it could be a law or a state symbol), or more in general any other time property which could be used by a very substantial number of items. If they can be applied to a vast number of different entities, their creation shouldn't be ruled out altogether in favour of a catchall 'significant event' property, because the result is that the use becomes very confusing, which would lead it to become seldom used (significant event (P793) is currently used less than 1,000 times) or prone to misuse, which is not something we would want to happen.--Underlying lk (talk) 06:58, 19 March 2014 (UTC)
- @Underlying lk: I agree with you; such clear properties should be proposed and approved quickly. I am also a bit surprised that Snipre, back then, preferred using generic significant event (P793) instead of something like production start/end date that would indeed clearly apply to a large number of "product" items. No task force seems to have requested "approval date" or "adoption date" either. LaddΩ chat ;) 01:14, 20 March 2014 (UTC)
- I think date of foundation or creation (P571) and start date (P580) are missused in a lot of items because more specific properties are missing. When is a building created? When the first stone is placed or when it is finished? When are a boat created? When the keel is laid down, when she is put to sea or when she is accepted into service? significant event (P793) is not an option imho. It should be used for things like conflagrations and collisions. /ℇsquilo 18:11, 21 March 2014 (UTC)
- significant event (P793) is better than a bunch of properties because with that properties you can describe everything in all different fields. The problem of having one property for each kind of event is to be sure that everyone can find and use these properties. And if you are nor convinced just lookat the examples to the number of properties you will need to create. significant event (P793) allows an accurate description of the event because generic properties like service entry (P729) are not very precise for some items: does it mean the date when the item got its approval, the date when the first item leaves the production, the date when the first user uses it,...
- And then think about the extraction of data from wikita in wp: if you want to describe the event linked to an item you have to know each property number. Here with significant event (P793) you know one property number and the rest can easily be derived. And finally by using a structured data storage like significant event (P793) you can create automatic timeline in wp without the need of selecting every event one by one. Snipre (talk) 13:34, 22 March 2014 (UTC)
- Using a single property for all key events also has some drawbacks. It makes it difficult to populate infoboxes that refer to two or more dates such as fr:Modèle:Infobox Équipe nationale de rugby à XV. Besides, in most cases, one will not be able to use significant event (P793) as a qualifier since you most often need qualifiers with it. I think we could do with some more properties related to dates. Casper Tinan (talk) 22:30, 24 March 2014 (UTC)
- @Caper Tinan:, provided the items used in p793 are consistent, I do not think it is difficult to populatefr:Modèle:Infobox Équipe nationale de rugby à XV using the "getQualifier" function of fr:Module:Wikidata. --Zolo (talk) 11:00, 26 March 2014 (UTC)
- Using a single property for all key events also has some drawbacks. It makes it difficult to populate infoboxes that refer to two or more dates such as fr:Modèle:Infobox Équipe nationale de rugby à XV. Besides, in most cases, one will not be able to use significant event (P793) as a qualifier since you most often need qualifiers with it. I think we could do with some more properties related to dates. Casper Tinan (talk) 22:30, 24 March 2014 (UTC)
- I think date of foundation or creation (P571) and start date (P580) are missused in a lot of items because more specific properties are missing. When is a building created? When the first stone is placed or when it is finished? When are a boat created? When the keel is laid down, when she is put to sea or when she is accepted into service? significant event (P793) is not an option imho. It should be used for things like conflagrations and collisions. /ℇsquilo 18:11, 21 March 2014 (UTC)
- @Underlying lk: I agree with you; such clear properties should be proposed and approved quickly. I am also a bit surprised that Snipre, back then, preferred using generic significant event (P793) instead of something like production start/end date that would indeed clearly apply to a large number of "product" items. No task force seems to have requested "approval date" or "adoption date" either. LaddΩ chat ;) 01:14, 20 March 2014 (UTC)
- @Laddo: I'm thinking of properties like production start/end date or the date something was officially adopted for example (it could be a law or a state symbol), or more in general any other time property which could be used by a very substantial number of items. If they can be applied to a vast number of different entities, their creation shouldn't be ruled out altogether in favour of a catchall 'significant event' property, because the result is that the use becomes very confusing, which would lead it to become seldom used (significant event (P793) is currently used less than 1,000 times) or prone to misuse, which is not something we would want to happen.--Underlying lk (talk) 06:58, 19 March 2014 (UTC)
Texas history[edit]
I would like to talk to fellow people who know a lot about Texas history
Magazine issues[edit]
I'm looking for a little advice. I want to add data items for specific issues of magazines but I can't find the right properties I need to do so. Before I request new properties, I want to check that I haven't missed anything and that I've got this worked out properly. First, would an issue be an instance of (P31) the magazine title, or part of (P361), or something else? For that matter, would the issue be an instance of a magazine (Q41298), or is there a data item for a single issue of a magazine, or is neither necessary (as the overall magazine data item will also be instance of magazine)? volume (P478) will probably work for the volume but I think I'm going to have to request a new "issue number" property. date of publication (P577) and editor (P98) will work for each issue; other staff are largely already covered too. I think I will also need a "contents" property, to link to data items for everything contained inside the issue of the magazine; "contains works" might be better as it's less generic. It would also be useful to have the opposite, say "collected in", for the work to link back to the issue of the magazine. In book terms, each linked "contained" work will be an edition rather than a work item. Does that all sound sensible? (As for why I want this: at some point Wikidata should be able to support pages like Weird Tales/Volume 24/Issue 3 on Wikisource.) - AdamBMorgan (talk) 22:20, 18 March 2014 (UTC)
- In my opinion you need items for 'Weird Tales', for 'Weird Tales/Volume 24' and for 'Weird Tales/Volume 24/Issue 3' and for each story in Issue 3.
- 'Weird Tales' is an instance of a magazine with a publisher, start date, end date editors etc.
- 'Weird Tales/Volume 24' is 'part of:Weird Tales' is preceded by/followed by other volumes.
- 'Weird Tales/Volume 24/Issue 3' is 'part of:Weird Tales/Volume 24' and has a publication date, preceded by, succeeded by properties, maybe 'editor' too, even 'illustrator'.
- Each story has an 'author', a 'date of publication', links to other 'edition's (such as the wikisource edition). I think 'Part of' is still the way to link each story to the issue it was published in.
- Each item should also have a sitelink to the corrresponding wikisource page but can also have the full text available at (P953) property linking to the URL for the wikisource text (useful for other people who are using wikidata info to search for stuff). P953 can be used to link to other archives too.
- At least that is my opinion. Filceolaire (talk) 23:09, 18 March 2014 (UTC)
- For issue there is issue (P433). The Help of sourcing explains how to link a single article within a magazine, but for source items it is not necessary to link to an issue, but to an article within an issue, so it is not much help for your request. Ahoerstemeier (talk) 23:12, 18 March 2014 (UTC)
- For sourcing you don't need a separate item for each issue, as Ahoerstemeier said here (issue (P433) is used a as a property in sources to link to a text name for an issue, not to an item). When you are linking to Wikisource documents however, where it is a compliation of different stories, like here, then I feel each story deserves a separate item because each has different properties (especially author). Filceolaire (talk) 23:22, 18 March 2014 (UTC)
- +1 For sourcing no need to create a bunch of elements. Then for wikisource I propose to avoid the creation of intermediary elements: create one element for the magazine and one element for each story and avoid the need of creating an element for each volume or each issue. We have to choose what kind of information has to be put in wikidata in terms of reusability by other projects. Snipre (talk) 10:11, 19 March 2014 (UTC)
- For issue there is issue (P433). The Help of sourcing explains how to link a single article within a magazine, but for source items it is not necessary to link to an issue, but to an article within an issue, so it is not much help for your request. Ahoerstemeier (talk) 23:12, 18 March 2014 (UTC)
Process of bot request[edit]
Hi. A week ago I posted a bot permission request for User:smbbot but have heard nothing since. If I'm just being impatient that's no problem but I suspect I've done something wrong. Smb1001 (talk) 17:32, 19 March 2014 (UTC)
- I've added it to the list at the top, since the bot seems to be dead. Maybe that will prompt some discussion :-) Ajraddatz (Talk) 05:22, 20 March 2014 (UTC)
Property for non-administrative place?[edit]
What is the property for indicating that an item is located in a given non-administrative place? A few examples: Sardis (Q232615) <property> -> Lydia (Q620765) or Merv (Q193325) <property> -> Central Asia (Q27275).--Underlying lk (talk) 17:56, 19 March 2014 (UTC)
- Well, Lydia (Q620765) maybe not litterly is an administrative entity, but I think it looks like you maybe still can use P131 for this purpose. -- Lavallen (talk) 19:41, 19 March 2014 (UTC)
- That's not doable in this case, as I'm importing from w:Template:Infobox ancient site which makes a distinction between the parameter for administrative units
locationand the non-administrative place where it is locatedregion.--Underlying lk (talk) 20:23, 19 March 2014 (UTC)
- That's not doable in this case, as I'm importing from w:Template:Infobox ancient site which makes a distinction between the parameter for administrative units
- In my opinion, the "region" parameter of en:Template:Infobox ancient site is too unspecific to import automatically.
- The first example ("Sardis (Q232615) <property> -> Lydia (Q620765)") should be a specific property <part of historical dominion> or something like that. I checked some items like Machu Picchu (Q676203), Pompeii (Q43332) and Lugdunum (Q665), but this property doesn't seem to exist yet. It should be crated in my opinion.
- But the second case ("Merv (Q193325) <property> -> Central Asia (Q27275)") is not so useful as a property. "Turkmenistan (Q874)" or "Karakum Desert (Q172702)" would be valid values too. That Merv (Q193325) is located in Central Asia (Q27275) is a derived property anyways that can be deduced from the coordinates. --Slomox (talk) 08:25, 20 March 2014 (UTC)
-
- Well, region sounds "administrative" to me? What prevents us from adding more than one kind of administrative unit in the same Property? They can still be separated from what claims they have in P31/P132. -- Lavallen (talk) 10:09, 20 March 2014 (UTC)
- In this case it isn't, from the template's documentation: Do not mention administrative divisions such as provinces here, those should be put in the location entry.--Underlying lk (talk) 13:26, 20 March 2014 (UTC)
- Then you may argue if Lydia (Q620765) really should be at that parameter. "Asia Minor" sound more like a region in that case. -- Lavallen (talk) 15:24, 20 March 2014 (UTC)
- If so, which property should be used for a region?--Underlying lk (talk) 15:39, 20 March 2014 (UTC)
- A property for a (historical) region is not yet available (do not use p1134 for that), but if you propose such a new property I will support that. But even then, the "region" parameter of en:Template:Infobox ancient site is not really specified good enough to import automatically. Some 'regions' point to deserts or mountains. Michiel1972 (talk) 15:06, 21 March 2014 (UTC)
- That does not sound as a well defined property. Would it not be better to try to find some kind of algoritm to identify a both contemporary region (P131) and a one region (P131) for the present time?
- Look at Q15528601 where I have tried to add both what region it was a part when the entity was "alive" in the beginning of 1970's (Q339637 with rank preferred) and another claim about where the entity can be found today (Q504626 with rank normal, but without P582). The template for historical regions on svwp demands both those claims, but I think I can use the same property for it.
- I guess you can do the same for "historical Sardes". When the site was alive, it belonged to Lydia, but now it is a part of some region in Turkey. If the entity is about a historical site, I think the historical region should be preferred, while the present should have normal rank. -- Lavallen (talk) 16:18, 21 March 2014 (UTC)
- Use located in place (P1134) or located on terrain feature (P706) whenever is in the administrative-territorial entity (P131) is inappropriate. /ℇsquilo 18:01, 21 March 2014 (UTC)
- A property for a (historical) region is not yet available (do not use p1134 for that), but if you propose such a new property I will support that. But even then, the "region" parameter of en:Template:Infobox ancient site is not really specified good enough to import automatically. Some 'regions' point to deserts or mountains. Michiel1972 (talk) 15:06, 21 March 2014 (UTC)
- If so, which property should be used for a region?--Underlying lk (talk) 15:39, 20 March 2014 (UTC)
- Then you may argue if Lydia (Q620765) really should be at that parameter. "Asia Minor" sound more like a region in that case. -- Lavallen (talk) 15:24, 20 March 2014 (UTC)
- In this case it isn't, from the template's documentation: Do not mention administrative divisions such as provinces here, those should be put in the location entry.--Underlying lk (talk) 13:26, 20 March 2014 (UTC)
- Well, region sounds "administrative" to me? What prevents us from adding more than one kind of administrative unit in the same Property? They can still be separated from what claims they have in P31/P132. -- Lavallen (talk) 10:09, 20 March 2014 (UTC)
-
- Lydia (Q620765) was a Kingdom so it was literally an administrative place up until end date 113BC when it was succeeded by the Roman province of Asia. I understand that for the archeologists there is a big distinction between the modern local authority with jurisdiction over the site and the ancient kingdom that held sway when the site last flourished but Wikidata doesn't think that way. For us they are just administrative entities linked together back through history. At least that is how I see it. Filceolaire (talk) 12:14, 23 March 2014 (UTC)
- Imo, with does a pretty good job. We might add a type to Sardis (Q232615) and we got everything we need to infer the rest, an historian could infer the rest with a good knowledge of the organisation of the Kingdom at the time. TomT0m (talk) 13:12, 23 March 2014 (UTC)
Pywikibot[edit]
Hi, it would be helpful to have more examples on Wikidata:Creating a bot, like : add a qualifier, create a page. Pyb (talk) 19:36, 19 March 2014 (UTC)
- Hmm, should probably have a link to mw:Manual:Pywikibot/Scripts#Wikidata and not duplicate effort. Multichill (talk) 19:51, 19 March 2014 (UTC)
- @Pyb: Hi Pyb, I'm also learning to use Pywikibot so if you have a question you can drop me a message and I'll answer it, within the limit of my abilities. To create a new item you can use newitem.py, Multichill's new script tailor-made for that purpose. For adding qualifiers the right function seems to be addQualifier from page.py, I have a few examples of how other claims are added in my sandbox but qualifiers are not among them yet, I might try to add them later. Cheers,--Underlying lk (talk) 20:40, 19 March 2014 (UTC)
- I could only manage to add a qualifier after changing page.py, either there is some sort of bug or I'm missing something.--Underlying lk (talk) 21:23, 19 March 2014 (UTC)
- Adding qualifiers works for me. I extended Wikidata:Creating a bot a little bit. Creating an empty Wikidata item is not supported yet (it needs to have at least one sitelink). — Felix Reimann (talk) 16:09, 20 March 2014 (UTC)
-
-
-
- This is what I get when I try your example: "pywikibot.data.api.APIError: no-such-qualifier: Claim does not have a qualifier with the given hash". Which is correct obviously, given that the qualifier is not supposed to exist.--Underlying lk (talk) 21:33, 20 March 2014 (UTC)
- This was a bug. It is fixed now. Please update. — Felix Reimann (talk) 09:30, 21 March 2014 (UTC)
- Your example works now, thank you.--Underlying lk (talk) 10:01, 21 March 2014 (UTC)
- This was a bug. It is fixed now. Please update. — Felix Reimann (talk) 09:30, 21 March 2014 (UTC)
- This is what I get when I try your example: "pywikibot.data.api.APIError: no-such-qualifier: Claim does not have a qualifier with the given hash". Which is correct obviously, given that the qualifier is not supposed to exist.--Underlying lk (talk) 21:33, 20 March 2014 (UTC)
-
-
indigenous species and migration paths[edit]
We have endemic to (P183), but I could not find a property for indigenous species (Q169480). How should we record that a species in indigenous to a set of geographic regions, e.g. a bird might be indigenous to Far North Queensland (Q1396047), New Guinea (Q40285) and Maluku Islands (Q3827)?
We have range map (P181) , but that is a pretty picture for humans to view; it isnt (re-)useful data.
I would love a property for flyway (Q5463697), but I suspect that needs to wait until we have a data type of 'geographic box'. John Vandenberg (talk) 02:20, 20 March 2014 (UTC)
- Well, the movements maybe still can be described by items?
:Q25399 :Migration: North & Eastern Europe, Northern and Central Asia ::Time: Summer :Migration: North & East Africa, Middle East & South Asia ::Time: Winter :Migration: Western Europe, Korea, Japan ::Time: All year
- ? -- Lavallen (talk) 16:03, 20 March 2014 (UTC)
- Describing the indigenous status with items would be useful. Other precise properties could be where the bird nest (Rookery (Q2640507)/Bird colony (Q2368963)) and rest (Communal roosting (Q5153964)).
- The flyway should be described with a series of waypoints (waypoint (Q138081) / coordinate location (P625)), or more generally identify which flyway they are part of. e.g. Black-headed Ibis (Q373114) <flyway> Central Asian Flyway (Q5060366). John Vandenberg (talk) 01:35, 21 March 2014 (UTC)
- We have day in year for periodic occurrence (P837) for yearly events like migrations.
- Some birds will have multiple migration routes (e.g. from europe to africa via Spain and also via Italy) so you need a property for the migration with qualifiers for the origin, destination, route and time of year. Basic queries will only see the value assigned to the general property and not see the qualifiers. The destination of the migration is probably the crucial value that should show up there.
- Migration to:East Africa
- Time of year:october
- From (place):Central Russia
- From (place):Ukraine
- via:Caucasus
- via:Palestine
- via:Nile Valley
- or something like that. Filceolaire (talk) 21:35, 21 March 2014 (UTC)
Is there a search function like this[edit]
For example, I'm looking for pages that are on the Chinese Wikipedia, but they do not have a corresponding page on the English Wikipedia, I want to search for such pages TheChampionMan1234 (talk) 01:50, 21 March 2014 (UTC)
- What you need is this: Not in the Other Language: finds Wikidata items with a Wikipedia page in language A but not in B.--Underlying lk (talk) 07:56, 21 March 2014 (UTC)
Reasonator for all[edit]
Can we add a toolbox link to Reasonator for all users? To do so, it should be sufficient to add this script to MediaWiki:Common.js.--Underlying lk (talk) 09:05, 21 March 2014 (UTC)
Support On this spirit, I still think we should do something like with {{Q'}}in{{Q}}and put a reasonator link also in Q. TomT0m (talk) 11:49, 21 March 2014 (UTC)
-
- Somebody already made that as a gadget (I'm sorry I forget who made this). Second function in my User:Tobias1984/common.js We should make it a default gadget. --Tobias1984 (talk) 12:17, 21 March 2014 (UTC)
- @Tobias1984: it was me, lol. But I'd like to provide a Reasonator link for everyone, including unregistered users if possible, which isn't something that can be done with a user script/gadget.--Underlying lk (talk) 12:41, 21 March 2014 (UTC)
- @Underlying lk: Thanks again :) I really like that gadget. Probably some Wikimedia-developer is watching this page and can comment on this feature. --Tobias1984 (talk) 16:33, 21 March 2014 (UTC)
- I put the code in MediaWiki:Gadget-ReasonatorTools.js but I'm missing something, because it doesn't seem to work. Please improve.
- When this works and we're confident that the code is correct. We can enable it by default in MediaWiki:Gadgets-definition. This enables it for everyone including logged out users. Multichill (talk) 13:48, 22 March 2014 (UTC)
- @Underlying lk: Thanks again :) I really like that gadget. Probably some Wikimedia-developer is watching this page and can comment on this feature. --Tobias1984 (talk) 16:33, 21 March 2014 (UTC)
- @Tobias1984: it was me, lol. But I'd like to provide a Reasonator link for everyone, including unregistered users if possible, which isn't something that can be done with a user script/gadget.--Underlying lk (talk) 12:41, 21 March 2014 (UTC)
- Somebody already made that as a gadget (I'm sorry I forget who made this). Second function in my User:Tobias1984/common.js We should make it a default gadget. --Tobias1984 (talk) 12:17, 21 March 2014 (UTC)
Support Yes, please! 80.249.52.108 16:43, 21 March 2014 (UTC)
Support Agree resonator really does help. --222.127.85.170 05:18, 22 March 2014 (UTC)
Support I agree, obviously ;-) --Magnus Manske (talk) 18:14, 22 March 2014 (UTC)
Support it will open the flood gates of even more Reasonator presentations. Thanks, GerardM (talk) 18:17, 22 March 2014 (UTC)
Support Yes please. Ajraddatz (talk) 18:22, 22 March 2014 (UTC)- Yes to make Resonator default on MediaWiki:Gadgets-definition, but no to making it default on MediaWiki:Common.js.--Snaevar (talk) 23:47, 22 March 2014 (UTC)
Oppose Enabling for all users and integrating to {{Q}}. It is not so useful tool for this. But
Support adding to https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-gadgets and {{Q'}}. — Ivan A. Krestinin (talk) 18:56, 22 March 2014 (UTC)- I don't really see the appeal of Reasonator (just one more badly designed interface?). Certainly it looks like a bad idea to put it in
{{Q}}; the system is overloaded and slow enough as it is. - Brya (talk) 19:56, 22 March 2014 (UTC)- I agree with the two above. It's fine as a gadget on the preferences. --Stryn (talk) 20:23, 22 March 2014 (UTC)
- IP users cannot use gadgets, though.--Underlying lk (talk) 20:41, 22 March 2014 (UTC)
- Let's make it a default gadget then, what matters is the outcome not the method.--Underlying lk (talk) 15:57, 25 March 2014 (UTC)
- IP users cannot use gadgets, though.--Underlying lk (talk) 20:41, 22 March 2014 (UTC)
- There is no performance problem with generating a link to reasonator in a template. And if you have suggestion to improve reasonator, please share, this is more constructive. TomT0m (talk) 21:36, 22 March 2014 (UTC)
- I agree with the two above. It's fine as a gadget on the preferences. --Stryn (talk) 20:23, 22 March 2014 (UTC)
- I don't really see the appeal of Reasonator (just one more badly designed interface?). Certainly it looks like a bad idea to put it in
NewPP limit report
Parsed by mw1181
CPU time usage: 4.324 seconds
Real time usage: 4.702 seconds
Preprocessor visited node count: 11200/1000000
Preprocessor generated node count: 19477/1500000
Post‐expand include size: 65756/2048000 bytes
Template argument size: 13698/2048000 bytes
Highest expansion depth: 17/40
Expensive parser function count: 117/500
Lua time usage: 1.769/10.000 seconds
Lua memory usage: 1.39 MB/50 MB
Lua Profile:
Scribunto_LuaSandboxCallback::getContent 340 ms 17.5%
Scribunto_LuaSandboxCallback::getExpandedArgument 300 ms 15.5%
<Module:JSON:297> 280 ms 14.4%
recursiveClone <mw.lua:109> 180 ms 9.3%
? 140 ms 7.2%
sub 140 ms 7.2%
<Module:JSON:373> 100 ms 5.2%
char 80 ms 4.1%
Scribunto_LuaSandboxCallback::newTitle 60 ms 3.1%
type 60 ms 3.1%
[others] 260 ms 13.4%
-
-
- -- Lavallen (talk) 06:16, 23 March 2014 (UTC)
- The link to reasonator generation requires nothing expensive, even no template extension but parameter code, so this is a non issue. See
{{Q'}}code. Adapted to{{Q}}code this require no real addition, in the worst case if we drop the requirement of generating a valid reasonator link we should see nothing in those numbers. TomT0m (talk) 11:31, 23 March 2014 (UTC)
- The link to reasonator generation requires nothing expensive, even no template extension but parameter code, so this is a non issue. See
- -- Lavallen (talk) 06:16, 23 March 2014 (UTC)
-
Oppose Use Q' if you like it. It makes no sense to have it at all this exceptions. --Succu (talk) 11:54, 23 March 2014 (UTC)
- The proposal is for adding a toolbox link to Reasonator, on item pages only.--Underlying lk (talk) 15:00, 23 March 2014 (UTC)
Oppose Enabling for all users and integrating to {{Q}}.
Support adding to {{Q'}}though. /ℇsquilo 13:39, 26 March 2014 (UTC)
Support as an opt-in gadget, but
Oppose by default. --Ricordisamoa 17:27, 26 March 2014 (UTC)
Hadoop[edit]
Anyone playing around with the Wikidata dataset and Hadoop at the moment? I wonder if anyone already has experience with that especially combined with Hive. Multichill (talk) 14:15, 22 March 2014 (UTC)
Ranking page for wikidata per articles type by country[edit]
Now that wikipedia articles are linked with wikidata, maybe we can also create a ranking page similar to what wikipedia has. Maybe we can create ranking of number of wikipedia / wikivoyage articles per country. We can create a list per category. Like list of wikipedia & wikivoyage articles per geographical entity per country. List of wikipedia articles per person per country. List of events per country event. Then create article density over land area and population and history start date and end date.
I see a good effect in creating this, it would be more visible which country/territory needs more articles based on density.
The bad effect is, since people tend to be competitive on ranking, we may have a stub creating race like what is happening in the ranking for wikipedia articles now.
What do you think? --Napoleon.tan (talk) 14:33, 22 March 2014 (UTC)
- @Magnus Manske: already implemented (basic) querying at http://208.80.153.172/wdq/ . Would be nice if over time the sitelinks would be part of this dataset and more advanced SQL statements like GROUP BY would be supported. Than you would be able to query for a bit more complicated questions. Multichill (talk) 14:53, 22 March 2014 (UTC)
- The sitelinks are part of WDQ; check the API docs (look for "link"). You could find how many items for a certain query have e.g. a frwiki sitelink. For overall stats, a direct database query would be more efficient though. I've put a simple one I just ran here. If you want categories, you can run quick_intersection to get the items; then run the database query on those items. --Magnus Manske (talk) 18:12, 22 March 2014 (UTC)
- Thank you Multichill and Magnus. I have been aware of the WDQ for a while. Let me check the quick_intersection tool. --Napoleon.tan (talk) 15:07, 23 March 2014 (UTC)
- The sitelinks are part of WDQ; check the API docs (look for "link"). You could find how many items for a certain query have e.g. a frwiki sitelink. For overall stats, a direct database query would be more efficient though. I've put a simple one I just ran here. If you want categories, you can run quick_intersection to get the items; then run the database query on those items. --Magnus Manske (talk) 18:12, 22 March 2014 (UTC)
Protecting data[edit]
Is there a possibility to protect some data in an item ? I want to import some ID from their origin databases so once the data is imported and sourced there is no need to access to that data for edition, at least for normal users. So can we expect once to protect some data like the authority control IDs for example and to allow only a small group of users to edit them in case of need in order to ensure a reliable data use ? Snipre (talk) 12:09, 26 March 2014 (UTC)
- The problem is not limited to authority control data, but quite some other properties, too. The sex of a person is very unlikely to change, and so is the author of a book, the coordinates of a place, and so on. Maybe we can even say that most every statement that is made once is rather unlikely to change, while of course there may be the need to add some statements at any time. One approach would be to allow changing any existing values only to a certain group (e.g. autopatrollers). This would probably prevent a lot of vandalism and accidents of all kinds, but also radically reduce the degree of freedom in Wikidata editing. --YMS (talk) 12:47, 26 March 2014 (UTC)
- This is not a good idea, because in that case vandalism will just add new statements instead of modifying old ones and this will be more difficult to correct. I think more about a specific protection for statements which have typically one value and are unique and are used as identifiers. And this protection should be activated only by bots through the API in case of large data import. Snipre (talk) 13:13, 26 March 2014 (UTC)
- We could use an AbuseFilter rule instead of "normal" protection. E.g. "if the claim's value is not supposed to change once set (or the property is not supposed to have more than x values) and the user is not reliable enough, then reject the edit". --Ricordisamoa 16:38, 26 March 2014 (UTC)
Gadget Preview not working[edit]
Hi, since 2-3 days I no longer see the preview link beside each article linked to an item, normally put by MediaWiki:Gadget-Preview. Anyone else having that problem ? LaddΩ chat ;) 22:41, 26 March 2014 (UTC)
Dušan Petković[edit]
Item Dušan Petković at wikidata should be connected with Душан Петковић at sr.wikipedia (https://sr.wikipedia.org/wiki/Душан_Петковић ). But when I try to connect them, some bug occurs so it is impossible. Someone know what could be problem? --Јованвб (talk) 23:24, 26 March 2014 (UTC)