Skip to end of banner
Go to start of banner

F2F Conf LDP Sessions

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Date

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:

ElementValue for Example ReportDescription
Requirements IDID401
JIRA TicketREP-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
Name(s) of query(ies)

The query is how to get the data. Possible naming convention for short names:

verb, source data, function
example: count loans for locations

Short name(s) of query(ies)

Umbrella category for reportCirculation

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? 



Action items

  •  
  •  


  • No labels