Metacat

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:

1. Number of views (defined as number of times the metadata has been viewed on the web)
2. Number of package downloads (needs definition)
3. Size in bytes of package downloads
4. 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 records matching:

1. a PID or list of PIDs
2. creator or list of creators (DN, or ORCID, or some amalgam -- to be discussed)
3. a time range of access event (upload, download, etc.)
4. ? spatial location of access event (upload, download, etc.)
5. ? IP Address
6. accessor or list of accessors (DN, or ORCID, or some amalgam, needs ACL -- to be discussed)

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):

1. User (DN, or ORCID, or some amalgam -- to be discussed)
2. Time range, aggregated to requested unit (day, week, month, year)
3. ? 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:

1. {Views,Downloads,Bytes,Citations} for a given pid or list of pids
2. {Views,Downloads,Bytes,Citations} by user (aggregates across pids)
3. {Views,Downloads,Bytes,Citations} by month (aggregates across pids)
4. {Views,Downloads,Bytes,Citations} by spatial location (aggregates across pids)
5. {Views,Downloads,Bytes,Citations} for a given pid by month for a specific time range
6. {Views,Downloads,Bytes,Citations} by user by month
7. 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.

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.