-
Notifications
You must be signed in to change notification settings - Fork 7
1.10 Metadata
Properties and their predicates come from Hyrax::BasicMetadata
Following the pattern for the Hyrax::BasicMetadata mixin, a local module could define full or partial ontologies. The cost of superfluous properties seems low and is outweighed by the benefit of being able to easily accommodate fields in views without having to alter models. So a module like ESSI::Image::Metadata could be mixed in the way Hyrax basic is within the model at https://github.com/IU-Libraries-Joint-Development/essi/blob/master/app/models/image.rb#L13
Note that BasicMetadata has to be the last included.
https://github.com/IU-Libraries-Joint-Development/essi/blob/work_type_customizations/app/models/image.rb#L12 https://github.com/IU-Libraries-Joint-Development/essi/blob/work_type_customizations/app/models/concerns/essi/extended_metadata.rb
It's "complicated", but essentially most predicates are defined in PlumSchema.
But note that more properties get set at various times that can be traced back to other schema and vocab classes.
In an earlier experiment for Biblio based on Curation Concerns, the available metadata in models and resulting display in views was dynamic via configuration. This could probably be lifted and fitted into Hyrax. The relevant details with links to code follow.
The default configuration serves as a model for other custom work type configurations.
The configuration for the Opera TV bibliography illustrates a complex configuration.
Reading and stashing the configuration in a watched directory is done in an initializer.
Examples of using the stashed configuration for a specific Work Type can be seen in the Blacklight results index view and the show view.
Configuration via an initializer would be mostly the same, but injecting into views and forms is more complex due to the Presenter pattern and reliance on the Solr document (vs. direct property access via Fedora.)
This commit from an experimental branch contains all of the changes necessary to display a single statically defined field, which illustrates where dynamically derived configuration would be injected. The direct references to a single property in that example would be replaced with code to iterate over formatted field configuration that is specific to a Work Type.
This commit and this commit from an experimental branch show how this would work in Hyrax 2 with the scientific work type. Here, the views are controlled from a config file that can be changed live using the methods described above. Note that this is not fully fleshed out: more fields should be added and the solr document classes are still hard coded.