Hey!
tl;dr after the next deploy merging two items creates a redirect, merge
gadget (and every tool with a similar functionality) needs to be adjusted
to the new functionality
There was a change to the functionality of merging items. Whenever you
merge two items a redirect will be automatically created.
If you merge via the special page nothing changed - except for the item,
that is merged into another item now also redirects to that item.
The same goes for the API except for using 'ignoreconflicts'- when the item
is not left empty after the merge it won't be a redirect and still be there
as before without the data that got merged into the other item. (So it will
only have the data that would have given a merge conflict.)
Last but not least: The merge gadget will need some adjusting. That's
expected since the functionality changed.
Please keep that in mind if you have any tool, that merges items.
Cheers,
Lucie
--
Lucie-Aimée Kaffee
Working Student Software Development
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0http://wikimedia.de
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/681/51985.
Hi,
The recent Wikidata JSON dumps again contain huge amounts of broken JSON
where empty maps are serialized as [] instead of using {}. Just grep for
"claims":[]
or
"aliases":[]
or
any other key that requires a map
to find many examples. The scope of the problem is massive. Basically
all entity documents that include some empty map are broken, which is
almost every entity document in
http://dumps.wikimedia.org/other/wikidata/20150803.json.gz. Concretely,
there are around 15.7 million entities with [] for aliases.
This is critically breaking the consumption of Wikidata content for all
model-based JSON parsers, including Wikidata Toolkit.
The bug used to occur only in XML dumps, but now also affects the JSON
dumps in the same way. In previous JSON dumps, the problem was avoided
by omitting empyt maps altogether (no keys, no values), which is better
because it allows implementations to fall back to the obvious default.
This is still done in the Web API, e.g.,
https://www.wikidata.org/wiki/Special:EntityData/Q12062430.json
It would be nice to test the export code before deploying it.
Regards,
Markus
Hi all,
Vladimir Alexiev has published an interesting post on issues he
encountered when using DBpedia at OntoText, drawing many comparisons to
Wikidata [1]. While this post praises the practices of Wikidata in
several places, I think there are a few important insights for Wikidata
there as well. There are certainly points where Wikidata is running into
similar issues (if you have had a look at our class hierarchy recently,
you know what I mean). Even in the cases where we are doing good, it
might be valuable to obtain some feedback and reconfirmation from
another perspective.
Cheers,
Markus
[1]
http://vladimiralexiev.github.io/pres/20150209-dbpedia/dbpedia-problems-lon…
--
Markus Kroetzsch
Faculty of Computer Science
Technische Universität Dresden
+49 351 463 38486
http://korrekt.org/
The Museum of Modern Art of New York has published a CSV on GitHub
containing the data of its entire collection under a CC0 license.
https://github.com/MuseumofModernArt/collection
They have blogged about it.
https://medium.com/digital-moma/thousands-of-exhausted-things-or-why-we-ded…
"This data release <https://github.com/MuseumofModernArt/collection>
includes all of the works that have been both accessioned into MoMA’s
collection *and* cataloged in our database. It includes basic data for each
work, including title, artist, date made, medium, dimensions, and date
acquired by the Museum."
"MoMA’s open data is primarily intended to be useful to scholars, so it was
important to make each version citable."
"*Thanks to the **Cooper-Hewitt*
<https://github.com/cooperhewitt/collection>* and **Tate*
<https://github.com/tategallery/collection>* for paving the way by
releasing their own collection data on GitHub using CC0. Thanks also to
George Oates (**@goodformand* <https://twitter.com/goodformand>*) for
reassuring us that a CSV is not just the easiest way to start but probably
the most accessible format for a broad audience of researchers, artists,
and designers."*
They actually produced a live, on-site performance about the data released,
and blogged about it: https://medium.com/@blprnt/a-sort-of-joy-1d9d5ff02ac9
"This release of open data by MoMA is by no means revolutionary. Two years
ago the Tate Modern released its own collection on GitHub
<https://github.com/tategallery/collection>. The Rijksmuseum in Amsterdam
has not only released its data (images and all), it has also built an API
<https://www.rijksmuseum.nl/en/api> to allow anyone easy access to it. In
2013 the British Museum released 1,000,000 images
<https://www.flickr.com/photos/britishlibrary/page1> under a Creative
Commons license."
Anyway, this might not be big or surprising news to those of you following
closely this scene. I just found amusing to learn accidentally about this
the day that Wiki Loves Open Data has started taking shape in a wiki page.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil