Wikidata September 2015

wikidata@lists.wikimedia.org

62 participants
50 discussions

Re: [Wikidata] [Commons-l] Trends in links from Wikidata items to Commons
by James Heald 13 Sep '15

13 Sep '15

To pick up on a few different comments from this thread: @revi (Hong, Yongmin) -- Yes, of course you are correct that it is categories rather than galleries that are the important structure for finding and navigating images on Commons. But even if we were to change the status-quo and ban sitelinks from Wikidata items to Commons galleries (which might not be 100% popular, since we currently have 87,000 sitelinks to galleries, up by about 3000 in the last year) -- even if we were to ban sitelinks to galleries, this would still leave the question of whether Commons categories should be sitelinked to categories or to articles. Currently there are 311,000 Commonscats sitelinked to category items on Wikidata, and 207,000 sitelinked to article items on Wikidata. So the status-quo is for Commonscats to be sitelinked to category items (and in the past has been even more so). The problem is that, the way the software exists at the moment, you can't have both. So if a Commonscat is sitelinked to an article item, that precludes a Commonscat being sitelinked to a category item, and vice-versa. At the moment, the expectation is that a Commonscat will be sitelinked to a category item, if possible. Of 323,825 Commonscats that can be identified with a Wikidata category item, 311,000 are connected by corresponding sitelinks. So if people are writing scripts or queries to look for such relationships, they will most likely look for sitelinks. On the other hand, of 884,439 Commonscats that can be identified with article-like Wikidata items, only 207,494 (= 23.4%) are connected by sitelinks -- even if this number has doubled in the last 12 months, the expectation in the current status quo is that such a connection is more likely *not* to be represented in a sitelink, by a three-to-one margin. Instead, links between Commonscats and article-like Wikidata items are currently overwhelmingly represented by the P373 property, which at the moment records 807,776 (= 91.3%) of such identifications. This is the property that the script https://commons.wikimedia.org/wiki/User:Jheald/wdcat.js looks up in order to display a link to Reasonator if there is a Wikidata article-item for a Commonscat. To get the best idea of whether there is a corresponding Wikidata item and Wikipedia articles for a Commonscat, Commons users should therefore use wdcat.js -- which is easily activated by adding a line to the common.js file, such as at https://commons.wikimedia.org/wiki/User:Jheald/common.js -- because this will pick up four times more connections than currently exist as sitelinks. The important think is to establish and preserve clear expectations, that software can build against. At the moment, with the confusion of sitelinks of Commonscats to articles and to categories, there is no guarantee that it is possible to create a sitelink to an article. On the other hand, it should always be possible to create a P373 connection. They are the connections that systematically *can* be made, so it is important to make sure that they systematically *are* made, to drag up the return rate from the current 91.3% to nearer 100%. That would be helped by a policy that was absolutely systematic in prescribing what should and what should not be sitelinked. @ RomaineWiki: You say that actively enforcing the longstanding Wikidata sitelink policy of only sitelinking Commons categories to category-like items, and Commons galleries to article-like items would be a plan to "demolish the navigational structure of Commons". But it wouldn't change any of the internal structures on Commons, and would merely underline the current fact that even now only 23% of Commonscats are linked to articles by sitelinks, compared to 91% by P373. Isn't it better to get Commons users used to using (and improving) the wdcat.js script, which uses the P373 property that can always be added, rather than perpetuating the current muddle of Commonscat <-> article sitelinks, which are so haphazard ? @ Steinsplitter As I understand it, the long-term plans for a new Wikibase structure specifically for Commons are currently no longer an immediate development priority; but will presumably start to move forward again sooner or later. On the other hand, this discussion was specifically about sitelinks. Here I believe what has driven the Wikidata side has been the desire to have a rule that is simple and consistent and predictable, because that is the foundation needed to develop queries and scripts and tools and user-interfaces on top of. Combining that desideratum with the technical restriction of only allowing one sitelink to each item from each wiki and vice-versa, is what has led to the recommended scheme of linking Commons categories <-> category-like items Commons galleries <-> article-like items with property P373 to handle identification of Commons categories <-> article-like items. This fulfils the requirements of simplicity, consistency and predictability. It's not ideal from a user-interface point of view (or a philosophical point of view). But so long as the rule is applied consistently, the limitations it leads to can be worked round with appropriate software improvements -- eg in the first instance the wdcat.js script. But to encourage people to develop and improve such software, it is helpful for the above structure to be applied consistently. In contrast perpetuating inconsistency and muddle blurs what is needed, and works against the stable predictable basis needed to make such software work. All best, James. On 29/08/2015 14:39, Steinsplitter Wiki wrote: > Wikidata needs to ask the Commons Community before doing commons related changes. > > It is so hard to understand what the wikidata people like to do with commons. Tons of text, hard to read. I don't understand what they like to do, but if this change is affecting commons then commons community consensus is needed. > > > Date: Fri, 28 Aug 2015 17:34:28 +0200 > From: romaine.wiki(a)gmail.com > To: wikidata(a)lists.wikimedia.org; commons-l(a)lists.wikimedia.org > Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons > > As I wrote before, that thought is too simple. You only say that a zero belongs to a zero, and a two belongs to a two, then you only describe the type of page, but you ignore the subject of a page. That subject matters much more than the namespace number. > > Especially Wikinews is a wrong example, as most categories on Commons do not have a 1 to 1 relationship with Commons. > However, articles on Wikipedia do have mostly a 1 on 1 relationship with categories on Commons. > > Romaine > > 2015-08-28 17:09 GMT+02:00 Luca Martinelli <martinelliluca(a)gmail.com>: > 2015-08-28 12:09 GMT+02:00 Romaine Wiki <romaine.wiki(a)gmail.com>: > >> And I agree completely with what Revi says: > >>> Wikidata ignores this Commons' fact by trying to enforce ridiculous rules > >>> like this. > > > > It's not such a ridiculous rule, if you think of the rationale behind > > it: if gallery = ns0 and category = ns2, linking ns0 <--> ns2 in the > > same item is IMHO not a rational thing to do (not even for Wikinews if > > you ask me, but I'm digressing). > > > > So the *practical* problem that we have to address is the list of > > links in the left column. We really don't have any possibilty to > > exploit P373 in any way, not even with a .js, to fix this? > > > > L. > > > > _______________________________________________ > > Wikidata mailing list > > Wikidata(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikidata > > > > > _______________________________________________ > Commons-l mailing list > Commons-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l > > > > _______________________________________________ > Commons-l mailing list > Commons-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/commons-l >

8 7

Why do these two SPARQL queries take such different times to run?
by James Heald 11 Sep '15

11 Sep '15

Prompted by this thread at Project Chat, https://www.wikidata.org/wiki/Wikidata:Project_chat#Identical_data_sets here's a query to find multiple humans with nationality:Greece that have the same day of birth and day of death: http://tinyurl.com/ow6lpen It produces one pair, and executes in about 0.6 seconds. Here's a query to try to add item numbers and labels to the previous search: http://tinyurl.com/ovjwzc9 It *just* completes, taking just over 60 seconds to execute. (Please don't merge the two items yet, because that will destroy the example). Analogous queries with lookups for France (71 apparent sets of duplicates), UK (32), and Italy(14) fail to complete. Two questions therefore: (1) Why are the two queries taking such different times to run ? (2) Is there a good way to rewrite the second to make it faster ? Obviously the second query as written at the moment involves a sub-query, which inevitably must make it a bit slower -- but given the solution set of the sub-query only has two rows, and an exact date for a given property ought to be a fairly quick key to look up, why is the second query taking 100 times longer than the first ? And is there a better way I should be doing this, since the query does appear to be producing useful real matches ? Thanks, James.

4 6

Wikidata needs your votes
by Lydia Pintscher 10 Sep '15

10 Sep '15

Hey folks, As you know Wikidata is one of the 100 winners of the "Germany - Land der Ideen" competition 2015. We now have the chance to win the Public’s Choice Award as well! At the moment, Wikidata is ranked 15th. We need to be among the first 10 to enter the next round and win the Public’s Choice Award. Voting is open until 23 August. The information about the competition and projects is available in English (https://www.land-der-ideen.de/en/projects-germany/landmarks-land-ideas/comp… and https://www.land-der-ideen.de/en/projects-germany/landmarks-land-ideas/2015…) but the voting process only in German. But it’s pretty easy to vote anyway: * Go to the Wikidata voting page at https://www.land-der-ideen.de/ausgezeichnete-orte/preistraeger/wikidata * Click the yellow button on the right ("Jetzt abstimmen"). * Type in your email address and tick the box to agree to the voting rules. * You will receive a link via email. Click the link within 24 hours. You can repeat this daily until 23 August. You have one vote every day. Let's win this! :D Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

11 22

more data for more sister projects coming right up
by Lydia Pintscher 09 Sep '15

09 Sep '15

Hey folks :) It is time to give some more sister projects access to the sitelink or data part of Wikidata. The schedule is as follows: * September 22nd: Wikibooks will get access to statements (aka Phase 2) * Oktober 20th: Meta, Mediawiki and Wikispecies will get access to the sitelinks (aka Phase 1) Please give them a warm welcome and watch https://www.wikidata.org/wiki/Wikidata:Wikibooks, https://www.wikidata.org/wiki/Wikidata:Meta-Wiki and https://www.wikidata.org/wiki/Wikidata:Wikispecies for questions. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

1 0

Wikidata Live RDF?
by Markus Krötzsch 09 Sep '15

09 Sep '15

Hi, Now that the SPARQL endpoint is "official", will the life RDF data (which you get, e.g, via Special:EntityData) also be switched to show the content using in SPARQL? Since this is already implemented, I guess this would be a minor switch. It could be very useful for users who want to learn about how to use SPARQL, since it can help a lot to see the data for one item to know what to query for. Cheers, Markus

3 4

Re: [Wikidata] [Dbpedia-discussion] Fwd: Announcing the release of the Wikidata Query Service
by Kingsley Idehen 09 Sep '15

09 Sep '15

On 9/8/15 11:26 AM, Markus Kroetzsch wrote: > > > On 08.09.2015 16:48, Kingsley Idehen wrote: >> On 9/8/15 8:56 AM, Markus Kroetzsch wrote: >>> The Wikimedia Foundation has just announced its official live query >>> service, based on SPARQL. You can do many things with this, since the >>> data is quite rich. Best start with some example queries, found at: >>> >>> https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples >>> >>> The data is based on the current content of Wikidata, so if you find >>> an error or omission, you can directly edit it (I think there might be >>> an update lag of about 1 min, depending on traffic). >> >> Markus, >> >> Great news! >> >> A quick question, in regards to the excerpt above: can I use SPARQL >> query URLs against this service? In addition, can I use SPARQL FED along >> the following lines from other SPARQL Query service providers [1]: >> >> select * where {service <https://query.wikidata.org/> {select * where >> {?s a ?o} limit 10 } } > > Yes, the UI we mostly advertise is not the plain SPARQL endpoint. What > you want is https://query.wikidata.org/bigdata/namespace/wdq/sparql/ > > Your queries are [1] (text [2]) then. > > Nonetheless, the recommended way to link to queries that users can > then view and edit is to refer to https://query.wikidata.org like the > examples do. Links to the plain endpoint query results (in various > formats) should be included there. I think this is a known issue that > will be fixed in due course. > > Markus > > [1] > http://linkeddata.uriburner.com/sparql?default-graph-uri=&query=select+*+wh… > > [2] > http://linkeddata.uriburner.com/sparql?default-graph-uri=&qtxt=select+*+whe… > Great! One more thing, if you click on [1] and then click on the HTTP URIs in the solution, none of them resolve (bar schema.org). Is this an oversight re., Linked Data deployment? Ideally, you want to have your SPARQL endpoint enable data exploration via HTTP URIs in the query solution, re., Linked Data. Examples: [1] http://id.nlm.nih.gov/mesh/query -- NIH Query Service [2] http://rdf.disgenet.org/sparql/ -- Disgenet Query Service [3] http://dbpedia.org/sparql -- DBpedia (which let's you explore via Class instances in the query solution). Kingsley >> >> [1] >> http://linkeddata.uriburner.com/sparql?default-graph-uri=&query=%0D%0Aselec… >> >> - Query >> >> [2] >> http://linkeddata.uriburner.com/sparql?default-graph-uri=&qtxt=%0D%0Aselect… >> >> -- Query Text in Editor >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> Dbpedia-discussion mailing list >> Dbpedia-discussion(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion >> > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

3 4

(Almost) empty items
by Markus Krötzsch 09 Sep '15

09 Sep '15

Hi all, My recent tests produced lists of empty or almost empty items, meaning that they have no sitelinks, no statements, no label (almost empty), and sometimes no descriptions or aliases either (empty). Many of the empty ones seem to be redirects now, but not all (e.g. Q18482644). Maybe somebody would like to check what is going on in each case. It seems like in most cases, a merge has emptied the item and a redirect should be placed now. Markus All data based on 31 Aug 2015 JSON dump. Empty: [Q4009003, Q10326820, Q11075784, Q11076861, Q13117977, Q13118077, Q17504622, Q9370571, Q9710731, Q11083936, Q11087561, Q13118625, Q16749989, Q18630019, Q20515598, Q6909817, Q10780450, Q11074508, Q11079165, Q11089726, Q13115994, Q13116978, Q13327246, Q19819704, Q19967348, Q5936922, Q9314766, Q12243231, Q12454977, Q13118107, Q13118374, Q16943273, Q18482644] Almost empty: [Q587248, Q1164798, Q3112633, Q4009003, Q4062117, Q4292083, Q4318132, Q5668795, Q6192003, Q6237634, Q6237652, Q6237655, Q6308010, Q6331429, Q6930680, Q6974238, Q7241365, Q7768807, Q7782293, Q7849393, Q8003207, Q8343296, Q8504111, Q8614159, Q8979826, Q8990731, Q9004011, Q9043398, Q9063876, Q9103025, Q9109206, Q9117920, Q9164306, Q9170348, Q9174405, Q9174424, Q9174555, Q9488312, Q9513173, Q9518437, Q9632533, Q9636117, Q9661338, Q9718033, Q9775961, Q9776559, Q9786262, Q9786601, Q9789144, Q9791363, Q9796753, Q9803673, Q9804276, Q9805622, Q9807208, Q9808694, Q9810197, Q9828378, Q9828528, Q9829439, Q9832003, Q9840979, Q9845828, Q9850795, Q9852621, Q9860579, Q9863446, Q9908743, Q9913015, Q9920520, Q9924412, Q9929068, Q9930757, Q9932368, Q9936017, Q9936060, Q9943410, Q9943530, Q9949358, Q9949788, Q9950572, Q9954180, Q9992311, Q10007569, Q10007635, Q10008745, Q10031183, Q10076666, Q10084373, Q10096437, Q10104020, Q10218343, Q10219749, Q10236783, Q10326820, Q10729998, Q11075784, Q11076861, Q11128812, Q11340931, Q11737059, Q12101945, Q12205093, Q12404189, Q12443121, Q12621871, Q12631965, Q13072852, Q13117977, Q13118077, Q13245750, Q13263997, Q13321100, Q13324365, Q13360518, Q14553821, Q14799878, Q15004946, Q15730551, Q16159846, Q16282742, Q16602153, Q16702173, Q16869872, Q17277701, Q17478425, Q17504622, Q17593537, Q18175021, Q18237112, Q18274457, Q18282299, Q18531535, Q18561899, Q18628032, Q18730938, Q18821128, Q18998044, Q19331912, Q19481981, Q19482131, Q19550459, Q19590380, Q19616299, Q19641075, Q19642002, Q19734545, Q19767134, Q19822949, Q19988106, Q20035189, Q20079998, Q20639714, Q20679947, Q20760080, Q20892816, Q2210323, Q3113056, Q3533562, Q4101879, Q4210087, Q5684730, Q5809971, Q6187338, Q6214071, Q6221847, Q6232454, Q6237623, Q6238407, Q6267133, Q6304334, Q6304340, Q6305887, Q6948925, Q6976279, Q7002200, Q7715677, Q7768811, Q7777227, Q7811966, Q8204528, Q8327914, Q8420039, Q8545168, Q9170600, Q9170895, Q9174261, Q9174398, Q9174402, Q9370571, Q9431627, Q9477845, Q9520148, Q9528273, Q9528284, Q9533963, Q9549703, Q9568787, Q9588409, Q9632151, Q9647812, Q9710731, Q9729602, Q9732941, Q9773192, Q9781543, Q9783257, Q9788337, Q9789469, Q9791424, Q9804106, Q9805916, Q9810115, Q9819720, Q9820281, Q9820461, Q9820835, Q9823355, Q9823407, Q9837555, Q9838783, Q9840499, Q9849199, Q9850679, Q9851940, Q9855390, Q9917449, Q9922940, Q9924272, Q9926256, Q9928042, Q9928254, Q9931521, Q9968727, Q9989440, Q10000259, Q10024392, Q10031160, Q10042639, Q10097916, Q10098140, Q10106067, Q10106068, Q10106347, Q10109679, Q10126604, Q10138517, Q10156971, Q10201244, Q10207296, Q10226384, Q10237094, Q11083936, Q11087561, Q11249136, Q11340216, Q11723301, Q12024692, Q12173627, Q12405002, Q12595491, Q13091247, Q13118625, Q13120053, Q13318236, Q13339703, Q13344714, Q13350354, Q15023800, Q15179680, Q15216251, Q15258494, Q15353671, Q15971392, Q16742302, Q16749989, Q17272669, Q17312641, Q17313103, Q17329406, Q17336067, Q17404038, Q17478412, Q18240140, Q18240752, Q18282081, Q18283071, Q18494403, Q18593433, Q18598473, Q18630019, Q18783455, Q19014615, Q19119068, Q19352325, Q19370628, Q19590712, Q19635746, Q19641080, Q19955305, Q20034343, Q20080001, Q20080814, Q20107489, Q20192449, Q20515598, Q20636623, Q20671182, Q20705601, Q20830805, Q20870799, Q1384584, Q1720927, Q2251351, Q3066778, Q4070991, Q4858090, Q6237616, Q6237619, Q6237676, Q6405134, Q6539112, Q6595216, Q6909817, Q6924240, Q7091930, Q7098258, Q8473098, Q8497107, Q8742956, Q8907476, Q8961567, Q9118475, Q9170334, Q9311504, Q9428083, Q9432965, Q9476291, Q9513989, Q9523286, Q9571617, Q9723093, Q9776024, Q9776350, Q9777657, Q9777739, Q9777974, Q9786515, Q9788293, Q9789416, Q9816934, Q9819231, Q9822928, Q9824643, Q9826885, Q9829206, Q9829711, Q9832139, Q9837547, Q9839179, Q9850745, Q9853057, Q9853575, Q9873126, Q9884441, Q9892430, Q9897034, Q9900422, Q9907796, Q9909494, Q9917083, Q9917432, Q9922959, Q9926577, Q9926648, Q9928091, Q9929582, Q9929656, Q9930201, Q9933652, Q9941606, Q9941679, Q9942423, Q9942460, Q9951122, Q9952159, Q9967447, Q9982655, Q9998938, Q10007908, Q10019264, Q10031280, Q10057516, Q10074237, Q10108312, Q10117216, Q10156882, Q10162525, Q10190884, Q10219171, Q10230032, Q10681226, Q10780450, Q11074508, Q11079165, Q11089726, Q12404349, Q12603119, Q12607658, Q13079203, Q13115994, Q13116978, Q13118015, Q13118726, Q13327246, Q13346198, Q13354313, Q13355317, Q14919665, Q15392017, Q15732738, Q15887261, Q16135451, Q16280337, Q16521958, Q16942523, Q17272719, Q17393971, Q17393976, Q17573242, Q18195798, Q18330554, Q18404440, Q18514101, Q18731648, Q18751120, Q18753526, Q18821437, Q19366242, Q19655229, Q19819704, Q19967348, Q20079513, Q20080003, Q20080004, Q20186907, Q20202278, Q20635844, Q20706633, Q20829306, Q20836027, Q20871823, Q897428, Q2762011, Q2819097, Q2911304, Q3556901, Q5936922, Q6192000, Q6518208, Q6593922, Q6925021, Q6958876, Q7002215, Q7021143, Q7111323, Q7839518, Q7861288, Q8379913, Q8638466, Q8735540, Q8815389, Q8915163, Q8965896, Q9048746, Q9070475, Q9094889, Q9170398, Q9229160, Q9314766, Q9528325, Q9541305, Q9561954, Q9695459, Q9711593, Q9730206, Q9750925, Q9776271, Q9781679, Q9781882, Q9783153, Q9797161, Q9801357, Q9802696, Q9803538, Q9804558, Q9805413, Q9809731, Q9810377, Q9826404, Q9832058, Q9839138, Q9840857, Q9841077, Q9844378, Q9848703, Q9852837, Q9853039, Q9871351, Q9874622, Q9877689, Q9902614, Q9902643, Q9906499, Q9927018, Q9930224, Q9943740, Q9950164, Q9950934, Q9970838, Q9991194, Q10007547, Q10015182, Q10052878, Q10087153, Q10106222, Q10106446, Q10117845, Q10120247, Q10157173, Q10180050, Q10214401, Q10222964, Q10234919, Q10249060, Q10251187, Q10258787, Q10814034, Q10816828, Q11001687, Q11047762, Q11291966, Q11819835, Q12114625, Q12149749, Q12173170, Q12185583, Q12243231, Q12277014, Q12454977, Q12593361, Q13118107, Q13118374, Q13121181, Q13320427, Q13331179, Q13349061, Q14375294, Q14668444, Q14995937, Q15340701, Q15887313, Q15994270, Q16943273, Q17393969, Q17404040, Q17423355, Q18019540, Q18219469, Q18404445, Q18482644, Q18551149, Q18551338, Q18717227, Q18818940, Q18998058, Q19370687, Q19481933, Q19591859, Q19734556, Q19847190, Q20022861, Q20185447, Q20187611, Q20655258, Q20658610, Q20705661, Q20763660, Q20858576]

7 7

Source statistics
by André Costa 08 Sep '15

08 Sep '15

Hi all! I'm wondering if there is a way (SQL, api, tool or otherwise) for finding out how often a particular source is used on Wikidata. The background is a collaboration with two GLAMs where we have used ther open (and CC0) datasets to add and/or source statements on Wikidata for items on which they can be considered an authority. Now I figured it would be nice to give them back a number for just how big the impact was. While I can find out how many items should be affected I couldn't find an easy way, short of analysing each of these, for how many statements were affected. Any suggestions would be welcome. Some details: Each reference is a P248 claim + P577 claim (where the latter may change) Cheers, André / Lokal_Profil André Costa | GLAM-tekniker, Wikimedia Sverige | Andre.Costa(a)wikimedia.se | +46 (0)733-964574 Stöd fri kunskap, bli medlem i Wikimedia Sverige. Läs mer på blimedlem.wikimedia.se

4 8

weekly summary #174
by Lydia Pintscher 07 Sep '15

07 Sep '15

Hey folks :) Here's what's been happening around Wikidata over the last week: Events <https://www.wikidata.org/wiki/Wikidata:Events>/Press/Blogs <https://www.wikidata.org/wiki/Wikidata:Press_coverage> - Wikimedia Grafana graphs of Wikidata profiling information <http://addshore.com/2015/09/wikimedia-grafana-graphs-of-wikidata-profiling-…> - Past: Wikimedia Science Conference (blog posts: Liberating Science Daily With, and To, Wikidata <http://contentmine.org/2015/09/liberating-science-daily-with-and-to-wikidat…>, Wikidata, Wikipedia, and #wikisci <http://iphylo.blogspot.co.uk/2015/09/wikidata-wikipedia-and-wikisci.html> ) - Past: Wikidata workshop in Rennes <https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Rencontres/Ouest#Atelier_:_d.C…> Other Noteworthy Stuff - New date for the next Arbitrary access rollout <https://www.wikidata.org/wiki/Wikidata:Arbitrary_access> has been set: 16th of September. - Support for units on Wikidata is coming on Wednesday (9th of September). - A new version of Kian <https://lists.wikimedia.org/pipermail/wikidata/2015-August/006967.html> has been released - The Wikidata Game <http://tools.wmflabs.org/wikidata-game/> has got a new mode: Books without author. - A new IEG proposal needs your review and support <https://meta.wikimedia.org/wiki/Grants:IEG/StrepHit:_Wikidata_Statements_Va…>. You can also submit your own until the 29th of September. - >8K Fellows of the Royal Society have been added to mix’n’match <https://tools.wmflabs.org/mix-n-match/?mode=catalog_details&catalog=92> - You can have a look at the spiffy new mobile view <https://m.wikidata.org/wiki/Q2> - Want to work with the data in Wikidata? There is a new release of the Wikidata Toolkit <https://lists.wikimedia.org/pipermail/wikidata/2015-September/006999.html> for you. - Your help is needed with the most important constraint violations <https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violatio…> . - A new noticeboard has been created to help with classification issues: d:Wikidata:Classification noticeboard <https://www.wikidata.org/wiki/Wikidata:Classification_noticeboard> Did you know? - Newest properties <https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violatio…>: Artsy artist <https://www.wikidata.org/wiki/Property:P2042>, National Gallery of Victoria artist identifier <https://www.wikidata.org/wiki/Property:P2041>, CITES Species+ ID <https://www.wikidata.org/wiki/Property:P2040> Development - Worked on search on the mobile site - Started working on automatically linking identifiers without a gadget and the new datatype for identifiers - We have a new Special page to query badges (finally!) After the next update it will be at Special:PagesWithBadges on Wikipedia and others - Fixed some of the remaining known issues with unit support to make it ready for rollout on Wednesday - Continued with making it possible to show meaningful edit summaries in the watchlist and recent changes on Wikipedia and others - Made change dispatching faster (This is what makes Wikipedia and others aware of changes happening on Wikidata) You can see all open tickets related to Wikidata here <https://phabricator.wikimedia.org/maniphest/query/4RotIcw5oINo/#R>. Monthly Tasks - Hack on one of these <https://phabricator.wikimedia.org/maniphest/query/R8GRzX1eH0tb/#R>. - Help develop the next summary here! <https://www.wikidata.org/wiki/Wikidata:Status_updates/Next> - Contribute to a Showcase item <https://www.wikidata.org/wiki/Wikidata:Showcase_items> - Help translate <https://www.wikidata.org/wiki/Special:LanguageStats> or proofread pages in your own language! - Add labels, in your own language(s), for the new properties listed above. Anything to add? Please share! :) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

1 0

Wikidata's 3 birthday is coming up
by Lydia Pintscher 07 Sep '15

07 Sep '15

Hey folks :) Wikidata's birthday is coming up in less than 2 months (29th of October). We're currently brainstorming some cool ideas for presents. Last year we had a few very cool ones from different corners of our community: https://www.wikidata.org/wiki/Wikidata:Second_Birthday So if you're interested in preparing a present of some sort for Wikidata's 3rd birthday this is your advance warning so you have enough time to prepare ;-) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Wikidata September 2015