Attendees
Christine Kim (Guest)
Adrian Turner (Guest)
Not attending
Recording of Meeting
Meeting Recording:
Future agenda items (See the Parking Lot row on the agenda).
Discussion items
Item | Desired Outcome | Time | Who | Notes | Decisions | Actions | |
|---|---|---|---|---|---|---|---|
| 1 | Welcome! | Get the meeting started; review and understand the agenda; raise questions. Record the meeting if there are no objections | 5 | Claudia | Notetaker: Lisa | ||
| 2 | News from PPC (Policy & Practice Coordinators) meeting | Learn relevant news, context, decisions, etc. from PPC meeting | 5 | Claudia | |||
| 3 | Calisphere, Nuxeo, the Registry, and OAC | 30 | Guests: Christine Kim, Adrian Turner | Content for Calisphere coming from Nuxeo and from harvested sites; the Registry drives the harvesting process. It is viewable, but not designed to be a public system. Records include item pages and collection landing pages. Item pages have a mocked up OAI-PMH like record for the SILS, as a work-around until a full OAI-PMH endpoint is built (see the link in the slides). There is also an API to the SOLR index; expressed in JSON and is primarily used by DPLA. Collection level records are separate; to get those in the SILS, we would need to provide JSON based collection level records through the API to the SILS. Question re the Registry including all collections from OAC as well? When the registry was built, there was a one-time pre-seeding of collections using OAC finding aid data; the thinking was that would provide pre-existing collection descriptions for collection landing pages in Calisphere. So there is no programmatic connection between OAC finding aids and collection descriptions in Calisphere. The Registry is used to drive Collection Landing pages in Calisphere only. Some of the registry information isn’t public. It’s also used to drive the harvesting work as well. The Registry API could be used to load Collection Records into the SILS. The Collection information in the Registry is always up to date with what is in Calisphere. To update collection descriptions, that needs to be updated in the Registry (an account is required). The title and descriptions show up real time in Calisphere. The OAC field in the Registry is manual--OAC and the Registry don’t know about each other programmatically. But updating the finding aid in the Registry will show up automatically in Calisphere. Also updating the URL in the locally hosted DAMS will also show up. For campuses that are harvested by the Calisphere, the information in the Collection landing page needs to be updated in the Registry. (Example of a collection with a link to OAC and the local system https://calisphere.org/collections/25496/) OAC: based on an ingest model--processing EADs. come from a variety of places--RecordExpress, ArchivesSpace. Some contributors use other systems. There’s an XML repository holding those records. HTML views are at the top. For SILS, can support OAI-PMH export/import right now. Can create sets for a given collection. It’s not the full finding aid, it’s the collection’s top level description. Here’s an example of a set for UCI: http://content.cdlib.org/oai?verb=ListRecords&metadataPrefix=oai_dc&set=uci_spcoll:ead So it doesn’t include the detailed inventory. | |||
| 4 | Reviewing Collaborative Workflow Testing | 10 | Everyone | Should DCFG be added/removed as an impacted group from any of the items on the list? Do we agree with the prioritization? | |||
| 5 | Update on Finding Aids/OAC (Defer to next week if there’s no update) | 10 | Lisa, Gabriela | We were able to get the OAC OAI-PMH feed configured, but the import fails to bring in any records. Ping Gao from Ex Libris is looking into it for us. | |||
| 6 | Parking lot | Everyone | Kate had posted to Slack: Can we revisit a previous discussion about the COLLECTIONS feature in Alma/Primo VE? So far Kate has found that everything has to be in Alma first, in order to create the collections. UCI has one collection of this type. | ||||
| 7 | TOTAL | 60 |
: