2019-07-01 Reporting SIG Meeting notes
- Sharon Markus
- Vandana Shah
- lm15@cornell.edu
- Nassib Nassar
Date
Attendees
Present? | Name | Organization | Present? | Name | Organization |
|---|---|---|---|---|---|
| x | Sharon Beltaine | Cornell University | Sara Colglazier | Mount Holyoke College/Five Colleges | |
| Elizabeth Berney | Duke University | Erin Nettifee | Duke University | ||
| Joyce Chapman | Duke University | Karen Newbery | Duke University | ||
| Elizabeth Edwards | University of Chicago | x | Tod Olson | University of Chicago | |
| x | Claudius Herkt-Januschek | SUB Hamburg | Scott Perry | University of Chicago | |
| Doreen Herold | Lehigh University | Stefan Stadtherr | MPIL Heidelberg | ||
| x | Anne L. Highsmith | Texas A&M | x | Simona Tabacaru | Texas A&M |
| Harry Kaplanian | EBSCO | x | Kevin Walker | The University of Alabama | |
| x | Ingolf Kuss | hbz | Charlotte Whitt | Index Data | |
| Lina Lakhia | SOAS | Michael Winkler | OLE | ||
| Joanne Leary | Cornell University | Uschi Klute | GBV | ||
| x | Michael Patrick | The University of Alabama | x | Vandana Shah | Cornell University |
| x | Nassib Nassar | Index Data | x | Angela Zoss | Duke University |
| x | Veit Köppen | University Magdeburg | Lisa DeCarolis | Smith College/Five Colleges | |
| x | Linda Miller | Cornell University | x | Elena O'Malley | Emerson |
| x | Matt Harrington | Duke University | Holly Mistlebauer | Cornell University | |
| Eric Pennington | Texas A&M | x | andi | ||
Discussion Items
| Item | Who | Notes |
|---|---|---|
| Attendance | Sharon | Today's Attendance Taker: Linda Miller Today's notetaker: Vandana Shah Last week's notetaker: Sharon Beltaine |
| Updates from Various Reporting Related Groups and Efforts | Various | Each week we will set aside some time for updates from reporting-related groups or discussions:
Along with the main LDP for querying, there is potential for a second database that is normalized in a way that the main LDP will not be, and this second database will be useful for cross-app reporting. We need to get more test data. A prototype is under development. Regarding e-usage, is there a use case for taking LDP data and feeding it back into apps? How would we construct a workflow for this? Is real-time data needed, and if so, how can that be incorporated? There would be data storage concerns. Data dictionary - This will be discussed in greater detail at the LDP Report Working Group Meeting, and then brought to the Reporting Sig.
There are several issues here. In terms of patron data privacy, if we all follow the GDPR requirements, they are stringent enough to cover all US data privacy laws. One straight-forward way is to make all reports with personal data as in-app, and not LDP. For those that can't be made into in-app, we would need to identify personal data in each report , and then determine whether these reports remain meaningful if all personal data are removed from them. It makes sense to first flag all reports that contain personal data, and then take these to the groups that requested them, for a discussion. In terms of staff data privacy (data that have been 'touched' by a staff member) - does the GDPR provide the same level of privacy to staff? There are cases when it is important to know what the 'touch' trail was. Is a staff audit more likely to happen in cataloging? The audit trail will not be uniform across modules. Whereas such staff audits would not be included in German library systems, they are included in US systems. For audit trails, we need to take a broader view, and have a wider conversation; talk with Product Council.
LDP software was loaded onto local machines, but there isn't much data as yet. Some queries were run; need more data for report testing.
Looking at e-usage, there are analytical queries, and more in-app requirements. It is difficult to guarantee a quick response from warehouse queries, so if there is loop-back of the data from LDP to in-app, then the in-app user interface has to account for the delay (if it's an in-app report that's being run on LDP data). An alternative is to create a separate, normalized database. That would be simpler to develop and maintain as compared to the LDP. A proof-of-concept of this normalized database is being developed and will be taken to the e-usage group.
|
| Resource Access Report Clustering | Angela Zoss | Angela will provide an update on her work with members of the Resource Access SIG to cluster the Resource Access report requirements. The list of resource access reports have a lot of overlap. The SIG looked at 98 RA reports, and created 'clusters' - areas of commonality for reports, so that it will be easier to see whether a single query can apply to multiple reports. This will help report prototyping as well as users; it can streamline workflow. In-app reports and those with Atlas components are also included in the clusters, and external reports can also be tied into the clusters. This will provide a more complete view of all reports relating to the same broad cluster. Cluster tags will make sorting easy, clusters can also highlight data privacy issues (e.g., identifying a cluster where a majority of the reports, LDP or in-app, all contain personal data). |
| Additional Topics? | All | |
| Topics for Future Meetings | All | Review and update Topics for Future Reporting SIG Meetings |
Action items
- Reporting Data Privacy Group to flag reports that may have user data
- Reporting Data Privacy to follow up with Jesse, Tod, and Cate, and Chair-Elect to determine approach to audit trails in LDP