2019-04-22 RPWG Meeting notes

Attendance

Update Attendee List

Action Items

Review and update Action Items

FOLIO Face-to-Face meeting plans

FOLIO Face-to-Face meeting plans -  

Working document for the Face to Face meeting:

https://docs.google.com/spreadsheets/d/1JELsHTfu_xYA1yTsyRCorZzEVofd8Njsg1Lo32rm_3s/edit#gid=1359585528

Goals

• Settle on what groups/individual should plan to attend

• Discuss and decide on meeting times/organization

• Identify any significant gaps in the program

German Folio Days and Data Warehouse Ideas

Veit presented his ideas from German Folio Days

• eUsage app data model

• how to “work” to a data model

• problem of slowly changing dimensions

NOTES:

-Veit presented ideas from German FOLIO days

-problems with underlying data structure

• UUIDs are string values, which have bad performance for joins (Nassib: UUIDs are Integers, so should be ok)

• Create Mapping Tables: map UUID to DWID

• recommend attributes with specific data types (e.g., Date, INT, String)

• dimension examples: Time, Patron, Item

-markers for slowly changing dimensions, e.g.

• service point

• loan transaction

-database has a lot of redundant information

Thoughts from Nassib

-we are using keys for joins, but sometimes the UUIDs are there in case you want to join them

-would be helpful for technical feedback in terms of work that has already been done (bring to Nassib first)

Veit: Problem of Slowly Changing Dimensions

-state of data structure impacts reporting

-report on states of data such as as is, as of, as posted, comparable each render different results

Thoughts from Nassib

-by default, we currently have fact tables linked to specific dimensions and an effective record date is stored

-there is some flexibility in the way elements impacted by time are modeled

-data warehouse impacted by the development of streaming functionality in FOLIO

Thoughts from Tod

-every record needs a created date and an updated date 

RPWG Projects

Review RPWG Project List

NOTES:

-is "filtering" to build out the data elements just for reporting the most efficient way to develop?

-will we develop all 250 reports?

-what scaling can we do at our institutions to support report development

Circ Item Detail Report Prototype

-latest update on progress?

eUsage Project

Please take a look at the documentation for API data elements from the eUsage app development team.

eUsage API data elements documentation: 
https://docs.google.com/spreadsheets/d/1CViG0LzMPpN2IVm1EM6vSEzVWnZvUJ0C61YbNP5vexA/edit?usp=sharing

• the "counter-reports" worksheet shows the metadata for the harvested reports.

• for eUsage, we do not actually save the single data fields of each report, but the monthly reports as a whole, with metadata to identify them

eUsage UI presentation:
The eUsage UI design includes a statistics previews backend that queries specific reports (identified by provider, date range, metric type etc.) and then processes the full report

Here is a presentation explaining this design with an example: https://docs.google.com/presentation/d/1r9KWetrYpQFd79j9uDRZkKEbigGp4mOqkh-a3nXJkq0/edit?usp=sharing

Some General Questions (from last meeting)

-custom fields?

-how many of the reports do we develop?

-next priority reports?

For our next meeting...

Next Topics:

• topic 1

• topic 2

• topic 3

Next meeting of the Report Prototype WG is scheduled for Monday, April 29 at 10:00am EST