Child pages
  • September 25, 2019: Calisphere/Shared DAMS/OAC Update

This is a public wiki space. All contents are publicly accessible unless page restrictions are in place.

Skip to end of metadata
Go to start of metadata



  • UCB: Julie Musson
  • UCD: Eric Nebeker
  • UCI: Elvia Arroyo-Ramirez, Jolene Beiser, Paul Park
  • UCM: Alisak Sanavongsay, Emily Lin, Jerrold Shiroma, Kelsey Raidt
  • UCR: Eric Milenkiewicz, Kevin Comerford, Noah Geraci
  • UCSC: Sue Perry
  • UCSD: Gabriela Montoya
  • UCSF: Charlie Macquarie
  • CDL: Adrian Turner, Amy Wieliczka, Barbara Hui, Brian Tingle, Christine Kim, Eric Lopatin, Lisa Schiff, Matthew McKinley


Slides for CDL updates here:

Discussion items

TopicIn briefAction
 Nuxeo updates
  • Within the next year, we want to upgrade to 10.10 and at the same time, remove Shibboleth

  • Also some parallel tracks

    • User interface transition (JSF-UI to Web-UI)

    • Adding new Nuxeo components; Enabling other features within Nuxeo:

      • Support for 3D files (management; rendering; and derivative files). Next step: Figure out how to render these in Calisphere

      • Support for structured text files (e.g., XML, Markdown, HTML). Some campuses have have legacy TEI files -- and Nuxeo could be more effectively used to manage them. Would also then position us to determine how to render these in Calisphere.

    • Changes or extensions to the standard schema. It’s a UCLDC metadata scheme that we developed early on

      • Want to update to support and CC licenses (option to add these) that we can render on Calisphere

      • Potentially include a signal that indicates particular kinds of complex objects, to facilitate their display in Calisphere (e.g., oral history complex object)

    • Community tools

      • Maintenance of the existing tools

        • Revisit the nuxeo_spreadsheet import: UCLA made some improvements to the nuxeo_spreadsheet importer to allow for Google Sheets importing/exporting; but there are performance issues with the most current version. We want to revisit and update the code.

        • File-renaming: option to rename uploaded files on the backend

      • Explore additional publication endpoints

        • E.g., oral history documents -- initial exploration for a Nuxeo → eScholarship integration

  • 3D file support deeper dive:

    • Nuxeo supports the following 3d filetypes: Collada (.dae); 3D Studio (.3ds); FBX (.fbx); Stanford (.ply); Wavefront (.obj); X3D Extensible 3D (.x3d); Stl (.stl)

      • And converts them into this open format

    • Functional overview available in their documentation

    • The viewer in Nuxeo is running 3.js

    • Should be able to take the 3.js library in the open spec 3d file that nuxeo creates and use those, but there’s still some work to hook that all in

    • We'll be in touch with campuses utilizing Nuxeo, to confirm once the 3D support is fully enabled

 Track this on our roadmap
Custom filters on Calisphere
  • We have documentation available on this feature, which can be enabled at the collection-level in Calisphere

  • This functionality is available for any Calisphere contributor -- beyond Nuxeo campuses.

  • And is specifically tied to collections. (Not available for repositories.)

Documentation available
DPLA Analytics Dashboard
  • We have a brown-bag scheduled for October 9, 1:00pm to walk through the DPLA Analytics Dashboard:

  • Before rolling out the Dashboard broadly to Calisphere contributors, we'd like to gather your input and feedback on the functionality -- and also determine if there are any sensitivities around seeing usage info. across other organizations

October 9, 1:00pm

Call-in info:

Dial by your location
+1 669 900 6833 US Toll (San Jose)

Meeting ID: 968 985 231

Test it out: Username:

Password: calisphere

Mediated access to digital materials: use case scenarios
  • Motivations to provide mediated access may include:

    • Materials have not yet been evaluated at an item-level, to assess copyright. Mediated access is viewed as a solution to help mitigate risk.

    • Donor stipulations state that a third-party must sign-off prior to access for reproductions

    • Culturally sensitive materials may also stipulate a third-party sign-off

    • Collections may lack donor documentation

    • Providing at least mediated access may surface materials that can be publicly accessed. There may be items that can’t yet be assessed due to lack of access -- and may need some type of visibility to have conversations with administrators

  • Large scale:

    • These scenarios are provided to demonstrate workflow considerations. Managing large quantities of materials/files could be simplified by pointing users to a centralized point of access.

    • Consider: item-level restriction vs. series-level restriction vs. collection-level restriction

  • Access considerations:

    • UCI wants users to consent to terms of use/track consent (through registration as a reader)

  • Crossover with research data curation:

    • Currently, only a single UC-wide platform (Dryad), which holds only openly available data.

      • Considerations for licensed data, or data with potentially sensitive information?

    • Would it make sense to have a common discovery/delivery platform for access to restricted content managed by UC Libs? Or should restricted data be accessed separately? (What would users prefer?)

      • Tends to consist of different user groups (archival vs. research data)

      • We're currently providing access based on particular formats: 

      • From an end-user perspective, it might make sense to have a centralized platform for restricted/mediated access materials

      • UCSD’s system provides access to both; perhaps they can provide insight on user experience: 

      • Perhaps, look at HathiTrust

Visit wiki workspace

Mediated access to digital materials: requirements (in progress)

  • In parallel, a draft set of requirements is beginning to form based on observations from the use case scenarios provided.

  • Currently at a very high-level to determine requirements for mediated access.

    • Not yet calling out any specific systems yet.

    • Not yet looking at delivery or display requirements.

  • This document is open for comments and suggestions -- we’d like to tighten up these mediated access requirements and make sure they address the use scenarios identified or anticipated.

Visit wiki workspace

Draft set of requirements document is open for comments.