Forwarding from the wikidata list. If you wish to reply, please do so there.
Awesome tools built on top of the Wikidata Query Service!
Dan
---------- Forwarded message ----------
From: Navino Evans <navino(a)histropedia.com>
Date: 10 August 2016 at 12:49
Subject: [Wikidata] Render sparql queries using the Histropedia timeline
engine
To: "Discussion list for the Wikidata project." <
wikidata(a)lists.wikimedia.org>
Hi all,
At long last, we’re delighted to announce you can now render sparql queries
using the Histropedia timeline engine \o/
Histropedia WikidataQuery Viewer
<http://histropedia.com/showcase/wikidata-viewer.html>
Unlike the main Histropedia site this tool renders timelines with data
directly from live Wikidata queries. It lets you map query variables to
values used to render the timeline. A few notable extra features compared
with the built in timeline view on the Wikidata query service:
*Precision* - You can render each event according to the precision of the
date (as long as you add date precision to your query). It will default to
day precision if you leave this out.
*Rank *– The events on the timeline have a rank defined by the order of
your sparql query results. You can also choose a query variable to use for
rank, but it’s not really needed if you use ORDER BY in your query to
control the order of results. Higher ranked events are placed more
prominently on the timeline.
*URL* – You can choose whichever URL you like from your query results,
which will be opened in a new tab when you double click on an event on the
timeline.
*Automatic colour code / filter* – You can choose any variable in your
sparql query to use for colour coding and filtering. From what I could tell
from the preview, this seems to be the same as the new map layers feature
that is close to launch on the Wikidata Query service (which looks awesome
by the way!)
Also similar to the ‘group by property’ feature on Magnus’ Listeria tool,
but using an arbitrary variable from the sparql results instead of a
Wikidata property.
*Some cool examples:*
Note: click on the droplet icon (top right) to see the colour code key and
filter options
- Discoveries about planetary systems, colour coded by type of object
<http://tinyurl.com/zlqupz9> (only items with an image and discoverer)
- Who's birthday is today? colour coded by country of citizenship
<http://tinyurl.com/hla7nqb>
- Oil paintings at the Louvre, colour coded by creator
<http://tinyurl.com/zu7cygv>
- Descendants of Alfred the Great, colour coded by religion, in Japanese
<http://tinyurl.com/h75utbg> – Note: select ‘no value’ in the filter
panel for a fun edit list of people missing religion statement :)
More examples on a dropdown list from the query input page
<http://www.histropedia.com/showcase/wikidata-viewer.html> in the tool.
The tool has been created by myself and fellow Histropedia co-founder Sean
using our newly released JavaScript library. We are only just learning to
code, and it’s a very early stage app so please let me know if anything
breaks!
You can find more info on the JS library (called HistropediaJS) on this
announcement from the Histropedia mailing list
<https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/…>
Cheers!
Navino
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
As of last night:
#discovery-analysis-backlog is now simply #discovery-analysis[1]
#discovery-analysis-sprint is now a milestone within #discovery-analysis,
and will (often) be displayed as "Discovery-Analysis (Current work)" [2].
That means it also appears as a column within #discovery-analysis.
The names could still change slightly, depending on the preferences of the
analysis team.
[1] https://phabricator.wikimedia.org/project/view/1850/
[2] https://phabricator.wikimedia.org/project/view/1241/
Kevin Smith
Agile Coach, Wikimedia Foundation
Awesome! Thanks for the heads up. I'll look out for the latest alpha build
after it's merged.
Dan
On 8 August 2016 at 15:39, Corey Floyd <cfloyd(a)wikimedia.org> wrote:
> Just a heads up to Discovery that the Android team has started development
> of the UI for the new and improved GeoSearch API.
>
> https://phabricator.wikimedia.org/T142431
> https://gerrit.wikimedia.org/r/303703
>
> Since the Android app already has a map UI and the API is rather
> straight-forward, Dmitri was able to get this scheduled and up and running
> rather quickly.
>
>
> --
> Corey Floyd
> Software Engineer
> Reading / iOS
> Wikimedia Foundation
>
> _______________________________________________
> reading-wmf mailing list
> reading-wmf(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>
--
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
Hi Pax,
I believe that WMF Discovery is the team that is best suited to address
matters like this, so I am forwarding your email to the Discovery mailing
list.
Pine
On Aug 7, 2016 16:46, "Pax Ahimsa Gethen" <list-wikimedia(a)funcrunch.org>
wrote:
> In a recent thread about improving search, I posted a comment about a
> possible hazard of relying on Google to search Wikipedia.[1] I explained
> that Google had been displaying a text snippet from an outdated, disruptive
> revision of the Gender page.[2] Well, that error has now resurfaced, and at
> an editor's suggestion I posted to the Village Pump about it.[3] The
> initial response at VP was essentially "not our problem; go away" which was
> not exactly encouraging.
>
> I'm sorry but if a major search engine is erroneously telling people that
> Wikipedia is stating " There are only 2 genders. Male and Female", that is
> a cause of concern for me, and I want to know if or how this problem can be
> fixed. As I explained on the talk page and in the Village Pump, Google's
> cache of the actual page is up to date; it's just the snippet that is wrong.
>
> - Pax
>
> [1] https://lists.wikimedia.org/pipermail/wikimedia-l/2016-July/
> 084890.html
>
> [2] https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975
>
> [3] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(techni
> cal)#Google_returning_outdated_text_snippet_for_Gender_page
>
> --
> Pax Ahimsa Gethen | http://funcrunch.org
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wik
> i/Mailing_lists/Guidelines
> New messages to: Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
*Stripping Question Marks From Wiki Searches*
*Do you ask questions on Wikipedia? Would you like better results?*
*Summary:* Because the large majority of question marks are used to ask
questions by users unfamiliar with bash-style wildcards
<https://en.wikipedia.org/wiki/Glob_(programming)>, the default behavior
for CirrusSearch will now be to ignore question marks (replacing them with
a space). Escaping them with a backslash (\?) will preserve their wildcard
meaning. Regular expressions in *insource:* will not be affected and should
not be escaped. This option can be modified on a per-wiki basis if needed
(see $wgCirrusSearchStripQuestionMarks
<https://github.com/wikimedia/mediawiki-extensions-CirrusSearch/blob/master/…>
).
When people ask *how old is tom cruise?* on Wikipedia they almost certainly
don’t expect the question mark in *cruise?* to match an additional letter.
They aren’t looking for the words *cruised, cruiser, * or *cruises—*but
that’s what they get, and it keeps them from finding the information they
are really after.
Search on Wikipedia (and other Wikimedia projects) includes a lot of
features that most users don’t know about. Most require special keywords,
and some even require specialized knowledge, such as familiarity with
regular expressions. It’s pretty difficult to invoke these special features
by accident.
But search also supports two particular bash-style wildcards without any
special syntax: *** will match any number of characters, and *?* will match
exactly one. Asterisks do come up from time to time, but people use
question marks all the time—because they like to ask questions!
A recent review of query-string features
<https://commons.wikimedia.org/wiki/File:From_Zero_to_Hero_-_Anticipating_Ze…>
called
out quotes and question marks as the two largest-impact predictors of
unsuccessful queries on Wikipedia. In a follow-up survey of queries with
question marks
<https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Dropping_Final_Quest…>
in
six of the top ten Wikipedias (by search volume), most question marks are
being used to ask questions (the other four of the top 10 were not
reviewed). In all ten of the top ten, stripping final question marks
dramatically decreased the number of ?-final queries that got either no
results, or very few results (i.e., less than 3). The improvement was
around 10-45% for ?-final queries, depending on the wiki. The overall
impact is much more modest (less than 0.5%) because queries with question
marks are not terribly common.
As a result of this analysis, we’ve implemented a change to search which
will by default replace question marks with spaces (to preserve the word
boundaries they intend in queries like *how?why?*). This setting can be
changed on a per-wiki basis, and other options include (i) only stripping
question marks at a clear word boundary (such as before a space), (ii) only
stripping question marks at the end of the query, and (iii) leaving the
question marks alone.
For the rarer users who do use question marks as a one-letter wildcard,
when question mark stripping is enabled, question marks can be escaped with
a backslash (e.g., *wiki\?edia*) to preserve their original wildcard
meaning. Power searchers who use *insource:* won’t need to do anything
special; queries with*insource:* will not be modified.
Here's a screenshot
<https://commons.wikimedia.org/wiki/File:Old-are_viruses_living%3F.png> of
the former question mark behavior, where it is treated as a wildcard.
Note that “living?” only matches the name “Livings”, leading to two very
unsatisfactory results.
Here's a screenshot
<https://commons.wikimedia.org/wiki/File:New-are_viruses_living%3F.png> of
the new question mark behavior, where it is ignored. Now the question
and part of the answer can be seen in the snippet for the very first
result, and all of the top three results seem relevant.
(Sorry I can't embed the screenshots—the mailing list won't allow messages
over 40K.)
Trey Jones
Software Engineer, Discovery
Wikimedia Foundation
I'm wondering if MS will pull citations from Wikipedia and/or make use of
Wikidata.
I'm also wondering if this will decrease Wikimedia site traffic in a
similar way to how search engine knowledge panels may have decreased
Wikimedia site traffic, particularly in this case from users who have
access to MS Office.
https://blogs.office.com/2016/07/26/the-evolution-of-office-apps-new-intell…
Pine
Forwarding
Pine
---------- Forwarded message ----------
From: "James Heilman" <jmh649(a)gmail.com>
Date: Jul 15, 2016 06:33
Subject: [Wikimedia-l] Improving search (sort of)
To: "Wikimedia Mailing List" <wikimedia-l(a)lists.wikimedia.org>
Cc:
A while ago I requested a list of the "most frequently searched for terms
for which no Wikipedia articles are returned". This would allow the
community to than create redirect or new pages as appropriate and help
address the "zero results rate" of about 30%.
While we are still waiting for this data I have recently come across a list
of the most frequently clicked on redlinks on En WP produced by Andrew West
https://en.wikipedia.org/wiki/User:West.andrew.g/Popular_redlinks Many of
these can be reasonably addressed with a redirect as the issue is often
capitals.
Do anyone know where things are at with respect to producing the list of
most search for terms that return nothing?
--
James Heilman
MD, CCFP-EM, Wikipedian
The Wikipedia Open Textbook of Medicine
www.opentextbookofmedicine.com
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
