Date
Attendees
- 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
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 |
| 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
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
- 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?