Collections concept in Omeka-S?

benbakelaar · September 20, 2018, 3:02pm

I could be missing something obvious, but in Omeka Classic admin there is “Collections” tab, so this is a core concept. Is “Item Sets” the equivalent in Omeka-S?

I’m skimming through the user manual now to see if I can find the answer.

I’m not interested in the concept of a collection as a visual presentation of a set of items, but rather collections as formal metadata to describe items.

Ultimately, the question is whether we build our collection metadata in Omeka Classic, and then can easily import it to Omeka-S, or if we should stop and just build the collection (folder/volume) structure in Omeka-S (in whatever way it supports).

mebrett · September 20, 2018, 4:28pm

Item Sets are roughly analogous to Collections in that they are both ways of grouping items. However, unlike Collections, an item can belong to multiple Item Sets.

If your end objective is to build sites using Omeka S, then it would make more sense to create the Item Sets with the metadata properties you want to use to describe the overall group of items.

Is there something specific you are accustomed to doing with Collections that you are trying to do with Item Sets?

benbakelaar · September 20, 2018, 5:17pm

Thank you for confirming! That was the initial conclusion I reached after reading some more.

And regarding Collection Tree plugin, I can simply use Item Sets to replace hierarchies in which multiple collections are grouped?

In other words, “one item, one collection” = metadata property. I can make this an item set if I need to display it separately, but whether I need that or not, I can also use Item Set to group collections (in our archival case, folders and volumes) together into hierarchical relationships. Is that true?

mebrett · September 20, 2018, 10:37pm

There’s not an equivalent module to Collection Tree for S, but because S supports using existing resources as properties, you could use the Dublin Core properties “Has Part” and “Is Part Of” to create a relationship between Item Sets.

benbakelaar · September 26, 2018, 4:06pm

OK, as a test I’ve used “Is Part Of” to set the volume title for 100 records in a test site using Omeka-S.
http://taedomekas.reclaim.hosting/digital/s/taed/item/67

I am using References module (of course) and am trying to implement hierarchy via the “Is Part Of” property.

We have a collection tree defined in a development Omeka Classic site.
https://drive.google.com/file/d/1ECfn-Z7GsksJ7fcNaVVzEhCV3uPm6SjP/view?usp=sharing

So as far as I can tell, what should happen is that I create a static copy (“an expandable hierarchical tree of statically specified references” referenced here https://github.com/Daniel-KM/Omeka-S-module-Reference) of the hierarchy, and paste it into the Reference module configuration. I’ve done that, with the appropriate conversion to the dashed syntax that the module requires. So I get the tree display:
http://taedomekas.reclaim.hosting/digital/s/taed/reference-tree

So far, so good. But then, and I’m hoping @Daniel-KM can chime in, the reference tree list is simply plain text. I was expecting each item to be a hyperlinked query? In this way, the “collection hierarchy” for this document set (Thomas A. Edison Papers) can be browsed hierarchically, even though any metadata changes would have to manually be incorporated in a new statically defined list for the References plugin.

^^ so that’s problem #1. Megan, do you think there is more utility / functionality in implementing these as Item Sets?

Now for the next question… the above solution still doesn’t include hierarchy “in the metadata” of each item itself. I can include the lowest-level (most specific) sub-collection that an item is part of, as with the first link, but the metadata record would only display that particular value, and not the “parent” super-collections (within the hierarchy context). Is there a built-in way to achieve this? Can I achieve this via multiple values in a single metadata field, e.g. “Is Part Of”? Since we have an arbitrary # of parent super-collections (see the reference tree display), I can’t spread it out to a specific number of metadata fields like “Has Part”, etc. - at least not at the item (document) level. Can Item Sets help with this?

I’m a bit out of my element since I’m not a master of all this terminology and archival context… even after 2 years at Edison Papers So I may be wording or communicating my questions poorly, please let me know if any clarification is needed.

mebrett · September 26, 2018, 6:05pm

Hi Ben,

I have not used Daniel’s reference module, so I can’t speak to that.

I think in general, it makes sense to translate collections to item sets. There are exceptions when the thing that is the collection actually makes more sense as an item and was only ever a collection because of hierarchical/organizational needs.

You could have more than one “is part of” inputs for an item, but yes you could also go with multiple item sets.

The best bet is to experiment with a handful of item sets that you have (5-7) and try creating them as items and as item sets and see which makes more sense for your workflow and needs.

benbakelaar · September 27, 2018, 1:52pm

“There are exceptions when the thing that is the collection actually makes more sense as an item and was only ever a collection because of hierarchical/organizational needs.” > great, I’ll talk to the editor about that

Next question - is there any way to create visual hierarchy (i.e. indentation) based on parent-child relationship of item sets (i.e. item set #1 contains item set #2 and #3, but not item set #4)? I have to do some more research on linked data, but I think “grouping” is not the main point of linked data as opposed to linking an individual item to additional items. This visual hierarchy is what Collection Tree plugin creates in Omeka Classic, and what the Reference plugin allows (statically) in Omeka C/Omeka-S. Not so important for casual end users, which I understand is what Omeka is targeted towards “out of the box” or with “core” functionality. But it is important for editors and scholars, librarians, advanced users, and others who are the more significant stakeholders in digital library/DH projects involving implementation of Omeka.

benbakelaar · September 27, 2018, 6:12pm

OK let me try rephrasing and simplifying.

But first, do item sets have their own built-in metadata display page?
http://taedomekas.reclaim.hosting/digital/s/taed/item-set/192

Seems to just be a search/filter.
http://taedomekas.reclaim.hosting/digital/s/taed/item-set/193

Now, as I’ve been experimenting today, it seems the root question is, is there any possible mechanism for “transitive” relationship, such that item-set 192 is a “linked resource” (via Omeka resource ID) within item-set 193 (item-set 192 > is part of > omeka resource id 193) - and so, within various displays of item metadata (http://taedomekas.reclaim.hosting/digital/s/taed/item/67) and searches (http://taedomekas.reclaim.hosting/digital/s/taed/item-set/193) all items in set 192 also appear in set 193?

I don’t know if that simplified my question… lol. But I’m guessing that’s what the Collection Tree accomplished in Omeka Classic?

… edit >

Via manual entry, batch action bulk edits, etc. I accomplished what I’m trying to describe. At this point I’m guessing this is the only way to do it.

Item Set A:
Foundation of the Postal and Telecommunication Museum Collection
1–25 of 67 results
http://taedomekas.reclaim.hosting/digital/s/taed/item-set/192

Item Set B:
Archives Nationales
1–25 of 75 results
http://taedomekas.reclaim.hosting/digital/s/taed/item-set/193

Logical hierarchy (completely made up, real data but fake relationship):
Archives Nationales
… Foundation of the Postal and Telecommunication Museum Collection

To accomplish the goal of showing all of items in set A when browsing set B:
http://taedomekas.reclaim.hosting/digital/s/taed/item-set/193

Create set A and manually add all items
Create set B and manually add all of set A
Manually add all additional items that are part of set B but not set A

To accomplish the goal of the UI showing the relationship:
… would need a plugin that is looking at a specific metadata property, for instance “Is Part Of”, and then displaying that in the left area (faceted search / filter area).

To accomplish the goal of the item showing the relationship:
http://taedomekas.reclaim.hosting/digital/s/taed/item/67

Is Part Of

Foundation of the Postal and Telecommunication Museum

text-only reference to lowest-level (most specific) group
1 possibility

Is Referenced By

Foundation of the Postal and Telecommunication Museum Collection

Archives Nationales

Manually assigned linked data (omeka resource ID) - has the benefit of being able to be imported as data, if the item set already exists and the ID is known prior to import.

Item sets

Foundation of the Postal and Telecommunication Museum Collection

Archives Nationales

But Omeka-S automatically can display the item sets anyway, so the prior metadata representation is essentially just a repeat of the item set display anyway

Seems to be the best solution, but… none of them show the relationship/hierarchy unless I were to control item set addition order, or more easily in the case above, control value order for the metadata property that contains the Omeka resource ID

After writing it out and sort of thinking out loud, that might be the best, because then the theme could simply be programmed to show that metadata value as a series of indentations…

So, new question - does this make any sense? Am I taking crazy pills? Am I going about this in the completely wrong way, or a ridiculously obtuse way?

Seem to have proven it can be done manually with lots of human calculation. Seem to have also recognized that this is not provided programmatically in any existing Omeka-S plugin or in core.

mebrett · September 27, 2018, 7:11pm

As a note, the site you’re linking to is set private.

There are no doubt a number of solutions, including the one you have crafted. The question is which works for you. There is also the potential to work to create a module for Omeka S which will help facilitate what you’re trying to achieve - the developer documentation should help you get started.

benbakelaar · September 27, 2018, 7:13pm

Just made it public. Always forget that tiny little icon…

When you say a number of solutions, I guess that’s another version of what I’m asking - what are some other possibilities that I’m missing? Ideally, simpler ones?

mebrett · September 27, 2018, 7:57pm

When I said there were likely a number of solutions it was speculative. I have not tried to create that kind of system in Omeka S, and S is new enough that there aren’t many working examples yet to draw from. As I said above, the best way to figure out what works for your project is experimentation.

Best of luck!

jflatnes · September 27, 2018, 8:19pm

To clarify one point: item sets in S are basically designed to be displayed as a search or “browse” result, as you’ve seen, but to also display their own metadata alongside. Your theme doesn’t seem to be displaying that metadata, but it’s typically an “are we showing an item set” conditional section in the item browse view.

I never dealt much with the older Collection Tree module, but my recollection is that it basically just gave you the hierarchical view of the collections, but each collection would only show the items directly in them, in other words a collection could show what collections were its “children” but when viewing the items in the parent collection you wouldn’t see items that are in the children. Is that what you’re looking for? I don’t think it quite is if I’ve understood your messages properly.

benbakelaar · September 27, 2018, 8:38pm

Thank you Megan and John for all your assistance! I do hope to get feedback from others in the community who are working on this use case.

John to your question, I believe you are correct in your analysis However, I don’t know exactly what I want as far as the UX goes, at this point just experimenting and finding out possibilities. (Edit: but in thinking about Amazon-style filtering and faceted search, people expect “narrowing” and “expanding” to work in the way I describe. If I am on amazon.com, I see all products - in theory, not really. Then I choose a category, now I see 80% of the products. Then I choose a sub-category, now I see 50% of the 80%. Then I filter based on metadata, now I see 10% of the 80%. That’s the UX I’m talking about).

So far we’ve only used Collection Tree to “model” the new hierarchy for the Omeka-based TAEP digital edition - and that’s the root of my post here. I’m exploring whether to continue implementing Collection Tree in Omeka Classic, with all the required effort in that - or to pause since it is likely non-transferable to Omeka-S, and instead just use the model we’ve built so far as a guide for implementing in Omeka-S - since we want to upgrade “sooner than later” anyway. And even more specifically, the question is do I implement collections in Omeka Classic this fall, then upgrade to Omeka-S in spring… or do I upgrade to Omeka-S now in the fall given my testing results in an acceptable UX of collection hierarchy along with an acceptable amount of associated effort (i.e. not too much).

JohnM · March 16, 2020, 4:26am

Hi everyone. Any movement on this? I’ve got a researcher who, as is natural, has organized his archival photos into a hierarchical folder structure.

How do I make an item set a member of another item set?

JohnM · March 16, 2020, 8:17pm

Here’s the workaround I’ve settled on for now:

import the CWRC vocabulary
http://sparql.cwrc.ca/ontology/cwrc.html
(I considered using Agrelon, but theirs is very explicitly tailored for biological and social genealogies, so from what I can tell they keep tweaking their taxonomy. If I remember correctly, “child” became “biological child,” etc.)
apply CWRC parent of/child of properties to item sets, thereby allowing hierarchical relations.

It really is a little odd that dc has “relation” but no hierarchical relation. And that we have the hierarchical concept of a “set” without the possibility of a sub-set? What’s the reasoning there?

Or is the assumption that we should be using highly specific bibliographical data to mirror archival organizational schemata like collection:box:folder:item:page

Daniel_KM · March 18, 2020, 4:51pm

You have to create item set for each level, and each of them can be related as an Omeka resource to the parent one and to the children via dcterms:isPartOf/hasPart. Then you can display the tree in the theme.

JohnM · March 18, 2020, 5:19pm

I like it. Currently porting over the last of the images, but I’ll restructure the relations from the CWRC vocab into this vocab and see how it works. Thanks!

JohnM · March 18, 2020, 8:21pm

That’s fantastic, I don’t need the extra vocabulary now.

Much appreciated. Using a dictionary of parent:child relations in each node, I quickly created the hierarchy of item sets this way:

for node_id in nodes.keys():
	
	parent_id = nodes[node_id]['parent_id']
	
	children_ids = nodes[node_id]['children_ids']
	
	params['id']=node_id

	node_data = json.loads(requests.get(url,params=params).text)

	if parent_id!=None:

		node_data["dcterms:isPartOf"]= [
				{
					"o:id":node_id,
					"type":"resource",
					"property_id":33,
					"property_label":"child of",
					"value_resource_name":"item_sets",
					"value_resource_id":parent_id,
				}
			]

	if len(children_ids)>0:
		node_data["dcterms:hasPart"] = []
		for child_id in children_ids:

			node_data["dcterms:hasPart"].append(
					{
						"o:id":node_id,
						"type":"resource",
						"property_id":34,
						"property_label":"parent of",
						"value_resource_name":"item_sets",
						"value_resource_id":child_id,
					}
				)

	response = requests.patch(url, params=params, data=json.dumps(node_data), headers=headers)
	print node_id,nodes[node_id],response

JohnM · March 20, 2020, 9:36pm

And that, with jstree and a little api finagling, allowed me to make the following interactive navigation. Not as fancy as Daniel_KM’s, but a good proof of concept I think.