Proposed refactor of relationships in Hyrax

relationships.md

Hyrax Models

• Collection
• Work
• FileSet
• File

These are currently created by including...

• CollectionBehavior
• WorkBehavior
• FileSetBehavior
• not sure about Files

Relationships

Currently relationships are setup as...

• Collection memberOf Collection
• Work isPartOf Collection
• Work hasMember Work (used to enforce ordering)
• Work hasMember FileSet
• FileSet hasFile File

Proposed relationships

I recommend storing the model more explicitely in Valkyrie.

# on Collection
attribute :parent_collection_ids, ::Valkyrie::Types::Set.of(::Valkyrie::Types::ID)

# on Work
attribute :parent_collection_ids, ::Valkyrie::Types::Set.of(::Valkyrie::Types::ID)
attribute :child_work_ids, ::Valkyrie::Types::Array.of(::Valkyrie::Types::ID).meta(ordered: true)
attribute :child_fileset_ids, ::Valkyrie::Types::Array.of(::Valkyrie::Types::ID).meta(ordered: true)

# on Filesets
attribute :file_ids, ::Valkyrie::Types::Set.of(::Valkyrie::Types::ID)

If we are going to maintain the ability to produce RDF, I would recommend creating a method that returns the appropriate predicate. Then the methods above combined with the predicate methods can be used to generate RDF.

Getter/Setter methods

Current methods

The current methods for getting and setting relationships are all over the board and do not follow a consistent pattern.

Proposed methods...

COL m..m COL (validation to avoid circular relationship chain)

• parent_collection.add_collections [col1, col2]

• parent_collection.add_collections_by_id [col1.id, col2.id]

• child_collection.add_in_collections [col1, col2]

• child_collection.add_in_collections_by_id [col1.id, col2.id]

• parent_collection.child_collections

• child_collection.parent_collections

COL m..m WORK

• collection.add_works [work1, work2]

• collection.add_works_by_id [work1.id, work2.id]

• work.add_in_collections [col1, col2]

• work.add_in_collections_by_id [col1.id, col2.id]

• parent_collection.child_works

• child_work.parent_collections

WORK m..m WORK (validation to avoid circular relationship chain)

• parent_work.add_works [work1, work2]

• parent_work.add_works_by_id [work1.id, work2.id]

• child_work.add_in_works [work1, work2]

• child_work.add_in_works_by_id [work1.id, work2.id]

• parent_work.child_works

• child_work.parent_works

WORK 1..m FILESET

• parent_work.add_filesets [fs1, fs2]

• parent_work.add_filesets_by_id [fs1.id, fs2.id]

• child_fileset.add_in_work work1

• child_fileset.add_in_work_by_id work1.id

• parent_work.child_filesets

• child_fileset.parent_work

FILESET 1..m FILE

• parent_fileset.add_files [file1, file2]

• parent_fileset.add_files_by_id [file1.id, file2.id]

• child_file.add_in_filesets [fs1, fs2]

• child_file.add_in_filesets_by_id [fs1.id, fs2.id]

• parent_fileset.child_files

• child_file.parent_fileset

Notes:

• Method names should be consistent and represent the relationships.
• Methods should go in both directions even if we only store one direction with the persisted object.
  • The non-stored direction will be less efficient if going against the datastore.
  • The non-stored direction could be stored in SOLR for faster retrieval.