Data Structuring

Generally, JSON:`

{ "title": "", "id": null, "journal": "name", "DOI": "link", "date_interested": "yyyy/mm/dd", "date_started": "yyyy/mm/dd", "date_finished": "yyyy/mm/dd", "referrer": "link" "notes": [ "user_description", "second_link_etc" ] }

Journal (Where is it Accessible?)

Assuming accessed JSTOR, MUSE, Wiley, SagePub, etc. or the journal's own website. May have unique article identifier, otherwise use DOI or equivalent. Prefer to track which articles read, not how many of any particular volume. Kitsu does this by listing all chapters from beginning of serialization to current/end. Only for long-running journals does this get cumbersome, and sometimes there is historical interest in journals that ceased publication and were either reborn (singular successor, after last issue) or narrowed/broadened, possibly while the original publication continued. Handling this case should be easy, journal staff don't need to be tracked for casual reader... Just add parent relation to journal same as usual. Competing journals interesting to compare, but enough to list in description, not as a data relation.

Referrer (What made you interested? Google search result? [From a known interest?] Citation in previously read paper/book?)

Assume direct influence. Should (policy) enter things chronologically. Difficulty is moving custom entry (ex jstor stable link) when becomes 'trusted' (using model of kitsu mods approving database changes), and onboarding/importing on first use. New users already have to authenticate, so the only gatekeeping should be interacting with a friendly mod. The respect goes both ways: genuine users will take time to methodically make true entries, stored on user's device until approved for merge into database, and as such database mods can review accounts for likelihood of spam. If found to be malicious, mods can remove all user's files, and entries in common with genuine users will be refactored to preserve the genuine user's progress. Probably able to quickly and accurately represent 'referred-to' (forward) by tracing 'referrers' (backwards), since only waiting for entry. Could implement 'Plan-to-Read' list that pre-fills new entry with "date-interested", which would help in the case of boredom and need something to read, but most likely will be full of 'On-Hold' as jump through interests. 'Dropped' should contain only a minimal data set, if exists.