Allow Relationship Validation / Enforcement of behavior rules

[flyingzumwalt]

ie. Hydra::PCDM::Object can NOT aggregate Hydra::PCDM::Collection

[jcoyne]

Does this ticket belongs in the PCDM level or need to be rephrased? What does success look like if we exclude PCDM terms?

[flyingzumwalt]

This ticket will be satisfied when it's possible for downstream code to enforce validation of relationship/aggregation behavior rules like those described in samvera/hydra-pcdm/issues/23

If we are able to rely on regular Rails validations and we don't need this gem to provide any special methods that are specific to aggregations, then you can close this ticket.

[jcoyne]

Well, that is rephrased. I guess I was looking for something a little more concrete. Are you saying:

Given: There is a class_name parameter (implicit or explicit) to aggregates.

1. Raise an error when attempting to append a member to the aggregation that is not the same as or a subclass of the specified class
2. Raise an error when attempting to assign the collection itself if one of the members is not of the specified class
3. Raise an error when attempting to append the id of a member to the aggregation if the object for that id is not the same as or a subclass of the specified object
4. Raise an error when attempting to assign an array of ids if one of the members is not of the specified class
5. What should we do if the data is present in the repository that does not conform to this validation?

[flyingzumwalt]

@awead is handling samvera/hydra-pcdm/issues/23. I'll leave it to him to decide what he needs. Adam, do you want to weigh in? Or do you want to postpone work on this until you've made some progress on the hydra-pcdm ticket?

@elrayle These tickets came from your comments in the original pcdm code. Do you have any thoughts on how this should work?

[awead]

@flyingzumwalt I think a lot depends on how hydra-pcdm (HP) is going to validate versus how AF would validate. I'm still trying to figure what's the best way for HP to validate. You do a simple is_kind_of? Hydra::PCDM::Collection but it seems like you should go deeper than that.

Given @jcoyne's points above, 1-4 should be successfully avoided if HP does it's own validation up front. #5, on the other hand, I'm not sure. I think AF now has the ability to reject instantiating classes that aren't the defined type, so it you tried to load a Collections class that wasn't Hydra::PCDM::Collection, that would fail outright.

[flyingzumwalt]

Sounds like we should close this ticket on activefedora-aggregations and you can submit a new ticket if you find that you actually do need something changed/added at this level. @awead do you agree?

[awead]

@flyingzumwalt @jcoyne looking into it deeper, it would be nice if AF could validate reflections, unless I'm not doing it right. For example, if I write a custom validation as you would with ActiveRecord, by the time I get to validate the attribute, it's a ActiveFedora::Aggregation::Association and I can't get to what the initial objects were that were being asserted in the relationship.

It may be out of scope for now. I can override methods in HP to ensure that the objects being added to the aggregates method are correct. See samvera/hydra-pcdm#39

[flyingzumwalt]

@awead I'm going to close this ticket because it's vague. If you decide that it's important for AF to validate reflections, make a new ticket for it so the purpose will be clear.