Hi pals,

Julia Weist from Collective Access shared some thoughts with me, and now
I'm sharing them with you. Note: I'm not saying we should use CA for our
catalog, just that Julia gives us some things to think about.

Jenna

---------- Forwarded message ----------

We have some experience with consortium projects here at CA, and those
function similarly to how a cooperative union catalog would.  In those
cases, we've had associations (comprised of several dozen museums) manage
individual back-end systems where they separately enter their data.  Those
back-ends systems, though separate, are identical in terms of metadata and
configuration.  Each system sends data (through scheduled migrations--could
be daily) into a single aggregator system.  That pooled back-end fuels a
single front-end.  We've learned a few lessons with this, and I'll share
those in case they are helpful!

1. We had to develop special tools which I'll call "metadata quality
   assessment rubrics" which use regular expression (/pattern matching) to
   flag data that was subpar based on the rules of a shared content standard.
   This helps your data look clean and consistent when it's being created from
   so many different cataloguers.

2. Every difference between systems adds complexity.  In our case this
   wasn't a concern because we designed all the systems to be identical, but
   if you're working with various partners on various platforms it can quickly
   become a ton of crosswalking and custom sub-projects to get one system to
   talk to another.  My advice would be to pick one shared platform and a
   common metadata schema.

3. The aggregation needs to be have built in rules to handle authority
   reconciliation.  What happens if two people submit data about the same
   person on the same day?  Who's is kept?  Are they merged?  If merged, will
   the data be redundant?  Sometimes this can be entirely handled with a rule
   set, other times a human intelligence is required.

CollectiveAccess could certainly work for this, because as I mentioned
we've done it before so it wouldn't require reinventing the wheel.  But
configuration, build out, partner wrangling and support does take time, so
we'd need funding if you wanted to go that route.

In any case I'm happy to provide an opinion here and there if that helps,
or to talk more seriously about using CA if you want.  In either case
sounds like a great project!

Julia

Zlunioncat mailing list
Zlunioncat@lists.qzap.org
http://lists.qzap.org/listinfo.cgi/zlunioncat-qzap.org

Hello Allison,

I like DPLA and I know the person in charge of the hub up here in
Minnesota.  My only question about DPLA is the “Digital” part.  Many of the
zine collections involved in this project are not digitized collections.
Many will never be digitized.

Would the Digital Public Library of American still be interested in
helping us develop a database without fully digitized content?

If so, then I’m for it.

Elissah Becknell

Librarian & Instructor

Minneapolis Community & Technical College Library

1501 Hennepin Avenue/Minneapolis, MN 55403

612-200-5334

elissah.becknell@minneapolis.edu

From: Zlunioncat [mailto:zlunioncat-bounces@lists.qzap.org] *On Behalf
Of *Allison Jai O'Dell
Sent: Monday, October 12, 2015 9:51 PM
To: zlunioncat@lists.qzap.org
Subject: [Zlunioncat] DPLA Hub

While we're on the subject of platforms...  I've been thinking some more
about the idea of ZLUC = DPLA Hub.  (DPLA Hubs aggregate metadata and/or
content from their partners and contribute it to DPLA, the Digital Public
Library of America.)  The more I think about it, the more it seems to make
sense for us.  Some reasons:

• DPLA is DPLA, not an individual institution, and not OCLC.  They're all
  about openness, freedom, and collaboration.

• DPLA is the platform.  We don't have to develop one.

• But we can develop apps, to create discovery interfaces tailored to
  specific needs and/or collections.  The DPLA model, and its friendly API,
  encourages developers to create and share apps -- supporting information
  discovery, and also innovation.

• The app approach lets individuals work individually, while contributing
  to the shared project.  For instance, Allison, associated with U.Florida,
  can get a grant to develop an app that does some thing...  Thus, the
  project team can remain loosely affiliated, while individuals take on app
  development.

• DPLA likes ingesting Dublin Core metadata, and xZINECOREx is based on DC.

• DPLA can handle both digitized content and metadata records alone.  It
  can link out to information about holding institutions, their catalogs, etc.

• DPLA has a wide and immediate audience.  We don't have to build one.

• Zines will be discoverable alongside other cool stuff -- or not.  We can
  create apps and queries that target just the ZLUC content.

• If the ZLUC project does tank, the data lives on in DPLA.  We don't
  have to commit ourselves forever in order to do something meaningful.

Thoughts?

Allison

On Mon, Oct 12, 2015 at 10:14 PM, jenna freedman leslzine@gmail.com
wrote:

Hi pals,

Julia Weist from Collective Access shared some thoughts with me, and now
I'm sharing them with you. Note: I'm not saying we should use CA for our
catalog, just that Julia gives us some things to think about.

Jenna

---------- Forwarded message ----------

We have some experience with consortium projects here at CA, and those
function similarly to how a cooperative union catalog would.  In those
cases, we've had associations (comprised of several dozen museums) manage
individual back-end systems where they separately enter their data.  Those
back-ends systems, though separate, are identical in terms of metadata and
configuration.  Each system sends data (through scheduled migrations--could
be daily) into a single aggregator system.  That pooled back-end fuels a
single front-end.  We've learned a few lessons with this, and I'll share
those in case they are helpful!

1. We had to develop special tools which I'll call "metadata quality
   assessment rubrics" which use regular expression (/pattern matching) to
   flag data that was subpar based on the rules of a shared content standard.
   This helps your data look clean and consistent when it's being created from
   so many different cataloguers.

2. Every difference between systems adds complexity.  In our case this
   wasn't a concern because we designed all the systems to be identical, but
   if you're working with various partners on various platforms it can quickly
   become a ton of crosswalking and custom sub-projects to get one system to
   talk to another.  My advice would be to pick one shared platform and a
   common metadata schema.

3. The aggregation needs to be have built in rules to handle authority
   reconciliation.  What happens if two people submit data about the same
   person on the same day?  Who's is kept?  Are they merged?  If merged, will
   the data be redundant?  Sometimes this can be entirely handled with a rule
   set, other times a human intelligence is required.

CollectiveAccess could certainly work for this, because as I mentioned
we've done it before so it wouldn't require reinventing the wheel.  But
configuration, build out, partner wrangling and support does take time, so
we'd need funding if you wanted to go that route.

In any case I'm happy to provide an opinion here and there if that helps,
or to talk more seriously about using CA if you want.  In either case
sounds like a great project!

Julia

Zlunioncat mailing list
Zlunioncat@lists.qzap.org
http://lists.qzap.org/listinfo.cgi/zlunioncat-qzap.org