Wikidata:Project chat

From Wikidata
Jump to: navigation, search
Shortcut: WD:PC
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Requests for deletions and mergers can be made here.

IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at October.

Move sitelink?[edit]

I have not been working on Wikidata for a while. Before, I could move a sitelink easily from item to item with the 'move' tool (an extra option when editing the sitelinks). In my preferences the option to have this 'tool' is still active. But now all sitelinks have a common edit field and for all sitelinks I can only type a new link or choose remove. Of course there is also the Merge tool but what if I want to only move part of the links? Bever (talk) 03:30, 7 October 2014 (UTC)

The UI changed a few days ago (e.g. you're able to edit multiple sitelinks at once). This broke the Move gadget (see MediaWiki talk:Gadget-Move.js#Doesn't work anymore with new UI), and nobody has fixed it yet or cared too much about it otherwise (e.g. proposing new ways to include it into the new UI). I'm not sure actually whether this would be a minor adjustment to the new layout or if some serious problems would have to be solved to re-activate it. --YMS (talk) 09:07, 7 October 2014 (UTC)
A few days ago? What a coincidence... I noticed the change and have some more troubles with it:
  • when I want to change labels or descriptions for languages in my babel box, now an extra mouse click is needed ('Edit' above the first box).
  • several times when I tried to change several labels and/or descriptions and/or aliases at once, I got an error message ('bewerkingsconflict', probably 'edit conflict' in English), it appeared that one change was effected but another was not. Bever (talk) 01:22, 10 October 2014 (UTC)

Is there a place read by the developers where such problems can be dropped? In the meantime I would prefer to use the old interface. The advantage of the new model would be that you have to click at 'save' only once after making several changes, which would outweigh the extra click on 'edit', but as I said, often it does not work. Bever (talk) 00:52, 14 October 2014 (UTC)

We're reading here ;-) There is also Wikidata:Contact the development team. We're working on improving the interface changes we made at the moment. As for the move gadget: Best check the talk page of the gadget and talk to the person who wrote it. --Lydia Pintscher (WMDE) (talk) 07:07, 14 October 2014 (UTC)
I (the creator of the gadget) thought that moving it into Wikibase itself will be much easier than having to create another hack to inject all the [move] buttons. Therefore I created bugzilla:72019. -- Bene* talk 07:47, 14 October 2014 (UTC)
Thank you both. I would like to point out that the move gadget is not only useful for people who want to move sitelinks. It is also advantageous for people who want to check the changes on the items on their watchlist. The gadget leaves an edit comment with a link to the new item. If sitelinks have been moved 'manually', you don't see why they disappeared on the old items.
Last week, when I wanted to move 2 links, I forgot to press 'save' when deleting the links on the old item. Therefore adding them on the new item resulted in an error. I spent 10-15 minutes in new tries. Bever (talk) 07:23, 21 October 2014 (UTC)
On Bugzilla (where I cannot edit, as I am not registered there), John F. Lewis replied to Bene's proposal with 'In the core as a feature - yeah but likely to be obsoleted by plain merging?' I do not know what 'plain merging' is, but between the 'merge' tool and the 'move' tool there is a big difference. With merge, you move all information (all sitelinks, properties, labels etc.) to another item. With the move tool, you can move 1 sitelink if it is just placed on the wrong item, leaving the rest of the item as it is. Bever (talk) 06:08, 25 October 2014 (UTC)

Two identical properties?[edit]

What is the difference between birth name (monolingual text) (P1477) and name in native language (P1559)?--Shlomo (talk) 08:36, 12 October 2014 (UTC)

birth name (monolingual text) (P1477) refers to for example someone's maiden name, or the name they were born with before they were adopted (or went into witness protection). It is also used for example for Barack Obama. Bill Gates and Bill Clinton, though, use birth name (Deprecated) (P513). name in native language (P1559) refers to for example if someone immigrates to an English speaking country and changes their name to a more Anglicized name. This is pretty common, and sometimes happened, for example, at Ellis Island simply because the immigration officer did not understand the name or the spelling of the name that someone had. The word "monolingual" in P1477 implies that there is no change in the language, for example, Smith to Robbins, and the words "native language" in P1559 implies that the name was changed from one language to another. For example Schmid to Smith, but more commonly to remove letters with accent marks or any non-English letters. 00:41, 13 October 2014 (UTC)
Does it mean that birth name (monolingual text) (P1477) should be only used for the very first variant of the name after the birth (not many people have a name in the moment of the birth...) and only when a later change of the name in the same language occured? And name in native language (P1559) should be used only for the "current" (What does it actually mean? Last known?) name and only when the person speaks this language at a native-speaker level and only when the person has had a name in another language before? First, this is is not clear from the descriptions of the properties, and second, this concept doesn't seem very useful. What if a person changed his/her name several times? What if we can't figure out which languages at which level does/did the person speak? What if a person who has a name in native language (P1559) statement changes his/her name again in the same language? Etc. etc. Wouldn't be easier to have one "full name" multilingual (or even monolingual in the meantime) property and use the qualifiers to show that this is the "birth" name (succeeds (P1365) set to novalue), the current name (succeeded by (P1366) set to novalue) a.s.o.?--Shlomo (talk) 09:31, 13 October 2014 (UTC)
name in native language (P1559) is probably most useful for users with non Latin scripts. For the Bill Gates example mentioned, this would be:
Have a look at it.--- Jura 10:48, 13 October 2014 (UTC)
I don't question the need of a full name monolingual property (IMHO a multilingual one would be more suitable, though). I just asked about the reason, why we have two of them and given the answer above I proposed reducing it to one property using qualifiers. I don't mind being it the name in native language (P1559), if we only cancel the strict requirement that it must be the "current" name in the "native/native equivalent" language of it's bearer.--Shlomo (talk) 16:28, 13 October 2014 (UTC)
I am not sure there is any benefit in combining two fundamentally different properties. 18:29, 13 October 2014 (UTC)
I agree. Birth name is the first name a person has, before marige and other name changes. /ℇsquilo 06:15, 14 October 2014 (UTC)
I still can't see what makes the "birth name" so different from all other names the person had during his/her lifetime except it is the first one in a row. We don't have properties for "first place of residence", "first nationality", "first school attended", "first husband" etc. either. But if there's a consensus that we need an extra property for a "birth name", let it be so. Let birth name (monolingual text) (P1477) be the "birth name" and name in native language (P1559) any full name of a person supported by sources no matter if current or abandoned, in any language no matter if and at what level spoken by the person in question (that's what qualifiers and rank are for).--Shlomo (talk) 08:52, 14 October 2014 (UTC)
@Shlomo The "birth name" is generally official - the one written on passport if the person never (officially) changed his/her name - contrarily to all pseudos a person uses... birth name is the name the people was registered at birth… contrarily to all other names, that can be (more or less, depending on country) freely used.
birth name (monolingual text) (P1477) is the contrary of pseudonym (P742), while name in native language (P1559) is to be used for cross-alphabet namings… russian/chinese, etc. — this is not at all the same use, even if birth name (monolingual text) (P1477) has been used in place of name in native language (P1559) before its creation :)
but I agree… name in native language (P1559) should not be monolingual - it should be string as it has only one language to receive… normally…
if you look at Mark Twain (Q7245) from a russian pov (ru link), you'll see that they display the name Марк Твен and the P1559 : Mark Twain, and the P1477 : Сэмюэл Лэнгхорн Клеменс (in russian), since it's monolingual… ;) - it would be exactly the same (reversed) for a Russian writer in en or fr or de… --Hsarrazin (talk) 20:29, 14 October 2014 (UTC)
If it should be an opposit of "pseudonym", then it should be named "official name", not "birth name" and an accent should be put on the officiality (whatever does it mean before 19th century...) of the name, not on the fact that it was the first name after person's birth. Anyway, it seems that your conception of these two properties is quite different from the one described above by That should be cleared before two different robots with different conceptions start mass adding contradicting statements using these properties.
Alas, I don't understand what you mean by "cross-alphabet namings". Neither do I understand what is your problem with Mark Twain (Q7245): For P1477 I see two statements: the English one and the Russian one added by you... Of course both without any source, in full accordance with local habit... Are you referring to the Wikidata item here or to some other Wikimedia project using the data?
And about the string datatype: It should be used for sequences of characters not associated with any language, like alphanumerical identifiers, codes etc. Since names of person's are always associated with some language, we should use mono- or multilingual text datatype for them.--Shlomo (talk) 22:15, 14 October 2014 (UTC)
Ok, strike the part about the string type : I did not clearly understand the change of type, and re-read the use of types… but this type is so recently introduced, that I was still under the understanding of the previously used property :) --Hsarrazin (talk) 08:37, 18 October 2014 (UTC)
Official name is less useful. It would work for someone who had never changed their name, or someone who had been knighted, like Paul McCartney (Sir James Paul McCartney) but commonly used a nickname. An actor is more thought of as having a real name than an official name. And any time you change your name, the new one becomes your new official name - all of your names are official names, just at different times. Sharon Stone's name is "Sharon Yvonne Stone", there is currently no property used to indicate that. Bob Hope was born "Leslie Townes Hope", and uses birth name (Deprecated) (P513) for that, but also given name (P735) for his stage first name, Bob, which is incorrect, because a given name is only the first name that you were given at birth, so it should be "Leslie" or "Leslie Townes". A "given name" is a name "given" to you at birth, as opposed to your last name, that you inherit, and not a name that you give yourself. Bob Hope is a stage name, and "In 1929, Hope informally changed his first name to 'Bob'", so he never officially changed his name, but simply used Bob Hope as a stage name. Martin Sheen also uses P513, but not his son, Charlie Sheen, which does not have the property yet. Deprecated is not really a very good word to use, unless they have actually changed their name to something else (officially, not like Bob Hope). 03:53, 17 October 2014 (UTC)
a thought I just tonight, about why the "birth nam" is so different from all other names the person had during his/her lifetime : and see that had the same above : the "birth name" is "objective" relatively to a person, contrary ot all other names : it was not chosen by the person, and can be considered as "permanent reference" :) , whilst all other names are the result of choices : nicknames, wedding, legal change of name, moving from a country to another… --Hsarrazin (talk) 08:32, 18 October 2014 (UTC)

Complex query[edit]

How would I go about finding a list of all biographies (instance of=human) which only exist on the Welsh (cy) Wikipedia? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 14 October 2014 (UTC)

@Pigsonthewing: I'm not sure, but you might be able to do it with ToolScript. But since you ask, here is a list made using the latest SQL dump and old fashioned Python:

 – The preceding unsigned comment was added by Haplology (talk • contribs).

@Haplology: That's very useful. thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:56, 15 October 2014 (UTC)
@Pigsonthewing: If you want a dynamically generated (and updated) list, you can get a rough approximation using the Wikidata Query API. You can't ask it for "no other wikis", but you can get it to look for links to cywiki and then cut out any with links to a given set of wikis.
CLAIM[31:5] AND LINK[cywiki] AND NOLINK[enwiki,frwiki,dewiki,eswiki,itwiki,ocwiki,ruwiki,gawiki,glwiki,gvwiki,nlwiki,svwiki,arwiki,ptwiki,brwiki,tlwiki] (autolist link)
There will be a couple with links to wikis I haven't spotted, but it'll be easy enough to add them to the list and rerun it. Andrew Gray (talk) 17:08, 19 October 2014 (UTC)

Populated places, administrative districts, states and territories, by year[edit]

In the English Wikipedia there are categories for en:Category:Populated places by year of establishment and en:Category:States and territories by year of establishment, such as en:Category:Populated places established in 1976 and en:Category:States and territories established in 1976.

In the French Wikipedia there is fr:Catégorie:Division administrative par date de fondation (which literally is just "Category:Administrative division by date of foundation") such as fr:Catégorie:Division administrative fondée en 1976. Some years of these French "administrative division"-categories are linked to "populated places" and some are linked to "states and territories". I would like to clear this up, so my question is, to which category should the French categories be linked? Or maybe it is so distinct that French should be linked to neither? - FakirNL (talk) 12:31, 15 October 2014 (UTC)

P.S. The Esperanto category eo:Kategorio:Administraj unuoj laŭ fondodato should probably follow French if consensus is reached.
in fact, the French categories are the sum of both… so I don't see how it could be linked to one OR the other…
another solution would be to propose a modification to fr ? good luck :D --Hsarrazin (talk) 23:23, 16 October 2014 (UTC)
Delinking sounds like best solution as of now. Anyone else? - FakirNL (talk) 13:15, 17 October 2014 (UTC)
another solution would be to propose a modification to en?  :D --Infovarius (talk) 03:58, 18 October 2014 (UTC)
Modification to EN, to ES, LA, NN, NO, SCO, SV, TR and several others. Sounds like a great plan! 718smiley.svg - FakirNL (talk) 11:09, 18 October 2014 (UTC)

Astronomical objects by year the same as asteroids by year?[edit]

In quite some language projects, astronomical objects are categorized by year of discovery. Examples:

and some others. But in Spanish and Latin Wikipedia, they have a very similar category that only allows asteroids (so, for example, no moons), they are like:

Are these categories similar enough to be linked together (as they are in about 127 cases), or is the difference so fundamental that Spanish and Latin are not supposed to be linked to the rest (as they are in about 44 cases now)? - FakirNL (talk) 13:12, 15 October 2014 (UTC)

P.S. Russian Wikipedia has both, so ru:Категория:Астрономические объекты, открытые в 1866 году (astronomical objects) and subcategory ru:Категория:Астероиды, открытые в 1866 году (asteroids). This would be an argument for splitting up the WD-items. - FakirNL (talk) 13:17, 15 October 2014 (UTC)
I'm starting to split off the items in one for "astronomical objects" (with English, French, Italian, Norwegian and Russian) and one for "asteroids" (with Spanish, Latin and Russian). - FakirNL (talk) 16:36, 18 October 2014 (UTC)

Authority control gadget[edit]

I have had the "Authority control" gadget enabled for several weeks, but have just realised that it is not working, even on a new computer. Can anyone help, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:28, 17 October 2014 (UTC)

I have the same problem, it hasn't been working in a long time... when I need to see the link I append "?debug=1" to the url, but that is not very user-friendly... --Micru (talk) 23:13, 17 October 2014 (UTC)
Nice trick! Possibly someone more familiar with MediaWiki:Gadget-AuthorityControl.js might have a look. Item Q47484 can be used for testing, it has a fair number of authority control links. -- LaddΩ chat ;) 15:16, 18 October 2014 (UTC)
@Pigsonthewing: working fine for me and gives the right wikilinks. And to clarify, the linking gadget, and magnus's tool with a similar name are both functioning for me.  — billinghurst sDrewth 04:07, 20 October 2014 (UTC)

Edit existing wikipedia links[edit]

Is there any possibility to edit an existing wikipedia link without using API-calls/client side scripts? In pure HTML there is only a "Add" link, but no link to edit the data field. (some weeks ago there was a edit-link to a special: page to edit/modify existing entries. this edit link vanish).--Wdwd (talk) 14:33, 18 October 2014 (UTC)

Currently the User Interface requires Javascript to edit links. You can add links without Javascript, but not remove or edit them now. But if you list here the edit that you want made, someone will be able to make it for you. 06:30, 21 October 2014 (UTC)

What to do when British English is used in title or description?[edit]

I'm not sure what the correct way to handle British English versus American English in the title and description areas. In at least two cases I have come across British English in a title or description, but there is a separate area for British English, which would imply that American English should be used in the title and desc areas. I know on en wiki it's sort of "whoever gets there first", but I'm not sure of the policy here.

First case was where I encountered this was the description for 2014 FIFA World Cup (Q79859); it was originally described as a football competition, but I changed it to soccer and moved the football description to the British English area.

This second case, however, is the case of Harry Potter and the Philosopher's Stone (Q43361). It was published in American English as 'Harry Potter and the Sorcerer's Stone'; and this is included in the "also known as" section. As the original title was in fact Sorcerer's Stone, I feel it's improper to change it to the American English version. However, I feel as though including the American English title in the "also known as" section isn't as semantically clear.

I think the most clear way to do this is to have a separate "American English" section in the language section, and that way it is unambiguous. But that doesn't exist yet! Thoughts? Mvolz (talk) 22:51, 18 October 2014 (UTC)

@Mvolz: I don't think that the English label on Wikidata should be understood as US-English, but as international English. I think only Canadians and US-Americans say soccer, versus all other English speaking countries and all the countries that have English as a second language call it football. In case it doesn't exist, we should probably think about a US-English language field for these cases. -Tobias1984 (talk) 15:34, 19 October 2014 (UTC)
We should either support en-US or (more sensibly) drop en-GB & other en-XX variants. There are very few cases where this is actually a net positive. Andrew Gray (talk) 16:27, 19 October 2014 (UTC)
The en-xx are a style that should not be applied in the Q: namespace, though maybe the Property: namespace is okay, though pretty much irrelevant, and in truth a fallacy, especially when there is also en-au, en-nz, etc. and there is no clear divide between then anyway (all wasted space stuff).

What I do find weird, and I left comment elsewhere is with something like birth name (monolingual text) (P1477) where something in English is English, you cannot have the nonsense of variations.  — billinghurst sDrewth 03:54, 20 October 2014 (UTC)

I believe there is a need to distinguish US-english from British-english in some occations to avoid confusion ("football" is a very good example). The same need probably exists for Brazilian vs. Portugese portugese. As a matter of fact we do distinguish between Nynorsk (Q25164) (nn) and Bokmål (Q25167) (nb). /ℇsquilo 12:35, 20 October 2014 (UTC)
No it isn't. In Australia there are five types of football — Australian Rules, Rugby League, Rugby Union, Soccer, Gridiron; and all played by footballers — and depending your state and persuasion will depend on which is your priority football, oh and Rugby Sevens. Then take New Zealand, South Africa, Samoa, Fiji, Papua New Guinea, where else would you like that don't have their own variations of en-xx. False realities. Cover all bases, and make sure that your explanations cover it.  — billinghurst sDrewth 13:13, 20 October 2014 (UTC)
A property to indicate en-US, en-BR, en-CA, en-AU, en-NZ (is there also an en-India?) is valuable, but what name is used for the namespace is unimportant and can be in any flavor of English. If there is a subject that is native to one flavor, that is the one that should be used, but otherwise it is really just arbitrary. 04:52, 21 October 2014 (UTC)
For football, the full name 'association football' could be used to avoid confusion. ('Soccer' would be a bad choice because this word is mostly used in countries where it isn't the favourite sport.) Of course 'en' should apply to all main variants of English. Bever (talk) 07:32, 21 October 2014 (UTC)
If the english speaking world can agree on one acceptable name for association football (Q2736) that is all good and well. However, the need still exists for other words and other languages, particurlarly Brazilian vs. Portugese portugese. Should maritime pilot (Q475604) be named prático or piloto and should aviator (Q2095549) be named piloto or aviador? /ℇsquilo 06:41, 23 October 2014 (UTC)
Once again, the name is not particularly important - what is on the page is what is important, and a clear description. English Wikipedia frankly just lets whoever creates the page first use their flavor of English (and perhaps because there is a 5-8 hour time advantage, a relative majority are in en-BR). If Portuguese also has different variations, pt-PT, pt-BR, pt-somewhere else, it would, just like the flavors of english be useful to have a property that says "in pt-PT", or "in pt-BR" if the name used was in the other of those two variations. Chinese has resolved this issue by having different wikipedias for each, because the character set is different, but English and other languages (most others?) have chosen to avoid that unnecessary duplication, instead noting in each article the en-US, en-BR, en-AU spelling. 19:04, 23 October 2014 (UTC)

It doesn't let me delete data from Q16162716, please help.[edit]


I'm trying to add an interlink between the article "Hard Rock Sofa" in the English Wikipedia and "HardRockSofa" in the Russian one. The former has a data page of Q18156495 where there is the English article and the Korean one already added there. When I tried to add the Russian article manually, it refused my edit pointing out to Q16162716. But when I went there to remove the Russian article from there to put it in the 495, it also refused my edit to remove because of something like "inappropriate action". Please help, because before it was much much easier to simply add the language brackets at the end of articles to get the proper interlinks.

Thanks, Spaceinvadersaresmokinggrass (talk) 07:44, 19 October 2014 (UTC)

@Spaceinvadersaresmokinggrass: I see that you found the "Merge" tool. I think that the tool does four things: First, it adds all the data to the surviving item; second, it clears the data in the doomed item; third, it marks the doomed item as "merged"; fourth, it adds the page to "Wikidata:Requests for deletions". It looks like the first and second actions happened, but the third and fourth didn't. I don't know why. Maybe it thinks that you are too new on Wikidata to mark the item for merging. (But that would be silly: A lot of users from other wikis would come to Wikidata to do this.) Earlier this year, the merge tool had some bug that was causing things like this; but that software bug was fixed. Since all the data was removed from Q16162716, you can go to Wikidata:Requests for deletions and add a new request for Q16162716, with something like "merged into Q18156495" as the reason. --Closeapple (talk) 09:11, 19 October 2014 (UTC)
Or even better: set the merge.js tool to redirect the source item to the target item. Lymantria (talk) 10:47, 19 October 2014 (UTC)
Having just recently done a bunch of merges, I can say that the merge tool was useless. I had to delete the item from where I was moving it from, and there is a trick do doing that (our new UI sucks). You click edit, you click remove, you click save - and you are not done - you will see a second save appear, and you have to click that one too. Only when you see edit again are you done. Then you can go to the merge to page and add in the item. Then as a final step you have to go to RFD and make a list of the pages that are no longer in use so that they can be deleted. Since they do no harm, it is easier to wait until you are done, and do a bulk request if you are doing more than one page. I have one pending now that I have not bothered to list so that I can combine it as a bulk request after I finish the project that I am working on, which requires a lot of merges (translating an image into 137 languages). 05:04, 21 October 2014 (UTC)

VIAF and "no value"[edit]

I would appreciate any further comment about the ability to have "no value" set for VIAF identifier (P214), or other means to help achieve the outcome for maintenance. If you have comment it would be appreciated at Property talk:P214#Managing a "no value" statement. Thanks.  — billinghurst sDrewth 04:51, 20 October 2014 (UTC)

Sometimes a relevant person has no own dataset. For example: you might be looking for an author with the name of "Michael Smith". As ist is a very common name, the cataloges might summarize the works of several persons with the same name of Michael Smith including the Michael Smith you are looking for. You might omit the property VIAF identifier (P214), however other users my be searching the database over and over again or link to the wrong dataset, which includes many people (and create occasionaly a constraint violation, if the same VIAF is linked to another Michael Smith allready). By placing VIAF identifier (P214) + no value, you can indicate, that you have made a search and found no appropriate value. The same applies to every other database you´d normally expect a dataset to be present. But please do not create VIAF identifier (P214) + no value for 3rd league football players, as usualy such people have no own data set in GND, VIAF.... and most probably never will have. Its the same with tennis players + a database that is designed for football players. --Giftzwerg 88 (talk) 17:33, 20 October 2014 (UTC)
Yes, I know that, and that is why I asked for comment at the talk page where you can see the context. At this stage there is a constraint on P214 that does not allow "no value", which means we have no tracking abiity. I am not proposing for every identifier, just this one that is becoming the default/central identifier.  — billinghurst sDrewth 00:53, 21 October 2014 (UTC)

Should people be human (Q5) or person (Q215627)?[edit]

Should instance of (P31) describe the people as human (Q5), like Jura1 is pushing ahead, or person (Q215627), like the Template:Constraint:Person is demanding?--Shlomo (talk) 08:50, 20 October 2014 (UTC)

First of all a Template cannot demand anything, the people behind it are the ones that might want to push that change. "Person" is an abstract term, and when anyone is stating "instance of:person" they are referring only to the abstract component (personhood) that humans share with others beings (real or imagined). Generally it is more useful to instantiate concepts that convey meaningful information to the reader. In this case for beings with a clear physical presence it is more relevant to use "instance of:human", since that concept refers to purely physical entities to which the constraints "sex, place of birth, and date of birth" will always be valid. The same cannot be said for instances of "person", which may or may not have these qualities. Summing up: there can be both a "Template:Constraint:Person" and a "Template:Constraint:Human", but the second one will be more relevant and it will be more useful. Btw, I replaced "<human> subclass of <person>", for "<human> manifestation of <person>" which might help to clarify this distinction.--Micru (talk) 09:39, 20 October 2014 (UTC)
@Shlomo: Thank you for your work on Wikidata and your four thousands contributions.
When you see a constraint, you can examine the items used to respect this constraint to see how it works.
For example here, any instance of or subclass of person validates this something (I hope manifestation too, or we need to change our system).
The goal is to have a hierarchical tree.
Let's look to the person constraint. It fills the goal to have a being with a date of birth, a place of birth, a gender. It's currently mainly used by human (Q5) but also by fictional character (Q95074). And in a speculative future, it could also be used for IA and non human beings. We so have an agnostic notion of person, fulfilling any need we have or could have in the future. And currently, we mainly use human (Q5) and fictional character (Q95074) to sort persons.
Please also note there are currently more than one million items with the instance of (P31) : human (Q5) claim.
If you wish to explore how more complex Wikidata mechanisms works like properties and items relationship, you could maybe try a participation to a new project to improve data on a new kind of items not yet well described, that would allow you to see a little how things work on this point of view. That will get you a stronger knowledge of the project and so you will be able to offer better proposals. Don't also hesitate to create an user page to explain your goal and activity here. --Dereckson (talk) 13:49, 20 October 2014 (UTC)
Thanks for explanation. If I now understand it right, the really and undoubtedly existing people can (even should) have instance of (P31) human (Q5) (because it's more specific for them) and the constraints demanding the items to be person (Q215627) won't report a violence, since it is a subclass. And the eventual question whether the constraint defined for a particular property shouldn't better demand a human (Q5) than a person (Q215627) let's discuss at the property discussion page...--Shlomo (talk) 14:40, 20 October 2014 (UTC)
Yes. Note that as well as {fictional character (Q95074) we also have biblical character ( Q14943515) and legendary character ( Q16934977) for cases where there is some doubt as to whether a character is or is not fictional. I would say that we should not, in practice, be using instance of (P31):person (Q215627) for any people. we should always use one of it's subclasses. Filceolaire (talk) 17:38, 20 October 2014 (UTC)

website account on (P553)[edit]

Regarding website account on (P553), should we list an account if the website lists it as a verified account? And with Facebook, do we only list accounts or can pages be added too? --AmaryllisGardener talk 15:50, 20 October 2014 (UTC)

Here is my personal practice filling these properties. I personally use the official person/corporate/organization website to add these links, so instead to apply a rule "only accepted Twitter verified accounts", I use the rule "use a trustable source for the websites account". Doing that, I added Facebook pages (which are a lot more frequent than regular accounts for Wikidate notable items' subjects). --Dereckson (talk) 16:53, 20 October 2014 (UTC)

Item Left (Q3556716) for disambiguation pages[edit]

What should I do with this 'disamb' page. In my opinion this disamb page is not correct and should be splitted into 12 or so different disamb pages with only identical names. (And p461 should not be on a disamb page). Is that ok? Michiel1972 (talk) 23:14, 20 October 2014 (UTC)

It looks fine to me. A wikipedia page is a concept, and if the concept is the same in a different language, then it does not matter what it is called in that language. It is a little bit odd to have something be the opposite of a disambiguation page, but what they did is choose the disambiguation page that is for the opposite of the subject that is being distinguished. 06:27, 21 October 2014 (UTC)
In my opinion, we should definitely split this item. The linked disam pages do not only deal with the direction but also with music albums called "Left", people with last name "Links" or "Ezkerra" or a wind with name شمال (north) --Pasleim (talk) 07:50, 21 October 2014 (UTC)
Yes, it should be splitted, but there should be a way to present all this similar disambiguation pages (or a link to a list of them), near to the "Languages" list on the sidebars of all this disambiguation pages to the Wikipedia readers. Maybe the Wikidata items should populate a item group for Translations of Left. --Diwas (talk) 11:34, 21 October 2014 (UTC)
Surely you are joking. That is what a "disambiguation" page is. Disambiguation is not just a big word that means "put a squiggly fork template here". It means "this title has more than one use in this language", and the fact that it means different collections of things in different languages is completely irrelevant. 13:50, 21 October 2014 (UTC)
The fork list (of items) should not be putted on the disambiguation pages, but (as one? link) near to the languages list. A (link to a) list of some discrete items, but not a mess on disambiguation pages and not a mess in one item. --Diwas (talk) 23:16, 21 October 2014 (UTC)
IMHO Wikidata:WikiProject Disambiguation pages/guidelines is too strict, but still this is an example of a disambiguation page that should be split. Lymantria (talk) 15:15, 21 October 2014 (UTC)
Speaking of "too strict", why is this a requirement? "The item should only contain links to Wikipedia disambiguation pages with the exact same spelling" How can we dictate what each Wikipedia wants to put on their disambiguation page? Why should we exclude one just because they think it is important to add items that are not spelled exactly the same? 16:31, 21 October 2014 (UTC)
For me, it is too strict too, but the same spelling is not a requirement for each listet element of the disambiguation page, but only for the title of the disambiguation page. But we will never get consensus for each grade of variance, if it should be splittet or not. And (maybe in the future) one language version will contain two disambiguation pages for two different spellings, and then the previous one item will going to be splitted. Then it will be helpful to have a short fork list of this two different but similar items. --Diwas (talk) 23:54, 21 October 2014 (UTC)
I must not be understanding what you are saying. To use the Left page as an example, it is very likely only spelled "Left" in English. There is a br dis page, but it was not Kleiz, but Kleiz (disheñvelout), and that has been corrected. Since many languages are sensitive to variables, the fact that the de page includes both Links and Linke or that the el page uses αριστερά and Αριστεράς disqualifying them from being called a dis page here is absurd, and obviously that guideline needs to be revised, as it is pathetically false that all of the things listed have to be spelled the same as in the title of the disambiguation page. 21:02, 22 October 2014 (UTC)
Yes is necessary to split item --ValterVB (talk) 18:03, 21 October 2014 (UTC) ps brwiki isn't a disambiguation page.
The Wikipedias tend to describe different variants or aspects of the general concept of 'left' (or izquierda, or whatever) in separate articles. Like political left, left-handedness etc. Hence the majority of articles which are mentioned on these disambiguation pages are for different aspects of the same. Is Bretonic the only language to have an article on the general concept at all? There is a good reason to link these pages, such links are helpful for readers interested in other languages.
Although there is a 'guideline' which suggests that this item should be split, why should this guideline be implemented in every case? What is the harm if we leave it as it is, as long as there are no interwiki conflicts? Bever (talk) 01:17, 22 October 2014 (UTC)
Disambiguation pages either can be aggregated by label or by concept. Most of them are by label, but in this case the label is so close to the concept that it might make sense to leave it like that. Some exceptions are needed to make a rule, right? :) --Micru (talk) 08:52, 22 October 2014 (UTC)
Pages like br:Kleiz are a good reason to have an additional way to link similar but different items. We should not mix it with disambiguation pages in the disambiguation pages item, but should give it an own item and link that in an item (one level higher) for pages (lists, disambiguation pages, articles) about the general concept. --Diwas (talk) 12:30, 22 October 2014 (UTC)
br:Kleiz was not a dis page, but was a page that describes left and several other uses of Kleiz. A disambiguation page can not have any content other than a minimal description. Once content is added, it is a page about that content and no longer a disambiguation page. It was removed and placed in the left (position) page, and replaced with the br:Kleiz (disheñvelout) page, which is a dis page. 21:59, 22 October 2014 (UTC)
I would agree with keeping this item unsplit if only the "concept" left gave reason to make the disambiguation. But now both spelling (e.g.: German and Dutch have a browser "Links" among their linked pages) and concept do and that does make it messy. Now we have to make a decision: Merge Links (Q11984152) into Left (Q3556716)? How about Sinister (Q10668323), because of the Latin link, or even Left (Q10316880)? To solve this mess splitting is needed. Lymantria (talk) 17:03, 22 October 2014 (UTC)
I have split the item.--GZWDer (talk) 05:50, 23 October 2014 (UTC)
That was a bit pre-mature, and pretty odd to only have the criteria that everything on the page use the same spelling as the English word "Left". What you ended up with is linking two disambiguation pages that have no pages in common with each other. And a dozen disambiguation pages for left that have no indication that there is an English disambiguation page for left. If you are going to "split" it how about start by removing the only page that you left - the one that has nothing to do with left? Wikidata pages refer to meaning, not spelling. The word gift in Swedish means poison, you can not link it to a disambiguation page for the english word gift, for example, just because it is spelled the same. And you linked the fr entry with en Gauche, even though the two dis pages have no links about the same subject. Ditto for la - you just linked to the English dis word for Sinister because they are spelled the same and the two dis pages have no links in common. It is always only meaning that causes a link, never spelling. I suggest just reverting all of your edits and starting over in a more meaningful manner. I am beginning to see how someone would say that the new wikidata links are useless when people make choices like this in grouping pages. The inherent problem is that the old way only native speakers were dictating where links were going, here someone who knows nothing about the language is deciding. Looking at the table I see none of these that need to be removed. 08:38, 23 October 2014 (UTC)
Language Page Link1 Link2 Link3 Link4 Link5 Link6
ar ‎(يسار (توضيح left (direction) Left-wing politics Suleiman ibn Yasar
br Kleiz (disheñvelout) left (direction) chalk
de Links left and right (directions) left (politics) link(computer hyperlink) Links (web browser) golf course (links) people and companies named link
el Αριστερά left (politics) left (direction)
en Left left (direction) Left (album) left (politics) Left (Marxist)
es Izquierda (desambiguación) many political parties left (direction) left handed left hand rule
eu Ezkerra (argipena) surname left (politics) left (direction) left handed
fa چپ left handed left (politics) political party
fr Gauche left (politics) political party political movement metallurgy (a "left" is a piece that is twisted) clumsy left (direction)
he שמאל left (direction) left handed left (politics) Left Hand of Darkness (book) wind from the left
ja レフト left fielder (baseball) a volleyball term left (politics)
la Sinister German political party Italian political party
lb Lénks left (direction) left (politics) homosexual
nl Links left (direction) left (politics) left handed Links (film) Links (web browser)
ro Stânga left (direction) left (politics) political party left handed copyleft (a PD form of copyright)
zh left (direction) left (politics) surname copyleft

Since there are no interwiki conflicts I would merge de/nl/lb as one item and eu/es/el as another. --Diwas (talk) 23:37, 23 October 2014 (UTC)

My idea and reason is at User talk:YMS#Disambiguation page, and Wikidata:Project_chat/Archive/2013/11#Disambig_page_link.--GZWDer (talk) 10:01, 23 October 2014 (UTC)
That is a ridiculous idea. When we link wikidata pages for pages we link everything that has the same meaning. We do not link en:Gift with sv:Gift, because the words have different meanings. In Swedish Gift means poison. So we link en:Poison with sv:Gift. What we have to do is look at how the word is used on the disambiguation page, and link it to another disambiguation page with the same meaning. For example left, in English is a direction, but that same direction is called Gauche in French, so we link the en:Left dis page to the fr:Gauche page. It is meaningless to link the en:Gauche dis page to the fr:Gauche page, because none of the pages on either dis page are about the same subjects. In English, Gauche has a very different meaning than "left". When the disambiguation page guidelines talk about the same identical spelling, they mean on the wikipedia disambiguation page, so for example by our guideline, which is also absurd, we could not have any link at all to en:Left as per our guideline it is not a disambiguation page, because it includes items that are not spelled "Left", but instead includes "Left-wing politics". That is why that strict requirement is absurd. It does not mean that every item on the wikidata page has to be spelled the same in every language, which is even more absurd, but that is exactly what you have done. 10:37, 23 October 2014 (UTC)
FYI, it is possible from reading the discussion page that adopted that guideline, that is what the guideline says, and it was adopted with near unanimous support, with the comment, "IMO all articles on a one item have to be the same title. E.g. English disambiguation site "Yellow" should be Yellow in other wikis too, not translated name." That of course is ludicrous, as you can not tell someone that their disambiguation page for the color yellow can not be linked to every other disambiguation page for the color yellow, but you have to only link your disambiguation page for the color yellow for disambiguation pages in other languages that use a word that is spelled using the latin characters "Y E L L O W" even if that word has a totally different meaning in that language, such as, "a bath tub stopper". That idiocy has just been done in splitting this page, where "gauche" has been linked from the en word gauche to the fr word gauche, and since the word in English does not mean the same thing in English as it does in French, none of the links on the en page are the same as any of the links on the fr page. Another example is in Swedish "gift" means poison, so if that guideline was followed, a disambiguation page for sv "poison" would be linked to an en "gift" page, once again obviously with no links in common. Another preposterous statement appears in the discussion - "i. e., how can we tell which pages deal with the same item?" Why is that even a question? See the table above. There were some items on the linked pages that I could not identify because they go to red links, but it was not hard to generate the able and see what the links were. Just as a wikidata page for "Yellow Brick Road (song by Eminem)" is only going to have links to other language articles about that same subject, a wikitable page for the disambiguation page for "Yellow Brick Road" is going to have link to other disambiguation pages about the road in the Wizard of Oz, which of course has different translations in different language, as indicated on Yellow brick road (Q3444039), which right now has only 3 entries. And none of the others use the words "yellow brick road". But if there was a disambiguation page for any of them, they should all be linked to the other disambiguation pages. Right now Wikipedia is really only in English and a few other languages, and has not been "built out" into most of the other languages of the world, but when it does, the purpose of wikidata is to link all of the pages that are about the same subject, not pages that use the same spelling, which would be nonsense.
So instead of making hash of things, such as was done for the perfectly good page of "left as a direction or political direction disambiguation page" (fortunately some of the local wikis still use local interwiki links and not the totally useless links that are now provided), and making it into a "page of disambiguation pages on wikis that use a word that is spelled "left" using only latin characters with special characters such as accents or that are pronounced like the English word "left" but use characters that have a similar pronunciation, which is totally useless to anyone, as it is going to for most languages inherently going to be only a wikidata link to itself, totally making the entire wikidata project useless for any wikipedia disambiguation pages, I would suggest putting an immediate hold on implementing that aspect of the guideline, as it is sheer nonsense. 18:31, 23 October 2014 (UTC)
Yellow isn't «a disambiguation page for the color yellow» but a disambiguation page for the word Yellow. In disambiguation page you can found a movie of Cassavetas, a single of Coldplay, a manga of Makoto Tateno and in English also the color yellow. This is the use of disambiguation pages, if you join page with the same meaning you have a list that is another thing. --ValterVB (talk) 19:40, 23 October 2014 (UTC)
That is not useful. We always only have pages that are based on meaning, not on spelling, why would disambiguation be any different? How is it useful to line en:gift with sv:poison just because the word for "poison" is spelled "g-i-f-t" in Swedish? This is sheer stupidity to link disambiguation pages differently than every other type of page. 20:33, 23 October 2014 (UTC)
Disambiguation must be different because are very special pages, They have specific category, specific template and mediawiki software manage they with specific "magic word", there are some SPecial page like Special:DisambiguationPageLinks or Special:DisambiguationPages. They are necessary to guide user to the correct page. If I search Left I want something called Left, not something called Stânga so with disambiguation page I can select the page that I want. --ValterVB (talk) 21:03, 23 October 2014 (UTC)
Fortunately most of the disambiguation pages I have seen do not follow that absurdity, but instead in fact do use the meaning. For example, the disambiguation page for ja:yellow does not use one named "yellow", but instead groups all of the other uses of the color yellow, which in japanese is called "黄色", and by the guideline would not be included on the color yellow disambiguation page but would be on its own page, and be totally useless (a wikidata page is only useful if there is more than one wikipedia link on it). 20:56, 23 October 2014 (UTC)
Wikidata isn't only for Wikipedia projects. For no-latin alphabet, transcription is acceptable if don't exist the same word, but if exist we must link this (ex. A10 (Q228260) the japanese link is A10 in latin alphabet). --ValterVB (talk) 21:19, 23 October 2014 (UTC)
That does not address the issue that translations are important to use, and are much more important to use than either literal spelling (see the example of gift/poison) or transcription. For example, if some other language used a transcription of gift, but the same meaning as in Swedish, poison, instead of something that is given, it is not useful - the principle being that only meanings are important, never spelling. 02:02, 24 October 2014 (UTC)
Your principle that spelling is never important is not widespread in this community, as you can see by the accepted guideline on disambiguation pages. The problem with disambiguation pages and meanings/translations is that, per se, disambiguation pages cover homonyms in a language, of which often it is not clear what the "leading meaning" is. The set of homonyms differs from language to language. Therefore the wikidata-community chose to make spelling important in case of disambiguation pages. And it certainly turns out to be useful. Lymantria (talk) 11:38, 24 October 2014 (UTC)
Yes spelling can be important - but only for proper names. All that avoiding translations does is create Wikidata pages with only one entry, and when there are more than one, such as Left now, those two entries have nothing to do with each other (the Hebrew word for left has now been added, which of course is a violation of the guideline, unless it is pronounced "left"). Ditto for Gauche, which has been linked between fr and en, but since the words have different meanings, there are no pages on either dis page that are in common. Normally when you go to a disambiguation page, you find a list of the subjects that have a corresponding article in every language, which was how everyone created local interwiki links. Now we have en:gift dis linked to no:gift dis, but in Norwegian, "gift" means "poison", so the link is useless. The fact that other Homonyms exist in each language is simply not important. There can only be one Wikidata page for every page, so you just have to choose which page you are going to link it to (in de left is Links, so you can either make a link to a Wikidata page on people named Links, or the direction left, but not both), but you certainly are never going to link en:gauche with fr:gauche, or en:gift with no:gift, because they have different meanings in those languages. When you do look at the Wikidata pages for disambiguation pages, you will see that almost none of them follow the guideline, and instead use the translations to make the links. "Fixing" them, would be a disaster. 01:54, 25 October 2014 (UTC)
I would actually call it a flaw of Wikidata that you can not link to more than one page, because with local links you can, and of course if they are needed, local links can still be used, to avoid that limitation. These are the interwiki links that the German Links disambiguation page used, prior to migrating to Wikidata, and they link to the word in some languages meaning left, venstre, but include a link to the English page Venstre, which of course means neither left nor Links. 02:39, 25 October 2014 (UTC)
Of these I would call the en, es, fr, and it links incorrect, because none of the political parties on those pages are on the de:Links dis page. 02:39, 25 October 2014 (UTC)
FYI the idiocy of linking en:gift with no:gift (poison) predates Wikidata, and was placed on the en page in 2007. I am not particularly surprised that no one noticed the error, though. 02:54, 25 October 2014 (UTC)
I think the criticism of is a good incentive to rethink some concepts on Wikidata and Wikipedia. Although disambiguation pages are primarily a tool for navigation when a user uses the search box, meanings do play a role when grouping links and information on them. The present guideline is too one-sided when ruling out this aspect.
On Wikipedia, I sometimes feel that the idea that disambiguation pages must not give any information (other than links) is in some cases too strict. It seems also that different versions of Wikipedia (and other Wikimedia projects) have different guidelines or practices regarding disambiguation pages, which can cause problems on Wikidata (interwiki conflicts). also points at the reduction of useful interwiki links since the roll-out of Wikidata, which is not always in the interest of the end-user. In my opinion this is caused by some inherent conflicts in Wikidata, but they might be solvable. Bever (talk) 03:54, 25 October 2014 (UTC)

Disambiguation pages are simply lists of "things known as X". As such, they should only be linked to similar lists of things called X on other language projects, not to pages with one arbitrarily chosen translation out of many of "X". These pages are about that particular string of letters (e.g. "l-e-f-t"), not about the meaning(s) behind it. Many, many words have several equally viable translations in other languages, so we're not looking at 1:1 relationships, but in most cases at 1:n or even n:n. Arbitrarily chosing just one translation might be a simple solution, but as it's often the case with simple solutions, this doesn't really work all that well, neither from an encyclopedic nor from a technical standpoint. The current guidelines are much better than what we had before, when interwiki links on disambiguation pages were changed from one translation to the other and back all the time and whole groups of interwiki links were moved between disambig pages because one person preferred one translation from language 1 to language 2 over another, which in turn influenced translations between language 2 and language 3 and so on... -- 10:55, 25 October 2014 (UTC)

You know, many things can have several names, and these names often are some variations of the one one (e.g. synonims, or translations). So a list of "things known as X" easily can be a list of "things known as <translation of X>" in other language. --Infovarius (talk) 13:55, 25 October 2014 (UTC)

Language column[edit]

First, I would like to note that Wikidata pages are very slow to load, I am not sure if that is just because it takes a long time to look up all the data, but is there any reason to display the language column in native language? Often I am looking for say, Slovenian, and have no idea what it is called in Slovenian (or worse, one of the many languages which to me just uses a bunch of squiggly letters - which is no doubt what they think of English). If I know the two letter code I can find it from that, but often I do not know the code. So I would suggest considering translating the language column into the selected language. That of course only needs to be done once, and is the same for every page. I would also though, suggest than when you put your mouse over the language you see the language in the native language. Right now I am making lists from the wikidata pages of what languages a particular article is in, and the language column is useless to me because it is in native language. On the wikipedia's, of course, it is useful to make the language be in native language, but on wikidata it serves no purpose, in my opinion, as everyone is already viewing that page in their own native language. 06:18, 21 October 2014 (UTC)

I can confirm the issue with the value being displayed in English once entering one and filed a bug for this. Thank you for reporting this. We are also aware of the loading time issue and working on it. Aude (talk) 22:12, 22 October 2014 (UTC)
Your bugzilla bug does not address the issue that I brought up. Here is what I am saying. I will use Giuseppe Porta (Q3108131) as an example. This is what it looks like in English:
Language Code Linked page
English enwiki Giuseppe Porta
français frwiki Giuseppe Porta
italiano itwiki Giuseppe Porta

This is what I want it to look like in English

Language Code Linked page
English enwiki Giuseppe Porta
French frwiki Giuseppe Porta
Italian itwiki Giuseppe Porta

and in French

Langue Code Page liée
anglais enwiki Giuseppe Porta
français frwiki Giuseppe Porta
italien itwiki Giuseppe Porta

and in Thai

ภาษา รหัส หน้าลิงค์
ภาษาอังกฤษ (with a mouse over to say English) enwiki Giuseppe Porta
ภาษาฝรั่งเศส (with a mouse over to say français) frwiki Giuseppe Porta
ภาษาอิตาลี (with a mouse over to say italiano) itwiki Giuseppe Porta

and in Chinese

语言 代码 链接的页面
英语 enwiki Giuseppe Porta
法语 frwiki Giuseppe Porta
意大利语 itwiki Giuseppe Porta

The column headings are translated (or should be - Thai is still in English), but the Language column is the one that I want translated. All of them can have a native language mouse over, I only showed the one for Thai. -- 10:19, 23 October 2014 (UTC)

Ah, yes I understand now and filed a new bug for this: Aude (talk) 13:17, 23 October 2014 (UTC)
Thanks. 18:48, 23 October 2014 (UTC)

BIG problem with date adding[edit]

I just tried to add dates of birth and death on Q2831659, but got The time value is malformed after typing the date in the property as usual (in French)... impossible to validate it… the field now accepts only English format or xxxx-mm-dd format :(

what happened ? --Hsarrazin (talk) 12:53, 22 October 2014 (UTC)

+1 yes, i got the same problem, adding timedata to film or band article. Layout is german but only accept is english. And all text i insert is known in german but shown in english. --Crazy1880 (talk) 15:10, 22 October 2014 (UTC)
moreover, all references (sources) are now displayed in English, instead of interface language…  :( --Hsarrazin (talk) 17:06, 22 October 2014 (UTC)
same with me editing in German :(--Oursana (talk) 18:15, 22 October 2014 (UTC)
It looks like these api requests (formatting and parsing values) are not getting or using the language correctly. It's probably the same issue that affects both entering dates and formatting, and filed a bug for this. [1] Aude (talk) 13:41, 23 October 2014 (UTC)

type of[edit]

Steak burger (Q18338265), for example, is not really an "Instance of" something (a sandwich), but a "type of" sandwich. Should we have a "Type of" property, as well as instance of? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:07, 22 October 2014 (UTC)

Steak burger (Q18338265) subclass of (P279) something. --Diwas (talk) 19:17, 22 October 2014 (UTC)
Thanks, but does that work instead of instance of? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 22 October 2014 (UTC)
Yes, instead of instance of. There are tons of steak burgers, and there are subclasses of it, like the Burger King Sirloin Steak sandwiches or like all steak burgers you eat ever, but the one you bite maybe tomorrow is an instance of Steak burger (Q18338265) and an instance of the subclass of your own steak burgers. --Diwas (talk) 23:12, 22 October 2014 (UTC)
There is a nice tool for browsing subclasses, which can display, for example in this case, subclasses of "food product" as a tree or as a list. So many sausages!
Sometimes I have been confused about whether to call something an instance or a subclass. There's some explanation at Help:Basic membership properties, but I would really like a list of examples, and ideally parallel lists aligned by property, e.g. instances of human versus subclasses of human. --Haplology (talk) 09:29, 23 October 2014 (UTC)

@Diwas: @Haplology: Thanks, both, Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:23, 23 October 2014 (UTC)

WMF grant proposal including Wikidata outreach[edit]

Wikimedia DC has submitted a grant proposal to the Wikimedia Foundation to cover some of its program costs for the fiscal year, including planned outreach around Wikidata. See meta:Grants:PEG/WM_US-DC/Projects_2015#Civic technology outreach. Please feel free to comment on the grant proposal. Thank you, Harej (talk) 21:17, 22 October 2014 (UTC)

what P31 for "1980 in xxxx" (year list of events) ?[edit]

What instance of (P31) should I use for all those 1980 in France, 1945 in football, items ?

Is chronicle (Q185363) that I've seen on some of those items OK ? or should I just use Q18288183 (Q18288183) ? or is there another item ? Thanks for help, since those items are accumulating just now… --Hsarrazin (talk) 15:00, 23 October 2014 (UTC)

1980 in France is not a real chronicle (Q185363), since it is just a title of an overview article created by wikipedians. So I would suggest to make an item Wikimedia year chronicle similar with Wikimedia history article (Q17524420). Michiel1972 (talk) 09:30, 24 October 2014 (UTC)
I created Wikimedia chronicle page (Q18340514). Michiel1972 (talk) 09:39, 24 October 2014 (UTC)

Commons AND Commonscat[edit]

Sorry, I'm not confident with the structure of WD, and I didn't have a look. But I cannot assign a commons page AND a commons category to the same item in WD. Why? Many times there are both a page and a category and the articles in the WPs in different languages follow different strategies to use pages or categories to link to Commons content. It would be helpful to allow the assignment of both a page AND a category in parallel. If the item is assigned to the page, I cannot assign the same item to the corresponding category. Which puts me back to using old interwiki syntax. Or is there already a policy on that topic. Different people obviously do it differently. Feel free to move this discussion to the right place. --Herzi Pinki (talk) 16:25, 23 October 2014 (UTC)

You add Commons category on the WD item about the category, and the Commons page on the WD item about the page. Like this: Category:Paris (Q5626403) (Commons:Category:Paris) and this: Paris (Q90) (Commons:Paris). Hope this will help you. --Harmonia Amanda (talk) 16:53, 23 October 2014 (UTC)
@Herzi Pinki:. It's a known problem. See c:Commons:Structured_data/Short_introduction_to_Wikidata#Commons-Wikidata_sitelinks for some discussion. But yes, at the moment it means that Commons categories are not to be directly sitelinked to article-like Wikidata items.
What we may do soon, though, is to roll out a template to go on Commons categories, to link them to an article-like page on Reasonator (eg this for Paris), that would provide further wikilinks. But the identifier for the article-like item would probably need to be explicitly included as a parameter to the template, because it's not the same as the category-like item the category would naturally be linked to; and in any case most Commons categories don't have any category-like item.
For Commons galleries, we should be able to do something more sophisticated. A very very basic prototype for a Commons gallery header can be seen at d:Template:SimpleCommonsGalleryHeader/test. To implement this requires Phase 2 access to Wikidata to be enabled for Commons; an RfC to request this is now open on Commons. Jheald (talk) 12:57, 24 October 2014 (UTC)

Impending deletion of Persondata template and associated metadata[edit]

English Wikipedians are chomping at the bit to delete the Persondata template from all the biography articles on English Wikipedia (currently included on 1.2 million articles). This is a hidden template (similar to the Personendaten template on German Wikipedia) that holds human-curated metadata about biographical articles. In the past month there has been an RfC and a TfD about deleting the template. Both reached the consensus that the template should be deleted as soon as all the metadata is migrated to Wikidata. This data includes:

  • NAME -> probably doesn't need to be imported
  • ALTERNATIVE NAMES -> Wikidata aliases
  • SHORT DESCRIPTION -> Wikidata description
  • DATE OF BIRTH -> Property:P569
  • PLACE OF BIRTH -> Property:P19
  • DATE OF DEATH -> Property:P570
  • PLACE OF DEATH -> Property:P20

While some of this data has already been imported, much of it has not, especially descriptions and aliases. Are there any bot writers that would like to help import this valuable collection of metadata before it gets deleted? Kaldari (talk) 18:06, 23 October 2014 (UTC)

I am not sure if it's enough to use labels and aliases to replace these templates. We need real name-properties. -- Innocent bystander (talk) 18:16, 23 October 2014 (UTC)
Can you elaborate? Are you referring to importing the NAME as a sortable name? The aliases can probably be imported as is. Kaldari (talk) 18:21, 23 October 2014 (UTC)
I have not been active here the last months, but properties for name, birthname etc should be created as soon as technically possible. And NAME/ALTERNATIVE NAMES should use such properties, to be able to add statements and sources. -- Innocent bystander (talk) 18:28, 23 October 2014 (UTC)
Regarding: "import this valuable collection of metadata before it gets deleted" - as far as I understand the outcome of the RfC in English Wikipedia, there's no danger that metadata will be deleted prematurely. No one wants to lose data, I suppose. The Persondata template in English Wikipedia can/will be deleted when it's really made obsolete by Wikidata, but not before. - Likewise, I think also the data from German Personendaten should be imported here, of course. Gestumblindi (talk) 20:53, 23 October 2014 (UTC)

I've posted a bot request. Kaldari (talk) 18:21, 23 October 2014 (UTC)

Morning, I think it will be make sense to import the data for german Wikipedia, too. So I leave a text at the botrequest --Crazy1880 (talk) 05:31, 24 October 2014 (UTC)
Supplement to the text of Kaldari. The name is usually represented as follows: NAME = Property:P735, Property:P734. --Crazy1880 (talk) 05:43, 24 October 2014 (UTC)

One thing that there is in Personadata is the name in the order it should be sorted in. (Which can be non-trivial). This is something we really ought to have in Wikidata, to be able to easily sort the output of WDQ queries. It would also be useful to have, eg for c:Commons:Structured data, to be able to sort search hits or a category by artist. Can we please import this as a string. This may need the creation of a new property to store it in. Jheald (talk) 09:23, 24 October 2014 (UTC)

Proposal posted; see Wikidata:Property proposal/Generic#Sort_key.

If entered properly, the birth and death dates in Persondata follow WP:Manual of Style; the details are contained in WP:Manual of Style/Dates and numbers (MOSNUM) which calls for using the Julian calendar on and before 4 October 1582. After that, the Gregorian calendar is used, if it was in force in the location(s) discussed in the article. If the Julian calendar was in force in the relevant location(s), it is used. MOSNUM is not explicit about what to do if the relevant location used some other calendar, and it is in the period where the Gregorian calendar had not fully supplanted the Julian calendar. Persondata does not have any flag to indicate if the Gregorian or Julian calendar was used. This makes it essentially impossible for a bot to import dates before 1924, the first full year Greece adopted the Gregorian calendar for secular use. I will repeat this comment in the bot request. Jc3s5h (talk) 14:45, 24 October 2014 (UTC)

I've replied there. I suggest we all agree to conduct discussion in one, not two, places. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:37, 24 October 2014 (UTC)

Redirects cause bad merges[edit]

A good-faith edit by User:Styko, discussed at User talk:Styko#Q18339801, in which they used the "edit links" feature in the sidebar of a Wikipedia article, caused the merge of two items on related, but different, topics, due to a redirect. How can such problems be avoided? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:21, 23 October 2014 (UTC)

The problem was caused because a link was made to a redirect. Redirects can not have wikidata links, and it has been removed. There used to be an en article about the subject[2] but it was deleted and changed into a redirect. When that was done the wikidata link needed to be removed. 12:17, 25 October 2014 (UTC)
No, you are wrong. Redirects can have wikidata links, but for now adding them is quite non-obvious. This example shows that redirect link in an item is useful, because it helps to get specific information even if it is in the other article now. --Infovarius (talk) 14:10, 25 October 2014 (UTC)

Wikidata-Templates for Wikipedia[edit]


I tried to find an answer to the following question on several development related pages, but haven't found the answer.

Will it sometime be possible to have some kind of Wikidata templates, i.e. templates that are filled with data here on Wikidata and can be used in the various Wikipedias out there. Use cases I am thinking of might be

- international infoboxes, i.e. an infobox is created once and just has to be translated and/or changed in design on that basis to be included from the local Wikipedias - international templates, e.g. tournament tables - imagine we would only have to fill out the results from any sports tournament once and have it available in all Wikipedias.

Would be nice if you could point me in the right direction, thanks in advance. --Mad melone (talk) 13:53, 24 October 2014 (UTC)

You are absolutely right. Wikidata is made exactly for this purpose. The use of templates that get the informations out of Wikidata is possible allready and it is not so difficult to use ist. Just put {{#invoke:Wikidata|claim|P217}} to get the value of inventory number (P217) in your template or {{#invoke:Wikidata|labelOf}} to get the label of the item in your template. However you need to create all necessary properties and source them. You have to make sure that all information is stored on Wikidata prior to using it in a template.--Giftzwerg 88 (talk) 16:00, 24 October 2014 (UTC)
There is still another issue: There are still some datatypes missing. We are not able to store all kinds of datata now. This is something the programmers are still at work. Lots of properties are not created until now because, the datatypes are missing. Unfortunately I can not find the documentation to all the possibilities of templates using wikidata. There is even a discussion to centralize the templates just as commons does with files. Then it will be possible to write a template once and use it in every wikipedia without having to copy it multiple times for all the wikipedias just by placing the name of the template into the pages. Many communities still debate if they want to use Wikidata at all. There is no activity to encourage users to write templates that use Wikidata, because there are still many issues and bugs to fix. But if you want it, you can use it with some limitations.--Giftzwerg 88 (talk) 16:43, 24 October 2014 (UTC)
Thanks for your swift reply. However, it is more about what you wrote in your second reply: especially things like tournament tables or all kind of sport results mostly have just a name and a result. But if we do this work for each local wikipedia with the respective language template, then we would have to fill out the template as many times as there are wikipedia articles in the different languages. So why not get these data at one template that might be translated, but all uses the same underlying data, e.g. sports results only would have to be updated once. I know that there are discussions on many wikipedias on whether to use wikidata at all, but this question is not about how to use wikidata in templates, but how enter data into templates once for all wikipedias.
In general, I was just curious whether this was on the development map at all or not.--Mad melone (talk) 08:30, 25 October 2014 (UTC)

Changing datatype[edit]

Is it possible to change a property's datatype? The property legal citation of this text (P1031) is a string, but for the sake of obsessive completeness, I'd like it to be monolingual text so that Canadian legislation to include the official English reference and official French reference (even though they're almost the same, English's "RSC 1985 c C-46 s 745" is French's "LRC 1985 c C-46 art 745). --Arctic.gnome (talk) 18:39, 24 October 2014 (UTC)

I can not even see any way to create a property, let alone set the datatype. Help:Data type describes the datatype but does not say how to change it. 06:01, 25 October 2014 (UTC)
It's not possible to change a datatype. The only way is to create a new property and delete the old one so you might first start a discussion at WD:PFD. --Pasleim (talk) 12:31, 25 October 2014 (UTC)

Can not edit (is this page protected?)[edit]

I had tried to add anatomical properties at rectum (Q158716). But, to me, there are no 'edit button'. Is this page protected? I want to add A05.7.04.001 to TA98 and 14544 to FMA. Thanks. --Was a bee (talk) 02:21, 25 October 2014 (UTC)

@Was a bee: Checked, it's not protected from what I see. I can't edit it either. --AmaryllisGardener talk 02:23, 25 October 2014 (UTC)
I cannot see what you are trying to add, but none of the Wikidata data pages have an edit tab at the top - I see all the usual edit links, and when I click on them they open as usual. 05:17, 25 October 2014 (UTC)
Thank you @AmaryllisGardener:, @ Now I can see edit links at that page. Hmm... mysterious phenomenon. But anyway, now it's ok. Thanks :D --Was a bee (talk) 07:31, 25 October 2014 (UTC)
Yes, it is a bizarre and unfamiliar user interface, very different from what anyone who is familiar with editing wikipedia is expecting. 12:11, 25 October 2014 (UTC)

LUA test to see if qualifier is used[edit]

Hi everyone, for Wikidata:Coordinates tracking we have some logic to see if coordinate location (P625) is used. If that's the case the article ends up in Category:Coordinates on Wikidata (Q15181105), if not it ends up in Category:Coordinates not on Wikidata (Q15181099) so we can import it. Now we run into an interesting edge case: For some people and companies coordinates are listed. For people this is usually the burial location and for companies the headquarters location. See or example BMW (Q26678). Could someone make a snippet of LUA code to check if a property is used as a qualifier in an item? It should return true in the BMW example. Than we can update the template for the tracking to remove the false positives. Multichill (talk) 11:16, 25 October 2014 (UTC)

Maybe something like:
function checkCoor(property)
 if property and property ~= '' then
  local property =
  local entity = mw.wikibase.getEntityObject()
  if and[property] then
   for i, statement in pairs([property]) do
    if statement.qualifiers and statement.qualifiers[P625] then
     for j, qualifier in pairs(statement.qualifiers[P625]) do
      if qualifier and qualifier.datavalue and qualifier.snaktype == "value" then
       return qualifier.datavalue.value.latitude .. ' ' .. qualifier.datavalue.value.longitude
 return nil
local p = {}
function p.qualifierInUse(frame)
 if checkCoor( ~= nil then
  return true
  return false
return p

Usage: {{#invoke:"Modulename"|checkCoor|property=p##}}, returns "latitude longtitude" or nothing. I'm not programmer so there may be errors. Matěj Suchánek (talk) 12:01, 25 October 2014 (UTC)

That's already a bit more than I needed :-). Probably could have a more general function qualifierInUse(<some property>) than just returns True or False. Multichill (talk) 12:34, 25 October 2014 (UTC)
If you use it in wikitext, you can use {{#if: {{#invoke:}} | }}. I made a change to the code. Matěj Suchánek (talk) 13:01, 25 October 2014 (UTC)