Date: July 19, 2023 @ 10am Eastern
Where: Zoom - https://lyrasis.zoom.us/j/88629285588?pwd=OXFwclBVdTdSdFFLdllncWNPT295UT09
Recording of the Discussion
Resources:
- Document shared by DocuTeam outline their current set up with proposed questions/topics for discussion
Discussion
Questions from DocuTeam to Group:
- Separate LD resources as we are currently trying to do?
- Literals (with own vocabulary of properties) on main resources?
- Inside a NonRDFSource?
- How do others model their objects and respective metadata?
- Do others use the ArchivalGroup to minimize the number of OCFL objects?
- Inventory duplication
- Version file
- F6 specific: .fcrepo folder
- If F6 is an LDP, does this work with the current OCFL storage?
- Can OCFL be used more efficiently?
Notes:
DocuTeam is moving to Fedora 6 not via the migration tool
- Coming from an archival background
- Want to model using archival-specific ontology (PREMIS) (Records in Context)
Creating a lot of Linked Data resources with this model which translates in to many OCFL records
- Find F6 with OCFL storage is creating a huge amount of files and folders if using these linked data resources extensively
Considering 2 options:
- Use hash-URI’s for the individual metadata resources
- Put all metadata - presumably still as RDF - into a NonRDFSource linked to the container
- Would mean that they can’t used Fedora as an LDP in the way it’s intended
- Have started to use Archival Groups to limit the number of OCFL objects
- In this instance it seems that the way they are handling their object records (Metadata is separated into individual objects) it is kind of the opposite of what OCFL is intended to do - ie. keep all of the objects and associated metadata together with it’s provenance etc.
- If one were to remove Fedora and trying to re-assemble the repo with it’s metadata would be very challenging in this set up
- Intention was to keep resources (from an LDP perspective) as individual resources that you might be using from other specific record resources
