Adds a permissive schema to the Fedora Valkyrie adapter (#6332).

[bwatson78]

Fixes

Fixes #6332

Summary

Processes predicates from metadata YAMLs for permissive schema.

Guidance for testing, such as acceptance criteria or new user interface behaviors:

• Bring sirenia docker container online (docker compose -f docker-compose-sirenia.yml up)
• Create a Monograph object in the UI (localhost:3002).
• Open the Fedora UI and find the Monograph object (id will match the show page's path end).
• Click the object and ensure that the predicates to the left of the fields creator, dateSubmitted, modified, and title all contain the letters "dc".

Type of change (for release notes)

notes-valkyrie Valkyrie Progress

Detailed Description

Our Basic and Core Metadata terms didn't have their predicates carry over when we transitioned to Valkyrie from ActiveFedora. This code implements the assigning of predicates in the Metadata YAMLs and logic to build the permissive schema required to pass to the Fedora adapter.

Changes proposed in this pull request:

• *.yaml: adds the legacy predicates to core and basic metadata attributes, as well as inserts fictitious predicates to those objects that are only used for examples. Helpful comments instructing users to only create attributes in these YAMLs have also been added.
• .koppie/config/initializers/1_valkyrie.rb: uses the new Hyrax::SimpleSchemaLoader method to populate a schema hash for the Fedora Valkyrie adapter.
• app/services/hyrax/simple_schema_loader.rb: creates a schema delivery method and two supporting private methods that assist with its construction.
• spec/services/hyrax/simple_schema_loader_spec.rb: tests the intended functionality of the schema method.

@samvera/hyrax-code-reviewers

[dlpierce]

Looking good. Some fields are still given the "example.com/predicate" schema, mostly the internal attributes that are defined outside of the metadata yaml files. What do you think of having a specially named yaml file that only defines the predicates for those internal attributes? I guess it would look like:

id:
  predicate: http://purl.org/dc/terms/identifier
internal_resource:
  predicate: ???

[dlpierce]

Also, I see the simple schema loader will not redefine an existing predicate pair, but perhaps that should raise an error or at least log a warning?

[bwatson78]

@dlpierce Yeah, I saw that. Is there a good location for all of those internal attributes? Wanna knock them all out if I can.

As far as the simple schema loader not redefining the predicate pair--I did that on purpose, since the YAML files from the main application comes first, effectively overriding any predicates that are defined in the Hyrax engine. I can throw a Rails log warning every time a predicate has the potential of being overwritten, if you'd like.

[dlpierce]

config/metadata/hyrax_internal_metadata.yml with a note in it that it's not used to define properties like the other yml files, just define predicates?

[bwatson78]

@dlpierce Ready for another look.

[dlpierce]

I think this looks good! @jlhardes and/or @rjkati what do you think of the chosen predicates?

[jlhardes]

Basic and core metadata match up with the predicates I know about from SMIG and the Metadata Application Profile. Collection metadata also seems to match up to basic metadata properties and that is what we want to use. I'm not so sure about file set metadata or hyrax internal metadata, but the predicates assigned seem like they would be OK to use if I understand the properties being defined.