Thursday, November 9, 3:10-4:30pm Central, Grand Parlour - B, Orrington Hotel

Facilitator: ruth.k.tillman and Juliet Hardesty

Notetaker: Juliet Hardesty

Attendees:

Community Notes: https://docs.google.com/document/d/1U7L2VLmaZF_l3jTSOg-Q1MVTu76rdcibZqpzNwNtT5w/edit?usp=sharin

Trying to finish documentation and figure out how to present this information for use and to get feedback from community - hopefully by ALA Midwinter

James R. Griffin III (Princeton)
http://slides.com/jrgriffiniii/deck-3
Hyrax 3
Valkyrie is a gem from Data Mapper WG (based on software design pattern, the Data Mapper Pattern)
Backends supported with Valkyrie - Fedora 4, PostgreSQL, Apache Solr, Disk

Separates Persistence from discovery backends
Princeton using Postgres
Hyrax 3, Princeton University Library, and Penn State Libraries using Valkyrie
Hyrax 3 using Fedora for storage but Valkyrie will be there
Valkyrie doesn’t care about structure of resource in repository (no collection, fileset, work, etc concepts); resources can also be a term in a vocabulary; more like RDF classes
Resources have properties but these properties are not in RDF
Decorators and presenters also part of this (didn’t quite understand)

40,000 works already ingested - moving quickly
Resources can be exposed as JSON, showing JSON-LD with namespaces declared and prefixes used to identify predicates for fields; JSON serialization can be used outside of Figgy within Princeton environment overall
IIIF manifests can also be generated (JSON serialization for this as well)

Can take ID’s and transform into URI’s
Take something from Hyrax, into Solr, and then turn that into linked data
Linked_data_attributes_indexer.rb - place in code base where most active dev work happening; early stages right now - https://github.com/samvera/hyrax/blob/valkyrie/app/indexers/hyrax/linked_data_attributes_indexer.rb
Julie Allinson and Justin Coyne working on this already

May be mostly due to performance concerns
This is a Solr sidecar approach (another way to think about it)
Adam Wead’s Solr discovery about turning off auto-suggest seems to have helped (possibly fixed) the Fedora 4 performance problems that have been seen on ingest

Princeton off of Hyrax for forseeable future but interested in helping out where possible; would like to see more developers participating that way

Would be great to work towards version schemas; make our software better able to handle changes to metadata schemas; naming schemas separate from software releases

Documentation Project on wiki - assembling things together here but would like this to be more intentional; share in Hyrax Developer Knowledge Base?
Also DLF AIG MAP Clearinghouse Project? Have to upload to this so would require maintaining in multiple places if we use both Hyrax Dev KB and this

Versioned metadata profiles that can come out with each software release, versioning that way as well is a possibility; can possibly ask DCE to contract for this work
UCSD/UCSB working on something now - want more than just another spreadsheet; want to produce something that can be used; store in GitHub so versioning that way

Developers recommending ways to format that MAP so it’s not something metadata folks create and give to developers to do something with, more immediately usable

What is confusing to you or was confusing when you started with the Samvera Community?

Browser not supported