## 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.