Customizing Metadata Tutorial: Defining Metadata in the Model

This tutorial assumes that you generated a work type name GenericWork. If you used a different name, substitute that name for all occurrences of GenericWork and generic_work.

The GenericWork class is generated with some default metadata, but we want to update it with our own metadata. The generated version of the file looks like…

# Generated via
#  `rails generate hyrax:work GenericWork`
class GenericWork < ActiveFedora::Base
  include ::Hyrax::WorkBehavior
  include ::Hyrax::BasicMetadata
  # Change this to restrict which works can be added as a child.
  # self.valid_child_concerns = []
  validates :title, presence: { message: 'Your work must have a title.' }
end

Basic and Core metadata

For an current list of metadata fields for the latest version of Hyrax, see the Metadata Application Profile.

Basic metadata

Basic metadata properties are defined in app/models/concerns/hyrax/basic_metadata.rb

Property	Predicate	Multiple

Property	Predicate	Multiple
label	ActiveFedora::RDF::Fcrepo::Model.downloadFilename	FALSE
relative_path	::RDF::URI.new(‘http://scholarsphere.psu.edu/ns#relativePath’)	FALSE
import_url	::RDF::URI.new(‘http://scholarsphere.psu.edu/ns#importUrl’)	FALSE
part_of	::RDF::Vocab::DC.isPartOf	TRUE
resource_type	::RDF::Vocab::DC.type	TRUE
creator	::RDF::Vocab::DC11.creator	TRUE
contributor	::RDF::Vocab::DC11.contributor	TRUE
description	::RDF::Vocab::DC11.description	TRUE
keyword	::RDF::Vocab::DC11.relation	TRUE
rights	::RDF::Vocab::DC.rights	TRUE
rights_statement	::RDF::Vocab::EDM.rights	TRUE
publisher	::RDF::Vocab::DC11.publisher	TRUE
date_created	::RDF::Vocab::DC.created	TRUE
subject	::RDF::Vocab::DC11.subject	TRUE
language	::RDF::Vocab::DC11.language	TRUE
identifier	::RDF::Vocab::DC.identifier	TRUE
based_near	::RDF::Vocab::FOAF.based_near	TRUE
related_url	::RDF::RDFS.seeAlso	TRUE
bibliographic_citation	::RDF::Vocab::DC.bibliographicCitation	TRUE
source	::RDF::Vocab::DC.source	TRUE

Core metadata

Core metadata properties (that should never be removed) are defined in app/models/concerns/hyrax/required_metadata.rb

Property	Predicate	Multiple

Property	Predicate	Multiple
depositor	::RDF::URI.new(‘http://id.loc.gov/vocabulary/relators/dpt’)	FALSE
title	::RDF::Vocab::DC.title	TRUE
date_uploaded	::RDF::Vocab::DC.dateSubmitted	FALSE
date_modified	::RDF::Vocab::DC.modified	FALSE

Extend the model

To add a new single-value property

To define a property that has a single text value, add the following to the GenericWork model.

  property :contact_email, predicate: ::RDF::Vocab::VCARD.hasEmail, multiple: false do |index|
    index.as :stored_searchable
  end

It will be limited to a single value (set multiple: true or leave off for multi-value, which is the default behavior)
If included in the new/edit form, it will have input type=text (There is a bit more configuration under section Add the new single-value property to the new/edit form to have this included in the form.)
By setting index.as :stored_searchable, values will be added to the solr_doc as contact_email_tesi indicating this field is English text (te), stored (s), indexed (i)
- See Solr Schema documentation for more information on dynamic solr field postfixes.
- See Solrizer::DefaultDescriptors documentation for more information on values for index.as

Are all values described in Solrizer::DefaultDescriptors supported within Hyrax property definitions?

To add a new multi-value property

To define a property that has multiple text values, add the following to the GenericWork model.

  property :contact_phone, predicate: ::RDF::Vocab::VCARD.hasTelephone do |index|
    index.as :stored_searchable
  end

Expected behaviors for this property:

Can have one or more values assigned. NOTE: By default properties are multi-value. You can also explicitly state this by adding , multiple: true before do |index|
The remaining basic behaviors are the same as for single-value properties. See more information under Add the new single-value property to the model Expected behaviors.

To add a new controlled vocabulary property

The process for adding a propery whose value comes from a controlled vocabulary is identical to that of the single and multi-value properties. We will add a single-value controlled vocabulary field here so that it is available for use in later examples.

Expected behaviors for this property:

The behaviors are the same as for single-value properties because we set the property up to be single-value. If this were multi-value, it would follow the behaviors of a multi-value field.

The modified model

With all three properties added, the GenericWork now looks like:

Samvera