Shortcut: WD:PC

Wikidata:Project chat

From Wikidata
Jump to: navigation, search
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Also see status updates to keep up-to-date on important things around Wikidata.
Requests for deletions and merges 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 2015/05.

Chinese question[edit]

Is there an equivalent of Wikipedia:WikiProject China (Q10816953) or Wikipedia:Proposed mergers (Q6596462) in Wikidata ? Visite fortuitement prolongée (talk) 13:26, 19 April 2015 (UTC)

There are some proposed merges: User:Byrial/countrymerge, User:Byrial/numbermerge, User:Ivan A. Krestinin/To merge, User:Pasleim/projectmerge. --Infovarius (talk) 05:39, 22 April 2015 (UTC)

What is the meaning of "内蒙古语言" ? Are w:zh:Category:内蒙古语言 and Category:Languages of Inner Mongolia (Q13328614) related? Visite fortuitement prolongée (talk) 21:25, 21 April 2015 (UTC)

内蒙古语言 literally means "Inner Mongolian Languages". the zh category and fr are related.--KTo288 (talk) 21:07, 22 April 2015 (UTC)
Can somebody change Q9536576 into redirect to Q13328614 ? Visite fortuitement prolongée (talk) 19:49, 22 April 2015 (UTC)
✓ Done Pamputt (talk) 19:54, 22 April 2015 (UTC)
Thank you. Visite fortuitement prolongée (talk) 19:05, 23 April 2015 (UTC)

What is the meaning of "云南语言" ? Are w:zh:Category:云南语言 and Category:Languages of Yunnan (Q13328628) related? Visite fortuitement prolongée (talk) 19:05, 23 April 2015 (UTC)

Yes.--KTo288 (talk) 08:09, 29 April 2015 (UTC)
Then should Q9508494 (Q9508494) and Category:Languages of Yunnan (Q13328628) be merged? Visite fortuitement prolongée (talk) 21:44, 29 April 2015 (UTC)

What is the meaning of "长江水系" ? Are w:zh:Category:长江水系 and Category:Chang Jiang Basin (Q8956112) related? Visite fortuitement prolongée (talk) 19:44, 25 April 2015 (UTC)

What is the meaning of "长江" ? What is the difference between w:zh:Category:长江 and w:zh:Category:长江水系? Visite fortuitement prolongée (talk) 19:43, 26 April 2015 (UTC)

Are Q8115786 (Q8115786) and Yangtze River basin (Q15758768) related? Visite fortuitement prolongée (talk) 19:43, 26 April 2015 (UTC)

Are Category:Chang Jiang Basin (Q8956112) and Category:Yangtze River basin (Q15758937) related? Visite fortuitement prolongée (talk) 19:43, 26 April 2015 (UTC)

"长江" is the Yangtze, strictly translated 长江水系 is the Yangtze drainage system, however at zh wiki it seems to be primarily used for tributaries of the Yangtze with w:zh:Category:长江流域 being used for a mix of the geological, geographical, historical and cultural aspects to the river. I'll have a look at how the cats are actually being used in zh:wiki and elsewhere, rather than just how they named, before getting back to you.--KTo288 (talk) 08:09, 29 April 2015 (UTC)
Have you found? Visite fortuitement prolongée (talk) 20:36, 5 May 2015 (UTC)

Same label in many languages[edit]

An examination of the history of GrassBase (Q19816560), which I created recently with the English-language label "Grassbase", shows others adding the same label in French and German. Indeed, I would expect the label, which is a proper noun, to be the same in every language using the western alphabet.

Would it be possible to have an option when setting a label, to do so for every such language? Individual instances could always be changed later, if necessary.

Or perhaps someone might make a tool to do this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:39, 20 April 2015 (UTC)

Add importScript( 'User:Jitrixis/nameGuzzler.js' ); to your personal JavaScript and copy this page to your own namespace. That would do the job. A link would appear in the tools menu. Sjoerd de Bruin (talk) 09:54, 20 April 2015 (UTC)
Thank you. That looks useful I'm not sure what the "autoselct" option is supposed to do. Also, is there a method to select only languages which are RTL, and/ or use the western alphabet? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:58, 20 April 2015 (UTC)
The autoselect fetches the list from your namespace. I think it contains all western languages. Sjoerd de Bruin (talk) 11:00, 20 April 2015 (UTC)
@Sjoerddebruin: It not working - not doing anything - for me :-( Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 20 April 2015 (UTC)
@Sjoerddebruin: Are you able to advise, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 23 April 2015 (UTC)
@Pigsonthewing: can you be more specific, please? Sjoerd de Bruin (talk) 17:10, 23 April 2015 (UTC)
@Sjoerddebruin: I click on the "autoselect" link and - literally - nothing happens. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:40, 23 April 2015 (UTC)
@Pigsonthewing: you still need to save with the buttons on the bottom. Sjoerd de Bruin (talk) 15:24, 27 April 2015 (UTC)
@Sjoerddebruin: Thank you., but I don't get that far When I click the "autoselect" link, nothing gets selected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:00, 27 April 2015 (UTC)
@Pigsonthewing: that's weird. You don't seem to have conflicting scripts, don't know what gadgets you use. Or are you double clicking on it? Sjoerd de Bruin (talk) 18:03, 27 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Sjoerddebruin: Single-clicking (double-clicking doesn't work, either). Oddly, after I click that link, the other link also becomes unresponsive. My enabled gadgets are: Merge; slurpInterwiki; AutoEdit; FindRedirectsForAliases; labelLister; Search; RequestDeletion; CommonsMEdia; Decritions; Reasonator; DraggableSitelinks; Site ID to interwiki; Protection indicators; PopupsFix; Navigation popups; Redirect image links to Commons for files that are hosted there; NewSection. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:09, 27 April 2015 (UTC)

Seems like a Firefox issue, I assume that you use that browser because a other user is also having the problem. I've asked Lydia if she can ask a developer to look at it. Sjoerd de Bruin (talk) 12:38, 3 May 2015 (UTC)
I already have this, will that do? --Magnus Manske (talk) 10:03, 20 April 2015 (UTC)
@Magnus Manske: Thank you. Is there any documentation? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:58, 20 April 2015 (UTC)
@Magnus Manske: that seems very interesting, but how do you use it to edit, please ? --Hsarrazin (talk) 19:46, 24 April 2015 (UTC)

wd-condensed.css: Condensed Wikidata UI CSS[edit]

I've been working on some CSS to make Wikidata's UI more condensed and it is now stable enough for other people to try.

Add @import url('//'); to your common.css file (Special:Preferences#mw-prefsection-rendering, and click "Shared CSS/JavaScript for all skins: Custom CSS").

Here are some screenshots:

Notable improvements:

  • Responsive layout; layout changes depending on the window width to make viewing/editing easier
  • Columned view: statements in a statementgroup are now inlined to take less space
  • edit/add buttons are invisible until you hover over a statementgroup/statement

Known issues:

  • Columned view has holes when statements have inconsistent heights
  • Width of references list is sometimes small

I've used it for the last few weeks or so, and I believe I've found/fixed all the critical bugs. Only tested on the latest browsers (~ Chrome 40+, Firefox 36+, IE11).

Hope this is useful. –Hardwigg (talk) 08:46, 25 April 2015 (UTC)

wow, nice, will certainly try it :)
the way you manage inline display of statements, while keeping them in column for edition is exactly what I would like for language management ;) - now, it's very difficult to add a long label to an item, even worse for descriptions and aliases :( --Hsarrazin (talk) 09:26, 25 April 2015 (UTC)
@Hardwigg: could one have subClassOf and instanceOf always at the top? In many cases both act similar to the description. FreightXPress (talk) 23:35, 25 April 2015 (UTC)
@FreightXPress: Not with plain CSS. If you want that, add the following to your common.js page:
if ( mw.config.get('wgNamespaceNumber') === 0 ) { // On an entity page
        $('.wikibase-statementgrouplistview > .wikibase-listview')
                .prepend($('#P31, #P279'));
Hardwigg (talk) 02:59, 26 April 2015 (UTC)
Thanks for sharing this. :) It's great to see people trying to reduce the amount of unnecessary whitespace. That's one of the things which bothers me most about the current layout. I won't be using this as it is though. :( My comments:
  • The hover effect is actually a big hindrance to me, not an improvement. It means I can't see where I'm aiming for on my main computer until I'm already close. It also seems to make it completely impossible to edit statements on touch screen devices like my tablet, since they don't really do hovering.
  • I don't really like the position of the edit link. It feels a bit lost amongst all the qualifiers and references and I keep wanting to interpret it as a link for editing the references, not for editing the statement.
  • The "add qualifier" link when adding a statement appears on the very right of my screen, a long way from the input field and save links.
  • The font sizes for the edit/save links and reference toggle are too small for me and it also makes them harder to click because they're even smaller than they were and I have to be even more accurate with my aiming. It's also problematic on touch screen devices where accurate clicking is difficult.
  • The headings for the "In more languages" section don't have enough padding and the letters are touching or even hanging out of the grey bar.
  • The responsive design doesn't seem to kick in on my mobile or tablet, not sure if it's possible to make that work.
  • This also seems to move the sitelinks (which are currently on the right for me on my main computer) back to the bottom. I'm not sure if that was intended or not, but most of the time there is only one statement for a particular property, so it means the right side of my screen is mostly wasted again, like it used to be before the sitelinks moved there.
Thanks for the piece of JS above! The statements having no consistent ordering is the other thing which bothers me but I hadn't managed to figure out how to reorder them using JS. - Nikki (talk) 09:21, 26 April 2015 (UTC)
@Nikki: Thanks for the great feedback, Nikki! I'm working on these issues, and will post an update sometime in the next few days. -Hardwigg (talk) 03:27, 28 April 2015 (UTC)

Hardwigg - thanks for the JS. I extended it, see below #wd-sorted-statements.js. I agree with Nikki that hiding edit links and requiring hover is a hinderance. FreightXPress (talk) 17:13, 26 April 2015 (UTC)

e-mail (P968) data type[edit]

The datatype of this is String according to the template, but URL according to statements in the entity. It should be string with a formatter url specifying "mailto:". Currently it is only used on one item (with mailto: in the value), so it can be fixed manually. -Hardwigg (talk) 08:14, 26 April 2015 (UTC)

@Hardwigg: mailto will disallow addresses without @. See --GZWDer (talk) 13:03, 26 April 2015 (UTC)
@GZWDer: (Assuming you mean the mailto in the value of an e-mail (P968) statement; let me know if I misunderstood) That's true, but the user doesn't have to enter "mailto:", and could use another protocol altogether. The format can at least be specified (although not enforced) using regex on the property. There are 3 reasons why I think it should be string:
  • an email address, by itself, doesn't have "mailto:"; adding the mailto protocol creates a link to an email address
  • I'm afraid that this is causing confusion. I've abandoned adding this property myself a number of times, because I didn't realize "mailto:" was necessary, and was confused by the "invalid URL" error I received when I'd entered a very valid email address. I'm afraid this might be why it's only used on 1 item ~1.5 years after this property was created.
  • We would still be able to link the email address using formatter URL (P1630).
-Hardwigg (talk) 21:56, 27 April 2015 (UTC)
It is used so little because until recently there was a bug preventing people from adding it. That is fixed now. --Lydia Pintscher (WMDE) (talk) 11:46, 5 May 2015 (UTC)


Thanks a lot to User:Hardwigg for posting

if ( mw.config.get('wgNamespaceNumber') === 0 ) { // On an entity page
        $('.wikibase-statementgrouplistview > .wikibase-listview')
                .prepend($('#P31, #P279'));

I extended this to User:FreightXPress/wd-sorted-statements.js.

Nikki - you said you are interested in consistent ordering too. I would be happy to hear, whether you think this is an improvement. FreightXPress (talk) 17:08, 26 April 2015 (UTC)

To get sorted statements, you might be interested in this user script: User:Soulkeeper/statementSort.js --Pasleim (talk) 19:37, 26 April 2015 (UTC)
@Pasleim: thanks a lot. The function toBottom is what I needed. FreightXPress (talk) 21:01, 26 April 2015 (UTC)

@Pasleim, Hardwigg, Soulkeeper, Nikki: Pasleim uses colors for the different data-types in the page Wikidata:Database reports/List of properties/all. I would like to have these colors on item pages too. Is that possible with JS or CSS? FreightXPress (talk) 21:08, 26 April 2015 (UTC)

@FreightXPress: Nice! I think a combination of the two would work best. First add a class to each datatype. The easiest way would probably be like this:
And then style each different type with CSS. Here's a material design styling, just for fun. To use it, add to your your common.js:
mw.loader.load( '//', 'text/javascript' );
mw.loader.load( '//', 'text/css' );
-Hardwigg (talk) 03:13, 28 April 2015 (UTC)
@Hardwigg: I will try your design later. Maybe you like to test mine: . I used "_" instead of "-", that could potentially allow the code to be even smaller, if one could provide "'datatype_monolingualtext'" as a string and then within the function it is converted to a variable name. Also, I failed to have all the data in one (2-dimensional) array with named fields, or a json object, but that should be possible. Then via providing a string to the function one could access the array in the array. For the CSS: I used only border coloring. I had background, but it was too much deviation from the normal interface. But I didn't tried your's yet! Thanks a lot! FreightXPress (talk) 12:05, 28 April 2015 (UTC)
@Hardwigg: I adjusted the class names in my JS to match yours. Then I tried your CSS - looks good. I then also changed my colors to be closer to yours, but kept 3-digit notation with multiple of 3 (0, 3, 6, 9, c ,f). FreightXPress (talk) 13:59, 29 April 2015 (UTC)
@FreightXPress: Hyphenated CSS names are part of the MedaWiki Coding Conventions. (Not that my CSS is that good about following conventions ;)). I tried out your bordered-style, and it looks good; it's less jarring than the material one. -Hardwigg (talk) 04:34, 2 May 2015 (UTC)

I managed to store all datatype-property-relationships in one object and name the fields by the CSS names:

FreightXPress (talk) 19:40, 29 April 2015 (UTC)

Datatype comparison table[edit]

Name from Special:ListDatatypes Commons media Globe coordinate Quantity String Time URL Item Property Monolingual text
Qunatity from Wikidata:Database reports/List of properties/all 31 8 102 ~700 29 23 590 6 17
Name from Wikidata:Database reports/List of properties/all commonsMedia globe-coordinate quantity string time url wikibase-item wikibase-property monolingualtext
Name in CSS classes, lowercase of the DB report names commonsmedia globe-coordinate quantity string time url wikibase-item wikibase-property monolingualtext
Color from Wikidata:Database reports/List of properties/all antiquewhite lavender oldlace lavenderblush lightyellow honeydraw wikibase-item / no specific color wikibase-property / no specific color mintcream
Color from User:FreightXPress/commons.css 3 digit web-safe color (Q19842015) #f90 #3c9 #3cf #fc0 #0cc #009 #3c3 #633 #ff0
Color 3 digit / bright #fda #afd #aef #feb #9ff #ccf #cfc #dcc #ffc
Color from User:Hardwigg/wd-material-typed.css 1 #FF9800 #4CAF50 #FFC107 string / no coloring #FFEB3B #03A9F4 #3F51B5 string / no coloring #00BCD4
Color from User:Hardwigg/wd-material-typed.css 2 #FFE0B2 #C8E6C9 #FFECB3 string / no coloring #FFF9C4 #B3E5FC #C5CAE9 string / no coloring #B2EBF2

@Hardwigg, Pasleim: I made a comparison table. I adjusted my border-colors to better match the dark colors used by Hardwigg, but rounded them, so that in 3-digit notation only multiple of 3 would be used (0, 3, 6, 9, c, f). I used a value close to link-blue for URL. Item statements and string statements will occur very often, so something aggressive is ruled out, I chose green for item. Hardwigg - where do your dark values come from? E.g. FF9800 is very close to my f90, but maybe there is a reason to have FF9800? In your color sets two datatypes have no coloring. FreightXPress (talk) 13:50, 29 April 2015 (UTC)

@FreightXPress: My palette's taken from Google's Material Design specification (using I have no special attachment to the specific colors :) I mostly tried to use colors of similar hue to those of Wikidata:Database reports/List of properties/all. The uncolored datatypes are just the result of negligence on my part. When I have some time, I'll work on the material design, place some more thought into the color choices, and fill in the missing types. -Hardwigg (talk) 04:34, 2 May 2015 (UTC)

@Pasleim: You use Honeydraw, do you mean Honeydew? FreightXPress (talk) 19:50, 29 April 2015 (UTC)

Two posts for vietnamese-american author Nha Ca[edit]

Q112180187 and Q10800987 refers to the same person. I do not know how to correct this. Boberger (talk) 12:22, 27 April 2015 (UTC)

Could you please correct the first link.--Ymblanter (talk) 13:07, 27 April 2015 (UTC)
Did you mean Q19629357? I have merged these. --Yair rand (talk) 14:06, 27 April 2015 (UTC)

"list of" episode[edit]

The class of all episode of Doctor Who (Q34316) (View with Reasonator) just has been linked to the item about the serie. So we now got an item that is both

< Doctor Who episode (Q387513) (View with Reasonator) > subclass of (P279) miga < episode (Q1983062) (View with Reasonator) >

and a list of episode. Is this really correct ? I don't know, do we have guidelines somewhere ? at some point we must have a rule for this otherwise this is a mess.

About episode (Q1983062) (View with Reasonator) : we can subclass this item with tv series and radiophonic episode. I think I did in the past, does anyone knows why they have been merged ?)

TomT0m (talk) 14:56, 27 April 2015 (UTC)

If you ask me it is wrong. There may be a category or a list article where the "list of" makes sense. Having a subclass of "Dr Who episode" is plain silly. Thanks, GerardM (talk) 06:45, 28 April 2015 (UTC)
you mean having a subclass of episode ? It's not silly, it's pretty convenient to be able to make specific subclasses (that's the whole point of subclassing). Imho the episode concept barely make sense if it is not subclassed. It's always an episode of some series. (and tv series episode is even more senseful, not having it would make a query in the set of all series who are television series more complicated). TomT0m (talk) 07:06, 28 April 2015 (UTC)
I agree that "Doctor Who episode" should not be a subclass of "episodes"; it should only be a list of episode (and probably renamed to something like "Doctor Who episode list"). Having "Doctor Who episode" implies "episode" should be subclassed into "Big Bang Theory episode", "Friends episode", "Modern Family episode", etc, which is silly. However I support subclassing "episode" into television/radio/etc. episode. -Hardwigg (talk) 03:28, 29 April 2015 (UTC)
@Hardwigg: First, no, it does not imply that. If you really want to list every episode instances, you can use Wikidata Query, which will work whether or not it is subclassed, but there is no problem with this. Considering a serie is by definition a list of episode, there is no need for a list of episode item, essentially. If we generate a query by episode in the future, this modelling is fine too: the article about the episode will list all the instances of some series' epidode class, ordered by their season/sequence number. Second, What's the problem with creating those items ? TomT0m (talk) 15:17, 29 April 2015 (UTC)
@TomT0m: I agree that subclassing with "Doctor Who episode" does not limit queries in any way. You can still search all episodes (CLAIM[instanceOf:TREE[episode][][subclassOf]]).
However not subclassing with "Doctor Who episode" also does not limit queries. You can still search for Doctor Who episodes (CLAIM[instanceOf:TREE[episode][][subclassOf]] AND CLAIM[series:Doctor Who]). I personally find this cleaner than CLAIM[instanceOf:Doctor Who episode], because it is more generic. It will work for any series; just replace the value of the series claim.
I also agree that having that "list of episode" item is not very useful, but we need a way to represent list pages in Wikipedia. (Actually, should Doctor Who episode (Q387513) and List of Doctor Who serials (Q19838686) be merged? Their corresponding Wikipedia pages both look to be lists of Doctor Who episodes).
I also agree that there is nothing technically incorrect with subclassing in this way (the universe of Doctor Who episodes is a subset of the "episode" universe). The reason I am against it is because I think it is too specific a subclass to be useful, and I don't see why it should be created. The relationship between a Doctor Who episode and the series "Doctor Who" is already well represented by the "series" property. I see subclassing "episode" into "Doctor Who episode", etc., the same as subclassing "novel" into "Harry Potter novel", "Sword of Truth novel", etc. Actually, you could probably replace every statement on an item with a subclass: "Hemingway novel", "1923 novel", "originally English language novel", "novel with Harry Potter character". I don't think "Doctor who episode" is any different from these. What does having a "Doctor Who episode" item add?
Also, you are correct that it does not imply that those items need to be created. It does support their creation, though, with which I have the above problem.
-Hardwigg (talk) 20:21, 1 May 2015 (UTC)
@Hardwigg: I do not agree. I think those item are useful, and if the model offers the flexibility to make this work, I see no reason why we should not do that.
details on how I see things:
  • There is an item for list of doctor who episode. In the original plan of Wikidata, this corresponds to a query. This query will very much look like CLAIM[] (plus an ordering for the sequence, maybe). Let's call this item Doctor Who episode.
  • This query defines a class by intensional definition (Q1026899) (View with Reasonator).
  • We should (that's where the uncertainty lies) be able to assert the membership of an item to a class, so potentially a query, if we want. This would mean this item should be in the query result
    < the episode > instance of (P31) miga < Doctor Who episode >
    should be something a user should be able to state (one edit at a time) :) So if the query does not returns the item, the item should be in a constraint report, and maybe someone would know the user did not put the series: Doctor Who claim. A semantic reasoner would not even need this, he would just deduce the claim himself.
Everything says that this makes sense and that it is possible. So this will be done by users. If we have the flexibility to do this, and this is consistent, I say we do this. If there is no real issue, no necessity to make some.
And last this is a flexibility I think we will need in a lot of cases when we do not really have enough information to build a meaningful query, and in which classes will exists and will be reals, but the properties we have won't be able to build a precise enough query. I think this ability to mix extensional definitions (when we explicitely says these items are members of this class and intensional one (a query will compute the instances) is a powerful thing that we should keep in mind.
So my position: if we can, this will be done, and there is no reason to fight this. This is (if nothing more) a conflict avoidance strategy :) TomT0m (talk) 08:23, 2 May 2015 (UTC)
@Hardwigg: One more thing, that the subway id topic below made me think of : there may be cases where these by episode items could even serve in constraint or as domain for some properties, this is similar to the Tokyo subway station example where there could be properties specific to Tokyo subway for example. TomT0m (talk) 14:44, 2 May 2015 (UTC)
I think all 'list of' items should be 'subclass of'.
'List of' itself doesn't mean much ontologically so by themselves these 'list of' items are not much use. In practice these describe a class of items and that is very useful in an ontology. For instance we have lots of 'list of mayors of Foo' articles. Rename these to 'mayor of foo' (alias 'list of mayors of Foo') and it is useful as a target for 'position held' statements. Or do you want to create a million 'mayor of Foo' items with no sitelinks? Even if there are no 'instance of' statements pointing at an item that isn't a reason to say we must not call it a class. If it's a class then give it a 'subclass of' statement - it may be the only statement you can make about that item. Filceolaire (talk) 20:56, 2 May 2015 (UTC)

Merge problems (2)[edit]

Can someone merge englisch en:Category:Biotechnologists (Q7626947) with German de:Kategorie:Biotechnologe (Q8908992) ? 17:33, 27 April 2015 (UTC)

→ ← Merged --Pasleim (talk) 17:41, 27 April 2015 (UTC)

Can someone merge english en:Category:Bion satellites (Q7021297) with German de:Kategorie:Forschungssatellit (Biologie und Medizin) (Q8957715) ? 17:40, 27 April 2015 (UTC)

Can someone merge en:Category:Hunting legislation with German de:Kategorie:Jagdrecht (Q8978391) ? 17:50, 27 April 2015 (UTC)

Can someone merge en:Category:Biotechnology law (Q7487449) with German de:Kategorie:Gentechnikrecht ((Q16863875)) ? 17:54, 27 April 2015 (UTC)

Done. --Marek Koudelka (talk) 18:00, 27 April 2015 (UTC)

Can someone merge en:Category:Cell culture (Q7305817) with German de:Kategorie:Zellkultur ((Q19617161)) ? 18:14, 27 April 2015 (UTC)

Can someone merge en:Category:Marine reserves (Q7145269) with German de:Kategorie:Meeresschutzgebiet (Q9017452) ? 18:25, 27 April 2015 (UTC)

→ ← Merged, I think it's better if you register here and activate the merge gadget. These requests will become annoying after some times. Sjoerd de Bruin (talk) 18:26, 27 April 2015 (UTC)
Even without an user account it's possible to merge items with Special:MergeItems --Pasleim (talk) 18:40, 27 April 2015 (UTC)

Match available Wikipedia data with empty Wikidata data (From infoboxes)[edit]

Hello Wikidatorians,

After discovering this project today I noticed a potential improvement on the current system of Wikidata but i'm not sure if this is possible or not, so it will be great if someone can review this comment and let me know how we can do this. After viewing Anzac Day which was a public holiday recently observed in Australia and New Zealand I noticed that the date observed (which is reoccurring annually on the same day) is April 25th, this data was not entered into Wikidata until the 15th Sept 2013 however the data was showing on Wikipedia in the infobox ever since 25th Nov 2006 is it possible to programmatically connect data available in Wikipedia from infobox's, to data available in Wikidata that has not been entered? is this even a good idea?

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

First of all: Wikidata didn't exist in November 2006. Wikidata was started on October 29, 2012, statements weren't enabled until February 2013, and data for what day of the year holidays occur could not be added to Wikidata until September 3, 2013.
Lots of data from Wikipedia is frequently mass-imported to Wikidata, and of course many Wikipedias are using data from Wikidata in their infoboxes. Importing data can be problematic as the infoboxes are sometimes unsourced, or sometimes importing the sources automatically can be difficult. --Yair rand (talk) 08:38, 28 April 2015 (UTC)
Thank you for clarifying the details around timings. Since Wikipedia infobox data is problematic do you then think it is a better solution for someone like me or anyone else to manually update data in Wikidata and find sources on government websites for things like public holiday dates if they reoccur on the same day each year. --Deepheater (talk) 03:23, 29 April 2015 (UTC)
Yes, that would be exactly right. --Denny (talk) 16:21, 30 April 2015 (UTC)
Is there a commonly used method to enter the date of a Wikidata event such as a Public holiday that is not a specific date of the year like April 25th every year. How would someone enter the date of an event if that date was a unique date to this year like on the 26th of April this year but on the 27th of April next year for example. Also is there a method to enter data such as this event occurs on the First monday before a specific date every year. --Deepheater (talk) 22:19, 30 April 2015 (UTC)

ISSNs for web and print[edit]

John Vandenberg (talk) 09:30, 2 December 2013 (UTC)
Aubrey (talk) 12:15, 11 December 2013 (UTC)
Daniel Mietchen (talk) 12:47, 11 December 2013 (UTC)
Micru (talk) 13:09, 11 December 2013 (UTC)
DarTar (talk) 01:37, 15 January 2014 (UTC)
Randykitty (talk) 14:57, 15 January 2014 (UTC)
Maximilianklein (talk) 00:23, 28 March 2014 (UTC)
Mvolz (talk) 08:10, 20 July 2014 (UTC)
Andy Mabbett (Pigsonthewing); Talk to Andy 22:17, 27 July 2014 (UTC)
Mattsenate (talk) 17:26, 14 August 2014 (UTC)
Pictogram voting comment.svg Notified participants of Wikiproject Periodicals @Andrew Gray, Hsarrazin: Last month I asked: "Faraday Discussions (Q385884) (for example) has two values for ISSN (P236), one for print the other for the online version. Should we use qualifiers, or separate properties to distinguish them. In either case, what should these be, or be called?" Several people said we should use qualifiers, but no-one suggested what these should be. Any suggestions?

I was also told, off-wiki: "There is now also the ISSN-L which is used to link together the various incarnations of the journal in different media (print/electronic/other). The ISSN-L has the same value as one of the existing ISSNs for the journal - so the ISSN-L for Faraday Discussions is 1359-6640 (i.e. same as p-ISSN)". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:54, 28 April 2015 (UTC)

Well, you equally could have consulted, on-wiki, en:International Standard Serial Number... Thus the problem has two dimensions: While in theory the wikidata item for the "periodical-as-work" could be related to additional items for the web and print versions (different dates of first issue / launch, different dates of cessation, or maybe the content is not an 1:1 copy, the print version having different ads, the web version having multimedia annexes to articles...), I agree, that the use of suitable qualifiers (for all these properties) could help avoiding such splits. I'm not sure whether the property for this qualifiers really does exist, applies to part (P518) sound so "phyiscal"... Or - the value of that qualifier could best be exactly the respective ISSN for identification purposes, thus for ISSN (P236) we would need a different set of qualifying values, representing "online" and "print" (usually - there were times where some publications may have been distributed on CD-ROM also - maybe someone finds an example for a serial with a third ISSN for that kind of carrier / distribution media).
The L-ISSN on the other hand is non-unique in princple, and it is always one of the "ordinary" ones. Since I expect that we extremly seldomly will have more than item representing the different forms of a periodical I propobse that instances of ISSN (P236) could be qualified with three cases: "novalue" (this is not the L-ISSN), "this is the L-ISSN and also a valid ISSN for this item" (which one is indicated by a different qualifier, cf. the preceding paragraph), "this is the L-ISSN but not a valid ISSN for this item" (this last case being extremely seldom and it should be kept out of uniqueness constraint reports...).
The situation is similar to books and editions, but much worse over there (items for 19th century works haunted by an arbitrary selection of ISBNs of modern editions in any language whatever, or, three-volume publications having four ISBNs: one for each volume and one for the "set". Or - for authority control: different pseudonyms plus the real identity all have different VIAF identifiers, but the real identity somehow is "distinguished"), perhaps one can learn from the ISSN: "L" stands for "Leader", i.e. it is permissible to view something as distinct entities (each of them with their own distinct ISSN) 'or' to combine the items to something (a group of publications regarded the same content-wise) and in the latter case the combined item should be identified by the distinguished "leader"-identifier. Thus a general property for identifier strings could take the values "leader, valid for this item", "leader, not valid for this item". -- Gymel (talk) 10:38, 28 April 2015 (UTC)
I would suggest the way to express all of the above in wikidata properties is that ISSN (P236) has two values and we use "applies to part" as the qualifier for each value to link to "on-line edition" or "print edition" where these are generic items rather than items representing the specific online and print editions of this publication. If one of the ISSN is identified as the leader then make it "preferred" rank.
For books we will usually have separate items for translations but often we will have one item for all the English language editions, even though their will likely be different ISBNs for the UK and USA editions. We may need to create items for the UK edition and for the USA edition, separate from the main item for the book, with the ISBNs listed in the item for the edition it applies to. This can mean the main item for the book doesn't have any ISBN. OK? Filceolaire (talk) 04:13, 30 April 2015 (UTC)
Very much agreed. However we may think for a moment whether we should now introduce a generic property "applies to version" (or more technically, "applies to expression or manifestation") and use that instead of applies to part (P518): As stated above I have trouble to dissect "the serial" (in several aspects an abstraction quite far away from the world of physical "things") into two parts, namely the "physical exemplars?" and the "electronic" (or online or CD-ROM-based) ones. And furthermore a dedicated (well, general enough to be extensible to "books") property would allow specific constraints checking. -- Gymel (talk) 09:16, 30 April 2015 (UTC)
Filceolaire, Gymel: Regarding the ISBN issue: Popular books may appear in many editions in the same language, each with its own ISBN. For example, Q170583, "Pride and Prejudice" by Jane Austen, certainly was published in dozens of different English-language editions with dozens of different ISBNs (and even more older editions without an ISBN, of course). There's not just an "UK edition" and an "USA edition" of "Pride and Prejudice", there are many. The funny thing is that the only ISBN currently listed in the item is a totally arbitrary one for a French edition - imported from French Wikipedia... I'm not sure that it is meaningful to include ISBNs at all in an item for a work, because an ISBN doesn't identify a work, but just a particular edition of that work. If we follow the FRBR approach, an item such as Q170583 is describing a work, and we would need separate items for individual manifestations (editions) of that work to add the ISBNs there. Gestumblindi (talk) 21:51, 4 May 2015 (UTC)
Gestumblindi, Gymel I agree that for "Pride and Prejudice" the item referring to the book should be about the first edition and, as such, will not have an ISBN because they didn't exist back then. Each French translation should have it's own 'edition' item with it's ISBN and other data related to that translation. Use 'edition' and 'edition of' properties to link between the book and the various translations. If a translation is crowd sourced on the web then it is another edition. Though it won't have an ISBN it will have a publisher, publication date etc. Filceolaire (talk) 22:58, 4 May 2015 (UTC)
@Filceolaire: I was under the understanding that this project followed the FRBR model, and that as such the work item was something different that the first edition item ... TomT0m (talk) 06:34, 5 May 2015 (UTC)
Possibly there is enough room for both approaches. At least the FRBR model does not employ the concept of "book" at all... -- Gymel (talk) 06:40, 5 May 2015 (UTC)
Gymel, yes, as "book" is rather diffuse: When you're talking about a "book", what do you mean? A particular physical copy currently on your desk? In FRBR terms, that would be an "item" - and only meaningful as a Wikidata item for certain rare or unique books, not for one of thousands of identical copies. You might also refer to a particular edition, such as the 2008 Oxford University Press edition of "Pride and Prejudice", an FRBR "manifestation": All copies (items) of this edition (manifestation) "bear the same characteristics, in respect to both intellectual content and physical form". For Wikidata, this would be the base for an item with a particular ISBN. Or you might refer to a particular French translation of "Pride and Prejudice", an FRBR "expression" that may have several manifestations (editions with differing ISBNs). Finally, you might be talking about the work as such, "Pride and Prejudice" as an "artistic creation". As I see it, a Wikidata item about a work probably shouldn't contain ISBNs, as they're - as said above - not referring to the work. But we already have many "book" (=work?) items with ISBNs; so - maybe the ISBNs should all be removed or converted (with the help of a bot? bibliographical data from library catalogues?) to edition items? - The current definition of Q571 ("book") might be fundamentally flawed. The description says: medium for a collection of words and/or pictures to represent knowledge, often manifested in bound paper and ink, or in e-books - so, it looks as if Q571 is referring to expressions and/or manifestations, but actually is often applied to works. Gestumblindi (talk) 20:54, 5 May 2015 (UTC)
Gestumblindi Sure, it's a complete mess (at least from a strict Functional Requirements for Bibliographic Records (Q16388) perspective) and the Wikidata:Books task force does not appear to have had much impact. OTOH we do need much more "books" (and articles like this discussion here is about) here in wikidata to serve as reference. And training the average editor to a state of mind where anything "bibliographic" has to be represented by at least three different wikidata items does not seem very feasible to me (but noticing that The Life and Opinions of Tristram Shandy (Q1164083) is a "book" with an ISBN-13 also hurts. BTW according to WorldCat the ISBN stands for the 1967 Penguin edition, way back in time before introduction of the ISBN system. Thus Sterne would be highly satisfied I presume). -- Gymel (talk) 21:17, 5 May 2015 (UTC)

Merge Problems[edit]

Can someone merge en:Category:Fishing museums (Q16780536) with German de:Kategorie:Fischereimuseum (Q8954440) ? 18:45, 28 April 2015 (UTC)

✓ Done see Q8954440. Delsion23 (talk) 23:58, 28 April 2015 (UTC)

Generating items from Wikipedia categories[edit]

In the category cy:Categori:Eisteddfodau yn ôl blwyddyn on, the articles for eisteddfodau (plural of eisteddfod) up to 1881 have Wikidata items, but not the ones for 1882 to the present day. Can the remaining items be generated automatically from the Wikipedia category? Ham II (talk) 05:17, 29 April 2015 (UTC)

With you can create them directly. --- Jura 06:34, 29 April 2015 (UTC)
@Jura1: Face-wink.svg Thank you!—starting to get the hang of it now! Ham II (talk) 06:52, 30 April 2015 (UTC)
To add English labels you can edit the result from [1] and add it with [2]. Adding "point in time" is a bit more complicated. --- Jura 08:23, 30 April 2015 (UTC)

How to Create company database in Wikidata[edit]

Hi there,

It would be great if you help me about how to save company database into wiki data. As we know Freebase is a medium to get fetched data as a knowledge graph into google searches. Since Freebase stopped providing services and its entire data is migrating to So how we will come to know or able to get database as knowledge graph for google search engine. Please suggest the steps to create company page as simply we had to create in freebase. --VarunNegiUr (talk) 08:38, 29 April 2015 (UTC)

Please read this first. Also, your company needs to meet our notability policy. Sjoerd de Bruin (talk) 08:47, 29 April 2015 (UTC)

extract items ordered by value on a certain property[edit]

I would like to (continually) be given a list of all items that have a certain property, ordered by the value of that property. Specifically, I would like all the items that have the Perry Index (P1852) property, ordered numerically by their value. So, say, a table the first column listed the P1852, the second column listed the (possibly more than one) items that have that specific value.

What is, at the moment, the easiest way to that? I know of Wikidata:Database reports/Constraint violations, but I don't mean to limit the above query to values that are erroneous. Gabbe (talk) 09:48, 29 April 2015 (UTC)

I also know how to construct this, but not how to sort the table by its rightmost column. Gabbe (talk) 10:26, 29 April 2015 (UTC)
I would try downloading it. Spreadsheet software should be able to sort it. Popcorndude (talk) 11:38, 29 April 2015 (UTC)
You might want to try TAB --- Jura 11:46, 29 April 2015 (UTC)

Commons category cannot be linked anymore[edit]

commons category can no longer be linked at Other Sites, e.g. Otto Modersohn (Q71425) c:Category:Otto Modersohn --Oursana (talk) 12:28, 29 April 2015 (UTC)

Seems working here. Sjoerd de Bruin (talk) 12:30, 29 April 2015 (UTC)
Thanks for your help, today it finally works again--Oursana (talk) 13:45, 30 April 2015 (UTC)

Should usage instructions be included in descriptions?[edit]

Please join the discussion at Help talk:Description#Putting usage instructions in descriptions. Cheers! Kaldari (talk) 21:35, 29 April 2015 (UTC)

Why not use appropriate properties to describe? And reduce "description" to comment for rare cases. FreightXPress (talk) 14:21, 30 April 2015 (UTC)

Merge problems: Eyal[edit]

Can someone merge German article de:Eyal (Q1385639) with english article en:Eyal (disambiguation) (Q5422549) ? 23:26, 29 April 2015 (UTC)

→ ← Merged -- LaddΩ chat ;) 02:29, 30 April 2015 (UTC)

If it's written with a different alphabet is it a different language?[edit]

There are a number of languages which can be written in multiple alphabets. When we use the "monolingual text" datatype we are asked to indicate which language the text is in but it should also be possible to indicate which alphabet is used. Can this be done with monolingual text? Filceolaire (talk) 16:15, 30 April 2015 (UTC)

Script (per ISO), via "ISO 15924 alpha-4 or numeric code" (Property:P506) and/or an orthography? FreightXPress (talk) 16:32, 30 April 2015 (UTC)
This should be done with IETF language tag (Q1059900). I tried "en-latn" with Sandbox Monolingual text (P1450) in Wikidata Sandbox (Q4115189), but my edit was blocked. IETF language code seem to be forbidden in "monolingual text". Ask developpers. Visite fortuitement prolongée (talk) 19:36, 30 April 2015 (UTC)
The answer is no. When something is written in a different script, it is still in the same language. Serbian may be sr-Latn or sr-Cyrl. Wikipedia uses technology to convert on the fly from one script to another. As far as I know we do not use that technolcogy for Wikidata. That is an issue and it is not solved by pretending that it is a different language. On a practical level, would we link sr.wp to the Cyrillic or to the Latin version... Same is true for Chinese. Consequently, it needs some REAL attention to do justice to this issue. It is not as simple as using monolingual type. Thanks, GerardM (talk) 05:50, 2 May 2015 (UTC)
So GerardM if a town in Serbia has an 'official name' with an official spelling in Cyrillic and an official spelling in Latin and we want to record both then the easiest way to do this (it seems to me) would be if 'monolingual text' could be tagged as 'sr-Latn' or as 'sr-Cyrl' as well as 'sr'. Does that seem like a sensible workaround to you? Filceolaire (talk) 20:34, 2 May 2015 (UTC)
Yes it does. GerardM (talk) 14:44, 3 May 2015 (UTC)

Level of granularity of properties[edit]

We have simultaneous discussions about deleting properties in favour of (i.e. effectively merging them into) more general properties (Wikidata:Properties for deletion#Slovene Cultural Heritage designation (P1597); Wikidata:Properties for deletion#MTR station code (P1377)); and, conversely, splitting specific properties off from the more general (Wikidata:Property proposal/Authority control#Web Gallery of Art id).

On the one hand, more specific properties allow easy use of formatter URL (P1630); on the other, they may make it harder to keep track of what's what.

We need, I think, to agree a policy on this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:00, 30 April 2015 (UTC)

Wikidata:Database reports/List of properties/datatype/string lists 712 properties. Many are identifiers. It would be nice if a table could show
for all of them. Maybe User:Magnus Manske could create a tool or it exists already? List selected properties of all properties of a specific datatype. FreightXPress (talk) 00:05, 1 May 2015 (UTC)
In my opinion it is better to have less but more general properties. These allow lots of reusage at several places which makes translation and connection easier. When a property is used widely it is also clear that the general idea behind that property is the same, even if it is applied in different contexts. In all cases, a general property can be clarified by qualifiers, but usually it is already clear by the context of the item which meaning of the property is relevant in that place. For example, for a station code for a station in Hong Kong it is actually clear that it is an MTR station code and not a London underground station code. Therefore I support reducing the number of properties to a group of general ones. -- Bene* talk 12:28, 2 May 2015 (UTC)
@Bene*: What makes translation easier is, to have a main space item for each Wikidata property that represents an identifier (Wikidata property representing a unique identifier (Q19847637)). At the main space item page properly describe the item via properties:
  • identifies : (e.g. railway station, or railway station in Hong Kong)
  • issued by/maintained by: (e.g. MTR, London Underground)
  • reusable after: (e.g. relevent for ISO 3166-1 alpha-2 codes, as they can be re-assigned after 10 years)
Then connect the property via P1629 with the item, e.g. ISO 3166-1 alpha-2 code (P297) via subject item of this property (P1629) with ISO 3166-1 alpha-2 code (Q1140221). FreightXPress (talk) 13:07, 2 May 2015 (UTC)
Regarding your example, it could also be an Asian-something station code, used in a DB concerned with stations in Asia. It would still be a code for a station in Hong Kong, but not a MTR code.
User:GerardM made a statement about descriptions [3]. It looks a if one is going to merge some selected identifiers into one, while not merging all identifiers into a general property "identifier", one will need more descriptions. So the extreme cases are: 1) one property storing the ID of one ID system 2) one property for storing all IDs. Everything inbetween requires more discussion, documentation and will lead to more confusion. FreightXPress (talk) 13:07, 2 May 2015 (UTC)
I don't see a problem with multiple properties in this case : we can even put a more precise domain constraint or statement for the property. (Tokyo Subway ID domain "Tokyo subway railstation"). We also have subproperties if we want a more generic property like "public transport line ID". TomT0m (talk)
In my opinion these constraints are just not helpful and useless. If you have a "Tokyo Subway ID" property which may only be addded to "Tokyo subway railstation" instances, it is worse than having a general "Subway ID" property which requires a "subway railstation" instance. That the subway station is in Tokyo can be easily expressed by another property. This requires 1.) less properties and 2.) less constraints. Having less things to maintain, translate etc. is always good for obvious reasons. Furthermore, it makes it easier for clients to query things. If I have a tool which lists subway station IDs in several cities, it would require to list all properties which deal with those IDs in the tool. However, having only one general "subway station ID" for all cities makes this a lot easier. One could just query for this ID property and filter the cities by another statement on that item. -- Bene* talk 15:06, 2 May 2015 (UTC)

Just a note : the future identifier datatype will be created and used to sort out identifier statement in the user interface. (Just having one identifier property would mean ... just one property with this datatype :)) TomT0m (talk) 14:40, 2 May 2015 (UTC)

User:TomT0m - Can you point to a page where this was said/agreed? FreightXPress (talk) 18:09, 2 May 2015 (UTC)
This has been discussed in 2013. Wikidata:Requests for comment/How to classify items: lots of specific type properties or a few generic ones?. To summarise that discussion:
  • Option 1 - one 'station ID' property with a 'catalog' qualifier to indicate exactly which ID registry this ID is part of.
Advantage: infoboxes and external queries know exactly what property to search for
Disadvantage: standard tools can't see the qualifier.
  • Option 2 - a separate property for each 'station ID' registry (may be more than one per country).
Advantage: don't need to see the qualifier to get all the information
Disadvantage: you need to know what property to search on so each registry needs a slightly different infobox from infoboxes for every other ID registry. Difficult to deal with stations with multiple IDs
  • Option 3 - a separate 'station ID' property for each station ID registry, all marked as 'subproperty of' a generic 'station ID' property. Use a special search on 'station ID with subproperties' function to search on all these properties at once
Advantage: as 1 and 2 above.
Disadvantage: the 'search including subproperties' function is not part of the current wikidata development plan (though rdfs:subPropertyOf does describe this function).
I have asked for a comment from the development team on the last point. Wikidata:Contact_the_development_team#Lots of specialist properties or fewer properties with qualifiers? Filceolaire (talk) 20:10, 2 May 2015 (UTC)
Link fixed. Filceolaire (talk) 12:45, 3 May 2015 (UTC)
Thanks for the link, Filceolaire. Maybe the time has come to restart this discussion so that we finally have some consistent rules which apply on most places (there will always be exceptions perhaps). -- Bene* talk 09:09, 3 May 2015 (UTC)
@FreightXPress: phab:T95287 Lydia confirms the datatype in a comment. TomT0m (talk) 09:45, 3 May 2015 (UTC)
@TomT0m: Thanks a lot! FreightXPress (talk) 13:03, 3 May 2015 (UTC)

Add a link to the creation discussion to property talk pages[edit]

Most property talk pages have very little information on how the property is to be used. They have the constraints but these in some cases contradict what was agreed in the discussion when the property was created.

Can we add a link to the archived property creation discussion? Let's put this at the top of the page, above the constraints? These discussions usually include useful guidance on how the property is to be used which is not available elsewhere and which is not easy to find. Filceolaire (talk) 01:19, 2 May 2015 (UTC)

I agree that we probably can do much better (I did propositions some time ago but nobody understood /o\). But things also evolves for good reasons beetween the creation and the current usage on the property. So I do not agree to just put a link. We should (and either the wikidatian who proposed the property, the creator ...) care to put a good documentation and a little text explanation on how to use the property on the property page. And when things evolves and new usecase are found, keep this up to date
If that's too big of a burden, we should index the usecases themselves, as often properties are used together, or said differently, for a given usecase, there is a set of properties involved. We should document the usecases, and for each property, give links in the property documenation on this pages.
That's why I proposed to also document classes, as a class is often associated to a set of related properties (for example, an event and its subclasses all have a date or an interval of date, usually a topic ..., that's also true for the subclasses). TomT0m (talk) 07:59, 2 May 2015 (UTC)
I didn't say mine is a complete solution but it seemed like an easy first step everyone could understand. In many cases use cases are documented in wikidata projects and I don't think that should be duplicated - we should have links to those as well. Filceolaire (talk) 20:16, 2 May 2015 (UTC)

Don't change old values of publication?[edit]

The instruction for publication (P577) currently says "don't replace old values", but it doesn't say why. If, for example, an art-house film was released during a film festival, what would be wrong about increasing the precision of P577 from "2014" to "2014-09-03"? Is there any reason for retaining the less precise value (unlike in the publication values for Lucy (Q15624215))? Gabbe (talk) 08:47, 2 May 2015 (UTC)

Ping @Tobias1984: you were the one who have added this instruction. Gabbe (talk) 09:20, 2 May 2015 (UTC)
@Gabbe: I added that message because people editing software items are always removing old releases and adding new ones without sources. Or they increase the minor version number, but keep the source that only is valid for the major release. --Tobias1984 (talk) 09:27, 2 May 2015 (UTC)
But for the specific example I mentioned (a film premiere) you don't see any problem? Gabbe (talk) 09:31, 2 May 2015 (UTC) Edit: By "see any problem" I mean, would you mind? Gabbe (talk) 09:35, 2 May 2015 (UTC)
For films, a year of publication can always be helpful, even if there are more precise value for whatever place of (initial or subsequent) publication. Most lists and categories are by year of publication. --- Jura 09:37, 2 May 2015 (UTC)
But isn't the year implicit from the more precise date? For example, what is wrong with this edit? Gabbe (talk) 09:42, 2 May 2015 (UTC)
Yes and no. In your edit, we don't know for sure if it's the initial date of publication ("release"). For other types of works, it might be more straightforward. --- Jura 09:54, 2 May 2015 (UTC)
@Gabbe: Your example seems perfectly fine. A more precise date is always good, and the year can be easily filtered from a date. --Tobias1984 (talk) 09:55, 2 May 2015 (UTC)
@Jura1: But if I do know for certain that it was its first release, then it would be okay? For items that are people, for example, we don't keep separate "year of birth" and "date of birth", even if categories are typically by "year of birth" (and the specific date is sometimes not known precisely). Gabbe (talk) 10:00, 2 May 2015 (UTC)
For DOB, a comparable issue could be when we can start entering time of birth. --- Jura 10:15, 2 May 2015 (UTC)
This needs to be rewritten. My suggested wording "(If rereleased then add the date of rerelease but keep the date of first release)". Filceolaire (talk) 20:26, 2 May 2015 (UTC)

How to merge two items?[edit]

Please merge Q19848684 and Q7422719. I do not know how to do that. When attempting to connect the Commons category to the existing Wikipedia article, I was just offered the option to create a new item, but not to connect to the existing item. I find this confusing and I do not know how to fix this. --Aodh (talk) 16:03, 2 May 2015 (UTC)

Those should not be merged. Categories and articles are two separate things. Sjoerd de Bruin (talk) 16:09, 2 May 2015 (UTC)
This is not about categories and articles but about two items, both about Sarah Purser. Do you want to maintain two items about the same person? --Aodh (talk) 16:24, 2 May 2015 (UTC)
An item having only one link to Commons link is not notable. It isn't clear whether Commons categories may be connected to items. If I deleted the second item for not being notable, you would be able to add the link to the second item. However, I don't claim it would be okay. Matěj Suchánek (talk) 16:47, 2 May 2015 (UTC)
If Q19848684 could be deleted, it would be appreciated as it was created by accident. Thanks, Aodh (talk) 17:13, 2 May 2015 (UTC)
You needed to just add the Commons category (P373) to her item, which I just did. You created an item for a Wikipedia category, which could easily exist if you created two separate articles for stained glass windows or other artworks she created. The you link that category to the item you created. It looks like she made some notable works, so that could easily be a possibility. I would leave it for now. Jane023 (talk) 07:46, 3 May 2015 (UTC)
We are here still left with two items, one accidently created. Commons category (P373) does not help to link the Commons category to the corresponding Wikipedia articles which is the desired functionality at Commons. I could get the desired list of interwiki links to Wikipedia articles at Commons if I would be able to enlist the Commons category among the "other sites" to Q7422719. Unfortunately, this is not possible for me as the accidently created Q19848684 has already this link which I cannot remove. Please note that many of the categories at Commons are considered to be in par with articles as there are no articles at Commons (galleries do not count as such). See this discussion for details. --Aodh (talk) 10:12, 3 May 2015 (UTC)
Oh yes I see the problem now. Sorry, but we are no where near ready for that functionality. Right now the "Category:<cat name>" items on Wikidata are all for Wikipedia categories, not Wikimedia Commons categories. It is best to explore well fleshed out subjects to orient yourself on this material. I suggest taking a look at the Category structures for Vincent Vermeer for example. I still don't see an immediate reason to delete the item you accidentally created by the way. It will probably get used in the near future. Jane023 (talk) 11:28, 3 May 2015 (UTC)

Oops - I meant van Gogh or Vermeer - take your pick. Jane023 (talk) 11:29, 3 May 2015 (UTC)

Johannes Vermeer category have issue too. commons:Category:Johannes Vermeer does not have link to ruwiki at all. User needs at least two clicks to navigate to ru:Вермеер, Ян. And user must know where to click. — Ivan A. Krestinin (talk) 11:58, 3 May 2015 (UTC)
I don't see the issue. In the Russian Wikipedia they have chosen not to have a category for Jan Vermeer and only have a category for "Paintings by Jan Vermeer". Clearly they have more pages about Jan Vermeer than just the pages about his paintings (such as this one, so I don't think this is an issue, but a misunderstanding. Jane023 (talk) 12:59, 3 May 2015 (UTC)
Commons and Wikipedia have different structure. Primary items for our readers are files and categories on Commons (galleries are not because its count is low and many of its are outdated and useless). Primary items are articles in Wikipedia, the most readers know nothing about categories in Wikipedia. Link from Commons category to Wikipedia category is useless for readers because it follows from primary namespace to technical useless for reader category page. Also Johannes Vermeer is bad sample because it is untypical. The most entities does not have category in Wikipedia and does not have gallery in Commons, like Q7422719. — Ivan A. Krestinin (talk) 13:31, 3 May 2015 (UTC)
Yes I totally agree with you, and as someone who does a lot of categorizing on Commons I would even go a step further and say that casual readers know nothing about Commons categories either (alas!). See my previous comment about how this functionality is just not useful (yet). My point was about the intention of the linked categories as they now currently exist (such as for Vermeer). We can whine and moan about it, but it is what it is. Jane023 (talk) 16:05, 3 May 2015 (UTC)
@Jane023, Ivan A. Krestinin, Aodh: Can I recommend the script c:User:TheDJ/wdcat.js ?
If you add the line
to your common.js file on Commons (as in eg c:User:Jheald/common.js), then whenever you go to a Commons category, it will show you a link on the category page that goes to Reasonator, if there is a corresponding article-like Wikidata item with a P373. (And of course Reasonator then has a link to the articles on all the individual Wikipedias). It's a little slow, but I've found it really useful; I think you would find it worth giving a try. Jheald (talk) 17:43, 5 May 2015 (UTC)
Thank you for the script, but link to Wikipedia is needed, not to Resonator. And it is needed not for me. I know current project structure and can find required information. Link is needed for our readers, who know very little about our projects structures. Maybe you can adapt your script for this goal. We need script for replacing Wikipedia categories links to Wikipedia articles links. — Ivan A. Krestinin (talk) 19:42, 5 May 2015 (UTC)

Murderers and their victims[edit]

Hi all, I could link the victim Catharina Helena Mirande (Q19685470) to her murderer, but how do I link the murderer Johan Barger (Q742496) back to the victim? thx Jane023 (talk) 07:39, 3 May 2015 (UTC)

You may propose inverse of the property. By the way, I think the property should be as a single claim, not as a qualifier as we want to have an inverse for it. Matěj Suchánek (talk) 07:47, 3 May 2015 (UTC)
OK I will do that (I couldn't find one either). Jane023 (talk) 08:16, 3 May 2015 (UTC)
Didn't we discuss once that having reverse properties is not such a good thing and should reather be solved using queries? -- Bene* talk 09:07, 3 May 2015 (UTC)
I didn't. Whose to say which direction is the "correct linking direction"? I am not sure what you mean. I of course would also like to see (for important properties) both the owned and owned-by fields on the respective pages of owners and their (former) properties. Are you saying this is not desirable behavior for the property concept? Jane023 (talk) 11:21, 3 May 2015 (UTC)

I mean objects such as buildings, paintings, or sculptures when I say properties plural and I do mean the Wikidata concept when I say property singular. Sorry for any confusion. Jane023 (talk) 11:32, 3 May 2015 (UTC)

Property proposal is here: Wikidata:Property_proposal/Person#Murdered Jane023 (talk) 06:41, 4 May 2015 (UTC)
A better solution might be to have the software automatically add the reverse property to the corresponding item. MSGJ (talk) 12:37, 5 May 2015 (UTC)

Edit actions performance[edit]

Hello, today large performance degradation appears for edit actions. For example this change takes 4.5 sec. Is it my local issue or global? Profiler says that POST request waits for server response during 4358 ms for the action. Were any known changes made this night? — Ivan A. Krestinin (talk) 09:57, 3 May 2015 (UTC)

I've experienced similar delays as well. Gabbe (talk) 10:07, 3 May 2015 (UTC)
Yes, same problem here and also on it.wikipedia. --ValterVB (talk) 10:38, 3 May 2015 (UTC)
Filed a bug and it was fixed. On wikitech:Incident documentation/20150503-JobQueueRedis you can read the incident report (people are still working on that). Multichill (talk) 17:06, 3 May 2015 (UTC)

Policy about draft[edit]

Hi, Succu took on himself to move Help:Classification to User:TomT0m\Classification. This is a draft there is a discussion Wikidata:Requests_for_comment/Adopt_Help:Classification_as_an_official_help_page opened to adopt it as a real policy. I note that most opposition are not on the ideas behind the help page, but only about the form who needs more work ... I want community's opinion about this move, and if needed that we wlarify the policy about dratfs and proposal. TomT0m (talk) 10:27, 3 May 2015 (UTC)

And now Visite fortuitement prolongée just redirects the link to Help:Basic Membership Properties. Do you really want to annoy me ? There is a discussion going on and this breaks all the links ! TomT0m (talk) 14:17, 5 May 2015 (UTC)

New datatype identifier - relation to datatype string - migration[edit]

TomT0m just made me aware of phab:T95287 "Identifiers are currently mixed with other statements. This makes it harder to scan the statement section and find relevant information. We should separate out identifiers."

@Lydia Pintscher (WMDE): maybe the following helps on the data side of the migration and helps answering the question: Which of the properties having datatype string are identifiers?

Some days ago I started: Wikidata:Database reports/List of properties/datatype/string.

To help me find out which of the properties are identifiers, I did harmonize several English descriptions that started with "identifier", "ID", "Identifier", or any misspelling like "indentifier", "indentifer" etc. and sorted by description.

I then also started to claim for each that is an identifier "instance of Q19847637". The property itself is not the identifier, any identifier itself would be in the main name space, that is why I choose as a name "Wikidata property representing a unique identifier". It is only linked from properties, so bots can very easily operate based on "instance of Q19847637".

User:Pasleim - can your bot that maintains Wikidata:Database reports/List of properties/all also update Wikidata:Database reports/List of properties/datatype/string? But add one additional column that indicates if the property has "instance of Q19847637"?

I think we need some talk about that. Some people may disagree about what is an identifier, e.g. here @Brya:. The list could help to centralize discussions about whether something is an identifier or not, discussions that otherwise might pop up in various places.

What do you think? FreightXPress (talk) 13:25, 3 May 2015 (UTC)

Wikidata:Database reports/Constraint violations/All properties can be useful. More than 50% string properties have {{Constraint:Unique value}}. — Ivan A. Krestinin (talk) 13:47, 3 May 2015 (UTC)
Ivan, that would be helpful in the table too. Furthermore a column for format as a regular expression (P1793) could be useful. FreightXPress (talk) 18:01, 4 May 2015 (UTC)
P1793 is not actual now, use {{Constraint:Format}} instead. Now we have 715 string properties. 560 properties have {{Constraint:Format}}. 514 properties have {{Constraint:Unique value}}. Many other string properties must have these templates. So the most string properties are identifiers. These properties are widely used already. So we need extending string type functionality, not data migration to new type. — Ivan A. Krestinin (talk) 18:23, 4 May 2015 (UTC)
Ivan, thanks for the statistics. It would be really helpful if any bot could create a table for these values. I also wonder whether User:Lydia Pintscher (WMDE) is listening? Talking about migration without analyzing the data? Maybe instead of migrating ~700 ID-properties one could better migrate the ~15 strings that are not IDs. FreightXPress (talk) 00:26, 5 May 2015 (UTC)
Yes I am reading. And I am not talking about migration without analyzing the data. I have looked into it. The migration is the clean way to handle this. Since we will not be losing the IDs of the properties for this particular migration it'll not cause migration pain for 3rd parties. --Lydia Pintscher (WMDE) (talk) 11:44, 5 May 2015 (UTC)
Lydia, you say "The migration is the clean way to handle this" - and "I am not talking about migration without analyzing the data" - then where is the analysis? Is the result only visible to WMF developers or can ordinary Wikidata editors see it too? Most interestingly: Did you find properties of type string that are not identifiers? FreightXPress (talk) 16:11, 5 May 2015 (UTC)

Strings that are not unique identifiers[edit]

FreightXPress (talk) 00:30, 5 May 2015 (UTC)

Neither RAÄ-nummer (P1262) is fully unique. Not a big deal, since only small parts of the database can be found here. -- Innocent bystander (talk) 08:45, 5 May 2015 (UTC)
How is that no unique? FreightXPress (talk) 16:11, 5 May 2015 (UTC)

Wikimedia Foundation Funds Dissemination Committee elections 2015[edit]

Wikimedia Foundation RGB logo with text.svg

This is a message from the 2015 Wikimedia Foundation Elections Committee. Translations are available.

Voting has begun for eligible voters in the 2015 elections for the Funds Dissemination Committee (FDC) and FDC Ombudsperson. Questions and discussion with the candidates for the Funds Dissemination Committee (FDC) and FDC Ombudsperson will continue during the voting. Nominations for the Board of Trustees will be accepted until 23:59 UTC May 5.

The Funds Dissemination Committee (FDC) makes recommendations about how to allocate Wikimedia movement funds to eligible entities. There are five positions on the committee being filled.

The FDC Ombudsperson receives complaints and feedback about the FDC process, investigates complaints at the request of the Board of Trustees, and summarizes the investigations and feedback for the Board of Trustees on an annual basis. One position is being filled.

The voting phase lasts from 00:00 UTC May 3 to 23:59 UTC May 10. Click here to vote. Questions and discussion with the candidates will continue during that time. Click here to ask the FDC candidates a question. Click here to ask the FDC Ombudsperson candidates a question. More information on the candidates and the elections can be found on the 2015 FDC election page, the 2015 FDC Ombudsperson election page, and the 2015 Board election page on Meta-Wiki.

On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Volunteer Coordinator, 2015 Wikimedia Foundation Elections Committee

Posted by the MediaWiki message delivery 03:45, 4 May 2015 (UTC) • TranslateGet help

Wikidata Visualization Challenge[edit]

I think this might be interesting to some here; a competition to visualize Wikidata has started. Jan Ainali (WMSE) (talk) 09:35, 4 May 2015 (UTC)


It was discussed before more than a year but with not much attention. There is no reason for numbers to default with an arbitrary +-1. The interface should stop adding precision by default. I did a workshop before one month and gave a task for people to add population. Everyone got frustrated by this and after I told them "type +-0 after the number", the answer/question was "how could we know?". There is no hint! It doesn't work as expected from any one who is not a casual wikidata editor. The expected behaviour is to store what the person has inputed. If it is really need it create an interface like for the date and coordinates data type. But the default should be +-0. Without having to wait for this inteface. --geraki talk 11:01, 4 May 2015 (UTC)

  • Maybe we should stop displaying +/-1 (as it's the default/unknown precision), but display +/-0 as it's a defined precision. --- Jura 11:06, 4 May 2015 (UTC)
  • I agree we need a better UI for this, but it's true that we usually do not pay enough attention to the precision. Usually statistical organisations gives a way to add the precision of their measures, for example see this for the 2012 population measurement. If we do not have a way to push the precision as a Wikidata feature, no one will care. TomT0m (talk) 11:18, 4 May 2015 (UTC)
  • @geraki, Jura1, TomT0m: phab:T68580.--GZWDer (talk) 11:23, 4 May 2015 (UTC)
  • I'm afraid we suggest a precision (to our readers) that isn't even right. Which makes it double wrong. Edoderoo (talk) 06:49, 5 May 2015 (UTC)
  • There needs to be a precision unknown or precision unspecified as default, not any arbitrary value, +-1, +-0, or any other number. --Izno (talk) 15:08, 5 May 2015 (UTC)


I have checked all the current gadgets in the section "Wikidata-centric" and found few issues:

  • SitelinkCheck: Shows a form to check whether a specific site link is already in use and gives the id of the item if so. – seems to be broken, after adding "title" and confirming it says there's no title given
  • Properties tool: send a request for copy specific property to many items. It will send your request here, and a bot will process the request after review. (Documentation) – has its own page, however it shouldn't be used anymore per User talk:Legobot/properties.js/requests
  • Descriptions: Show the description of items and properties when hovering them. – not sure how it should work but I don't see any descriptions using it

Looking at my common.js:

Matěj Suchánek (talk) 12:03, 4 May 2015 (UTC)

"specifies" relationship[edit]

Here's an interesting one that I'm not sure is captured as a property:

I'd like to be able to make the statement MIL-STD-1815 specifies Ada (Q154755) (or the inverse?). Is there such a relationship available? --Izno (talk) 15:06, 5 May 2015 (UTC)

@Izno: I don't think so, it seems like a good case for a property. main subject (P921) miga fit for the other side of the relationship thought. TomT0m (talk) 15:09, 5 May 2015 (UTC)
How would you use main subject? --Izno (talk) 15:11, 5 May 2015 (UTC)
Also, I don't think "main subject" carries the intent that "specifies" does, though it is a near fit. We can say that MIL-STD-185 main subject Ada (Q154755) and it be a true statement, but it's not the entire intent of "specifies" ("specifies" carrying also the relation that the object item is "constrained by" the subject item ("the document")). --Izno (talk) 15:16, 5 May 2015 (UTC)
The main subject of the specification of a language is of course the language itself :) That is if you see the specification as a document. It may be different if you view the specification as a set of rule, but ... it may work as well :) Maybe we can generalize this to constructive and non constructive definition and to mathematical proofs of algorithms with a couple of fullfils/compute and defines/specifies properties though.
the main subject of the constraints is the languages, or more precisely wht it computes. Said differently, it's the semantics of the language. The semantic is a part of a language, so the language is a subject of the constraints :) TomT0m (talk) 15:18, 5 May 2015 (UTC)
I always wondered how far foundational text (P457) could extend... -- Gymel (talk) 15:56, 5 May 2015 (UTC)

Wikisource link addition error[edit]

I get the following error message "An error occurred while saving. Your changes could not be completed." when trying to add Hill, James John (DNB00) to James John Hill (Q18385235) --Bamyers99 (talk) 18:51, 5 May 2015 (UTC)

Fixed, the wikisource page alredy was on wikidata on item Q19038632, now I have merged the items. --ValterVB (talk) 19:25, 5 May 2015 (UTC)

Usage tracking issue (with saving pages)[edit]

There was an issue after deploy today with saving (wikitext) pages that are connected to some item. The problem was related to usage tracking phab:T98186 and should be fixed now. If there are any other problems please poke us. Aude (talk) 19:47, 5 May 2015 (UTC)

btw, new things in the deployment include a new special page for listing properties, Special:ListProperties, and some other bug fixes. mw:Wikidata_deployment#wmf.2F1.26wmf4 Aude (talk) 19:52, 5 May 2015 (UTC)