Yes! +1 On Mon, Sep 28, 2015 at 11:27 PM, Denny Vrandečić <vrande...@gmail.com> wrote:
> Actually, my suggestion would be to switch on Primary Sources as a default > tool for everyone. That should increase exposure and turnover, without > compromising quality of data. > > > > On Mon, Sep 28, 2015 at 2:23 PM Denny Vrandečić <vrande...@google.com> > wrote: > >> Hi Gerard, >> >> given the statistics you cite from >> >> https://tools.wmflabs.org/wikidata-primary-sources/status.html >> >> I see that 19.6k statements have been approved through the tool, and 5.1k >> statements have been rejected - which means that about 1 in 5 statements is >> deemed unsuitable by the users of primary sources. >> >> Given that there are 12.4M statements in the tool, this means that about >> 2.5M statements will turn out to be unsuitable for inclusion in Wikidata >> (if the current ratio holds). Are you suggesting to upload all of these >> statements to Wikidata? >> >> Tpt already did upload pieces of the data which have sufficient quality >> outside the primary sources tool, and more is planned. But for the data >> where the suitability for Wikidata seems questionable, I would not know >> what other approach to use. Do you have a suggestion? >> >> Once you have a suggestion and there is community consensus in doing it, >> no one will stand in the way of implementing that suggestion. >> >> Cheers, >> Denny >> >> >> On Mon, Sep 28, 2015 at 1:19 PM John Erling Blad <jeb...@gmail.com> >> wrote: >> >>> Another; make a kind of worklist on Wikidata that reflect the watchlist >>> on the clients (Wikipedias) but then, we often have items on our watchlist >>> that we don't know much about. (Digression: Somehow we should be able to >>> sort out those things we know (the place we live, the persons we have meet) >>> from those things we have done (edited, copy-pasted).) >>> >>> I been trying to get some interest in the past for worklists on >>> Wikipedia, it isn't much interest to make them. It would speed up tedious >>> tasks of finding the next page to edit after a given edit is completed. It >>> is the same problem with imports from Freebase on Wikidata, locate the next >>> item on Wikidata with the same queued statement from Freebase, but within >>> some worklist that the user has some knowledge about. >>> >>> Imagine "municipalities within a county" or "municipalities that is also >>> on the users watchlist", and combine that with available unhandled >>> Freebase-statements. >>> >>> On Mon, Sep 28, 2015 at 10:09 PM, John Erling Blad <jeb...@gmail.com> >>> wrote: >>> >>>> Could it be possible to create some kind of info (notification?) in a >>>> wikipedia article that additional data is available in a queue ("freebase") >>>> somewhere? >>>> >>>> If you have the article on your watch-list, then you will get a warning >>>> that says "You lazy boy, get your ass over here and help us out!" Or >>>> perhaps slightly rephrased. >>>> >>>> On Mon, Sep 28, 2015 at 4:52 PM, Markus Krötzsch < >>>> mar...@semantic-mediawiki.org> wrote: >>>> >>>>> Hi Gerard, hi all, >>>>> >>>>> The key misunderstanding here is that the main issue with the Freebase >>>>> import would be data quality. It is actually community support. The goal >>>>> of >>>>> the current slow import process is for the Wikidata community to "adopt" >>>>> the Freebase data. It's not about "storing" the data somewhere, but about >>>>> finding a way to maintain it in the future. >>>>> >>>>> The import statistics show that Wikidata does not currently have >>>>> enough community power for a quick import. This is regrettable, but not >>>>> something that we can fix by dumping in more data that will then be >>>>> orphaned. >>>>> >>>>> Freebase people: this is not a small amount of data for our young >>>>> community. We really need your help to digest this huge amount of data! I >>>>> am absolutely convinced from the emails I saw here that none of the former >>>>> Freebase editors on this list would support low quality standards. They >>>>> have fought hard to fix errors and avoid issues coming into their data for >>>>> a long time. >>>>> >>>>> Nobody believes that either Freebase or Wikidata can ever be free of >>>>> errors, and this is really not the point of this discussion at all [1]. >>>>> The >>>>> experienced community managers among us know that it is not about the >>>>> amount of data you have. Data is cheap and easy to get, even free data >>>>> with >>>>> very high quality. But the value proposition of Wikidata is not that it >>>>> can >>>>> provide storage space for lot of data -- it is that we have a functioning >>>>> community that can maintain it. For the Freebase data donation, we do not >>>>> seem to have this community yet. We need to find a way to engage people to >>>>> do this. Ideas are welcome. >>>>> >>>>> What I can see from the statistics, however, is that some users (and I >>>>> cannot say if they are "Freebase users" or "Wikidata users" ;-) are >>>>> putting >>>>> a lot of effort into integrating the data already. This is great, and we >>>>> should thank these people because they are the ones who are now working on >>>>> what we are just talking about here. In addition, we should think about >>>>> ways of engaging more community in this. Some ideas: >>>>> >>>>> (1) Find a way to clean and import some statements using bots. Maybe >>>>> there are cases where Freebase already had a working import infrastructure >>>>> that could be migrated to Wikidata? This would also solve the community >>>>> support problem in one way. We just need to import the maintenance >>>>> infrastructure together with the data. >>>>> >>>>> (2) Find a way to expose specific suggestions to more people. The >>>>> Wikidata Games have attracted so many contributions. Could some of the >>>>> Freebase data be solved in this way, with a dedicated UI? >>>>> >>>>> (3) Organise Freebase edit-a-thons where people come together to work >>>>> through a bunch of suggested statements. >>>>> >>>>> (4) Form wiki projects that discuss a particular topic domain in >>>>> Freebase and how it could be imported faster using (1)-(3) or any other >>>>> idea. >>>>> >>>>> (5) Connect to existing Wiki projects to make them aware of valuable >>>>> data they might take from Freebase. >>>>> >>>>> Freebase is a much better resource than many other data resources we >>>>> are already using with similar approaches as (1)-(5) above, and yet it >>>>> seems many people are waiting for Google alone to come up with a solution. >>>>> >>>>> Cheers, >>>>> >>>>> Markus >>>>> >>>>> [1] Gerard, if you think otherwise, please let us know which error >>>>> rates you think are typical or acceptable for Freebase and Wikidata, >>>>> respectively. Without giving actual numbers you just produce empty >>>>> strawman >>>>> arguments (for example: claiming that anyone would think that Wikidata is >>>>> better quality than Freebase and then refuting this point, which nobody is >>>>> trying to make). See https://en.wikipedia.org/wiki/Straw_man >>>>> >>>>> >>>>> On 26.09.2015 18:31, Gerard Meijssen wrote: >>>>> >>>>>> Hoi, >>>>>> When you analyse the statistics, it shows how bad the current state of >>>>>> affairs is. Slightly over one in a thousanths of the content of the >>>>>> primary sources tool has been included. >>>>>> >>>>>> Markus, Lydia and myself agree that the content of Freebase may be >>>>>> improved. Where we differ is that the same can be said for Wikidata. >>>>>> It >>>>>> is not much better and by including the data from Freebase we have a >>>>>> much improved coverage of facts. The same can be said for the content >>>>>> of >>>>>> DBpedia probably other sources as well. >>>>>> >>>>>> I seriously hate this procrastination and the denial of the efforts of >>>>>> others. It is one type of discrimination that is utterly deplorable. >>>>>> >>>>>> We should concentrate on comparing Wikidata with other sources that >>>>>> are >>>>>> maintained. We should do this repeatedly and concentrate on workflows >>>>>> that seek the differences and provide workflows that help our >>>>>> community >>>>>> to improve what we have. What we have is the sum of all available >>>>>> knowledge and by splitting it up, we are weakened as a result. >>>>>> Thanks, >>>>>> GerardM >>>>>> >>>>>> On 26 September 2015 at 03:32, Thad Guidry <thadgui...@gmail.com >>>>>> <mailto:thadgui...@gmail.com>> wrote: >>>>>> >>>>>> Also, Freebase users themselves who did daily, weekly work.... >>>>>> some >>>>>> where passing users, some tried harder, but made lots of erroneous >>>>>> entries (battling against our Experts at times). We could >>>>>> probably >>>>>> provide a list of those sorta community blacklisted users who's >>>>>> data >>>>>> submissions should probably not be trusted. >>>>>> >>>>>> +1 for looking at better maintained specific properties. >>>>>> +1 for being cautious for some Freebase usernames and their >>>>>> entries. >>>>>> +1 for trusting wholesale all of the Freebase Experts submissions. >>>>>> We policed each other quite well. >>>>>> >>>>>> >>>>>> >>>>>> Thad >>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry> >>>>>> >>>>>> On Fri, Sep 25, 2015 at 11:45 AM, Jason Douglas >>>>>> <jasondoug...@google.com <mailto:jasondoug...@google.com>> wrote: >>>>>> >>>>>> > It would indeed be interesting to see which percentage of >>>>>> proposals are >>>>>> > being approved (and stay in Wikidata after a while), and >>>>>> whether there >>>>>> > is a pattern (100% approval on some type of fact that could >>>>>> then be >>>>>> > merged more quickly; or very low approval on something else >>>>>> that would >>>>>> > maybe better revisited for mapping errors or other >>>>>> systematic problems). >>>>>> >>>>>> +1, I think that's your best bet. Specific properties were >>>>>> much >>>>>> better maintained than others -- identify those that meet the >>>>>> bar for wholesale import and leave the rest to the primary >>>>>> sources tool. >>>>>> >>>>>> On Thu, Sep 24, 2015 at 4:03 PM Markus Krötzsch >>>>>> <mar...@semantic-mediawiki.org >>>>>> <mailto:mar...@semantic-mediawiki.org>> wrote: >>>>>> >>>>>> On 24.09.2015 23:48, James Heald wrote: >>>>>> > Has anybody actually done an assessment on Freebase and >>>>>> its reliability? >>>>>> > >>>>>> > Is it *really* too unreliable to import wholesale? >>>>>> >>>>>> From experience with the Primary Sources tool proposals, >>>>>> the quality is >>>>>> mixed. Some things it proposes are really very valuable, >>>>>> but >>>>>> other >>>>>> things are also just wrong. I added a few very useful >>>>>> facts >>>>>> and fitting >>>>>> references based on the suggestions, but I also rejected >>>>>> others. Not >>>>>> sure what the success rate is for the cases I looked at, >>>>>> but >>>>>> my feeling >>>>>> is that some kind of "supervised import" approach is >>>>>> really >>>>>> needed when >>>>>> considering the total amount of facts. >>>>>> >>>>>> An issue is that it is often fairly hard to tell if a >>>>>> suggestion is true >>>>>> or not (mainly in cases where no references are suggested >>>>>> to >>>>>> check). In >>>>>> other cases, I am just not sure if a fact is correct for >>>>>> the >>>>>> property >>>>>> used. For example, I recently ended up accepting >>>>>> "architect: >>>>>> Charles >>>>>> Husband" for Lovell Telescope (Q555130), but to be honest >>>>>> I >>>>>> am not sure >>>>>> that this is correct: he was the leading engineer >>>>>> contracted >>>>>> to design >>>>>> the telescope, which seems different from an architect; no >>>>>> official web >>>>>> site uses the word "architect" it seems; I could not find >>>>>> a >>>>>> better >>>>>> property though, and it seemed "good enough" to accept it >>>>>> (as opposed to >>>>>> the post code of the location of this structure, which >>>>>> apparently was >>>>>> just wrong). >>>>>> >>>>>> > >>>>>> > Are there any stats/progress graphs as to how the >>>>>> actual >>>>>> import is in >>>>>> > fact going? >>>>>> >>>>>> It would indeed be interesting to see which percentage of >>>>>> proposals are >>>>>> being approved (and stay in Wikidata after a while), and >>>>>> whether there >>>>>> is a pattern (100% approval on some type of fact that >>>>>> could >>>>>> then be >>>>>> merged more quickly; or very low approval on something >>>>>> else >>>>>> that would >>>>>> maybe better revisited for mapping errors or other >>>>>> systematic problems). >>>>>> >>>>>> Markus >>>>>> >>>>>> >>>>>> > >>>>>> > -- James. >>>>>> > >>>>>> > >>>>>> > On 24/09/2015 19:35, Lydia Pintscher wrote: >>>>>> >> On Thu, Sep 24, 2015 at 8:31 PM, Tom Morris >>>>>> <tfmor...@gmail.com <mailto:tfmor...@gmail.com>> wrote: >>>>>> >>>> This is to add MusicBrainz to the primary source >>>>>> tool, >>>>>> not anything >>>>>> >>>> else? >>>>>> >>> >>>>>> >>> >>>>>> >>> It's apparently worse than that (which I hadn't >>>>>> realized until I >>>>>> >>> re-read the >>>>>> >>> transcript). It sounds like it's just going to >>>>>> generate little warning >>>>>> >>> icons for "bad" facts and not lead to the recording >>>>>> of >>>>>> any new facts >>>>>> >>> at all. >>>>>> >>> >>>>>> >>> 17:22:33 <Lydia_WMDE> we'll also work on getting the >>>>>> extension >>>>>> >>> deployed that >>>>>> >>> will help with checking against 3rd party databases >>>>>> >>> 17:23:33 <Lydia_WMDE> the result of constraint checks >>>>>> and checks >>>>>> >>> against 3rd >>>>>> >>> party databases will then be used to display little >>>>>> indicators next to a >>>>>> >>> statement in case it is problematic >>>>>> >>> 17:23:47 <Lydia_WMDE> i hope this way more people >>>>>> become aware of >>>>>> >>> issues and >>>>>> >>> can help fix them >>>>>> >>> 17:24:35 <sjoerddebruin> Do you have any names of >>>>>> databases that are >>>>>> >>> supported? :) >>>>>> >>> 17:24:59 <Lydia_WMDE> sjoerddebruin: in the first >>>>>> version the german >>>>>> >>> national library. it can be extended later >>>>>> >>> >>>>>> >>> >>>>>> >>> I know Freebase is deemed to be nasty and unreliable, >>>>>> but is MusicBrainz >>>>>> >>> considered trustworthy enough to import directly or >>>>>> will its facts >>>>>> >>> need to >>>>>> >>> be dripped through the primary source soda straw one >>>>>> at >>>>>> a time too? >>>>>> >> >>>>>> >> The primary sources tool and the extension that helps >>>>>> us >>>>>> check against >>>>>> >> other databases are two independent things. >>>>>> >> Imports from Musicbrainz have been happening since a >>>>>> very long time >>>>>> >> already. >>>>>> >> >>>>>> >> >>>>>> >> Cheers >>>>>> >> Lydia >>>>>> >> >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Wikidata mailing list >>>>>> > Wikidata@lists.wikimedia.org >>>>>> <mailto:Wikidata@lists.wikimedia.org> >>>>>> > https://lists.wikimedia.org/mailman/listinfo/wikidata >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wikidata mailing list >>>>>> Wikidata@lists.wikimedia.org >>>>>> <mailto:Wikidata@lists.wikimedia.org> >>>>>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wikidata mailing list >>>>>> Wikidata@lists.wikimedia.org <mailto: >>>>>> Wikidata@lists.wikimedia.org> >>>>>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wikidata mailing list >>>>>> Wikidata@lists.wikimedia.org <mailto: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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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 > >
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
