...
| 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? Thre would eb data storage concerns. Data dictionary - This will be discussed in greater detail at the LDP Report Working Group Meeting, and then we will bring it 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. and the second is to do with staff data privacyIn 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. There are resource access reports with overall throughout the list of resource access reports. 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. |
| Additional Topics? | All | |
| Topics for Future Meetings | All | Review and update Topics for Future Reporting SIG Meetings |
...