Re: [Wikidata-l] next 2 rounds of arbitrary access coming up
This is great! I just ran through the whole 1001 Vrouwen list of the DVN
hier:
https://nl.wikipedia.org/wiki/Gebruiker:Jane023/DVN
It seems to work fine, but there are no links for anything but the article
portion, so not quite as useful as the same functionality on the enwiki,
but still way, WAY better than my old manual list.
Thanks Magnus!
On Tue, May 19, 2015 at 1:22 PM, Magnus Manske magnusman...@googlemail.com
wrote:
I didn't copy the templates over; try this (I just ran it though):
https://tools.wmflabs.org/listeria/index.php?action=updatelang=nlpage=Gebruiker:Magnus_Manske/test1
On Tue, May 19, 2015 at 12:08 PM Gerard Meijssen
gerard.meijs...@gmail.com wrote:
Hoi,
I added Dutch labels. How can I refresh the data ?
Thanks,
GerardM
On 19 May 2015 at 12:54, Magnus Manske magnusman...@googlemail.com
wrote:
Trying (on my user subpage!) Wikidata-based lists with {{#property}}
instead of fixed text:
https://nl.wikipedia.org/wiki/Gebruiker:Magnus_Manske/test1
Works (date columns only in this example), but could use improvement.
Are there more details on {{#property}} somwhere?
On Tue, May 19, 2015 at 11:19 AM Lydia Pintscher
lydia.pintsc...@wikimedia.de wrote:
On Wed, May 13, 2015 at 5:20 PM, Lydia Pintscher
lydia.pintsc...@wikimedia.de wrote:
Hey folks :)
The rollout of arbitrary access on Dutch Wikipedia and French
Wikisource seems to be going well so we're going to continue the
rollout. The next projects will be:
* 18. May: Farsi Wikipedia, English Wikivoyage, Hebrew Wikipedia
* 1. June: Italian Wikipedia, all remaining Wikisource
Hey folks :)
Next round has been done now.
I have one request: Please do NOT go to those projects and try out
arbitrary access in their articles. Leave that to the local
communities. We want more projects to make use of Wikidata and not be
annoyed by random people coming to their projects and messing up their
articles.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
___
Wikidata-l 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 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] next 2 rounds of arbitrary access coming up
Thanks! This is a really powerful tool
On Tue, May 19, 2015 at 4:19 PM, Magnus Manske magnusman...@googlemail.com
wrote:
{{#property}} doesn't auto-link, apparently; switched item links back to
hand-crafted, now with links (updated yours already).
[sent from an airport restaurant...]
On Tue, May 19, 2015 at 2:37 PM Jane Darnell jane...@gmail.com wrote:
This is great! I just ran through the whole 1001 Vrouwen list of the
DVN hier:
https://nl.wikipedia.org/wiki/Gebruiker:Jane023/DVN
It seems to work fine, but there are no links for anything but the
article portion, so not quite as useful as the same functionality on the
enwiki, but still way, WAY better than my old manual list.
Thanks Magnus!
On Tue, May 19, 2015 at 1:22 PM, Magnus Manske
magnusman...@googlemail.com wrote:
I didn't copy the templates over; try this (I just ran it though):
https://tools.wmflabs.org/listeria/index.php?action=updatelang=nlpage=Gebruiker:Magnus_Manske/test1
On Tue, May 19, 2015 at 12:08 PM Gerard Meijssen
gerard.meijs...@gmail.com wrote:
Hoi,
I added Dutch labels. How can I refresh the data ?
Thanks,
GerardM
On 19 May 2015 at 12:54, Magnus Manske magnusman...@googlemail.com
wrote:
Trying (on my user subpage!) Wikidata-based lists with {{#property}}
instead of fixed text:
https://nl.wikipedia.org/wiki/Gebruiker:Magnus_Manske/test1
Works (date columns only in this example), but could use improvement.
Are there more details on {{#property}} somwhere?
On Tue, May 19, 2015 at 11:19 AM Lydia Pintscher
lydia.pintsc...@wikimedia.de wrote:
On Wed, May 13, 2015 at 5:20 PM, Lydia Pintscher
lydia.pintsc...@wikimedia.de wrote:
Hey folks :)
The rollout of arbitrary access on Dutch Wikipedia and French
Wikisource seems to be going well so we're going to continue the
rollout. The next projects will be:
* 18. May: Farsi Wikipedia, English Wikivoyage, Hebrew Wikipedia
* 1. June: Italian Wikipedia, all remaining Wikisource
Hey folks :)
Next round has been done now.
I have one request: Please do NOT go to those projects and try out
arbitrary access in their articles. Leave that to the local
communities. We want more projects to make use of Wikidata and not be
annoyed by random people coming to their projects and messing up their
articles.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.
V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
___
Wikidata-l 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 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 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] Merging items no longer possible
Thankis Lydia, it broke for me yesterday morning, but it was fixed this morning - no idea what caused it or what fixed it. I did try deselecting all options and reselecting them, but nothing seemed to help yesterday. I did notice however that the function as it exists today has changed: there is an option Select for merging now which wasn't there before it broke yesterday. On Mon, May 18, 2015 at 10:48 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Mon, May 18, 2015 at 5:08 AM, Jane Darnell jane...@gmail.com wrote: Hi, I no longer see the option to merge an item. Clicking on random items i see the star for watching an item, but no more tab for other options such as move or merge. Has this function been replaced with some other method? Nothing should have changed, no. Can you check if you get any javascript errors? You can do this in Chrome for example by clicking F12 and looking for the console part. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Merging items no longer possible
Solved, thanks! On Mon, May 18, 2015 at 5:08 AM, Jane Darnell jane...@gmail.com wrote: Hi, I no longer see the option to merge an item. Clicking on random items i see the star for watching an item, but no more tab for other options such as move or merge. Has this function been replaced with some other method? ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
[Wikidata-l] Merging items no longer possible
Hi, I no longer see the option to merge an item. Clicking on random items i see the star for watching an item, but no more tab for other options such as move or merge. Has this function been replaced with some other method? ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] novalue in qualifiers or references
What about people who were born in the 18th-century? We know they are dead, but their death is not recorded and we only know when they were last active. How do you set that end date? On Sun, Apr 26, 2015 at 8:36 AM, Stas Malyshev smalys...@wikimedia.org wrote: Hi! Actually I think that having no value for the end date qualifier probably means that it has not ended yet. There is no other way to But that's what no end date also means, in 99% cases where there's start date and no end date. Let's see https://www.wikidata.org/wiki/Q30#P35 - does it say that we have no idea if Barack Obama is still the US president (same for P6) and nobody bothered to check? I don't think so. I mean, maybe that was the original idea, but are we going to go and fix all start/end pairs now and add novalues to them? Are people editing Wikidata even aware this is what they should be doing - in case it is what they should be doing? I think in this case the common usage and the intent of the editor would be in 99% of cases that start date and no end date means current event and not we have no idea if it's still current or not. At least for something like P582. I admit, for some others the meaning may be different - i.e., if there's neither P580 nor P582 then the above reasoning does not apply. But then we by default assume it's current (unless it has P585) so the outcome is essentially the same. Other qualifiers I could imagine where an explicit no value would make sense is P678, I guess. OK, here I don't know much about what it means, so I just accept your point. In references it might make sense to state explicitly that the source does not have an issue number or an ISSN, etc., in order for example to allow cleanup of references and to mark the cases where a reference does not have a given value from those cases where it is merely incomplete. Here though again the same as above - usually when you add something that is expected to have issue number but it's not there, it's either somevalue (means, we don't know what the issue is, but it was an issue) or somehow it's the exception and it has no issue. Only actual usage of novalue I found in refs so far was confused usage of refs instead of qualifiers (pretty soon - ~couple of weeks - we'll have full recent dump loaded in the lab machine and we could answer this with real certainty, right now it's like 80% certainty :). I don't have superstrong arguments as you see (I would have much stronger arguments for unknown value), but I would prefer not to forbid no value in those cases explicitly, because it might be useful and it is already there. For qualifiers, I can see now there might be cases where it is useful, still not on references. But I think maybe not forbidding as such but having the guideline on what is considered the Right Thing and then if there's an exception than the editors can use their own judgement. -- Stas Malyshev smalys...@wikimedia.org ___ 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] items about data model concepts
So the intention is to use Q19798647 as a random place holder specifically for Wikibase entities without a value, but not as a no value placeholder for a person? I think it is useful in the way you describe it, but I am curious how you would model the source B saying that X had no child On Thu, Apr 23, 2015 at 11:37 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Thu, Apr 23, 2015 at 11:33 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Sorry for being dense.. What is wrong with there being no value ? Having a no value is imho understanding only a complication of saying nothing... Why not say nothing in the first place ? It is important for cases like the following for example: Source A says X had a child and source B says X had no child. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Data templates
For paintings you can better look here: https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings On Tue, Apr 7, 2015 at 1:12 PM, Valentine Charles valentine...@gmail.com wrote: Hello, I wanted to get an overview of all the properties used boy the instance Painting (https://www.wikidata.org/wiki/Q3305213) for further mapping with the Europeana Data Model. My initial thought that I would find a representative list at http://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure but in fact I have found much more properties used in association with painting. So I was wondering whether it would be a good idea to update the template mentioned above with the additional properties. I think it would be really interesting for GLAMs to have access to to representative templates listing all the properties used for a given type of objects. It would help them to understand Wikidata and to compare it with their own data. I think it would also help mappings activities. I on behalf of Europeana would be happy to help in this task and also facilitate the discussions with GLAMs around Wikidata. What do you think? Best wishes, Valentine 2015-04-04 23:45 GMT+02:00 Stas Malyshev smalys...@wikimedia.org: 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 :) 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. -- Stas Malyshev smalys...@wikimedia.org ___ 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Data templates
The more I think about this issue, the more I think we need a separate animal altogether that sits between Wikidata and Wikipedia (or alongside it somehow) and that is a quick-ref simple mobile version that acts as a go-between to image data on Commons (or any other WM project). Right now Wikipedia is still the main gateway for all related projects even though you can link those WM projects as extra sitelinks on the Wikidata item. We have seen with the problems regarding the label for the mobile interface that the current label falls short of what it needs to do, and the Wikipedia first sentence or paragraph is often not a viable option (too chatty) I am very satisified with all of the UI changes that Wikidata has implemented so far, but I don't think we should make Wikidata the definitive UI for mobile traffic, or for external websites. As more and more websites (such as GLAM's) link out to Wikipedia, we should offer them a way to tap into the wealth of info on Wikidata, especially since Wikidata is all about long-tail subjects at a higher granularity of precision, which is the same segment of information dissemination where most GLAMs reside. It could be a Reasonator on steroids On Wed, Apr 1, 2015 at 11:51 PM, Andrew Gray andrew.g...@dunelm.org.uk wrote: Hi Valentine, The long, chatty, free-text descriptive element of Wikidata is really Wikipedia ;-) There is a small free-text field in Wikidata for each item (the description, one per language) but it's intended for a short identifying/disambiguating note: 1887 self-portrait by XYZ; Danish artist and historian, 1912-1974, etc. Dimensions are, I believe, being worked on. Andrew. On 1 April 2015 at 08:20, Valentine Charles valentine...@gmail.com wrote: Dear all, Thank you all for your answers. I will have a look to the different projects you have mentioned in your emails. In the meantime I have spent a bit more time exploring Wikidata for paintings as one of our project currently focuses on Art and comparing it with the Europeana Data Model in terms of properties. I have noticed the absence of some properties and I would be curious whether it is just an overlook or whether there is a real intention behind the omission: -Cultural Heritage data have most of the time a description property where you will find lot of relevant free text information. The structured property but inside you will find mostly free- text. I couldn't find a similar property in Wikidata but there is something similar in Dbpedia. Is it something you are planning to introduce or have you made the decision to exclude any free-text infromation from Wikidata for now. -While I was looking for painting in Wikidata I also noticed the absence of information related to the size/dimension of the Artwork. The information is most of the time present in Cultural Heritage data. Is it something Wikidata is interested in or has it been omitted intentionally? -Then the last question is about values in different languages for a given property. How do you indicate the language in Wikidata? Are you using a xml:lang attribute or something similar? Thank you very much for your help Best, Valentine ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- - Andrew Gray andrew.g...@dunelm.org.uk ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] OWL based ontologies as basis for Wikidata item interactions and property proposal
Interesting approach, and one I would support. I have been against forcing Wikidata into any other jacket than one of its own knitting, but this approach makes OWL look like any other external database that may or may not come with properties worth integrating into Wikidata's jacket On Fri, Apr 3, 2015 at 11:16 AM, Sebastian Burgstaller sebastian.burgstal...@gmail.com wrote: Hello all, Wikidata consists of millions of single data items, which is great. In order to facilitate modeling the interactions between the single items, we hereby suggest using OWL based ontologies ( http://en.wikipedia.org/wiki/Web_Ontology_Language). We think that using ontologies brings several advantages: -Looking at an ontology (could collaboratively be generated e.g. on webprotege.stanford.edu) gives a very clear overview of how data is interconnected. This would allow for modeling of even very large and/or complex interactions. -Layouting a data integration project in an ontology first, before really integrating data into WD facilitates property proposal, as a ontology with its properties could first be designed and then the ontology with all its properties and classes could be generated as a whole. -Data could be queried/exported from WD based on an ontology by simply selecting the whole or parts of an ontology. This approach has been suggested and discussed by Benjamin Good, Elvira Mitraka, Andra Wagmeester, Andrew Su and me. As an example, we put together draft properties for gene disease interactions, which allows for WD community discussion of this apporach. A preliminary version can be found here: https://www.wikidata.org/wiki/User:ProteinBoxBot/GeneDiseaseIteraction_Discussion Best regards, Sebastian ___ 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] weekly summary #148
Wikiskim is great! It's International Women's Day though, so maybe this link is better https://tools.wmflabs.org/hay/wdskim/index.php?prop=P170item=Q232423language=enwithimages=on On Sun, Mar 8, 2015 at 10:47 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: Hey folks :) Here's your summary of what's been happening around Wikidata over the last week: Discussions - Open RfA: Haplology https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrator/Haplology Events https://www.wikidata.org/wiki/Wikidata:Events/Press/Blogs https://www.wikidata.org/wiki/Wikidata:Press_coverage - upcoming: Wikidata for Wikipedians at Lokal K in Köln in 17th of March https://de.wikipedia.org/wiki/Wikipedia:Lokal_K/Kalender - upcoming: Wikidata editathon in Berlin on 24th of March https://www.wikidata.org/wiki/Wikidata:Events/Berlin Other Noteworthy Stuff - Help flesh out landing pages for partners https://www.wikidata.org/wiki/Wikidata:Project_chat#Landing_pages_for_partners - Update on the Wikidata query service progress https://lists.wikimedia.org/pipermail/wikidata-tech/2015-March/000740.html - The automatic description API https://tools.wmflabs.org/autodesc/ can now generate infoboxes (currently, person and artwork on en.wp) - Wikidata Skim https://tools.wmflabs.org/hay/wdskim/index.php?prop=P170item=Q167654language=enwithimages=on gives you very simple query functionality - Meet Kian, the first neural network to serve Wikidata https://lists.wikimedia.org/pipermail/wikidata-l/2015-March/005537.html Did you know? - Newest properties: Information Center for Israeli Art artist identifier https://www.wikidata.org/wiki/Property:P1736, Comedien.ch identifier https://www.wikidata.org/wiki/Property:P1735, oath of office date https://www.wikidata.org/wiki/Property:P1734, Steam ID https://www.wikidata.org/wiki/Property:P1733 - Showcase items https://www.wikidata.org/wiki/Wikidata:Showcase_items: Symphony No. 7 https://www.wikidata.org/wiki/Q260957 Development - Fixed edit buttons sometimes not showing up because of caching - Added mailto to the allowed protocols in the URL data type - Worked on updating the data model documentation - Worked on client wiki subscription/notification mechanism - Improved handling of scientific notation for quantity values - Reworked a lot of code related to time parsing and formatting, e.g. proper support for language independent parsing of -MM-DD ordered dates - Continued working on the new Special:SetLabelDescriptionAliases 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! Anything to add? Please share! :) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Update on data quality project
OK thanks for the clarification. I believe both projects are related to the constraints, no? Anyway I think this is good work, though some of the exception reports are so huge that I wonder how useful some constraints are. On Fri, Feb 20, 2015 at 11:57 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Fri, Feb 20, 2015 at 11:54 AM, Jane Darnell jane...@gmail.com wrote: Lydia, Thanks. Is this the team responsible for the suggested properties? As a Wikidata user, how do I see their work exactly? Yes they are. https://www.mediawiki.org/wiki/WikidataQuality is the best overview of their work currently. Demos and so on will follow. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Update on data quality project
Lydia, Thanks. Is this the team responsible for the suggested properties? As a Wikidata user, how do I see their work exactly? Jane On Fri, Feb 20, 2015 at 11:40 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: Hey folks :) The students team working on data quality is making good progress. For some reason their emails don't go through to this list so I am sending it for them below. Cheers Lydia Hey :) We are a team of students from Hasso-Plattner-Institute in Potsdam, Germany. For our bachelor project we're working together with the team of Wikidata to ensure their data quality. On our wiki page (https://www.mediawiki.org/wiki/WikidataQuality) we introduce our projects in more detail. One of them deals with constraints, for which we need your input since we want to work on constraints as statements on properties and the final form of those still needs to be specified. So far, we hope you like our projects and we appreciate your input! Cheers, the Wikidata Quality Team -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Update on data quality project
Lydia, Thanks - I have used those suggestions tons of times and I have noticed the suggestions getting better. Great and useful work definitely! Jane On Fri, Feb 20, 2015 at 11:57 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Fri, Feb 20, 2015 at 11:54 AM, Jane Darnell jane...@gmail.com wrote: Lydia, Thanks. Is this the team responsible for the suggested properties? As a Wikidata user, how do I see their work exactly? Yes they are. https://www.mediawiki.org/wiki/WikidataQuality is the best overview of their work currently. Demos and so on will follow. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Update on data quality project
On Fri, Feb 20, 2015 at 11:57 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: On Fri, Feb 20, 2015 at 11:54 AM, Jane Darnell jane...@gmail.com wrote: Lydia, Thanks. Is this the team responsible for the suggested properties? As a Wikidata user, how do I see their work exactly? Yes they are. https://www.mediawiki.org/wiki/WikidataQuality is the best overview of their work currently. Demos and so on will follow. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] annotating red links
I'm thinking it should be a combination of syntax in the page, but also in the New Page create page. That page now directs you to the new Drafts userspace, but I think it should direct you also to Wikidata. That page says this now on enwiki: Before creating an article, please read Wikipedia:Your first article. You can also search for an existing article to which you can redirect this title. To experiment, please use the sandbox. To use a wizard to create an article, see the Article wizard. When creating an article, provide references to reliable published sources. An article without references, especially a biography of a living person, may be deleted. You can also start your new article at Special:Mypage/XX. There, you can develop the article with less risk of deletion, ask other editors to help work on it, and move it into article space when it is ready. On Thu, Feb 12, 2015 at 12:43 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: The question is not so much where to point it, but how to put it into the wiki syntax of the page. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2015-02-12 13:05 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com: Hoi, The obvious is painful. When you need a placeholder... Why not use Reasonator? It is just a call to the Wikidata item that is associated with the page. Thanks, Gerard On 12 February 2015 at 11:18, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: implementationthoughts The advantage of a template is that it doesn't touch core and doesn't create new wiki syntax. Maybe this template could be a Lua module built into the Wikibase Client extension, so it wouldn't have to be lamely synchronized across hundreds of projects? /implementationthoughts -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2015-02-12 12:12 GMT+02:00 Lydia Pintscher lydia.pintsc...@wikimedia.de : I am also interested in solving this for the article placeholder feature where we show date from Wikidata when no local article exists. We can't really just put the link to the non existent article into the Wikidata item because the article might be created and then cover a completely unrelated topic. We already have this problem with red links on Wikipedia but it would be even worse on Wikidata. I think the way to go is to have the Wikidata identifier used in the link on the article. Question is how to do that nicely. I am happy to see the template experiment. Are people generally ok with the way it works? Cheers Lydia ___ 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 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] annotating red links
Lydia, Good question! To answer your question, I have no idea. There have been no deletion discussions, but use of the template is limited at best. Here are few more ways I used it: https://nl.wikipedia.org/wiki/Eerebegraafplaats_Bloemendaal https://en.wikipedia.org/wiki/Modern_Times:_Photography_in_the_20th_Century Jane On Thu, Feb 12, 2015 at 11:12 AM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: I am also interested in solving this for the article placeholder feature where we show date from Wikidata when no local article exists. We can't really just put the link to the non existent article into the Wikidata item because the article might be created and then cover a completely unrelated topic. We already have this problem with red links on Wikipedia but it would be even worse on Wikidata. I think the way to go is to have the Wikidata identifier used in the link on the article. Question is how to do that nicely. I am happy to see the template experiment. Are people generally ok with the way it works? Cheers Lydia ___ 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] annotating red links
Amir, The most important thing to consider when you look at the burden to the community is the Bonnie Clyde problem where it gets to be the choice of a few editors (maybe just one?) on any given Wikipedia. I noticed that the English Wikipedia only has one article for both Q11629 the art of painting and Q3305213 the physical object, whereas both probably need about 5 articles each (container article and subarticles; so eg. 1) Q3305213 painting, 1.1)oil painting 1.2) miniature 1.3) watercolor, etc). The enwiki article is currently linked to the Wikidata item for the art of painting and the English Wikipedia has no article for the physical object. This strange situation is probably caused by the fact that both meanings are covered by the same word in English, which is of course not the case in other languages. When I created an article in the English Wikipedia for painting (object), it just got redirected to the other one, and I was accused of disruptive editing. Now this redirect is become one of the many hanging redirects in Wikidata that should be deleted. In the pre-Wikidata world, people tended to stuff articles full of every lemma that was not encyclopedia worthy in and of itself. In the English Wikipedia there is even a merge template for that. Today, in the post-Wikidata world we are concentrating on getting the most info possible into a mobile-sized screen, so we favor condensed chunks of twitter-style info, rather than pages of text. I see this in my watchlist from the number of changes to lead paragraphs. Everyone seems to just concentrate on the lead these days, because that is what Google is serving to searchers. In conclusion, though I share your dream, after considering this problem from many angles I think the best interim solution is to do nothing. A cultural revolution is taking place in Wikipedia, whereby people are slowly realizing that breadth (range of articles on any given subject) is more important than length (depth of any given article on its own subject). Let that revolution take place, one article at a time, at the pace granted by the policies of any given Wikipedia. Jane On Thu, Feb 12, 2015 at 8:58 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Yeah, looking into labels is certainly something that I considered, but that is by definition only a guess and not as bulletproof as Q numbers. We considered doing stuff like: * [[not-yet-written article about Douglas Adams|Douglas Adams]]!-- wd: Q42 -- * [[not-yet-written article about Douglas Adams#Q42|Douglas Adams]] ... and this would kinda work, but would be leave a lot of mess to the community editors to clean up. The template way, suggested by Gerard, is similar and seems slightly less messy to me. But only slightly. (If anybody cares, the relevant task in ContentTranslation is https://phabricator.wikimedia.org/T88580 .) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2015-02-12 7:51 GMT+02:00 Maarten Dammers maar...@mdammers.nl: Hi Amir, Amir E. Aharoni schreef op 11-2-2015 om 13:12: If I may dream for a moment, this should be something that can be used in all Wikipedias, and without copying this template everywhere, but built into the site's software :) Exactly, the template based approach doesn't scale at all. You have to somehow make it automatic. One thing I thought about is adding suggested sitelinks to Wikidata. The software would encounter a red link and would look in Wikidata if it can find an item with a suggested sitelink of the same title. Huge software overhaul so I don't see that happening. Another approach that is probably already possible right now: * Take an article with a red link * Look at the links in the article in other languages. * If you find a link that points to another article which has the same label as the red link in the same language, link to it I wonder how many good results that would give. Maarten ___ 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] annotating red links
Hi Amir, We created a template in the English Wikipedia for this and I used it here: https://en.wikipedia.org/wiki/Koekkoek I also just stumbled across this, which is also acceptable here: https://en.wikipedia.org/wiki/Wauters The first method keeps the enwiki link red, which is what you want, but the wrapper leads you to Wikidata or to Reasonator. The second method leads you to an article in the language that you may recognize by the prefix, but the color difference from blue is too subtle to notice. It would be nice if we had a gadget that made these orange, the way I have a gadget now that makes redirects look green. Jane On Wed, Feb 11, 2015 at 8:26 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 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 ___ 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] descriptions in mobile app
I assume Magnus is referring to cases where for example, an item exists because someone's biography has been added to the Esperanto Wikipedia as a leading esperantist, but whose actual claim to fame for other Wikipedias is quite different (e.g. the person was a poet in another language, a leading politician in some city, etc). On Mon, Feb 9, 2015 at 12:26 PM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: Am 09.02.2015 um 12:17 schrieb Magnus Manske: My autodesc API serves both at the moment, so the consumer can decide which one they want to use. Automatic descriptions can miss the point sometimes, but are generally more up-to-date. Can you post a link for us to play with? In any case, the mobile app would need a production grade service, so it would have to wait until this is fully integrated with wikibase and live on wikidata. So, if you want to help with making automated description a reality, please make suggestions that take into account the above points, and also consider the mechanisms for language fallback. From my point of view, this is the evolution of automatic descriptions (ADs): 1. web-based tools as proof-of-concept. This is done. 2. web-based API to standardise automatic descriptions, and make them easily accessible for everyone. I am trying to do that now, 3. WMF/Wikibase-team picks up the API code, or writes their own; integration into MediaWiki/extension, with proper language generation in many languages, good caching/invalidation, API integration etc. Waiting for that :-) As Markus points out, this does not address the needs of dump consumers. If the UI and API generate automatic summaries on the fly, there is very little incentive for users to enter descriptions manually (which is the point, of course). This means few descriptions in dumps. To have the automatic summaries in the dumps, we would need to either materialize them in the database (and then invalidate/update them when appropriate), or we generated them on the fly when creating the dump. In summary, I understand the issue, but it seems tricky to get the solution right, both conceptually, and in terms of engineering. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Impossible to add interwiki links
+1 on collecting the click data! I for one would bet that the number of page creators in any given Wikipedia that know enough to even look at the left side of the page is quite small. In my experience, most page creators are unaware that Wikipedia exists in any language but their own On Thu, Jan 29, 2015 at 11:49 AM, Federico Leva (Nemo) nemow...@gmail.com wrote: Daniel Kinzler, 29/01/2015 11:24: As far as I recall, there is some very silly technical reason that this is not easy to change at all. We tried to do this right when we introduced the other widget, of course. I don't recall what exactly the problem was though, and it might have been fixed since. Worth another look... I see. I said should (ought to?). :P Is there a phabricator ticket for this? Lydia Pintscher, 29/01/2015 11:31: The issue with doing this when there are several sitelinks is that people will unknowingly merge items this way that should not be merged. That'd be a huge pita. We'll need to put some good thinking into this still. I have no good solution right now. This is a non-issue IMHO, as soon as my suggestion at https://phabricator.wikimedia.org/T85776 / https://phabricator.wikimedia. org/transactions/detail/PHID-XACT-TASK-zi2igyjlfqasknq/ is implemented. This should be very easy to change. The dialog could then contain a link to the Wikidata item for the case when one wants to edit or remove links, until such a feature is added to the dialog itself. Showing the dialog and requiring people to click would probably annoy people for having to click one additional time? Especially if their intention is clear. There is already a generic Wikidata link in the sidebar which users can click; having two of them is a waste. Also, the drawback is much lower than the gain: if I'm forced to visit an entry in Wikidata to edit a sitelink, I have to spend X seconds to load the entry, then find the add button etc, spend additional N links; if I really want to go to the Wikidata entry, having to click in a dialog is just one click more and a fraction of second spent. If you really think the add one link case is minoritary for those who click the edit links button, I trust you, but we should have click tracking data to back this. Personally, I'd bet 85 % of users clicking the button just wants to add one link and expects to see the dialog they usually see to add links (when there are none). Nemo ___ 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] Impossible to add interwiki links
A link to Reasonator would be more useful probably, or at at least offering that as a choice along with the message no sitelinks found On Thu, Jan 29, 2015 at 11:24 AM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: Am 29.01.2015 um 02:05 schrieb Federico Leva (Nemo): This should be very easy to change. The dialog could then contain a link to the Wikidata item for the case when one wants to edit or remove links, until such a feature is added to the dialog itself. As far as I recall, there is some very silly technical reason that this is not easy to change at all. We tried to do this right when we introduced the other widget, of course. I don't recall what exactly the problem was though, and it might have been fixed since. Worth another look... -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Impossible to add interwiki links
I do think we are in agreement, as we both wish for more data. I would be very interested in any survey results the Welsh community may have. In my comment about your logic, I was referring to your comment that size matters, because I think size is not at issue here. The true issue is the language barrier, but not so much because of the unfolding role of Wikidata in relationship to the variety of languages as much as the unfolding role of Wikidata in relationship to the community of engaged users On Thu, Jan 29, 2015 at 4:03 PM, Fabian Tompsett fabian.tomps...@wikimedia.org.uk wrote: Hi Jane, Thanks for that. My guesses maybe wrong, but that does not mean my logic is flawed. My point was precisely that different language Wikipedias will have their own characteristics, and that it is precisely because, as we agree, Welsh wikimedians also read English wikipedia that I made my point. I found the information you gave about the survey you did in Netherlands very interesting, but as this discussion focuses more on page creators, I wonder how well the data reflects such a more engaged group of people. Also I feel that the example of Dutch wikipedia is of course very important, bearing in mind it is the third largest wikipedia, even bigger than German wikipedia. However my concern is that we should also be considering a variety of circumstances: - Chinese https://en.wikipedia.org/wiki/Chinese_language (15th), - Norwegian (Bokmål) https://en.wikipedia.org/wiki/Norwegian_%28Bokm%C3%A5l%29_language (19th) and Norwegian (Nynorsk) https://en.wikipedia.org/wiki/Norwegian_%28Nynorsk%29_language (48th) - Swahili https://en.wikipedia.org/wiki/Swahili_language (93rd) an official language in three different countries If we are thinking in terms of more generic usability and the unfolding role of Wikidata in relationship to the variety of languages which will increasingly come to use it, then I feel we should be sketching out a broader picture. I hope that makes my thinking clearer. all the best Fabian Tompsett, Volunteer Support Organiser, Wikimedia UK, Address: 56-64 Leonard St, Shoreditch, London EC2A 4LT Phone:020 7065 0990 *Mobile: *07840 455 746 Wikimedia UK is a Company Limited by Guarantee registered in England and Wales, Registered No. 6741827. Registered Charity No.1144513. Registered Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT. United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia movement. The Wikimedia projects are run by the Wikimedia Foundation (who operate Wikipedia, amongst other projects). Visit http://www.wikimedia.org.uk/ and @wikimediauk On 29 January 2015 at 14:23, Jane Darnell jane...@gmail.com wrote: Hi Fabian, I think your logic is flawed, as I believe most of the Welsh contributors probably also read the English Wikipedia. This will be true for many languages that are closely related, such as Dutch and Afrikaans, but there is much less cross reading between English and languages that are located far from English-speaking countries. Hungarian and other languages will show less cross reading. In the Netherlands, we held a user survey in 2013 that was very enlightening as it showed us some interesting data that we didn't know. One of the most surprising was that most people in the Netherlands were unaware that Wikipedia is written by volunteers (we are holding a PR campaign this year that just addresses this specific point). The other very interesting and surprising thing we learned was that most people were unaware that Wikipedia was an American invention. They assumed it was Dutch. I personally infer from this the following two things: 1) Dutch people are unaware that Wikipedia exists in other languages, especially since Google's knowledge graph is able to give them enough meta data in web searches such that they need to click on a Wikipedia page less and less for basic information on any specific subject. 2) Dutch people are unaware that the servers of the Dutch Wikipedia are hosted in the U.S. and are therefore abiding by the rules in the U.S. legislative territory. We know from earlier tests with users that Donate buttons and other links appearing on the left seem to be invisible to most users. It is based on all of these things that I made that comment. The click-through data on the interwikis would be very interesting to see. Best, Jane On Thu, Jan 29, 2015 at 12:26 PM, Fabian Tompsett fabian.tomps...@wikimedia.org.uk wrote: I for one would bet that the number of page creators in any given Wikipedia that know enough to even look at the left side of the page is quite small. In my experience, most page creators are unaware that Wikipedia exists in any language but their own mmm, an interesting perspective, but do we have any data? As we are in to speculation here, I would hazard a guess that the smaller the Wikipedia the more likely
Re: [Wikidata-l] Impossible to add interwiki links
Hi Fabian, I think your logic is flawed, as I believe most of the Welsh contributors probably also read the English Wikipedia. This will be true for many languages that are closely related, such as Dutch and Afrikaans, but there is much less cross reading between English and languages that are located far from English-speaking countries. Hungarian and other languages will show less cross reading. In the Netherlands, we held a user survey in 2013 that was very enlightening as it showed us some interesting data that we didn't know. One of the most surprising was that most people in the Netherlands were unaware that Wikipedia is written by volunteers (we are holding a PR campaign this year that just addresses this specific point). The other very interesting and surprising thing we learned was that most people were unaware that Wikipedia was an American invention. They assumed it was Dutch. I personally infer from this the following two things: 1) Dutch people are unaware that Wikipedia exists in other languages, especially since Google's knowledge graph is able to give them enough meta data in web searches such that they need to click on a Wikipedia page less and less for basic information on any specific subject. 2) Dutch people are unaware that the servers of the Dutch Wikipedia are hosted in the U.S. and are therefore abiding by the rules in the U.S. legislative territory. We know from earlier tests with users that Donate buttons and other links appearing on the left seem to be invisible to most users. It is based on all of these things that I made that comment. The click-through data on the interwikis would be very interesting to see. Best, Jane On Thu, Jan 29, 2015 at 12:26 PM, Fabian Tompsett fabian.tomps...@wikimedia.org.uk wrote: I for one would bet that the number of page creators in any given Wikipedia that know enough to even look at the left side of the page is quite small. In my experience, most page creators are unaware that Wikipedia exists in any language but their own mmm, an interesting perspective, but do we have any data? As we are in to speculation here, I would hazard a guess that the smaller the Wikipedia the more likely it is that page creators are aware that there are wikipedias in other languages. So for example on Welsh Wicipedia https://cy.wikipedia.org/wiki/Hafan I would guess something close to 100% of page creators are aware of English Wikipedia. https://cy.wikipedia.org/wiki/Hafan all the best Fabian Tompsett, Volunteer Support Organiser, Wikimedia UK, Address: 56-64 Leonard St, Shoreditch, London EC2A 4LT Phone:020 7065 0990 *Mobile: *07840 455 746 Wikimedia UK is a Company Limited by Guarantee registered in England and Wales, Registered No. 6741827. Registered Charity No.1144513. Registered Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT. United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia movement. The Wikimedia projects are run by the Wikimedia Foundation (who operate Wikipedia, amongst other projects). Visit http://www.wikimedia.org.uk/ and @wikimediauk On 29 January 2015 at 11:00, Jane Darnell jane...@gmail.com wrote: +1 on collecting the click data! I for one would bet that the number of page creators in any given Wikipedia that know enough to even look at the left side of the page is quite small. In my experience, most page creators are unaware that Wikipedia exists in any language but their own On Thu, Jan 29, 2015 at 11:49 AM, Federico Leva (Nemo) nemow...@gmail.com wrote: Daniel Kinzler, 29/01/2015 11:24: As far as I recall, there is some very silly technical reason that this is not easy to change at all. We tried to do this right when we introduced the other widget, of course. I don't recall what exactly the problem was though, and it might have been fixed since. Worth another look... I see. I said should (ought to?). :P Is there a phabricator ticket for this? Lydia Pintscher, 29/01/2015 11:31: The issue with doing this when there are several sitelinks is that people will unknowingly merge items this way that should not be merged. That'd be a huge pita. We'll need to put some good thinking into this still. I have no good solution right now. This is a non-issue IMHO, as soon as my suggestion at https://phabricator.wikimedia.org/T85776 / https://phabricator.wikimedia.org/transactions/detail/PHID- XACT-TASK-zi2igyjlfqasknq/ is implemented. This should be very easy to change. The dialog could then contain a link to the Wikidata item for the case when one wants to edit or remove links, until such a feature is added to the dialog itself. Showing the dialog and requiring people to click would probably annoy people for having to click one additional time? Especially if their intention is clear. There is already a generic Wikidata link in the sidebar which users can click; having two of them is a waste. Also, the drawback is much
Re: [Wikidata-l] Example of Wikipedia infobox generated from Wikidata?
Magnus' tool called PrepBio will create a brief or extended biography infobox for use on the English Wikipedia. I would really like to see a PrepPlace tool developed that does the same thing for locations. http://tools.wmflabs.org/magnustools/prepbio.php On Thu, Jan 15, 2015 at 1:29 AM, ja...@j1w.xyz wrote: I read that some Wikipedia infoboxes are generated from Wikidata. Can someone please point me to an example of this? Thanks, James Weaver ___ 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] Conflict of Interest policy for Wikidata
I can't imagine anyone reading these mails who has never hit the edit button at least once on some random Wikimedia project. Could it possibly be entertaining otherwise? For the sorry few who need to read these mails for their work (whatever that may be), they have my sympathy. On Sun, Jan 4, 2015 at 11:36 AM, John Lewis johnflewi...@gmail.com wrote: Love this thread - Happy New Year, to all of you TOU groupies! I bet half of the lurkers on this list never even clicked on the meta page Half of the lurkers on this list probably don't even edit Wikimedia. John Lewis -- John Lewis ___ 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] Conflict of Interest policy for Wikidata
Lydia, I believe you meant to say override, not overwrite. Freudian slip, but I found it rather funny (and could think of multiple instances where that might even be true). Jane 2015-01-03 12:46 GMT+01:00 Lydia Pintscher lydia.pintsc...@wikimedia.de: On Fri, Jan 2, 2015 at 11:15 AM, Flaken Aldnonymous aldnonymo...@yahoo.com wrote: On [[m:TOU]] already explain what you should do. That is the default for Wikimedia projects. An individual project can overwrite that if wanted. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Queries related question : relationship beetween queries
Actually, I would posit that the inverse of that statement is true On Fri, Jan 2, 2015 at 10:26 AM, Thomas Douillard thomas.douill...@gmail.com wrote: Generated a grammatically correct same meaning sentence in all language in the planet automatically is way more difficult than finding a user that will write a template is his 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] Queries related question : relationship beetween queries
not to mention the simple fact that Wikidata has way more Flemish painters than are in the English Wikipedia's list, for example just look at this query for painters born in Antwerp: http://tools.wmflabs.org/autolist/autolist1.html?q=claim%5B106%3A1028181%5D%20and%20claim%5B19%3A12892%5D On Thu, Jan 1, 2015 at 1:29 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, For the list Flemish surrealist painters there is no intersection between Flemish painter or with Surrealist painters. That list is in and of itself an article in a Wikipedia. In Wikidata you want the two properties separate so that you can be surprised with who fits in a list. It is not deterministic. Thanks, GerardM On 1 January 2015 at 13:23, Thomas Douillard thomas.douill...@gmail.com wrote: I don't think so. There always be intersections beetween lists. One of the Flemish painter might also be in the list of surrealist painters. 2014-12-30 14:41 GMT+01:00 Jane Darnell jane...@gmail.com: I would suggest you are thinking from the wrong perspective. Think specific, and work your way from there. On the English Wikipedia, there are tons of lists which each have their own set of rules for list items. This makes a specific query much easier, tied to the list item on Wikidata. For example, take a look at this list which uses a motley crew of references to keep redlinks from being deleted: https://en.wikipedia.org/wiki/List_of_Flemish_painters Wikidata has well filled items for most of those redlinks, for which articles could be created using the PrepBio tool: http://tools.wmflabs.org/magnustools/prepbio.php On Tue, Dec 30, 2014 at 1:57 PM, Thomas Douillard thomas.douill...@gmail.com wrote: Hi, I got an open question about Wikidata concepts, partly related to the idea of selecting a templates wrt. a query for placeholder articles. One question about this idea is : what to do when several templates are possible for an item, for example the item with no article is in the result set of several queries associated with article stubs templates, say: * the query anything, that could be associated with a totally generic templates that shows a Wikibase page like article templates that shows all the claims about this item * a more specific query living organism * another even more specific query like animal * ... In this example each more specific query results is obviously a subset of each more generic one. In such cases it could be useful to choose the template of the most specific one. In the same spirit of the subclass of property we can create (or reuse it) for the queries. But as no property has in Wikibase itself a meaning, this means the choice of the template would not be possible using raw Wikibase concepts, which partly breaks the interests of the idea. Any thoughts about this problem ? Cheers, TomT0m ___ 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 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
Redirects are great! They belong locally though and should not be attempted cross-wiki On Wed, Dec 10, 2014 at 1:50 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The only reason why Wikidata and Reasonator are not found is because this is not configured. yes you may think as you like and for how long as you like about Wikipedia but that does not imply anything when it is not about Wikipedia. Redirects are evil. Thanks, GerardM On 10 December 2014 at 13:10, James Heald j.he...@ucl.ac.uk wrote: I think your point is of limited relevance, Gerard. * If somebody searches on Wikidata or Reasonator, they will be taken to the Wikidata item we have -- so this proposal will make no difference. * If somebody searches on xx-Wikipedia, and if there is already a redirect, they will be taken to the redirected item, just as they are at the moment -- so this proposal will make no difference. * If somebody is reading an article on yy-Wikipedia, and wonders how the material is covered on xx-Wikipedia, they will now be able to see that there is not a directly equivalent item, but it is handled by a redirect. That is information we currently do not show them, that may in many cases be useful -- eg it prompts them to look to see whether xx-Wikipedia's existing coverage is adequate, or whether xx-Wikipedia would benefit from a new article being published. It's worth noting, if they're looking at yy-Wikipedia, they will still be able to see a link to Wikidata (which could/should be made more prominent, by moving it to the in other projects part of the sidebar), and from the Wikidata item they can navigate to Reasonator, just as they do at the moment. * The only real difference is for people searching in xx-Wikipedia, if that get taken to new redirects that didn't previously exist, but that permitting this has encouraged people to create. Your complaint seems to be that they aren't offered a Wikidata/Reasonator link instead. But then, they're not offered a Wikidata/Reasonator link at the moment -- so really nothing is being loss. Instead, I take what you're saying as a feature request: if somebody is searching on xx-Wikipedia, and that search would have hits on Reasonator that are different from wherever a redirect would point to, then present those options as well. But either way, that is a future feature request, because it's not an option that people get presented with at the moment. Finally, you write that the thinking is very much Wikipedia oriented. And to an extent that is true, because this *is* about the sidelinks people see when they are browsing Wikipedia, and really it affects Wikidata hardly at all -- very little either way. But there would be one significant advantage for Wikidata, I think: If people could accurately link to redirects, I think we would have better hygiene here about what items are instances or subclasses of -- eg whether an item was for a profession/professional -- because there would no longer be such a motivation to something that many people do really quite often now -- namely to lump together articles of different kinds from different Wikipedias, purely for the sake of preserving sitelinks, rather than to much more clearly define an item and its true sublinks to strictly reflect what it is an instance of. That is a current problem that I think facilitating sitelinks to redirects would I hope help ease. All best, James. On 10/12/2014 10:11, Gerard Meijssen wrote: Hoi, Maybe. At the same time other people are equally opposed to what you favour so much. Your approach is one that is very much Wikipedia oriented. It is not something that makes sense with a more Wikidata oriented approach. The point is that quite often Wikidata is more informative than what Wikipedia has to say in these redirects. It is also much better to link to Reasonator to inform you about missing information than referring to disambiguation pages or use redirects. Really your approach does not consider the relevance the information Wikidata and Reasonator holds. Thanks, GerardM On 10 December 2014 at 10:06, James Heald j.he...@ucl.ac.uk wrote: The trouble is that a particular individual may have many memberships and affiliations -- some perhaps to small units like bands; but some to larger groups like clubs, or artistic movements. It's better to let humans decide where is the best place in a particular language to redirect people looking for information about a particular person or thing. And that then also covers hatmakers/hatmaking, or Bonnie and Clyde, and every other example which is not just about a member of bands. This discussion has been going on for two years now, and every time it has come up (which has been many times -- at least a dozen now?), there have been an overwhelming number of people supporting allowing and marking site-links to redirects. It's now time to
Re: [Wikidata-l] weekly summary #130
Thanks! I really like seeing the q number in the global usage section on commons Sent from my iPad On Oct 27, 2014, at 5:24 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: Hey folks :) Here is your weekly summary for the past week around Wikidata. Other Noteworthy Stuff The Wikidata Game now has a 'Commons Categories' game Did you know? Newest properties: At the Circulating Library ID, MacTutor id (biographies), allmovie identifier, number of survivors, given name version for other gender, name in native language, tempo marking, manifestation of, zbMATH author ID, Executive Order number Development Made significant performance improvements (to be rolled out next week) Worked on usability improvements to the editing of sitelinks When you link to an image on Wikimedia Commons in a statement it will now show up in “global usage” there. Made the phpunit tests for Wikibase much faster Wikibase phpunit tests on travis pass with hhvm now Fixed label/description uniqueness constraint checks Work on entity usage tracking Year formatter now shows the year instead of the unformatted ISO string in case of a precision mismatch Diff and old revision pages don’t run the JavaScript UI any more, should be much faster now Introduced a Changers concept to the JavaScript frontend, wrapping the API and entityStore functionality Identified issue causing content in the old serialization format to be included in XML dumps See current sprint items for what we’re working on next. You can see all open bugs related to Wikidata here Monthly Tasks Hack on one of these. Help fix these items which have been flagged using Wikidata - The Game. Help develop the next summary here! Contribute to a Showcase item Anything to add? Please share! :) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
OK Andy Gerard, cut it out! I like both of you, but we will never fix things this way. As you correctly point out Gerard, Wikipedians should spend more time adding labels and aliases to existing items and creating new items on Wikidata rather than just making redirects on Wikipedia. As you correctly pointed out Andy, it IS physically possible to include categories and templates on redirects (but if you do this in the way Gerard suggests than it is a small step to create a stub that deserves a sitelink from Wikidata). More Wikidatans should probably spend more time fixing and splitting Wikipedia articles, but since the majority of Wikpedians don't understand Wikidata at all, I think this should NOT be done unless you are already a Wikipedian in good standing. Personallly I think it is ridiculous that Robert Havell, Jr. does not have his own Wikipedia article and is only included in a bundled-up version of a few members of his extended family. Clearly, Derric's comments indicate that this email thread has not helped matters any. I am just as frustrated as Gerard and don't know how to explain why sitelinks to redirects are A REALLY BAD THING because to me it is so obvious. On Wed, Oct 22, 2014 at 7:43 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, When a position is taken that is manifestly wrong, it is worse to desist. Andy I like you too but calling someone a dick because he does not agree with you and calls bullshit on the points taken, the examples supplied is not in the best tradition of our projects. Wikidata is NOT there to serve the English Wikipedia at the expense of its own integrity. A wish has been formulated to support redirects by WIkipedians while Wikidata has been EXPLICITLY designed NOT to support redirects but more importantly parts of articles. If a project does not have or want to have an article on a given subject, Wikidata can provide information when used in combination with the Reasonator. Articles are about a subject and CONSEQUENTLY they should have categories and info boxes that are in line with the subject of the article. The ARTICLE 2014 ISIL beheading incidents http://www.wikidata.org/wiki/Q17985279 for instance is NOT about a human and it should NOT have a category deaths in 2014 or any other information that is particular to one person. The same is true for Death of Alice Gross; it is NOT about Alice Gross. When an article is just text and nobody cares about such consistencies, fine. However, you want articles like this linked and someone else is to clean up such mess. This prevents automated processes, it is bad practice and it is part of the same practice/school of thought whereby we are to have redirects ... Hell no! Please reconsider your arguments and please do not be a dick yourself.. Thanks, GerardM On 21 October 2014 21:21, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 21 October 2014 07:13, Gerard Meijssen gerard.meijs...@gmail.com wrote: If this Jackson Douglas is the best that you can do, you destroyed the argument that it has merit. Gerard, I like you; but you're being a dick. Please desist. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
No James, redirects do not have templates or categories. Back to the case of the African plum, I have created an English label for the Wikidata item, so that when I seach the English Wikipedia and choose the option everything, this Wikidata item will show up: https://en.wikipedia.org/w/index.php?title=Special%3ASearchprofile=allsearch=african+plumfulltext=Search If I had created a redirect in the English Wikipedia for African plum to Plum, than of course that is what would come up. In this case the search is giving me more precise information. The problem with redirects when they aren't used as synonyms is that they direct readers to something else that they might or might not recognize as being something else. Within one project this may not be a problem, but going from Korean into English or the other way around you could become easily misled by the redirect rabbit-hole. On Sun, Oct 19, 2014 at 10:55 PM, James Heald j.he...@ucl.ac.uk wrote: But Gerard templates and the categories used on the *redirect* will be specific to the redirect, so can draw quite happily from the item corresponding to the redirect. And templates and categories used on the *article* will be specific to the article, so can draw quite happily from the item corresponding to the article. I don't see where the problem is ? -- James. On 19/10/2014 21:44, Gerard Meijssen wrote: Hoi, I am very comfortable with items not having articles. I am very comfortable with items that have one or more articles. When you suggest that Wikidata items link to redirects, there are many assumptions that break down. You cannot longer assume what the templates, the categories are about. They are NOT necessarily about the article, they may be about all kinds of everything. The notion that Wikidata is subservient to Wikipedia can be considered but WHAT Wikipedia and why should Wikidata be subservient to the English Wikipedia ? Some people representing the English Wikipedia make demands however, Wikidata can provide services the English Wikipedia is not able to provide. Things like providing search results based on information from Wikidata. Why is this not even considered? Thanks, GerardM On 19 October 2014 18:54, rupert THURNER rupert.thur...@gmail.com wrote: david, i think you hit the major point here. at the end of the day it is a document management problem, and the idea to recombine contents is followed by some extensions, like books extension. would it make sense to use wikidata for such tasks as well? i am not convinced that it makes sense to go onto a sentence level, but paragraphs do imo make sense. alone because e.g. the german wikipedia often stores an item in a paragraph, what is stored in an article in the english wikipedia. redirects are managed in de:wp, and there is no notion of storing wrong redirects to cover typo's. of course there are some wikidata purists, like jane and gerard, who seem to be a little imprisoned in the original semantic mediawiki notation that every entry needs to be an article. one may even consider this opinion as correct in a greenfield approach where the contents is created from scratch. but - unfortunately this is not the case. wikidata came after wikipedia, and i consider it a fundamental failure of wikidata to not address the issue. rupert On Sat, Oct 18, 2014 at 1:03 AM, David Cuenca dacu...@gmail.com wrote: As Wikidata grows this problem will become more significant. Using redirects doesn't seem a sustainable approach, but it will be hard to find better ones considering the number of people involved and the investment in the current platform. The biggest challenge will be to convince Wikipedians to break free of the article box. There is no reason to limit oneself to articles when there can be smaller building blocks that can be recombined in different articles with as much detail level as needed. Maybe after Commons there should be also a Wikidata for Wikipedia content, where each article section or sentence is represented by an item that can be displayed in several articles or translated into different languages. Cheers, Micru On Fri, Oct 17, 2014 at 8:55 PM, Derric Atzrott datzr...@alizeepathology.com wrote: Thought I'd throw in my opinion on the matter. After reading this thread I think that I agree with the folks who believe that Wikidata items should be able to specify a Wikipedia article that is a redirect as a sitelink to Wikipedia. Its by no means an ideal solution, but I can't see any problems that it causes and I do see problems that it fixes. If there are problems /for Wikidata/ that allowing Wikidata items to link to Wikipedia redirects causes, I would be happy to hear them. I imagine someone likely tried to point some out, but I just didn't quite grasp them. Thank you, Derric Atzrott ___ Wikidata-l mailing
Re: [Wikidata-l] Sitelinks to Redirects
My comments inline: On Fri, Oct 17, 2014 at 2:00 PM, Joe Filceolaire filceola...@gmail.com wrote: Having sitelinks to redirects in my wikipedia makes it easier for other wikipedias to link to my wikipedia. No, it only makes it easy for other wikipedias to link to redirects in your wikipedia, which begs the question why you feel this is useful. If I dont care about that then I may delete those redirects from my wikipedia and the sitelink to my wikipedia will go too. No, whether or not you care about them is irrelevant and they are not an issue, but ALL sitelinks on Wikidata to redirects on Wikipedias should be deleted, including and especially those sitelinks to redirects in Wikidata items that do not contain any other statements whatsoever, such as this one: https://www.wikidata.org/wiki/Q12817561 Hopefully someone will create a bot to do this. The wikipedias have the final say on what they do and do not include. Yes ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
this redirects on client wikis en masse, and site-linking them. This would solve a huge number of issues we currently have, where wiki A has lots of little articles, whereas wiki B has the same content all in sections of one article; or where wiki A and wiki B have chosen different primary items for their treatment of a field. (For example: the profession 'hatmaker' or the activity 'hatmaking'). Allowing and encouraging sitelinks to redirect is the key to keeping a clean item structure on Wikidata, while still connecting readers to the most relevant pages in their preferred alternative languages. -- James. On 14/10/2014 21:00, Jane Darnell wrote: nope On Tue, Oct 14, 2014 at 6:23 PM, Smolenski Nikola smole...@eunet.rs wrote: Citiranje Jane Darnell jane...@gmail.com: 2) There is no way of making an interwikilink for a redirect, and the German Wikipedia's afrikanische Pflaume is currently a redirect to Prunus You should still be able to make an interwiki link for a redirect the old way, are you not? ___ 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Sitelinks to Redirects
I don't understand why you can't make an item for each character or each person in a band. As long as you have a valid reference (IMDb? Book? out of my league here) you can make an item for anything On Thu, Oct 16, 2014 at 12:45 PM, Jan Dudík jan.du...@gmail.com wrote: There is one big field, where redirects make sense: lists (of characters) or members of bands *Rob Bourdon (Q19205) have article in 38 languages. There is also part of article de:Linkin_Park, which is about him and [[de:Rob Bourdon]] is redirect. *Character X from tv series Y is not notable enough to have separate article, but it should have own item on wikidata. And there is article about him in some small wiki. When you search , you found that there is one article, but fifteen redirects to section (List of Y characters#X) *Fred Weasley (Q13359612) have one sitelink (to redirect), but informations are in en, cs, fr, es, it, pt, pl, da and others too. But when I want to find relevant articles, I must try each language separate. With alowed redirects, I find it. JAnD 2014-10-16 11:06 GMT+02:00 Jane Darnell jane...@gmail.com: With a view to supporting mobile, why bundle concepts needlessly into large articles? Why not split them out and use the typical Wikipedia blue link methodology to link them together? Some of the English Wikipedia articles are very unwieldy on mobile and you need to scroll through lots of stuff to get the information you are looking for. In the case you are describing however, I find the article rather short and I can't even see any reference to the occupation of hatmaker at all unless you are referring to a list of notable hatters and milliners (which also seems rather short). On Thu, Oct 16, 2014 at 10:40 AM, James Heald j.he...@ucl.ac.uk wrote: We have the relevant information on :en in hatmaking. Why create a stub? Why require the duplication? Surely it is for client wikis to decide how they want to treat topics, either in a big omnibus article, or in a lot of little articles -- that is a decision for them. But we should be helping readers moving from one language to another to find the nearest equivalent in that language -- no matter whether in that language it is a small part of a large article, or a separate article in its own right. -- James. On 16/10/2014 09:29, Jane Darnell wrote: James, I totally agree with Gerard and I totally disagree with you. The fact that the English Wikipedia does not have an article on hatmaker is not something that Wikidata should support, and the energy you are wasting with your talk about redirects could better be spent on making a stub for hatmaker on the English wikipedia. Jane On Thu, Oct 16, 2014 at 9:34 AM, James Heald j.he...@ucl.ac.uk wrote: I am sorry, Gerard, you seem to have fundamentally misunderstood what I am saying. To be clearer: * Noting that a link goes to a redirect is a feature of the *sitelink* not the item. * It is no more Wikipedia centric than noting that a link goes to a featured article in some language, or any other badge. I'm not proposing items be introduced for new things that do not exist Let's take an example, from Project Chat recently. * Hatmaking is a real-world concept that exists. We have an article on it in English Wikipedia: https://en.wikipedia.org/wiki/Hatmaking https://www.wikidata.org/wiki/Q663375 * Hatmaker is a real-world concept that exists. We have an article on it on lots of Wikipedias. https://www.wikidata.org/wiki/Q18199649 The two concepts are not the same. One is a skill, the other is an occupation. They have a P425 / P na relationship. It therefore would not make any sense to add Hatmaking as a label to the Hatmaker item. At the moment, there is no sitelink to :en: defined for Hatmaker. What would make sense would be to sitelink to the redirect page https://en.wikipedia.org/w/index.php?title=Hatmakerredirect=no with a badge, noting that this was a sitelink to a redirect page. At the moment, there is no sitelink to wikis other than :en: defined for Hatmaking What would make sense would be to create redirects on these wikis, linking to their articles on Hatmaker, and then add sitelinks to the Hatmaking item, pointing to these redirects in each of the languages. To give another example: On Commons, we have a creator page for the engraver Daniel Havell, https://commons.wikimedia.org/wiki/Creator:Daniel_Havell which ought to be made to draw from a Wikidata item for the engraver. (cf https://www.wikidata.org/wiki/Template:Creator/wrapper/test for tests) On en-wiki, there is no separate article for Daniel Havell. Instead there is a redirect, https://en.wikipedia.org/w/index.php?title=Daniel_Havell; redirect=no, which points to a section of an article on the Havell family: https
Re: [Wikidata-l] Sitelinks to Redirects
Joe, That's actually not what I said. What I said was that we should explode all bundled concepts on Wikipedia into items on Wikidata. I did not say that we should do anything at all on Wikipedia. I am perfectly capable of keeping to the point on a Wikidata mailing list, and I believe that the explosion of data as I envision it on Wikidata would be helped by using Wiktionary. Jane On Thu, Oct 16, 2014 at 4:13 PM, Joe Filceolaire filceola...@gmail.com wrote: Jane I disagree. Sitelinks to wikipedia redirects are useful because they help one wikipedia get useful links to other wikipedias even where the structure of the wikipedias is different, without having to force the various wikipedias to follow the same structure. Your comment that wikipedias should change their policies and have one concept per article may be correct but it is a comment on wikipedia policy and should be addressed to the wikipedias. This list is for wikidata. Note that we also have wikidata redirects. These should be created whenever we merge two wikidata items so that external links to the 'merged' item will automagically link to the combined item so that wikidata urls are stable and persistent. Joe On Thu, Oct 16, 2014 at 2:19 PM, Jane Darnell jane...@gmail.com wrote: Redirects are indeed cheap on Wikipedia, and I have created tons of them on the English Wikipedia. I am a big fan of redirects, but only on Wikipedia. Redirects are not useful for Wikidatans or for Wikipedians who become Wikidatans. Period. On Thu, Oct 16, 2014 at 2:57 PM, James Heald j.he...@ucl.ac.uk wrote: Redirects are cheap. On en-wiki the creation of new redirects is positively encouraged. There is also a category on en-wiki, Redirects with possibilities for redirects that have the potential to be built into stand-alone articles. I would have thought the (possibly automated) creation of large numbers of redirects similarly on other language wikis would be something that might be rather welcome. Remember also that it's not changing the item structure on Wikidata, just what it can point to on the client wikis. -- James. On 16/10/2014 13:44, P. Blissenbach wrote: While I agree with the idea of linking between languages including links to related topics, I am a bit hesitant to use Wikidata for it now and in the suggested fashion. Rather let us try to find a more generalized approach which not only serves Wikipedias but all parties interested in finding related topics. Then a search in WP can, in addition to its current hits, show a list of related topics which are determined semantically rather then by spelling. Also I doubt that WP communties will tolerate the abundance of redirects that are likely going to be necessary if you really make all the ones that are possibly useful. Purodha James Heald j.he...@ucl.ac.uk writes: We have the relevant information on :en in hatmaking. Why create a stub? Why require the duplication? Surely it is for client wikis to decide how they want to treat topics, either in a big omnibus article, or in a lot of little articles -- that is a decision for them. But we should be helping readers moving from one language to another to find the nearest equivalent in that language -- no matter whether in that language it is a small part of a large article, or a separate article in its own right. -- James. On 16/10/2014 09:29, Jane Darnell wrote: James, I totally agree with Gerard and I totally disagree with you. The fact that the English Wikipedia does not have an article on hatmaker is not something that Wikidata should support, and the energy you are wasting with your talk about redirects could better be spent on making a stub for hatmaker on the English wikipedia. Jane On Thu, Oct 16, 2014 at 9:34 AM, James Heald j.he...@ucl.ac.uk wrote: I am sorry, Gerard, you seem to have fundamentally misunderstood what I am saying. To be clearer: * Noting that a link goes to a redirect is a feature of the *sitelink* not the item. * It is no more Wikipedia centric than noting that a link goes to a featured article in some language, or any other badge. I'm not proposing items be introduced for new things that do not exist Let's take an example, from Project Chat recently. * Hatmaking is a real-world concept that exists. We have an article on it in English Wikipedia: https://en.wikipedia.org/wiki/Hatmaking https://www.wikidata.org/wiki/Q663375 * Hatmaker is a real-world concept that exists. We have an article on it on lots of Wikipedias. https://www.wikidata.org/wiki/ Q18199649 The two concepts are not the same. One is a skill, the other is an occupation. They have a P425 / P na relationship. It therefore would not make any sense to add Hatmaking as a label to the Hatmaker item. At the moment, there is no sitelink to :en: defined for Hatmaker. What would make sense would be to sitelink to the redirect page
Re: [Wikidata-l] Sitelinks to Redirects
Purodha, Redirects are cheap - so cheap in fact, that they take up more space when you delete them, 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 On Thu, Oct 16, 2014 at 6:09 PM, P. Blissenbach pu...@web.de wrote: I do not mind having huge numbers of redirects at all, but you must be aware that there are wikipedias the powers of which will stubbornly and customarily delete such redirects when you create them. So that cannot be a solutiion for all. Purodha ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] [Multimedia] Inclusion criteria for Wikidata items for paintings, engravings, illustrations, manuscript folios, photographs, old postcards, etc ?
@Daniel - the further back you go, the more notable the engravings in books become (see for example the whole family of engravings and copies thereof for the 17th-century Counts of Holland series) and sometimes engravings from books are the source for paintings. @Nemo - I don't follow your thinking on this one - when you say new Commons pages, do you mean new Wikidata items based on Commons categories? I don't see a problem with that. Things that have needed a category on Wikimedia Commons are probably notable enough for Wikidata (though I can think of some non-notable categories like 1610 engravings that would be unnecessary on Wikidata) On Tue, Oct 14, 2014 at 8:39 AM, Federico Leva (Nemo) nemow...@gmail.com wrote: In my opinion how many items will X add is a false problem. If p.a. we moved file categories to subpages as we do on templates, we'd have 20 millions new Commons pages: but the question would be, are they as accessible as they were before? Similarly, the only danger is when items' statements are not transcluded outside Wikidata. When stuff is in use on projects, as for authority codes; and when it can be edited in-place, as we all do for sitelinks and ru.wiki does for much more: then there is nothing I worry about. Nemo ___ 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] Users do understand Wikidata less than before
There are multiple issues with linking the German Wikipedia's afrikanische Pflaume to the French Wikipedia's safou: 1) A tree can only interwikilink to a tree or combined article on the tree + fruit and a fruit can only interwikilink to a fruit or a combined article on the tree + fruit (this is the single vs. multiple concepts problem Gerard refers to) 2) There is no way of making an interwikilink for a redirect, and the German Wikipedia's afrikanische Pflaume is currently a redirect to Prunus On Mon, Oct 13, 2014 at 4:59 PM, rupert THURNER rupert.thur...@gmail.com wrote: On Oct 13, 2014 2:07 PM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: Am 12.10.2014 17:02, schrieb Romaine Wiki: Hello Lydia, This is a different problem from the other issue I described in an other mail. I notice two different problems that occur with the same version. One is about the workflow, one is about less experienced/less technical users have difficulties in adding site links. Linking a newly created article would be done using the add links feature at the bottom of the sidebar. That should not have changed at all in the last couple of months, as far as I know. Can you identify which change exactly is the problem, and why it is problematic? I tried to link afrikanische Pflaume to safou the fruit and got an error which was not helpful. I tried to report it here, and nobody used time to look into it. So my personal user experience degraded from usable to not usable. But I have no idea which change caused the this. Rupert ___ 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] Users do understand Wikidata less than before
nope On Tue, Oct 14, 2014 at 6:23 PM, Smolenski Nikola smole...@eunet.rs wrote: Citiranje Jane Darnell jane...@gmail.com: 2) There is no way of making an interwikilink for a redirect, and the German Wikipedia's afrikanische Pflaume is currently a redirect to Prunus You should still be able to make an interwiki link for a redirect the old way, are you not? ___ 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] Re-enable quick editing in Wikidata please
Romaine, Have you looked at quick statements to add or update information in Wikidata? It is here: http://tools.wmflabs.org/wikidata-todo/quick_statements.php Maybe this will help you do repetitive updates (you still need to build a list of something, but then you don't have to wait for Wikidata to make the update) Jane On Sat, Oct 11, 2014 at 9:22 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, What you missed is how plainly Lydia indicates that this is an in between state of affairs. Usability issues are taken seriously. You and maybe several other users are absorbed in misery. Every workflow in Wikidata is not explicitly supported. I do not discuss user friendliness, it sucks. The good thing about user interfaces and usability is that it can be worked on improved upon. The way people complain and make demands is something that is to be suffered. I do not suffer quietly I prefer not to suffer and make the best of the hand I am dealt. Thanks, GerardM On 10 October 2014 15:50, Romaine Wiki romaine.w...@gmail.com wrote: You can discuss the general user friendliness, but that is not the topic of this thread. You also miss the problem that is described. All the rest you write is not relevant here at all. There is a problem with the workflow and we (I have seen several users who complaint about it) would like that to be taken seriously. Romaine 2014-10-10 8:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com: Hoi Romaine, I am sorry but while I understand your frustration, you are not realistic and you do no justice to the situation. To start with Wikidata is not user friendly at all. It never was because development has been concentrating on basic architecture and basic functionality. At that we are still waiting for much needed basic functionality for instance statements that indicate what unit they are (kilo, meter, calories etc) and queries. When you read the replies of Lydia, it is quite plain that what we have is an intermediate step towards a different user interface. What we have now will pass. When you consider the old UI, it may have worked for you but I find it is lacking basic functionality for editors. My pet pieve is that when I add a URL for an item, it is not able to strip all the web junk away to be left with the Qnumber. Now I have to do it by hand and, I do that a lot. Some work on similar issues were done in the paper cuts. What I am looking for in the new UI is similarity with what Reasonator looks like. My motivation is that in this way it will be possible to have an overview of all the data. The data becomes informative in this way. That may not help editors much. Much of the data is entered by bots and external tools, they are likely to be affected in different ways by the continuing stream of changes as well. I am sure you have seen all the huha around Flow and the visual editor. I loathed the way people bullied their opinion on everybody else. PLEASE let us not go that way with Wikidata. Thanks, GerardM On 10 October 2014 04:20, Romaine Wiki romaine.w...@gmail.com wrote: Sorry Lydia, but I can't read that in your reply. I point on an overlooked issue with designing the current version. I see no recognition that this is an issue that is taken serious and needs to be solved. You mention that there are issues that will be solved, but the issue raised here is not taken into account (it seems). You say that you will move forward. I reply on that the current design is a downfall compared with how it was. I conclude based on what I notice in the editing workflow that the change is not an improvement. In your reply you do not give the impression that the issue raised here is going to be solved, nor that you want to restore the previous workable version, so in that perspective you keep the current design which is troubling. It is a step back. If someone would ask me to put the versions in chronological order of development based on how it works for users, than the current version would come before the previous version. If the current design would have been followed by the previous design, I would have congratulated the Wikidata team with this major improvement, which makes editing Wikidata for users much easier. Are there any plans yet in what the workflow of users is restored to a workable situation? Romaine 2014-10-09 18:08 GMT+02:00 Lydia Pintscher lydia.pintsc...@wikimedia.de: On Thu, Oct 9, 2014 at 4:52 PM, Romaine Wiki romaine.w...@gmail.com wrote: Hello Lydia, I can understand that it is not restored back in the previous situation, but this is not an improvement. Editing Wikidata is made harder, more difficult, and more clumpsy. This change of a new design is counter-productive. For months we are asking people to add stuff to Wikidata if they created an article, we stop with that. We really can't explain this change. It is also counter-productive
Re: [Wikidata-l] [Multimedia] Inclusion criteria for Wikidata items for paintings, engravings, illustrations, manuscript folios, photographs, old postcards, etc ?
I think the place for all data about an image should be Wikidata. It will be trivial to update a Wikidata item with an image when that image becomes available on Commons. Until that time, the item can point to a catalog's online or offline entry where the image can be viewed. I am thinking for example of a Salvador Dali work that cannot be included on Wikipedia due to copyright constraints. In this case the catalog entry at least points the user in a useful direction On Fri, Oct 10, 2014 at 7:33 PM, James Heald j.he...@ucl.ac.uk wrote: One case that particularly comes to mind is where we have multiple different scans of the same work -- eg we have multiple (incomplete) sets of the early 1800s colour engravings from Ackermann's Microcosm of London, or Pyne's Royal Palaces, or Audubon's Birds of America etc. It seems a shame not to be able to abstract the duplicated information between different scans -- eg the creatorship, the publication history, the topic list of items depicted -- given that they are versions of the same work. However, if the different scans have been made independently, there is no chain of derivation between them. And - probably - the individual engravings would not pass WD notability, so would not have separate items, though the book they were collected in probably would. So it doesn't seem that there would be an item on which to store the data that would be common between the different versions of the image. (Similarly, multiple reproductions of the same vintage photograph, etc). Perhaps there might be a case for CommonsData items for works that belong to a sequence, where the sequence has an item on Wikidata? Or perhaps they should just have items on Wikidata? -- James. On 10/10/2014 17:08, Gergo Tisza wrote: Thanks for the pointers, James! I'll try to digest them. Our thoughts on the issue of representing relationships between works are not fully formed yet, but the current idea is loosely that * if the original work has a Wikidata item (according to whatever notability guidelines the community prefers), link to that * otherwise if it is a Commons image, link to the local data item of that image * otherwise representing the relationships in full detail is probably not that important, so it's fine to just add the authors of the originals as contributors to the CommonsData entry with some generic role such as author of a source work, without trying to represent the accurate relationship between them. So, if there is a chain of derivative of relationships between works which have Wikidata or CommonsData items, we can walk the chain upon extraction and collect the authors. Where the theoretical chain extends outside Wikidata+CommonsData, the actual (as stored in Wikibase) chain would have author information from the outlying nodes squashed into the edge nodes. On Mon, Oct 6, 2014 at 11:08 AM, James Heald j.he...@ucl.ac.uk wrote: Gergo, ___ 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] Linking to Wikipedia page using Wikidata ID
Thanks, Rexx, that is very helpful!
On Wed, Sep 3, 2014 at 2:28 PM, rexx r...@blueyonder.co.uk wrote:
The generic fetch property values that I wrote is capable of replacing
#property in a more intelligent manner - documented at:
https://en.wikipedia.org/wiki/Module:Wikidata
For simple cases though, #property will work - for example if you paste
the following into any section of an article and **preview** it, it will
return the image from Wikidata:
{{#if: {{#property:p18}} | [[File:{{#property:p18}}|thumb]] |}}
Similarly, in an infobox, just using |image = {{#property:p18}} will work
fine.
However, Wikidata can store multiple image filenames, so the question is:
how do you want to deal with those cases?
Building a Lua call to return an image or something like Noimage.svg is a
trivial job : I've made a demo module at:
https://en.wikipedia.org/wiki/Module:Sandbox/RexxS/Images
If you paste {{#invoke:Sandbox/RexxS/Images|getImage}} into
https://en.wikipedia.org/wiki/Franz_Kafka and preview it you'll see Kafka
portrait.jpg
If you paste {{#invoke:Sandbox/RexxS/Images|getImage}} into
https://en.wikipedia.org/wiki/Hangthwaite and preview it you'll see
Noimage.svg
Obviously calls can be buried inside templates to hide them from editors -
either an infobox or create a template to make the image as a thumb outside
of an infobox, etc.
--
Rexx
On 3 September 2014 12:42, Andy Mabbett a...@pigsonthewing.org.uk wrote:
On 3 September 2014 04:51, Jane Darnell jane...@gmail.com wrote:
I would like the same sort of thing for use on the English Wikipedia for
pictures, so for example if you link to the Wikidata item image
property and
this is filled with a value, it will present the image that is on
Wikidata,
and if not, will present an alternate such as [1]. Has anyone built
such a
thing?
[1] https://commons.wikimedia.org/wiki/File:Noimage.svg
No, but people have written templates that pull in other Wikidata
values, so it's certainly possible.
I'm blind-copying this to someone who may be able to help.
--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Linking to Wikipedia page using Wikidata ID
I just created this on Wikidata here, but the list order is out of whack: https://www.wikidata.org/wiki/Talk:Q17616737 On Wed, Sep 3, 2014 at 7:42 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 3 September 2014 04:51, Jane Darnell jane...@gmail.com wrote: I would like the same sort of thing for use on the English Wikipedia for pictures, so for example if you link to the Wikidata item image property and this is filled with a value, it will present the image that is on Wikidata, and if not, will present an alternate such as [1]. Has anyone built such a thing? [1] https://commons.wikimedia.org/wiki/File:Noimage.svg No, but people have written templates that pull in other Wikidata values, so it's certainly possible. I'm blind-copying this to someone who may be able to help. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Linking to Wikipedia page using Wikidata ID
I would like the same sort of thing for use on the English Wikipedia for pictures, so for example if you link to the Wikidata item image property and this is filled with a value, it will present the image that is on Wikidata, and if not, will present an alternate such as [1]. Has anyone built such a thing? [1] https://commons.wikimedia.org/wiki/File:Noimage.svg On Fri, Aug 29, 2014 at 3:57 AM, David Cuenca dacu...@gmail.com wrote: Hi Nick, I have opened this bug report where you can subscribe or add your use case (if you think my suggestion is not appropriate): https://bugzilla.wikimedia.org/show_bug.cgi?id=70159 There is also this related enhancement proposal for error handling: https://bugzilla.wikimedia.org/show_bug.cgi?id=70127 Regards, Micru On Thu, Aug 28, 2014 at 2:08 PM, Nicholas Humfrey nicholas.humf...@bbc.co.uk wrote: Fantastic, thanks! Could you put linking to the user's preferred language (Accept-Language header?) on the backlog? nick. From: David Cuenca dacu...@gmail.com Reply-To: Discussion list for the Wikidata project. wikidata-l@lists.wikimedia.org Date: Thursday, 28 August 2014 12:59 To: Discussion list for the Wikidata project. wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Linking to Wikipedia page using Wikidata ID Hi Nick, You are lucky, that feature has been released this week: https://www.wikidata.org/wiki/Special:GoToLinkedPage For instance https://www.wikidata.org/wiki/Special:GoToLinkedPage/enwiki/Q732383 Cheers, Micru On Thu, Aug 28, 2014 at 12:52 PM, Nicholas Humfrey nicholas.humf...@bbc.co.uk wrote: Hello, We have been working on associating every episode of BBC Desert Island Discs to a Wikipedia page about that person. Example: http://www.bbc.co.uk/programmes/p0093x3l http://en.wikipedia.org/wiki/David_Croft https://en.wikipedia.org/wiki/David_Croft http://www.wikidata.org/wiki/Q2072654 https://www.wikidata.org/wiki/Q2072654 Since we created some of the links to Wikipedia, those pages have changed into disambiguation pages. Is it possible to link to a Wikipedia page using the Wikidata ID, via some kind of redirect URL? Thus ensuring that we continue to link to the correct article? Ideally it would even link to the users preferred language… Thanks! nick. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non ___ 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] WikiData Categories
Q17 is Japan, and if you are interested in people from Japan for example, you can do this: http://tools.wmflabs.org/reasonator/?q=7463305 (thanks to Magnus' reasonator tool that can extract category-like info from Wikidata based on properties and qualifiers) On Fri, Jul 4, 2014 at 9:01 AM, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: Am 04.07.2014 07:10, schrieb Rohan Badlani: I had downloaded the wikidata dump from http://dumps.wikimedia.org/wikidatawiki/latest/ There is a file wikidatawiki-20140420-pages-articles-multistream-index which consists of triplets like: 537:114:Q17 I couldn't find documentation for the multistream-index format at https://meta.wikimedia.org/wiki/Data_dumps. I can't make sense of it myself offhand. Perhaps ask on the wikitech-l list. I suppose the authority on the question would be Ariel Glenn, perhaps you can get hold of him on IRC. Note that this format is used for all wikis, so it will not contain anything that is specific to Wikidata. It would be the same for Wikipedia. If you figure it out, please add the info to https://meta.wikimedia.org/wiki/Data_dumps! which I interpreted as following: 537 - category of the topic (which I am unable to find. I want the details of this item) It's not a category. Wikidata doesn't use MediaWiki's Category feature for data items at all. Wikipedia does, but there pages generally have multiple categories, identified by name, not a numeric ID. If you want to build a classification graph of the concepts in Wikidata (I'm intentionally avoiding the terms ontology and taxonomy here), you will have to go by the properties P31 (instance of) and P279 (subclass of) which are used in many (roughly half) of the data items. 114 - page_id of the item Q17. That seems to be correct. Q17 - which is the item. (JSON: https://www.wikidata.org/wiki/Special:EntityData/Q17.json) It's the page title, which, on wikidata.org, is the same as the item ID. HTH Daniel PS: we are close to providing JSON dumps on a regular basis, and also make the JSON contained in the XML dumps more readable. This will hopefully make analyzing Wikidata less painful. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Reasonator ignores of qualifier
Derric, Good luck with your edit-a-thon today [1] and it would be awesome if you could introduce Reasonator and Wikidata while discussing Wikipedia. I think it is very interesting that you just discovered Magnus through Reasonator instead of the other way around - discovering more of Magnus through his Wikipedia tools. So few people venture outside of the text-oriented Wikipedia projects, it's always refreshing to see someone in a public-facing capacity getting involved in Wikidata. [1] https://en.wikipedia.org/wiki/User:Zellfaze/Edit-a-thon_Planning Jane On Fri, Jun 13, 2014 at 5:27 PM, Derric Atzrott datzr...@alizeepathology.com wrote: FYI, I maintain Reasonator, as a click on Other/About Reasonator would have revealed... Oh, so it does. I have no idea how I missed that. I promise I did try to look around. Absolutely. Do I take it that you volunteer? The code is at: https://bitbucket.org/magnusmanske/reasonator I can add you to the codebase there, and/or make you co-maintainer on the tool. I'll volunteer at the very least I'll take a look and see if I can find what needs to be modified and then possibly submit a patch. This seems like one of those things that ought to be a pretty simple fix. No need to make me co-maintainer; I'm not looking for that kind of responsibility. Because I sure don't have the time at the moment to fiddle with some edge cases in a secondary component of one of my 50+ tools. Sorry if I came off rude or demanding. That was not my intention. With that many tools, I'm sure there are more important bugs. I just wanted to add this to the list. I'll take a look at the source and see if I can find where the issue is and how to fix it. Thank you, Derric Atzrott ___ 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] WP-geocoordinates filter by using Wikidata classes
Kolossos, Thanks for this work - it's fascinating to see the huge gaps in the data and I was wondering if maybe this reflects the work of lots of individuals who have input those properties by hand, or whether some people have enabled clever bots for their regions that other regions could reuse? (hopefully) I can see at a glance in the case of the Netherlands that not all objects in the subclass lists that are in the English (or Dutch!) Wikipedia with geo-coordinates are in the overlay maps, so I was wondering how the data got in there. I was also interested to see some slight incorrections in the coordinates for certain subclasses (probably based on some older geocoordinate conversion software for some specific database). Jane 2014-05-10 10:19 GMT+02:00, Tim Alder t...@alder-digital.de: Hello, I'm glad to can announce my last experiment working with Wikidata and Wikipedia-coordinates: http://tools.wmflabs.org/wp-world/wikidata/superclasses.php?lang=en This list shows how many objects we have in different classes and provide links to maps with only this specific class. I think it's much more useful than in the past where 80% of our coordinates were simply a landmark. Now we have maps full with roller coaster or with museums. To create this tool I used properties is instance of[1] and is subclass of[2]. To extract this properties it was necessary to use Wikidata Query. Now all classes, where an object is a member, are in a numerical array-element in the database. So with an index on this array it should have a good performances. Next steps are to try to bring more order inside this list and support the community to create more is instance of-entries in Wikidata. (Only 30% off all objects have such an entry). Greetings from Switzerland Kolossos [1]https://www.wikidata.org/wiki/Property:P31 [2]https://www.wikidata.org/wiki/Property:P279 ___ 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] weekly summary #108
Hi all, What I don't understand is the need to keep all labels blank until they are updated by hand. Especially for biographical articles, it would be nice to have original spellings of the person's name, even if it's Chinese or something else really far away from English. That might serve as a prompt to people to update the label more than blank, no? Take a look at this person: https://www.wikidata.org/wiki/Q11287651 There are so many variants in spelling of the name, but I consider them all correct, depending on the source. In the case of historical people, can't a bot go through and update the labels so that queries will return something? Anything is better than blank, I think. Jane 2014-05-05 10:57 GMT+02:00, Gerard Meijssen gerard.meijs...@gmail.com: Hoi, When the other languages box needs to become more flexible, it is a different problem that has nothing to do with the ability to understand what statements are made. At this time it is an absolute inability when there is no label in *YOUR* language. Thanks, GerardM On 5 May 2014 10:21, Daniel Kinzler daniel.kinz...@wikimedia.de wrote: Am 05.05.2014 01:35, schrieb Joe Filceolaire: I agree with Gerard that you only edit your language label in the 'label' edit box. If the label box is showing the label in a fallback language then it should be visually different - greyed out and italic for instance or like the 'edit label in English' text. If a user wants to edit other language labels then that is what the 'in other languages' boxes are for. That's probably a good approach, but would need the other languages box to become more flexible, and include aliases. It's also strange to have it visually separate from the thing you actually want to change. Not easy to get this right. -- daniel -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] When the source says the information provided is dubious
David, I assume you are referring to books. The same is true for works of art. The reason why these statements are still valuable is because it is an attribution based on grounds determined by someone somewhere and based on that loose statement alone are therefore considered of interest. You basically make a decision to include the statement or not, as you see fit. When it comes to people, one source may say Pete was the son of Klaus, while another source says Pete was the younger brother of Klaus. I think it's just a question of picking one on Wikidata to keep the family aspect of the relationship (whichever it is) intact, and sooner or later one or the other will be chosen. It's a wiki after all. Jane 2014-05-05 11:24 GMT+02:00, David Cuenca dacu...@gmail.com: Hi, I'm having some cases where a work has been attributed to an author by a source, but the source itself says this attribution is dubious, or it is contesting a previous attributions as spurious. As I see it, the rank of the statement is not deprecated (in fact it is normal or even preferred), but I have no way of representing this claim uncertainty or claim rebuttal. Is there any hidden parameter for this or should it be addressed with a qualifier? Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] When the source says the information provided is dubious
Hmm, I guess I am still not getting it - both of your examples wouldn't make it into one of my Wikipedia articles, and I would probably remove them from an existing article if I was working on it. If it's not factual enough for Wikipedia, then it's not factual enough for Wikidata. I recall a situation where painter A was documented as a pupil of painter B who according to the sources died when painter A was just a young boy of 8. Either very young children could become pupils of other painters, or the original document got painter B mixed up with someone else. Either way it is highly doubtful that painter A was strongly influenced professionally by the art of B. I would probably include this info on Wikipedia but would not bother to include it on Wikidata. 2014-05-05 14:46 GMT+02:00, David Cuenca dacu...@gmail.com: Hi Jane, No, I was not referring to books in particular, but of course it could be applied to books as well, and to works of art, and to many things in general. I agree that the statement is valuable and that it should be included, but I don't know how to represent it. Following your examples, what I am trying to represent is not what you say, but instead: a) uncertainty: it is hinted that Pete was the son of Klaus, but I have no conclusive proof b) rebuttal: Source A says that Pete was the younger brother of Klaus, I can disprove that (but I cannot provide an alternative) Cheers, Micru On Mon, May 5, 2014 at 2:10 PM, Jane Darnell jane...@gmail.com wrote: David, I assume you are referring to books. The same is true for works of art. The reason why these statements are still valuable is because it is an attribution based on grounds determined by someone somewhere and based on that loose statement alone are therefore considered of interest. You basically make a decision to include the statement or not, as you see fit. When it comes to people, one source may say Pete was the son of Klaus, while another source says Pete was the younger brother of Klaus. I think it's just a question of picking one on Wikidata to keep the family aspect of the relationship (whichever it is) intact, and sooner or later one or the other will be chosen. It's a wiki after all. Jane 2014-05-05 11:24 GMT+02:00, David Cuenca dacu...@gmail.com: Hi, I'm having some cases where a work has been attributed to an author by a source, but the source itself says this attribution is dubious, or it is contesting a previous attributions as spurious. As I see it, the rank of the statement is not deprecated (in fact it is normal or even preferred), but I have no way of representing this claim uncertainty or claim rebuttal. Is there any hidden parameter for this or should it be addressed with a qualifier? Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] When the source says the information provided is dubious
Well in the case of attributions of artworks, these things tend to go back and forth a lot, so museums take a fairly pragmatic approach when they invent a pseudo-artist. They will attribute something like a previously attributed B to school of B or follower of B and sort it as B for all other intents and purposes. In the creator field of the artwork template on Commons we have the after qualification, which softens the attribution quite a bit - are you looking for something like that? 2014-05-05 15:43 GMT+02:00, David Cuenca dacu...@gmail.com: Jane, this info is in Wikipedia. For instance see: https://en.wikipedia.org/wiki/Waltzes_(Chopin) N. 17 was attributed to Chopin (Kobylańska and others), Chomiński says that claim is spurious. And that is just one of many examples. According to Wikidata principles we should collect both statements and let the reader decide which source to believe. I can enter Kobylańska's claim, but I have no way to enter Chomiński's counter-claim. I think it is important to be able to model that information because that is how sources act, they don't limit themselves to make certain claims, they also make uncertain claims or counter other claims (even if they don't offer better ones). On Mon, May 5, 2014 at 3:18 PM, Jane Darnell jane...@gmail.com wrote: Hmm, I guess I am still not getting it - both of your examples wouldn't make it into one of my Wikipedia articles, and I would probably remove them from an existing article if I was working on it. If it's not factual enough for Wikipedia, then it's not factual enough for Wikidata. I recall a situation where painter A was documented as a pupil of painter B who according to the sources died when painter A was just a young boy of 8. Either very young children could become pupils of other painters, or the original document got painter B mixed up with someone else. Either way it is highly doubtful that painter A was strongly influenced professionally by the art of B. I would probably include this info on Wikipedia but would not bother to include it on Wikidata. 2014-05-05 14:46 GMT+02:00, David Cuenca dacu...@gmail.com: Hi Jane, No, I was not referring to books in particular, but of course it could be applied to books as well, and to works of art, and to many things in general. I agree that the statement is valuable and that it should be included, but I don't know how to represent it. Following your examples, what I am trying to represent is not what you say, but instead: a) uncertainty: it is hinted that Pete was the son of Klaus, but I have no conclusive proof b) rebuttal: Source A says that Pete was the younger brother of Klaus, I can disprove that (but I cannot provide an alternative) Cheers, Micru On Mon, May 5, 2014 at 2:10 PM, Jane Darnell jane...@gmail.com wrote: David, I assume you are referring to books. The same is true for works of art. The reason why these statements are still valuable is because it is an attribution based on grounds determined by someone somewhere and based on that loose statement alone are therefore considered of interest. You basically make a decision to include the statement or not, as you see fit. When it comes to people, one source may say Pete was the son of Klaus, while another source says Pete was the younger brother of Klaus. I think it's just a question of picking one on Wikidata to keep the family aspect of the relationship (whichever it is) intact, and sooner or later one or the other will be chosen. It's a wiki after all. Jane 2014-05-05 11:24 GMT+02:00, David Cuenca dacu...@gmail.com: Hi, I'm having some cases where a work has been attributed to an author by a source, but the source itself says this attribution is dubious, or it is contesting a previous attributions as spurious. As I see it, the rank of the statement is not deprecated (in fact it is normal or even preferred), but I have no way of representing this claim uncertainty or claim rebuttal. Is there any hidden parameter for this or should it be addressed with a qualifier? Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Etiamsi omnes, ego non ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Bot request: 250+ thousands person data
I was stumped by the same question and couldn't find an answer
anywhere either - as I recall, I just picked the default option,
whichever it was
2014-04-27 14:04 GMT+02:00, Amir Ladsgroup ladsgr...@gmail.com:
I started my
bothttps://www.wikidata.org/wiki/Special:Contributions/Dexboton:
P31 (instance of), P21 (gender), P19 (place of birth), and P20 (place
of death)
I also wrote the code to import dates of birth and death but I'm not
running it yet because there is one important question: What is the
colander model you use as date of birth and death? in some places Gregorian
wasn't common until 1912 so I can't add these dates before 1912 because the
bot can't be sure about calender model of these dates
Best
On Sun, Apr 27, 2014 at 3:32 PM, Luca Martinelli
martinellil...@gmail.comwrote:
Il 27/apr/2014 12:59 Federico Leva (Nemo) nemow...@gmail.com ha
scritto:
David Cuenca, 27/04/2014 12:21:
@Nemo, Apper: Do you think you could import that data into the wd-repo
AND make use of it via an inclusion template?
The Italian Wikipedia has a track of early adoption of Wikidata as a
source. Almost everything that was added to Wikidata was immediately put
into use (most recent big example, I think, the {{interprogetto}}). It
wouldn't take long before {{bio}} starts using the data once it's
available
(probably days or weeks), it's been discussed several times and nobody
appeared to dislike the idea.
If I'm not mistaken, there are (or were) already some experiments going
on
with {{Bio}} using data from Wikidata, possibly for the image field.
Anyway, if Amir (thanks!) is really going to upload that data, nobody is
preventing us from trying to make an experiment on large scale. I'll talk
with the Italian community about it.
L.
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
--
Amir
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Making Wikidata entries at the time of 'Article for Creation' publication
Hi Andy, You hit the nail on the head! I have been cataloguing the artists of the Netherlands since 2009 and have created tons of stubs on Wikipedia that now all need to become items on Wikidata. Most of them became items in the Great Item-creation party of the first few months after WD's birth, especially since a lot of them were already in the Hungarian Wikipedia that got converted first. It is a source of annoyance to me that I can't discover any way to automate the population of the English labels on Wikidata though, so I have been somewhat lazily filling these in as I bump into them. I have decided that the easiest way to pin a painter bio in the Wikiverse that does not exist yet on the English Wikipedia, is to simply go ahead and create the stub on the English Wikipedia. This makes your 15 minutes of legwork into a half-hour of legwork, but it makes it much easier down the line to mesh in with WD, especially because searching WD for names of people who died more than 100 years ago brings its own international spelling challenges. Though I totally agree with Lydia that in the ideal world you could create the item first on WD to use for stub-creation later, we are still a long way from that situation. I feel strongly that there could be a good case for an article creation wizard that runs off of WD, pre-populating things like info-boxes, categories, defaultsort, and lead sentence. my 2c, Jane 2014-03-12 14:52 GMT+01:00, Andy Mabbett a...@pigsonthewing.org.uk: On 10 March 2014 23:28, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: I'd love to know how you think that will happen, in a timely manner, for the kinds of people who use AfC, Where do you see the biggest obstacles right now in the process? Maybe we can identify those and then see if we can find solutions for them? I'm not saying what you're seeing isn't a problem we need to fix. I just think we need to solve it in a better way. Let's find it. The long answer to your question is for you to spend some time looking through, reviewing, and where appropriate publishing, the articles (especially biographies) submitted at AfC (on en.WP, though de.WP and others presumably have an equivalent?). The short asnwer is that we're talking about people who are using Wikipedia for the first time, and struggling, often requiring several iterations, to understand templates, referencing and other things which you and I take for granted. Meanwhile, articles are being created, daily, via AfC with no Wikidata equivalent, or where someone has to create the equivalent manually, cutting-and-pasting or retyping text, rather than having tools do the work for them. That's crazy. Sure. That is clearly not a great situation and we should see if we can improve it. What I'm saying is that we should not improve it by making people enter even more information in Wikipedia and then copy it over to Wikipedia [ITYM copy it over to Wikidata] I'm not sugegsting that we make people enter even more information in Wikipedia; I'm suggesting that wikidata would benefit from capturing the data that is /already/ being entered into Wikipedia, not least via AfC, by the people I describe above; and that I and others who review and publish those articles would benefit from tool to save us the manual task of having to retype (into Wikidata) what we're already asked to type once (into the AfC tool) as part of that process. Let's identify the specific issues and see if we can find other solutions for them. I'm pretty sure I already identified the specific issue here. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Meta header for asserting that a web page is about a Wikidata subject
my 2c: I trust your judgement, so to the last two queries: No and Yes respectively. 2014-02-26 14:20 GMT+01:00, Andy Mabbett a...@pigsonthewing.org.uk: Suppose I publish a web page about a notable person, building or other entity; and that the subject has a Wikidata entry. What's the best meta header, to assert that the page is about the same subject as the Wikidata entry? I'm thinking of something like: link rel=foo href=https://www.wikidata.org/wiki/Q42; or meta name=DC.bar content=https://www.wikidata.org/wiki/Q42; but what values of foo or bar? Given the likely ubiquity of Wikidata in the near future, should we mint: link rel=wikidata or a more generic: link rel=datasource ? Are there any such headers already in the wild? Should Wikipedia articles and pages on sister projects include such headers? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] difference between Person and Human classes
I would imagine it's for fictional characters like Little Red Riding Hood, but I see that when I click on What links here while on page Q215627 I see Sleeping Beauty, but also roles and dead people. I am just as lost as you are! 2014-02-15 2:42 GMT+01:00, Hady elsahar hadyelsa...@gmail.com: Hi all, just got confused a little bit between Person Q215627 and Human Q5 classes in the Person page https://www.wikidata.org/wiki/Q215627 it's written not for use with P31, instead use Q5 human , if so what's the usage of the Person class ? thanks Regards - Hady El-Sahar Research Assistant Center of Informatics Sciences | Nile Universityhttp://nileuniversity.edu.eg/ ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] classes and qualifiers
Hi TomTOm, Be careful what you wish for! If this were possible, then if someone changed the dates, this could mess up other things. We already have a big job untangling mismatched interwiki links, and this would make such mismatches possible to the nth degree. Jane Sent from my iPad On Nov 4, 2013, at 6:14 PM, Thomas Douillard thomas.douill...@gmail.com wrote: Hey, I got an ontology question. Classes are, in semantic web framework and their foundations like Description Logic, if I'am not wrong, something like a lohic predicate that intensionaly or extentionaly defines the properties of their instances. They are usually not qualified, but in Wikidata, as of now they are properties like the others, who can also be qualified. So the question is : could we use qualifier on classes to add predicates on the class definition ? For example if George Bush is an instance of United States President [from 1980 to 1984] (random years), this would mean that the instanciation add some predicates on the other predicates we have on the president of the united states ? Just a random thought, I just realise I just qualified the instanciation, not the class itself. --TomT0m ___ 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] Happy Birthday, Wikidata!
Ditto! Can't wait to see what the next year brings- Jane Sent from my iPad On Oct 29, 2013, at 1:02 AM, Alolita Sharma alolita.sha...@gmail.com wrote: Awesomely cool. Lydia thanks for sharing and celebrating Wikidata's first birthday. Alolita Sharma On Oct 28, 2013 4:59 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote: Heya everyone! Today is Wikidata's first birthday. One year ago Q1 was created. This is time for a lot of celebration and a bit of reflection. Join us over at https://www.wikidata.org/wiki/Wikidata:First_Birthday for an editorial on Wikidata's accomplishments and challenges by Sven, some notes by me, a great interview and some cupcakes ;-) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager 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. ___ 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Automatic summaries?
Sounds like another one of your brilliant ideas, Magnus. If you built it, I would definitely use it. I would also be happy with a description=name solution - anything is better than the blank fields I see now. 2013/9/7, Luca Martinelli martinellil...@gmail.com: 2013/9/7 Magnus Manske magnusman...@googlemail.com: I believe that, for items that have basic claims/statements, short descriptions can be generated automatically, for supported languages. If we have person, Belgian, painter, and birth/death year, a sentence like Belgian painter (1900-2000) can be constructed. Some awards (Nobel prize, Victoria cross, etc.) could be added. +1 on the idea. Not sure about the birth/death year, though. -- Luca Sannita Martinelli http://it.wikipedia.org/wiki/Utente:Sannita ___ 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] Make Commons a wikidata client
Maarten, thanks for that clarification! Gerard, I totally agree with you. Personally I was hoping for a way to use WikiData to find Commons images that was *not* through the gallery/category structures as we know them, for all the reasons Gerard has mentioned (in this and previous mails). Now that I think about it, if you want to create a relationship where Wiki Commons is a client of WikiData, then I think this should be done for galleries only, not categories. Galleries can be easily split and/or merged, reside in more than one category, and offer a best selection of images of the subject, as well as offering a link to more images on Commons by clicking through to categories. Jane 2013/8/13, Gerard Meijssen gerard.meijs...@gmail.com: Hoi, As far as I am concerned, the categories used for images are not really helpful , While there are many images about Kiribati, you find only a few in the category by that name. The rest can be found in subcategories. In the proposal for Commons there is a provision for tags. These tags can be populated to some extend by the categories they are in. The reason to have categories is because they are intended to help find images. Without them and without tags we would not have Commons as a functioning entity. However, the way they work with all these subcategories and stuff prevent many people including myself to use Commons as the source of images when I need them. So yes, having categories are good in a half arsed way but we should get rid of them as we can have something better. One other big advantage of tags is that they are typically single concepts that have typically have translations either in the labels in Wikidata or in Wiktionary. This allows us to make Commons a truly multi-lingual resource. Thanks, GerardM On 10 August 2013 06:19, Maarten Dammers maar...@mdammers.nl wrote: Hi everyone, At Wikimania we had several discussions about the future of Wikidata and Commons. Some broader feedback would be nice. Now we have a property Commons category (https://www.wikidata.org/** wiki/Property:P373 https://www.wikidata.org/wiki/Property:P373). This is a string and an intermediate solution. In the long run Commons should probably be a wikibase instance in it's own right (structured metadata stored at Commons) integrated with Wikidata.org, see https://www.wikidata.org/wiki/**Wikidata:Wikimedia_Commonshttps://www.wikidata.org/wiki/Wikidata:Wikimedia_Commonsfor more info. In the meantime we should make Commons a wikidata client like Wikipedia and Wikivoyage. How would that work? We have an item https://www.wikidata.org/wiki/**Q9920https://www.wikidata.org/wiki/Q9920for the city Haarlem. It links to the Wikipedia article Haarlem and the Wikivoyage article Haarlem. It should link to the Commons gallery Haarlem (https://commons.wikimedia.**org/wiki/Haarlemhttps://commons.wikimedia.org/wiki/Haarlem ) We have an item https://www.wikidata.org/wiki/**Q7427769https://www.wikidata.org/wiki/Q7427769for the category Haarlem. It links to the Wikipedia category Haarlem. It should link to the Commons category Haarlem (https://commons.wikimedia.* *org/wiki/Category:Haarlemhttps://commons.wikimedia.org/wiki/Category:Haarlem ). The category item (Q7427769) links to article item (Q9920) using the property main category topic (https://www.wikidata.org/** wiki/Property:P301 https://www.wikidata.org/wiki/Property:P301). We would need to make an inverse property of P301 to make the backlink. Some reasons why this is helpful: * Wikidata takes care of a lot of things like page moves, deletions, etc. Now with P373 (Commons category) it's all manual * Having Wikidata on Commons means that you can automatically get backlinks to Wikipedia, have intro's for category, etc etc * It's a step in the right direction. It makes it easier to do next steps Small change, lot's of benefits! Maarten __**_ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://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] Make Commons a wikidata client
geocoordinates can be linked to places; creator templates, book templates, and artwork templates can all be linked to people. The problem is if you store the data on WikiData, but do not allow the content to show up on WikiCommons (due to copyright problems), then where does data-curation take place? After I sent that email it occurred to me though that probably most, if not all the people on Commons who understand this stuff are already Wikidatans anyway. So maybe it's a moot point. 2013/8/12, Cristian Consonni kikkocrist...@gmail.com: 2013/8/11 Jane Darnell jane...@gmail.com: Hmm, I am not quite sure how to see this. Places and people yes: It would be nice to have the geo coordinates on Wikidata and for the artist and writers I am not sure I get what geocoordinates means for people. I also agree for the book and the artwork templates. But how could you possibly move all of the Commons copyright logic? As far as I know, it's really quite a small group of people who even understand how all that stuff works on Commons and can untangle those template categories and delete/keep workflows... if you open Wikidata to keeping the data on copyrighted materials, like books and artworks, is that metadata OK to move and manage there? I think this was not the sense of Maarten's proposal. Cristian ___ 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] Wikidata slides on Wikimania2013
Thanks Lydia! 2013/8/11, Lydia Pintscher lydia.pintsc...@wikimedia.de: On Sat, Aug 10, 2013 at 6:59 PM, Federico Leva (Nemo) nemow...@gmail.com wrote: Jiang BIAN, 10/08/2013 18:48: Hi, Is there a place that I can find the slides used on this Wikimania? They have to go here: https://commons.wikimedia.org/wiki/Category:Wikimania_2013_presentation_slides Poke by email the presenters who didn't upload them... How about link them on the submission page, e.g. State of Wikidata http://wikimania2013.wikimedia.org/wiki/Submissions/State_of_Wikidata. Yes, please link or transclude on their wiki page all those you can find. The slides are at https://docs.google.com/presentation/d/1AgpzDNp0z5GVrizQOc_CFZOj7UpttwJDd99fg-JliF8/edit?usp=sharing and http://brightbyte.de/repos/papers/2013/ for now. I'll get to uploading them to Commons in the next days when I am back at home. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Technical Projects 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. ___ 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] Make Commons a wikidata client
Well I am a bit behind on my email, but I thought the idea was that empty templates like the Commons creator template could be plopped onto a Commons category or gallery page and these would get auto-filled on click/open by sucking their data from Wikidata. 2013/8/11, Gerard Meijssen gerard.meijs...@gmail.com: Hoi, There is a lot of data that already fits perfectly well in Wikidata. There is one thing that should become absolutely clear. Wikidata is a project in its own right and Wikipedia is only linked through its interwiki links. The relevance is that there will be an increasing number of Wikidata items with no link at all to Wikipedia. Thanks, Gerard On 11 August 2013 09:36, Jane Darnell jane...@gmail.com wrote: Hmm, I am not quite sure how to see this. Places and people yes: It would be nice to have the geo coordinates on Wikidata and for the artist and writers it would be nice to have the creator templates on Wikidata as well. I also agree for the book and the artwork templates. But how could you possibly move all of the Commons copyright logic? As far as I know, it's really quite a small group of people who even understand how all that stuff works on Commons and can untangle those template categories and delete/keep workflows... if you open Wikidata to keeping the data on copyrighted materials, like books and artworks, is that metadata OK to move and manage there? 2013/8/10, Cristian Consonni kikkocrist...@gmail.com: 2013/8/10 Maarten Dammers maar...@mdammers.nl: Small change, lot's of benefits! Strong +1 C ___ 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Browser search plugins for Wikidata
Hmm, I tried installing this plugin for Chrome, but I just get the message This web page has not been found 2013/7/12, Jeroen De Dauw jeroended...@gmail.com: (Apologies if you are getting this twice - I accidentally send this to wikidata-tech earlier on.) Hey all, Today I had a day off and decided to play around with Firefox plugins and Chrome extensions. The result is one of each being created, both for searching against Wikidata. They are both very simple, though hopefully helpful to you. Firefox plugin: https://addons.mozilla.org/en-US/firefox/addon/wikidata-search/ Chrome extension: https://chrome.google.com/webstore/detail/wikidata-search/ingjkjibhnkhomomlmlabndfmiaejkpn A more verbose version of this email: http://www.bn2vs.com/blog/2013/07/12/wikidata-search-plugins/ Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Accelerating software innovation with Wikidata and improved Wikicode
Michael, The wonderful thing about organic growth models is that they are sometimes extremely energy efficient, and very hard for computers to compete with. If as you say such a 5-year-plan to reduce CO2 emissions were executed, all sorts of other, unintended bad things would happen, such as plants and insects moving into areas of the country where the ecology is thrown off balance, traditional farming communities uprooted, rivers running dry for overuse by irrigation, and so on. There are just too many factors to consider. In the movie Broken Flowers with Bill Murray, one of the (many) funny themes in his visits to 20 ex-girlfriends is his rental of a Ford Focus and using pre-printed MapQuest maps to locate his girlfriends' homes. In one scene he drives along a wooded lane next to a cornfield called Main Street. Back in 1806 after the LewisClark expedition, the newly mapped Louisiana Territory was filled in with street names in Washington D.C. The Westward Ho! movement subsequently populated the area and all Indians were conveniently rounded up and moved to reservations. If you drive through parts of Nebraska, the Dakotas and Wyoming today, you will often come to some Main Street where planners calculated that a town should be settled, but this never happened. It was a good idea in theory to make money by selling land to people who would populate the land, but in practise the only successful farmers were the ones who settled on land in climates that they knew by experience how to farm. It is unknown how many people died in the badlands in the 19th century, but you can be sure that the planners in Washington had very little knowledge of what they were selling. But I like the way you think about using Wikidata to solve the bigger issues like global warming! Jane 2013/7/9, Michael Hale hale.michael...@live.com: Well, you would run into many of the same decisions we already face about how much to limit automated uploads of data if you wanted to turn it into a live programming platform. You can certainly already use DBpedia and Wikidata to get datasets for many cool demonstrations of functional programming though. Yes, I suspect we are just at the learning to walk stage of programming in the big picture. My favorite examples of AI these days are when computers do large mathematical optimization tasks. I was most impressed by a paper last year that optimized the placement and configuration of coal power plants and more farmland to reduce transport related CO2 emissions by 50% for the entire US. The paper was called Nationwide energy supply chain analysis for hybrid feedstock processes with significant CO2 emissions reduction. A free early version was published here: http://www.nt.ntnu.no/users/skoge/prost/proceedings/cpc8-focapo-2012/data/papers/092.pdf And to think how nice it would be if the customized optimization techniques they developed were merged into the code associated with those Wikipedia articles for everyone to easily use. The reason that task impresses me so much is that if a computer at Pixar draws a nice picture it is just matching what the artists could already partially see in their heads and if Siri on the iPhone tells me a good restaurant to visit it is just doing what a person that lives in the area could do, but if a computer redesigns the entire energy infrastructure for a country I have no idea what the solution will look like in advance. There is a lot of smart information out there if people are willing to look for it. How can the singularity get them to stop listening to the bad information? I think things like Wikipedia are definitely helping us all get gradually smarter though, so I'm optimistic. From: dacu...@gmail.com Date: Mon, 8 Jul 2013 19:32:37 -0400 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Accelerating software innovation with Wikidata and improved Wikicode Wikidata seems like a good platform for functional computing, it just needs Lisp-like lists (which would be an expansion of queries/tree-searches) and processing capabilities. What you say it is also true, it would be ahead of the times, because high-level computing languages never expanded as much as imperative languages (probably because the processing power and the need was not there yet). Wikidata as an AI... how far away is that singularity? :) Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Is an ecosystem of Wikidatas possible?
On Sat, Jun 22, 2013 at 6:42 AM, David Cuenca dacu...@gmail.com wrote: On Sat, Jun 22, 2013 at 1:49 AM, Jane Darnell jane...@gmail.com wrote: [...] do you think there is a need for this file to have its own F status in WikiData? Yes. The reason to have file entities is mainly to have a platform that can store semantic descriptions of a file. For text searches in classical terms it doesn't matter much, but to search things like: - portrait engravings by artists born in Dordrecht - depictions of Dutch poets born between 1600 and 1700 For these kind of searches, the only possible way to return relevant results is to store the information a semantic way as Wikidata does. As Thomas pointed out, the task to transition to the new method looks somewhat daunting, luckily here there is not much trouble using bots to automate the task filling out the properties of the 17M files. The case of image promotion I think it is a different issue that would require some tagging (maybe best depiction of) or a simple voting system (like in youtube, reddit, etc). It is also important to note that the old issue of sexual content in Commons [1] has gained *a lot* of traction lately since the last three op-ed's questioning/defending its suistainability [2] [3]. Basically there is a need that the searches show what you are looking for and not some other random content. The urgency to present a solution is very high at the moment, a matter of weeks before starting organizing WikiLoveMonuments with a cleaned reputation, so I hope that Wikidata can present a proposal soon that I am sure will be better than this other proposal [4] Cheers, Micru [1] https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2010-05-10/Commons_deletions [2] https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2013-06-12/Op-ed [3] https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2013-06-19/Op-ed [4] https://www.mediawiki.org/wiki/Requests_for_comment/Image_information ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Scott MacLeod Founder President http://scottmacleod.com -- World University and School (like Wikipedia with MIT OpenCourseWare) http://worlduniversity.wikia.com/wiki/Subjects World University and School is a 501 (c) (3) tax-exempt, educational organization. P.O. Box 442, (86 Ridgecrest Road), Canyon, CA 94516 415 480 4577 worldunivand...@scottmacleod.com worlduniversityandsch...@gmail.com Skype: scottm100 Google + main, WUaS page: https://plus.google.com/u/0/b/108179352492243955816/108179352492243955816/posts Please contribute, and invite friends to contribute, tax deductibly, via PayPal and credit card: http://scottmacleod.com/worlduniversityandschool.htm. World University and School is sending you this because of your interest in free, online, higher education. If you don't want to receive these, please reply with 'remove' in the subject line. Thank you. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Is an ecosystem of Wikidatas possible?
I was thinking about items vs properties and Commons. I am not sure a F entity is necessary. In theory, each file on Commons can be linked to another one, and each item on WikiData can be linked to another one, but those links do not necessarily need to interconnect with Commons. If a Commons file is not the best promoted image of a certain WikiData item, then in my mind it does not need to be in WikiData. Here is an example of what I mean: This is an image of an engraving of Dirk van Hoogstraten: http://commons.wikimedia.org/wiki/File:Dirk_van_hoogstraten_by_arnold_houbraken.JPG He has a WikiData (person) item that could link to that image here: http://www.wikidata.org/wiki/Q5280895 The image file is derived from this file: http://commons.wikimedia.org/wiki/File:Schouburg_I_Plate_I_Leonard_Bramer_-_Dirk_van_Hoogstraten_-_Salomon_de_Bray.jpg which is a page from a 3-volume book about artists that has a WikiData (book) item (that could use the titlepage of the first volume as linked image). The picture of Hoogstraten on that page was also used later by another engraver in a later book about artists: http://commons.wikimedia.org/wiki/File:Schouburg_I_Plate_I_Leonard_Bramer_-_Dirk_van_Hoogstraten_-_Salomon_de_Bray.jpg This second book also has a Wikidata (book) item, and the authors of both books have WikiData (person) items, and so do the engravers of the original engravings. If the original drawing of Dirk Hoogstraten ever comes to light, then that image could be promoted to best image of Dirk Hoogstraten, and this one can remain on commons, but does not need to be linked to WikiData, or do you think there is a need for this file to have its own F status in WikiData? 2013/6/21, David Cuenca dacu...@gmail.com: On Wed, Jun 19, 2013 at 11:15 AM, Denny Vrandečić denny.vrande...@wikimedia.de wrote: I agree that the different projects have different requirements. But I think we should strive for a small number of Wikidatas - you could have made the same argument for Commons, after all. The two projects that might need it most are Wikivoyage (hotel/restaurant listings) and Wikiquote (semantic quotes), though in the end they could be included in Wikidata with different entity types. Wikisource is aligned with the existence of source items in Wikidata, so other than having a S namespace for sources (or not) and adapting the extension to work in Wikisource, there is not much need of development from the Wikidata side. See more here: https://www.wikidata.org/wiki/Wikidata:Wikisource Right now, I think there is a need for Commons to have better support for data - we are working on a proposal text for that - and Wiktionary - as it is really a different system - needs some special treatments - we have just send a proposal text for that. The Wiktionary proposal is a great start. I'm excited about the Commons proposal. It would be fabulous to have an F entity type for files :) (You can always go further and say but it would be better if we supported Wikibooks with structured data about the books and its chapters etc., but at some point you need to weigh implementation effort and cost and the expected benefit) Wikibooks (user-generated text-books) is a special case, a bit different from Wikisource (digital versions of existing sources). However both can be treated in a similar way. I agree that the potential benefit of linking chapters wouldn't be that high. Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Is an ecosystem of Wikidatas possible?
I don't see each file on Commons having its own WikiData item, but I do think each subject of files should have their own item (and some, but not all of them, may also have their own wikipedia pages). These files on Commons could make use of properties on wikidata like is designed by, is a copy of, is an example of, is the best image of or something like that. When the work is a sculpture or a garden and there are many photos, it would be nice to promote one of them to best choice image for some works, this way you can easily replace photos across many Wikipedia's for some of the great pictures coming in with efforts like Wiki Loves Monuments. Similarly, I don't think each poem or each book should have its own WikiData item, but I think each first edition should have its own item, and all other editions should be able to link to it, regardless of translated versions and so on. I see WikiSource and WikiBooks as the same in this respect. 2013/6/20, Martynas Jusevičius marty...@graphity.org: You probably mean Linked Data? On Tue, Jun 11, 2013 at 9:41 PM, David Cuenca dacu...@gmail.com wrote: While on the Hackathon I had the opportunity to talk with some people from sister projects about how they view Wikidata and the relationship it should have to sister projects. Probably you are already familiar with the views because they have been presented already several times. The hopes are high, in my opinion too high, about what can be accomplished when Wikidata is deployed to sister projects. There are conflicting needs about what belongs into Wikidata and what sister projects need, and that divide it is far greater to be overcome than just by installing the extension. In fact, I think there is a confusion between the need for Wikidata and the need for structured data. True that Wikidata embodies that technology, but I don't think all problems can be approached by the same centralized tool. At least not from the social side of it. Wikiquote could have one item for each quote, or Wikivoyage an item for each bar, hostel, restaurant, etc..., and the question will always be: are they relevant enough to be created in Wikidata? Considering that Wikidata was initially thought for Wikipedia, that scope wouldn't allow those uses. However, the structured data needs could be covered in other ways. It doesn't need to be a big wikidata addressing it all. It could well be a central Wikidata addressing common issues (like author data, population data, etc), plus other Wikidata installs on each sister project that requires it. For instance there could be a data.wikiquote.org, a data.wikivoyage.org, etc that would cater for the needs of each community, that I predict will increase as soon as the benefits become clear, and of course linked to the central Wikidata whenever needed. Even Commons could be wikidatized with each file becoming an item and having different labels representing the file name depending on the language version being accessed. Could be this the right direction to go? Cheers, Micru ___ 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 mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Representing Wikidata at LODLAM Summit 2013
Good work, David, go for it! I am very curious to see if the UN comes back with anything 2013/6/19, David Cuenca dacu...@gmail.com: Hi there! I am right now at the LODLAM Summit in Montreal and there was a wish to get Wikidata information, so I improvised a short talk (6th column of the 13:30-14:30 slot) http://summit2013.lodlam.net/files/2013/06/BNIm-WPCEAE5b1N.jpg-large.jpeg There were people from several national libraries (German, Spanish, etc), their impression was very good and some of them want to start linking. Also made some other interesting connections (OpenAgris from the United Nations) which can provide a gateway for government data. I know it is not much, but I couldn't pass the chance for PR'ing :) Cheers, Micru ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] 20% of interwiki conflicts solved at nl-wiki, others?
I noticed this when I clicked on a few notorious Dutch-English wikipages that I know of - thanks for all the good work! I for one, appreciate it. I think the only reason this can be done is thanks to WikiData, which now easily shows what other interwiki possibilities are when you select an item. How exactly are you solving these? I would be interested in helping for pages in Portal:Arts 2013/6/17, Svavar Kjarrval sva...@kjarrval.is: I'd like to see the status on my wiki. How can one detect those conflicts? - Svavar Kjarrval On 17/06/13 00:13, Romaine Wiki wrote: In the past weeks the community of the Dutch Wikipedia has been working hard to solve interwiki conflicts. A few months ago we had more than 14000 interwiki conflicts, today less than 10800. With fixing these interwiki conflicts, often we also fix them on other wikis. But are other Wikipedias also active on massively fixing interwiki conflicts? Romaine ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Question about wikipedia categories.
I think it is a perfectly good and noble ambition to strive for a logically sound ontology as contrasted with a controlled terminology. I just don't believe it is attainable. Perhaps you could build it by including all existing non-compatible ontologies. I had an interesting conversation about tagging last month, in which it was stated that enough tagging could cause new ontologies to appear through organic growth. I find that an interesting concept. Our Wikipedia category tree structures are being built vertically and horizontally around a few main categories like Category:People that slowly get split off into subcategories such as Category:People praying on stained glass windows as they get too large, whereas a tagging system could lead to the formation of new categories for which there is no parent category (as yet). 2013/5/8, Patrick Cassidy p...@micra.com: Should we have more than one ontology? It depends on what you want to do with your ontology(s). Multiple logically incompatible ontologies are now built and used by different groups that have no need to communicate with each other. But when they do want to communicate, the incompatibility creates big problems. Different points of view can be represented by different theories (or 'beliefs) using the same common set of basic terms (i.e. within a single, logically sound ontology). This is the best way, so that the ways in which theories or beliefs actually differ can be precisely specified using a common universally understood vocabulary. In fact, if we didn't have a commonly understood set of basic terms, we would never be able to tell that we have different theories or beliefs or how they differ. The benefits of a logically sound ontology as contrasted with a controlled terminology are the ability to do logical inferencing. In the classic example, if Jack and Joe both have the same parents we can infer that they are siblings. It gets a lot more complicated, and more useful. Therefore it is possible to have all local ontologies represented by a common logical language (i.e. a common foundation ontology). This provide the local flexibility to use terms and theories at will, while providing the maximum degree of accurate communication between the local communities of users. When different communities use different terms to mean the same thing, the common foundation ontology provides a means for automatic translation. The DBpedia ontology could serve this purpose, and I hope it is developed for that purpose, because the range of topics that it needs to represent are unlimited. Why settle for anything less? Pat Patrick Cassidy MICRA Inc. cass...@micra.com 908-561-3416 -Original Message- From: wikidata-l-boun...@lists.wikimedia.org [mailto:wikidata-l- boun...@lists.wikimedia.org] On Behalf Of Jane Darnell Sent: Monday, May 06, 2013 12:14 PM To: Discussion list for the Wikidata project. Subject: Re: [Wikidata-l] Question about wikipedia categories. Yes, there is and should be more than one ontology, and that is already the case with categories, which are so flexible they can loop around and become their own grandfather. Dbpedia complaints should be discussed on that list, I am not a dbpedia user, though I think it's a useful project to have around. Sent from my iPad On May 6, 2013, at 12:00 PM, Jona Christopher Sahnwaldt j...@sahnwaldt.de wrote: Hi Mathieu, I think the DBpedia mailing list is a better place for discussing the DBpedia ontology: https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion Drop us a message if you have questions or concerns. I'm sure someone will answer your questions. I am not an ontology expert, so I'll just leave it at that. JC On 6 May 2013 11:01, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le 2013-05-06 00:09, Jona Christopher Sahnwaldt a écrit : On 5 May 2013 20:48, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le dimanche 05 mai 2013 à 16:28 +0200, Jona Christopher Sahnwaldt a The ontology is maintained by a community that everyone can join at http://mappings.dbpedia.org/ . An overview of the current class hierarchy is here: http://mappings.dbpedia.org/server/ontology/classes/ . You're more than welcome to help! I think talk pages are not used enough on the mappings wiki, so if you have ideas, misgivings or questions about the DBpedia ontology, the place to go is probably the mailing list: https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion Do you maintain several ontologies in parallel? Otherwise, how do you plane to avoid a cultural bias, and how do you think it may impact the other projects? I mean, if you try to establish one semantic hierarchy to rule them all, couldn't it arise cultural diversity concerns? We maintain only one version of the ontology. We have a pretty diverse community, so I hope the editors will take care
Re: [Wikidata-l] Question about wikipedia categories.
What is interesting about categories, is that no matter how shaky the system is, these are pretty much the only meta data that there is for articles, because as I said before, just about every article has one. The weakness of DBpedia is that it is only programmed to pick up articles with infoboxes, and there just aren't that many of those. 2013/5/7, Michael Hale hale.michael...@live.com: Pardon the spam, but it is only 2000 categories. Four steps would be 25000. From: hale.michael...@live.com To: wikidata-l@lists.wikimedia.org Date: Tue, 7 May 2013 12:10:51 -0400 Subject: Re: [Wikidata-l] Question about wikipedia categories. I spoke too soon. That is the only loop at two steps. But if you go out three steps (25000 categories) you find another 23 loops. Organizational studies - organizations, housing - household behavior and family economics - home - housing, religious pluralism - religious persecution, secularism - religious pluralism, learning - inductive reasoning - scientific theories - sociological theories - social systems - society - education - learning, etc. From: hale.michael...@live.com To: wikidata-l@lists.wikimedia.org Date: Tue, 7 May 2013 11:31:24 -0400 Subject: Re: [Wikidata-l] Question about wikipedia categories. I don't know if these are useful, but if we go two steps from the fundamental categories on the English Wikipedia we find several loops. Knowledge contains information and information contains knowledge, for example. Not allowing loops might force you to have to give different ranks to two categories that are equally important. Date: Tue, 7 May 2013 16:41:45 +0200 From: hellm...@informatik.uni-leipzig.de To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Question about wikipedia categories. Am 07.05.2013 14:01, schrieb emw: Yes, there is and should be more than one ontology, and that is already the case with categories, which are so flexible they can loop around and become their own grandfather. Can someone give an example of where it would be useful to have a cycle in an ontology? Navigation! How else are you going to find back where you came from ;) Wikipieda categories were invented originally for navigation, right? Cycles are not soo bad, then... Now we live in a new era. -- Sebastian To my knowledge cycles are considered a problem in categorization, and would be a problem in a large-scaled ontology-based classification system as well. My impression has been that Wikidata's ontology would be a directed acyclic graph (DAG) with a single root at entity (thing). On Tue, May 7, 2013 at 3:03 AM, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le 2013-05-06 18:13, Jane Darnell a écrit : Yes, there is and should be more than one ontology, and that is already the case with categories, which are so flexible they can loop around and become their own grandfather. To my mind, categories indeed feet better how we think. I'm not sure grandfather is a canonical term in such a graph, I think it's simply a cycle[1]. [1] https://en.wikipedia.org/wiki/Cycle_%28graph_theory%29 Dbpedia complaints should be discussed on that list, I am not a dbpedia user, though I think it's a useful project to have around. Sorry I didn't want to make off topic messages, nor sound complaining. I just wanted to give my feedback, hopefuly a constructive one, on a message posted on this list. I transfered my message to dbpedia mailing list. Sent from my iPad On May 6, 2013, at 12:00 PM, Jona Christopher Sahnwaldt j...@sahnwaldt.de wrote: Hi Mathieu, I think the DBpedia mailing list is a better place for discussing the DBpedia ontology: https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion Drop us a message if you have questions or concerns. I'm sure someone will answer your questions. I am not an ontology expert, so I'll just leave it at that. JC On 6 May 2013 11:01, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le 2013-05-06 00:09, Jona Christopher Sahnwaldt a écrit : On 5 May 2013 20:48, Mathieu Stumpf psychosl
Re: [Wikidata-l] Question about wikipedia categories.
Yes, there is and should be more than one ontology, and that is already the case with categories, which are so flexible they can loop around and become their own grandfather. Dbpedia complaints should be discussed on that list, I am not a dbpedia user, though I think it's a useful project to have around. Sent from my iPad On May 6, 2013, at 12:00 PM, Jona Christopher Sahnwaldt j...@sahnwaldt.de wrote: Hi Mathieu, I think the DBpedia mailing list is a better place for discussing the DBpedia ontology: https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion Drop us a message if you have questions or concerns. I'm sure someone will answer your questions. I am not an ontology expert, so I'll just leave it at that. JC On 6 May 2013 11:01, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le 2013-05-06 00:09, Jona Christopher Sahnwaldt a écrit : On 5 May 2013 20:48, Mathieu Stumpf psychosl...@culture-libre.org wrote: Le dimanche 05 mai 2013 à 16:28 +0200, Jona Christopher Sahnwaldt a The ontology is maintained by a community that everyone can join at http://mappings.dbpedia.org/ . An overview of the current class hierarchy is here: http://mappings.dbpedia.org/server/ontology/classes/ . You're more than welcome to help! I think talk pages are not used enough on the mappings wiki, so if you have ideas, misgivings or questions about the DBpedia ontology, the place to go is probably the mailing list: https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion Do you maintain several ontologies in parallel? Otherwise, how do you plane to avoid a cultural bias, and how do you think it may impact the other projects? I mean, if you try to establish one semantic hierarchy to rule them all, couldn't it arise cultural diversity concerns? We maintain only one version of the ontology. We have a pretty diverse community, so I hope the editors will take care of that. So far, the ontology does have a Western bias though, more or less like the English Wikipedia or the current list of Wikidata properties. JC I can't see how your community could take care of it when they have no choice but not contribute at all or contribute to one ontology whose structure already defined main axes. To my mind, it's a structural bias, you can't go out of it without going out of the structure. As far as I understand, the current ontology[1] you are using is a tree with a central root, and not a DAG or any other graph. In my humble opinion, if you need a central element/leaf, it should be precisely ontology/representation, under which one may build several world representation networks, and even more relations between this networks which would represent how one may links concepts of different cultures. To my mind the problem is much more important than with a local Wikipedia (or other Wikimedia projects). Because each project can expose subjects through the collective representation of this local community. But with wikidata central role, isn't there a risk of short-circuit this local expressions? Also, what is your metric to measure a community diversity? I don't want to be pessimist, nor to look like I blame the current wikidata community, but it doesn't seems evident to me that it currently represent human diversity. I think that there are probably a lot of economical/social/educational/etc barriers that may seems like nothing to anyone already involved in the wikidata community, but which are gigantic for those non-part-of-the-community people. Now to give my own opinion of the representation/ontology you are building, I would say that it's based on exactly the opposite premisses I would use. Wikidata Q1 is universe, then you have earth, life, death and human, and it seems to me that the ontology you are building have the same anthropocentrist bias of the universe. To my mind, should I peak a central concept to begin with, I would not take universe, but perception, because perceptions are what is given to you before you even have a concept for it. Even within solipsism you can't deny perceptions (at least as long as the solipcist pretend to exist, but if she doesn't, who care about the opinion of a non-existing person :P). Well I wouldn't want to flood this list with epistemological concerns, but it just to say that even for a someone like me that you may probably categorise as western-minded, this ontology looks like the opposite of my personal opinion on the matter. I don't say that I am right and the rest of the community is wrong. I say that I doubt that you can build an ontology which would fit every cultural represantions into a tree of concepts. But maybe it's not your goal in the first place, so you may explain me what is your goal then. [1] I use quotes because it's seems to me that what most IT people call an ontology, is what I would call a representation. ___
Re: [Wikidata-l] Question about wikipedia categories.
Wondering exactly the same thing - my frustrations with categories began about three years ago and it seems I am surprised monthly by severe limitations to this outdated apparatus. I am a heavy category user, but I would love to be able to kick it out the door in favour of a more structured method. As far as I can tell, there is very little synchronisation among language Wikipedias of category trees, and being able to apply a central structure to all Wikipedias through Wikidata sounds like a great idea, and one which would not disturb the current category trees we already have, but supplement them. As I see it, some category structures are OK, but when categories get big, people split them in non-standard ways, causing problems like this recent media-hype regarding female novellists. I think that it's great this is in the news in this way, because I am sure that most Wikipedia readers never knew we had categories, and this is a great introduction to them, as well as an invitation to edit Wikipedia. 2013/5/4, Chris Maloney voldr...@gmail.com: I am just curious if there has ever been discussion about the potential for reimplementing / replacing the category system in Wikipedia with semantic tagging in WikiData. It seem to me that the recent kerfuffle with regards to American women writers would not have happened if the pages were tagged with simple RDF assertions instead of these convoluted categories. I know, of course, that it would be a huge undertaking, but I just don't see how the category system can continue to scale (I'm amazed it has scaled as well as it has already, of course). I am trying to learn more about wikidata, and have perused the various infos and FAQs for the last two hours, and can't find any discussion of this particular issue. -- Chris ___ 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] Browsing Wikipedia categories by popularity
Nice work! Interesting to see that you made it in Mathematica, of all things! 2013/4/12, Michael Hale hale.michael...@live.com: I made a quick demo of browsing Wikipedia categories by popularity. The video is here (sorry about the audio quality): http://www.youtube.com/watch?v=f3QXwY-XR28The source code is here: http://en.wikipedia.org/wiki/User:Wakebrdkid/Popular_category_browsing If other people like having an option to sort categories that way then article traffic might be a good property to store on Wikidata. ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Complaint about the partial Phase II deployment
Sven, I see your point, since I also spent some time creating data items for a while and then stopped. I disagree that this means that I lost interest. I am still very interested, and I was also somewhat puzzled by the new look. I disagree though that this release causes any more confusion than the first one did. Of course every release will go slower than projected, and of course it will have bugs and cause confusion. I also see no problem with the English Wikipedia implementation, because the consensus (as far as I understand it) is that there will be no automatic edits to the English Wikipedia resulting from Wikidata. I think you need to see this as a second implementation of Wikimedia Commons. That implementation had no automatic edits to the English Wikipedia either, though bots were developed to ease this migration as a way to seed Wikimedia Commons with images that could be used by more than one language. I expect something similar to occur with Wikidata. Not all local images on the English Wikipedia have been migrated to Wikimedia Commons yet. Many of them never will be (these are the fair use images), but many are just not seen enough or have too little metadata to do this responsibly. Jane 2013/2/8, Sven Manguard svenmangu...@gmail.com: Hello there. I have been an active and vocal supporter of Wikidata since almost the day it went live, and after giving Phase II a legitimate chance, I have to say that in my opinion the decision to deploy Phase II with only a small number of the expected features has been a massive mistake. Yes, I understand that the project was losing momentum and that several people commented that they felt that there was nothing to do on the project before Phase II hit, however the partial release has caused considerable confusion, and worse, has caused people to make decisions *based on what is available now* as opposed to based on *what would be the best choice in the long term*. It would have been one thing if Phase II were released with 80% of its projected features and an official list from the developers of the things that were left out. Instead we got what I have to guess is around 10% of the projected features, and if there's an official list of things that are missing or a timeline of when they're going to appear, I haven't seen it. I also have to question the timing of the release, bringing Phase II live just before Wikidata hits English Wikipedia. Was this done on purpose to try and bring over some of the Wikipedia editors? If not, the timing is awful. Nothing of this scale and level of technical sophistication ever gets deployed to English Wikipedia smoothly, and I think that the near future is going to show that the English Wikipedia deployment is going to be competing with the Phase II rollout for the time of the coders, who will need to fix bugs in both areas. I'm sorry for being so pessimistic, but I really do feel let down by this release. It's like being told that you're going to watch a feature film and then only getting the official trailer. The trailer is good, but it's not what people were expecting and it's not particularly valuable on its own. I look forward to any response that the Wikidata staff or the community might have to this. Sven ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Re: [Wikidata-l] Order of language links
I think the order of languages is only important for articles with lots of interwiki links, but for the vast majority of articles there will be less than 5 or so and it doesn't matter. I often click on article interwikis for languages I don't know and can't read (like Japanese). I do this for several reasons, the most prevalent being that I want to see 1) How many links to that page are there in that language? 2) How many items (and which items are these) that are in the articles category in that language? I tend to only do this for the larger Wikipedia projects, where I do this regularly as a trick to track down articles in foreign languages that are good candidates to translate into English (the fathers/sons/siblings of painters). Jane 2013/1/8 Platonides platoni...@gmail.com On 08/01/13 22:31, LD 100 wrote: I would preferred if this could also be changed by each users individually in the settings (maybe the settings could be set globally) Although preferences are evil, I see the point for customizing this. Having ar: in the top if I have no idea of that language is useless, I would prefer to sort first those languages I could understand, perhaps with a separator from those I definetely don't know (others might want to completely hide those). On 08/01/13 22:41, Meng Lu wrote: It's an interesting point. I personally would prefer seeing the Wikipedia instance's own language and English stay at the top, followed by the rest in alphabetical order.A longer stretch might be providing alternative ordering methods for languages such as alphabetical order, descending sizes of that page in each Wikipedia instance. Article sizes are not a perfect estimator for article quality, but seems decent enough. However, it should be able to be overriden by marks of Featured-article / Good-article when some of the entries are tagged as such. Con: Any edit potentially means purgin the entries for all interwikis. Although if the interwiki sort order is stored in wikidata, and we perhaps aren't actively purgin the squid entries, that shouldn't be a problem. ___ 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
