What to do with islandora_collection?

[whikloj]

Now that we have moved to using context and resource handling is based on tags, etc.

Do we take islandora_collection out behind the woodshed and delete it?

[dannylamb]

We were young and naive back then.

🔥 🔥 🔥

[mjordan]

I can think of no better (or Dupalier) use for tags than to define "collections" of things, and Views for displaying them to the user OOTB. If we go this route, should we be defining a Collections taxonomy as per #888?

[dannylamb]

Collections vocabulary, yes. We'll also probably also want to make the distinction between being member of a collection (field_member_of_collection, which references a taxonomy term) vs. being a member of a compound/complex object (field_member_of, which references a node).

[mjordan]

Just thinking about the perpetual challenge of the non-recursive nature of collection membership in 7.x where pages/child objects/members of child collections have no direct lineage to the grandparents. I wonder if using taxonomies to define collection and child relationships can help us here, where only an expensive SPARQL query or special Solr indexing meets this need in 7.x. In other words, does Drupal's taxonomies API or a contrib module provide easy traversal up the tree?

[dannylamb]

My understanding is that if you select a broader (e.g. parent) term to use as a search filter, it will grab everything tagged with that term or any of its children. So we should have by default what we get from indexing ancestors in 7.x. Is that what you're looking for?

I'm vagrant uping at the moment, but I'll verify for sure once its up.

[mjordan]

Yes, that's what I'm talking about, the equivalent of the ancestor indexing in 7.x.

[whikloj]

I'm lost as to what you two are now discussing, you want to use tags for each Collection to be able to identify each item or part of an item that is part of a specific Collection?

[mjordan]

@whikloj my question is whether using taxonomies to define collection membership and compound relationships can help us avoid having to do anything special to determine, for example, if a page is a member of a collection where its book is the node that has the collection tag applied to it. I am wondering if we can avoid SPARQL queries or special indexing to determine whether that page is a "member" of its parent's collection.

[dannylamb]

@mjordan that's somewhat different than what I was describing. I guess for what you're saying you'd want to slap the collection term on both the book and its page.

[mjordan]

Right, we don't do it in 7.x, and I'm not advocating that we do it in CLAW, I'm just wondering if D8's taxonomies offer any built-in transitivity that we can take advantage of. If not, no problem, I'm just asking the question because in 7.x it's an extra step (either by SPARQL or querying Solr for <ancestor> elements) to determine if a page is part of a collection.

[mjordan]

Some possible use cases for wanting to know if a page/compound child is part of a collection:

• "everything in a collection" (even pages in books) is under some sort of access control
• you want to update metadata for "everything in a collection", even children of compounds
• I want to regenerate thumbnails for "everything in a collection"

[whikloj]

So we are conceivably going to be moving all of our structure to taxonomy terms, so those terms need to remain in the same order and must be persisted to Fedora.

[dannylamb]

That's a good point. I'm not sure how the hierarchical information for terms is stored in Drupal. We may need some custom code to get at that and put it in the RDF.

[whikloj]

I has killed islandora_collection.