Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
I should state that I haven't fully kept up to date on this thread; I managed to give myself a concussion this week and have been limiting the amount of time spent on activities that are mentally intensive. I decided to pop in and check on how it was going though, and after seeing Russavia's friendly there-are-no-problems-with-commons-culture tone in his last post, I figured I'd pop in and ask a question of Russavia (which he refused to answer on-wiki.) Russavia: one of your recent comments at a deletion discussion (here: [1]) looks an awful lot like you think that labelling a group of identifiable, living people as engaged in prostitution related activities with no evidence other than their location is perfectly acceptable and not a violation of [[COM:IDENT]] or the board BLP resolution. To me, labelling a group of identifiable, living people as engaged in prostitution related activities with no evidence other than their location is a strong violation of both COM:IDENT, and the board's BLP resolution. Most of the other Wikimedians I've shown your comment to have interpreted it in the same way I have. (You said that labelling a group of identifiable, living people as engaged in prostitution related activities was apt because they were in an area known to have a lot of sex work. Given my understanding of the word, that means you thought it was appropriate/suitable - apt is definitely not a word I'd use to describe a BLP violation. Just in case I'd misunderstood what the word meant, I took a look at MW and the OED, both of which indicated that no,I really hadnt.) a) Have I accurately interpreted your comment? If I haven't, would you mind clarifying your intent as you refused to do on-wiki so those confused about what you meant are able to understand what you meant? b) Do you believe that walking away from an active on-wiki discussion refusing to explain what you meant by a comment some took as highly questionable is in line with what should be expected of sysops on major projects? Here's the comment in question reproduced for those who don't want to click through: Carrer de Sant Ramon in El Raval, Barcelona is notorious for being one of the worst places in Barcelona for street prostitution, and this is also acknowledged in local Catalan press. The uploader has done the right thing in applying cover to the eyes of the people, and no individual person is being named as a prostitute, but given that this street is known for daylight prostitution, the name of the file and its description is apt. However, prostitutes in the street do not generally like their photographs to be taken. I am not opining delete on the basis of the nomination but rather for very different reasons. Inline withCommons:Country_specific_consent_requirements, in Spain one requires permission to both take a photograph and publish the photograph when it is taken in a public place, and there is no evidence that this was obtained by the uploader. So on that basis, and that basis alone, it's a firm delete. - Kevin Gorman (Since I cut/pasted Russavia's comment directly, one of the links to Youtube he posted may attach to this email, and I don't currently see the right button to turn that off.) On Thu, May 15, 2014 at 10:58 PM, Erik Moeller e...@wikimedia.org wrote: On Thu, May 15, 2014 at 10:03 PM, John Mark Vandenberg jay...@gmail.com wrote: We're getting a long way off topic of the still frame on MOTD, but I agree, and wish that the WMF would make this a priority for their multimedia and search team. Many improvements have been suggested by the community, and both sides of the fence have even agreed on some of them, such as clustered search results: https://meta.wikimedia.org/wiki/Controversial_content/Brainstorming#Clustering_for_search_results_on_Commons https://bugzilla.wikimedia.org/show_bug.cgi?id=35701 First, as general background, WMF recently started migrating its search infrastructure over to ElasticSearch. See: https://www.mediawiki.org/wiki/Search https://www.mediawiki.org/wiki/Help:CirrusSearch The new search is available on Commons as a BetaFeature. It's worth looking at search results that are viewed as problematic through the new search and compare. For example, the results for Asian are markedly different in the new search. I would caution against a simplistic characterization of technology as a solution for what's inherently a complex socio-technical problem. That was a core issue with the image filter proposal and it's a similar issue here. If people insist on uploading pictures of masturbation with toothbrushes, those pictures will come up in searches. If we insist on not having a distinction between explicit and non-explicit materials in file metadata, search results won't have it either. We can point the finger at technology because that's easy, but it's not magical pixie dust. To get a feel for ElasticSearch's capabilities, please see the help page above, as
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Thu, May 15, 2014 at 8:20 PM, Andreas Kolbe jayen...@gmail.com wrote: Don't put words in my mouth, Pete. Commons is broken is a Jimmy Wales quote. It's something many people have said, and I do apologize for my mistake -- I thought you were one of them. I am very happy to learn that I was wrong about that, and appreciate the clarification. I do think Commons has some ways to go, though, Agree 100%. This is something I work on, if not every day, probably every week. I do think that progress is being made, on adult material and in many other areas. But you're right, there's lots of work to do in developing a a shared understanding of what issues are at play and how to go about addressing them. The point of I'm trying to make in this discussion is, we do a lot more good by focusing on what's working, and then expanding on that, than we do by getting all accusatory about the things that are *not* working. (And such accusations often seem to be accompanied by an unjustified assumption that the bad somehow outweighs the good.) Pete [[User:Peteforsyth]] ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
Kevin, Let me know when you have recovered from the concussion you have incurred, which I hope is soon and I hope you are getting better, and then I would urge you to re-look at the issues and re-present them, and I would be more than happy to discuss publicly right here. It would be unfair of you to expect me to be able to comment frankly (which is my preferred way) right now, when what you are writing here, on Commons, and in the comments section of Pete's blog post may not be Kevin Gorman, Wikipedian-in-Residence at UC Berkeley, but Kevin Gorman, the guy who has received a nasty knock to the head. Until then, I would prefer not to comment further. Cheers, Russavia ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Request for comments: How to deal with open datasets?
On Thu, May 15, 2014 at 11:53 PM, Andrew Gray andrew.g...@dunelm.org.ukwrote: Definitely agree that we needed something like this. There's a lot of confusion about what Wikidata is for, and what is and isn't appropriate for it - both from outsiders and from within the Wikimedia community. I've seen vague it's data, it'll go on Wikidata a few times, which is a bit like saying it's text, it'll go on Wikipedia ;-) Actually during the Hackathon somebody said: We need a new project... a sort of Wiki...Data...Source? :D And it is great that you make the analogy of Wikipedia-and-Text because when you think about it, Wikipedia went through exactly the same process until Project Sourceberg was characterized ;-) Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Thu, May 15, 2014 at 10:58 PM, Erik Moeller e...@wikimedia.org wrote: I would caution against a simplistic characterization of technology as a solution for what's inherently a complex socio-technical problem. Please forgive a sentimental moment -- I am so happy to hear this clearly acknowledged by somebody in a position like yours. It is amazing to me how little attention this simple and obvious point has gotten in the years of discussion we have had on these topics! It seems that somehow, our discussions often seem to ignore that free speech, varying cultural values and editorial objectives, and individual rights have ALWAYS led to drama and problem, starting many centuries before Wikimedia ever came on the scene. It is really astonishing to me how much currency the XYZ group is ethically challenged frame gains in our discussion -- whether that group is those guys at Commons, or those guys at WMF, or whatever. These problems are fundamentally difficult. Yes. That is the appropriate starting point for these discussions, and we should all keep our shared value to assume good faith in mind as we dig into the next layer. All that said, I have long argued that there is a very simple solution to 90+% of the problem, and I'm curious whether this has ever been pursued. A quick visit to stats.grok.se indicates that the Search feature of English Wikipedia was used 63 million times last month, while the Search feature of Commons was used 18,000 times in the same month. Of course, most of the Wikipedia searches were for text, but at least *some* of them would have involved the multimedia tab, which returns almost exactly the same results whether you are on Wikipedia or Wikimedia Commons. (If there's a way to quantify this, I don't know it.) So my question is this: does a reader searching for images on Wikipedia automatically want the same kind of results as a reader searching for images on Wikimedia Commons? Does the Wikipedia reader *expect* to find images from a *related* site? I think the clear answer is no. (Of course this could be tested, but to do so is beyond my resources.) I think it is much more likely that a Wikipedia reader would expect to find those images *used in Wikipedia articles* than a massive collection of stuff that is somehow tangentially related to Wikipedia in a way that they don't fully understand. So why on earth does the main multimedia search link on Wikipedia automatically return unused results from Commons to begin with? Is that really the right way to go? I think a better way for the Wikipedia multimedia Search feature to work would be if it returned for electric toothbrush ONLY the images (from Wikipedia and from Commons) that are *actually* used in Wikipedia articles. There could also be a link there, Would you like to search the media repository Wikimedia Commons, a sister site to Wikipedia? But that could be a secondary step, thereby preventing lots of people (who found the electric toothbrush image they wanted already) from ever seeing the horrific masturbation photo. Is there a good reason not to have the Search feature work this way? I'm not the most technical person, but this doesn't seem like a hugely challenging project. Could it be accomplished for (say) $10,000? And if so, is there a good reason not to do so, and eliminate a large portion of the astonished users who get surprised by something like a toothbrush being put to an unexpected use? Pete [[User:Peteforsyth]] ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
Russavia - It would be pretty easy to go No, I didn't mean to imply that it was okay to label a group of identifiable living people as prostitutes based on the street they happened to be standing on, which, for some odd reason, you've refused to do both on and off-wiki. This has obviously gotten significantly away from the topic of the original thread, but would it comfort you if I asked one of the non-concussed people who interpreted your comment in the exact same way I did to pose the same question to you here? It doesn't exactly look awesome to make what is, charitably, an easy to misinterpret statement, and then refuse to clarify the intent of your statement on a project you're a sysop on. Kevin Gorman On Fri, May 16, 2014 at 1:12 AM, Russavia russavia.wikipe...@gmail.comwrote: Kevin, Let me know when you have recovered from the concussion you have incurred, which I hope is soon and I hope you are getting better, and then I would urge you to re-look at the issues and re-present them, and I would be more than happy to discuss publicly right here. It would be unfair of you to expect me to be able to comment frankly (which is my preferred way) right now, when what you are writing here, on Commons, and in the comments section of Pete's blog post may not be Kevin Gorman, Wikipedian-in-Residence at UC Berkeley, but Kevin Gorman, the guy who has received a nasty knock to the head. Until then, I would prefer not to comment further. Cheers, Russavia ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Fri, May 16, 2014 at 9:05 AM, Pete Forsyth petefors...@gmail.com wrote: The point of I'm trying to make in this discussion is, we do a lot more good by focusing on what's working, and then expanding on that, than we do by getting all accusatory about the things that are *not* working. Think of a surgeon who's done thousands of successful routine operations. But every once in a while, he does a gastric bypass, and those patients more often than not end up harmed. It isn't appropriate in such a case to focus on what's working. (And such accusations often seem to be accompanied by an unjustified assumption that the bad somehow outweighs the good.) The question isn't whether the bad outweighs the good. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
Kevin, Feel free to have one of the people who don't have a nasty head injury ask me the question. That would be fine, and I would actually prefer it. Given your head injury, I'm actually a little surprised that your friends did think of asking me themselves under the circumstances. Cheers Russavia ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Fri, May 16, 2014 at 1:39 AM, Andreas Kolbe jayen...@gmail.com wrote: On Fri, May 16, 2014 at 9:05 AM, Pete Forsyth petefors...@gmail.com wrote: The point of I'm trying to make in this discussion is, we do a lot more good by focusing on what's working, and then expanding on that, than we do by getting all accusatory about the things that are *not* working. Think of a surgeon who's done thousands of successful routine operations. But every once in a while, he does a gastric bypass, and those patients more often than not end up harmed. It isn't appropriate in such a case to focus on what's working. (And such accusations often seem to be accompanied by an unjustified assumption that the bad somehow outweighs the good.) The question isn't whether the bad outweighs the good. Andreas, I agree with your more sophisticated concerns about what is going on. However, I think it's really important to put them in context. If Wikimedia Commons had existed in 1985, this would be a very compelling line of criticism. But in 2014, the same kind of issues -- occasionally encountering shockingly inappropriate images on occasion -- happens whether you are using Wikimedia Commons, Google search, Flickr, Instagram, or any number of other sites -- not to mention spam that arrives unbidden in your email box. If there are studies that quantify how often this happens in different contexts, I'm not aware of them (and would be very happy to learn about them). Until we can look at that kind of study, I refuse to accept as a premise that Commons is categorically worse than other broad collections of media on the Internet. This is a problem to be addressed, yes. And it is a problem that the Commons community works to address (at least in incremental fashion) every single day. But in my opinion, it is not a problem to panic about. Pete [[User:Peteforsyth]] ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On 16 May 2014 15:09, Russavia russavia.wikipe...@gmail.com wrote: But of course, you, with a grand total of 303 edits on Commons going back to 2007 (most of which comprises of voting on Picture of the Year) are speaking from a position of experience when you say you understand Commons and its culture. So you'll excuse me, but it is a bit rich you saying that, and see your comments as insanely out of touch with the reality. Out of curiosity, how many edits to Commons must one have for their opinion to be valid? Cheers, Craig ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Wikimedia Search (it was Commons' frontpage...)
On Fri, May 16, 2014 at 10:28 AM, Pete Forsyth petefors...@gmail.comwrote: A quick visit to stats.grok.se indicates that the Search feature of English Wikipedia was used 63 million times last month [...] Long time ago I played around with the idea that our endeavor for free knowledge would result in spin-off movements, some of which have already happened. Like easing the access to current primary sources (Open Access), guaranteeing the distribution of knowledge (Wikipedia Zero, movement for net neutrality), and making sure that it can be found with global open search tools (?). This last part is mostly uncharted territory, and as the diversity of our open knowledge repository expands, it seems that we can offer much more than just wikipedia text search. Commercial search engines are moving in the direction of search result mash-ups, mixing text , images, videos, maps, data... so the user has an idea of which facets of the subject he or she can explore further. Even mash-ups generated from Wikimedia sites will never be able to compete with web search engines, but it can become the primary choice when looking for free knowledge, specially if synergies with other free knowledge organizations were sought. Perhaps there will be gaps, but I am convinced that with the time they will become less. Maps were missing and OSM has covered that void, there were no free scores, and then IMSLP appeared. Even for products there is Open Product Data in the making. And regarding local business seems that Wikivoyage and OSM have something to offer too, and who knows what will come next. I wonder what are your thoughts about the exciting topic of joining forces with other organizations in the search front to become more than the sum of the parts. Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Fri, May 16, 2014 at 9:46 AM, Pete Forsyth petefors...@gmail.com wrote: I agree with your more sophisticated concerns about what is going on. However, I think it's really important to put them in context. If Wikimedia Commons had existed in 1985, this would be a very compelling line of criticism. But in 2014, the same kind of issues -- occasionally encountering shockingly inappropriate images on occasion -- happens whether you are using Wikimedia Commons, Google search, Flickr, Instagram, or any number of other sites -- not to mention spam that arrives unbidden in your email box. If there are studies that quantify how often this happens in different contexts, I'm not aware of them (and would be very happy to learn about them). Until we can look at that kind of study, I refuse to accept as a premise that Commons is categorically worse than other broad collections of media on the Internet. Commons is fundamentally different from Google, Flickr and other image repositories in that it doesn't have safe search, neither as default nor as an option. If you enter human male, forefinger, Asian, Caucasian, or Black as search terms in – 1. Google Images http://images.google.com/ 2. Flickr https://www.flickr.com/ 3. Wikipedia Multimedia https://en.wikipedia.org/w/index.php?title=Special:Searchsearch=fulltext=Searchprofile=images – the results are strikingly different, with the Wikimedia image repository the only one returning NSFW results (this applies even if you switch Google Safe Search off). You can philosophically debate, applaud or excoriate that fact, as many have done, but it remains a fact. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikimedia Search (it was Commons' frontpage...)
Hoi, We already have this in WD-Search. Try it for instance on the Telugu or Tamil Wikipedia. Search for any subject that is covered in a Wikidata supported Wiki. You can use any script. When the label exists, it will find it for you. Thanks to automated descriptions you will get to see what the item is about. You will be able to find articles in a Wikipedia and a link to Commons. PS Your project can have this enabled by adding one line to common.js Thanks, GerardM On 16 May 2014 11:46, David Cuenca dacu...@gmail.com wrote: On Fri, May 16, 2014 at 10:28 AM, Pete Forsyth petefors...@gmail.com wrote: A quick visit to stats.grok.se indicates that the Search feature of English Wikipedia was used 63 million times last month [...] Long time ago I played around with the idea that our endeavor for free knowledge would result in spin-off movements, some of which have already happened. Like easing the access to current primary sources (Open Access), guaranteeing the distribution of knowledge (Wikipedia Zero, movement for net neutrality), and making sure that it can be found with global open search tools (?). This last part is mostly uncharted territory, and as the diversity of our open knowledge repository expands, it seems that we can offer much more than just wikipedia text search. Commercial search engines are moving in the direction of search result mash-ups, mixing text , images, videos, maps, data... so the user has an idea of which facets of the subject he or she can explore further. Even mash-ups generated from Wikimedia sites will never be able to compete with web search engines, but it can become the primary choice when looking for free knowledge, specially if synergies with other free knowledge organizations were sought. Perhaps there will be gaps, but I am convinced that with the time they will become less. Maps were missing and OSM has covered that void, there were no free scores, and then IMSLP appeared. Even for products there is Open Product Data in the making. And regarding local business seems that Wikivoyage and OSM have something to offer too, and who knows what will come next. I wonder what are your thoughts about the exciting topic of joining forces with other organizations in the search front to become more than the sum of the parts. Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikimedia Search (it was Commons' frontpage...)
Gerard, I was referring to search integration with external projects. Does WD-Search do that? On Fri, May 16, 2014 at 12:29 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, We already have this in WD-Search. Try it for instance on the Telugu or Tamil Wikipedia. Search for any subject that is covered in a Wikidata supported Wiki. You can use any script. When the label exists, it will find it for you. Thanks to automated descriptions you will get to see what the item is about. You will be able to find articles in a Wikipedia and a link to Commons. PS Your project can have this enabled by adding one line to common.js Thanks, GerardM On 16 May 2014 11:46, David Cuenca dacu...@gmail.com wrote: On Fri, May 16, 2014 at 10:28 AM, Pete Forsyth petefors...@gmail.com wrote: A quick visit to stats.grok.se indicates that the Search feature of English Wikipedia was used 63 million times last month [...] Long time ago I played around with the idea that our endeavor for free knowledge would result in spin-off movements, some of which have already happened. Like easing the access to current primary sources (Open Access), guaranteeing the distribution of knowledge (Wikipedia Zero, movement for net neutrality), and making sure that it can be found with global open search tools (?). This last part is mostly uncharted territory, and as the diversity of our open knowledge repository expands, it seems that we can offer much more than just wikipedia text search. Commercial search engines are moving in the direction of search result mash-ups, mixing text , images, videos, maps, data... so the user has an idea of which facets of the subject he or she can explore further. Even mash-ups generated from Wikimedia sites will never be able to compete with web search engines, but it can become the primary choice when looking for free knowledge, specially if synergies with other free knowledge organizations were sought. Perhaps there will be gaps, but I am convinced that with the time they will become less. Maps were missing and OSM has covered that void, there were no free scores, and then IMSLP appeared. Even for products there is Open Product Data in the making. And regarding local business seems that Wikivoyage and OSM have something to offer too, and who knows what will come next. I wonder what are your thoughts about the exciting topic of joining forces with other organizations in the search front to become more than the sum of the parts. Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- Etiamsi omnes, ego non ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Request for comments: How to deal with open datasets?
Thanks for sharing your frustrations. I also notice that the word dataset has many interpretations that we should delimit first its meaning, or at least add some clarification. For instance dataset can be interpreted as a: - static data table: just a table containing some information in each fields and that gets updated/versioned as a whole - collections of files and their associated metadata: what the GLAMs release - an object and its representations My intention was that the RFC only refers to the first interpretation of the word dataset, that is static data tables. Sorry if my use of the word caused some misunderstanding, I will try to make it more clear in the RFC. The issues that you mention in your email are not related to the RFC scope, however they deserve attention. I have identified the following subtopics: 1. Change a page of a djvu 2. Dirty metadata from GLAMs 3. Not reconizing the good job done by Commons 4. Files associated with a concept 5. Users not classifying their data in proper subcategories 6. Showing gaps in our coverage 7. Files as parts of a real object item To keep this thread on-topic, I will address them in a separate email that I will call it Dealing with GLAM data. I hope you don't mind. Micru On Fri, May 16, 2014 at 11:35 AM, Jane Darnell jane...@gmail.com wrote: David, I would strongly prefer a system that keeps the parts together, while at the same time, keeping all the parts separate and interchangeable. I hate that the .djvu files are blobs now, because if I find a better scan of an engraving from a book, I would like to replace the crappy scan that is in the .djvu file. I suppose you need to keep the version you uploaded, but you always want to present the best you have to the reader. I have looked at problems with datasets for a small GLAM, and have seen just how bad the data can be. I am mostly a web-surfer of poorly-designed GLAM datasets, which is why I have spent many hours thinking about these things. I have since given up trying to preach the evangelism of open data to GLAMs and started thinking more about what Wikipedia can do to curate the world's art. Many GLAMs are willing to share their data, but believe me when I say we may not want it. The backlog in batch uploads to Commons is not the technical upload queue, it's all the data massaging by hand that Wikipedians need to do beforehand. That work, which is done by Commons wizards, goes largely unrecognized today. Theoretically, a specific artwork is both a data item and a dataset. If you look at our artwork template on Commons you may have noticed how it has grown in the past 4 years and is fast becoming a fairly comprehensive standard dataset for certain items. The next step is to create a way to index these per object (yes we have categories - is that really the best we can do?). For popular artworks that are architectural features, Wiki Loves Monuments has harvested so many images of these from all different angles that you could probably make the case that Wikimedia Commons has more images than any other publication about that specific item. If you browse the various language versions and their representation of the object, you will notice that individual Wikipedians have selected different images, but these are rarely linked to each other and the casual Wikipedia reader has no idea that they can probably view the object in 3-D if they want to, or see a short movie about how it was made. Indeed, let's face it, most casual readers have only heard of Wikipedia and are completely unaware of Wikimedia Commons and have never heard of Wikimedia Commons categories. Take the case for the Sagrada Familia: https://commons.wikimedia.org/wiki/Category:Sagrada_Fam%C3%ADlia This category is augmented by a gallery page, with the helpful text The Sagrada Família is an unfinished church in the Catalan city of Barcelona, considered to be architect Antoni Gaudí's masterpiece. For images of the Holy Family (Jesus, Mary, and Joseph), see Category:Holy Family. : https://commons.wikimedia.org/wiki/Sagrada_Fam%C3%ADlia Is this really the best we can do? Has anyone ever stopped and counted the rate at which we accumulate photos of the Sagrada Familia each year? We don't want to deter people from uploading, because we are probably still missing important photos of various internal features. But how do we show the gaps in our coverage of this object, while presenting an encyclopedic view? The English Wikipedia page includes about 40 images with a link to the category, but no other hints for media navigation. This is just one example, there are many more. I would like to see a system by which the normal Wiki-collaboration process can be used to slowly integrate all of the Commons files into datasets per item, and then include these into datasets per city or artist or GLAM or whatever. I suppose it should be lists of categories, gallery pages, and templates,
[Wikimedia-l] Dealing with GLAM data (it was: How to deal with open datasets?)
Hi Jane, As a continuation of the other thread: 1. Change a page of a djvu The usual procedure is to download the file, perform changes with tools like Djvu Solo, and overwrite the previous file with the new one adding a description of the cannges (Upload a new version of this file). This doesn't delete the old file, it is still accessible, and it can be restored any time. 2. Dirty metadata from GLAMs That is a problem I heard many times and there is no easy solution, however there are better tools now that some years ago. Have you heard of OpenRefine? https://code.google.com/p/google-refine/ Commons needs something like that, but to annotate metadata with Wikidata concepts. Maybe you could write a description on what is needed on the IdeaLab?https://meta.wikimedia.org/wiki/Grants:IdeaLab 3. Not recognizing the good job done by Commons This is something not addressed in current designs of the Media Viewer. You can only thank the person who uploaded the file, but not the one who curated the metadata, added categories, etc. If you have any idea about how to send good karma to these users, please do share them in the MediaViewer feedback page: https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer I also think that many Wikipedians have the mindset that since English Wikipedia is the biggest project, all other projects should be subordinated to their wishes. That creates some tensions (as you probably have seen the last days). There is no easy solution to this en-wp centric mentality, I just wish that more shared international projects (like Wikidata) will add perspective and a better understanding in the long run. 4. Files associated with a concept Hopefully this will be addressed by new tools like Wikidata for media info https://commons.wikimedia.org/wiki/Commons:Wikidata_for_media_info 5. Users not classifying their data in proper subcategories It is hard to educate casual users, I guess you could propose a new notification when a file gets re-categorized. That way users will learn which category would have been better. 6. Showing gaps in our coverage Again this depends on wikidata for commons. When that tool is in place then it will be possible to create concept trees and signal which branch of the tree doesn't have any file. It is doable, but not trivial for now. 7. Files as parts of a real object item We are going in that direction, however it is a long ride... again the Wikidata for media info is part of the solution. We'll see... Cheers, Micru On Fri, May 16, 2014 at 11:35 AM, Jane Darnell jane...@gmail.com wrote: David, I would strongly prefer a system that keeps the parts together, while at the same time, keeping all the parts separate and interchangeable. I hate that the .djvu files are blobs now, because if I find a better scan of an engraving from a book, I would like to replace the crappy scan that is in the .djvu file. I suppose you need to keep the version you uploaded, but you always want to present the best you have to the reader. I have looked at problems with datasets for a small GLAM, and have seen just how bad the data can be. I am mostly a web-surfer of poorly-designed GLAM datasets, which is why I have spent many hours thinking about these things. I have since given up trying to preach the evangelism of open data to GLAMs and started thinking more about what Wikipedia can do to curate the world's art. Many GLAMs are willing to share their data, but believe me when I say we may not want it. The backlog in batch uploads to Commons is not the technical upload queue, it's all the data massaging by hand that Wikipedians need to do beforehand. That work, which is done by Commons wizards, goes largely unrecognized today. Theoretically, a specific artwork is both a data item and a dataset. If you look at our artwork template on Commons you may have noticed how it has grown in the past 4 years and is fast becoming a fairly comprehensive standard dataset for certain items. The next step is to create a way to index these per object (yes we have categories - is that really the best we can do?). For popular artworks that are architectural features, Wiki Loves Monuments has harvested so many images of these from all different angles that you could probably make the case that Wikimedia Commons has more images than any other publication about that specific item. If you browse the various language versions and their representation of the object, you will notice that individual Wikipedians have selected different images, but these are rarely linked to each other and the casual Wikipedia reader has no idea that they can probably view the object in 3-D if they want to, or see a short movie about how it was made. Indeed, let's face it, most casual readers have only heard of Wikipedia and are completely unaware of Wikimedia Commons and have never heard of Wikimedia Commons categories. Take the case for the Sagrada Familia:
Re: [Wikimedia-l] Dealing with GLAM data (it was: How to deal with open datasets?)
David, Thanks for your thoughtful reply. Yes I think if I sat down I could probably type up about 20 things to go into the Idea Lab, but it's quite a small group of people that ever reads anything in there, and most of the readers are just quickly checking other ideas to make sure they have filled in their own idea correctly. One problem is that there is very little human interaction at all on Commons. I was personally very sad to see this user [1] leave the project, but I can't help but agree with him/her. Sometimes I wonder what I am doing there myself! I just checked, and I have only left messages on 21 other Commons user pages since 2006. Of those 21 users, I have personally met only 4 of them. I can safely say I do not use Commons as a social media website. On the subject of dirty metadata from GLAMS, I am afraid that we concentrate too much on metadata from GLAMs and I would like to see some project work on our own metadata. Lots of it is dirty, but there are some featured items in there that can be used to clean lots of the dirty stuff to a higher level of quality and we should do that. I am worried though when I read things from experienced Wikipedians along the lines of getting rid of the creator and institution templates, or even categories. [2] The whole power of Wikipedia lies in the low threshold of technical knowledge necessary for participation. We need to keep the entrance gate as wide open as possible. I see it as a sign of failure on the part of Commons that I rarely use the newimproved default upload wizard because it almost never fits my needs. I find it annoying that I need to use my own link to use the old uploader. When searching for new solutions, let's not throw away what we have, but try to incorporate innovative approaches on top of the technical landscape we already created. I don't expect newbies to understand and use categories, but it should be easier to identify and fix uncategorized items, and we need to lower thresholds of participation. I think your suggestion of uploading a new version of a djvu file shows an example of a high threshold (the participant must have djvu software to be able to update the file). In the case of the Sagrada Familia, there is a lot more necessary to consolidate our knowledge about it than just media files and text. We need improved search methods and associated navigational tooling, as well as a way to aggregate the number of projects involved in a quick overview. It's more useful if you can see that more than 100 projects carry information about it, than if it was in just 1 or two projects. Even Google just references the article in your default language. I would also like to see redirects and disambiguation pages exported to a central place, so search will improve across language boundaries. I've noticed that it's often spelling differences that keeps Google search better than Wikipedia at locating Wikipedia stuff. As far as the English-centric vision goes, I don't feel one way or another about it. English is as good a lingua franca as any other, as long as it's one basic language. I have said before I am cool with this being Chinese, as long as it's consistent. My main problem with Wikidata is the spotty coverage of labels, and if German was the default language and was completely filled in for all data item labels, I would be totally happy to put German in my Google settings from now on. I get frustrated when people get into arguments about the database-ification of Wikipedia, as if that is a bad thing. It is unrealistic to think we can make everything machine-readable, just as it is unrealistic to think we can keep the reading machines outside the gates. We need to satisfy both our power users and our power editors, and the only way to do that is to keep low-thresholds of participation for both groups. That low threshold of participation is first and foremost for our casual mobile readers who become Wiki(p/m)edians when they upload one thing and go away for ever. We need them too, and though I don't want to force them into learning about our category structures, I do want to serve them a few tips so they can leave the default uploader and take a look around the landscape. The main thing is, we need to share more about where we are going as we get there, so users don't leave because they get tired of waiting. [1] https://commons.wikimedia.org/w/index.php?title=User:Boo-Boo_Baroooldid=90832110 [2] https://commons.wikimedia.org/wiki/Commons_talk:Wikidata_for_media_info Jane 2014-05-16 14:20 GMT+02:00, David Cuenca dacu...@gmail.com: Hi Jane, As a continuation of the other thread: 1. Change a page of a djvu The usual procedure is to download the file, perform changes with tools like Djvu Solo, and overwrite the previous file with the new one adding a description of the cannges (Upload a new version of this file). This doesn't delete the old file, it is still accessible, and it can be restored any time. 2. Dirty metadata
Re: [Wikimedia-l] Wikimedia Search (it was Commons' frontpage...)
David Cuenca, 16/05/2014 12:55: Gerard, I was referring to search integration with external projects. Does WD-Search do that? No, but it's an example of what can be already be done with API calls. http://magnusmanske.de/wordpress/?p=108 Potentially even better, interwiki search was restored: https://bugzilla.wikimedia.org/show_bug.cgi?id=44420 You can try it on Italian language projects: https://it.wikiquote.org/w/index.php?title=Speciale%3ARicercasearch=gattofulltext=Ricerca Portals like wikiwix.com and http://search.creativecommons.org have existed for a long time, but soon they'll be able to get much more from Wikimedia projects (after some more CirrusSearch deploys and Wikidata data imports). Nemo ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Fri, May 16, 2014 at 2:54 AM, Andreas Kolbe jayen...@gmail.com wrote: Commons is fundamentally different from Google, Flickr and other image repositories in that it doesn't have safe search, neither as default nor as an option. Have you never had Safe Search features fail? It seems to happen regularly for me. Overall though -- I don't disagree with you, this is stuff that should be fixed. But as Erik pointed out, the fix is not obvious. The thing that bothers me is when people (especially movement leaders) falsely accuse entire communities of standing in the way of progress. Pete [[User:Peteforsyth]] ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] How to Criticize with Kindness
Hello all, I had a discussion with Fabrice about how a culture of Kindness and Fabrice also made a submission for Wikimania about it: https://wikimania2014.wikimedia.org/wiki/Submissions/A_Culture_of_Kindness In the past years I notice very much how easy discussions can go in the wrong direction as all the facial expressions and intonation are lost when users write a message on a talk page. Many many times this goes wrong, and users have a different interpretation of what someone else said what causes a fight on the wiki. If users are smart they find out that in fact the difference between them is very small with (usually) only a very slight difference in focus, but in general they agree with each other, but they don't realize that on the moment of the discussion. (If users with good will aren't that smart to discover that, such can grow out to a fighting situation for many years.) If I estimate I would say at least 50% of all troubled discussions are causes by miscommunication as the result of words being read differently as result of missing facial expressions and intonation what most people are used to have in the communication with people around them. If certain users are deaf, autistic or dyslectic, or have such background, this is even worsened. For some years I say that if I can follow a training to improve textual communication to better understand how things are perceived, I really like to follow such training. As I don't know of any, I started to figure out and collect what communication mistakes are made what cause troubles between users with the intention of creating a guide for users, to let them understand why some communication gives worse results. Romaine ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Commons vs. local media search
On Fri, May 16, 2014 at 1:28 AM, Pete Forsyth petefors...@gmail.com wrote: I think it is much more likely that a Wikipedia reader would expect to find those images *used in Wikipedia articles* than a massive collection of stuff that is somehow tangentially related to Wikipedia in a way that they don't fully understand. So why on earth does the main multimedia search link on Wikipedia automatically return unused results from Commons to begin with? Is that really the right way to go? I'm breaking out this question since it's a concrete technical proposal; it should probably also be raised on the multimedia list. But we should answer it from the perspective What's best for the user, rather than have it be driven solely by the NSFW corner case (which may also appear when searching images used on a project like en.wp alone). As a user, I might want to find images to add to an article. Having results from the central repository presented locally makes it easier to do so without visiting a separate site. (Consider this from the perspective of smaller projects especially, where the local search would be pretty much useless.) This is why VisualEditor presents Commons search results, as well. As a user, I might be interested in multimedia about a certain topic I just read about in Wikipedia. Showing only the results already in the Wikipedia article(s) about the topic would make it harder to find such media. Simple example: Let's say I read an article about a city, and I want to find other historic maps of that city. In many cases, these maps do exist on Commons but not locally. Should we therefore force people to visit Commons to find them? I would argue that from the ordinary user's perspective, the distinction between Wikipedia/Commons is less important than what they have in common, i.e. being large repositories of useful educational content (and hyperbole aside, 99% of Commons is pretty boring stuff). We could default to displaying locally used media and offer to search Commons with an extra click. From a usability perspective, you want to minimize the steps a user has to take, so good UX design would likely disclose results from Commons either a) always, clearly labeled or b) when no local results are available. There's no question that search UX, both on Commons and on Wikipedia, can be improved. I'm just skeptical that an unbiased evaluation of the user experience using standard UX heuristics would lead to a design that hides explicit content from initial search results. Distinguish different types of content more clearly and make it easier to find the stuff you want - sure, that's doable. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons vs. local media search
On Fri, May 16, 2014 at 1:25 PM, Erik Moeller e...@wikimedia.org wrote: On Fri, May 16, 2014 at 1:28 AM, Pete Forsyth petefors...@gmail.com wrote: I think it is much more likely that a Wikipedia reader would expect to find those images *used in Wikipedia articles* than a massive collection of stuff that is somehow tangentially related to Wikipedia in a way that they don't fully understand. So why on earth does the main multimedia search link on Wikipedia automatically return unused results from Commons to begin with? Is that really the right way to go? I'm breaking out this question since it's a concrete technical proposal; it should probably also be raised on the multimedia list. But we should answer it from the perspective What's best for the user, rather than have it be driven solely by the NSFW corner case (which may also appear when searching images used on a project like en.wp alone). As a user, I might want to find images to add to an article. Having results from the central repository presented locally makes it easier to do so without visiting a separate site. (Consider this from the perspective of smaller projects especially, where the local search would be pretty much useless.) This is why VisualEditor presents Commons search results, as well. As a user, I might be interested in multimedia about a certain topic I just read about in Wikipedia. Showing only the results already in the Wikipedia article(s) about the topic would make it harder to find such media. Simple example: Let's say I read an article about a city, and I want to find other historic maps of that city. In many cases, these maps do exist on Commons but not locally. Should we therefore force people to visit Commons to find them? I would argue that from the ordinary user's perspective, the distinction between Wikipedia/Commons is less important than what they have in common, i.e. being large repositories of useful educational content (and hyperbole aside, 99% of Commons is pretty boring stuff). We could default to displaying locally used media and offer to search Commons with an extra click. From a usability perspective, you want to minimize the steps a user has to take, so good UX design would likely disclose results from Commons either a) always, clearly labeled or b) when no local results are available. There's no question that search UX, both on Commons and on Wikipedia, can be improved. I'm just skeptical that an unbiased evaluation of the user experience using standard UX heuristics would lead to a design that hides explicit content from initial search results. Distinguish different types of content more clearly and make it easier to find the stuff you want - sure, that's doable. With Cirrus (the New Seach beta feature) both marking stuff from commons as from commons and adding a tick box to remove stuff from commons would also be possible. Marking would be easier but both wouldn't be too hard. We could even artificially push results that are on the local wiki higher then those on commons. I know its a horrible excuse, but we're spinning up a project to rework the search page's user interface. It hasn't something like that since tables in table in tables was normal. We've been talking about this. The project is still in the those a pretty mock ups stage and it has been moving slowly. Nik ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons vs. local media search
On Fri, May 16, 2014 at 10:25 AM, Erik Moeller e...@wikimedia.org wrote: On Fri, May 16, 2014 at 1:28 AM, Pete Forsyth petefors...@gmail.com wrote: I think it is much more likely that a Wikipedia reader would expect to find those images *used in Wikipedia articles* than a massive collection of stuff that is somehow tangentially related to Wikipedia in a way that they don't fully understand. So why on earth does the main multimedia search link on Wikipedia automatically return unused results from Commons to begin with? Is that really the right way to go? I'm breaking out this question since it's a concrete technical proposal; it should probably also be raised on the multimedia list. But we should answer it from the perspective What's best for the user, rather than have it be driven solely by the NSFW corner case (which may also appear when searching images used on a project like en.wp alone). As a user, I might want to find images to add to an article. Having results from the central repository presented locally makes it easier to do so without visiting a separate site. (Consider this from the perspective of smaller projects especially, where the local search would be pretty much useless.) This is why VisualEditor presents Commons search results, as well. As a user, I might be interested in multimedia about a certain topic I just read about in Wikipedia. Showing only the results already in the Wikipedia article(s) about the topic would make it harder to find such media. Simple example: Let's say I read an article about a city, and I want to find other historic maps of that city. In many cases, these maps do exist on Commons but not locally. Should we therefore force people to visit Commons to find them? I would argue that from the ordinary user's perspective, the distinction between Wikipedia/Commons is less important than what they have in common, i.e. being large repositories of useful educational content (and hyperbole aside, 99% of Commons is pretty boring stuff). We could default to displaying locally used media and offer to search Commons with an extra click. From a usability perspective, you want to minimize the steps a user has to take, so good UX design would likely disclose results from Commons either a) always, clearly labeled or b) when no local results are available. There's no question that search UX, both on Commons and on Wikipedia, can be improved. I'm just skeptical that an unbiased evaluation of the user experience using standard UX heuristics would lead to a design that hides explicit content from initial search results. Distinguish different types of content more clearly and make it easier to find the stuff you want - sure, that's doable. Erik Thanks Erik, this all sounds like a very reasonable and welcome approach. I certainly don't think my proposal is complete, and as I indicated I don't have the capability to do the required user research, but would hope this idea could be a useful prompt for charting of a path forward. Pete [[User:Peteforsyth]] ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikimedia Search (it was Commons' frontpage...)
On Fri, May 16, 2014 at 4:23 PM, Federico Leva (Nemo) nemow...@gmail.comwrote: Portals like wikiwix.com and http://search.creativecommons.org have existed for a long time, but soon they'll be able to get much more from Wikimedia projects (after some more CirrusSearch deploys and Wikidata data imports). Wikiwix doesn't combine results from other non-wikimedia sites. And the CC portal just directs to each different search engine. Those are really poor search solutions when looking for results from multiple free knowledge sites. Thanks anyhow for pointing me to them, I didn't know about their existence before. Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Fri, May 16, 2014 at 9:43 AM, Russavia russavia.wikipe...@gmail.comwrote: Kevin, Feel free to have one of the people who don't have a nasty head injury ask me the question. That would be fine, and I would actually prefer it. Given your head injury, I'm actually a little surprised that your friends did think of asking me themselves under the circumstances. Cheers Russavia Cutting to the chase, bearing in mind the location and other visual cues, I personally would also assume that the description was indeed apt. In other words, if I saw those women standing there, I'd assume they were prostitutes too. However, assumptions can be wrong. It would be wise for Commons to err on the side of caution, and not label potentially identifiable women as prostitutes on the basis of an unknown individual's upload to Commons. This is a good example: https://commons.wikimedia.org/wiki/File:Street_prostitute_EP_Blvd_02_Memphis_TN.jpg She might well be a prostitute. She might also (for example) just have had a tiff with her ex-boyfriend, who snapped this picture. To be wrong in one out of a hundred cases like that is one time too many. In topic areas like that, I'd be far more comfortable relying on an image from a verifiable source like the one you mentioned in the deletion discussion: https://commons.wikimedia.org/wiki/File:9.000919_Pattaya_streetscene5.jpg ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikimedia Search (it was Commons' frontpage...)
David Cuenca, 16/05/2014 20:41: Wikiwix doesn't combine results from other non-wikimedia sites. And the CC portal just directs to each different search engine. Those are really poor search solutions when looking for results from multiple free knowledge sites. Thanks anyhow for pointing me to them, I didn't know about their existence before. Sure, I mentioned them as two long-time loosely related partners of ours who could be (in theory) contacted for an idea like yours, now that there are more options. No idea who else could be interested: the last Ubuntu, and Firefox since forever, have their own search portals, but with their own priorities. Otherwise, we can just wait for the miracles of APIs and free licenses to happen, at most with some prodding, unrelatedly from any effort of ours. For instance, Yandex seems to have some interest in our stuff, maybe they'll do something surprising at some point. :) Nemo ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Commons' frontpage probably shouldn't prominently feature a decontextualised stack of corpses.
On Thu, May 15, 2014 at 10:58 PM, Erik Moeller e...@wikimedia.org wrote:
Capabilities that exist today with the new search include
template-based boosting of results, a feature that's already enabled
on Commons and which will boost quality content in search results:
https://commons.wikimedia.org/w/index.php?title=MediaWiki:Cirrussearch-boost-templatesaction=edit
For the record, negative boosting is possible as well. So if folks
wanted to add {{NSFW}} to media files that should appear lower in
search results and then apply a 100% boost to that template, that
would put those results further down. Of course that would likely have
unintended consequences, and also take us down the familiar road of
having to figure out what to label / not label.
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
