Linking Wikimedia projects with scholarly research.
- User Since
- Oct 27 2014, 10:02 PM (185 w, 6 d)
- LDAP User
- MediaWiki User
- Daniel Mietchen
Wed, May 16
Still hundreds of spam pages, and I don't see how to get rid of them at scale.
Mon, May 14
So far, spam seems to go exclusively to the main namespace, so perhaps it's worth restricting edits there to autoconfirmed users.
Wed, May 9
@Addshore My example is from Commons (see main page), but in case we allow local uploads (not sure about that right now), it would certainly be nice to be able to display these properly as well.
Fri, May 4
Thu, Apr 26
Wed, Apr 25
This now exists at https://phabricator.wikimedia.org/project/view/3356/ .
Another aspect of this would be to consider ShEx for selecting the data to be migrated. More info via https://phabricator.wikimedia.org/T192884 .
This would include considerations about
This sounds like something for ShEx: https://www.wikidata.org/wiki/Wikidata:WikiProject_ShEx .
This could also include tokens or API keys or things like that for the associated MediaWiki APIs or the respective SPARQL endpoints
@Magnus seems to be working on this: https://twitter.com/MagnusManske/status/986260652237967360
Tue, Apr 24
e.g. how to change the logo, license or user rights in a new Wikibase/ WDQS installation.
Find all other (registered) Wikibase instances that have information for "exact match" to something specific.
A good candidate query for a fresh Wikibase instance could also be to query the Wikibase registry for other instances of Wikibase.
We might also want to consider using some existing graphical UI for the SPARQL endpoint. One popular example is Blockly, and here are two papers that report on doing it for SPARQL:
Example for a user-friendly SPARQL interface
Mon, Apr 23
Apr 19 2018
Accessibility has multiple dimensions.
Mar 26 2018
I like the suggestion of adding a load-dependent server-side delay for API edits.
Mar 17 2018
There has been some erratic behaviour of this feature for Wikidata as well lately, e.g.
sometimes goes to where it would be expected, and sometimes to where the user is.
Mar 13 2018
Mar 12 2018
Dec 2 2017
That seems like a good option indeed. In that case, we'd need a way to pull the data back into the WDQS for visualization.
Oct 28 2017
Oct 18 2017
I would suggest to start the items without a "published in" statement, and to build a tool/ Wikidata game/ Mix'n match catalog for reconciling those mismatches.
Sep 25 2017
Here's a suggestion in terms of mechanisms to avoid malicious re-runs. I'm not sure how practical it is, but perhaps it helps us move forward
Sep 22 2017
Sep 9 2017
Sep 5 2017
Sep 1 2017
Aug 13 2017
Aug 9 2017
Aug 3 2017
I posted this over at https://github.com/SuLab/WikidataIntegrator/issues/33 .
Jul 11 2017
I think a Stop or Cancel button would be nice - sometimes, I know shortly after pressing the Run/ Play button that the query is not precisely what I wanted (e.g. because I changed something in one place, but should have done it in two places), and then I have to wait until it finishes or times out.
Jul 4 2017
Adding the Tools tag in the hope that this helps find people who could help address this issue.
Jun 29 2017
Jun 26 2017
Jun 21 2017
Affects audio files as well - just irritated uploaders at an audio-focused hackathon.
What about just "Describe the file" instead?
Jun 19 2017
Jun 15 2017
Jun 10 2017
Jun 6 2017
I agree that the current "add" buttons at the bottom are hard to find on large pages, and I have seen this put off newbies.
Replacing them with one predictably located bottom on the top sounds like progress to me.