Date

Attendees

Discussion items

ItemNotes
AttendanceUpdate Attendee List
Action ItemsReview 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


Action Items