...
- E Pennington
- Former user (Deleted)
- Kevin Walker
- Angela Zoss (Old)
- Matthew Harrington
- Roman Ruiz-Esparza
- Nassib Nassar
- lm15@cornell.edu
- Vandana Shah
- Michael Patrick
NOTES
-Establish Naming Conventions for reports and queries
-modularizing queries
-core query to generate 1st stage table
...
Purpose of establishing naming conventions:
...
- organization should be simple, clear, and logical
-include date
-use short description focusing on function eg Count Loans for Locations
-information should come from API structure, FOLIO elements
-report: how queries used
-query describes what the query does
-show app name in the report code? eg RA, RM, etc.
- need to be useful for end users
- organization of reports, queries should be logical and simple as possible; library technology right now has incredible complexity, explodes in every corner; would like to organize things so it's clear and simple for people coming in
- what we're really doing is taxonomy, which is both organization and naming
Example: Circulation Item Detail Report
- there are two main types of circulation reports: aggregate counts, transaction details
- "circulation" usually refers physical items, and usage usually refers to electronic
Elements relevant to naming:
| Element | Value for Example |
|---|
...
| Report | Description |
|---|---|
| Requirements ID |
...
| ID401 | ||
| JIRA Ticket |
...
...
| Name of Report |
...
|
Question: do we really need to specific "bibliographic detail" in the report name? Is it reasonable to assume bibliographic data will be included?
(extensive discussion)
General workflow for reports:
- cluster reports
- figure out the query that includes all necessary data elements
- build additional queries that filter/subset that full query as specified
The report itself is focused on how the report is going to be used, not about how to get the data. This will also be the name of the JIRA issue. Report Naming Construct
| ||
| Name(s) of query(ies) | The query is how to get the data. Possible naming convention for short names: verb, source data, function | |
| Short name(s) of query(ies) | ||
| Umbrella category for report | Circulation | Group reports by the 5 most used apps of FOLIO that reports will be generated for:
just use umbrella category to organize reports, not to name them (could be the directory structure in LDP GitHub) use tagging (e.g., in GitHub?) to help organize reports, maybe to add original functional area to query |
Additional information that would be useful when browsing reports in, e.g., GitHub:
|
Report Name Discussion:
Question: do we really need to specific "bibliographic detail" in the report name? Is it reasonable to assume bibliographic data will be included?
(extensive discussion)
Upper-level grouping options:
- Circulation (use App names/API structure; users, circulation, inventory, finance and orders, resource management)
- maybe this is most readable for non-expert analysts
- Resource Access (stick with current functional areas)
- useful for report development, but maybe not useful for UX; could potentially just include tags on GitHub
-just use functional area to organize reports, not to name them
-use tagging (e.g., in GitHub?) to help organize reports
Linking between JIRA and future report documentation (GitHub);
- Issue title should change to the new naming convention
- all dwreport issues stay in REP
- to filter down to reporting umbrella categories, create a new field? add tags? (TBD)
Report Naming Construct
-
-by = filter or focus
-with = what the report includes, details
General workflow for reports:
- cluster reports by topic/purpose/common data elements
- figure out the query that includes all necessary data elements (full, larger report with all the difficult joins)
- build additional queries that filter/subset that full query as specified
Filtering Questions and Names of Reports and Queries
...
- only include columns for which there is a one to one join
...
- Where vs Select Filtering
- Query = join loans
- Query = filter material types
Loans Report
Loans Query
What should we build?
-full, larger report with all the difficult joins
Name of Quer(ies):
Short name(s) for queries:
Circulation Detail Report
-counts, aggregation
-detail about function
-cluster report topics; elements in common could be factored into smaller queries
Discussion items
...
Eric and Sharon met with Charlotte Whitt about overlaps between REP-189 and UXPROD-892 and UXPROD-880. Charlotte will propose replacing UXPRD-892 and UXPROD-880 with REP-189 to the MM SIG. There are also some follow-up questions for this group on how to deal with Repeating Fields.
We need to determine how to address repeating fields in the data model. For example:
- Contributor
- Identifier
- Instance Format
- Call Numbers
Answer: For Repeating Fields the star schema will do a full join for all areas where there are multiple fields; Angela recommends that Eric just note that there will be multiple fields; select based on Item ID
...
Review RPWG Project List
-next priority reports?
...
-Nassib and Roman implementing this data model in the shared LDP data warehouse
-latest update on progress from Nassib?
...
-duplicate report checking
-still meet with Reporting SIG
-try to meet with POs
-Marc in the data warehouse
-MM Convener joins to discuss MM reporting
...
Next Topics:
- Topic 1
- Topic 2
Next meeting of the Report Prototype WG is scheduled for Monday, June 10 at 10:00am EST
Action items
- Angela Zoss (Old) to follow up with Marc Johnson about why dates are stored as strings; dates are not being validated for Service Point Usage data model
- Sharon Markus to set up meeting on data elements for renewal dates
Linking between JIRA and future report documentation (GitHub):
- Issue title should change to the new naming convention
- all dwreport issues stay in REP
- to filter down to reporting umbrella categories, create a new field? add tags? (TBD)
Special cases:
- external reports (e.g., ARL) - the "report" will be a collected set of queries required for external statistics; each of the queries, however, might be useful for other reports
- Question: how does that work with GitHub? If we update the query in one place, do we just have to remember to update it everywhere else it might be used?