On Fri, Apr 26, 2013 at 6:15 PM, Daniel Kinzler <daniel.kinzler(a)wikimedia.de
On 26.04.2013 16:56, Denny Vrandečić wrote:
The third party propagation is not very high on
our priority list. Not
it is not important, but because there are things
that are even more
like getting it to work for Wikipedia :) And this
seems to be
What we have, for now:
* We have the broadcast of all edits through IRC.
This interface is quite unreliable, the output can't be parsed in an
way, and may get truncated. I did implement notifications via XMPP several
ago, but it never went beyond a proof of concept. Have a look at the XMLRC
extension if you are interested.
* One could poll recent changes, but with 200-450
edits per minute, this
Well, polling isn't really the problem, fetching all the content is. And
need to do that no matter how you get the information of what has changed.
* We do have the OAIRepository extension
installed on Wikidata. Did
anyone try that?
In principle that is a decent update interface, but I'd recommend not to
before we have implemented feature 47714 ("Support RDF and API
of entity data via OAI-MPH"). Right now, what you'd get from there would
*internal* JSON representation, which is different from what the API
and may change at any time without notice.
What we do right now in DBpedia Live is that we have a local clone of
Wikipedia that get's in sync using the OAIRepository extension. This is
done to abuse our local copy as we please.
The local copy also publishes updates with OAI-PMH that we use to get the
list of modified page ids. Once we get the page ids, we use the normal
mediawiki api to fetch the actual page content.
So, feature 47714 should not be a problem in our case since we don't need
the data serialized directly from OAI-PMH
Daniel Kinzler, Softwarearchitekt
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Wikidata-l mailing list