Wikidata

wikidata@lists.wikimedia.org

3 participants
4224 discussions

[Wikidata-l] Some handy links for keeping track of changes
by Jeroen De Dauw 25 May '12

25 May '12

Hey, Hope these are of use to others as well :) * http://bit.ly/wdreview - Our review queue for the Wikibase extensions (should be short!) * http://bit.ly/wdchanges - Open and merged changes to the Wikibase extensions, gives you an idea of who has been doing what Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

1 0

[Wikidata-l] Translation of wikibase-api-aliases-invalid-list
by Snaevar 25 May '12

25 May '12

Regarding the translation of wikibase-api-aliases-invalid-list, would it work to use an translation instead of one of the three parameters. Example: "Ajouter" is defined in wikibase-add as the french translation of "add". If "ajouter" would be used instead of "add" as an parameter in the API, would that work?

3 2

[Wikidata-l] [[meta:Wikitopics]] posted
by jmcclure＠hypergrove.com 23 May '12

23 May '12

Dear all, Comments are welcomed about a page I just posted which posits the use of the topic map metamodel (TMM) in the wikidata project. I'll do my best to respond, but frankly my focus these days is on more mundane topics like simple survival. Cheers - john Belltower Wikis

1 0

Re: [Wikidata-l] [wikidata-intern] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)
by Daniel Kinzler 23 May '12

23 May '12

On 22.05.2012 15:15, Nikola Smolenski wrote: > Including Items in an Article: > > {{#data-template:Infobox > |data_item=q332211 > |data_param=stuff > |foo=some value > |stuff.color=green > }} > > I see no reason for creating a new parser function for inclusion of templates. Basically, we need a way to pass a complex data object as a parameter to a template. If we don't have that, we have two alternative choices: 1) assign per-page variables to items, e.g. make {{{thingy}}} available in the article after a call to {{#load-data|thingy}}. Then you can use {{Infobox|data={{{thingy}}}}}, as usual. But I think this "global variables" approach is ugly and confusing, at least when stuff is loaded from inside templates. 2) alternatively, don't pass item from the article to the template at all. Instead, use parser functions for every access to an item property, and specify the item id as a parameter if necessary. That would create a lot of rundundancy and wouldn't allow "normal" template parameter syntax to be used to access data properties. To me, this seems natural, because it behaves like a function call. Being able to pass complex objects as parameters directly would of course be better still. Actually, if the template in question wants to pass the data object on to another template, we kind of need this... > Also, this syntax would not allow a template to draw data from more than one > item Correct. This could be simple enough to overcome, though I can't think of a *nice* way off hand. Off the top of my head, I'd do something like this: ... |data_item_2=q556677 |data_param_2=other_stuff |data_item_3=q114488 |data_param_3=more_stuff ... or even: |data_item=q332211 as stuff |data_item_2=q556677 as other_stuff |data_item_3=q114488 as more_stuff > which would probably be a requirement in phase3. No, it's not. phase3 is about automatic listings, which require a different syntax anyway. Also, in a list, all items would use the same template and the same rendering options. No need for the ability to pass multiple items to a single template. > Rather, I would include a template normally and use a parser function within the > template to access the data. So, that would be option (2) from above. > So, instead of {{{data}}} there would be {{#data:}}, instead of {{{data.color}}} > there would be {{#data:color}}, instead of {{{data.color(ACME_SURVEY_2010)}}} > there would be {{#data:color|ref=ACME_SURVEY_2010}} and so on. How would you specify which item {{#data:}} refers to, in case it's not the articles "default" item? How would you pass multiple items to a template? > One advantage is that commonly used syntax is always used, instead of inventing > new syntax (as for the reference in this example). For the most part, I tried to keep the normal syntax for template parameters, just introducing structured names (dots and colons). The syntax for selection-by-reference-id is indeed a bit awkward. Perhaps we can just drop it. If this is needed, one can always use the {{#data-value}} function with source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source'). > Another advantage, this way would make data usable directly in article text, if > that is wanted. Yes, that's also something that is bothering me. I would propose for this case to implement option (1) from above: use {{#load-data|stuff}} to make the item available as {{{stuff}}} in the current scope (preprocessor frame). That's kind of like saying "pass the item to me" instead of "pass the item to the template". > The parser function should be able to override itself by template parameters - I > believe it is possible to do this. That makes the hair in my neck stand up :) > Unrelated to the above, > > "This will return the value of the color property, in the page's content > language, as plain text." > > I see that there is need to also select desired content language (for example, a > lot of infoboxes display name of the topic in the content language and in the > topic's language(s)). This has the potential to introduce additional problems, > of course. The parameter syntax is the simply way to access property values. For all fancy needs, like picking the language, use {{#data-value}} instead. Basically, the {{{data.foo}}} syntax is just a shorthand for the more powerful {{#data-value}} stuff. Except that it's not wrapped in any HTML. Perhaps there should be an option to {{#data-value}} to turn that off completely, using form=plain or some such. > form > Specifies in what form rendered, that is, in which HTML element the value > should be wrapped. > > span: wrap in <span> tags, use <span> tags for parts > div: wrap in <div> tags, use <span> tags for parts > li: wrap in <li> tags, use <span> tags for parts > > I don't like this at all, since it limits the number of possibilities, > introduces yet another syntax parallel to HTML. > > Yet, I don't see anything much better. A half-baked idea is to leave it to the > client wikis to create their data display templates that could be used to format > data appropriately. Yes, this is kind of a nasty compromise. On the one hand, it would be extremely cumbersome to have to re-implement the table (and other) structures for representing property values with various qualifiers, not to speak of the rendering logic for these qualifiers themselves. On the other hand, we want to allow template authors to integrate property values in different kinds of structures, like tables and lists. Note that with the help of the show=... parameters, template authors can still implement their own rendering of the value (or rather, statement) with all it's parts, using one {{#data-value}} call for each one. > > (I see Jérémie's email now, and see that we came independently to some of the > same conclusions :) ) > > {{#data-values}}: > > But this is of course an even worse problem. > > {{#data-link:data|the data item}} > > Why not the usual interwiki syntax of [[wikidata:data|the data item]]? because "data" is not an identifier for that item on the wikidata repo. YOu would have to use something like: [[wikidata:/id/{{{data.id}}}|the data item]] But constructing edit links this way is very cumbersome. The main intend for this function is to make it easy to provide an edit link in the infobox. But perhaps a different syntax should be used for this. After all, the edit link would, with javascript enabled, not really be a link, but a button to activate the on-site editing feature. Thanks for your comments! -- daniel -- Daniel Kinzler, Softwarearchitekt Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin http://wikimedia.de | Tel. (030) 219 158 260 Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

4 6

[Wikidata-l] Teilnahme Wikidata
by pre.web＠gawnet.ch 23 May '12

23 May '12

(Once Wikidata seems to be a german project, I'll write this mail also in german language. Let me know if I'm wrong, so I would write again in english) Hallo Ich bin sehr an der Teilnahme vom Wikidata-Projekt interessiert, kämpfe aber noch mit der richtigen Anlaufstelle, bzw. Informationsbeschaffung. Natürlich habe ich die Informationen unter http://meta.wikimedia.org/wiki/Wikidata (http://meta.wikimedia.org/wiki/Wikidata) sowie einigen der Unterseiten gelesen. Eine Anfratge unter #wikimedia-wikidata (irc://irc.freenode.net/wikimedia-wikidata) wurde obschon etwa 30 Teilnehmer online waren nicht beantwortet. Deshalb nun meine Anfrage über die Mailingliste. Soweit ich gesehen habe, gibt es eine Liste in der man sich als Helfer eintragen lassen kann (http://meta.wikimedia.org/wiki/Wikidata/Volunteers (http://meta.wikimedia.org/wiki/Wikidata/Volunteers)). Allerdings sind mir die Aufgaben nicht ganz klar. Was genau man also z.B. unter "Interwiki to wikidata transition", "Importing data to Wikidata" oder "Infobox transition" zu verstehen hat. Solange ich darüber nicht im klaren bin, kann ich mich leider nicht eintragen. Könnte mir jemand beschreiben was genau man unter diesen drei Begriffen zu verstehen hat, wie die Arbeit daran genau aussieht und ab wann man mit der Arbeit loslegen kann? Ich würde mich gerne in irgendeiner Form der Dateneingabe-/übernahme beteiligen. Entweder die direkte Dateneingabe/-import, oder die nötigen Vorbereitungen dazu, damit der Import automatisiert werden kann. Welche Arbeit wäre da für mich passend? Freundliche Grüsse Tobias

2 1

[Wikidata-l] mockups for linking Wikipedia articles up for feedback
by Lydia Pintscher 22 May '12

22 May '12

Heya folks :) We've worked on mockups for how we think linking of articles between different Wikipedias should work with Wikidata. You can find the mock-ups and explanations here: https://meta.wikimedia.org/wiki/Wikidata/Notes/Storyboard_for_linking_Wikip… It'd be great if you could have a look and give feedback either here or on the discussion page on meta. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 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.

3 4

[Wikidata-l] We have a demosystem
by Lydia Pintscher 21 May '12

21 May '12

Heya folks :) I’m happy to let you know that we now have a demo system where you can follow Wikidata development hands-on. The demo system will be updated regularly so you can always see what we’ve been up to and try it out yourself. Please keep in mind that this is a system for testing so things might and probably will break here and there. There will be bugs. If you find any of them please tell us. There will be missing features or things that are not really finished yet. Data in there can be deleted at any time. That being said we hope that this gives you a good view of where Wikidata is heading and an opportunity to try it out and give feedback before it gets deployed. Right now you'll only see the start of the interwiki-link part of Wikidata. This means there is a repository where the links are collected and stored and a client that uses them. We’re looking forward to your feedback. For small comments please use the feedback link at the top of each page. For bug reports please use http://bugs.wikimedia.org (component Wikibase Client or Wikibase Repo in the product MediaWiki Extensions) and mention any information that might be relevant. And you’re of course free to discuss on this list. Thanks for your help with testing this. Your feedback is important to make Wikidata successful. You can access the demo at http://wikidata-test-repo.wikimedia.de. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 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.

3 5

[Wikidata-l] weekly summary #6
by Lydia Pintscher 18 May '12

18 May '12

Hi! This is the Wikidata summary of the week before 2012-05-18. You can find the wiki version of this at http://meta.wikimedia.org/wiki/Wikidata/Status_updates/2012_05_18 = Development = * Finished a clean-up and polish cycle: ** Implemented error handling in the UI ** A lot of work on getting the demo system up and running ** Set up a machine for automatic testing in different browsers and operating systems ** A lot of review of previous work and fixing problems that came up in the reviews * Start of next scrum cycle (http://meta.wikimedia.org/wiki/Wikidata/Development/Current sprint) * We have a demo system up and running now: http://lists.wikimedia.org/pipermail/wikidata-l/2012-May/000479.html You can follow commits at https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/WikidataClient… and https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/WikidataRepo.g… (stuff not merged into master yet isn't included there) = Discussions/Press = * Wikidata: The next step for Wikipedia and more http://www.infotoday.eu/Articles/Editorial/Featured-Articles/Wikidata-the-n… * mentions here and there in relation to Google’s recent announcement of the Knowledge Graph = Events = see http://meta.wikimedia.org/wiki/Wikidata/Events * upcoming: Wikipedia Stammtisch in Berlin * upcoming: Linuxtag * organizing a few local Wikidata intro and Q&A events in Essen, Köln and Dresden - more to follow = other stuff = * preparations for the hackathon and Wikidata/RENDER event in 2 weeks Anything to add? Please share! :) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 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.

1 0

[Wikidata-l] Wikidata extension on Mediawiki software
by Johnny West 17 May '12

17 May '12

I've looked through the documentation but can't find an explicit answer to this question so if I've missed it, apologies. Wikidata will be implemented as an extension to Mediawiki -- does that mean that the entire Wikidata architecture will be capable of being installed on Mediawiki instances outside Wikipedia? And if so, by this (northern) autumn, when we understand the interface may first be available to early users? I ask because we run a family of mediawikis and are very interested in piloting integration of Wikidata-type functionality across our own sites. I understand the emphasis in the main Wikipedia-connected project will be to on growing the community of users, and moving forward cautiously with regard to large data uploads. But we would like to experiment with data uploads within our own family of mediawikis, engaging networks of specialists around the world, and also working on the possibilty of automated integration from RSS etc. Is there anyone in Berlin we could talk to about this? Thanks Johnny West -- ************************************************************************* OUT NOW: Karama! Journeys in the Arab Spring -- http://johnnywest.net Imagine an Open Oil Industry -- http://openoil.net *************************************************************************

2 1

[Wikidata-l] Wikidata efforts for wiktionaries
by Sébastien Druon 15 May '12

15 May '12

Hello! Are their also wikidata efforts to give structure to wiktionaries? Do someone have references to some projects? Thanks in advance, S. Druon

4 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Wikidata