UCLDC Product Stakeholder Group
Face-to-Face Meeting: January 14, 3014
Notes
Schedule
10:00 – 10:30
10:30 – 12:00
12:00 – 12:30
12:30 – 1:00
1:00 – 2:45
2:45 – 3:15
3:15 – 4:30
4:30 – 5:00
Introductions, review of agenda
Exploration of Calisphere and the UCLDC
Break for lunch
Working lunch topic: the Collection Registry
6 questions to dig into the public interface
Break
“Buy the feature!”
What next?
Exploration of Calisphere and the UCLDC
Discussion of a straw-man proposal for realizing efficiencies and combining the two sites/services.
General discussion:

Proposal addresses a big question that the campus libraries have: what is the UCLDC and how
does it relate to Calisphere?

Repository/workflow proposed (through DAMS/harvest) is much more sustainable way of
ingesting collections than Calisphere METS repository; UCLDC is a solution to replacing local
development efforts and infrastructure. Makes sense to replace Calisphere workflow here.

Regarding the interface, availability of resources is key: if it’s not possible to maintain and
continually upgrade Calisphere once UCLDC is launched, this provides a way to continue the
aims of both projects

“Curatorial” aspect of Calisphere is still desired, and UCLDC provides opportunity to both
continue this tradition and expand upon it (see below for more detail)

There are both opportunities and challenges around the Calisphere name and brand for the
UCLDC public interface (see below for more detail)

General comfort with the idea of expanding the content base exposed through the UCLDC public
interface (whatever its name), but crucial to provide branded campus landing pages—meeting
one of the main needs of this service, which is clear “portal” to each campus library’s collection

What would be the strategy for migrating existing Calisphere to the new Calisphere?
o

Calisphere would initially be a harvesting target. Eventually wean off of Calisphere,
once those collections are loaded in the DAMS/pulled from a local system
How about resolution of ARKs and maintenance of persistent URLs?
o
We'd eventually redirect the ARKs to the new Calisphere target
Sub-topic 1: curation opportunities:

Since one of Calisphere’s major draws is its “themed collection” or topical grouping approach,
some of the conversation focused on this aspect of the platform and moved more generally to
an interest in curation options; conversation was wide-reaching and could use follow-up
o
Talked both about curation within the shared space/public interface as well as locally

Interest in curation options similar to what Calisphere currently provides, but in a more evolving
way (currently the collections on Calisphere are in a fairly rigid historical framework)

Potential for campuses to provide metadata to help drive other re-uses as they are desired, e.g.
for a particular user group or purpose

API will also be available, but not all campuses will have resources to take advantage of it

Omeka particularly of interest—current version may have more functionality for integrating with
UCLDC DAMS infrastructure

Potential for co-development opportunities around this area?
o
Shared solutions for creating local, custom/tailored portals?
o
Drupal has a CMIS bridge -- could integrate with Nuxeo, which supports CMIS
o
Providing faculty with a tool or set of tools to create custom views of content.
Subtopic 2: brand/name:

Calisphere brand has been viewed as K-12 resource at campus libraries; if we’re going to reuse
the name/brand, we’ll need to communicate that primary audience is scholars, researchers
within UC

Many primary sources in our collections are used by students and researchers well beyond our
campus; Calisphere brand could be repurposed since it is already reaching these users

Interesting that users’ perceptions are that Calisphere is not K-12; libraries will want to know
more about this. Seems like all users really care about is getting access to the stuff.
o
(CDL data suggests that end-users aren’t hung up on K-12 aspects of Calisphere.
Between 1/3-1/2 of total Calisphere users are academic (faculty, grad students,
undergrad).)

“Calisphere” is flexible. If UCLDC expands beyond UC libraries (e.g. inclusion of UC museums,
organizations beyond UC), we want to think about this and keep the name broad. “Calisphere” is
nice because it doesn’t prematurely limit the options.

Part of the appeal/power of the Calisphere brand is “University of California”

At the end of the day, UCLDC will require a lot of marketing effort—whether or not Calisphere is
used. It would just be a different emphasis of marketing if keeping Calisphere, maybe some
adjustments to that brand as well as how we talk about it.
Subtopic 3: showcasing campus content in a broader collection

There was interest in the idea of the UCLDC content base growing beyond the current scope of
UC Libraries, but focus of UCLDC is to showcase UC libraries – this has been the missing piece

Ownership of content is fuzzy—there’s already non-UC owned content within the mix of stuff
slated for initial inclusion (e.g. Merced’s digitized civil war diaries, which are physically owned by
a community member).

An approach that resonated: UC content goes through the UC Libraries, as "UC sponsored"
projects or “UC stewarded” collections – could characterize as "UC Libraries and their partners".

Another possible approach: phased, where initial focus is on UC Libraries content, but ramp up
to start working with other institutions

Very important for campus content to be subsetted—i.e. landing pages for individual
campuses—and that there is clear identification, branding for campus libraries there.
o
Like Internet Archive where there is a “channel” for each campus?
o
Calisphere could be top-level brand, with sub-brands for individual campuses?
o
Or the other way around, where Calisphere is a “subsite” of the UCLDC?
o
Also goes back to the idea of the API and curatorial options, with campus portals also
existing beyond the public interface – e.g. if there was a special occasion or anniversary
Collection Registry overview: discussions and Q&A
Brian Tingle presented an overview of the Collection Registry and the key functional requirements for
and intended use of this particular component of the UCLDC framework
(https://wiki.library.ucsf.edu/display/UCLDC/UCLDC+Model+and+Major+Components#UCLDCModeland
MajorComponents-CollectionRegistry). Summary of additional comments and questions raised during
the overview:

There was broad interest in building out the Collection Registry's functionality, in the area of
supporting collaborative digital collection development. For example, the data model could be
extended to include non-digitized collections -- and could be used for digitization planning and
prioritization, for identifying collections "on deck" for publication in the UCLDC public interface,
etc. Data such as extent, topics, and rights status would be important to capture for nondigitized collections. For both digitized and non-digitized collections, extent information would
be particularly useful for tracking and for reporting statistics (e.g., ARL, UCOP Schedule F).

Participants proposed developing and refining use cases for the Collection Registry, specifically
pertaining to the area of collaborative digital collection development and digitization planning.
This activity could be part of the purview of an existing SAG3 sub-group -- where members of
that group are also on the UCLDC Project Stakeholder Group.

It would be helpful to more clearly delineate and define types and categories of collections, and
associated collection-related information, that should be tracked and managed in the Collection
Registry. There are currently a range of types of collections represented in the Collection
Registry, ranging from provenance-based collections to aggregations of materials that are
related topically or by form/genre.

The Collection Registry currently contains information for provenance-based collections, where
those collections are already described in the form of finding aids within the OAC. As we build
out the functionality of the Registry, we'll need to be aware of not duplicating and overlapping
information in OAC.

We should consider promoting or providing specific recommendations for supplying collectionrelated information in the Collection Registry, such as standardized rules for collection titles.
Buy-a-Feature Recap
The group participated in a collaborative activity for determining the relative priority of public interface
features and requirements. Each of the nine attendees was given $150 in monopoly money to apply
towards any of 45 identified features with "costs" ranging from $10 - $300. For a more detailed
explanation of the activity, see http://www.uxforthemasses.com/buy-the-feature/

Faceting by collection title: general consensus was that this wouldn't really work well, given that
collection titles would be fairly heterogeneous -- and not a useful mechanism to winnow results
post-search or browse.

Facet by campus: there was strong interest in the development of campus/unit-level landing
pages, and the ability to facet and subset by campus.

Advanced search: there was general interest in supporting advanced search operators, in
particular, targeted searching within particular metadata fields (e.g., title, local identifier) -although not necessarily supporting the creation of an advanced search page. Searching within
results was also identified as important.

Download: participants noted that users will find a way to download content; if building in
download options, it would be an opportunity to incorporate features that ensure users are
aware of the re-use terms and the rights status of objects -- as part of the download process.

Access control using Shibboleth: this was viewed as a high-priority feature, although there were
not enough collective funds to purchase it. We would also need to support an option for nonUC affiliates to access content, without authenticating.

Comments: Participants indicated if they had additional funds, they would have purchased this
feature, and suggested that a registration process may need to be required for end users to
post.
Wrap-up discussion

There was a broad interest in opportunities to participate in sub-group or work teams, and also
in co-developing components of the UCLDC infrastructure. In particular, there was strong
interest in collaborating on tools and infrastructure needed to create local, custom/tailored
portals to content in UCLDC. Suggested that the wiki could serve as a workspace and listing of
"micro tasks" for particular collaborative tasks.

Participants welcomed and solicted for ongoing requests from the Project Team for input and
feedback on UCLDC components, as they are being developed.

Participants noted that the release notes and brief video tutorials from the Aggie release were
instructive and useful, especially in communicating development activities to campus
colleagues; suggested that this model is continued for future releases.

Participants appreciated the opportunity to meet in-person, and suggested other future inperson meeting opportunities (e.g., timed with regional conferences). As one PSG member
noted, it was instructive to have an opportunity to share information about individual campus
activities -- "we're building a shared infrastructure".