I was thinking about these issues, too. And my conclusion was that if we indeed run into this problem, then qLabel was much more successful than I expected :) -- which would be awesome!

My understanding is that it will take quite some uptake to make a serious dent on the server requirements of Wikidata or Freebase (not sure about any23). Also, this uptake will be gradual and growing slowly, so we should have the time to react to that.

You already sketch out a few possible solutions. They sound reasonable.

What I am much more worried about is that we -- if my understanding is current and correct -- do not even count accesses to the Wikidata web API, in particular not which modules are called. So, in short, we actually have no grasp at all as to whether this API is called, how much it is called, usage patterns, etc. This makes it very hard to talk about it and to consider any solutions.

So, whereas I fully understand your concerns and I appreciate the suggested solutions, I think our first task in this direction is to actually start gathering more data, and set up counts and metrics for the API. Anything else would be just guesswork.

(In case we already gather these metrics, I would be very interested in seeing them!)

Hope that makes sense,
Denny





On Wed, Apr 2, 2014 at 1:36 AM, Daniel Kinzler <daniel.kinzler@wikimedia.de> wrote:
Hey Denny! Awesome tool!

It's so awesome, we are already wondering about how to handle the load this may
generate.

As far as I can see, qlabel uses the wbgetentities API module. This has the
advantage of allowing the labels for all relevant entities to be fetched with a
single query, but it has the disadvantage of not being cacheable.

If qlabel used the .../entity/Q12345.json URLs to get entity data, that would be
covered by the web caches (squid/varnish). But it would mean one request per
entity, and would also return the full entity data, not just the  labels in one
language. So, a lot more traffic.

If this becomes big, we should probably offer a dedicated web interface for
fetching labels of many entities in a given language, using nice, cacheable
URLs. This would mean a new cache entry per language per combination of entities
- potentially, a large number. However, the combination of entities requested is
determiend by the page being localized - that is, all visitors of a given page
in a given language would hit the same cache entry. That seems workable.

Anyway, we are not there quite yet, just something to ponder :)

-- daniel


Am 01.04.2014 20:14, schrieb Denny Vrandečić:
> I just published qLabel, an Open Source jQuery plugin that allows to annotate
> HTML elements with Wikidata Q-IDs (or Freebase IDs, or, technically, with any
> other Semantic Web / Linked Data URI), and then grabs the labels and displays
> them in the selected language of the user.
>
> Put differently, it allows for the easy creation of multilingual structured
> websites. And it is one more way in which Wikidata data can be used, by anyone.
>
> Contributors and users are more than welcome!
>
> <http://google-opensource.blogspot.com/2014/04/qlabel-multilingual-content-without.html>
>
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>


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