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>

On 1 April 2014 19:14, Denny Vrandečić &lt;vrandecic(a)google.com&gt; wrote: That looks a very powerful and useful tool; thank you for making it available. I have two questions:" What if the author is already using "class='qlabel'" in their markup?

Why the attribute name "its-ta-ident-ref"?

-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

> What if the author is already using "class='qlabel'" in their markup?

Good point. Would you mind making a bug on the github project? https://github.com/googleknowledge/qlabel/ This should be configurable.

> Why the attribute name "its-ta-ident-ref"?

Standards. http://www.w3.org/TR/its20/

It is an absolutely terrible name.

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

a bug on the github project

It's called JsonP. We could support it, but it would render the URL uncacheable... bah, annoying.

CORS is indeed pretty well supported now http://caniuse.com/cors Mohamed On Wed, Apr 2, 2014 at 12:29 PM, Thomas Steiner &lt;tomac(a)google.com&gt; wrote: -- 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Am 02.04.2014 14:12, schrieb Magnus Manske: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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 &lt;magnusmanske(a)googlemail.com -- 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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 &lt;daniel.kinzler(a)wikimedia.de&gt; wrote: this may the with a would be per in one for cacheable entities requested is given page annotate with any displays structured anyone. http://google-opensource.blogspot.com/2014/04/qlabel-multilingual-content-w… -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254 paul.houle on Skype ontology2(a)gmail.com _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

This is so great, Denny! I wonder in what ways MIT OCW Translated Courses, for example, may begin to engage this - http://ocw.mit.edu/courses/translated-courses/. Thank you, Scott On Tue, Apr 1, 2014 at 2:02 PM, Andy Mabbett &lt;andy(a)pigsonthewing.org.uk&gt;wrote;wrote: -- - Scott MacLeod - Founder & President - http://scottmacleod.com/worlduniversityandschool.html - World University and School - like Wikipedia with MIT OpenCourseWare (not endorsed by MIT OCW) - incorporated as a nonprofit effective April 2010. _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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 &lt;daniel.kinzler(a)wikimedia.de&gt; wrote: this may the with a would be per in one for cacheable entities requested is given page annotate with any displays structured anyone. http://google-opensource.blogspot.com/2014/04/qlabel-multilingual-content-w… -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254 paul.houle on Skype ontology2(a)gmail.com _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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.