Context
The Advancement department's Culture & Heritage team asked the Digital Public Library of America what their top structured data tasks were. They also included their top analytics tasks.
As part of our work to get ready for the GLAM Wiki conference, let's review the top requests and see if we can meet needs outlined.
Tasks
- T244712: Allow users to query mediarequests using a file page link - Query mediarequests API with a file name
This is an old one that has a lot of discussion on it that I think is mostly missing the point and might be discouraging any developer work, but the request is simple. If I have a list of files to query in the API, I cannot actually send a request without first doing another query to the Commons API to translate the file name to a server path. This is a major performance issue over large sets, because this additional query for every file is a significant cost over millions of files.
- T235588: PageViewInfo should include media counts on ?action=info for stuff in File namespace - Include media requests in PageViewInfo
This idea for incorporating media requests in the PageViewInfo extension would greatly improve ease of access to the data, since you could then get the data you wanted from the Commons API itself, just using a category generator and the right page properties.
- T344857: Access to full dataset in PageViewInfo/T344856: "all time" granularity for pageviews prop/T238800: Allow monthly granularity for PageViewService at least for uniques -
These are a set of tickets around extending the time and granularity of available data in PageViewInfo. It's mainly only of use to me if T235588: PageViewInfo should include media counts on ?action=info for stuff in File namespace is also being done, but these would make the data you could get from the API actually useful for our applications, whereas the current design with only a moving window of a few days' data makes this more useful only for the novelty right now.
- NTY AQS data in wikireplicas
Generally, one thing that is not currently captured in Phabricator—because I am not sure what it would entail or if it's even feasible—would be inclusion of the data behind all the AQS endpoints in the actual wiki replicas such that you could do a query in Quarry where you, for example, join categorylinks and mediarequests tables and get page view reports that way.