Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
See Best Practices for Decision Pages and Tags for groups
Legend:
Status
titlenot started
Status
colourYellow
titleIN PROGRESS
Status
colourRed
titleSTALLED
Status
colourGreen
titledecided
Page Properties

Status

Status
colourYellow
titleIn progress

Description

Determine which Analytics field(s) should be used when counting physical items to ensure we include things we have and exclude things we don’t have.

Decision summary

Use x from the item recordUse “Physical Items”.”Item Creation Date” to count physical items based on date. Use “E-Inventory“.”Portfolio Activation Date”.”Portfolio Activation Date” for electronic items. Adjust queries to account for migration artifacts and Alma date value inconsistencies when necessary.

Owning group

AASAP Team sils-aasa-l@listserv.ucop.edu

Approver

Consulted

AASAP Team members consulted locally.

Informed

Leadership Group

Decision-making process

Priority

Target decision date

Date decided

[type // to add Date]

...

Recommendations

...

  1. All materials

...

If item addition and/or withdrawal by fiscal year are desired, please consider the following:

For Added counts:

...

Use “Physical Items“.”Physical Item Details”.”Lifecycle” = Active AND

...

  1. : account for Alma date variable quirks. Adjust queries to account for inconsistent behavior for dates due to Alma’s method of manipulating and storing date variables, as well as migration artifacts. For example, many Network Zone portfolios migrated with a null value for Activation Date.

  2. Physical materials: use “Physical Items”.”Item Creation Date”

...

Use “Physical Items”.”Item Receiving Date” and find out why there are significant impacts at San Diego, Davis, Irvine, Riverside, San Francisco, and Santa Barbara when dates are added into the data extract/report build in Alma Analytics.

...

For Withdrawn counts:

  • Use “Physical Items”.”Item Modification Date” = Deleted and/or None or NULL AND

  • Find out reasons behind the usage of the Deleted value AND/OR

  • Encourage identification of a common field to house a withdrawal/deletion note which consists of at least the initial of the person accountable for the withdrawal/deletion, date of the withdrawal/deletion, and reason behind the withdrawal/deletion for not only statistical reporting purposes but also accountability purposes.

Note: Pending SILS and ExLibris explanation behind significant differences in counts when dates are used in the report/data extraction builds.

Impact

...

Stakeholder group

...

Impact

...

UC Libraries

...

Determinations around what and how we report are for the most part managed/owned by the UC Libraries (i.e., shared ownership).

...

CDL

...

CDL analysts, who are responsible for building report queries at the Network Zone according to templates agreements upon by the UC Libraries, will have to exclude items and titles based a variety of date parameters.

Reasoning

After review, the AASA-PT Harmonization group determined that

Background

The AASA-PT Harmonization group reviewed all the UCOP statistics data that can be retrieved via Alma Analytics. Factors considered during this review were the existing UCOP, ACRL and ARL requirements.

  • UCOP statistical reporting are collected for risk management purposes.

  • ARL reporting guidelines would like institutions to be consistent with their reporting such that institutions should continue reporting counts for criteria reported initial years should be continually reported in subsequent years, including the groupings of the institution types.

  • ACRL and ARL statistical reporting requirements allow focus in counts reflecting what has been catalogued.

  • CEAL statistical reporting requirements would like to know what has not yet been catalogued.

While reasons for statistical reporting are unknown and not shared; there exists suggested reasons for statistical reporting for studies on values and impacts of libraries and their collections which encourages desires for further reporting of changes in the libraries and collections, where counts of additional and withdrawal of items each year are significant in the report build.

Further, due to the occasional amendments to the past annual UCOP and ARL stats submissions recorded in past annual UCOP stats reports and discussed and presented by representatives from ARL; the manual amendments practiced can be eliminated with the inclusion of the date fields in the report built in Alma Analytics. However, while the design behind Alma and Alma Analytics are promising, problems with the date fields surfaced.

As a result, the following variables and a combination of them were reviewed for decisions to be made:

  • Physical Items

    • Lifecycle

    • Material Type v. Resource Type

    • Item Creation Date v. Creation Date

    • Item Receiving Date v. Receiving Date v. Receiving Date (Calendar)

    • Item Modification Date v. Modification Date

Other variables were also reviewed and considered but they played minor roles for the build. They included locations, item policies, call numbers, etc. They are modifiable and require significant study and maintenance at each institution level, similar to the material type option listed above, which we have decided not to focus on and use for the Fiscal Year 2022-2023 UCOP Stats reporting.

This decision page reports on the comparisons and decisions behind the bolded items in the above listed variables reviewed.

*Material Type v. Resource Type not reported in this decision page as neither of them show significant correlations with the usage of date variables. Please see separate decision page on them.

Observations about the current data:

Physical Items

Lifecycle

Three values are available in this “Physical Items“.”Physical Item Details”.”Lifecycle” variable:

...

Active, which allows us to know what items' records are active, discoverable, and retrievable in patron-facing interface of the catalog.

...

Deleted, which allows us to know what items' records are not discoverable or retrievable in patron-facing interface of the catalog.

...

  1. Electronic materials: use “Activation Date”

Using the data that currently exists in these fields provides the best balance of costs and benefits: it avoids significant, immediate local cleanup projects while providing counts that are within an acceptable margin of error.

Impact

Stakeholder group

Impact

UC Libraries

Determinations around what and how we report are for the most part managed/owned by the UC Libraries (i.e., shared ownership).

CDL

CDL analysts, who are responsible for building report queries at the Network Zone according to templates agreements upon by the UC Libraries, will have to exclude items and titles based a variety of date parameters.

Reasoning

Background

The AASA-PT Harmonization group reviewed all the UCOP statistics data that can be retrieved via Alma Analytics. Factors considered during this review were the existing UCOP, ACRL and ARL requirements.

  • UCOP statistical reporting are collected for risk management purposes.

  • ARL reporting guidelines would like institutions to be consistent with their reporting.

  • ACRL and ARL reporting requirements focus on catalogued material.

  • CEAL reporting requirements ask about both catalogued and un-catalogued material

UCOP and other requirements statistics want counts for a snapshot in time: usually, it’s the end of the most recent fiscal year. Therefore, campuses have in the past used various approaches to exclude any material added after the end of the fiscal year when running reports after that date. For example, a report run on August 1 would be set up to excludematerial added after July 1. Alma Analytics has a variety of date fields that could be used to accomplish this. However, these fields each have a variety of drawbacks for several reasons, e.g., campus procedures, migration artifacts, and other data issues. The following variables were reviewed :

  • Physical

    • Lifecycle

    • Item Creation Date v. Creation Date

    • Item Receiving Date v. Receiving Date v. Receiving Date (Calendar)

    • Item Modification Date v. Modification Date

  • Electronic

    • Lifecycle

    • Portfolio Modification Date v. Modification Date

    • Portfolio Creation Date

    • Portfolio Activation Date

Observations about the current data:

For counts of items added or withdrawn by fiscal year, options include:

  • For Added :

    • Physical

      • Use “Physical Items“.”Physical Item Details”.”Lifecycle” = Active AND

      • Use “Physical Items”.”Item Creation Date” OR

      • Use “Physical Items”.”Item Receiving Date” and research significant impacts at San Diego, Davis, Irvine, Los Angeles, Riverside, San Francisco, and Santa Barbara when dates are added into the data extract in Alma Analytics.

    • Electronic

      • Use “E-Inventory”.”Portfolio”.”Lifecycle” = Active AND

      • Use “E-Inventory“.”Portfolio Activation Date”.”Portfolio Activation Date”

  • For Withdrawn:

    • Physical

      • Use “Physical Items”.”Item Modification Date”.”Item Modification Date” AND

      • Use “Physical Items”.”Physical Item Details”.”Lifecycle” = Deleted and/or None or NULL AND/OR

      • Find out reasons behind the usage of the Deleted value and harmonize on a field and values for deletion notes

    • Electronic

      • Use “E-Inventory”.”Portfolio”.”Lifecycle” = Deleted and/or None or NULL AND

      • Use “E-Inventory“.”Portfolio Modification Date”.”Portfolio Modification Date”

Note: ExLibris is reviewing the differences in counts when dates are used in Analytics reports as of May, 2023.

Physical

  • Lifecycle

    • Three values are available for “Physical Items“.”Physical Item Details”.”Lifecycle”:

      • Active items are active and discoverable in Primo.

      • Deleted items are not discoverable in Primo.

      • None items are not discoverable in Primo. These records are also associated with records without creation dates and possibly other pertinent metadata not yet determined in our knowledge without consideration with ExLibris.

      Although useful by ExLibris' design, based on the above knowledge and our knowledge of our current practices and ExLibris' design for Alma Analytics Subject Areas, where full record of each record’s modification history is not considered;
      • ; consultation with Ex Libris is ongoing.

    • For withdrawn counts, filtering based on lifecycle , where lifecycle equals “Deleted” and/= “Deleted” or “None” will cause the following issuescauses:

      There exists two available modification date options:

      • Exclusion of items that were deleted from the repository after the reporting deadline but before the report run date. For example, if a weeding project happens in August 2023 and hundreds of print items and their associated records are removed, a report looking for the items from before July 2023 that runs in October 2023 will exclude those items, even though they were still in the collection before July 2023.

      • Items deleted by mistake for various reasons and circumstances not explained and/or not noted in record suggests irrelevance of the lifecycle variable, especially for those with lifecycles of at least “Deleted”. To account for the deleted items, it would require investigations into reasons and circumstances behind the deletions of records and enforcements of practices in flagging and noting the details of such deletions into certain fields and variables that would allow easy filtering and/or usage of such available variable in Alma Analytics.

    Modification Date

      • “Physical Items”.”Item Modification Date”, which cleans up and harmonizes the value available in “Physical Items”.Inclusion of items deleted because they were added by mistake, but that do not actually represent items that were removed from the collection.

  • Modification Date

    • There are two modification date options:

      • “Physical Items”.”Item Modification Date”, which cleans up and harmonizes the value available in “Physical Items”.”Physical Items Details”.”Modification Date”. ExLibris documentation reads that says: “The Item Modification date is the date of the last change to the item. Therefore, if on January 19, 2016 the item was in process type Acquisition, on January 20, 2016 the item was in process type Request, and on January 21, 2016 the item was in process type Loan (and no additional change to the item was made after January 21), the Item Modification Date is January 21, 2016.“

      • “Physical Items”.”Physical Items Details”.”Modification Date”, which allows us to know when the item record is modified. ExLibris documentation reads that this variable says it “Holds the date the physical item was modified“.

    • Alma Analytics data-based findings not yet attempted. No similar issues and findings as those found for other date variables are found for modification date variables. AASA-PT team looking for reasons to dive into a study on modification date options. So far, per common knowledge and experience, each of the modification date options suggest automatic generation due to any alteration or modifications attempted. Although not senior seasoned users, per experience in Alma Analytics thus far, the recent availability of the Physical Items Historical Event Subject Area in late 2022, and the current data available in such recent available area provides no complete historical data on the changes behind each record type, be it one on each physical item or one on each bibliographic record.

      Alma Analytics data-based findings:

    • When crossed with Lifecycle = Delete, modification dates can be useful to determine and account for items withdrawn from the collection (see Prototype Version 1 at https://docs.google.com/spreadsheets/d/1IBV9tKyvO3xq-UZeuLoeEViSmBwgp2YO/edit#gid=552748451 ). However, due to the problems noted in the Lifecycle section of this decision page, certain institutions are requesting to opt out of reporting annual add and withdrawal counts in statistical reporting.

    • No significant findings in the values of the modification date variables.

      Values in

      :

    • Based on the reported knowledge and practices, “Physical Items”.”Item Modification Date” is the best variable to use to determine when the items' records were last modified, especially when the record of the item was deleted.

  • Creation Date

    • Automatic date and time stamps for when records are created are a norm in relational databases. In Alma physical items, there are two creation dates:

      • “Physical Items”.”Item Creation Date”, which cleans up and harmonizes the value available in “Physical Items”.”Physical Items Details”.”Creation Date.” ExLibris documentation says this “Stores the item creation date in a date format such as 2/29/2014” and that “All date dimensions include dates up to and including 30 years back and 20 years forward. So, for example, if today is March 17, 2021: The earliest loan date that would appear is March 17, 1991. The latest due date that would appear is March 17, 2041.“).

      • “Physical Items”.”Physical Items Details”.

        ”Modification Date” suggests automatic generation by system when item records are modified. If record has not yet been modified, no modification date is available.
      • Values in “Physical Items”.”Item Modification Date” suggests that this dimension and variable was created to make use of and harmonize any discrepancies found in “Physical Items”.”Physical Items Details”.”Modification Date”. Since none was experienced there, no discrepancies are found in this variable.

    • Based on the reported knowledge and practices, “Physical Items”.”Item Modification Date” would be the best variable to use to determine when the items' records were last modified, especially when the record of the item was deleted. Doing so would encourage leaderships to consider oversights in understanding and reporting about the practices in the deletion of records in the usage of SILS.

  • Creation Date

    • Per common database design knowledge, automatic date and time stamps for when records are created are expected, resulting in the choice of creation date values. There exists two available creation date options:

      • “Physical Items”.”Item Creation Date”, which cleans up and harmonizes the value available in “Physical Items”.”Physical Items Details”.”Creation Date” (variable mentioned below; ExLibris documentation reads that this variable “Stores the item creation date in a date format such as 2/29/2014” and that “All date dimensions include dates up to and including 30 years back and 20 years forward. So, for example, if today is March 17, 2021: The earliest loan date that would appear is March 17, 1991. The latest due date that would appear is March 17, 2041.“).

      • “Physical Items”.”Physical Items Details”.”Creation Date”, which allows us to know when the record on the item was created. (ExLibris documentation reads that this variable: “Holds the date the physical item was created” and that “This date is assigned by Alma when the physical item is created.“)

    • Alma-based findings:

      • The abovementioned definition in ExLibris documentations are questionable due to the Alma Analytics data-based findings mentioned in below section.

      • Location of where originating physical item creation date field in Alma which corresponds to those in Alma Analytics is unknown and not yet provided to AASA-PT analysts.

      • There are three possibilities of how this field is populated in Alma for Alma Analytics:

        • Items are created on order and, as part of predictions, before the material is received AND/OR

        • Using the “Add Item” button in Physical Item Editor module upon finding bibliographic and/or holdings record AND/OR

        • Using other record creation options and practices behind outside of Alma such as those needed and used for initial data migration purposes.

  • Alma Analytics data-based findings:

    • Based on the following and our knowledge of the campuses' current practices, “Physical Items”.”Item Creation Date” would be the best variable to use, if reporting counts of items added into the catalog by fiscal year and/or a particular date range is needed:

      • “Physical Items”.”Physical Items Details”.”Creation Date” is the raw data transferred from Alma to Alma Analytics.

      • “Physical Items”.”Item Creation Date” is the harmonization/data cleanup processed variable based on the Physical Items.Physical Items Details.Creation Date.

Institution Name

Version 1

(Item Creation Date Used)

Version 2

(Item Creation Date Not Used)

Northern Regional Library Facility

7,596,443

7,596,443

Southern Regional Library Facility

6,971,497

6,971,497

UC San Diego

1,704,653

2,363,938

University of California Berkeley

5,983,372

5,983,372

University of California Davis

1,961,543

3,024,327

University of California Irvine

1,466,838

2,010,303

University of California Los Angeles

4,437,059*

4,436,031*

University of California Riverside

1,235,630

2,359,278

University of California San Francisco

72,977

162,356

University of California, Merced

154,615

154,615

University of California, Santa Barbara

1,968,100

2,581,878

University of California, Santa Cruz

1,067,382

1,067,382

Total

34,620,109

38,711,420

...

      • ”Creation Date”, which allows us to know when the record on the item was created. ExLibris documentation says that this “Holds the date the physical item was created” and that “This date is assigned by Alma when the physical item is created.“

    • Note: ExLibris documentation does not completely align with findings.

  • Alma Analytics data findings:

Institution Name

Version 1

(Item Creation Date Used)

Version 2

(Item Creation Date Not Used)

Northern Regional Library Facility

7,596,443

7,596,443

Southern Regional Library Facility

6,971,497

6,971,497

UC San Diego

1,704,653

2,363,938

University of California Berkeley

5,983,372

5,983,372

University of California Davis

1,961,543

3,024,327

University of California Irvine

1,466,838

2,010,303

University of California Los Angeles

4,437,059*

4,436,031*

University of California Riverside

1,235,630

2,359,278

University of California San Francisco

72,977

162,356

University of California, Merced

154,615

154,615

University of California, Santa Barbara

1,968,100

2,581,878

University of California, Santa Cruz

1,067,382

1,067,382

Total

34,620,109

38,711,420

Table 3. Comparison of counts when creation date is used. The above table compares the total counts at each institution when Item Creation Date is used and not used in the report build. For details behind the counts, see https://docs.google.com/spreadsheets/d/1xOqWAWqn1P7uF5gkZbPZ5rOCDrWctZxencx4yf50_z0/edit#gid=471658574, where Version 1 is at https://docs.google.com/spreadsheets/d/1IBV9tKyvO3xq-UZeuLoeEViSmBwgp2YO/edit#gid=552748451 and Version 2 is at https://docs.google.com/spreadsheets/d/1eoN1qFGTYA4JQG_SY89UvhznCvgGZj6w/. Causes are not yet determined, and institutions impacted are highlighted in red.

* Cannot determine why there is a smaller count in Version 2 for UCLA. Version 1 and 2 were both ran on May 22, 2023 between 8 and 9 a.m. Although Version 2’s UCLA did not finish running until 8:57 am, there should not be that much of a difference in the output. Numbers in Table 4, which were based on Version 1’s build, shows that the numbers for UCLA was closer to Version 2, too. See Table 4.

  • Receiving Date

    • There are three available receiving date options:

      • “Physical Items”.”Item Receiving Date”

      • “Physical Items”.”Physical Items Details”.”Receiving Date (calendar)”

      • “Physical Items”.”Physical Items Details”.”Receiving Date”

    • Alma :

      • Screenshot of receive new material screen:

        Image Added

        The Receiving Date variable in Alma Analytics comes from a “Received Date” field in Alma that is currently validated. End users can use a calendar drop down; and they can also type dates into the field—the values must translate to a calendar date for the record to save.

    • Alma Analytics:

...

...

...

...

...

...

* Cannot determine why there is a smaller count in Version 2 for UCLA. Version 1 and 2 were both ran on May 22, 2023 between 8 and 9 a.m. Although Version 2’s UCLA did not finish running until 8:57 am, there should not be that much of a difference in the output. Numbers in Table 4, which were based on Version 1’s build, shows that the numbers for UCLA was closer to Version 2, too. See Table 4.

  • Receiving Date

    • There exists three available receiving date options:

      • “Physical Items”.”Item Receiving Date”, which cleans up and harmonizes the value available in “Physical Items”.”Physical Items Details”.”Creation Date” (variable mentioned below; ExLibris documentation reads that this variable “Stores the item creation date in a date format such as 2/29/2014” and that “All date dimensions include dates up to and including 30 years back and 20 years forward. So, for example, if today is March 17, 2021: The earliest loan date that would appear is March 17, 1991. The latest due date that would appear is March 17, 2041.“).

      • “Physical Items”.”Physical Items Details”.”Receiving Date (calendar)”, which allows us to know when the record on the item was created. (ExLibris documentation reads that this variable: “Holds the date the physical item was created” and that “This date is assigned by Alma when the physical item is created.“)

      • “Physical Items”.”Physical Items Details”.”Receiving Date”, which allows us to know when the record on the item was created. (ExLibris documentation reads that this variable: “The Receiving Date table is a dimension table that stores details about the date the item was received by the library”; “Stores the item modification date in a date format such as 2/29/2014“; and that “The date the material was actually received/activated for the first time.“)

    • Alma-based findings:

      • The following is a screen capture of the receive date that is designed to collect such values in Alma:

        Image Removed

        This above screen capture suggests that the Receiving Date variable in Alma Analytics was a free-text textbox in Alma and that the Receiving Date (Calendar) variable in Alma Analytics is the calendar dropdown in Alma. This means that end users are allowed to enter the date values manually and can use the calendar dropdown to enter standardized date values. This also suggests that the data transfer from Alma to Alma Analytics did not include a process to clean the manually entered date values such that dates entered with m/d/yy are not read as mm/dd/yyyy date formats that are needed for sorting and filtering in Alma Analytics. There is also a possibility that these manually entered values are read as strings rather than dates such that Alma Analytics are not able to filter them correctly.

    • Alma Analytics-based findings

    • Institution-Level Consultation findings:

      • Some campuses report that they do not use this date.

    • Based on the following and our knowledge of the campuses' current practices, “Physical Items”.”Item Receiving Date” would be the best variable to use, if reporting counts of items added into the collection by fiscal year and/or a particular date range is needed:

      • “Physical Items”.”Physical Items Details”.”Receiving Date” is the raw data transferred from the corresponding text-free field in Alma to Alma Analytics.

      • “Physical Items”.”Physical Items Details”.”Receiving Date (Calendar)” is the raw data transferred from the corresponding calendar dropdown menu in Alma to Alma Analytics.

      • “Physical Items”.”Item Receiving Date” is the harmonization/data cleanup processed variable based on “Physical Items”.”Physical Items Details”.”Receiving Date” and “Physical Items”.”Physical Items Details”.”Receiving Date (Calendar)”.

Institution Name

A

Item Creation Date

B

Item Receiving Date

C

No Dates

D

Impact (numeric)

E

Impact (more than 500,000 in difference)

F

Percentage

Northern Regional Library Facility

7,597,208

7,567,096

7,597,208

30,112

not significant

not significant

Southern Regional Library Facility

6,973,790

6,871,888

6,973,790

101,902

not significant

not significant

UC San Diego

1,704,821

1,688,838

2,364,098

675,260

significant

27.89%

University of California Berkeley

5,983,706

5,912,356

5,983,706

71,350

not significant

not significant

University of California Davis

1,961,837

1,872,691

3,024,594

1,151,903

significant

35.14%

University of California Irvine

1,466,925

1,455,819

2,010,391

554,572

significant

27.03%

University of California Los Angeles

4,436,011

4,003,694

4,436,011

432,317

not significant

not significant

University of California Riverside

1,235,634

1,169,536

2,359,105

1,189,569

significant

47.62%

University of California San Francisco

72,946

71,391

162,115

90,724

not significant

not significant

University of California, Merced

155,356

151,862

155,356

3,494

not significant

not significant

University of California, Santa Barbara

1,968,635

1,923,660

2,582,326

658,666

significant

23.77%

University of California, Santa Cruz

1,067,475

1,044,417

1,067,475

23,058

not significant

not significant

Grand Total

34,624,344

33,733,248

38,716,175

4,982,927

significant

10.57%

Table 4. Comparison of counts and impacts when the dates considered are used in build. The above table compares the counts and shows the calculated impacts based on the counts with and without the dates listed.

Item Creation Date and Item Receiving Date are the harmonization/data cleanup processed variable provided by ExLibris in Alma Analytics which would be useful for filtering for adding and withdrawal accountabilities by certain dates and date ranges, including fiscal years. These two variables are compared with a build without any dates for comparisons in this Table.

Impact (numeric) (D) is calculated by (C-B) or (C-A), whichever is greater. If more than 500,000 in difference, impact (E) is significant and a percentage of the significance is calculated into percentage (F).

Institutions with significant impacts (San Diego, Davis, Irvine, Riverside, San Francisco, and Santa Barbara), regardless of which date variable to use or not, which require attention are high-lighted in red. These institutions should consider a preference for Version 2, where no dates are used in the build.

Those highlighted in green (NRLF, SRLF, Berkeley, Los Angeles, Merced, and Santa Cruz) should consider a preference for Version 1 and use Item Creation Date to count toward items added each fiscal year.

Options Considered

...

Option 1

...

Option 2

...

Option 3

...

Option 4

...

Option 5

...

Option

...

"Physical Items". "Item Creation Date"

...

"Physical Items". "Item Receiving Date"

...

"Physical Items". "Physical Item Details". "Receiving Date (Calendar)"

...

"Physical Items". "Physical Item Details". "Receiving Date"

...

"Physical Items". “Physical Item Details”. “Creation Date

...

Pros

Cleans up/converts/harmonizes each of the value in “Physical Items”.”Physical Item Details”.”Creation Date”, which includes all the Pros and Cons of that variable.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” created.

Although counts are not significantly higher, this variable does provide a higher count than when receiving date options are used.

...

Cleans up/converts/harmonizes each of the value in “Physical Items”.”Physical Item Details”.”Receiving Date” and “Physical Items”.”Physical Item Details”.”Receiving Date (Calendar)”, which includes all the Pros and Cons of those variables.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” received.

Cleans up/converts/harmonizes each of the value in “Physical Items”.”Physical Item Details”.”Receiving Date”, which includes all the Pros and Cons of that variable.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” received.

This variable suggests the actual date of availability of the item at the library and would be the best option if it was used properly*.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” received.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” created.

...

Cons

...

Item records can exist for items that we do not have, e.g. on-order items.

Actual location of how and where creation date is generated and/or entered into Alma have been educated guesses and not confirmed by ExLibris, hence the term “supposedly” used in the Pros section for this variable.

Even though this variable was created to clean up and harmonize “Physical Items”.”Physical Item Details”.”Creation Date”, it does not read the values from such a variable correctly such that dates in m/d/yy formats are not converted to mm/dd/yyyy formats and dates more recent than certain date values are interpreted as dates older than that same certain dates.

...

Not all campuses update this field via Alma upon item arrival to campus.

Even though this variable was created to clean up and harmonize “Physical Items”.”Physical Item Details”.”Receiving Date” and “Physical Items”.”Physical Item Details”.”Receiving Date (Calendar)”, it does not read the values from such a variable correctly such that dates in m/d/yy formats are not converted to mm/dd/yyyy formats and dates more recent than certain date values are interpreted as dates older than that same certain dates.

When used, due to above finding, items may fall into the NULL counts or the wrong date ranges.

Since some dates were of dates in the future, items with such future dates will need significant amount of investigation and attention.

Although counts are not significantly less, this variable does provide a smaller count than when creation date options are used. Further, if receiving date options are used, filtering by receiving dates may drop records which are not updated where receiving dates are not available.

...

Even though this variable was created to clean up and harmonize “Physical Items”.”Physical Item Details”.”Receiving Date”, it does not read the values from such a variable correctly such that dates in m/d/yy formats are not converted to mm/dd/yyyy formats and dates more recent than certain date values are interpreted as dates older than that same certain dates.

When used, due to above finding, items may fall into the NULL counts or the wrong date ranges.

Since some dates were of dates in the future, items with such future dates will need significant amount of investigation and attention.

While some campus reps report that this field is used, some report that this field is not used.

*This variable is found to be “Received Date” in Alma but named “Receiving Date” in Alma Analytics. Dates found within these fields go beyond today’s date--dates in the future.

*This variable is found to be populated as the “Received Date”, date when item was received, in Alma, where the field is a free-text textbox.

Alma Analytics are not able to fully filter this variable. Some of the dates in this variable are in m/d/yy formats. Alma Analytics seems to be confused. For instance, if the “yy” portion is “22”, should it be 1922 or 2022?

...

      • ).

    • Institution-Level Consultation findings:

      • Some campuses report that they do not use this date.

    • Based on the following and our knowledge of the campuses' current practices, “Physical Items”.”Item Receiving Date” would be the best variable to use, if reporting counts of items added into the collection by fiscal year and/or a particular date range is needed:

      • “Physical Items”.”Physical Items Details”.”Receiving Date” is the raw data transferred from the corresponding text-free field in Alma to Alma Analytics.

      • “Physical Items”.”Physical Items Details”.”Receiving Date (Calendar)” is the raw data transferred from the corresponding calendar dropdown menu in Alma to Alma Analytics.

      • “Physical Items”.”Item Receiving Date” is the harmonization/data cleanup processed variable based on “Physical Items”.”Physical Items Details”.”Receiving Date” and “Physical Items”.”Physical Items Details”.”Receiving Date (Calendar)”.

Institution Name

A

Item Creation Date

B

Item Receiving Date

C

No Dates

D

Impact (numeric)

E

Impact (more than 500,000 in difference)

F

Impact
(percent)

G

Impact
(more than 5% in difference)

Northern Regional Library Facility

7,597,208

7,567,096

7,597,208

30,112

not significant

0.40%

not significant

Southern Regional Library Facility

6,973,790

6,871,888

6,973,790

101,902

not significant

1.46%

not significant

UC San Diego

1,704,821

1,688,838

2,364,098

675,260

significant

28.56%

significant

University of California Berkeley

5,983,706

5,912,356

5,983,706

71,350

not significant

1.19%

not significant

University of California Davis

1,961,837

1,872,691

3,024,594

1,151,903

significant

38.08%

significant

University of California Irvine

1,466,925

1,455,819

2,010,391

554,572

significant

27.59%

significant

University of California Los Angeles

4,436,011

4,003,694

4,436,011

432,317

not significant

9.75%

significant

University of California Riverside

1,235,634

1,169,536

2,359,105

1,189,569

significant

50.42%

significant

University of California San Francisco

72,946

71,391

162,115

90,724

not significant

55.96%

significant

University of California, Merced

155,356

151,862

155,356

3,494

not significant

2.25%

not significant

University of California, Santa Barbara

1,968,635

1,923,660

2,582,326

658,666

significant

25.51%

significant

University of California, Santa Cruz

1,067,475

1,044,417

1,067,475

23,058

not significant

2.16%

not significant

Grand Total

34,624,344

33,733,248

38,716,175

4,982,927

significant

12.87%

significant

Table 4. Comparison of counts and impacts when the dates considered are used in build. The above table compares the counts and shows the calculated impacts based on the counts with and without the dates listed.

Item Creation Date and Item Receiving Date are the harmonization/data cleanup processed variable provided by ExLibris in Alma Analytics which would be useful for filtering for adding and withdrawal accountabilities by certain dates and date ranges, including fiscal years. These two variables are compared with a build without any dates for comparisons in this Table.

Impact (numeric) (D) is calculated by (C-B) or (C-A), whichever is greater. If more than 500,000 in difference, impact (E) is significant.

Impact (percent) (F) is calculated by (C-B)/C or (C-A)/C, whichever is greater. If more than 5% in difference, impact (G) is significant and the Institution Name is highlighted in red.

Institutions with significant impacts (San Diego, Davis, Irvine, Los Angeles, Riverside, San Francisco, and Santa Barbara), regardless of which date variable to use or not, which require attention are high-lighted in red. These institutions should consider a preference for Version 2, where no dates are used in the build.

Those highlighted in green (NRLF, SRLF, Berkeley, Merced, and Santa Cruz) should consider a preference for Version 1 and use Item Creation Date to count toward items added each fiscal year.

Options Considered

Option 1

Option 2

Option 3

Option 4

Option 5

Option

"Physical Items". "Item Creation Date"

"Physical Items". "Item Receiving Date"

"Physical Items". "Physical Item Details". "Receiving Date (Calendar)"

"Physical Items". "Physical Item Details". "Receiving Date"

"Physical Items". “Physical Item Details”. “Creation Date

Pros

Cleans up/converts/harmonizes each of the value in “Physical Items”.”Physical Item Details”.”Creation Date”, which includes all the Pros and Cons of that variable.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” created.

Although counts are not significantly higher, this variable does provide a higher count than when receiving date options are used.

Cleans up/converts/harmonizes each of the value in “Physical Items”.”Physical Item Details”.”Receiving Date” and “Physical Items”.”Physical Item Details”.”Receiving Date (Calendar)”, which includes all the Pros and Cons of those variables.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” received.

Cleans up/converts/harmonizes each of the value in “Physical Items”.”Physical Item Details”.”Receiving Date”, which includes all the Pros and Cons of that variable.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” received.

This variable suggests the actual date of availability of the item at the library and would be the best option if it was used properly*.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” received.

Available at the item level which specifically describes when each of the physical item counted were “supposedly” created.

Cons

Item records can exist for items that we do not have, e.g. on-order items.

Actual location of how and where creation date is generated and/or entered into Alma have been educated guesses and not confirmed by ExLibris, hence the term “supposedly” used in the Pros section for this variable.

Even though this variable was created to clean up and harmonize “Physical Items”.”Physical Item Details”.”Creation Date”, it does not read the values from such a variable correctly such that dates in m/d/yy formats are not converted to mm/dd/yyyy formats and dates more recent than certain date values are interpreted as dates older than that same certain dates.

Not all campuses update this field via Alma upon item arrival to campus.

Even though this variable was created to clean up and harmonize “Physical Items”.”Physical Item Details”.”Receiving Date” and “Physical Items”.”Physical Item Details”.”Receiving Date (Calendar)”, it does not read the values from such a variable correctly such that dates in m/d/yy formats are not converted to mm/dd/yyyy formats and dates more recent than certain date values are interpreted as dates older than that same certain dates.

When used, due to above finding, items may fall into the NULL counts or the wrong date ranges.

Since some dates were of dates in the future, items with such future dates will need significant amount of investigation and attention.

Although counts are not significantly less, this variable does provide a smaller count than when creation date options are used. Further, if receiving date options are used, filtering by receiving dates may drop records which are not updated where receiving dates are not available.

Even though this variable was created to clean up and harmonize “Physical Items”.”Physical Item Details”.”Receiving Date”, it does not read the values from such a variable correctly such that dates in m/d/yy formats are not converted to mm/dd/yyyy formats and dates more recent than certain date values are interpreted as dates older than that same certain dates.

When used, due to above finding, items may fall into the NULL counts or the wrong date ranges.

Since some dates were of dates in the future, items with such future dates will need significant amount of investigation and attention.

While some campus reps report that this field is used, some report that this field is not used.

*This variable is found to be “Received Date” in Alma but named “Receiving Date” in Alma Analytics. Dates found within these fields go beyond today’s date--dates in the future.

*This variable is found to be populated as the “Received Date”, date when item was received, in Alma, where the field is a free-text textbox.

Alma Analytics are not able to fully filter this variable. Some of the dates in this variable are in m/d/yy formats. Alma Analytics seems to be confused. For instance, if the “yy” portion is “22”, should it be 1922 or 2022?

According to ExLibris users, 1922 and dates prior to availability of computers may make sense to their build because some ExLibris customers do have historic items created and/or received from way before time. Although the users and customers may consider using “Receive Date”, ExLibris has not yet responded to these other clients of theirs.

Electronic Items

  • Lifecycle

    • Three values are available for “E-Inventory“.”Portfolio”.”Lifecycle”:

      • Active items are active and discoverable in Primo.

      • Deleted items are not discoverable in Primo.

      • None items are not discoverable in Primo.

    • Records where Lifecycle = Deleted or None may not be reliable for the following reasons:

      • Portfolios that were deleted from the repository after the reporting deadline but before the report run date may not be accounted for.

      • Campuses noted that deletions due to deactivations may not be relevant as campuses delete, deactivate and reactivate portfolios regularly as part of normal electronic resource management processes.

      • Items available via “E-Inventory” Subject Area are not available for manual backup counting processes.

      • No thorough historical record modification data available for review.

  • Modification Date

    • Two options available:

      • “E-Inventory”.”Portfolio”.”Modification Date”, which is the raw and automatically generated date of when the record on the portfolio was last modified. ExLibris notes “The date information was updated in the portfolio“.

      • “E-Inventory”.”Portfolio Modification Date”.”Portfolio Modification Date”, which cleans up and harmonizes “E-Inventory”.”Portfolio”.”Modification Date”. Per ExLibris: “The Portfolio Modification Date table is a dimension table that stores details about the Portfolio modification date. The modification date of the portfolio (either in the Alma UI or by running a job)“ denotes that the raw “E-Inventory”.”Portfolio”.”Modification Date” date value is automatically generated.

    • When crossed with Lifecycle = Delete, modification dates can be useful to determine and account for portfolios withdrawn from the collection. However, due to the problems noted in the Lifecycle section of this decision page, institutions are requesting to opt out of reporting at least withdrawal counts in statistical reporting.

  • Creation Date

    • Only one option is available:

      • “E-Inventory”.”Portfolio Creation Date”.”Portfolio Creation Date”, which is the date when the record on the portfolio was created. Per ExLibris documentation: “The Portfolio Creation Date table is a dimension table that stores details about the date on which the portfolio was activated from the Community Zone and became part of the Institution Zone. Key fields are used whenever calculations are required. Description fields may be used for formatting the display of the report. Alma stores the following types of fields: Calendar Fields – These are date fields as they display in the calendar. Fiscal Date Fields – These are date fields that match the institution's fiscal period. Using this dimension, the user may drill down from year to month to the specific date on which the portfolio was created in the Institution Zone. The number of portfolios is accumulated to the relevant level in the hierarchy.” Further, ExLibris notes that it “Stores the portfolio creation date in the date format 2/29/2012“, meaning that this variable was created to clean up and harmonize a certain raw date of record creation, which we were not provided with.

    • This is a risky option. It is not consistent with the design of the important date variables that have been made into a separate dimension, where the raw Alma Analytics variable the Portfolio Creation Date originated can be determined. However, it does hide up any similar flaw which we currently experience with the Physical Items Subject Area.

    • Based on the design of the Subject Area, “E-Inventory”.”Portfolio Activation Date”.”Portfolio Creation Date” would be the most reasonable variable to use for accounting the counts of portfolios available to the us to consider for activation within a certain date, date range and fiscal year.

  • Activation Date

    • Only one option is available:

      • “E-Inventory”.”Portfolio Activation Date”.”Portfolio Activation Date”, which suggests the date when the Portfolio was activated. Per ExLibris documentation: “The Portfolio Activation Date table is a dimension table that stores details about the Portfolio activation date. Key fields are used whenever calculations are required. Description fields may be used for formatting the display of the report. Alma stores the following types of fields: Calendar Fields – These are date fields as they display in the calendar. Fiscal Date Fields – These are date fields that match the institution's fiscal period. Using this dimension, the user may drill down from year to month to the specific date on which the Portfolio was created. The number of portfolios is accumulated to the relevant level in the hierarchy.“ Further, ExLibris notes that it “Stores the portfolio activation date in the date format 2/29/2012“, meaning that this variable was created to clean up and harmonize a certain raw date of activation, which we were not provided with.

    • This is a risky option. It is not consistent with the design of the important date variables that have been made into a separate dimension, where the raw Alma Analytics variable the Portfolio Activation Date originated. However, it does hide up any similar flaw which we currently experience with the Physical Items Subject Area.

    • Based on the design of the Subject Area, “E-Inventory”.”Portfolio Activation Date”.”Portfolio Activation Date” would be the most reasonable variable to use for accounting the counts of portfolios added to the collection within a certain date, date range and fiscal year.

Available At

A

Version i

B

Version 1

C

Version 2

D

Impact (numeric)

E

Impact (percentage)

UC San Diego

1,634,888

1,635,014

1,635,015

1

0.0001%

University of California Berkeley

1,491,172

1,491,488

1,491,488

0

0.0000%

University of California Davis

823,846

824,165

824,205

40

0.0049%

University of California Irvine

1,058,186

1,058,411

1,058,415

4

0.0004%

University of California Los Angeles

1,256,203

1,256,298

1,256,300

2

0.0002%

University of California Riverside

572,888

573,009

573,007

-2

-0.0003%

University of California San Francisco

43,016

43,077

43,077

0

0.0000%

University of California, Merced

995,413

995,492

995,492

0

0.0000%

University of California, Santa Barbara

1,284,799

1,284,845

1,284,913

68

0.0053%

University of California, Santa Cruz

838,207

838,268

838,237

-31

-0.0037%

Grand Total

9,998,618

10,000,067

10,000,149

82

0.0008%

Table 6. Comparison of counts and impacts when the dates considered are used in build for Electronic items available at each listed institution. The above table compares the counts and shows the calculated impacts based on the counts with and without the dates listed. These counts are of items activated at each listed institution.

Versions i and 1 uses “E-Inventory“.”Portfolio Activation Date”, which is the harmonized/data-cleanup-processed variable provided by ExLibris in Alma Analytics and which would be useful for filtering for adding accountabilities by certain dates and date ranges, including fiscal years.

Version 2 was built without any dates.

Impact (numeric) (D) is calculated by C-B, while Impact (percent) (F) is calculated by (C-B)/C. Minimal difference experienced. (Cause of the difference is not known, and priority to seek investigation in this finding is low due to insignificance.)

Available For

Version i

Version 1

Version 2

Impact (numeric)

Impact (percentage)

UC San Diego

2,191,683

2,194,822

2,194,822

0

0.0000%

University of California Berkeley

2,126,373

2,128,459

2,128,459

0

0.0000%

University of California Davis

2,012,834

2,038,163

2,038,163

0

0.0000%

University of California Irvine

2,189,430

2,192,576

2,192,576

0

0.0000%

University of California Los Angeles

2,191,378

2,194,524

2,194,524

0

0.0000%

University of California Riverside

2,054,623

2,080,588

2,080,578

-10

-0.0005%

University of California San Francisco

1,872,185

1,896,661

1,896,651

-10

-0.0005%

University of California, Merced

2,068,342

2,093,684

2,093,684

0

0.0000%

University of California, Santa Barbara

2,058,484

2,083,962

2,083,952

-10

-0.0005%

University of California, Santa Cruz

2,097,271

2,100,563

2,100,553

-10

-0.0005%

Total (calculated by max available)

2,191,683

2,194,822

2,194,822

0

0.0000%

Table 7. Comparison of counts and impacts when the dates considered are used in build for Electronic items available for each listed institution. The above table compares the counts and shows the calculated impacts based on the counts with and without the dates listed. These items are made available via the Network Zone.

Versions i and 1 uses “E-Inventory“.”Portfolio Activation Date”, which is the harmonized/data-cleanup-processed variable provided by ExLibris in Alma Analytics and which would be useful for filtering for adding accountabilities by certain dates and date ranges, including fiscal years.

Version 2 was built without any dates.

Impact (numeric) (D) is calculated by C-B, while Impact (percent) (F) is calculated by (C-B)/C. No difference experienced.

...

Image 1. Sample comparison of Schedule A - Electronic Holdings Totals v. Total Deduplicated Titles using “E-Inventory“.”Portfolio Activation Date”.”Portfolio Activation Date” (Left) versus “E-Inventory“.”Portfolio Creation Date”.”Portfolio Creation Date” (right) for University of California Los Angeles. Holdings uses COUNT(Portfolio Id); Titles uses COUNT(DISTINCT MMS Id); withdrawals not included in build; and, although causes in differences not yet determined, minimal differences experienced.

References

ExLibris. (2023). “Physical Items”. Retrieved from https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/080Analytics/Alma_Analytics_Subject_Areas/Physical_Items last accessed May 26, 2023.

ExLibris. (2023). “Subject Areas”. Retrieved from https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/080Analytics/Alma_Analytics_Subject_Areas last accessed May 26, 2023.

Action Log

Action/Point Person

Expected Completion Date

Notes

Status

AASA-PT

Review Draft

AASA-PT

Final Decision