daniel-mietchen / ideas

A dumping ground for halfbaked ideas, some of which will hopefully be worked on soon

About

This repo is for keeping and possibly developing ideas (and I am mainly thinking of research ideas here, though in a broad sense) that I

• cannot immediately put into practice myself
• think may be worth another look, including by people who come in here via search engines

I am also experimenting with using this repo for managing some of my to-do stuff in general, so not just broad ideas but also small things to do when I have 5 min of time, an hour or a day. While many of these things are one-off, there are also recurring activities.

Mechanics

I have yet to figure this out in detail, but probably mainly via issues, perhaps with the "documentation" label for things that are about the repo rather than about research ideas. Some of the research ideas may end up in the Journal of Brief Ideas, others in Research Ideas and Outcomes, while yet others may go elsewhere or simply stay here.

Quotes about ideas

I find it inspiring to browse through collections of quotes around ideas and related concepts. A good starting point here is Wikiquote, which gives us, for instance, this one from Mary Quant:

"One thing I learnt was never to hoard ideas because either they are not so relevant or they've gone stale. Whatever it is, pour them out."

Files in this repo

• research-interests.md — an attempt to explore interactions between different lines of research
• hashtags.md — keeps track of hashtags of interest to me
• labels.md — keeps track of the labels I am using in this repo

ideas's Issues

Analyze all Jupyter notebooks mentioned in PMC

Jupyter notebooks are a popular vehicle these days to share data science workflows. To get an idea of best practices in this regard, it would be good to analyze a good number of them in terms of their reproducibility and other aspects of usability (e.g. documentation, ease of reuse).

A search in PubMed Central reveals the following results:

• query for Jupyter
• query for ipynb

Ping Wikidata item talk page upon publication of new literature on the topic

e.g.
https://www.wikidata.org/wiki/Talk:Q654718
for new papers tagged with P921:Q654718

Document how to clone GitHub repos with all associated issues and labels

By default, the issues and labels are not brought over, but there are mechanisms to bring them over and maybe even to sync in some way.

May be useful for, say, cloning a repo like
https://github.com/okfde/de.opendataday.org
to build a site for a specific event.

Estimating 1h to get started.

A /Queries subpage for Wikidata items and properties

Could be based on #11.

Review Google Alerts

including those from Scholar.

Recurrent. Perhaps 1h each time.

Devise a way of integrating learning into this system

e.g.
https://github.com/Daniel-Mietchen/learning2code

Estimating 1h to get started

Rethink the way I am keeping track of events

Perhaps a dedicated repo or some different way of using
https://github.com/Daniel-Mietchen/talks/ ?

Reply to Kopiersperre with Query from Wikidatafacts

as per https://twitter.com/WikidataFacts/status/833778469930692608 and https://www.wikidata.org/wiki/User_talk:Daniel_Mietchen#Research_Bot

Look into more examples for Scholia

https://tools.wmflabs.org/scholia/

1h to get started

Review learning progress

and revise issues as necessary

Recurrent. perhaps 1h each time.

Watch a talk

as per
https://github.com/Daniel-Mietchen/datascience/blob/master/cinema.md#maybe-watch-in-the-future .

Typically takes 1h, so adding that label.

Devise a system for using small time slots effectively to get little things done

I often hear people say "I'll do that if/ when I have time", and I sometimes say that too, but I don't have a way to keep track of those things, nor to prepare for them.

In other words, suppose I have 5 min between two longer activities, how can I use them most effectively?

Lots of options, e.g.

• some physical activity (e.g. pushups)
• some mental activity (e.g. trigger a random word generator and try to spin those generated words into a coherent short story)
• some digital activity (e.g. https://tools.wmflabs.org/wikidata-game/distributed/# or https://tools.wmflabs.org/wikidata-game/# )
• something else.

What about a 12 minute slot, an hour, a day or a week?

In any case, it would be good to have a system for that.

Think about specific labels for learning targets

e.g. Python, Jupyter

Devise system to get physical activity into the small time slot system

as per #7 , using physical .

Expecting 1h to get started, so adding that label.

Review GitHub notifications

Recurrent. Perhaps 1h each time.

Collect GitHub ProTips

At the bottom of pages on GitHub (e.g. issue lists), there are sometimes little messages like

ProTip! What’s not been updated in a month: updated:<2017-01-22. 

or

 ProTip! Type g p on any issue or pull request to go back to the pull request listing page. 

It would be useful to have a system to keep track of these and to use them as some sort of cheat sheet, which I suspect is existing somewhere already.

1h to get started.

A HotCat equivalent for Wikidata

Items on Wikidata are often not classified to the optimal level of granularity, in part because there are no tools (at least none known to me) that would help with that.

Some inspiration here could be what HotCat does for categories on Wikimedia sites.

Look into PyCharm

as per
https://www.jetbrains.com/pycharm/ .

Perhaps 1h to get started.

Add recurring stuff to README or other file in repo

update label-based search strings as needed

1h to get things started.

Look into test-driven development

As per
https://en.wikipedia.org/wiki/Test-driven_development .

1h to get started.

Go through Source MD issues and file bugs as appropriate

as per
https://www.wikidata.org/wiki/Wikidata:WikiProject_Source_MetaData/Source,_M.D./Tests

Estimating 1h to get started

Add time-scale labels to all open issues

as per #7

Specific labels for "tools"?

e.g. #40 .

5min

Look into Python self

e.g. with https://pythontips.com/2013/08/07/the-self-variable-in-python-explained/ .

1h to get started.

Devise a system to integrate notes from other repos/ platforms here

Perhaps 1h to get started.

Centralizing the collection of Wikidata queries

While there is
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries/examples ,
lots of useful Wikidata queries are being collected elsewhere, e.g. at

• https://github.com/JJ/wikidata-queries
• https://github.com/sebotic/SPARQL
• https://twitter.com/WikidataFacts
• https://twitter.com/kidehen/status/830192903263764481 .

It would be useful to collect them more systematically, like Quarry does for SQL queries, and a Phabricator ticket has been opened for that at
https://phabricator.wikimedia.org/T104762 .

Look into Python classes

as per
https://docs.python.org/3/tutorial/classes.html
or
https://learnpythonthehardway.org/book/ex40.html

1h to get started.

Look into unit testing

Try to understand it enough to be able to devise a plan for learning to do it.

Expecting 1h to get things started.

Build WikiFactMine pipeline for P921 (main subject)

As per
https://meta.wikimedia.org/wiki/Grants:Project/WikiFactMine
and
https://www.wikidata.org/wiki/Property:P921

Bug reports to science

Lots of things in the research ecosystem would benefit from improvements. It would be good to have a collection of concrete issues to look at, which could then be tracked in a more systematic fashion.

Could be coupled with https://openscience.ub.uni-bielefeld.de/ .

Review Tweeted Times

As per
https://www.wikidata.org/wiki/User:Daniel_Mietchen/TweetedTimes .

Recurrent. Perhaps 1h each time.

Look into 'logging' library

https://docs.python.org/3.6/library/logging.html

initially 1h to read up and get started

Think about using milestones here, e.g. for handling external deadlines

This may work better if implemented via
https://github.com/Daniel-Mietchen/events .

Estimating 1h to get started.

Add usage info for labels into README

As per
https://github.com/Daniel-Mietchen/ideas/blob/master/README.md
and #7 #14 .

Expecting ca. 30min, so adding 1h label.

Add recurring label to all existing issues where applicable

https://github.com/Daniel-Mietchen/ideas/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20

Pinging #7

Think about using this repo to keep track of things to do in my other repos

There are good arguments for keeping the issues with the repo they are concerned with.

However, it could well be useful to have all my main activities - regardless of the precise repo (or other platform) in one system, e.g. here.

Giving it 5min to get started - likely needs more time.

Should this repo have labels for months, years, days of the week and such?

Or should these better go to /events?

5mins to get started.

Make plan for how to learn pandas

as per
http://pandas.pydata.org/ .

Estimating 1h to get things started.

Look into GitLab

as per
https://www.gitlab.com/ .

Things to look at:

• licensing
• suitability for code and pipelines
• suitability for data
• suitability for management purposes similar to the issues in this repo
• ease of use

1h to get started

Make How-to issues for each label

Open a new issue, add the target label, document usage of the label, refer to this issue (#14), add documentation label.

I expect this to take on the order of 5min per label, so I'm adding a 5min label now.

Leave open for a week or so to see how things work.

Build an open science museum

As the concept of open science is becoming more popular, it is worth taking a step back on occasion to look at how it evolved in theory and practice. In many other contexts, such functionality is provided by museums, so for the time being, the thoughts here are going to be assembled under the assumption that there will be an Open Science Museum one day.

The term is intentionally ambiguous in that it can be interpreted to refer to an open science museum as described above or an open science museum, which would be pretty similar to the classical science museums, but with a focus on open science, hands-on and reproducibility.

I have set up a dedicated repo for this under https://github.com/Daniel-Mietchen/open-science-museum .

A search engine for finding academic papers using the same or similar mathematical formulas

The basic idea here is to go through the literature and to use the similarity of the maths used in different papers as another discovery mechanism for finding related papers, i.e. papers that are related via their maths, rather than the specific knowledge domain they focus on (if any).

Some basic discussion of the concept is in
http://mathoverflow.net/questions/162487/which-tools-can-identify-scholarly-papers-that-use-the-same-types-of-equations ,
where Approach0 was recently mentioned as an open-source tool that has started to do this for MathOverflow.

Recent queries feed

from https://query.wikidata.org/ or its API

Close browser tabs

and document here if/ when something needs further thought.

Recurrent. Should not take more than 1h each time.

Devise a system for prioritizing the review of open issues

May need specific labels like "High priority" or "deadline" or "today"/ "tomorrow" / "this week"/ "next week" etc.

5min to get things started.

Rethink use of the "craft" label

As per
craft .

Perhaps solved by #14 but not sure.

5 min for the moment.

Review all open issues

Including this one:
https://github.com/Daniel-Mietchen/ideas/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20 .

Document things that need to be documented beyond adjusting labels.

Expecting less than 5 min per issue, so giving it the 5min label.

Rethink the way I am handling bookmarks

1h to get started

Think about new labels for /events

as per
https://github.com/Daniel-Mietchen/events .

Perhaps labels specific for years or months
as well as meta labels like "documentation".

Estimating 5 min to get started.

Look into the Python Debugger

as per
https://docs.python.org/3/library/pdb.html

Probably 1h to read up and get things started.