Feature #5989
Updated by Matt Jones over 10 years ago
Currently the only usage stats we have in Metacat are the raw logs. This new service would provide several statistical reports in machine-readable format intended for efficient use on clients for building user interface displays that show those statistics. The service should include the following response statistics, and be extensible to add other tracked statistics as needed: # Number of views (defined as number of times the metadata has been viewed on the web) # Number of package downloads (needs definition) # Size in bytes of package downloads # Number of citations (implement in a second phase) For each of these statistics, calling apps should be able to constrain the results to only include certain records matching: pertaining to: # a PID or list of PIDs # a user or list of users (DN, or ORCID, or some amalgam -- to be discussed) # a time range # a spatial range For each of these statistics, calling apps should be able to request the statistic aggregated by several specific facets, including the following (in order of importance): # PID # User (DN, or ORCID, or some amalgam -- to be discussed) # Time range, aggregated to requested unit (day, week, month, year) # Spatial range, aggregated to requested unit (to be discussed) Intersections of these aggregated facets should also be possible, but are a lower priority than the facets alone. For example, when finished, one should be able to request the following reports, among others: # {Views,Downloads,Bytes,Citations} for a given Number of downloads by pid or list of pids # {Views,Downloads,Bytes,Citations} Number of downloads by user (aggregates across pids) # {Views,Downloads,Bytes,Citations} Number of downloads by month (aggregates across pids) # {Views,Downloads,Bytes,Citations} Number of downloads by spatial location (aggregates across pids) # {Views,Downloads,Bytes,Citations} for a given Number of downloads by pid by month for a specific time range # {Views,Downloads,Bytes,Citations} Number of downloads by user by month # etc. The download format (JSON?, XML?) should allow for an extended set of response variables, and an extendable set of aggregating facets. Need to discuss, but probably XML as that is DataONE's initial choice for all other services. Contemplate both if useful. discuss. The REST API for this service should be developed in the DataONE space, with intention of it being implementable by both other MNs and CNs in DataONE.