What definition of Set/List/Collection is in scope?

[azaroth42]

From #9 and #17 and to clarify #8 ... which notions of collections (either unordered sets, or ordered lists) are in scope for discussion and which aren't?

[jcoyne]

I'd like to move the model currently in hydra-collections into this. This is an un-ordered list and each Works/DigitalObjects can belong to many of these Collections simultaneously.

[awead]

👍 I assumed hydra-collections was a part of this. So let's make that explicit.

[jcoyne]

I'm avoiding using "Set" because set implies that a membership is unique.

[azaroth42]

What's the use case for membership not being unique?

Use cases for order:

• Series of works (eg journal issue 1, then issue 2)
• Series of components (eg page 1, then page 2)
• Non-administrative lists of all types (reading list, gallery, exhibition etc, per Use Case: Collections, Admin Sets, Display Sets #17 )

[jcoyne]

@azaroth42 Hmm, Yeah, I can't thing of any time a collection (in the hydra-collection sense) could have non-unique members. I do have cases of ordered lists, where members arise more than once (tufts image library & Northwestern image library), but I think that ought to be out of scope.

[jeremyf]

EDITED: As this is not a specific use case, but appears to be a discussion about scope, I'll throw in my two cents. This is more of a synthesis conversation.

👎 I want to avoid bringing Collections, Sets, and other aggregations of the Work concept into Hyrda::Works.

From the implementation stand point, we can think about how a Collection might interact with a work.

class CollectionManager
  def initialize(collection)
    @collection = collection
  end

  def <<(collectible)
    @collection.add_member(coerce_to_collectible(collectible))
  end
end

A Hydra::Work would be coercible into something that is collectible.

[barmintor]

We have structured aggregations in our repo right now, so an outcome here that didn't accommodate ordering somehow would lie fallow in the source repositories of Columbia. I'm very sympathetic to excluding Sets, though.

[mjgiarlo]

I find myself agreeing with @jeremyf that we may want to leave collections, lists, and sets out of scope at the moment while we firm up Works. This is a related, and similarly interesting and needed, conversation but I'm thinking it'd behoove us to punt on this for now except to say: you are free to make relationships between Works and other containers (like collections, APOs, display sets, etc.).

[azaroth42]

I'm easy either way, but agree with @jpstroop that once you have Components underneath Works with the potential for order, you have 99% of the Collections requirements already done.

[barmintor]

Sure. I only want to lay out the propostion that, if these practices map to
persisted object assertions, saying "you are free to do collections" means
that Hydra:Works does not meet the MVP criterion for adoption in our (and,
I would venture, most any large) repo.

On Fri, Oct 10, 2014 at 2:06 PM, Michael J. Giarlo <notifications@github.com

wrote:

I find myself agreeing with @jeremyf https://github.com/jeremyf that we
may want to leave collections, lists, and sets out of scope at the moment
while we firm up Works. This is a related, and similarly interesting and
needed, conversation but I'm thinking it'd behoove us to punt on this for
now except to say: you are free to make relationships between Works and
other containers (like collections, APOs, display sets, etc.).

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[mjgiarlo]

@barmintor I didn't mean to suggest Hydra::Works should pretend that higher-level abstractions don't exist, but rather that perhaps we shouldn't make decisions about these abstractions now while we're still firming up the nature of Works proper.

We'll need to take up this issue soon, and figure out what the connections are between Hydra::Works and Hydra::Collections, or if these boundaries still make sense, and how much of this goes in, e.g., Sufia or Worthwhile or Curate.

Suffice to say: there are many concurrent active discussions and lots of moving parts here, but I think there is a common interest in figuring out a model that will work for all of us.

Yes, even Columbia. ;) @barmintor++