Ticket for WikidataIntegrator is https://github.com/SuLab/WikidataIntegrator/issues/34

How about: https://en.wikipedia.org/wiki/Sign_of_the_horns

Thanks, I didn't actually realise the default swagger did this out of the box.

Thanks, this should probably be included in the upstream package Wikidata Integrator. I'll pass this ticket on to them.

I've popped a note in https://wikitech.wikimedia.org/wiki/Graphite but it could be good to have a specific guide for labs users.

Yep, that's exactly what's happening.

Perhaps its because it is under a path that is autofilled with metrics describing the status of labs instances.

Just from the homepage. http://tools.wmflabs.org/ This is where you'll
probably land if you Google wikimedia tool labs.

The content of the fact extraction is now available on the wikifactmine labs project elasticsearch cluster. See http://elasticsearch-01.wikifactmine.eqiad.wmflabs/wikifactmine-facts-custom for the facts. You need to be inside labs to get to this (e.g. on tool labs)

I think the above tasks are still proving a little nebulous for work to start. I'm making separate subtasks and adding slightly more granular breakdowns for work that can be done for them.

I'm not sure what the solution to this problem is; or if it might impact other people.

I also suffered with this for a very long time. Eventually I settled on having a standalone puppetmaster (for my other instances) but keeping the puppetmaster an agent of the labs puppetmaster not of itself.

Not really.

I've discovered that I can read the elasticsearch logs by connecting to tools-elastic-01.tools.eqiad.wmflabs and looking in /var/log/elasticsearch.

So the tool is wikifactmine-pipeline which auths with elasticsearch as 'tools.wikifactmine-pipeline'.

You can also see the same problem for lt.

I'd be happy with this if it's preferable to using the ubuntu/debian binaries from nodesource (https://github.com/nodesource/distributions) which seems to be what upstream recommends (https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions). I guess using what is already supported by production has a lot of advantages.

According to https://github.com/nodejs/LTS 0.10.x and 0.12.x are now both EOL. The former at 2016-10-31 and the later at 2016-12-31.

Sorry; I'd obviously overlooked that there is currently a very old version of NodeJS available.

Great! Can you add a user for 'tools.wikifactmine-pipeline'? Thanks.

That sounds good to me; clear and not confusing. Thanks for the suggestion @Aklapper

It runs on pretty much vanilla mediawiki and wikibase. There isn't really 'code'; its value is really just the data stored within it. Maybe I shouldn't have asked for a component type project and should have asked for an umbrella (?) but we don't really have distinct subcomponents either (we're using wikibase, and a clone of the wikidata query service as well as some custom scripts for data importing etc.. but these aren't centralised)

librarybase.wmflabs.org is probably the best place to go. It is where the actual wikibase is hosted and is also where we are documenting things. Thanks!

I've already imported a couple of hundred items about articles from PMC into librarybase and hope to add the remaining ones that are cited in en-wiki in the next few days.

This is now done (all non-localhost requests go through nginx which is set to drop POSTs) and it hosts a slightly modified version of the WDQS gui for submitting queries.

The updater now works. Turns out there were some hardcoded references to www.wikidata.org in the endpoint which made it treat URIs from there differently. I've changed this to librarybase.wmflabs.org and it seems to work.

I'd be interested in working on creating a reference database. I'm particularly interested in tracking the usage of PMIDs (I'm about to start a short project with EuropePMC) rather than DOIs but it seems silly to replicate work.