F2F Conf LDP Sessions

Date

17 Jun 2019

Attendees

NOTES

Purpose of establishing naming conventions:

organization should be simple, clear, and logical
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	REP-103
Name of Report	Circulation Transaction Detail Circulation Transactions Loans with Material Type Circulation Transactions with Bibliographic Detail Loans with Material Type and Bibliographic Detail Loans with Item Detail	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 by = filter or focus; appropriate for reports that aggregate transactions, not for transaction-level reports with = what the report includes, details only include as many extra clauses as is necessary to distinguish this report; if "bibliographic detail" is expected, don't need to list it Note: we should create a markdown file for each report that would live in a reports folder on GitHub; it should include original purpose of the report, description of the different queries, links to queries Can also link to report markdown files from the main ldp-analytics markdown file Question: how to keep track of work on things like this in JIRA
Name(s) of query(ies)	ex.: Count Loans for Locations	The query is how to get the data. Possible naming convention for short names: verb, source data, function example: count loans for locations or maybe noun, verb, function example: Loans - Count by Location with Material Type
Short name(s) of query(ies)	ex.: count_loans_locations	needs to be machine-readable, usable as a variable underscores are better than dashes because some programs don't like dashes in variable names may or may not need to look like the regular name; might need to be shorter use as GitHub folder name if adding something to indicate aggregation (_counts, _detail), add to end so you can sort like with short name, maybe use verb after nouns so things can be sorted by main topic of interest
Umbrella category for report	Circulation	Group reports by the 5 most used apps of FOLIO that reports will be generated for: users circulation (check out, check in, requests) inventory finance and orders resource management 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: date of query tag indicating original functional area

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?

when is something like that assumed to be in a report, and when does it need to be called out in the name?
can we just make a general "Loans" report with all of the columns and let people discard columns they don't need later?
- end users would probably be happier with more specific subset reports already created for them; they will want to see both "Loans with Material Type" and "Loans with Service Point", even if at their core they are similar and we could hypothetically create a master "Loans" query with all necessary columns
- going forward, maybe that's how we organize our work on report clusters: create master queries will a large set of columns needed across several reports, then develop queries that build off that query to tailor the results for specific report requests (see workflow below)

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

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

Linking between JIRA and future report documentation (GitHub):

Issue title should change to the new naming convention
don't try to create new JIRA projects for the umbrella categories; all dwreport issues stay in REP
to filter down to reporting umbrella categories, could create a new field or just add more tags. Solution 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?

Resource Access Visit

Topics

how can reporting step in for workflow, which won't cover everything RA needs in first iteration
- example: items that need to change state after certain amount of time
- RA will need to sit down and identify things that it was assumed the workflow engine would take care of
- is any of it reporting functionality? may be, but some may just be normal reports
- maybe set up a meeting with RA SIG, small group?
- RA will probably just work on it together first
- this may be part of a great use case for additional development resources
- will have to do some analysis of in-app vs. LDP; only have resources to work on LDP (check out the new LDP vs. In-App explanation)
In-App vs. Data Warehouse
- changing UXPROD-933 to REP, is a partial duplicate of UXPROD-1327, so no need for two in-app reports and makes sense to be able to run this kind of report against historical data
- for data privacy, reports with patron identifiable data may need to stay in-app; includes things like fees/fines?

building report prototypes is like a mycelial network: you build one report, but then can tailor different branches

Demo of schemaspy, GitHub, test data

Resource Access has additional report requirements

Action items

add a user story to the JIRA issue about storing effective location in loan (UXPROD-1432)