Re: [Wikidata-l] qLabel
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
Re: [Wikidata-l] qLabel
On 1 April 2014 20:01, Denny Vrandečić vrande...@google.com wrote: a bug on the github project I've raised another, about the use of adjectives and adverbs: https://github.com/googleknowledge/qlabel/issues/2 -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] qLabel
Am 02.04.2014 11:04, schrieb Magnus Manske: The ../entity/Q12345.json won't work, because of cross-domain browser limitations? Unless wikidata allows these server-side (forgot what the mechanism was called). It's called JsonP. We could support it, but it would render the URL uncacheable... bah, annoying. -- daniel -- 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
Re: [Wikidata-l] qLabel
It's called JsonP. We could support it, but it would render the URL uncacheable... bah, annoying. CORS to the rescue? Or did I miss something? Sorry in that case. -- Thomas Steiner, Employee, Google Inc. http://blog.tomayac.com, http://twitter.com/tomayac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtP5://xKcd.c0m/1181/ -END PGP SIGNATURE- ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] qLabel
CORS is indeed pretty well supported now http://caniuse.com/cors Mohamed On Wed, Apr 2, 2014 at 12:29 PM, Thomas Steiner to...@google.com wrote: It's called JsonP. We could support it, but it would render the URL uncacheable... bah, annoying. CORS to the rescue? Or did I miss something? Sorry in that case. -- Thomas Steiner, Employee, Google Inc. http://blog.tomayac.com, http://twitter.com/tomayac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtP5://xKcd.c0m/1181/ -END PGP SIGNATURE- ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 EURO ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Wikitech-l] Reducing the number of GeoData coordinates stored
Hoi Max, Is it possible to compare your index with the items in Wikidata. There are several things that I would like to do * add all coordinates to Wikidata items * report on all coordinates where what you know differs from Wikidata A next obvious question is how can we keep the two data sets in sync.. Thanks, GerardM On 2 April 2014 11:39, Max Semenik maxsem.w...@gmail.com wrote: Hi, I'd like a sanity check on my plans to reduce the GeoData index. I plan to: 1) Not store coordinates from pages outside of content namespaces: main and file. 2) Not store secondary coordinates that don't specify the coordinate name. There is currently a bunch of secondary coordinates that make no sense because there's to way to tell them apart or tell what are they for. I hope that these measures will make our database of geographical coordinates more useful on average, but please tell me if there's a fatal flaw in my plans:) -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list wikitec...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] qLabel
That's the one! On Wed, Apr 2, 2014 at 11:33 AM, Innovimax SARL innovi...@gmail.com wrote: CORS is indeed pretty well supported now http://caniuse.com/cors Mohamed On Wed, Apr 2, 2014 at 12:29 PM, Thomas Steiner to...@google.com wrote: It's called JsonP. We could support it, but it would render the URL uncacheable... bah, annoying. CORS to the rescue? Or did I miss something? Sorry in that case. -- Thomas Steiner, Employee, Google Inc. http://blog.tomayac.com, http://twitter.com/tomayac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtP5://xKcd.c0m/1181/ -END PGP SIGNATURE- ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 € ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- undefined ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] qLabel
Yes, if it's enabled on Wikidata. On Wed, Apr 2, 2014 at 1:26 PM, Daniel Kinzler daniel.kinz...@wikimedia.dewrote: Am 02.04.2014 14:12, schrieb Magnus Manske: That's the one! CORS should work fine with the cacheable URLs. -- daniel -- 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 -- undefined ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] qLabel
Indeed, and this is the good part about it. It's solvable server side and Wikidata is a server, so I just a matter of opening a bug, isn'it ? It seems there is already bunch of them open https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=CORS Mohamed On Wed, Apr 2, 2014 at 2:59 PM, Magnus Manske magnusman...@googlemail.comwrote: Yes, if it's enabled on Wikidata. On Wed, Apr 2, 2014 at 1:26 PM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: Am 02.04.2014 14:12, schrieb Magnus Manske: That's the one! CORS should work fine with the cacheable URLs. -- daniel -- 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 -- undefined ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 EURO ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] qLabel
I've been thinking about this kind of problem in my own systems. Name and link generation from entities is a cross-cutting concern that's best separated from other queries in your application. With SPARQL and multiple languages each with multiple rdf:label it is awkward to write queries that bring labels back with identifiers, particularly if you want to apply rules that amount if an ?lang label doesn't exist for a topic, show a label from a language that uses that uses the same alphabet as ?lang in preference to any others. Another issue too is that the design and business people might have some desire for certain kinds of labels and it's good to be able to change that without changing your queries. Anyway, a lot of people live on the other end of internet connections with 50ms, 2000ms or more latency to the network core, plus sometimes the network has a really bad day or even a bad few seconds. For every hundred or so TCP packets you send across the modern internet, you lose one. The fewer packets you send per interaction the less likely the user is going to experience this. If 20 names are looked up sequentially and somebody is on 3G cellular with 300ms latency, the user needs to wait six seconds for this data to load on top of the actual time moving the data and waiting for the server to get out of it's own way. This is using jQuery so it's very likely the page has other Javascript geegaws in that work OK for the developer who lives in Kansas City but ordinary folks in Peoria might not have the patience to wait until your page is fully loaded. Batch queries give users performance they can feel, even if they demand more of your server. In my system I am looking at having a name lookup server that is stupidly simple and looks up precomputed names in a key value store, everything really stripped down and efficient with no factors of two left on the floor. I'm looking at putting a pretty ordinary servlet that writes HTML in front of it, but a key thing is that the front of the back end runs queries in parallel to fight latency, which is the scourge of our times. (It's the difference between Github and Altassian) On Wed, Apr 2, 2014 at 4:36 AM, Daniel Kinzler daniel.kinz...@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 -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254paul.houle on Skype ontolo...@gmail.com ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] qLabel
Could one of the front-ends (squid?) perform a simple batch service, by just concatenating the /entity/ JSON for requested items? That could effectively run on the cache and still deliver batches. On Wed, Apr 2, 2014 at 4:44 PM, Paul Houle ontolo...@gmail.com wrote: I've been thinking about this kind of problem in my own systems. Name and link generation from entities is a cross-cutting concern that's best separated from other queries in your application. With SPARQL and multiple languages each with multiple rdf:label it is awkward to write queries that bring labels back with identifiers, particularly if you want to apply rules that amount if an ?lang label doesn't exist for a topic, show a label from a language that uses that uses the same alphabet as ?lang in preference to any others. Another issue too is that the design and business people might have some desire for certain kinds of labels and it's good to be able to change that without changing your queries. Anyway, a lot of people live on the other end of internet connections with 50ms, 2000ms or more latency to the network core, plus sometimes the network has a really bad day or even a bad few seconds. For every hundred or so TCP packets you send across the modern internet, you lose one. The fewer packets you send per interaction the less likely the user is going to experience this. If 20 names are looked up sequentially and somebody is on 3G cellular with 300ms latency, the user needs to wait six seconds for this data to load on top of the actual time moving the data and waiting for the server to get out of it's own way. This is using jQuery so it's very likely the page has other Javascript geegaws in that work OK for the developer who lives in Kansas City but ordinary folks in Peoria might not have the patience to wait until your page is fully loaded. Batch queries give users performance they can feel, even if they demand more of your server. In my system I am looking at having a name lookup server that is stupidly simple and looks up precomputed names in a key value store, everything really stripped down and efficient with no factors of two left on the floor. I'm looking at putting a pretty ordinary servlet that writes HTML in front of it, but a key thing is that the front of the back end runs queries in parallel to fight latency, which is the scourge of our times. (It's the difference between Github and Altassian) On Wed, Apr 2, 2014 at 4:36 AM, Daniel Kinzler daniel.kinz...@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 -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254paul.houle on Skype
Re: [Wikidata-l] qLabel
Of course. You can cache the individual entities somewhere inside the server-system where they can be stuck together very quickly, or you can cache them on the client. On Wed, Apr 2, 2014 at 12:04 PM, Magnus Manske magnusman...@googlemail.com wrote: Could one of the front-ends (squid?) perform a simple batch service, by just concatenating the /entity/ JSON for requested items? That could effectively run on the cache and still deliver batches. On Wed, Apr 2, 2014 at 4:44 PM, Paul Houle ontolo...@gmail.com wrote: I've been thinking about this kind of problem in my own systems. Name and link generation from entities is a cross-cutting concern that's best separated from other queries in your application. With SPARQL and multiple languages each with multiple rdf:label it is awkward to write queries that bring labels back with identifiers, particularly if you want to apply rules that amount if an ?lang label doesn't exist for a topic, show a label from a language that uses that uses the same alphabet as ?lang in preference to any others. Another issue too is that the design and business people might have some desire for certain kinds of labels and it's good to be able to change that without changing your queries. Anyway, a lot of people live on the other end of internet connections with 50ms, 2000ms or more latency to the network core, plus sometimes the network has a really bad day or even a bad few seconds. For every hundred or so TCP packets you send across the modern internet, you lose one. The fewer packets you send per interaction the less likely the user is going to experience this. If 20 names are looked up sequentially and somebody is on 3G cellular with 300ms latency, the user needs to wait six seconds for this data to load on top of the actual time moving the data and waiting for the server to get out of it's own way. This is using jQuery so it's very likely the page has other Javascript geegaws in that work OK for the developer who lives in Kansas City but ordinary folks in Peoria might not have the patience to wait until your page is fully loaded. Batch queries give users performance they can feel, even if they demand more of your server. In my system I am looking at having a name lookup server that is stupidly simple and looks up precomputed names in a key value store, everything really stripped down and efficient with no factors of two left on the floor. I'm looking at putting a pretty ordinary servlet that writes HTML in front of it, but a key thing is that the front of the back end runs queries in parallel to fight latency, which is the scourge of our times. (It's the difference between Github and Altassian) On Wed, Apr 2, 2014 at 4:36 AM, Daniel Kinzler daniel.kinz...@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.
Re: [Wikidata-l] qLabel
That's a toughie. Looking forward to see that one resolved :) On Wed, Apr 2, 2014 at 2:14 AM, Andy Mabbett a...@pigsonthewing.org.ukwrote: On 1 April 2014 20:01, Denny Vrandečić vrande...@google.com wrote: a bug on the github project I've raised another, about the use of adjectives and adverbs: https://github.com/googleknowledge/qlabel/issues/2 -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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
Re: [Wikidata-l] qLabel
Yes. That is why qLabel has a mechanism to implement your own loaders. The Wikidata and Freebase loaders are much more efficient than the generic RDF loader. Using SPARQL, RDF loading can be made more effective, but the LOD protocols break down with regards to that. Such a basic thing like labels on the Web of Data is a highly unsolved problem, and there is plenty of space for improvement. I hope that qLabel will incite the small number of changes required to change this situation. Cheers, Denny On Wed, Apr 2, 2014 at 8:44 AM, Paul Houle ontolo...@gmail.com wrote: I've been thinking about this kind of problem in my own systems. Name and link generation from entities is a cross-cutting concern that's best separated from other queries in your application. With SPARQL and multiple languages each with multiple rdf:label it is awkward to write queries that bring labels back with identifiers, particularly if you want to apply rules that amount if an ?lang label doesn't exist for a topic, show a label from a language that uses that uses the same alphabet as ?lang in preference to any others. Another issue too is that the design and business people might have some desire for certain kinds of labels and it's good to be able to change that without changing your queries. Anyway, a lot of people live on the other end of internet connections with 50ms, 2000ms or more latency to the network core, plus sometimes the network has a really bad day or even a bad few seconds. For every hundred or so TCP packets you send across the modern internet, you lose one. The fewer packets you send per interaction the less likely the user is going to experience this. If 20 names are looked up sequentially and somebody is on 3G cellular with 300ms latency, the user needs to wait six seconds for this data to load on top of the actual time moving the data and waiting for the server to get out of it's own way. This is using jQuery so it's very likely the page has other Javascript geegaws in that work OK for the developer who lives in Kansas City but ordinary folks in Peoria might not have the patience to wait until your page is fully loaded. Batch queries give users performance they can feel, even if they demand more of your server. In my system I am looking at having a name lookup server that is stupidly simple and looks up precomputed names in a key value store, everything really stripped down and efficient with no factors of two left on the floor. I'm looking at putting a pretty ordinary servlet that writes HTML in front of it, but a key thing is that the front of the back end runs queries in parallel to fight latency, which is the scourge of our times. (It's the difference between Github and Altassian) On Wed, Apr 2, 2014 at 4:36 AM, Daniel Kinzler daniel.kinz...@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
Re: [Wikidata-l] qLabel
On Wed, Apr 2, 2014 at 8:57 PM, Denny Vrandečić vrande...@google.com wrote: 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. https://bugzilla.wikimedia.org/show_bug.cgi?id=62873 ;-) -- 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. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] We should have a property for WikiMapia
Hello all, I think we should create a property for the items of Wikimapia, they are of additional value to Wikipedia articles as they mark the area of a certain subject instead of only a coordinate. http://wikimapia.org Romaine ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] We should have a property for WikiMapia
You should visit [[WD:PP]]([1]) and its subpages for proposing property. [1]: https://www.wikidata.org/wiki/WD:PP -Yena Hong (Revi) Wikimedian -- Sent from Android -- 2014. 4. 3. 오전 8:29에 Romaine Wiki romaine_w...@yahoo.com님이 작성: Hello all, I think we should create a property for the items of Wikimapia, they are of additional value to Wikipedia articles as they mark the area of a certain subject instead of only a coordinate. http://wikimapia.org Romaine ___ 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
