Wikidata

wikidata@lists.wikimedia.org

4 participants
4159 discussions

[Wikidata-l] next Wikidata office hours
by Lydia Pintscher 29 May '12

29 May '12

Heya folks, I just wanted to let you know that the next Wikidata office hours will be on Tuesday and Wednesday next week. Denny and I will be around on IRC in #wikimedia-wikidata to answer any question you might have and discuss. I assume there will be a few more questions than usual now that we have a demo system. Logs will be published afterwards. English: May 29 at 16:30 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=30&sec=0&d…) German: May 30 at 16:30 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=30&sec=0&d…) 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 1

[Wikidata-l] JsonData extension
by Rob Lanphier 29 May '12

29 May '12

Hi folks, I'm about to head off to Berlin, but I've been quietly toiling away on this project for a while (technically since 2005) and I figured it's time to start making a little noise. The project is the JsonData extension for MediaWiki, which allows for validated editing of JSON files using a form in a MediaWiki installation. You may have stumbled upon my jsonwidget javascript editor, which has been around a long time (since 2005...gah, it's almost as old as a second grader!) When I wrote that, I always envisioned using that on a wiki, and never finished the job until recently. I also have never had a strong desire to maintain a schema format, so over this past weekend, I converted it to use a subset of Kris Zyp's draft-03. Validation is done both server side (PHP) and client side (Javascript). The license for both the server side validator and the client side library are three-clause BSD. The rest of the MediaWiki extension is GPLv2. The UI is still quite 2005-ish, unfortunately. There are other draft-03 compatible editors out there (one recently announced built on jquery-ui) which I may take a crack at . More information about the project can be found here: http://jsonwidget.org/wiki/JsonData I've got a test install there, so if you'd like to do some playing there, feel free to play around. I haven't made a big point of getting this checked into Gerrit, but I plan on doing that. This is a personal project (during my own time) and not-at-all something I'm doing on behalf of the WMF. It's also not (yet?) affiliated with Wikidata project, and I'm happy to change names to avoid confusion. Rob p.s. the security question answer, should you hit it, is "wikitech-l". It's amazing how quickly wikis start attracting spam.

2 1

Re: [Wikidata-l] Who to talk to about integrating WolrCat
by Klein,Max 25 May '12

25 May '12

Hi emijrp, I will have to investigate the licensing computability. Looking at the wikidata site on meta, it only mentions that " The content in Wikidata will be made available under a free license." [1] Are there any more decisions so far on this topic or will any CC license do? [1] http://meta.wikimedia.org/wiki/Wikidata/Notes/Requirements Best, Max Klein Wikipedia in Residence kleinm(a)oclc.org +17074787023 Hi Max; Is WorldCat aware of the Wikidata free license? I think that it is a good idea to include that info in Wikidata, that and the DOI metadata, which is currently generated like this[1] (only available in English Wikipedia). Regards, emijrp [1] https://en.wikipedia.org/wiki/Category:Cite_doi_templates 2012/5/25 Klein,Max <kleinm(a)oclc.org> > Hello Wikidata Wizards,**** > > ** ** > > Phoebe Ayers from the Board recommended I talk to you. My name is Max > Klein and I am the Wikipedian in Residence for OCLC. OCLC owns Worldcat.org > the world?s largest holder of Library data at 264 million bibliographic > records about books, journals and other library items. We would really like > to partner with you as Wikidata is being built, in incorporating our data > into your project.**** > > ** ** > > *What we can offer:* > > **? **WorldCat.org metadata http://www.worldcat.org/ . **** > > **o **Typically, for any work we have most of the following: title, > authors, publisher, formats, summaries, editions, subjects, languages, > intended audience, all associated ISBNs, length, and abstract.**** > > **? **APIs to this data http://oclc.org/developer/**** > > **o **And some other cool APIs like xISBN which returns all the ISBNs > of all the editions of book on the input of any single one.**** > > **? **Library finding tools**** > > **o **When viewing a record on our site, we show you the closest > library which has that work, and links to reserve it for pick-up.**** > > **? **The Virtual International Authority File (VIAF) > http://viaf.org/, which is an Authoritative Disambiguation file**** > > **o **That means that we have certified data on disambiguation of > Authors**** > > **? **WorldCat Identities, an Analytics site > http://www.worldcat.org/identities/**** > > **o **It gives you for Author metadata and analytics: Alternative > names, significant dates, publication timelines, genres, roles, related > authors, and tag clouds of associated subjects.**** > > ** ** > > *What?s in it for us:* > > **? **We are a not-for-profit member cooperative. Our mission is > ?Connecting people to knowledge through library cooperation.?**** > > **? **Since I work at the research group, for now this is just a > research project.**** > > **o **If at some point this goes live - and you want to - we?d like to > integrate the ?find it at a library near me? feature, that means > click-throughs for us.**** > > ** ** > > *The ideas:* > > There are a lot of possibilities, and I?d like to hear your input. These > are the first few that I?ve can come up with.**** > > **? **Making infoboxes for each book or author that contains all > their metadata.**** > > **o **Ready to incorporate into all language projects.**** > > **? **Using authority files to disambiguate or link works to > their creators.**** > > **o **Solving DABs**** > > **? **Using our analytics (e.g. author timelines) as Wikidata > data types to transclude.**** > > **o **Curating articles with easy to include dynamic analytics**** > > **? **Populating or creating works/author pages with their > algorithmically-derived history and details.**** > > **o **Extremely experimental semantic work.**** > > ** ** > > I?m roaring and ready to get this collaboration going. I know Wikidata is > at an early stage, and we are willing to accommodate you.**** > > Send me any feedback or ideas,**** > > ** ** > > Max Klein**** > > Wikipedia in Residence**** > > kleinm(a)oclc.org**** > > +17074787023**** > > ** ** > > _______________________________________________ > Wikidata-l mailing list > Wikidata-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-l > > -- Emilio J. Rodr?guez-Posada. E-mail: emijrp AT gmail DOT com Pre-doctoral student at the University of C?diz (Spain) Projects: AVBOT <http://code.google.com/p/avbot/> | StatMediaWiki<http://statmediawiki.forja.rediris.es> | WikiEvidens <http://code.google.com/p/wikievidens/> | WikiPapers<http://wikipapers.referata.com> | WikiTeam <http://code.google.com/p/wikiteam/> Personal website: https://sites.google.com/site/emijrp/

3 2

[Wikidata-l] weekly summary #7
by Lydia Pintscher 25 May '12

25 May '12

Hey :) This is the Wikidata summary of the week before 2012-05-25. You can also find this at http://meta.wikimedia.org/wiki/Wikidata/Status_updates/2012_05_25 = Development = * Reworked our git workflow: http://meta.wikimedia.org/wiki/Wikidata/Development/Process * Wrote tests for client, lib and repo * Introduced namespaces in lib and repo * Finished work on diff functionality which now supports recursion * Started work on handling changes on the client and appropriately caching info there * Reviewed code * Test, debug and fix problems in the Wikidata core branch * Fixed & refactored some minor stuff in the UI * Fixed broken UI tests * Getting git-review running on Windows * Trying to make all PHPUnit tests running without Failures & Errors under Windows See http://meta.wikimedia.org/wiki/Wikidata/Development/Current sprint for what we’re working on next. 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 = * Proposal for inclusion syntax: http://meta.wikimedia.org/wiki/Wikidata/Notes/Inclusion_syntax * Feedback on the demo system in various places has been very positive so far = Events = see http://meta.wikimedia.org/wiki/Wikidata/Events * LinuxTag * upcoming: IRC office hours next Tuesday and Wednesday * upcoming: MediaWiki hackathon (and Wikidata/RENDER event) * upcoming: Admin Convention of the German Wikipedia = other stuff = * preparations for the hackathon and Wikidata/RENDER event next week 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] Designs for the Universal Language Selector
by glenda jerome 25 May '12

25 May '12

I think this exchange with an expert of languages on-line can be of interest to us. Discussion comes from the Unicode mailing list. Best Glenda. At 16:29 25/05/2012, Philippe Verdy wrote: 2012/5/25 glenda.jerome <info(a)execlub.org>: > At 00:15 24/05/2012, Philippe Verdy wrote: >> >> >> http://blog.wikimedia.org/2012/05/21/introducing-designs-for-the-universal-… >> Enjoy :-) >> -- Philippe. > > > Philippe, > > could you please comment a little further on your comment? It would be of > real help to people working on the Wikidata project. I personally have no > idea why it would be a good/bad idea as I see cons and pros to the concept. > The real issue we have is to associate a term, its display, its exact > meaning and its value to a linguistic community. My fear is that a term may > have orthoghraphic and meaning variances and that such a simplified approach > may errode this diversity. This is not an area where we are expert, but I am > aware that what may decided for a MediaWiki project may influence many > things. > > Thank you! > Glenda I did not want to be obtrusive when posting this URL. But the current project in the Wikimedia foundation certainly has many valuable contributors available that could criticize the concepts and help defining it more precisely. But if the intent is to create associations of terms across languages, the difficulty is several orders of magnitude higher than doing that only within the same language. For now there are manual tuning to help create interwiki links, but we all know that these links are not (and cannot) be completely transitive, include for the reason that articles on each wiki have different structures and coverage of their subject (and it's irrealist to have as many articles with exactly the same coverage across all languages). So articles are splitting their subjects differently :some wikis will group several subjects with similar names on the same page, some will be so developed that they will be separated. In my opinion, the only safe interlingual classification that works is the one used in Commons (but Commons does not cover all subjects found in other wikis, it is poor about history, linguistic, politics, music, cinema, books and comics, and advanced sciences for example, because it is difficult to illustrate many concepts distinctly with images, audio or videos. So instead, I would build a dedicated search engine that can search through existing interwiki links and find associations, and possibly develop some automatic translation tools, or text extractors that can be used to compare contents from the various projects.

1 0

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Wikidata