On containers - mlibrary/hydra-prototype GitHub Wiki

Hydra::PCDM::PcdmBehavior defines members with

      aggregates :members, predicate: Vocab::PCDMTerms.hasMember,
                           class_name: 'ActiveFedora::Base',
                           type_validator: type_validator

To create your own container:

class Bag < ActiveFedora::Base
  include Hydra::Works::CollectionBehavior

  aggregates :works, predicate: App1::Vocab::APP1Terms.hasWork,
                       class_name: 'ActiveFedora::Base',
                       type_validator: type_validator

  property :title, predicate: ::RDF::DC.title, multiple: false
end

You can create a container that re-uses hasMember: items added to bag.generic_works and bag.works will appear in their own separate containers. But bag.ordered_works will return anything connected with hasMember (bug? feature?)

This doesn't quite align with the End Goal - Final State diagram, where <raven> pcdm:hasMember <cover>, and this relationship is managed by a ldp:DirectContainer. (Maybe you just re-define the members aggregation for Books?)

aggregate comes from ActiveFedora::Aggregation, which pulls in ActiveFedora::Associations::IndirectlyContainsAssociation, which is what actually sets up the ldp:IndirectContainer.

Finally, Hydra::PCDM::ObjectBehavior does define the relationship with attached files as a direct container:

      directly_contains :files, has_member_relation: Vocab::PCDMTerms.hasFile,
                                class_name: 'Hydra::PCDM::File'

Later.

Direct containers require additional support in the model --- out of the box only Hydra::PCDM::File supports this, as it inherits from ActiveFedora::File which has the machinery for creating objects relative to a parent object.

Having added the necessary code, turns out that direct containers don't automatically create the order proxies, and ordered_:property does not work.

https://github.com/elrayle/hydra-works-demo/wiki