Project:Analytics/PubPeer - Revision history

Harej: Observation

2026-01-19T21:09:42Z

Observation

← Older revision		Revision as of 21:09, 19 January 2026
Line 66:		Line 66:
	* '''Frequency of Runs:''' Designed to be run periodically (e.g., via cron) using the --update flag for index_pubpeer.py		* '''Frequency of Runs:''' Designed to be run periodically (e.g., via cron) using the --update flag for index_pubpeer.py
	* '''Dismissals Not Recognized:''' The logic to recognize user removals of report entries does not work yet and has been disabled.		* '''Dismissals Not Recognized:''' The logic to recognize user removals of report entries does not work yet and has been disabled.

			== 2026-01-19 Observation ==
			Example edit: https://en.wikipedia.org/w/index.php?title=Wikipedia:PubPeer/By_article/Z&diff=prev&oldid=1333802277

			Sometimes, an article will have multiple PubPeer IDs, with different sets of comments on each. This causes the report generation process to be confused. Should probably canonize on a different identifier.

Harej: Updating notes based on current repository

2026-01-13T23:37:23Z

Updating notes based on current repository

← Older revision		Revision as of 23:37, 13 January 2026
Line 17:		Line 17:

	==Process==		==Process==
	* Initial ~~seed~~:		=== Data collection and indexing ===
	** ~~Build pageset~~		; PubPeer Data (index_pubpeer.py)
	*** Pull usages of identifiers from ~~Wikimedia Cloud DB Replicas~~		* '''Initial Seed:'''
	*** Create database table (~~wikipedia~~):		** Starts from 2000-01-01
	**** id (~~incrementing key~~)		** Uses an initial large date window (2000-01-01 to 2014-12-31) followed by 30-day increments
	**** language_code		** API query handles pagination (per_page: 300) and automatically reduces the time window if the result set hits the 10,000-record limit to ensure no data is missed
	**** mw_page_id		* '''Subsequent Builds:'''
	**** mw_page_title (probably should have a process to refresh this before the full process runs)		** Triggered via <code>python index_pubpeer.py --update</code>
	** API query: <code>~~2006-01-01~~.~~.2025~~-12-31</code>		** Identifies the latest_comment_date from the local database and starts fetching from that date to the present
	*** ~~To prevent overloading the script, I~~'~~ll probably end up going one month at a time, 2006-01-01..2006-01-31~~		* '''Database Updates:'''
	** ~~Iterate through as many pages as needed to get to~~ the ~~end~~		** Updates the pubpeer_articles table
	** Build internal database (pubpeer_articles table):		** Fields: id_pubpeer (URL), id_doi, id_pubmed, id_arxiv, title (truncated to 250 chars), and time_last_comment
	*** id_pubpeer (~~key~~)		; Wikipedia Citations (index_citations.py)
	~~***~~ id_doi (~~update on conflict~~)		* '''Process:'''
	*** id_pubmed (~~update on conflict~~)		** Pulls current external links from Wikimedia Cloud DB Replicas for DOI (org.doi.), PubMed (gov.nih.nlm.ncbi.pubmed.), and arXiv (org.arxiv.)
	*** ~~id_arxiv~~ (~~update on conflict~~)		** Restricted to Main (0) and Draft (118) namespaces
	**~~Build minimal citations database~~ (~~citations table~~):		** Matches these links against the local pubpeer_articles table
	***id_pubpeer (key to pubpeer_articles table)		* '''Database Updates:'''
	***~~id_wiki_page (key to~~ wikipedia table)		** '''wikipedia table:''' Stores language_code, mw_page_id, mw_page_title, and mw_talk_page_id. Page titles are refreshed during each run
	***cited_id_type (integer)		** '''citations table:''' Maps id_pubpeer to id_wiki_page
	****0 = ~~unknown/other~~		** '''Stale Data:''' Automatically removes citations from the local database if the link has been removed from Wikipedia
	****1 = ~~doi~~
	****2 = ~~pubmed~~		=== Reporting and wiki updates ===
	****3 = ~~arxiv~~		* '''Wiki Maintenance:'''
	****Why not use enum? It'~~s easier to add a new value Python-side than it is to carry out a database schema migration~~		** Automatically handles page moves and deletions via sync_wikipedia_titles.py before updating reports
	***~~cited_id_value~~ (~~string~~)		* '''Report Generation (report.py):'''
	***time_last_updated_table (~~<code~~>~~null</code> when created~~)		** '''Alerts Report:''' Lists new citations (time_last_updated_table IS NULL) or existing citations with new comments (time_last_comment > time_last_updated_table)
	***~~time_last_talk_page_post~~ (~~<code>null<~~/~~code> when created~~)		** '''Most Affected Report:''' Lists Wikipedia articles with the highest number of unique PubPeer-commented citations
	*** ~~time_most_recent_comment~~ (~~on conflict, update if submitted > stored~~)		** '''Article List Reports:''' Large table and alphabetical subpages (/By article/A, etc.) listing all matched citations
	**~~Post initial~~ report to ~~wiki as a table~~		** '''Frequency Report:''' Aggregates by PubPeer article to show which research is most cited across Wikipedia
	**~~Post initial notification~~ that the ~~report is posted~~		* '''User Interactions (Dismissals):''' (pending working implementation)
	* ~~Subsequent builds~~:		** The bot reads the current wiki report and compares it to its previous version
	** Get most recent <code>time_most_recent_comment</code> from database		** If an editor removes a row from a wiki table, the bot marks that citation as dismissed = TRUE in the database and stops reporting it
	** API query: ~~<code>that date...present day</code>~~
	** ~~Iterate through as many result~~ pages ~~as needed (probably only one page)~~		=== Database Schema (schema.sql) ===
	** ~~Submit into database~~, ~~which should transparently handle conflicts~~		* '''wikipedia:''' id, language_code, mw_page_id, mw_page_title, mw_talk_page_id, librarybase_id
	** ~~Build new wiki table based on citations database table~~		* '''pubpeer_articles:''' id_pubpeer, id_doi, id_pubmed, id_arxiv, title, time_last_comment
	*** Check database for		* '''citations:'''
	****null time_last_updated_table		** Links articles to wiki pages
	****time_most_recent_comment > time_last_updated_table		** cited_id_type: 1 (DOI), 2 (PubMed), 3 (arXiv)
	** Come up with alerts describing changes to table.		*** 0 is reserved for "other"
	*** Retire old notifications to a subpage		** time_last_updated_table: Tracks when the wiki report last included this citation
	*If/when talk page notifications ~~are approved:~~		** time_last_talk_page_post: (Reserved for future talk page notifications)
	**~~Check database~~ for		** dismissed: Boolean flag for editor-driven dismissals
	***null time_last_talk_page_post
	***time_most_recent_comment > time_last_talk_page_post		=== Post-Implementation Status ===
	**Queue up talk ~~pages to notify~~		* '''Talk Page Notifications:''' Code includes fields for tracking (time_last_talk_page_post), but the active workflow currently focuses on centralized reports (Wikipedia:PubPeer/*) rather than automated talk page posting
	**Check presence for ~~message already on talk page~~.		* '''Frequency of Runs:''' Designed to be run periodically (e.g., via cron) using the --update flag for index_pubpeer.py
	***No message comment: ~~add post~~ to ~~talk page~~		* '''Dismissals Not Recognized:''' The logic to recognize user removals of report entries does not work yet and has been disabled.
	***Presence of ~~message comment: skip over talk page~~

Harej: Update resources

2026-01-09T02:00:43Z

Update resources

← Older revision		Revision as of 02:00, 9 January 2026
Line 11:		Line 11:
	* Wikimedia Cloud Services		* Wikimedia Cloud Services
	** Toolforge: project "pubpeer"		** Toolforge: project "pubpeer"
	** Cloud VPS: project "wikicite", VM wikicite-refsdb-proc-1, Trove DB ~~instance~~		*** Don't think it's being used for anything
			** Cloud VPS: project "wikicite"
			*** VM wikicite-refsdb-proc-1.wikicite.eqiad1.wikimedia.cloud
			*** Trove DB: ouqdvgrbzf3.svc.trove.eqiad1.wikimedia.cloud

	==Process==		==Process==

Harej: resources

2026-01-08T20:15:15Z

resources

← Older revision		Revision as of 20:15, 8 January 2026
Line 11:		Line 11:
	* Wikimedia Cloud Services		* Wikimedia Cloud Services
	** Toolforge: project "pubpeer"		** Toolforge: project "pubpeer"
	** Cloud VPS: project "wikicite", Trove DB instance		** Cloud VPS: project "wikicite", VM wikicite-refsdb-proc-1, Trove DB instance

	==Process==		==Process==

Harej: New schema!

2026-01-08T03:52:46Z

New schema!

← Older revision		Revision as of 03:52, 8 January 2026
Line 22:		Line 22:
	**** mw_page_id		**** mw_page_id
	**** mw_page_title (probably should have a process to refresh this before the full process runs)		**** mw_page_title (probably should have a process to refresh this before the full process runs)
	** API query: <code>2006-01-01...2025-12-31</code>		** API query: <code>2006-01-01..2025-12-31</code>
			*** To prevent overloading the script, I'll probably end up going one month at a time, 2006-01-01..2006-01-31
	** Iterate through as many pages as needed to get to the end		** Iterate through as many pages as needed to get to the end
	** Build internal database (pubpeer_articles table):		** Build internal database (pubpeer_articles table):
Line 32:		Line 33:
	***id_pubpeer (key to pubpeer_articles table)		***id_pubpeer (key to pubpeer_articles table)
	***id_wiki_page (key to wikipedia table)		***id_wiki_page (key to wikipedia table)
			***cited_id_type (integer)
			****0 = unknown/other
			****1 = doi
			****2 = pubmed
			****3 = arxiv
			****Why not use enum? It's easier to add a new value Python-side than it is to carry out a database schema migration
			***cited_id_value (string)
	***time_last_updated_table (<code>null</code> when created)		***time_last_updated_table (<code>null</code> when created)
	***time_last_talk_page_post (<code>null</code> when created)		***time_last_talk_page_post (<code>null</code> when created)

Harej: I think that's the workflow

2026-01-08T00:52:07Z

I think that's the workflow

← Older revision		Revision as of 00:52, 8 January 2026
Line 16:		Line 16:
	* Initial seed:		* Initial seed:
	** Build pageset		** Build pageset
	** ~~Start~~ from <code>2006-01-01...2025-12-31</code>		*** Pull usages of identifiers from Wikimedia Cloud DB Replicas
			*** Create database table (wikipedia):
			**** id (incrementing key)
			**** language_code
			**** mw_page_id
			**** mw_page_title (probably should have a process to refresh this before the full process runs)
			** API query: <code>2006-01-01...2025-12-31</code>
	** Iterate through as many pages as needed to get to the end		** Iterate through as many pages as needed to get to the end
	** Build internal database:		** Build internal database (pubpeer_articles table):
	*** id_pubpeer (key)		*** id_pubpeer (key)
	*** id_doi (update on conflict)		*** id_doi (update on conflict)
	*** id_pubmed (update on conflict)		*** id_pubmed (update on conflict)
	*** id_arxiv (update on conflict)		*** id_arxiv (update on conflict)
	*** ~~time_last_notified_wiki~~ (<code>null</code> when created)		**Build minimal citations database (citations table):
			***id_pubpeer (key to pubpeer_articles table)
			***id_wiki_page (key to wikipedia table)
			***time_last_updated_table (<code>null</code> when created)
			***time_last_talk_page_post (<code>null</code> when created)
	*** time_most_recent_comment (on conflict, update if submitted > stored)		*** time_most_recent_comment (on conflict, update if submitted > stored)
			**Post initial report to wiki as a table
			**Post initial notification that the report is posted
	* Subsequent builds:		* Subsequent builds:
	** Get most recent <code>time_most_recent_comment</code> from database		** Get most recent <code>time_most_recent_comment</code> from database
	** ~~Start from~~ <code>that date...present day</code>		** API query: <code>that date...present day</code>
	** Iterate through as many result pages as needed (probably only one page)		** Iterate through as many result pages as needed (probably only one page)
	** Submit into database, which should transparently handle conflicts		** Submit into database, which should transparently handle conflicts
			** Build new wiki table based on citations database table
			*** Check database for
			****null time_last_updated_table
			****time_most_recent_comment > time_last_updated_table
			** Come up with alerts describing changes to table.
			*** Retire old notifications to a subpage
			*If/when talk page notifications are approved:
			**Check database for
			***null time_last_talk_page_post
			***time_most_recent_comment > time_last_talk_page_post
			**Queue up talk pages to notify
			**Check presence for message already on talk page.
			***No message comment: add post to talk page
			***Presence of message comment: skip over talk page

Harej: Start

2026-01-07T23:58:51Z

Start

New page

==API==
https://dashboards.pubpeer.com/docs/api#/operations/partner

Relevant parameters:
* <code>page</code>: start with <code>1</code> then iterate based on whether there are more results
* <code>per_page</code>: set at maximum value <code>300</code>
* <code>sort</code>:
* <s><code>published_at</code></s>: concerns when the document was ''published''; I only care about ''comments''

==Resources==
* Wikimedia Cloud Services
** Toolforge: project "pubpeer"
** Cloud VPS: project "wikicite", Trove DB instance

==Process==
* Initial seed:
** Build pageset
** Start from <code>2006-01-01...2025-12-31</code>
** Iterate through as many pages as needed to get to the end
** Build internal database:
*** id_pubpeer (key)
*** id_doi (update on conflict)
*** id_pubmed (update on conflict)
*** id_arxiv (update on conflict)
*** time_last_notified_wiki (<code>null</code> when created)
*** time_most_recent_comment (on conflict, update if submitted > stored)
* Subsequent builds:
** Get most recent <code>time_most_recent_comment</code> from database
** Start from <code>that date...present day</code>
** Iterate through as many result pages as needed (probably only one page)
** Submit into database, which should transparently handle conflicts