Hoi,
We have imported data from Freebase into Wikidata. It is not seen by WDQ
and consequently it is not considered when adding information.
Imho the need for human verification is already questionable.. Insisting on
it results in an epic fail.
Thanks,
GerardM
http://ultimategerardm.blogspot.nl/2015/07/wikidata-appeasing-wikipedia-cro…
Cross-posting to the Wikidata list because we're considering using Wikibase
as the backend storage for Extension:EducationProgram. The motivation is
that we want to expand the scope of EducationProgram tools to work for
editathons, wiki projects, and any other group of people working on
articles together. Hope to see you on Wednesday!
-Adam
---------- Forwarded message ----------
From: Floor Koudijs <fkoudijs(a)wikimedia.org>
Date: Mon, Jul 13, 2015 at 10:19 AM
To: Wikimedia Education <education(a)lists.wikimedia.org>
TL;DR, Whether you are an amateur or an expert coder, or if you are a
current or interested user of the WikiEduDashboard or of the Education
Extension,* please join us at a hackathon session at Wikimania
on Wednesday, 15 July in Workplace 2 - Don Genaro at 1pm. [0]*
A long time ago in a galaxy far, far away, the Wikimedia Foundation
developed Extension:EducationProgram. It did what we needed it to do at the
time, which was to provide a tool that helps organize classes that want to
edit Wikipedia articles for course credit. Since its release, the extension
has been deployed to 18 Wikimedia projects: it's on 4 sister projects in 16
languages.
Recently, the Wiki Education Foundation [1], led by project manager Sage
Ross (User:Sage (Wiki Ed), User:Ragesoss) developed a Ruby on Rails app
called the WikiEduDashboard [2], which they will use beginning this fall
instead of the EducationProgram extension, for the university courses that
they support on English Wikipedia.
We believe it is possible to use their freely-licensed code to create a
clone of this dashboard that can be used for non-Wiki Ed education program
courses and other group editing activities on English Wikipedia and,
ultimately, on other Wikimedia projects and in other languages.
We are asking for community support for this project since this is outside
the scope of WMF's engineering team for this year. We see the need for a
global dashboard tool and would love to have your help building it!
We're planning some exciting improvements to the Wiki Education Dashboard,
see Phabricator [3] for the full list.
* Full i18n, including right-to-left support.
* Generalize the UI to work for any wiki project and not only
university courses.
* Integration with the Gather extension, to render lists of articles
being written and reviewed.
* Integration with Campaigns, to track group membership and statistics.
* Improvements to the API to simplify some actions taken from the
Dashboard.
* Potentially using Wikidata as the backend for storing information
about courses and editing projects.
We look forward to working together to build this powerful tool which will
support more education and outreach programs in the movement!
[0] https://phabricator.wikimedia.org/T103623
[1] http://wikiedu.org/
[2] https://github.com/WikiEducationFoundation/WikiEduDashboard
[3] https://phabricator.wikimedia.org/tag/education-program-dashboard/
Floor Koudijs
Senior Manager, Wikipedia Education Program
Wikimedia Foundation
+1.415.839.6885 x6806 (landline)
+1.415.692.5289 (cell phone)
fkoudijs(a)wikimedia.org
education.wikimedia.org
Hey folks :)
Right now the property parser function on Wikipedia and other clients
only works with the label of the property. People are asking us to
make it also work with aliases. In order to do that labels and aliases
need to be unique across properties. There are unfortunately a number
of properties where the label and aliases are not unique. Those need
to be fixed before we can enable the feature. Bene has created a page
that lists all properties that need to have their aliases changed:
https://tools.wmflabs.org/bene/alias-uniqueness/ If you could have a
look at this and fix some that'd be much appreciated.
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.
Hey folks :)
Here are all the sessions that are Wikidata related for Wikimania:
https://wikimania2015.wikimedia.org/wiki/Category:Wikidata
We'll also be at the hackathon. If you want to join us for the intro
session on Wednesday at 14:00: https://phabricator.wikimedia.org/T105540
Cheers and hope to see you soon
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.
Hey folks!
We're happy (and kinda proud) to announce that one of our Wikibase Quality
Extensions was deployed yesterday -- with it, you will be able to perform
live checks for most property constraints on both items and properties.
The special page will be accessible here:
https://www.wikidata.org/wiki/Special:ConstraintReport
Some documentation can be found here:
https://www.mediawiki.org/wiki/Wikibase_Quality_Extensions
We hope, you'll like it! (By the way, we found out that 97% of constraints
are complying so go for the last 3%! :wink: )
Cheers,
the Wikidata Quality Team (Andreas Burmeister, Jonas Keutel, Sören Oldag,
Dominic Sauer, Dimitri Schmidt and Tamara Slosarek)
Hi everyone,
I have some bad news. We screwed up. I’m really sorry about this. I’d
really appreciate everyone’s help with fixing it.
TLDR: We have a bad mixup of calendar models for the dates in Wikidata
and we need to fix them.
==== What happened? ====
Wikidata dates have a calendar model. This can be Julian or Gregorian
and the plan is to support more in the future. There are two ways to
interpret this calendar model:
# the given date is in this calendar model
# the given date is Gregorian and this calendar model says if the date
should be displayed in Gregorian or Julian in the user interface
Unfortunately both among the developers as well as bot operators there
was confusion about which of those is to be used. This lead to
inconsistencies in the backend/frontend code as well as different bot
authors treating the calendar model differently. In addition the user
interface had problematic defaults. We now have a number of dates with
a potentially wrong calendar model. The biggest issue started when we
moved code from the frontend to the backend in Mid 2014 in order to
improve performance. Prior to the move, the user interface used to
make the conversion from one model to the other. After the move, the
conversion was not done anywhere anymore - but the calendar model was
still displayed. We made one part better but in the process broke
another part badly :(
==== What now? ====
* Going forward the date data value will be given in both the
normalized proleptic Gregorian calendar as well as in the calendar
model explicitly given (which currently supports, as said, proleptic
Gregorian and proleptic Julian).
* The user interface will again indicate which calendar model the date
is given in. We will improve documentation around this to make sure
there is no confusion from now on.
* We made a flowchart to help decide what the correct calendar model
for a date should be to help with the clean up.
* We are improving the user interface to make it easier to understand
what is going on and by default do the right thing.
* We are providing a list of dates that need to be checked and
potentially fixed.
* How are we making sure it doesn’t happen again?
* We are improving documentation around dates and will look for other
potential ambiguous concepts we have.
==== How can we fix it? ====
We have created a list of all dates that potentially need checking. We
can either provide this as a list on some wiki page or run a bot to
add “instance of: date needing calendar model check“ or something
similar as a qualifier to the respective dates. What do you prefer?
The list probably contains dates we can batch-change or approve but
we’d need your help with figuring out which those are.
We also created a flowchart that should help with making the decision
which calendar model to pick for a given date:
https://commons.wikimedia.org/wiki/File:Wikidata_Calendar_Model_Decision_Tr…
Thank you to everyone who helped us investigate and get to the bottom
of the issue. Sorry again this has happened and is causing work. I
feel miserable about this and if there is anything more we can do to
help with the cleanup please do let me know.
Let's please keep further discussion about this in one place on-wiki
at https://www.wikidata.org/wiki/Wikidata:Project_chat#calendar_model_screwup
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.
If 1 librarian in the USA added one fact or verified / qualified it per
work day in their spare 2 mins a day.
119,729 Libraries in USA
x
1 Librarian minimum per Library with internet access...mostly :-)
x
251 work days in a year
=
30,051,979 MILLION facts that could be added or verified
Get the word out,
Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
