I assume Magnus is referring to cases where for example, an item exists because someone's biography has been added to the Esperanto Wikipedia as a leading esperantist, but whose actual claim to fame for other Wikipedias is quite different (e.g. the person was a poet in another language, a leading politician in some city, etc).
On Mon, Feb 9, 2015 at 12:26 PM, Daniel Kinzler <daniel.kinz...@wikimedia.de > wrote: > Am 09.02.2015 um 12:17 schrieb Magnus Manske: > > My autodesc API serves both at the moment, so the consumer can decide > which one > > they want to use. Automatic descriptions can "miss the point" sometimes, > but are > > generally more up-to-date. > > Can you post a link for us to play with? > > In any case, the mobile app would need a production grade service, so it > would > have to wait until this is fully integrated with wikibase and live on > wikidata. > > > So, if you want to help with making automated description a reality, > please make > > suggestions that take into account the above points, and also > consider the > > mechanisms for language fallback. > > > > > > From my point of view, this is the "evolution" of automatic descriptions > (ADs): > > 1. web-based tools as proof-of-concept. This is done. > > 2. web-based API to standardise automatic descriptions, and make them > easily > > accessible for everyone. I am trying to do that now, > > 3. WMF/Wikibase-team picks up the API code, or writes their own; > integration > > into MediaWiki/extension, with proper language generation in many > languages, > > good caching/invalidation, API integration etc. Waiting for that :-) > > As Markus points out, this does not address the needs of dump consumers. > If the > UI and API generate automatic summaries on the fly, there is very little > incentive for users to enter descriptions manually (which is the point, of > course). This means few descriptions in dumps. > > To have the automatic summaries in the dumps, we would need to either > materialize them in the database (and then invalidate/update them when > appropriate), or we generated them on the fly when creating the dump. > > > In summary, I understand the issue, but it seems tricky to get the solution > right, both conceptually, and in terms of engineering. > > -- > Daniel Kinzler > Senior Software Developer > > Wikimedia Deutschland > Gesellschaft zur Förderung Freien Wissens e.V. > > _______________________________________________ > Wikidata-l mailing list > Wikidata-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-l >
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
