Page tree
Skip to end of metadata
Go to start of metadata









xSharon BeltaineCornell UniversityxSara ColglazierMount Holyoke College/Five Colleges

Elizabeth BerneyDuke University
Erin NettifeeDuke University

Joyce ChapmanDuke University
Karen NewberyDuke University

Elizabeth EdwardsUniversity of ChicagoxTod OlsonUniversity of Chicago

Claudius Herkt-JanuschekSUB HamburgxScott PerryUniversity of Chicago


Doreen HeroldLehigh University
Stefan StadtherrMPIL Heidelberg

Anne L. HighsmithTexas A&MxSimona TabacaruTexas A&M

Harry KaplanianEBSCOxKevin WalkerThe University of Alabama
xIngolf Kusshbz
Charlotte WhittIndex Data

Lina LakhiaSOASx

Andi Bihler

Munich Technical University Library

Joanne LearyCornell University
Uschi KluteGBV
xMichael PatrickThe University of Alabama
Vandana ShahCornell University

Nassib NassarIndex DataxAngela Zoss

Duke University

Veit KöppenUniversity Magdeburg
Lisa DeCarolisSmith College/Five Colleges
xLinda MillerCornell UniversityxElena O'Malley


Matt HarringtonDuke University     Holly MistlebauerCornell University
xJean PajerekCornell University

Discussion Items





Today's Attendance Taker: 

Today's notetaker:  Angela Zoss

Last week's notetaker: Vandana Shah

Review of Non-Clustered RA ReportsAngela

Angela will walk us through a review of Resource Access reports that did not fit into a cluster category. 

See the list at:

RA clusters have been uploaded to the Google drive. Next step was to create UXPROD issues in JIRA to represent each cluster. Each issue shows the reports included in each cluster, sorted by cluster labels. The po-mvp labels indicate that at least one inquisition needs this at go-live. Good news is that only half of the clusters in RA are needed at go-live. This will help with prioritization. Originally 100 reports had been added to the RA master sheet. Only 50 reports were clustered, as the remaining did not fit into any RA clusters. For example, reports on batch jobs - these could be moved elsewhere. Also some need to be pushed back into in-app.

Note: How current does the data for a given "real-time" report really need to be? Currently we are recording the need for current data as a simple "real-time" yes-or-no, and using this to decide whether a report is in-app or LDP. As we move towards planing operations, this seems to be too narrow. At UChicago, for example, discussions of real-time reports reveal that many reports could use information that is updated more than nightly, but hour or every fifteen minutes or a few minutes, are common and relatively few "real-time" reports really need to be up-to-the-second. Capturing some of this nuance could open up some possibilities as we are deciding whether how to provide a report. Additional possibilities could include selective updating of tables during the day, providing a framework for light scripting outside of the LDP, and there may be others. If we have more nuanced information about the requirements for current data, we would have a more realistic view of the needs of the report and possibilities for providing it.

Metadata Management Report Cluster ReviewVandana

Vandana will walk us through her analysis of Metadata Management reports to create clusters.

See the list at:

Additional Topics?All 
Topics for Future MeetingsAll

Review and update Topics for Future Reporting SIG Meetings 

Action items

  • Reporting Data Privacy to follow up with Jesse, Tod, and Cate, and Chair-Elect to determine approach to audit trails in LDP