Hey folks,
we plan to drop the wb_entity_per_page table sometime soon[0], because
it is just not required (as we will likely always have a programmatic
mapping from entity id to page title) and it does not supported non
-numeric entity ids as it is now. Due to this removing it is a blocker
for the commons metadata.
Is anybody using that for their tools (on tool labs)? If so, please
tell us so that we can give you instructions and a longer grace period
to update your scripts.
Cheers,
Marius
[0]: https://phabricator.wikimedia.org/T95685
Hoi,
Jura1 created a wonderful list of people who died in Brazil in 2015 [1]. It
is a page that may update regularly from Wikidata thanks to the
ListeriaBot. Obviously, there may be a few more because I am falling ever
more behind with my quest for registering deaths in 2015.
I have copied his work and created a page for people who died in the
Netherlands in 2015 [2]. It is trivially easy to do this and, the result is
great. The result looks great, it can be used for any country in any
Wikipedia
The Dutch Wikipedia indicated that they nowadays maintain important
metadata at Wikidata. I am really happy that we can showcase their work. It
is important work because as someone reminded me at some stage, this is
part of what amounts to the policy of living people...
Thanks,
GerardM
[1] https://www.wikidata.org/wiki/User:Jura1/Recent_deaths_in_Brazil
[2]
https://www.wikidata.org/wiki/User:Jura1/Recent_deaths_in_the_Netherlands
We lack several maintenance scripts for the clients, that is human
readable special pages with reports on which pages lacks special
treatment. In no particular order we need some way to identify
unconnected pages in general (the present one does not work [1]), we
need some way to identify pages that are unconnected but has some
language links, we need to identify items that are used in some
language and lacks labels (almost like [2],but on the client and for
items that are somehow connected to pages on the client), and we need
to identify items that lacks specific claims and the client pages use
a specific template.
There are probably more such maintenance pages, these are those that
are most urgent. Now users start to create categories to hack around
the missing maintenance pages, which create a bunch of categories.[3]
At Norwegian Bokmål there are just a few scripts that utilize data
from Wikidata, still the number of categories starts to grow large.
For us at the "receiving end" this is a show stopper. We can't
convince the users that this is a positive addition to the pages
without the maintenance scripts, because them we more or less are in
the blind when we try to fix errors. We can't use random pages to try
to prod the pages to find something that is wrong, we must be able to
search for the errors and fix them.
This summer we (nowiki) have added about ten (10) properties to the
infobokses, some with scripts and some with the property parser
function. Most of my time I have not been coding, and I have not been
fixing errors. I have been trying to explain to the community why
Wikidata is a good idea. At one point the changes was even reverted
because someone disagree with what we had done. The whole thing
basically revolves around "my article got an Q-id in the infobox and I
don't know how to fix it". We know how to fix it, and I have explained
that to the editors at nowiki several times. They still don't get it,
so we need some way to fix it, and we don't have maintenance scripts
to do it.
Right now we don't need more wild ideas that will swamp the
development for months and years to come, we need maintenance scripts,
and we need them now!
[1] https://no.wikipedia.org/wiki/Spesial:UnconnectedPages
[2] https://www.wikidata.org/wiki/Special:EntitiesWithoutLabel
[3] https://no.wikipedia.org/wiki/Spesial:Prefiksindeks/Kategori:Artikler_hvor
John Erling Blad
/jeblad
Hi, it's first of July and I would like to introduce you a quarterly goal
that the Engineering Community team has committed to:
Establish a framework to engage with data engineers and open data
organizations
https://phabricator.wikimedia.org/T101950
We are missing a community framework allowing Wikidata content and tech
contributors, data engineers, and open data organizations to collaborate
effectively. Imagine GLAM applied to data.
If all goes well, by the end of September we would like to have basic
documentation and community processes for open data engineers and
organizations willing to contribute to Wikidata, and ongoing projects with
one open data org.
If you are interested, get involved! We are looking for
* Wikidata contributors with good institutional memory
* people that has been in touch with organizations willing to contribute
their open data
* developers willing to help improving our software and programming missing
pieces
* also contributors familiar with the GLAM model(s), what works and what
didn't work
This goal has been created after some conversations with Lydia Pintscher
(Wikidata team) and Sylvia Ventura (Strategic Partnerships). Both are on
board, Lydia assuring that this work fits into what is technically
effective, and Sylvia checking our work against real open data
organizations willing to get involved.
This email effectively starts the bootstrapping of this project. I will
start creating subtasks under that goal based on your feedback and common
sense.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I think I've seen something somewhere saying that the prevailing sentiment
is that obsolete identifiers which are just redirects to a new identifier
should be removed.
There's also the case of sites like MusicBrainz which keep the
non-canonical IDs without redirecting to the canonical ID, but will tell
you which ID is preferred, e.g. Fritz Kreisler
<https://www.wikidata.org/wiki/Q78517#revision=254297158>
https://musicbrainz.org/artist/590fcad4-2ba4-43bc-a22f-a4bb9b496fe8https://musicbrainz.org/artist/627ac6c2-ee5c-4120-8af3-ab00345447f5https://musicbrainz.org/artist/bf6d6ce1-ce88-40e6-9424-11d11d2e54ea
where all the tabs for the second two pages actually point to the first,
canonical entry.
Is there an established policy for either the redirect or non-redirect case?
I'd argue that even the obsolete identifiers are useful for inbound
resolution and reconciliation. Aggressively pruning them just makes more
work for people, because they must resolve the identifier that they have in
hand to its canonical form (probably by hitting the issuing authority)
before using it for Wikidata lookups.
What do others think?
Tom
Hi everyone,
I'm currently working on a concept to improve the current editing situation
of Wikidata's data on a client (e.g. Wikipedia & co.) in colaboration with
Lydia Pintscher, in the scope of my Bachelor's thesis.
It would be very appreciated if you could add your input and comments to
the page below and pass this info to the other Wikis and their editors
since their input is crucial to this project.
https://www.wikidata.org/wiki/Wikidata:Client_editing_input
Thanks!
Charlie
<https://www.wikidata.org/wiki/User:Lydia_Pintscher_%28WMDE%29>
Hey folks :)
Wikidata is turning 3 years old on October 29th. This is a reason to
celebrate for all of us. We'll be having a big party in Berlin and I'd
love to see as many of you there as possible.
You can find out more at
https://www.wikidata.org/wiki/Wikidata:Third_Birthday/Party
We also have a few more things planned where I'd love to have videos,
images and other input from you. More on that on
https://www.wikidata.org/wiki/Wikidata:Third_Birthday/Party as well.
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 everyone :)
We'll be doing the next Wikidata office hour on September 23rd at
17:00 UTC. See http://www.timeanddate.com/worldclock/fixedtime.html?hour=17&min=00&sec=0&d…
for your timezone. We'll be meeting in #wikimedia-office on Freenode
IRC.
As usual I'll start with an overview of what's been happening around
Wikidata since the last office hour and then we'll have time for
questions and discussions.
If there is a particular topic you'd like to have on the agenda please
let me know.
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.
I had to clean up this entity that had Sister City property filled in with
lots of erroneous statements for it that I removed.
https://www.wikidata.org/wiki/Q185684
How can I figure out where the import went wrong, how it happened, and how
to ensure it doesn't happen again ? How does one look at Wikidata bots and
their efficiency or incorrectness ?
Trying to learn more,
Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>