Predicates for technical metadata

[eporter23]

While testing persistence in Fedora, many of our extended technical metadata properties are assigned to an http://example.com namespace. We should adjust this to reflect actual established namespaces where these properties are formally defined.

To discuss: with changes in Valkyrie and FileMetadata, do we need to re-identify RDF predicates for all characterization properties?

Original worksheet with RDF predicates used for Curate:
https://docs.google.com/spreadsheets/d/1csDcDnJdhB1VLlgJUU95DndXSeIP2j8yPMlErrsVVPw/edit#gid=1836172006

Hydra: Works schemas:
https://github.com/samvera/hydra-works/tree/fc6680591ac4bf29309202ca0033c1ed7d778d5c/lib/hydra/works/characterization/schema

Some of our local additions to the Hydra Works schema for Curate:
https://github.com/emory-libraries/dlp-curate/blob/main/app/models/schemas/curate_file_schema.rb

Valkyrie FileMetadata:
https://github.com/samvera/hyrax/blob/main/app/models/hyrax/file_metadata.rb

[eporter23]

Additional note: it appears that many of the original properties using the ebucore namespace are now changed, after an ebucore update. So, we can either try to match them up to the new properties or create our own predicates.

[eporter23]

As a precursor, Emily will review which attributes are receiving an example.com predicate vs what is defined here https://github.com/samvera/hyrax/blob/main/config/metadata/hyrax_internal_metadata.yaml

[bwatson78]

A couple of files that details the attributes:
https://github.com/samvera/hydra-works/blob/main/lib/hydra/works/characterization.rb
https://github.com/samvera/hydra-works/blob/main/lib/hydra/works/characterization/fits_document.rb

Those are referenced here: https://github.com/samvera/hyrax/blob/main/app/services/hyrax/characterization/valkyrie_characterization_service.rb

[eporter23]

Brad is going to run the attributes for both FileSet and File metadata to see how values are being assigned.

[bwatson78]

@eporter23 Here is the link to my spreadsheet that details what does/doesn't have predicates: https://docs.google.com/spreadsheets/d/1fKTeEAHyzyDuyh_GVzauVQnEXptn4IKAuQtT_jSho3o/edit#gid=0

[eporter23]

This is great, thanks @bwatson78 !

[eporter23]

@bwatson78 I've added predicates to everything I think is applicable to us. Note: there are both checksum and original_checksum attributes and we may need to confirm which is which - I think in Curate we used both, but included our 3 checksum values in one vs. the other. I've added comments about that in the worksheet.

[bwatson78]

@eporter23 It's funny you mention that. When I was writing the code for our checksum customization, I noticed that checksum wasn't being indexed to any Solr field. Let me reference that PR here--just a moment.

[bwatson78]

There's an open issue with Hyrax: samvera/hyrax#6794

[bwatson78]

With #224, I had to create the original_checksum field since it wasn't initiated on the Valkyrie side of things.

[bwatson78]

Let me amend my previous statement: it is indexed into a Solr field, but the troublesome piece is that all of the UI interactions only look at original_checksum. I don't know why they decided to arbitrarily change the field name that Valkyrie uses, but they did.

[bwatson78]

@eporter23 For This probably an embedded document file title. If we map it, it may conflict with other DC titles?, I have dug into Samvera's repositories and have confirmed that we could use http://purl.org/dc/elements/1.1/title (RDF::Vocab::DC11.title) for file_title without conflict. For Valkyrie-specific predicates, Samvera uses http://purl.org/dc/terms/title for title, which shouldn't clash. The only history I find in Samvera of using http://purl.org/dc/elements/1.1/title for title in the past is in a model intended only for rSpec mocking.

[bwatson78]

@eporter23 https://www.semanticdesktop.org/ontologies/2007/03/22/nfo/#hashValue is confirmed for original_checksum.

[bwatson78]

PR made: #316

I have also created a PR with Hyrax to address the fields that match predicates but lack them on the Valkyrie processing side: samvera/hyrax#6820

[eporter23]

I was trying to check this out in the test environment but I'm running into errors there: #325 - I will try to test in arch however.

[eporter23]

@bwatson78 looking great with the recent changes! I know that fixity checking isn't currently supported in Hyrax, and we'll likely have to do our own local fix for this, and I'm not sure which attribute they previously used. I do see that our hashValue with 3 checksums is populated, though, so I will close this ticket.