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 September.



Songs or singles[edit]

en.Wikipedia has an ongoing problem with the conflation, or confusion, of songs and singles. This is exemplified by the interchangeable use of its Infobox song and Infobox single. I am now seeing this affecting Wikidata; for example, One of These Days (Q957641) is tagged as an instance of single (Q134556), whereas the linked en.Wikipedia article, en:One of These Days (instrumental), is about the composition in all it forms, including live performances and as an album tack.

Furthermore, singles (at least from the pre-digital-download era) usually comprise at least two recordings, an "A" and "B" side; and the latter may vary by territory or release format.

How granular do we want to be? Can we learn anything from sites like MusicBrainz? Is there a task force looking at this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:32, 13 September 2014 (UTC)

There are some advantages to use two items, to respect some relation constraints, I give here some example:
  • A discography is a list of discs (singles, EPs, albums), not of songs.
  • A song could be on a single, but also later on an album.
  • A song could get an award, or reused in a movie. The movie reuses the song, not the single disc.
  • The single could get a sales award, it's the disc, not the song which is sold.
  • Pigsonthewing has already noted the B-side issue for maxi single.
So I'd routinely create two items.
Link the en. article to the relevant item according the infobox or introduction of the article, it's mainly their problem, if they speak about two notions in one article.
In the worst case, if an en. article offers a comprehensive content of both, create a third item Wikimedia list / instance of : Wikimedia list / list of : <single>, <song> to link the en. interwiki to. --Dereckson (talk) 13:46, 13 September 2014 (UTC)
Using distinct items is not a good idea because (at least on en.wiki) the vast majority of these articles are about both the song and the single. Since you can't have two Wikidata items with the same en.wiki link, separating the two items will create a lot of confusion. I prefer having a single item with both statements P31:song and P31:single. Pichpich (talk) 19:48, 13 September 2014 (UTC)
Wikidata is the opportunity to fix the technical debt of bad organizations and structure on Wikipedia articles.
Your preference goes against the current trend of Wikidata. For example, it would be against what we're doing on written creative works where we distinguish franchise, fictional universe, books, movies.
The goal of Wikidata is to organize human knowledge, and you can't organize knowledge if one item is about two notions.
If an article are about both, create an item Wikimedia list / list of <the single>, <the song> for this item, because from a data overview, a fruit isn't a tree, a song is not a single. --Dereckson (talk) 20:41, 13 September 2014 (UTC)
By the way, this remembers me (and on IRC someone arrives separately to the same conclusion) the Wikimedia Commons first years, where people considered the project as a mere annex of Wikipédia. Wikimedia Commons is a project per se, to host informative and educative free media. Similarly, Wikidata is a projet per se, to host facts and organize human knowledge, not only an interwiki repository, with nice properties to fill infoboxes. --Dereckson (talk) 20:46, 13 September 2014 (UTC)
But what are you proposing? If you want to go back to en.wiki and convince editors there to split the tens of thousands articles that are about both the song and the single, I'd be stunned if you get any support. So how do you plan to share the site link on two items? Pichpich (talk) 20:53, 13 September 2014 (UTC)
Okki offers a good analogy: if we have an article about an album, this article could contains several paragraphs, one per song, but still be an article about the album.
So an article about a single could also speak about the song on the single.
For him, in such case, the link is to put on the single item ; and when an article is clearly about a song, the link is to put on the song item. --Dereckson (talk) 21:16, 13 September 2014 (UTC)

Each song and each single needs its own item. But we need a way to model, that: ItemsongA_version1 and ItemsongB are treated in en:articlesingleA and ItemsongA_version2 ist treated in en:articleartistA, but ItemsongA_version1 is treated in de:articlealbumX and ItemsongB is treated in de:articlesongB, while ItemsongA_version2 and ItemsongB is treated in fr:articlesingleA. Moreover from every of the articles must be a short and easy way for readers of Wikipedia to find all of these items and articles per one or two clicks. --Diwas (talk) 23:29, 13 September 2014 (UTC)

That would be perfect but as far as I understand this is not currently possible and there's no real plan to make it possible in the future. Can anyone confirm this? Pichpich (talk) 03:27, 14 September 2014 (UTC)
@Pichpich, Dereckson, Pigsonthewing:[ Hi, this seems very similar to the work/edition problem discussed by the Book project. To be consistent, maybe a Work item and two editions items (if needed) could do the trick. Maybe the most important item is the work item, who is declined. A reuse or make the scope broader of the properties used by the project for edition items. This could be use to build Wikidata queries queries in templates

Aubrey
Viswaprabha (talk)
Micru
Tpt
EugeneZelenko
User:Jarekt
Maximilianklein (talk)
Don-kun
VIGNERON (talk)
Jane023 (talk) 08:21, 30 May 2013 (UTC)
Alexander Doria (talk)
Ruud 23:15, 24 June 2013 (UTC)
Filceolaire (talk)
Kolja21
Jayanta Nath
Yann (talk)
John Vandenberg (talk) 09:14, 30 November 2013 (UTC)
JakobVoss
Danmichaelo (talk) 19:30, 16 February 2014 (UTC)
Ravi (talk)
Vlsergey (talk)
Mvolz (talk) 08:21, 20 July 2014 (UTC)
Hsarrazin (talk) 07:56, 9 August 2014 (UTC)
Accurimbono
Mushroom
Danneks
Pictogram voting comment.svg Notified participants to Wikiproject Books @Micru: you could be interested

TomT0m (talk) 09:24, 15 September 2014 (UTC)

Quick answer: You definitely don't need to worry about Wikipedias and what they do. Just concentrate on Wikidata: For each single that has no Wikipedia article for either of its songs, make one Wikidata item with a label such as "More famous song, flip side: second song". In the case one or the other song is already in some Wikipedia and there is a song item, then make one Wikidata item with a label such as "Existing song, flip side: other song". Whenever the songs are added, edit their items to include "part of" linking to the single item. The single item needs a "depicts"-like property for the individual songs, don't know offhand what that is. Jane023 (talk) 10:26, 15 September 2014 (UTC)
"You definitely don't need to worry about Wikipedias and what they do." Yes, we do. We don't need to slavishly follow it, but people are clearly making links based on what's on Wikipedia, and using Wikipedia categories to auto-populate Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:25, 15 September 2014 (UTC)
Actually I think that is what is preventing more people from participating in Wikidata: a mistaken idea that multiple concepts bundled into one article must somehow be linked in their entirety on Wikidata. If Wikidata untangles these concepts and splits them out, that is a good thing. It is then up to the Wikipedias to keep the concepts bundled or split them out. Presumeably at some point infoboxes will be far enough along that they can bundle the Wikidata items back up for the "concept bundlers", but personally, I am in favor of splitting everything up to the atomic level. Jane023 (talk) 12:03, 15 September 2014 (UTC)
@Dereckson, Pichpich: As TomT0m says this is exactly the same case as with bibliographic information. There is a work, a version of a work (releases), manifestations of a particular version (recordings), and exemplars (one CD, one file, etc). It would be nice if you could start the Wikiproject Music so users know about this structure. In most cases it is enough to have one item to represent it all, but in some other cases you might want to create all of them.--Micru (talk) 16:36, 15 September 2014 (UTC)

I concur with the Jane023's untangle and atomic-level describe rationale. --Dereckson (talk) 18:21, 15 September 2014 (UTC)

It is perhaps easier to decide how to proceed if we look at a specific example: Make You Feel My Love (Q1886329). It's a song written by Bob Dylan but first recorded and released as singles by Billy Joel and Garth Brooks (under a slightly different title). More recently Adele released it as a single. Countless other artists have recorded it. Do we really want one article for the song, four articles on the singles, four articles about these versions of the song and another few dozen for the somewhat lesser known recordings? And which of these items gets the en.wiki link? Pichpich (talk) 18:39, 15 September 2014 (UTC)

That's easy - make Wikidata items for all the ones you want, and don't update Wikipedia at all. I would it would be great to have Wikidata items for all of these that link back to the original song item. Leave the Wikipedia link as is, as that is the most generic choice (the original song on Wikidata should be the linking pin item in a web of recording items linking back to that item). Jane023 (talk) 08:28, 16 September 2014 (UTC)


Mattsenate (talk) 13:11, 8 August 2014 (UTC)
KHammerstein (WMF) (talk) 13:15, 8 August 2014 (UTC)
Mitar (talk) 13:17, 8 August 2014 (UTC)
Mvolz (talk) 18:07, 8 August 2014 (UTC)
Daniel Mietchen (talk) 18:09, 8 August 2014 (UTC)
Merrilee (talk) 13:37, 9 August 2014 (UTC)
Pharos (talk) 14:09, 9 August 2014 (UTC)
DarTar (talk) 15:46, 9 August 2014 (UTC)
HLHJ (talk) 09:11, 11 August 2014 (UTC)
Lawsonstu (talk) 15:15, 11 August 2014 (UTC)
Blue Rasberry (talk) 18:02, 11 August 2014 (UTC)
Micru (talk) 20:11, 12 August 2014 (UTC)
JakobVoss (talk) 12:23, 20 August 2014 (UTC)
Finn Årup Nielsen (fnielsen) (talk) 02:06, 23 August 2014 (UTC)
Jodi.a.schneider (talk) 09:24, 25 August 2014 (UTC)
Abecker (talk) 23:35, 5 September 2014 (UTC)
Andy MabbettTalk to Andy; Andy's edits
Pictogram voting comment.svg Notified participants to Wikiproject Source MetaData Just chiming in to say that we created Wikidata:WikiProject_Source_MetaData for discussions like these! Also pointing to this discussion of a "manifestation of" property from User:Micru, Wikidata:Property_proposal/Creative_work#manifestation_of- I actually brought up there the issue with songs there in particular, i.e. Silent Night which has a large number of "performers" listed. I agree with Jane023 that where combining the works seems confusing to you, the best practice would be to make separate wikidata items. But it would be nice to have a property so we can link them together. Mvolz (talk) 14:29, 20 September 2014 (UTC)

President of Bolivia[edit]

This item is a mix of lists and singular. I am quite happy to use it in the singular but I am not well able to distinguish between them in all the possible languages. Truthfully, I only need the singular and I cannot be bothered splitting them properly.

What I can do is create a split and chuck out all the obvious list items. This does create a mess. However, this is a side effect of the "decision" to split. My question therefore is "what to do". As it is I just assume that this instance is singular and I add all presidents of Bolivia to it. Thanks, GerardM (talk) 16:39, 15 September 2014 (UTC)

GerardM You know my opinion. All these pages, whether they are called 'list of' or not, relate to the class of people who have held the office of President of Bolivia. As such it should be the target of 'office held' statements about these people and should be renamed to reflect this. Filceolaire (talk) 20:23, 15 September 2014 (UTC)
In Russian this item it linked to list. And list is not a valid option for "office held". It shall be split in two items ("President of Bolivia" and "List of presidents of Bolivia") and used as value of "office held" only after that. Well, you will brake interwiki by doing that, so take care. -- Vlsergey (talk) 06:16, 16 September 2014 (UTC)
Hoi, I love opinions. I do not know Russian and most other languages. I can break things up, I cannot put them back together again. A list is not a building and an institution like you see often in a college. It makes sense to break these up. Not so much in lists and items. They are a WMF construct anyway. Thanks, GerardM (talk) 06:26, 16 September 2014 (UTC)
@GerardM: another option is not to care about interwiki, create new element "President of Bolivia", NOT move interwiki to it and use it as qualifier both to list and as "office help" value. -- Vlsergey (talk) 06:31, 16 September 2014 (UTC)
From a data management point of view this is a hopeless proposal. It is much better to have two items, one for list and one for singular and isolate the links waiting for someone to fix things. What would we do with all the existing statements for instance... The new item would be the singular anyway. Thanks, GerardM (talk) 06:49, 16 September 2014 (UTC)
@GerardM: From a data modelling point of view 'lists' don't exist. They are a strange wikipedia concept we have to include because they have pages. Classes however have a meaning and fit right in on wikidata.
having two items and splitting the sitelinks between them makes interlanguage links between them makes wikipedia worse too. Splitting has no advantages
Vlsergey The Russian article may be called a 'list' but it is still about a class of people and should be linked to the item about that class of people even if that item is called 'President of Bolivia". Change the russian label for the wikidata item to 'President of Bolivia' (with 'list of ...' as an alias) and it is a valid option for 'office held'. Generating the list automatically should also be much easier when the item links directly to the target of these statements. Filceolaire (talk) 17:43, 16 September 2014 (UTC)
@Filceolaire: The President of Bolivia (Q373548) is a mix, primary goal of such mix -- to create interwiki links between de-facto different items -- ones are lists (not only Russian one), others are about position. Before using such items as property value we need a common policy. I can't agree to policy "let's count list as class" because it is not correct and will create problems. It's already a problem with Q13403037 (Q13403037) and List of early East Slavic states (Q393871). Policy "let split them apart" would be much better, but requires additional software support to show links from linked items on interwiki panel. -- Vlsergey (talk) 02:01, 17 September 2014 (UTC)
Vlsergey You say you "can't agree to policy "let's count list as class" because it is not correct and will create problems". I say it is correct and will not create problems and I have presented arguments. Can we agree that until the additional software is available we should count lists as classes and see if any problems arise.
Note that the wikipedias don't think links between these are inappropriate - they want sitelinks between these. Can't we just agree that an article which just has a list or which just discusses are both incomplete and each needs the missing bit.
Remember that this policy applies not just to Presidents. It also applies to mayors in every little hamlet around the world. Creating two items for each of these would fill wikidata with unneeded cruft. Filceolaire (talk) 20:34, 18 September 2014 (UTC)
@Filceolaire: i did provide very good argument against such policy just above: Q13403037 (Q13403037) and List of early East Slavic states (Q393871). Do you want another example? I do have: President of Russia (Q218295) and list of presidents of Russia (Q6861127). It is not correct to count list or objects as class -- just because we already have different Wikipedia items about those. -- Vlsergey (talk) 07:34, 19 September 2014 (UTC)

calling all German and Italian speakers[edit]

I've been making lists of items where the item's description or label has zero (0) words in common with the article of the Wikipedia in that language, or in other words two lists, one where Description ∩ Article = Ø and the other where Label ∩ Article = Ø. This method is good at finding unhelpful edits in English so I tried it for German and Italian, and unfortunately it is very inaccurate but a speaker of that language can scan the list and quickly find vandalism or other junk. --Haplology (talk) 01:47, 16 September 2014 (UTC)

Thanks for these lists. I have started to work on the German one. But there might be some false positives, e.g. Isaac Habrecht (Q1673486). Its German description "Uhrmacher" is found twice in the German article. --Pasleim (talk) 19:23, 16 September 2014 (UTC)
Thanks for the feedback. I think the problem with Isaak's article was that the extractor (WikiExtractor.py) was confused by the * mark. The script throws away lists and maybe it thought that the text following * was a list item. The other instance of "Uhrmacher" was inside a template, and the script throws out templates too. Maybe later I'll scan the XML dumps directly, but it seems hard... --Haplology (talk) 00:41, 17 September 2014 (UTC)
Thank you for the Italian list. I have started to work on it. --FRacco (talk) 01:22, 17 September 2014 (UTC)
Thanks, noted. --Haplology (talk) 10:55, 17 September 2014 (UTC)

@Haplology: Can you make this list for other languages too? e.g. czech (cs) one? JAn Dudík (talk) 05:23, 17 September 2014 (UTC)

I'd be glad to. I make them one by one and and it takes a little time but I'll put it up at User:Haplology/cs when it's done. --Haplology (talk) 05:28, 17 September 2014 (UTC)
@JAn Dudík: It's up. It might be only 10% accurate but I hope it helps.
I posted this at Wikidata:Café, but in case any interested Spanish speakers are reading this, you might want to look at es. --Haplology (talk) 10:55, 17 September 2014 (UTC)

@Haplology:, can we try Russian too? But list for descriptions can be very bad because of declensions... --Infovarius (talk) 09:08, 18 September 2014 (UTC)

Please merge two items[edit]

For categories: Q9605295 and Q8768211 . Thanks, --Piotrus (talk) 07:15, 16 September 2014 (UTC)

Done by GZWDer. --Dereckson (talk) 11:05, 16 September 2014 (UTC)

request to get items without labels in language XX[edit]

I'd like to get all items with only russian label - or other language - without label in FR language... is it possible ?

Special:EntitiesWithoutLabel/fr gives ALL items without FR label, in antechronological order, which is not what I'm looking for. Is there an autolist request that would do it ?

Even better would be to get all instance of (P31)  human (Q5) without FR label :) - or any statement/any language combination, of course ;)

That would be very useful :) --Hsarrazin (talk) 12:29, 16 September 2014 (UTC)

Tools can offer you results for queries you can execute in 0-20 seconds.
When a 4-10 minutes time is required, this is not convenient for web interfaces. You have to ask what you want previously, so we can prepare a periodic job to run a query and format the result (or request a Wikimedia Tool Labs access if you wish to dive into SQL and do yourself such queries).
I'm preparing the instance of (P31)  human (Q5) to see if it's a good strategy to automate that. --Dereckson (talk) 12:06, 17 September 2014 (UTC)
sorry :( - I thought it was possible with Autolist but I just could not get the syntax ok... I did not want to make you build a tool :) --Hsarrazin (talk) 12:27, 18 September 2014 (UTC)

Get Q for the current Wikipedia page[edit]

I really stock with it. Say I am on w:ru:Фотиева схизма and I need to know that it is Q3813712 at Wikidata. The engine itself perfectly knows it as the link to Wikidata is already at the page side menu. Yet I failed to find any obvious way to obtain this data either by "magic words" or by mw:Extension:Wikibase Client/Lua. So far I am using quick'n'durty way over API and Javascript: first quering https://www.wikidata.org/w/api.php?action=wbgetentities&sites=ruwiki&format=json&props=info&titles=Фотиева_схизма and second (as Q property in the returned object is actually what we need to find) a lesser trivial for-in loop:

function onSuccess() {
  var data = JSON.parse(xhr.responseText);
  var q = '';
  for (q in data.entities) {break;}
  return q;
}

I agree that it looks just as it is: a rather sick pervertion — but I really couldn't find yet something normal. --NeoLexx (talk) 13:18, 16 September 2014 (UTC)

  • @Neolexx: did you try mw.wikibase.getEntityObject().id ? -- Vlsergey (talk) 13:47, 16 September 2014 (UTC)
    • Perfect, thank you! If there is something as simple to query Wikidata API then I'll be totally happy. --NeoLexx (talk) 13:59, 16 September 2014 (UTC)
There is also mw.config.get('wgWikibaseItemId') Javascript. --JulesWinnfield-hu (talk) 14:16, 16 September 2014 (UTC)

After a throughout reading I also found a way over API of the corresponding Wikipedia via mobileview query. For the same example from ruWiki it is possible
https://ru.wikipedia.org/w/api.php?format=json&action=mobileview&prop=pageprops&pageprops=wikibase_item&page=Фотиева_схизма
and then
Q = jsonObject.mobileview.pageprops.wikibase_item for Wikidata API compliant form or
Q = jsonObject.mobileview.pageprops.wikibase_item.substring(1).parseInt(10) for WDQ API compliant form.
Still it most definitely needs to be a feature of action=wbgetentities of Wikidata API itself, not some side use of mobileview from local wikis. And WD/WDQ format choice in the query itself would be also helpful. --NeoLexx (talk) 11:29, 18 September 2014 (UTC)

"Instance of" for periodic events[edit]

Between Frankfurt Book Fair (Q57293) and 2010 Frankfurt Book Fair, which one is an instance of trade fair (Q57305) ? (I would say the 2010 edition). And any idea for the P31 of the other ? --Zolo (talk) 07:28, 17 September 2014 (UTC)

I would say that the 2010 Frankfurt Book Fair is an instance of Frankfurt Book Fair (Q57293) which is a subclass of trade fair (Q57305), thus implying that the 2010 Frankfurt Book Fair is an instance of trade fair (Q57305) without having to add an extra statement. --Yair rand (talk) 08:32, 17 September 2014 (UTC)
That seems reasonable, but what I do not like is that it does not make any distinction between say "Frankfurt Book Fair" and "Book fair". There should be something telling that Frankfurt Book Fair feels like an individual event, while Book fair does not. Maybe we could need an item Frankfurt Book Fair and Detroit Motor Show, but not to "Book fair" or "auto show". But I know neither how it should be labelled nor how it should be structured. If the new item is used as a P31 for Frankfurt Book Fair, it should probably not be a subclass of trade fair, else both Frankfurt Book Fair and 2010 Frankfurt Book Fair would end up being instances of trade fair. --Zolo (talk) 08:54, 17 September 2014 (UTC)
This imo is related to the metaclass notion : if Book fair is a class of periodical events, then "Frankfurt Book Fair" is an instance of it. To be consistent, we could create two items Book fair for the class of sigular event, and Periodical Book Fair for the class of events. Then we coud have :
TomT0m (talk) 11:47, 17 September 2014 (UTC)
To draw a more complete picture : imagine we associate properties to instances of a class. The periodical events class is then convenient, it would have a potential periodicity or day in year property associated. The Event class would have the point in time (P585) miga property associated, on the contrary. This picture is consistent with the scheme I proposed, the <Frankfurt Book Fair> has a periodicity, and the <2010 Frankfurt Book Fair> has a date.
I'm with Yair rand on this: 2010 Frankfurt Book Fair is an instance of Frankfurt Book Fair (Q57293) which is a subclass of trade fair (Q57305), or book fair, or periodical book fair. Emw (talk) 00:37, 18 September 2014 (UTC)
Symbol support vote.svg Support LaddΩ chat ;) 01:55, 18 September 2014 (UTC)
It seems that we all agree that the 2010 Frankfurt Book Fair should be an instance of Frankfurt Book Fair, and the Frankfurt Book Fair an instance of Book Fair. But I think like TomT0m that we should have a P31 (or, perhaps, a p279) in Frankfurt Book Fair so that we distinguish items about a identifiable fair like Frankfurt Book Fair from more generic subclasses of book fair like children's book fair. "Periodical Book Fair" might not be the clearest label though, because it feels like it is a subclass of Book Fair while the two classes are really disjoint). --Zolo (talk) 07:54, 18 September 2014 (UTC)
Yes, not only they are really disjoint, but if we associate a level in the individual (0)/class (1)/metaclass or class of classes (2) model I proposed, one is on the (1) level (the Frankfurt BookFair class) and the other on the (2) level (the <Periodical Bookfair> metaclass). Conceptually it is important not to mix levels if we want to keep things well founded : an item in the level (1) can only be a subclass of other items in the level (1), and an instance of items in the level (2), an item in the (0) level can only be an instance of an item in the (1) level, and absolutely not an instance of items in the level (2) as this would mix class and metaclass instances, ...
This works pretty well in our case here : a specific edition of Frankfurt Bookcase is an instance of Bookcase, Frankfurt Bookcase (as a class of event) is an instance of <periodical events> (and periodical events instances are classes of concrete events themselves), and this is also consistent with the class/properties of their instances classical scheme we also find in Object Oriented programming languages, or in OWL in a more powerful way.
But you are right, maybe another label to <Periodical Bookfair> would help, or at least an explicit description like Bookfair events classes in a common place and date in year. TomT0m (talk) 09:49, 18 September 2014 (UTC)

What should we do with wrong data from Wikipedia ?[edit]

I have been trying to fix some coordinates using fr:Catégorie:Page avec coordonnées différentes sur Wikidata (currently triggered when wikipedia coordinates are more than 10 kms away from Wikidata's). When the issue comes from fr.wikipedia's coordinates, that is pretty simple: I just delete local frwiki data and the template calls Wikidata instead. But when the issue comes from Wikidata's coordinates, that is more complex. I can fix Wikidata's coordinates. But they have usually been copied from local Wikipedia's values that should be fixed too. I can fix them in the language indicated by the "imported from", but that takes more time. And as errors have often been copied across projects, that does not entirely solve the issue. I can also mark the erroneous data as "deprecated" and let bot see about fixing Wikipedia, but I am not sure this is the most efficient solution. Any other idea ? --Zolo (talk) 13:27, 17 September 2014 (UTC)

The deprecation solution seems not so bad : it leaves a trace that the value was checked by someone. TomT0m (talk) 14:37, 17 September 2014 (UTC)
Marking wrong coors as deprecated does not make a sense for me. In situations like that i simply delete wrond coors from WD (and hoping that some bot will not import wrong coors from another wiki), hoping that most of the wikis will call coors from WD soon. --Jklamo (talk) 10:10, 18 September 2014 (UTC)
+1. Deprecated should be used only with a value having a reference. If you have another value with a reference, the imported value from WP correct or not has to be deleted. Snipre (talk) 10:17, 18 September 2014 (UTC)
Just deleting incorrect (or inappropriate) coordinates are not enough. They are soon imported again. I have started to set "no value" in those cases instead. When it comes to imported data, French Wikipedia is the most frequent source of incorrect coordinate location (P625) and incorrect is in the administrative territorial entity (P131) when it comes to items with coordinates within Swedish territory. /ℇsquilo 12:06, 18 September 2014 (UTC)
@Jklamo: that seems to place a bit too much faith on hope ;). But anyway even if Wikidata want to switch to an all-Wikidata based system, this does not appear like a good solution. If we just delete wrong data in Wikidata without deleting we will have different data in Wikipedia and in Wikidata. If Wikipedia's data are different from Wikidata's, we should not remove them from Wikipedia until we have checked that Wikidata's are either the same or more accurate. If the bad data have been removed from Wikidata, there is no way to do it automatically, so we have to do that by hand all over again. That is one big time waste. If we keep the wrong data in Wikidata, but mark them as deprecated, we know that these are wrong data, and a bot can remove them from Wikipedia. There may be better solutions (that is why I was asking), but unless we have made sure wrong data have been removed from all Wikipedias, depcrecating is certainly better than just removing bad data in Wikidata.
@Snipre: if we have a value with an external reference but that is clearly wrong, it does not seem very reasonable to delete data imported from Wikipedia that appear to be right just because of that (not mentionning that most coordinates data will possibly never have a proper reference, and may not need one).
@Esquilo: Sorry but I do not understand how things would work with "no value", could you give an example ? --Zolo (talk) 12:19, 18 September 2014 (UTC)Zolo (talk) 10:32, 19 September 2014 (UTC)
The core of problem here is the way how data is transferred from Wikipedia to Wikidata. There always should be someone who is responsible for data. If all data is just copied from Wikipedia, noone is responsible -- because Wikipedia authors do not care about data on Wikidata. The only way to make the data actual and remove errors is to remove data from Wikipedia as soon as data is transferred to Wikidata. That's exactly as done in Russian wikipedia: all data from a number of infoboxes is moved from Wikipedia to Wikidata. Along with it we have a number of reports about differences -- and as soon as they resolved, data would be moved to Wikidata completely. Because of that Russian Wikipedia will look after those data (birthdays, deathdays, birth place, death place, nationality, gender, official website) because it is the data actually shown in infoboxes. If it's okay to repeat myself, as I already said on Wikimania-2014 meeting, there should not be any second data copy from Wikipedia to Wikidata. As soon as data is copied from some Wikipedia to Wikidata it shall be prohibited to copy them second time (the same data), i.e. Wikidata should me master copy of data, not any Wikipedia. Not even German. -- Vlsergey (talk) 07:31, 19 September 2014 (UTC)
You demonstrated the consequences of your way: Gadget to create local copy of Wikidata (to disable Wikidata update). Nobody at dewiki is willing to use unreferenced data. So the main question is: how do we improve referencing to relaiable sources. --Succu (talk) 09:09, 19 September 2014 (UTC)
@Succu: 1. It is very obvious consequence and i do not see anything wrong with it until we have sufficient technical support to do the same at MediaWiki level. We need to use common data and at the same time we need control over how it's embedded in protected and semi-protected wikipedia pages. 2. dewiki problem is more "deeper" -- they just don't want to. Doesn't matter if data would be referenced or not. It is just outside of dewiki, so dewiki will not use it. They want to have control over their data and references has nothing to do with it. 3. Original question was not how to handle unreferenced data, but how to remove errors from data. In wikipedia 99.99% of information has no references. Obviously Wikidata would have 90% at min unreferenced but sensitive data. Question should be not how to change it (it's impossible) but how to live with it. 4. The main idea of my answer was "data won't be good until someone would start to use them". Even with restrictions and limitations. -- Vlsergey (talk) 09:40, 19 September 2014 (UTC)
Vlsergey, I think I know a little bit more about the concerns of dewiki (2), but your statement proved them all: Yeah they have data (4), lets use us these unreliable (=unsourced) data (3), because they are data. If we don't like them, let's make us a local copy of wikidata, after we dropped our precious data into wikidata (1). Do you really think this bot-way leads to a better acceptability of wikidata? As you know dropping several database ids from ruwiki into wikidata causes a lot of work, fixing false data. --Succu (talk) 19:59, 19 September 2014 (UTC) BTW: Even coordinates could be sourced: Q4518823 (Q4518823) (see de:Liste der Galapagosinseln#Literatur, my only contribution to dewiki using coordinates).
re Vlsergey. I agree, but it cannot be done for all languages at the same time. Wikpedias often copy each other (especially for basic, language-independent things like coordinates). It means that if data were imported from xwiki to Wikidata, and removed from xwiki, and if someone finds that the data are wrong and corrects Wikidata, it may still be useful to keep them with rank "deprecated" in case other Wikis have the same wrong data.--Zolo (talk) 10:32, 19 September 2014 (UTC)
@Zolo: i don't think it is a good way. Let's consider an example:
  1. bot checks article in xxwiki and finds that birthday field is 1 April 1234 year;
  2. bot checks Wikidata and found there are two values: one is "1 April 1234" and marked as deprecated, second is "2 May 2345" and marked as normal
  3. bot does not edit xxwiki article (not removing "1 April 1234") neither edit Wikidata (add "1 April 1234" to values list), but adds the article to local "discrepansies" xxwiki report, because if he touch anything he would change article content (and by default he must not)
another variant:
  1. bot checks article in xxwiki and finds that birthday field is 1 april 1234 year;
  2. bot checks Wikidata and found there are single value: "2 May 2345" and marked as normal
  3. bot does not edit xxwiki article (not removing "1 April 1234") neither edit Wikidata (add "1 April 1234" to values list), but adds the article to local "discrepansies" xxwiki report, because if he touch anything he would change article content (and by default he must not)
since there is no difference, i don't see the reason to keep incorrect data in Wikidata unless some source (real source, not Wikipedia) displays them. -- Vlsergey (talk) 10:51, 19 September 2014 (UTC)
@Vlsergey:. I was assuming that if local data are equal to those marked as deprecated in Wikidata it was ok to automatically replace them with those marked as normal. Maybe Wikipedias will not be willing to do that, but still I think it would be a sensible way to go, especially for data like coordinates or birth dates, that should usually have just one value. If someone marks a birth date as deprecated and keeps the other one as normal, it is hopefully because the latter is more correct. It may happen that someone or a bot will add a wrong birth date after that. But that should not happen too often because we do not encourage bot to import birth dates from Wikipedia to Wikidata when there is already one. And if it does, we would end up with two birth dates, with at least one without "real" references, and that would be a suspicious case that needs to be checked. In a worst case scenario, the local wrong value will be replaced with an even wronger Wikidata value. But that will most likely be a small minority of cases, so that this way of doing things would still be reasonable. --Zolo (talk) 12:23, 19 September 2014 (UTC)
@Zolo: Wikipedias will never agree to replace their values with Wikidata ones -- not until we prove that Wikidata is more correct than Wikipedia (in 10-15 years, i believe). Because of that so far I don't see how having such values would help. If there is a error in bot code, bot can do anything, including deleting all the claims. Bot shall be fixed. If there is no error, it doesn't matter if we have deprecated value (alongside with correct one) or not. For existing Wikidata values xxwiki [bot] should check their data and not add their value to Wikidata, unless they provide sources and change the ranks accordingly. "If someone marks a birth date as deprecated and keeps the other one as normal, it is hopefully because the latter is more correct" -- the same here: "If someone removes a birth date and replace it with the other one, it is hopefully because the latter is more correct" -- Vlsergey (talk) 12:45, 19 September 2014 (UTC)
@Vlsergey:. It surely depends on the sort of data, but take coordinates that are rather non controversial. Errors usually have pretty trivial reasons like messing up with the decimal conversion. Once they are noticed they are pretty obvious. If someone has marked a value as deprecated there is not much doubt that the value is indeed wrong. The few coordinates that I marked as deprecated were mostly from Dutch and Russian Wikipedias, but it may be that 10 other Wikipedias have the same. If they see that their data matches a deprecated Wikidata value, can they automatically delete them and use the normal or preferred Wikidata values instead ? I think they can. --Zolo (talk) 15:21, 19 September 2014 (UTC)
@Zolo: "can they automatically delete them" -- let's start from other point. Do you already have some Wikipedia in mind that will do that? Does it have timeplan and bot flag/task request discussion? Because i just don't believe that any Wikipedia would do it. And if noone will -- such data is not required. In case someone would -- I would like to have some kind of "delete after" timestamp to cleanup those incorrect data. -- Vlsergey (talk) 17:21, 19 September 2014 (UTC)
Many properties has {{Constraint:Single value}}. Bots must not add more than one value per item for these properties. And bots must not replace existing property values because bot can not decide that data is correct in general case. So it is enough to fix invalid data in Wikidata. And we need fix or block bots who are trying to add more than one value or replace existing. Saving a number of values with deprecated rank is very unpleasant way. Collecting errors — is not Wikidata goal. — Ivan A. Krestinin (talk) 07:29, 21 September 2014 (UTC)

Special:SetSiteLink cancel button suggestion[edit]

Usually, when you click an "edit" link somewhere on WD, there's also a "cancel" link in edit mode. But there is no Cancel button when assigning badges; you can only use the browser's Back button or whatever. So, could Special:SetSiteLink/Q123456 (i.e. could the screen when assigning badges) have a Cancel button too, please? It Is Me Here t / c 13:48, 17 September 2014 (UTC)

I cannot imagine what is the specific purpose of button "cancel". Can you tell? --Infovarius (talk) 09:22, 18 September 2014 (UTC)
In case you press the wrong thing, and don't want to screw the page up. It Is Me Here t / c 00:48, 19 September 2014 (UTC)

Label lister not working[edit]

The new (BETA) version of the labellister doesn't seem to work. Is it just me? --- Jura 14:08, 17 September 2014 (UTC)

Same for me, will not let me save my changes after Preview; had to switch back to released version. It somehow got broken in the last few days. Author is @Jitrixis: - LaddΩ chat ;) 02:03, 18 September 2014 (UTC)
I miss it already. --- Jura 22:58, 18 September 2014 (UTC)

Property values full list[edit]

Hello. Is there any possibility to get a full list of possible values for some property? Thank you very much in advance, (IKhitron (talk) 10:56, 18 September 2014 (UTC))

@IKhitron: The set of all possible values for a property is listed in the field "allowed values", on the "talk page" of each property, like Property talk:P190 or Property talk:P17.
However if you rather want to get the list of all values that are actually being used (as of now), I don't know. A bot or a WD query, possibly. LaddΩ chat ;) 01:50, 19 September 2014 (UTC)
Thank you very much. It did not help in this specific case because I can see there "Any item that represents a class; any item that is not an instance", but at least I know the direction to search. (IKhitron (talk) 12:57, 19 September 2014 (UTC))
@IKhitron: : Any item that represents a class : this is any instance of class, if our tree is somewhat complete (not yet probably), so it's a pretty big number of item. One query that might be an approximation is any item that has a subclass of items with a subclass of claim. Which property are you talking of, instance of (P31). ? TomT0m (talk) 15:14, 19 September 2014 (UTC)
Thank you for your answer. Indeed, this is the one. (IKhitron (talk) 19:36, 19 September 2014 (UTC))

Big articles in English wikipedia and linking to subheaders[edit]

Sometimes English wikipedia does not have a corresponding article, and then I would like to interwiki-link to section of an article. This was possible in pre-Wikidata era.

This is not possible anymore? Also an interwiki-link to a section of article disables linking to a (whole) article, because target article can't be referenced multiple times from source wiki.

So (English) wikipedia articles should not be created as one huge article, but as a modular article with sub-articles.

Here is the case that I tried: source of a interwiki-link: https://fi.wikipedia.org/wiki/Ristikulma target of a interwiki-link: https://en.wikipedia.org/wiki/Angle#Intersecting_angle_pairs

--Pasixxxx (talk) 10:06, 19 September 2014 (UTC)

It has to be done the "old fashioned" way by adding the link to the bottom of the page. Unfortunately it's only one way "fi -> en". I've added the link to the bottom of the Finnish page. 130.88.141.34 12:12, 19 September 2014 (UTC)
Many long Wikipedia articles were not created large to begin with, but grew organically to their current size. It would probably be good for readability to split these to match up with other languages, but using Wikidata as a reason is not a good idea. Jane023 (talk) 17:35, 19 September 2014 (UTC)
Temporarily remove the redirect from the WP page, link the page to Wikidata, then put back the redirect again. This has been a long-lasting discussion. 132.208.169.223 21:48, 19 September 2014 (UTC)

Wikidata for GLAMs Workshop: November 14, Amsterdam[edit]

Wikimedia Nederland is organising a Wikidata for GLAMs workshop on the 14th of November 2014 in Amsterdam. The invitations have just been send out. I might need some help with writing tutorials, small assignments, etc. It would also be nice to know if anyone is available for assistance through IRC in case we need more thinking power or get stuck with anything. If anyone is interested in helping with this or would like to receive a message where to find the content, please contact me. Ter-burg (talk) 13:35, 19 September 2014 (UTC)

Vital Article badge?[edit]

Should we have Vital Article as a badge? There's currently Top-importance articles (Q17580682) at Category:Badge items, but I'm not sure that's the same thing. It Is Me Here t / c 15:52, 19 September 2014 (UTC)

We should have badges for all quality/importance rankings. And maybe vital articles as well. --Jakob (talk) 01:49, 20 September 2014 (UTC)

Rendering of Module pages ?[edit]

Why is it that some module pages get rendered nicely, eg Module:Wikidata link, but some don't, eg Module:Infobox ?

Is there any reason for this? (Does it sometimes get better by itself ?) There doesn't seem to be anything obvious in the wikitext of the page to explain it. Jheald (talk) 21:04, 19 September 2014 (UTC)

There is an reason for this, yes and no it does not get better automatically. In order to understand the cause of the issue you need to know that Module:Wikidata link was created on wikidata while Module:Infobox was imported from the french wikipedia. Importing of modules is very broken and the root cause of that is mentioned in bugzilla:45750. Basically imports of modules tend to either fail compleatly, give broken display of the code like with Module:Infobox or somewhere in between the two.--Snaevar (talk) 13:31, 20 September 2014 (UTC)

Why? Modeling causes on Wikidata[edit]

Talk about causes is ubiquitous in everyday life and many other domains of knowledge. Until recently, we've had a few properties to make statements about cause in certain narrow areas, but lacked a way to structure data about causes across a broad range of subjects. For example, you might want to know:

Wikidata now has some new properties that provide structure for basic answers to such questions.

This approach to modeling causation attempts to balance expressiveness with simplicity. It borrows from the idea of causation as a "chain of events", which also has background conditions or events that set the stage for some outcome. These properties are not perfect, but they do allow us to capture much richness in how various sources talk about causes -- and to do so in a way that humans can easily understand.

Help:Modeling causes explains these properties, their background, examples, things to avoid, issues and context. Please comment on the 'Help:Modeling causes' talk page, or here, with any feedback. Note that a simultaneous thread exists on the wikidata-l mailing list at https://lists.wikimedia.org/pipermail/wikidata-l/2014-September/004631.html.

Hopefully we'll be able to build some cool stuff with this. Cheers, Emw (talk) 00:11, 20 September 2014 (UTC)

Don't forget cause of destruction (P770) /ℇsquilo 12:41, 20 September 2014 (UTC)
Indeed, and cause of death (P509), which motivated this broader approach to modeling causes. See Help:Modeling_causes#Related_properties. Emw (talk) 13:10, 21 September 2014 (UTC)

Label vandalism in a mainstream item[edit]

See Special:Diff/157874111/158717184 : 4 days of IP vandalism on the item on Mathematics. This seems pretty bad to me because it's not a burried item on an unknown topic ... Maybe a little tweaking of the vandalism filter would help a little though :) TomT0m (talk) 10:38, 20 September 2014 (UTC)

@TomT0m: These are things FlaggedRevs could help us with... :-)
What exactly is "a mainstream item"? How does AF recognize such an item?
By the way, the vandalized stuff was a description, not a label. Matěj Suchánek (talk) 17:10, 20 September 2014 (UTC)
I meant an item about a very important subject ( I guess the articles about maths are very consulted on Wikipedia, everybody child in school learns some maths ... compared to, let's say the mayor of a small town of a small country's item, I would think vandalism is caught fast ... This may be a bad sign for overall vandalism rate in Wikidata, hence for the quality of our datas (although less visible items are less exposed) (and it is not that much used yet. It could b a lot more I guess, alyhough a bit too general). TomT0m (talk) 18:19, 20 September 2014 (UTC)

Rafael Nadal (Q10132)[edit]

I tried to add the ATP-Doublesranking, but when I typed in his doubles ranking, "±1" is added to my entry. Can someone help me??? --Korrektor123 (talk) 16:58, 20 September 2014 (UTC)

It comes automatically, you have to make an another edit and change "±1" to "±0" so it goes off. --Stryn (talk) 17:25, 20 September 2014 (UTC)

Sortkey[edit]

Do we have a property for "Sortkey" ? (ie the string that ought to be used for sorting an item in a particular language). I can't seem to find it.

I see that we do have surname (P734) and given name (P735), but that is not helpful for an item like eg Sting (Q483203).

Sortkey is useful for eg: sorting WDQ results in order. It is also needed by some templates for ordering the categorisation of the page they are applied to.

Many many individuals on en-wiki have a Sortkey defined in their PERSONDATA. On Commons, it is also a standard part of the Creator template.

Did I miss it? Is it here all the time? Or is this a property that ought to be created? Jheald (talk) 18:32, 20 September 2014 (UTC)

I don't think you missed it. It actually seems a little weird in the Wikidata paradigm : sorting is something the user of the data might want to do but is not really a property of the datas themselves. It is moreother language (or worse) dependant. If you watch closely to surname (P734) and given name (P735), you will notice that their datatype is not string, which complicate further. Correct me if I'm wrong, but sortkey in your mouth means when we have to sort person by alphabeletical order of their name, we sort them by "sortkey" if available otherwise by family name then by proper name ? TomT0m (talk) 19:28, 20 September 2014 (UTC)
Well unless it is in the database, it is otherwise not possible to search by it. The <Family Name>, <Given Name> <Middle Names>, <title> format is pretty standard for many applications -- en:Wikipedia:Persondata notes that it is used both by the Library of Congress in the U.S. and by Deutsche NationalBibliothek -- so it is something that, if possible, we should aim to hold and be able to make available to those that want it. Another key example where this property is needed is to be able to properly format (or re-format) citations per certain style guides.
This is information that is not necessarily easy to extract from names. Of course, one can often make a good first guess; but it really needs the data to be stored to identify that it should be "Beethoven, Ludwig van" but "Van Zandt, Townes".
So, questions, before submitting a property proposal
  • Should this be a string or multilingual text ?
    Do different langages differ much, eg LoC <-> DNB ? Or are there clear language preferences ? If the latter, would language fallbacks work sanely ? Or, are there appropriate qualifiers that could be used to do the job.
In Irish names are sorted by the surname but without the Ó or Mac prefix. 86.6.111.107 02:27, 22 September 2014 (UTC)
  • Should diacritics be included ?
  • Should this apply only to personal names, or should eg Book-titles also have their standardised searchable forms recorded ?
  • Is there a better name for the property ?
... more ? Jheald (talk) 22:28, 20 September 2014 (UTC)
This seems to be a language characteristic or maybe a flag to be included in a query rather than a characteristic of the concept/item so I would be opposed to trying to describe this in the statements about the item. 86.6.111.107 02:27, 22 September 2014 (UTC)
And how do you propose to query it, if it's not in the database? Jheald (talk) 16:16, 23 September 2014 (UTC)

Wikidata Game Slow[edit]

The game is slow for me as I can it won't load in Chrome. I tried it yesterday and I couldn't login to it. Magnus anything? Eurodyne (talk | contribs) 21:58, 20 September 2014 (UTC)

Just restarted. Again. Currently on vacation, reduced connectivity. --Magnus Manske (talk) 20:03, 21 September 2014 (UTC)
Thanks a bunch! Eurodyne (talk | contribs) 20:07, 21 September 2014 (UTC)
Magnus Manske Is it down again? Eurodyne (talk | contribs) 02:01, 23 September 2014 (UTC)

Featured articles[edit]

How can I change an article (or page) to a featured article and vice versa? --Joe Watzmo (talk) 07:28, 21 September 2014 (UTC)

de:Wikipedia:Wikidata#Exzellente und lesenswerte Artikel (Sorry only in German language)
Wikidata:Project chat/Archive/2014/09#Removing badge --Diwas (talk) 09:55, 21 September 2014 (UTC)
helped, many thanks --Joe Watzmo (talk) 10:59, 21 September 2014 (UTC)

Fresh category members tool idea[edit]

Hi. I'd like to (and I'm almost in the process on) write a tool which would show latest category members -- with subcats, recursively -- for new page patrol purposes. It would be a web app where you type a wiki name and category name and get a list of category members sorted by time. Later on I'd have to implement pages (if there's too many) or limit the time frame. Is this worth doing given that categories would move to Wikidata soon? If so, how soon? Thoughts? (P.S. Please distribute to sister projects village pumps). Gryllida 07:32, 21 September 2014 (UTC)

Could you develop the idea?
Maybe you could join a wireframe showing the UI? --Dereckson (talk) 13:21, 21 September 2014 (UTC)
What is a "wirefeame"? Yes, I can try to develop it. You might know how work with databases performance is pretty hard, but I hope to try to complete. Gryllida 01:08, 22 September 2014 (UTC)
  • I like the idea. I am even thinking about more advanced gadget - "Category history", which should show also deleted members. But obviously it is quite hard query by now. As for future of categories - their elimination is a question of quite long time (I'd say - years). --Infovarius (talk) 19:38, 21 September 2014 (UTC)
Eliminate categories? This sounds like a good recipe to wipe out all sisters that don't happen to have Wikipedia-like category hierarchies. Wikivoyage would probably be unaffected. Wikinews does things differently, and would be deprived of control of that part of its own infrastructure. Wikibooks uses categories in a very different way, using both manually arranged structures and lots of stuff automatically generated based on the arrangement of pages in five (or it is six) different namespaces. --Pi zero (talk) 21:49, 21 September 2014 (UTC)
At the Commons village pump I was told that Wikibase/Wikidata wouldn't replace categories but would complement them. (And even if replace, I think Wikibase/Wikidata would be capable of implementing all the pretty things that are done at various projects by hand.) I'm still querying for documentation (was expecting the folks here to enlighten me with the details, too). Gryllida 01:08, 22 September 2014 (UTC)
I'm not planning to make it a gadget, because JavaScript doesn't have a means of querying the DB directly. I already know - I already tried - that API is slow and it is inappropriate for this tool, were it to go recursively (and I currently think it needs to do that). Thought I'd try to have it be a tool on WM Labs (as they have a near-live replica of the wikimedia projects database there). Gryllida 01:08, 22 September 2014 (UTC)

RfC on deletion vs redirect[edit]

FYI, I started a RfC on the issue of deletion vs redirect here. Lymantria (talk) 12:26, 21 September 2014 (UTC)

o que significar isso pode me imformar[edit]

Quero imformação sobre a wikidata 177.206.184.254 03:24, 22 September 2014 (UTC)

While linking languages together : An error occurred while saving. Your changes could not be completed.[edit]

I tried to link these two pages but neither wants to let me link to the other language page. There is obviously some conflict hiding in the works but I cannot figure out where to look.

The pages are equivalent.

The Finnish (Suomi) language ATS page directly translates to the English ALC page with the odd L.. at the end which correctly redirects to the English AGC page.

.

Idyllic press (talk) 20:34, 22 September 2014 (UTC)

I'm not sure what was the problem, but I've now merged Q782524 and Q11853587. Best regards, --Stryn (talk) 20:43, 22 September 2014 (UTC)
Stryn I think I may have figured it out. These were unique wikidata entries for two language versions so they were not able to add items from one linked list to the other linked list. I fixed another similar just now by deleting the lone entry and then it allowed me to add it to the longer list of linked languages. Thanks for the prompt service. What do I do in future if there are two groups of language links with many in each group, do I have the ability to do the merge that you performed?
Idyllic press (talk) 20:52, 22 September 2014 (UTC)
On Wikidata one item can have only one sitelink from a certain project. In Finnish: Heh, huomasin juuri että taidat osata myös suomea :) Yksi kohde (item) voi sisältää vain yhden sivustolinkin tietystä projektista. Eli fi-wiki-linkki samaan artikkeliin ei voi olla kahdessa kohteessa samaan aikaan. Voit yhdistää kohteita, kun otat käyttöön asetuksistasi pienoisohjelman "merge". --Stryn (talk) 21:02, 22 September 2014 (UTC)

Open Government WikiHack[edit]

Hello everyone,

Wikimedia DC is organizing the Open Government WikiHack from September 27–28 at the National Archives in Washington, DC. The Open Government WikiHack is a one-of-a-kind hackathon. Wikimedia DC and the National Archives are teaming up to come up with solutions that help integrate government data into Wikimedia projects, especially Wikidata. If you are in the area and you would like to get involved, you can sign up for free. Please let me know if you have any questions. Harej (talk) 21:37, 22 September 2014 (UTC)

Link to multilingual Wikisource?[edit]

Is it possible to link e.g. [1] to Category:Akkadian literature (Q8229677)? It Is Me Here t / c 12:46, 23 September 2014 (UTC)

Constraints checks for Wikisource work links[edit]

I noticed that some items related to Wikisource works contains links to both work and it translation. I think will be good idea to detect such items as candidates for splitting. Labels of such items may need cleaning too (since it may be translated in different ways).

We also need to have showcase items for works with translations (for example, Shakespeare, Byron, Conan Doyle), so user with Wikisource background could learn from them.

EugeneZelenko (talk) 13:57, 23 September 2014 (UTC)

Accepted qualifiers[edit]

I just realized that the suggestions for properties that are shown when you try to add a qualifier are not all accepted.

E.g. when you add a qualifier to date of birth (P569), place of birth (P19) is listed in the dropdown. However, Property talk:P569 lists only four possible qualifiers, none of which are in the dropdown. Wouldn't it make sense to populate the dropdown with only the accepted qualifiers? I assume that all other properties are available as qualifiers to allow new uses to emerge organically, which can be codified later? But currently the qualifiers we want/accept are effectively hidden to the editor. --Azertus (talk) 14:39, 23 September 2014 (UTC)