Document vs. Links

The metadata for DAMS PAS is stored in a triplestore, and assembled into virtual datastreams for the Fedora REST API by DAMS Repository. Each object, collection, name, subject, etc. has its own RDF graph, with its own unique ID. A typical object record will link to many records both for core metadata (names, subjects) and for administrative metadata (preservation events, ownership, collection membership). DAMS Repository provides the ability to retrieve either a single record, or to recursively retrieve a record with all the other records it links to.

When modeling our objects in Hydra and mapping between our triplestore and datastreams, we've explored two basic approaches:

1. Document: objects are retrieved recursively and all metadata is included in a single datastream. Relationships between classes are parsed from the RDF/XML and loaded as needed. RELS-EXT is only populated with a model (derived from the record's rdf:type) to trigger mapping to the correct Hydra class.
2. Links: objects are not retrieved recursively, so only the metadata included directly in the record is included in the object's datastream. Links between classes are modeling using Hydra belongs_to/has_many relationships, and present in RELS-EXT.

The Document approach is implemented in our develop branch:

https://github.com/ucsdlib/damspas/blob/develop/app/models/dams_object.rb

This implementation has custom to_solr methods indexing all the metadata we want to use for retrieval and display, and working CRUD forms for the simpler classes. The main work left to do is implementing CRUD operations for the more complex classes (e.g., DamsObject and MadsComplexSubject), including discovery of external records to link to.

There is a proof-of-concept implementation of the Links approach in the feature/links branch:

https://github.com/ucsdlib/damspas/blob/feature/links/app/models/x_vocabulary_entry.rb

The XVocabularyEntry and XVocabulary classes link to each other with Hydra belongs_to/has_many relationships, but we still have custom code in the model and controller to get related objects loaded correctly. Relationships are presented in RELS-EXT, but the relationships are still mapped as properties in the datastream classes, and updates are done using the single metadata datastream rather than updates to RELS-EXT itself.

---

We have made steady progress on the Document approach, and feel like we will be able to successfully model our metadata this way, and finish implement single-item editing. But we have concerns about whether this is failing to take full advantage of the Hydra relationships functionality (and creating a maintenance burden for ourselves). We are also concerned that this approach may make it harder for us to use other Hydra code, such as the Batch Edit gem.