Re: [Wikidata-l] weekly summary #156
Il 03/05/2015 16:13, Lydia Pintscher ha scritto: Hey folks :) Here's your summary of what happened around Wikidata over the last week. Events https://www.wikidata.org/wiki/Wikidata:Events/Press/Blogs https://www.wikidata.org/wiki/Wikidata:Press_coverage * Wikidata was presented at a Swedish Linked Data Network Meet-up https://www.eventbrite.com/e/lankade-data-natverkstraff-swedish-linked-data-network-meet-up-tickets-15689895901 in Gothenburg. * The most important Wikipedia pages http://www.gizmodo.in/news/The-Most-Important-Wikipedia-Pages-From-the-First-Open-Wiki-Ranking/articleshow/47082229.cms Other Noteworthy Stuff * P107 (main type) https://www.wikidata.org/w/index.php?title=Property:P107action=editredlink=1 is finally orphaned and deleted, 20 months after deprecation. This was the first property used 100 times. * The royal baby https://www.wikidata.org/wiki/Q18002970 was quickly updated on Wikidata. (her family tree https://tools.wmflabs.org/family/ancestors.php?q=Q18002970lang=en) * New tool by Magnus: Find pictures on geography.co.uk, upload them to Commons and add them to Wikidata https://tools.wmflabs.org/fist/geograph_candidates.html * All Van Gogh Museum paintings are now on Commons and Wikidata. Go go SumOfAllPaintings peeps! * List of topics with links in at least X Wikipedias https://tools.wmflabs.org/wikidata-todo/static/multi_wp/ * All French Senators matched using MixNMatch https://tools.wmflabs.org/mix-n-match/?mode=catalog_detailscatalog=44 \o/ Did you know? * Newest properties: represented by https://www.wikidata.org/wiki/Property:P1875, Netflix Identifier https://www.wikidata.org/wiki/Property:P1874, maximum number of players https://www.wikidata.org/wiki/Property:P1873, minimum number of players https://www.wikidata.org/wiki/Property:P1872, CERL ID https://www.wikidata.org/wiki/Property:P1871, Name Assigning Authority Number https://www.wikidata.org/wiki/Property:P1870, Hall of Valor ID https://www.wikidata.org/wiki/Property:P1869, ballots cast https://www.wikidata.org/wiki/Property:P1868, eligible voters https://www.wikidata.org/wiki/Property:P1867, catholic-hierarchy diocese ID https://www.wikidata.org/wiki/Property:P1866, Wikidata example geographic coordinates https://www.wikidata.org/wiki/Property:P1865, Wikidata example monolingual text https://www.wikidata.org/wiki/Property:P1864, Wikidata example property https://www.wikidata.org/wiki/Property:P1863, Wikidata example quantity https://www.wikidata.org/wiki/Property:P1862, Wikidata example time https://www.wikidata.org/wiki/Property:P1861, Wikidata example URL https://www.wikidata.org/wiki/Property:P1860, Wikidata example item value https://www.wikidata.org/wiki/Property:P1859, Wikidata example string https://www.wikidata.org/wiki/Property:P1858, Wikidata example media file https://www.wikidata.org/wiki/Property:P1856, Wikidata property example https://www.wikidata.org/wiki/Property:P1855 Development * We rolled out usage tracking on the first two wikis (French Wikisource and Dutch Wikipedia). Users should not notice anything. More wikis will follow in the next weeks. This is the remaining step for enabling arbitrary access on wikis other than Commons. * The students team is working hard to get a first release of the improved constraint reports and checks against 3rd party databases out. * Ricordisamoa fixed the issue with long descriptions being cut off. Actually Thiemo did the most of it ;) ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata for Wiktionary
Il 07/05/2015 14:08, Andy Mabbett ha scritto: On 7 May 2015 at 11:57, Ricordisamoa ricordisa...@openmailbox.org wrote: Let's focus on Commons, OpenStreetMap, queries, arbitrary access, new datatypes? OSM in what context? Adding mutual links, keeping them up to date, building applications that use both databases, etc. https://wiki.openstreetmap.org/wiki/Wikidata Also, we should throw WikiSpecies into the mix. This reminds me of some old discussions... [1] https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2013/02#Include_Wikispecies_into_Wikidata [2] https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2013/04#Wikispecies [3] https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/02#Wikispecies etc. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata for Wiktionary
Hi Denny, I would strongly advise against connecting Wiktionary to Wikidata in the status quo, mainly for the reasons Gerard summarized. While wikt's 'data model' probably makes sense for a spelling-based dictionary, it does not for a concept-based knowledge base like ours. Even turning Wiktionary into an OmegaWiki https://meta.wikimedia.org/wiki/OmegaWiki-like project seems unlikely feasible without an intermediate step. Let's focus on Commons, OpenStreetMap, queries, arbitrary access, new datatypes? Il 07/05/2015 04:54, Denny Vrandečić ha scritto: It is rather clear that everyone wants Wikidata to also support Wiktionary, and there have been plenty of proposals in the last few years. I think that the latest proposals are sufficiently similar to go for the next step: a break down of the tasks needed to get this done. Currently, the idea of having Wikidata supporting Wiktionary is stalled because it is regarded as a large monolithic task, and as such it is hard to plan and commit to. I tried to come up with a task break-down, and discussed it with Lydia and Daniel, and now, as said in the last office hour, here it is for discussion and community input. https://www.wikidata.org/wiki/Wikidata:Wiktionary/Development/Proposals/2015-05 I think it would be really awesome if we would start moving in this direction. Wiktionary supported by Wikidata could quickly become one of the crucial pieces of infrastructure for the Web as a whole, but in particular for Wikipedia and its future development. Cheers, Denny ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata for Wiktionary
Il 07/05/2015 16:03, Daniel Kinzler ha scritto: Am 07.05.2015 um 14:56 schrieb Yair Rand: Task 1 as described on the proposal page isn't completely clear on how it would work. Would the generated items have Q-ids? Would it be possible to link Wiktionary entries to non-Wiktionary pages in the very rare situations that make sense (articles on particular series of (not-language-associated) symbols/characters)? Task 1 (Interlanguage-Links for Wiktionary) would not involve Wikidata or Wikibase at all. It would be a standalone extension linking pages with identical names between wikis. It's ok then! I have been thinking about something like that for some time... ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Making queries on Wikibase
Il 29/04/2015 20:56, Luca Martinelli ha scritto: Dear all, I need to know about the possibility of making queries on a Wikibase instance. I think it is possible to make queries on data on a particular instance only with external tools at the moment, right? Thanks for the answer. :) Wikidata-Query-Service https://phabricator.wikimedia.org/project/profile/891/ ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Data templates
Il 11/04/2015 13:29, Antoine Isaac ha scritto: Hi, Is the 'template' word so bad? Paraphrasing Daniel's definition of the MediaWiki template, one could see a 'WikiData template' as a set of of properties that can be re-used, e.g. to make create statements about a certain class. (the 'parameter' bit could be understood as adding or removing properties from the templates, e.g. using twice a property or adding a new one when it's needed). What we're after seems to exist already, described as 'item structure': http://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure Or 'list of properties': https://www.wikidata.org/wiki/Wikidata:List_of_properties/Works 'schema convention' matches the idea, but the wording may be too abstract. I come from a community that calls such things 'description set profiles'; such expressions have a hard time being adopted in less technical communities... About the text values. A big +1 to Daniel at not trying to represent semi-structured text, which is meant to piggyback structured data in legacy systems that can't handle it. The matter is rather the availability in Wikidata of text-like summaries like the dbpedia-owl:abstract at http://dbpedia.org/page/Castle . Having things like this together with the Wikidata data would be great for data-reusers like us, instead of having to fetch it from elsewhere! There's TextExtracts https://www.mediawiki.org/wiki/Extension:TextExtracts for that: example https://en.wikipedia.org/w/api.php?action=queryprop=extractsexsentences=1explaintext=1titles=Castle Antoine --- Antoine Isaac RD Manager, Europeana.eu ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Data templates
Il 04/04/2015 23:45, Stas Malyshev ha scritto: Hi! For things that actually *are* free text, and not terribly long, a monolongual (or, in the future, multilingual) text property could be used. quote already exists, abstract could be added, pending community discussion. Length limitations can be adjusted if need be. Maybe if the need of bigger texts arises we can have separate field type? Right now the storage model is not very good for storing texts of non-negligible sizes, especially multilingual ones (x800 languages). OTOH, we have a type that allows us to use multimedia by integrating with Commons. So maybe the same idea with using some other wiki - quotes? sources? for bigger text snippets would work too? Just brainstorming here :) spamStructured Wikiquote https://meta.wikimedia.org/wiki/Structured_Wikiquote/spam What I was warning against is continuing the misuse of text fields for semi-structured or even fully structured data that I have often seen in GLAM meta-data. That kind of thing should not be copied to Wikidata. Right. I think it may be useful here to understand which kinds of text we're talking about which can't be structured but are big enough to cause concern. I.e. if it's quotes - we already have wikiquote, right? Etc. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Wikidata periodic table
Forgot: the code is formally under review here https://gerrit.wikimedia.org/r/202610/. GPL-3.0+ as the old WikiPeriod. Il 08/04/2015 01:18, Ricordisamoa ha scritto: I'd like to announce a new Labs tool to show a periodic table https://tools.wmflabs.org/ptable/. It is based on WikiPeriod's PHP code (in turn ported from JavaScript) and features several improvements: * 'tiles' are wider and taller; * most of them are now provided with a background color (the same as Wikipedia's https://en.wikipedia.org/wiki/Periodic_table#Periodic_table_legend_for_category) based on the elements' subclass of property https://www.wikidata.org/wiki/Property:P279 (the same that powers period/group detection); * for labels, Wikidata's built-in language fallback is used instead of just falling back to English; * a public JSON API https://tools.wmflabs.org/ptable/api is available for everyone! And some more under the hood: * rewritten in Python with Jinja2: o more object-oriented o presentation is split from actual logic o less vulnerable to XSS attacks * a LRU (least recently used) cache with a maximum TTL (per-item time-to-live) value of 6 hours is used to avoid hitting data sources on every request; * both the Wikidata API and Wikidata Query can be used interchangeably as sources. I had to create some items such as Q19753344 https://www.wikidata.org/wiki/Q19753344 and Q19753345 https://www.wikidata.org/wiki/Q19753345 to properly categorize elements. My knowledge of chemistry is limited, so please report/fix every mistake you can find ;-) Future plans include: * oxidation state * images * responsive design * alternative table structures ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Weekly Summary #152
Il 05/04/2015 17:18, John Lewis ha scritto: Hi everyone, Here is the latest update of everything going on around Wikidata! Discussions * Closed RfC: Reforming administrator inactivity criteria https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Reforming_administrator_inactivity_criteria Events https://www.wikidata.org/wiki/Wikidata:Events/Press/Blogs https://www.wikidata.org/wiki/Wikidata:Press_coverage * WikiArabia http://arabia.wikimedia.tn/index.php?title=Main_Page takes place in Monastir, Tunisia, 3-5 April * The GLAM-WIKI 2015 http://www.glamwiki.nl/ conference in The Hague (10-12 April) features several presentations and tutorials about Wikidata for/with cultural institutions. * The Library world will use Wikidata http://ultimategerardm.blogspot.nl/2015/04/viaf-move-over-wikipedia-for-wikidata.html to link its information to any and all Wikipedias. No longer English only, but every Wikipedia will be exposed in this way. * Freebase, SEO and Wikidata http://infobib.de/2015/04/01/seo-freebase-und-wikidata/ Hmm... German? * Office hour on IRC covering overall status/development, Freebase and admin inactivity criteria RfC. You can read the log https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-03-31-16.00.log.html. Other Noteworthy Stuff * Magnus wrote a short tour of Wikidata's tool ecosystem https://tools.wmflabs.org/wikidata-todo/tour.html#slide.3D0. * A first version of the Primary Sources Tool has been released https://lists.wikimedia.org/pipermail/wikidata-l/2015-April/005724.html. It'll help with migrating Freebase data and more. * Italian Wikipedia's quality festival https://it.wikipedia.org/wiki/Wikipedia:Festival_della_qualit%C3%A0/Aprile_2015 is focusing on interwiki links and Wikidata this month. Help them out? * Lots of new databases have been added to Mix n Match https://tools.wmflabs.org/mix-n-match/. * Screenshots of the current state of new constraint reports and checks against 3rd party databases have been posted. https://twitter.com/wikidata/status/582545229884063744 Did you know? * Newest properties: choreographer https://www.wikidata.org/wiki/Property:P1809, senat.fr ID https://www.wikidata.org/wiki/Property:P1808, Great Aragonese Encyclopedia ID https://www.wikidata.org/wiki/Property:P1807 Development * Wikidata development started 3 years ago https://twitter.com/wikidata/status/583220841711845376. 3 to everyone who is a part of it. * Went through all the feedback we got for improving watchlist integration on Wikipedia and co and posted our assesment https://www.wikidata.org/wiki/Wikidata:Watchlist_integration_improvement_input#First_iteration_on_feedback_by_dev_team * Put the infrastructure for creating Turtle https://en.wikipedia.org/wiki/Turtle_%28syntax%29-Beta dumps in place. All new Wikidata dumps will be in https://dumps.wikimedia.org/wikidatawiki/entities/ from Monday on (the old * directory will be kept around and receive new json dumps for backwards compatibility). * Reduced size of entities pages by removing no longer needed data (to make the UI faster). * Fixed bug that sometimes caused dates and other types of values to be cut short when quickly saving. (phabricator:T92831 https://phabricator.wikimedia.org/T92831) * Fixed issues with setting focus after clicking edit. You can see all open bugs related to Wikidata here https://phabricator.wikimedia.org/maniphest/query/4RotIcw5oINo/#R. Monthly Tasks * Hack on one of these https://phabricator.wikimedia.org/maniphest/query/R8GRzX1eH0tb/#R. * Help fix these items https://www.wikidata.org/wiki/Wikidata:The_Game/Flagged_items which have been flagged using Wikidata - The Game. * Help develop the next summary here! https://www.wikidata.org/wiki/Wikidata:Status_updates/Next * Contribute to a Showcase item https://www.wikidata.org/wiki/Wikidata:Showcase_items * Help translate https://www.wikidata.org/wiki/Special:LanguageStats or proofread pages in your own language! ___ 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] Data templates
Il 02/04/2015 13:51, Daniel Kinzler ha scritto: Am 02.04.2015 um 09:03 schrieb Valentine Charles: Regarding the dimensions, it is great to know that it is on your plate. I was wondering is there a place where we can see the classes/properties that are in the pipeline and participate to discussions around them? Note however that for dimensions, the issue is not creating the property, but teaching the software about units, so that such a property would make sense. A *lot* of properties are waiting for unit support: length, height, speed, distance, and many more are blocked on units. See Wikidata:Property proposal/Pending/2 https://www.wikidata.org/wiki/Wikidata:Property_proposal/Pending/2 for a list. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] 3 years!
Il 01/04/2015 12:46, Lydia Pintscher ha scritto:
Hey folks :)
3 years ago we started the development on Wikidata. I'm amazed at how
far we've come together in those 3 years. 3 to everyone who's a part
of this and helped us get to where we are. Looking forward to what we
can achieve in the next 3 ;-)
Cheers
Lydia
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
{{}}
__ __ _ _ __ _ _ ___
\ \/ /|_ _|| |/ /|_ _|| __ \ /\ |__ __| /\
\ \ /\ / / | | | ' / | | | | | | / \| | / \
\ \/ \/ /| | | | | | | | | / /\ \ | | / /\ \
\ /\ /_| |_ | . \ _| |_ | |__| | / \ | | / \
\/ \/|_||_|\_\|_||_/ /_/\_\ |_| /_/\_\
\\ // \\ // \\ // \\ //
\\ @@@ // \\ // \\ ééé // \\ %%% //
\\ @ // \\ // \\ è // \\ % //
\\ @@@ // \\ // \\ ééé // \\ %%% //
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Initial release of the primary sources tool
Il 01/04/2015 21:30, Denny Vrandečić ha scritto: Even better are pull requests! Unfortunately, Google requires anyone to sign a Contributor License Agreement. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Kian: The first neural network to serve Wikidata
Il 20/03/2015 01:11, Amir Ladsgroup ha scritto: OK, I have some news: 1- Today I rewrote some parts of Kian and now it automatically chooses regulation parameter (lambda), thus predictions are more accurate. I wanted to push changes to the github but It seems my ssh has issues. It'll be there soon 2- (Important) I wrote a code that can find possible mistakes in Wikidata based on Kian. The code will be in github soon. Check out this link http://tools.wmflabs.org/dexbot/possible_mistakes_fr.txt. It's result from comparing French Wikipedia against Wikidata e.g. this line: Q2994923: 1 (d), 0.257480420229 (w) [0, 0, 1, 2, 0] 1 (d) means Wikidata thinks it's a human 0.25... (w) means French Wikipedia thinks it's not a human (with 74.3% certainty) And if you check the link you can see it's a mistake in Wikidata. Please check other results and fix them. Tell me if you want this test to be ran from another language too. 3- I used Kian to import unconnected pages from French Wikipedia and created about 1900 items. The result is here http://tools.wmflabs.org/dexbot/kian_res_fr.txt and please check if anything in this list is not human and tell me and I run some error analysis. Best Great! Unfortunately, some files seem to have been published with the wrong character encoding. E.g. the first name shows up as Échécrate in my browsers. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Kian: The first neural network to serve Wikidata
Il 20/03/2015 01:11, Amir Ladsgroup ha scritto: OK, I have some news: 1- Today I rewrote some parts of Kian and now it automatically chooses regulation parameter (lambda), thus predictions are more accurate. I wanted to push changes to the github but It seems my ssh has issues. It'll be there soon 2- (Important) I wrote a code that can find possible mistakes in Wikidata based on Kian. The code will be in github soon. Check out this link http://tools.wmflabs.org/dexbot/possible_mistakes_fr.txt. It's result from comparing French Wikipedia against Wikidata e.g. this line: Q2994923: 1 (d), 0.257480420229 (w) [0, 0, 1, 2, 0] 1 (d) means Wikidata thinks it's a human 0.25... (w) means French Wikipedia thinks it's not a human (with 74.3% certainty) And if you check the link you can see it's a mistake in Wikidata. Please check other results and fix them. Tell me if you want this test to be ran from another language too. 3- I used Kian to import unconnected pages from French Wikipedia and created about 1900 items. The result is here http://tools.wmflabs.org/dexbot/kian_res_fr.txt and please check if anything in this list is not human and tell me and I run some error analysis. Best The data are based on dumps, aren't they? Wikidata hasn't been thinking Q73823 https://www.wikidata.org/wiki/Q73823 is a human since 21 Feb. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] mapping template parameters using Wikidata?
Il 04/03/2015 18:00, Ricordisamoa ha scritto: That's what Translatemplate https://tools.wmflabs.org/translatemplate/ is for! (thanks to you and Daniel for the idea :-) It uses mwparserfromhell to parse DBpedia mappings and 'translate' templates in-place. I've added you to the service group so you can fiddle with it. The code got a bit hackish to work around a mwparserfromhell/Labs bug. If you're happy with the result we can publish it in Gerrit. And the new version is live! You can test it right now in your browser. While it is not meant for production yet, I am very happy with the result. Amir, if you can come up with a better name I'll go straight to the Gerrit repository requests :-) ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Names, Aliases, Copyright (and a little OpenStreetMap)
I completely forgot we already had the excellent transliteration gadget https://www.wikidata.org/wiki/MediaWiki:Gadget-SimpleTransliterate.js by Ebraminio https://www.wikidata.org/wiki/User:Ebraminio. Just made a rough patch https://www.wikidata.org/w/index.php?title=MediaWiki:Gadget-SimpleTransliterate.jsdiff=20370oldid=155995810 to make it work with the new UI. Enjoy! Il 12/03/2015 11:24, Daniel Kinzler ha scritto: Am 12.03.2015 um 10:03 schrieb Gerard Meijssen: Hoi, What would you do with the many, many Chinese place names in Wikidata where we have nothing but Chinese ? It is completely useless to me in this way. A good transliterations works for me. Like most people beyond that I do not care much about it being official or sourced. Decent automatic translitteration is fine I think. Automatic word-for-word *translation* however seems rather problematic. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Kian: The first neural network to serve Wikidata
Sounds promising! It'd be good to have the code publicly viewable. Il 07/03/2015 13:24, Amir Ladsgroup ha scritto: Hey, I spent last few weeks working on this lights off [1] and now it's ready to work! Kian is a three-layered neural network with flexible number of inputs and outputs. So if we can parametrize a job, we can teach him easily and get the job done. For example and as the first job. We want to add P31:5 (human) to items of Wikidata based on categories of articles in Wikipedia. The only thing we need to is get list of items with P31:5 and list of items of not-humans (P31 exists but not 5 in it). then get list of category links in any wiki we want[2] and at last we feed these files to Kian and let him learn. Afterwards if we give Kian other articles and their categories, he classifies them as human, not human, or failed to determine. As test I gave him categories of ckb wiki (a small wiki) and worked pretty well and now I'm creating the training set from German Wikipedia and the next step will be English Wikipedia. Number of P31:5 will drastically increase this week. I would love comments or ideas for tasks that Kian can do. [1]: Because I love surprises [2]: select pp_value, cl_to from page_props join categorylinks on pp_page = cl_from where pp_propname = 'wikibase_item'; Best -- Amir ___ 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] mapping template parameters using Wikidata?
Il 03/03/2015 21:40, Amir E. Aharoni ha scritto:
Thanks, that's a step forward. Now the question is how to bring this
all together.
The context that interests me the most is translating an article in
ContentTranslation. Let's go with an architect.[1] I am translating an
article about an architect from English to Dutch, and it has {{Infobox
architect}} at the top. How would ContentTranslation, a MediaWiki
extension installed on the Wikimedia cluster, know that the name
parameter is naam in Dutch?
Currently, in theory, it would:
1. Find that there's a corresponding infobox in Dutch using the
interlanguage link:
https://nl.wikipedia.org/wiki/Sjabloon:Infobox_architect
2. Go to dbpedia and find the English template:
http://mappings.dbpedia.org/index.php/Mapping_en:Infobox_architect
3. Find that name is foaf:name
4. Go to dbpedia and find the Dutch template:
http://mappings.dbpedia.org/index.php/Mapping_nl:Infobox_architect
5. Find that foaf:name is naam
... And then repeat steps 1 to 5 for each parameter.
Is this something that is possible to query now? (I'm not even talking
about performance.)
That's what Translatemplate https://tools.wmflabs.org/translatemplate/
is for! (thanks to you and Daniel for the idea :-)
It uses mwparserfromhell to parse DBpedia mappings and 'translate'
templates in-place.
I've added you to the service group so you can fiddle with it.
The code got a bit hackish to work around a mwparserfromhell/Labs bug.
If you're happy with the result we can publish it in Gerrit.
Even if it is possible to query it, is it good to be dependent on an
external website for this? Maybe it makes sense to import the data
from dbpedia to Wikidata? It's absolutely not a rhetorical question -
maybe it is OK to use dbpedia.
[1] {{Infobox cricketer}} exists in the Dutch Wikipedia, but doesn'
appear in the Dutch mappings in dbpedia.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
2015-03-03 20:39 GMT+02:00 Daniel Kinzler daniel.kinz...@wikimedia.de
mailto:daniel.kinz...@wikimedia.de:
Am 03.03.2015 um 18:48 schrieb Amir E. Aharoni:
Trying again... It's a really important topic for me.
How do I go about proposing storing information about templates
parameters
mapping to the community? I kinda understand how Wikidata works,
and it sounds
like something that could be implemented using the current
properties, but
thoughts about moving this forward would be very welcome.
Hi Amir!
We had a call today with the dbPedia folks, about exactly this topic!
The dbPedia mapping wiki[1] has this information, at least to some
extent. Let's
say you are looking at {{Cricketer Infobox}} on en. You can look
out the DBPedia
mappings for the template parameters on their mapping page[2].
There you can see
that the country parameter maps to the country proeprty in the
dbpedia
ontology[2], which in turn uses owl:equivalentProperty to
cross-link P17[4].
I assume this info is also available in machine readable form
somewhere, but I
don't know where offhand.
Today we discussed that this mapping should also be available in
the opposite
direction: on Wikidata, you can use P1628 (equivalent property) to
cross-reference the dbPedia ontology. I just added this info to
the country
property.
let me know if this helps :)
-- daniel
[1] http://mappings.dbpedia.org/index.php/
[2] http://mappings.dbpedia.org/index.php/Mapping_en:Cricketer_Infobox
[3] http://mappings.dbpedia.org/index.php/OntologyProperty:Country
[4] https://www.wikidata.org/wiki/Property:P17
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org mailto: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
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Call for development openness
Hi. I recently started following mediawiki/extensions/Wikibase on Gerrit, and quite astonishingly found that nearly all of the 100 most recently updated changes appear to be owned by WMDE employees (exceptions being one change by Legoktm and some from L10n-bot). This is not the case, for example, with mediawiki/core. While this may be desired by the Wikidata team for corporate reasons, I feel that encouraging code review by volunteers would empower both Wikidata and third-party communities with new ways of contributing to the project and raise awareness of the development team's goals in the long term. The messy naming conventions play a role too, i.e. Extension:Wikibase https://www.mediawiki.org/w/index.php?title=Extension:Wikibaseredirect=no is supposed to host technical documentation but instead redirects to the Wikibase https://www.mediawiki.org/wiki/Wikibase portal, with actual documentation split into Extension:Wikibase Repository https://www.mediawiki.org/wiki/Extension:Wikibase_Repository and Extension:Wikibase Client https://www.mediawiki.org/wiki/Extension:Wikibase_Client, apparently ignoring the fact that the code is actually developed in a single repository (correct me if I'm wrong). Just to add some more confusion, there's also Extension:Wikidata build https://www.mediawiki.org/wiki/Extension:Wikidata_build with no documentation. And what about wmde on GitHub https://github.com/wmde with countless creatively-named repos? They make life even harder for potential contributors. Finally, the ever-changing client-side APIs make gadgets development a pain in the ass. Sorry if this sounds like a slap in the face, but it had to be said. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Call for development openness
Il 17/02/2015 12:53, Lydia Pintscher ha scritto: On Tue, Feb 17, 2015 at 12:43 PM, Ricordisamoa ricordisa...@openmailbox.org wrote: Hi. I recently started following mediawiki/extensions/Wikibase on Gerrit, and quite astonishingly found that nearly all of the 100 most recently updated changes appear to be owned by WMDE employees (exceptions being one change by Legoktm and some from L10n-bot). This is not the case, for example, with mediawiki/core. While this may be desired by the Wikidata team for corporate reasons, I feel that encouraging code review by volunteers would empower both Wikidata and third-party communities with new ways of contributing to the project and raise awareness of the development team's goals in the long term. How would you like to see us encourage this more? It is nothing we actively do not want of course. Using a single code review system and a simpler repository structure will indirectly encourage them. I'm now seeing Wikibase/Programmer's guide to Wikibase https://www.mediawiki.org/wiki/Wikibase/Programmer%27s_guide_to_Wikibase, which seems fairly detailed but partly duplicates the Gerrit help pages. The messy naming conventions play a role too, i.e. Extension:Wikibase is supposed to host technical documentation but instead redirects to the Wikibase portal, with actual documentation split into Extension:Wikibase Repository and Extension:Wikibase Client, apparently ignoring the fact that the code is actually developed in a single repository (correct me if I'm wrong). Just to add some more confusion, there's also Extension:Wikidata build with no documentation. There are different repositories. They just get merged into one for deployment. Really? AFAICS development occurs on mediawiki/extensions/Wikibase https://git.wikimedia.org/summary/?r=mediawiki/extensions/Wikibase.git and on GitHub. mediawiki/extensions/WikibaseRepository https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseRepository.git and mediawiki/extensions/WikibaseClient https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseClient.git also exist but have always been empty. Even mediawiki/extensions/WikibaseRepo https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseRepo.git appears to exist according to Gitblit, but not according to Gerrit nor GitHub... And what about wmde on GitHub with countless creatively-named repos? They make life even harder for potential contributors. Agreed. Something we want to tackle. Out of curiosity, was GitHub chosen because it fitted with your workflow? Will you embrace Differential when it comes? Finally, the ever-changing client-side APIs make gadgets development a pain in the ass. Agreed but as I said this is going to be painful for a little longer until we have done the UI redesign. After that I want it to be more stable again obviously. Thanks. Is there a task/page where progress is tracked? Cheers Lydia ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Call for development openness
Il 17/02/2015 13:33, Ricordisamoa ha scritto: Il 17/02/2015 12:53, Lydia Pintscher ha scritto: On Tue, Feb 17, 2015 at 12:43 PM, Ricordisamoa ricordisa...@openmailbox.org wrote: Hi. I recently started following mediawiki/extensions/Wikibase on Gerrit, and quite astonishingly found that nearly all of the 100 most recently updated changes appear to be owned by WMDE employees (exceptions being one change by Legoktm and some from L10n-bot). This is not the case, for example, with mediawiki/core. While this may be desired by the Wikidata team for corporate reasons, I feel that encouraging code review by volunteers would empower both Wikidata and third-party communities with new ways of contributing to the project and raise awareness of the development team's goals in the long term. How would you like to see us encourage this more? It is nothing we actively do not want of course. Using a single code review system and a simpler repository structure will indirectly encourage them. I'm now seeing Wikibase/Programmer's guide to Wikibase https://www.mediawiki.org/wiki/Wikibase/Programmer%27s_guide_to_Wikibase, which seems fairly detailed but partly duplicates the Gerrit help pages. The messy naming conventions play a role too, i.e. Extension:Wikibase is supposed to host technical documentation but instead redirects to the Wikibase portal, with actual documentation split into Extension:Wikibase Repository and Extension:Wikibase Client, apparently ignoring the fact that the code is actually developed in a single repository (correct me if I'm wrong). Just to add some more confusion, there's also Extension:Wikidata build with no documentation. There are different repositories. They just get merged into one for deployment. Really? AFAICS development occurs on mediawiki/extensions/Wikibase https://git.wikimedia.org/summary/?r=mediawiki/extensions/Wikibase.git and on GitHub. mediawiki/extensions/WikibaseRepository https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseRepository.git and mediawiki/extensions/WikibaseClient https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseClient.git also exist but have always been empty. Even mediawiki/extensions/WikibaseRepo https://git.wikimedia.org/summary/?r=mediawiki/extensions/WikibaseRepo.git appears to exist according to Gitblit, but not according to Gerrit nor GitHub... Upd: I found https://github.com/wmde/WikibaseRepository, https://github.com/wmde/WikibaseClient and https://github.com/wmde/WikibaseLib, but they're marked as experimental splits and have no commits since Oct 2014, so I suppose they're dead. And what about wmde on GitHub with countless creatively-named repos? They make life even harder for potential contributors. Agreed. Something we want to tackle. Out of curiosity, was GitHub chosen because it fitted with your workflow? Will you embrace Differential when it comes? Finally, the ever-changing client-side APIs make gadgets development a pain in the ass. Agreed but as I said this is going to be painful for a little longer until we have done the UI redesign. After that I want it to be more stable again obviously. Thanks. Is there a task/page where progress is tracked? Cheers Lydia ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] annotating red links
Il 11/02/2015 22:08, Amir E. Aharoni ha scritto: 2015-02-11 22:14 GMT+02:00 Ricordisamoa ricordisa...@openmailbox.org mailto:ricordisa...@openmailbox.org: Adding non-existing pages to Wikidata items? Using a syntax like [Q42[notexistingpagetitle]]? Is this a suggestion for possible syntax or something that actually works somewhere? It is only a humble attempt at designing a syntax that should be familiar with most wikitexters but shouldn't break the existing content corpus :-) But yeah, something like this - something that includes the title of a page that doesn't exist in this wiki, but may some to exist some day, and the Q number. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] annotating red links
Il 12/02/2015 11:23, Amir E. Aharoni ha scritto: The other is to extend the link syntax similar to image syntax, for example with [[Article Name|Alternate Text|wd=Q1234]]. This should be minimally disruptive to the editors. Yes - this would be more or less perfect, but it would require changes in core MediaWiki. If nothing else works, then it's possible, but seems harder to get through in practice. Wouldn't it be feasible by means of a hook? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] annotating red links
Il 11/02/2015 20:26, Amir E. Aharoni ha scritto: Hi, TL;DR: How can a red link be annotated in a semantic way with a foreign article title or a Wikidata Q item number? Imagine: I'm writing a Wikipedia article in Russian. There's a red link in it. I don't have time to write the target article for that link now, but I'm sure that it should exist. In fact, that article does exist in the English Wikipedia. I want the link to be red (fr the usual wiki reasons), but until the Russian article is written, I want to give the software a hint about which topic it is supposed to be about. Telling it the English article name would be one way to do it. Giving it the Wikidata Q item number would be an even better way to do it. Unfortunately, MediaWiki does not currently have true syntax to do either. (Correct me if I'm wrong.) Some Wikipedias may have templates that do something like this (e.g. Russian: https://ru.wikipedia.org/wiki/Template:En ). But there's nothing that is uniform to all projects. *Why* is it useful to give the software this hint in the first place? Most simplistically, it's useful to the reader - in case that reader knows English, she can at least read something. But there's something bigger. When the ContentTranslation extension translates links, it automatically adapts links that can be found. What to do about those that can't be auto-adapted? It frequently happens when Wikipedians translate articles that many links in the created articles turn out to be red. We'd love to get ContentTranslation to help the translators make those articles by writing relevant articles with as few clicks as possible, and that is only possible by annotating the red links with the topics to which they belong. So, any ideas? What do other Wikipedias for such annotation? Is it imaginable to add wiki syntax for such a thing? Can anybody think of a hack that reuses the current [[link]] syntax to add such annotation? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore Adding non-existing pages to Wikidata items? Using a syntax like [Q42[notexistingpagetitle]]? ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Freebase's incompatible types and Property description permissions
Il 08/01/2015 20:37, Thad Guidry ha scritto: On Thu, Jan 8, 2015 at 12:17 PM, Federico Leva (Nemo) nemow...@gmail.com mailto:nemow...@gmail.com wrote: Thad Guidry, 08/01/2015 18:58: Unless the P17 Country property had an expanded definition of sovereign state (or originating sovereign state) of this item That's more like P27. Both are rather flexible though, see their talk pages. https://www.wikidata.org/wiki/Property_talk:P17 1. How does Wikidata want to handle Property / Statement rule enforcement and Freebase's incompatible types ? I'm not sure how this is an example of incompatible type, it sounds more like a type Freebase didn't have. Handling such differences is possible by tweaking property descriptions and adding constraints. P17 is already declared incompatible with instance of: human. If you make music band a subclass of human, then this statement about U2 will be reported by bots as a constraint violation. Right, Freebase would not stick a Property called Country right on an instance of a Music Band. We would put Country under the Musical Group type, and give it a better definition like The nation or territory that this item originated from. Freebase's Properties always live under a Freebase Type, like Musical Group. Which is why on Wikidata, even seeing P17 on the U2 topic page makes me wonder what kind of schema Wikidata is trying to pull off. But it appears that someone did not really read the description page of P17, like I just did, then they would see it just is not allowed like that, but instead should have used P27, but then you can't have a date of birth for a Musical Group (band), which voids using even P27 on an instance of band. I understand, there are many holes in Wikidata's schema currently. I am one of several Freebase experts coming over that can help Wikidata identify those problematic Schema. :-) 2. How does Wikidata want to handle locking down Property descriptions (Freebase uses Permissions and Owners), where the complete meaning of something being changed might cause severe wrongful polluted data ? There is no such thing in wikis. http://c2.com/cgi/wiki?WikiDesignPrinciples https://meta.wikimedia.org/wiki/The_wiki_way But Wikidata is not a wiki in the true sense, or should not be purported as one Because it is not Schema-less, but in fact, prescribes to a publicly editable and agreed upon Schema model. One thing I did notice is that the Wikidata Schema model is actually composed of both agreement on the 2 tabs of https://www.wikidata.org/wiki/Property_talk:P17 both the Property tab, AND the Discussions tabcombined...give the effective model of the Property...whereas in Freebase, we would just have the Property, where all rules and definitions about it are stored (Discussions about a Property were stored on our wiki and also our mailing list). I enjoy the Wikidata way a bit more compared to Freebase, the benefit being a primary place to see the defines of the Property as well as the Discussion and questions about it in the past. The errors are corrected after the fact; the central control system is not made of permissions, but of checks like the constraint violations bots mentioned above. What other pollutions of the data you have in mind? And that is my worry. That the Schema model is publicly editable at any time. And constraint violations are only effective against a Well Defined Property. But what if I do not Well Define that property, or worst, I completely change the meaning of that Property. Imagine if I suddenly change the meaning of one of your MySQL table columns... like, PERSON suddenly becomes FURNITURE. That can happen with Wikidata's publicly editable Schema modelif someone maliciously changes the description of that P17 Country to something very generic like a state oh really ? What kind of state ? Nations only ? Or territories considered as an organized political community under one government.? or both ? it appears that P17's Discussion clarifies this a bit, and defines it a bit more narrowly and would not allow just any territory with a political community. We have the same problem in Freebase, where if by public agreement, we change the meaning of a Property so much that it might cause erroneous data statements, then we deprecate that Property and create a new one, splitting off the various statements into their proper form and letting the Community know, and also performing the data tasks to subscribe the old data to the new Schema. The pollution of data would happen if by agreement P17's Discussion page drastically changed the intended meaning of it, then all the data that used P17 would need to be cleaned up. How does Wikidata intend to deal with those kinds of changes to Property
Re: [Wikidata-l] Integration of ProteinBoxBot to the Mediawiki Gerrit
Il 11/11/2014 17:18, Sebastian Burgstaller ha scritto: Hi everyone! I would like to quickly introduce myself, my name is Sebastian (https://www.wikidata.org/wiki/User:Sebotic) and I will join the lab of Andrew Su (sulab.org) towards the end of this year. As you probably know, our main aim regarding WikiData is to integrate human genomics and medical data, this will also be my primary project. We therefore thought that it might be interesting to the WikiData community and also helpful for us, if we could integrate our sources for the ProteinBoxBot into the Mediawiki Gerrit code review system and receive contributions from the large community. The projects on Mediawiki Gerrit seems to be primarily concerning Mediawiki itself or addons to it. Would it be possible, to get our ProteinBoxBot project integrated on Gerrit? It is currently hosted on https://bitbucket.org/sulab/wikidatagenebot and is under strong development by Andra Wagmeester and I am about to join him in this effort. Thank you! Best regards, Sebastian Yes, please! Per my previous proposal https://lists.wikimedia.org/pipermail/wikidata-l/2014-October/004804.html, I think the project would benefit from being hosted on the same platform as Pywikibot. And what about a 'ProteinBoxBot' Phabricator project? ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
Il 16/10/2014 18:50, Jane Darnell ha scritto: Purodha, Redirects are cheap - so cheap in fact, that they take up more space when you delete them Every deletion of any page (as almost every action in MediaWiki) increases the size of the database. That doesn't mean the wiki is more cluttered. , so even if they are misspelled or whatever, they are mostly left to rot unless they break something (for example when someone wants to use a redlink like [[redlink]] and someone else makes a redirect for redlink). I don't think there is any Wikimedia project that actively deletes redirects. In general, redirects are supposed to be used as alternate names for the same thing, and in Wikidata, this is done by typing in alternate labels. Of course people also use redirects as a way of bundling concepts - just take a look at all the redirects to the article for insurance for all the types of insurance that don't yet have their own article. Before Wikidata there were lots of interwiki links to redirects, and this caused multiple issues with unresolvable interwikilinks. Wikidata was invented to be able to use persistent identifiers for Wikipedia articles. Now everyone is surprised that now the interwikilinks work differently from before. The fact that redirects are not supported is by design and not a bug. Going forward, instead of making redirects, Wikidatans should just keep creating items in Wikidata and let the Wikipedias take care of themselves by letting them create articles and redirects in the normal wiki way. It should not be a goal for Wikidata to sitelink to every redirect in every Wikipedia, just as it is not a goal to sitelink to every image on Wikimedia Commons. The subject at hand in this email thread is that instead of creating an article, the user ThurnerRupert made a redirect in the German Wikipedia called afrikanische Pflaume that links to Prunus and expected to be able to interwikilink this redirect via the Wikidata item for African Plum to the French Wikipedia's article for safou. I would say that Wikidata should not support this workflow and it is incorrect editing behavior. This has nothing to do with the numbers of redirects or whether or not they need to be deleted by anybody. Jane ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] standardize Wikidata WikiProject logos
Currently, we have different styles: c:Category:Wikidata task forces https://commons.wikimedia.org/wiki/Category:Wikidata_task_forces. What could a guideline be? ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] How can I increase the throughput of ProteinBoxBot?
Il 03/10/2014 22:31, Legoktm ha scritto: On 9/30/14 10:00 AM, Andra Waagmeester wrote: Would it be accepted if we increase the throughput by running multiple instances of ProteinBoxBot in parallel. If so, what would be an accepted number of parallel instances of a bot to run? We can run multiple instances from different geographical locations if necessary. https://www.mediawiki.org/wiki/API:Etiquette recommends that you don't make parallel requests. But if you're just going to run another instance of your bot I doubt it would cause any problems. Could you provide a link to your source code (I didn't see a link on the bot's userpage)? IIRC, you might be using pywikibot, but I don't remember exactly. Myself and other pywikibot developers can help you optimize your code :) -- Legoktm I suppose the latest version is https://bitbucket.org/chinmay26/proteinboxbot/. Pywikibot recently introduced a very simple way of manipulating items and sending back the changes via wbeditentity. If the whole Gene Wiki Project codebase were hosted on gerrit.wikimedia.org, more people could help ;-) ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
