Hello, Thanks. Few questions: - Have you found the problem or is the procedure you ask me to follow is what you prefer doing when an issue MAY be related to a corrupted environment? - If you think the True Image environment got corrupted, what is the root source for it? What will prevent it from happening again? - As of now, 6 incremental backups have been done after the last full backup (the unexpected full backup underlying this ticket). My scheme is set to do 6 incremental backups before a full backup, so the next backup should be a full one. Assuming it will indeed be a full backup, do you still want me to follow the cleaning procedure?
Regards, Haim -----Original Message----- From: Wikidata [mailto:wikidata-boun...@lists.wikimedia.org] On Behalf Of wikidata-requ...@lists.wikimedia.org Sent: Saturday, July 28, 2018 3:00 PM To: wikidata@lists.wikimedia.org Subject: Wikidata Digest, Vol 80, Issue 24 Send Wikidata mailing list submissions to wikidata@lists.wikimedia.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikidata or, via email, send a message with subject or body 'help' to wikidata-requ...@lists.wikimedia.org You can reach the person managing the list at wikidata-ow...@lists.wikimedia.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Wikidata digest..." Today's Topics: 1. Re: NCI Thesaurus ID links not working (Thad Guidry) 2. Re: Indexing all item properties in ElasticSearch (sushil dutt) 3. Re: [discovery-private] Indexing all item properties in ElasticSearch (David Causse) 4. Re: [discovery-private] Indexing all item properties in ElasticSearch (David Causse) 5. Re: Indexing all item properties in ElasticSearch (Sylvain Boissel) 6. Re: Indexing all item properties in ElasticSearch (Stas Malyshev) 7. Re: [discovery-private] Indexing all item properties in ElasticSearch (Stas Malyshev) 8. Re: Indexing all item properties in ElasticSearch (James Heald) 9. Re: [discovery-private] Indexing all item properties in ElasticSearch (Stas Malyshev) 10. Re: Indexing all item properties in ElasticSearch (Stas Malyshev) 11. Re: Indexing all item properties in ElasticSearch (Stas Malyshev) 12. Re: [discovery-private] Indexing all item properties in ElasticSearch (David Causse) 13. Re: Wikidata in the LOD Cloud (Ettore RIZZA) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Jul 2018 07:08:26 -0500 From: Thad Guidry <thadgui...@gmail.com> To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.org> Subject: Re: [Wikidata] NCI Thesaurus ID links not working Message-ID: <CAChbWaMBNs7RmpCXWCXanupRNHnAZe2OmNBpmc3W+z9=sc7...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" No other issues, Lydia. Thanks for the answer. How or where to give my vote for consensus of that ? -Thad On Thu, Jul 26, 2018, 7:38 AM Lydia Pintscher <lydia.pintsc...@wikimedia.de> wrote: > Hey Thad, > > Sorry it took me a bit to reply because of Wikimania. > https://www.wikidata.org/wiki/Q1931388 does have a link for the NCI > Thesaurus ID for me. The reason for it not being in the external > identifier section is that it has datatype string and not external > identifier like the others in the external identifier section. It can > be converted if there is rough consensus to do so. > Are there still other issues that I didn't answer? > > > Cheers > Lydia > > -- Thad +ThadGuidry <https://plus.google.com/+ThadGuidry> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.wikimedia.org/pipermail/wikidata/attachments/20180727/2cb55c61/attachment-0001.html> ------------------------------ Message: 2 Date: Fri, 27 Jul 2018 18:16:16 +0530 From: sushil dutt <sushil.killst...@gmail.com> To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.org> Subject: Re: [Wikidata] Indexing all item properties in ElasticSearch Message-ID: <cahtqeep7am9tsnx9qgmcve5onq+mx5z7+rbummx-rwmtsry...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Please, any one let me know about Wikidata project because I dont know about this. On Fri, Jul 27, 2018 at 5:29 PM, James Heald <jpm.he...@gmail.com> wrote: > +1 with Magnus on years of birth and death > (but perhaps /only/ years of birth and death, or close surrogates eg years > of baptism and burial, and inception or publication date for things, > otherwise the search specificity would become useless with too many other > 'significant event' dates) > > I have found in the last few weeks I have been using the External ID value > search a lot, from its search-box on the talk page of the main page for a > property. > > I'm finding this works very well, so I wonder whether people think that > the ability to search for one of these strings directly in the general > search box would actually add anything, or is the custom search eg via the > talk-page search box already enough? > > -- James. > > > > On 27/07/2018 12:49, Magnus Manske wrote: > >> Hi, and thanks for working on this! >> >> My subjective view: >> * We don't need P2860/P1433 indexed, at least not at the moment >> * I would really like dates (mainly, born/died), especially if they work >> for "greater units", that is, I search for a year and get an item back, >> even though the statament is month- or day-precise >> >> Cheers, >> Magnus >> >> On Thu, Jul 26, 2018 at 10:48 PM Stas Malyshev <smalys...@wikimedia.org> >> wrote: >> >> Hi! >>> >>> Today we are indexing in ElasticSearch almost all string properties >>> (except a few) and select item properties (P31 and P279). We've been >>> asked to extend this set and index more item properties >>> (https://phabricator.wikimedia.org/T199884). We did not do it from the >>> start because we did not want to add too much data to the index at once, >>> and wanted to see how the index behaves. To evaluate what this change >>> would mean, some statistics: >>> >>> All usage of item properties in statements is about 231 million uses >>> (according to sqid tool database). Of those, about 50M uses are >>> "instance of" which we are already indexing. Another 98M uses belong to >>> two properties - published in (P1433) and cites (P2860). Leaving about >>> 86M for the rest of the properties. >>> >>> So, if we index all the item properties except P2860 and P1433, we'll be >>> a little more than doubling the amount of data we're storing for this >>> field, which seems OK. But if we index those too, we'll be essentially >>> quadrupling it - which may be OK too, but is bigger jump and one that >>> may potentially cause some issues. >>> >>> So, we have two questions: >>> 1. Do we want to enable indexing for all item properties? Note that if >>> you just want to find items with certain statement values, Wikidata >>> Query Service matches this use case best. It's only in combination with >>> actual fulltext search where on-wiki search is better. >>> >>> 2. Do we need to index P2860 and P1433 at all, and if so, would it be ok >>> if we omit indexing for now? >>> >>> Would be glad to hear thoughts on the matter. >>> >>> Thanks, >>> -- >>> Stas Malyshev >>> smalys...@wikimedia.org >>> >>> _______________________________________________ >>> Wikidata mailing list >>> Wikidata@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>> >>> >> >> >> _______________________________________________ >> Wikidata mailing list >> Wikidata@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> >> > > --- > This email has been checked for viruses by AVG. > https://www.avg.com > > > > _______________________________________________ > Wikidata mailing list > Wikidata@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata > -- Regards, Sushil Dutt 8800911840 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.wikimedia.org/pipermail/wikidata/attachments/20180727/da8be2c3/attachment-0001.html> ------------------------------ Message: 3 Date: Fri, 27 Jul 2018 15:31:55 +0200 From: David Causse <dcau...@wikimedia.org> To: Internal communications for WMF search and discovery team <discovery-priv...@lists.wikimedia.org> Cc: wikidata@lists.wikimedia.org Subject: Re: [Wikidata] [discovery-private] Indexing all item properties in ElasticSearch Message-ID: <cajkbcoxqx-sbn2u0knhbxytkhc46fxxjzwopfbxv_jetbv0...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, I think we already index way more than P31 and P279. For instance we have 102.301.706 (approximation) distinct values in the term lexicon for statement_keywords. Sadly I can't extract the list of unique PIDs used (we'd have to enable field_data on statement_keywords.property). The top 1000 is: https://docs.google.com/spreadsheets/d/1E58W_t_o6vTNUAx_TG3ifW6-eZE4KJ2VGEaBX_74YkY/edit?usp=sharing I think this is because we not only index statements by PID but also by data type. So I think that the increase is smaller than what you anticipate. What I'd try to avoid in general is indexing terms that have only doc since they are pretty useless. I think we should investigate what kind of data we may have here, and at least for statement_keywords I would not index data that contain random text (esp. natural language) since they are prone to be unique and impossible to search. On Thu, Jul 26, 2018 at 11:48 PM Stas Malyshev <smalys...@wikimedia.org> wrote: > Hi! > > Today we are indexing in ElasticSearch almost all string properties > (except a few) and select item properties (P31 and P279). We've been > asked to extend this set and index more item properties > (https://phabricator.wikimedia.org/T199884). We did not do it from the > start because we did not want to add too much data to the index at once, > and wanted to see how the index behaves. To evaluate what this change > would mean, some statistics: > > All usage of item properties in statements is about 231 million uses > (according to sqid tool database). Of those, about 50M uses are > "instance of" which we are already indexing. Another 98M uses belong to > two properties - published in (P1433) and cites (P2860). Leaving about > 86M for the rest of the properties. > > So, if we index all the item properties except P2860 and P1433, we'll be > a little more than doubling the amount of data we're storing for this > field, which seems OK. But if we index those too, we'll be essentially > quadrupling it - which may be OK too, but is bigger jump and one that > may potentially cause some issues. > > So, we have two questions: > 1. Do we want to enable indexing for all item properties? Note that if > you just want to find items with certain statement values, Wikidata > Query Service matches this use case best. It's only in combination with > actual fulltext search where on-wiki search is better. > > 2. Do we need to index P2860 and P1433 at all, and if so, would it be ok > if we omit indexing for now? > > Would be glad to hear thoughts on the matter. > > Thanks, > -- > Stas Malyshev > smalys...@wikimedia.org > > _______________________________________________ > discovery-private mailing list > discovery-priv...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/discovery-private > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.wikimedia.org/pipermail/wikidata/attachments/20180727/c4a56abb/attachment-0001.html> ------------------------------ Message: 4 Date: Fri, 27 Jul 2018 15:44:12 +0200 From: David Causse <dcau...@wikimedia.org> To: Internal communications for WMF search and discovery team <discovery-priv...@lists.wikimedia.org> Cc: wikidata@lists.wikimedia.org Subject: Re: [Wikidata] [discovery-private] Indexing all item properties in ElasticSearch Message-ID: <CAJKbcoVjtyfNBLEN9VzEumB74=z23rmqzejybjcv4_lhzwd...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Fri, Jul 27, 2018 at 3:31 PM David Causse <dcau...@wikimedia.org> wrote: > What I'd try to avoid in general is indexing terms that have only doc > since they are pretty useless. > I meant: that have only *one* doc -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.wikimedia.org/pipermail/wikidata/attachments/20180727/204c93c9/attachment-0001.html> ------------------------------ Message: 5 Date: Fri, 27 Jul 2018 15:15:04 +0200 From: Sylvain Boissel <sylv...@ashtree.eu> To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.org> Subject: Re: [Wikidata] Indexing all item properties in ElasticSearch Message-ID: <capvch_v93p-ut1r-vjofb5zf2z_kzkj0zyafd9tg4ayhb26...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Le ven. 27 juil. 2018 à 14:00, James Heald <jpm.he...@gmail.com> a écrit : > +1 with Magnus on years of birth and death > (but perhaps /only/ years of birth and death, or close surrogates eg > years of baptism and burial, and inception or publication date for > things, otherwise the search specificity would become useless with too > many other 'significant event' dates) > Maybe just dates as declarations on the item? On 'significant event', dates are qualifiers. Ash. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.wikimedia.org/pipermail/wikidata/attachments/20180727/62adbaee/attachment-0001.html> ------------------------------ Message: 6 Date: Fri, 27 Jul 2018 10:34:56 -0700 From: Stas Malyshev <smalys...@wikimedia.org> To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.org>, Magnus Manske <magnusman...@googlemail.com> Cc: Internal communications for WMF search and discovery team <discovery-priv...@lists.wikimedia.org> Subject: Re: [Wikidata] Indexing all item properties in ElasticSearch Message-ID: <fcfe752d-799d-8830-390d-8ad35507f...@wikimedia.org> Content-Type: text/plain; charset=utf-8 Hi! > * I would really like dates (mainly, born/died), especially if they work > for "greater units", that is, I search for a year and get an item back, > even though the statament is month- or day-precise What would be the use case for this? -- Stas Malyshev smalys...@wikimedia.org ------------------------------ Message: 7 Date: Fri, 27 Jul 2018 10:37:51 -0700 From: Stas Malyshev <smalys...@wikimedia.org> To: Internal communications for WMF Discovery Department <discovery-priv...@lists.wikimedia.org>, David Causse <dcau...@wikimedia.org> Cc: wikidata@lists.wikimedia.org Subject: Re: [Wikidata] [discovery-private] Indexing all item properties in ElasticSearch Message-ID: <69c0dd9f-4dd8-c8a3-6873-71f183d9f...@wikimedia.org> Content-Type: text/plain; charset=utf-8 Hi! > I think we already index way more than P31 and P279. Oh yes, all the string properties. > So I think that the increase is smaller than what you anticipate. > What I'd try to avoid in general is indexing terms that have only doc > since they are pretty useless. For unique string properties, that would be a frequent occurrence. But I am not sure why it's useless - won't it be a legit use case to look up something by external ID? > I think we should investigate what kind of data we may have here, and at > least for statement_keywords I would not index data that contain random > text (esp. natural language) since they are prone to be unique and > impossible to search. Yes, we definitely should not do that. I tried to exclude such properties but if you notice more of them, let's add them to exclusion config. -- Stas Malyshev smalys...@wikimedia.org ------------------------------ Message: 8 Date: Fri, 27 Jul 2018 23:33:05 +0100 From: James Heald <jpm.he...@gmail.com> To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.org>, Stas Malyshev <smalys...@wikimedia.org>, Magnus Manske <magnusman...@googlemail.com> Cc: Internal communications for WMF search and discovery team <discovery-priv...@lists.wikimedia.org> Subject: Re: [Wikidata] Indexing all item properties in ElasticSearch Message-ID: <fcbf833d-9bf5-fce7-fa47-d275a0c0b...@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed On 27/07/2018 18:34, Stas Malyshev wrote: > Hi! > >> * I would really like dates (mainly, born/died), especially if they work >> for "greater units", that is, I search for a year and get an item back, >> even though the statament is month- or day-precise > > What would be the use case for this? > The use case is to be able to look up "John Smith 1820 1897" and have some hope of finding the one you want... --- This email has been checked for viruses by AVG. https://www.avg.com ------------------------------ Message: 9 Date: Fri, 27 Jul 2018 17:02:28 -0700 From: Stas Malyshev <smalys...@wikimedia.org> To: Internal communications for WMF Discovery Department <discovery-priv...@lists.wikimedia.org>, David Causse <dcau...@wikimedia.org> Cc: wikidata@lists.wikimedia.org Subject: Re: [Wikidata] [discovery-private] Indexing all item properties in ElasticSearch Message-ID: <451cfbb7-9a71-7ef8-cdda-70c83f71b...@wikimedia.org> Content-Type: text/plain; charset=utf-8 Hi! > The top 1000 > is: > https://docs.google.com/spreadsheets/d/1E58W_t_o6vTNUAx_TG3ifW6-eZE4KJ2VGEaBX_74YkY/edit?usp=sharing This one is pretty interesting, how do I extract this data? It may be useful independently of what we're discussing here. -- Stas Malyshev smalys...@wikimedia.org ------------------------------ Message: 10 Date: Fri, 27 Jul 2018 17:12:10 -0700 From: Stas Malyshev <smalys...@wikimedia.org> To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.org>, "Hay (Husky)" <hus...@gmail.com> Subject: Re: [Wikidata] Indexing all item properties in ElasticSearch Message-ID: <793c305c-3b57-ef45-4b19-961566d4e...@wikimedia.org> Content-Type: text/plain; charset=utf-8 Hi! > I could definitely see a usecase for 1) and maybe for 2). For example, > let's say i remember that one movie that Rutger Hauer played in, just > searching for 'movie rutger hauer' gives back nothing: > > https://www.wikidata.org/w/index.php?search=movie+rutger+hauer > > While Wikipedia gives back quite a nice list of options: > > https://en.wikipedia.org/w/index.php?search=movie+rutger+hauer Well, this is not going to change with the work we're discussing. The reason you don't get anything from Wikidata is because "movie" and "rutger hauer" are labels from different documents and ElasticSearch does not do joins. We only index each document in itself, and possibly some additional data, but indexing labels from other documents is now beyond what we're doing. We could certainly discuss it but that would be separate (and much bigger) discussion. > If we would index item properties as well, you could get back Blade > Runner (Q184843) which has Rutger Hauer as one of its 'cast member' > values. You could, but not by asking something like "movie rutger hauer", at least not without a lot of additional work. Indexing "cast member" would get you a step closer, but only a tiny step and there are a number of other steps to take before that can work. -- Stas Malyshev smalys...@wikimedia.org ------------------------------ Message: 11 Date: Fri, 27 Jul 2018 17:16:47 -0700 From: Stas Malyshev <smalys...@wikimedia.org> To: Discussion list for the Wikidata project <wikidata@lists.wikimedia.org>, Magnus Manske <magnusman...@googlemail.com> Cc: Internal communications for WMF search and discovery team <discovery-priv...@lists.wikimedia.org> Subject: Re: [Wikidata] Indexing all item properties in ElasticSearch Message-ID: <07ea18a4-4edc-a6c5-8b3a-2799ea107...@wikimedia.org> Content-Type: text/plain; charset=utf-8 Hi! > * I would really like dates (mainly, born/died), especially if they work > for "greater units", that is, I search for a year and get an item back, > even though the statament is month- or day-precise This is something I've been thinking about for a while, mainly because the way we index dates now does not serve some important use cases. Even in the Query Service we treat dates as fixed instants on the time scale, whereas some dates are not instants but intervals (which in captured in wikidata Precision but we are currently not paying any attention to it), in fact many of the dates we use are more of interval-y nature than instant-y. This makes searching for "somebody that was born in 1820" possible but laborious (you need to do intervals manually) and inefficient since we can't just look up by year. There are certainly improvement possible in this area, not yet sure how to do it though. -- Stas Malyshev smalys...@wikimedia.org ------------------------------ Message: 12 Date: Sat, 28 Jul 2018 12:42:52 +0200 From: David Causse <dcau...@wikimedia.org> To: Stas Malyshev <smalys...@wikimedia.org> Cc: Internal communications for WMF search and discovery team <discovery-priv...@lists.wikimedia.org>, wikidata@lists.wikimedia.org Subject: Re: [Wikidata] [discovery-private] Indexing all item properties in ElasticSearch Message-ID: <cajkbcougdcb5dvksigqkn49sbf8rr3b+4_b7uzgts0bhejf...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Sat, Jul 28, 2018 at 2:02 AM Stas Malyshev <smalys...@wikimedia.org> wrote: > Hi! > > > The top 1000 > > is: > https://docs.google.com/spreadsheets/d/1E58W_t_o6vTNUAx_TG3ifW6-eZE4KJ2VGEaBX_74YkY/edit?usp=sharing > > This one is pretty interesting, how do I extract this data? It may be > useful independently of what we're discussing here. > This can be extracted from elastic using aggregations, to obtain a top1000 of the terms that do match P21= or P279 you can run this: curl -XPOST 'localhost:9200/wikidatawiki_content/_search?size=0&pretty' -d '{"aggs": {"item_usage": { "terms": { "field": "statement_keywords", "exclude": "P(31|279)=.*", "size": 1000 }}}}' > top1k.json To obtain an approximation of the cardinality (unique terms) of a field: curl -XPOST localhost:9200/wikidatawiki_content/_search?size=0 -d '{"aggs": {"item_usage": { "cardinality": { "field": "statement_keywords" }}}}' Note that I used the spare cluster to run these. As for Property usage I just realized that we the outgoing_link which contains a array like: outgoing_link": ["Q1355298","Q1379672","Q15241312","Q8844594","Property:P18" ,"Property:P1889","Property:P248","Property:P2612","Property:P279"," Property:P3221","Property:P3417","Property:P373","Property:P3827"," Property:P577","Property:P646","Property:P910"], We don't have doc values enabled for this one so we can't extract aggregations but if the list of terms is known it could be easily extracted by running X count queries where X is the number of possible possible properties. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.wikimedia.org/pipermail/wikidata/attachments/20180728/9284cd0f/attachment-0001.html> ------------------------------ Message: 13 Date: Sat, 28 Jul 2018 13:13:29 +0200 From: Ettore RIZZA <ettoreri...@gmail.com> To: "Discussion list for the Wikidata project." <wikidata@lists.wikimedia.org> Subject: Re: [Wikidata] Wikidata in the LOD Cloud Message-ID: <CAGq-doprdkAD0ww4XOdP3YG=oacpdr3bod-vu-t3zqcsfn+...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Dear all, stop me if my question is naive or stupid. But I see that a dataset like Europeana is both in the Lod Cloud and as a property in Wikidata <https://www.wikidata.org/wiki/Property:P727>. However, the method using the "Formatter URL for RDF resource" property does not work because this property is missing from Europeana ID. How many other cases like this? But I see in this simplified version of the Lod Cloud <https://jqplay.org/s/bgiJvPKryC> that each dataset has a namespace. Would not it be more efficient to match Wikidata and Lod Cloud using this namespaces in a series of Sparql queries <http://tinyurl.com/y8taazzm>? Cheers, Ettore On Mon, 9 Jul 2018 at 14:07, Lucas Werkmeister <m...@lucaswerkmeister.de> wrote: > On 27.06.2018 22:40, Federico Leva (Nemo) wrote: > > Maarten Dammers, 27/06/2018 23:26: > >> Excellent news! https://lod-cloud.net/dataset/wikidata seems to > >> contain the info in a more human readable (and machine readable) way. > >> If we add some URI link, does it automagically appear or does Lucas > >> has to do some manual work? I assume Lucas has to do some manual work. > > > > I'd also be curious what to do when a property does not have a node in > > the LOD cloud, for instance P2948 is among the 77 results for P1921 > > but I don't see any corresponding URL in > > http://lod-cloud.net/versions/2018-30-05/lod-data.json > > Previously it was manual work, yes, and for properties not in the LOD > cloud I added commented-out entries to the page source of > https://www.wikidata.org/wiki/User:Lucas_Werkmeister_(WMDE)/LOD_Cloud. > I’ll try to resubmit Wikidata now and see how the submission process has > evolved. > > Cheers, Lucas > > _______________________________________________ > Wikidata mailing list > Wikidata@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.wikimedia.org/pipermail/wikidata/attachments/20180728/2d629031/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata ------------------------------ End of Wikidata Digest, Vol 80, Issue 24 **************************************** _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
