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
Hi folks!
My name is Glorian Yapinus, but you can simply call me Glorian ;) . For the
next 6 months, I will assist Lydia in supporting you all.
Regarding to my educational background, I hold a bachelor's degree in
Information Technology and currently, I am working on my Master's in
Software Engineering and Management.
I am a warm and nice person. So, please do not hesitate to reach out to me
for any queries :-)
Last but not least, I am looking forward to working with you.
Cheers,
Glorian
--
Glorian Yapinus
Product Management Intern for Wikidata
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Dear all,
I am happy to announce that we have just deployed a new version of the
SQID Wikidata browser at
https://tools.wmflabs.org/sqid/
The main news are the first working editing features. Users that log in
will be given options to modify the data directly. (Regular users may
have to hard reload the page to see the new version; it should have a
"login" option on the top right.)
== Features ==
* Users can login with their Wikimedia accounts
* Statement suggestions from Primary Sources are offered to logged in
users, who can approve or reject them
* Approving/rejecting statements takes immediate effect, without a slow
page reload
* Statement suggestions are shown in the same "smart" order used for all
data on SQID. For example, statements with start time will be ordered by
time so you can compare suggested data to existing data more easily.
* There is a minimal "edit label" functionality for logged in users too
We hope this can help to speed up the work of editors who want to get
more PS data merged into Wikidata (e.g., for Freebase import).
== Known issues ==
* Some statements cannot be rejected in Primary Sources. This problem
affects both SQID and the Wikidata gadget in the same way. It seems to
be a bug in the PS web service, which we hope will be fixed at some point.
* There is no error reporting yet -- if PS fails, the user can see that
a requested action does not happen but errors are logged on the
Javascript console only.
* If many references for the same statement are suggested, they will
show as many statements with one reference each instead. The editing
functionality is there, but the UI needs to be improved.
* Label editing is pretty minimal, e.g., you cannot edit descriptions yet.
* If a suggestion (reference or additional statement value) is in a
collapsed panel in the UI, there is no indication of it.
Please report issues and requests through github:
https://github.com/Wikidata/SQID/issues
== Next steps ==
* Address the open issues above (those that can be fixed in SQID)
* Add further editing controls (e.g., direct statement deletion)
* Add further suggestion sources
== Acks ==
This implementation was mainly done by Michael Günther. Many thanks are
also due to Magnus, whose Widar service for editing Wikidata is used to
make the actual changes in the back (so edits will get a Widar tag in
Wikidata's history).
As usual, feedback is welcome.
Cheers,
Markus
--
Prof. Dr. Markus Kroetzsch
Knowledge-Based Systems Group
Center for Advancing Electronics Dresden (cfaed)
Faculty of Computer Science
TU Dresden
+49 351 463 38486
https://iccl.inf.tu-dresden.de/web/KBS/en
Hey folks :)
We'll do the next office hour on IRC on the 5th of January at 19:00
Berlin time in #wikimedia-office. See
https://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=00&sec=0&…
for your time.
As usual we'll take a look back at the last quarter and see what's
coming up next. Please let me know if there are any other topics you'd
like to put on the agenda.
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/029/42207.
Hi all,
I think this topic might have been discussed many months ago. For
certain data types in the chemical compound space (P233, canonical
smiles, P2017 isomeric smiles and P234 Inchi key) a higher character
limit than 400 would be really helpful (1500 to 2000 chars (I sense
that this might cause problems with SPARQL)). Are there any plans on
implementing this? In general, for quality assurance, many string
property types would profit from a fixed max string length.
Best,
Sebastian
Sebastian Burgstaller-Muehlbacher, PhD
Research Associate
Andrew Su Lab
MEM-216, Department of Molecular and Experimental Medicine
The Scripps Research Institute
10550 North Torrey Pines Road
La Jolla, CA 92037
@sebotic
Folks,
We're now officially mainstream ;-)
https://www.buzzfeed.com/katiehasty/song-ends-melody-lingers-in-2016?utm_te…
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/029/42207.
Hi,
now that SQID supports the confirmation/rejection of statements from
Primary Sources (Freebase imports), I notice certain systematic issues
with it. I believe many of the proposals should be removed because they
are already represented in Wikidata and do not need to be imported.
Three types of data I found so far:
(1) Redundant "located in the administrative territorial
entity"/"contains administrative territorial entity". Wikidata stores
only the next territory above/below the current one in these relations.
PS often suggests territories reachable through several steps instead.
Examples:
- https://tools.wmflabs.org/sqid/#/view?id=Q980 (login first to see
suggestions). There are almost 100 towns that fall into this area
suggested here, but they all should be organised in more specific
sub-regions of the hierarchy.
- https://tools.wmflabs.org/sqid/#/view?id=Q10474 There is a
higher-level territory suggested here (Bavaria) even though "Lower
Bavaria" is already present.
Similar things are found, e.g., for occupation (P106), where a person
that is already a "sport cyclist" might be suggested to be a "sportsperson".
(2) Syntactic variations of the "same" value. Typical cases are URLs,
which PS suggests with trailing "/" even after top-level domains, while
Wikidata often omits it. This means you have suggestions like
"http://www.pirna.de/" when there is already "http://www.pirna.de".
(https://tools.wmflabs.org/sqid/#/view?id=Q6477)
(3) Redirect items as values. PS sometimes suggests statement values
that are redirects to other entities, for which there already is a
statement.
All of these cases should be fixed on the provider side, not by hiding
suggestions in the UI (as it seems to be done by the PS gadget for case
(2)). This would also help to get better statistics: right now, all I
can do is to reject all of these values, but this might be misleading if
one looks at the PS statistics since they are not wrong, but simply
unnecessary.
Simply hiding suggestions that are not eliminated from the data also
makes the PS service's feature for finding items with suggestions much
less useful (you might find items that does not show you any suggestion).
I was wondering if anybody is still working on PS clean up now or if
this part of the project this orphaned.
Cheers,
Markus
--
Prof. Dr. Markus Kroetzsch
Knowledge-Based Systems Group
Center for Advancing Electronics Dresden (cfaed)
Faculty of Computer Science
TU Dresden
+49 351 463 38486
https://iccl.inf.tu-dresden.de/web/KBS/en
Hey,
Due to an API change in Wikibase which happened several weeks ago, one of
ORES dependencies (pywikibase) broke and caused ORES to break in small
proportion of Wikidata edits but it got bigger and bigger until today which
which we had an unscheduled deployment of ORES. Everything is okay now but
we might lose some scores on edits in ORES review tool, I run a maintenance
script to fill them now.
More details can be found in https://phabricator.wikimedia.org/T154168
Happy holidays,
Prost!
--
Amir Sarabadani Tafreshi
Software Engineer (contractor)
-------------------------------------
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.