Skip to content

Overview

Jump to bottom
Julie Allinson edited this page Dec 7, 2018 · 9 revisions

Overview

DogBiscuits 🐶 🍪 provides a set of re-usable components for adding 'Works' to Hyrax applications.

Models

A range of models for common object types are provided. Models are grouped into four types:

  • Works
  • Collections
  • FileSet
  • Authorities

Works

Works represent resources proper, ie. the resources we are managing in our repository and want to describe, such as a thesis, the work depicted by an image, a dataset etc.

Works correspond to what is generated with the Hyrax Work generator, and the dog_biscuits Work generator.

Works adhere to PCDM and the PCDM works extension as implimented by Hydra::Works.

  • All works inherit from a based class (Work), which in turn inherits from ActiveFedora::Base
  • Works MUST have a title

Current work models are:

  • Conference Item
  • Dataset
  • Digital Archival Object (developed to represent an EAD DAO, referenced by an archival item description)
  • Exam Paper
  • Journal Article
  • Package (developed to represent an AIP/DIP from Archivematica)
  • Published Work
  • Thesis

FileSets

There is only one FileSet class. This class currently does not stray far from Hyrax::FileSet and includes Hyrax::FileSetBehavior. FileSets must be a member of a Work.

It is included here to allow for addition of extra metadata (eg. content version for journal articles) and also for specialized relationships between a Work and a FileSet.

See models/concerns/metadata_properties/dlib/main_file.rb for an example of a specialized relationship being used to indicate which FileSet contains the 'main' file (eg. the thesis, rather than any ancillary files).

  • Please Note: DogBiscuits::FileSet has not been used in a Hyrax application and would require extra work for it to be supported fully with a generator.

Collections

Do not use. WIP.

Authorities

Authorities are things which help describe Works, but that are are not classed as works themselves in the context of the repository (and so are not modelled as PCDM objects).

Authorities are loosely conceived as anything where we need to store more information than can be done a single literal property on a Work and where we want to do that as objects in our Fedora repository.

  • All authorities inherit from an Authority class, which in turn inherits from ActiveFedora::Base

  • All agent classes (people, organisations) inherit from Agent class, which in turn inherits from Authority.

  • Authorities MUST be contained within a ConceptScheme if they are to be used with Questioning Authority.

Current authority models are:

  • Agents (People, Organisations, Groups)
  • Concepts
  • Concept Schemes
  • Projects
  • Events

In the current implementation, authorities are completely independent of Works/FileSets/Collections. They can, however be used to populate an auto-suggest field using questioning authority in a Hyrax application.

Concerns

The Models are built-up of concerns like Lego.

The Concerns folder is structured for human navigation, like so:

  • concerns/behaviours - validation and behaviours
  • concerns/metadata_properties contains individual properties organised into directories by scheme name (eg. dc)
  • concerns/model_property_sets - groups of concerns or properties for a specific model

As a general rule:

  • if a metadata property is useful across multiple models, it will have it's own concern file (eg. metadata_properties/premis/has_restriction)
  • if a property is specific to a single model (and its children) it will be specified on the model itself or in a metadata_properties/property_sets concern

Indexers

Indexer classes for each Work model are where we can add special indexing rules.

Callbacks

Callbacks are a handy way of doing extra stuff before the record is saved (and at other times). For authorities, callbacks are used to construct a label from name parts for Places, People, Groups and Organisations. They are also used to ensure that the rdfs:label and skos:preflabel are the same.

Vocabs

Each property defined in the models needs to come from a vocab. There are three ways to do this:

  • Terms from existing ontologies that are already supported in RDF::Vocab, eg. ::RDF::Vocab::FOAF.name PREFERRED
  • Terms from existing ontologies that are not supported in RDF:Vocab, eg. ::RDF::URI.new('http://purl.org/spar/fabio/ExaminationPaper')
  • Terms from locally defined ontologies, eg. DogBiscuits::Vocab::Uketd.qualificationLevel

The aim is always to use existing properties/predicates wherever possible but some Vocabs have been defined locally.

Note: New properties should be submitted to the Samvera URI Management Working Group.

Validators

Validators are called before an object is saved. Use of validators have been kept to a minimum, but could be extended. Four currently exist:

  • validate labels so ensure works have a title and authorities have an rdfs label
  • validate concept_schemes to ensure they only contain authorities
  • validate concepts to ensure that a see_also cannot be added if it is already a narrower/broader
  • validate place to ensure it has a place_name

Services

Services contains the code needed to support object-based questioning authority authorities.

Terms contains a class for each authority list we want. Currently, these are:

  • People
  • Groups
  • Organisations
  • Departments
  • Subjects
  • Projects
  • Places

The generators use these services to drop the correct configurations and code into place in the calling application. The naming convention here is significant.

TermsService contains all of the code needed to use questioning_authority with the terms lists. This code uses solr to retrieve terms.

Generators

These are documented in the Generators page

Rake Tasks

TODO

Clone this wiki locally