Hi, thanks for pointing out those issues. The issue of proprietary software is the only potential showstopper, but that can be addressed by introducing the notion of "wikimedia-friendly sharing", rather than "unrestricted sharing". Basically, the visual search engine source code can be copied by anyone, and the burden will be on ScrappyCito to track down wikimedia-unfriendly organizations using the software. See the comments-in-context below for details.
Unfortunately, there are some subjective aspects in the issues raised, which I think are due to a misunderstanding of the system. In short, this a general-purpose visual search front end: a search of "spirit of wikimedia" on each system of Google, Bing, and Scrappy Search shows which are interfaces are truly paleolithic (e.g., pre-2000)! See http://www.scrappycito.com/bgs-spirit-of-wikipedia-24jul18.png Sorry, for the the long delay. This was my first post to a Wikipedia forum, and I overlooked the response. I also overlooked the initial display of my posting, as can seen by my reposting on the 11th. Unfortunately, I was then engulfed in an extended finalization for my patent application. Again more details are below to elaborate the main concerns raised. Best, Tom > Tom O'Hara, > > I foresee several problems with your proposal. > > a) The Wikimedia Foundation itself spent a very large amount of money > building something essentially the same which was rejected by the community > and abandoned. > https://en.wikipedia.org/wiki/Knowledge_Engine_(Wikimedia_Foundation) > <https://en.wikipedia.org/wiki/Knowledge_Engine_(Wikimedia_Foundation)> That was overly ambitious, basically trying to be a search engine as well as structured data integrator. Moreover, it was also highly controversial due to the lack of transparency at the start. This alienated many people in the wikimedia m community. Furthermore, the example on the page for the Knowledge Engine shows that not all search result entries have associated images. For example, both United Nations Security Council and Cyclone Pam had images when the example screen shot was taken. This is basically another example of a stylish visual search that only shows a subset of the results with images in order to accommodate the display of related information. See Danny Sullivan's critique of such visual search engines in his Search Engine Land article. Danny Sullivan (2006), "Visual Search The Future? Spare Me The Eye Candy", https://searchengineland.com/visual-search-the-future-spare-me-the-eye-candy-14279 > b) Your proposal is for a proprietary software to be added to the core > Mediawiki software of Wikipedia. The Wikimedia Foundation is notorious for > never using third-party proprietary software. Does that include third-party proprietary software for which the source code is available? The is the only substantial objection raised. I was surprised that the Wikimedia Foundation imposing such a stringent requirement for server software. Based on https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles, the main reason seems to be to streamline the process customizing wikimedia content and supporting code. This is in the spirit of unrestricted sharing. However, I think it is reasonable for the Wikimedia Foundation to adopt a restricted form of sharing with respect to server software, provided the source code is available. Basically, the wikimedia software can be downloaded and run on by anyone in good standing with the wikimedia community. The intention will be that the software can be used by any wikimedia-friendly organization, such as schools and public agencies which promote open sharing. It would then be up to ScrappyCito to track down ineligible organizations that are using the software. > c) The design is still in the stone age when compared to Bing/Google, so > would not necessarily compete well to attract the target demographic. I believe this is due to a misunderstanding. An important constraint is that all results have image. This is not the case for Google or Bing, especially for abstract queries. If you are referring just to image-only results, I agree the interface is primitive with respect to image search provided by Google or Bing. However, this is a general purpose front end, so all results will have associated images. For example, Google and Bing only show a few images for "boring topic", and neither shows any for "abstruse topic": Scrappy Search always shows images. Moreover, this is particularly designed to take advantage of high resolution provided by tablet. I know of no visual search engine front end that allows users to re-arrange and re-size the results using gestures common to modern handheld devices. Grade school students will surely like this features; see http://www.tomasohara.trade:9330/static/night-owl-sample.png The interface is streamlined on smartphones, bur it nonetheless is quite usable for casual browsing. > d) The search bar at https://www.wikipedia.org/ already has images in a > kind of drop-down search suggestions function, this is nice, but has not > become very popular. That only works for disambiguation and just shows limited information in the menu (e.g., title plus characterization [if available[). Images are not always included even though some of the pages contain images. For example, searching for "garden party" just shows a generic document icon. It would be more useful if it could include other article as well. That would be on-the-fly search. Organizing it into a grid would be more space efficient. The end result would be something like Scrappy Search. > I would actually suggest you go down the route of offering it as an > extension on https://www.mediawiki.org/wiki/Category:Extensions Thanks for pointing that out the wikimedia extension: I was unaware of that, so I will do some experimentation. Being able to customize wikimedia interfaces can be a useful skill. However, this is not attractive in this case because casual wikimedia users will not likely download the extension. It also looks a bit complicated to implement. For instance, parts of the interface would need to rewritten to work as part of a wikimedia. > Warm Regards > > Jeremy Lee-Jenkins > Best, Tom > On Fri, Jul 6, 2018 at 3:07 PM, Tomás O'Hara <tomasoh...@gmail.com> wrote: > >> Hi, here's a link to a proposal I have for adding visual search to >> Wikipedia: >> >> https://meta.wikimedia.org/wiki/Use_visual_search_frontend_for_Wikipedia >> <https://meta.wikimedia.org/wiki/Use_visual_search_frontend_for_Wikipedia# >> Proposed_by> >> >> (This was created with user ID: tomasohara >> <https://en.wiktionary.org/wiki/User:Tomasohara>.) I can move it into a >> better location if desired as it as not a "sister project" proper. The >> Proposals >> for new projects >> <https://meta.wikimedia.org/wiki/Proposals_for_new_projects> page doesn't >> offer suggestions for alternative postings, so I left it there for now. >> >> Below is a copy of the project overview. See the link above for details on >> how this can be applied to foreign language wikipedias. Note that most can >> be supported right "out of the box" except for the text categorization used >> to select images for documents without images. A Wikipedia-specific way to >> do this might be possible (e.g., based on the hierarchy of pages). >> >> Best, >> Tom >> >> --------- >> >> It would be good for Wikipedia to use a general-purpose visual search front >> end. Note that a big incentive for this is that users will be drawn to >> Wikipedia to use this type of search rather than Google Search or Bing. >> This would be beneficial because these search engines often show Wikipedia >> content for popular entities like sports stars or tourist attractions, >> which cuts down on Wikipedia traffic. >> >> You will be able to use the visual search frontend I developed without >> charge for the duration of my patent in the works (a la license free). Here >> is a link to an example with Wikipedia search on left and my Scrappy Search >> on right: >> >> http://www.scrappycito.com/wikipedia-vs-scrappy-search-small >> -dog-breeds-en-wiki-site.png >> >> >> Two other examples illustrate some added benefits of this visual search >> with respect to Wikipedia. First, disambiguation becomes based on images >> and keywords rather than just snippets of text. See the following: >> >> http://www.scrappycito.com/wikipedia-vs-scrappy-search-bob-j >> ones-en-wiki-site.png >> >> In addition, links to other pages for the same entity become much more >> engaging: >> >> http://www.scrappycito.com/wikipedia-vs-scrappy-search-taylo >> r-swift-en-wiki-site.png >> >> >> See http://www.scrappycito.com for the stable version of the system and >> http://www.tomasohara.trade:9330 for the work-in-progress version. The >> latter has support for handheld devices and also better aesthetics (n.b., >> version used in examples). >> >> I think this will be extremely popular with the Instagram crowd and younger >> users in general (e.g., younger than 30). To do similar Wikipedia-specific >> searches with the visual search front end, just add *site:en.wikipedia.org >> <http://en.wikipedia.org>* to the query*,* as in following example: >> >> Lionel Messi site:en.wikipedia.org >> >> Scrappy Search uses the Google search API, so all of the search operators >> <https://support.google.com/websearch/answer/2466433?hl=en> are supported. >> >> The patent for this visual search will be owned by my company ScrappyCito, >> LLC. If the company gets acquired, I will require that they honor the >> license-free usage of the visual search system by Wikimedia for Wikipedia. >> (They will likewise be required to pass along this license-free usage >> requirement if they in turn are acquired). You will have access to the >> current source code for use in Wikipedia and other approved projects. >> >> I am doing this both for exposure and because I want to help keep Wikipedia >> viable (e.g., by enabling higher traffic). This is a great way for users to >> browse the encyclopedia, so it can keep users on the Wikipedia domain >> longer. >> >> If this sounds interesting, I can develop a prototype for the Simple >> English Wikipedia for use on one of my servers. After review, I help with >> the deployment for the regular English Wikipedia on your servers once >> approved. >> >> ============================================================== >> Tom O'Hara, founder ScrappyCito, LLC. PO Box 6430 >> tomasoh...@gmail.com Austin, TX 78762-6430 >> 737-203-1577 www.scrappycito.com >> _______________________________________________ >> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ >> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ >> wiki/Wikimedia-l >> New messages to: Wikimediafirstname.lastname@example.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 and > https://meta.wikimedia.org/wiki/Wikimedia-l > New messages to: Wikimediaemail@example.com > 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 and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimediafirstname.lastname@example.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>