hyrax: work.is_part_of metadata attribute usage in forms conflicts with AdminSet behavior

@elrayle @mark-dce @no-reply @jlhardes cc: @vantuyls Good points, all.

I’m hesitant to change the default this late in the release process of 2.0.0. Could we address this via documentation in the meantime, letting folks know of collection extension changes that are coming and recommending usage of the community-preferred predicate (from @mark-dce’s 2. above)? If so… we need to figure out what the community-preferred predicate is, i.e., have a process for getting this done and a volunteer for taking the lead.

@mjgiarlo - The DCE team would like to make a counter-proposal that might allow us to approach the issue in a more incremental and flexible way:

PHASE ONE As part of the Hyrax 2.0.0 release

1. Make the predicate used to associate Works to AdminSets an easily configurable option
2. Set the default for the predicate to match the current implementation in Hyrax 1.x (i.e. ::RDF::Vocab::DC.isPartOf)

This is sufficient to meet the needs of the Greenfield 2.x adopters who wish to use DC.isPartOf as part of their own modeling, and use a different predicate for AdminSet relationships. At the same time, it does not interfere with users migrating production implementations from Hyrax 1.x based repositories.

PHASE TWO At a later date in the 2.x release stream 3. Select a more narrowly defined predicate, perhaps something as specific as ::RDF::Vocab::Samvera.belongsToAdminSet 4. Provide a deprecation notice that the usage will be changed in 3.x 5. Provide migration tooling as described in Mike’s comment above

This allows folks with existing 1.x based implementation to plan a scheduled data (predicate) migration independently of updating their application to use the 2.x codebase. The sooner we can do steps 3 and 4 the better, but the wouldn’t have to be in place at the 2.0.0 release. The hardest part here might be reaching consensus on the new predicate.

PHASE THREE As part of the 3.0.0 release 6. Change the default for the predicate used internally to indicate AdminSet membership to something other than DC.isPartOf

If folks want to carry forward the use of DC.isPartOf from their 1.x or 2.x implementation, they’re free to keep the default configuration they’ve been using. Greenfield deployers of 3.0.0 get a more narrowly defined predicate for the AdminSet relationship when the application is initially generated.

=========== DCE can definitely signs up for PHASE ONE. We can probably help on a significant portion of PHASE TWO. After that, PHASE THREE feels almost trivial (other than remembering to do it).

I like @mark-dce’s breakdown and phased implementation. It makes sense to narrow the administrative scope of this predicate

@mjgiarlo yes, folks obviously could use a different predicate; however, none that we are aware of, stand out as obvious or clear candiates. Hence this ticket.

We’ve discussed alternatives internally to DCE and have not come up with useful alternatives - partially because the specific current use case also implements dc.has_part, dc.has_format, dc.is_format_of, dc.replaces, and dc.is_replaced_by. In this broader context, using a non-dc predicate for is_part_of (because of the collision with internal Admin Set use) breaks a clear pattern present with other descriptive metadata - i.e. there’s a clear parallelism when describing things using dc.is_part_of / dc.has_part that is broken when you use other_vocab.is_subunit_of / dc.has_part.

I guess my questions would be “How much are AdminSets meant to be externally referenced or to support behavior outside the repository?” and “Are there characteristics of the AdminSet relationship that would be more clearly represented by a narrower or application specific predicate?”

If the AdminSet relations are meant to be first class relationships that are actionable outside of Samvera, then dc.is_part_of probably does make sense. If AdminSets really aren’t meaningful outside the context of Samvera and it’s workflows, then I’d lobby to free up the current predicate and choose something more narrowly defined.