We are doing requirements development a website type that blends concepts from a “digital collection” / “digital exhibit” and a “finding aid” … so imagine a scenario where you land on an expressive exhibit type home page but can (via menu selection) move to a traditional finding aid view of the collection. As part of that we are exploring whether these requirements are a theme, a module, or something else (custom resource blocks, extensions to existing themes and modules).
We have installed the hierarchy module and can see where some of our requirements can be met with extensions to Hierarchy/view/hierarchy/site/index/hierarchy.phtml.
Other requirements, however, seem to be similar to what is available via “resource page” configuration options. So, for example, themes allow one to configure what appears on Item, Item Set and Media pages but not to add another “resource” type … which makes some sense as those fundamental concepts are the “resources”. However, some of our requirements seem to indicate a 4th type of page, called Finding Aid (so that we could configure this more easily than recreating the look and feel for each collection). Once configured, this Finding Aid page would show up as a Navigation option. Key to the functionality of this finding aid would be the display (with metadata) of a single Item Set (the top of the Finding Aid hierarchy).
Related questions:
(1) We assume the list of Item, Item Set and Media is considered definitive and one cannot add another “configurable resource page” likewise assessable from the theme settings. Is that correct?
(2) That seems to indicate a module. This module would define the resource block for “Item set with metadata” and create a “reusable and configurable” page that had a similar user experience as the configurable resource pages.
(3) Our users are also happy to see the Hierarchy module and like what it does but are 100 percent adamant about having the hierarch display be collapsable and expandable … a non-negotiable requirement. Would the appropriate way to do this be to include this as a feature of the module suggested in #2 or as a separate module that is a customization of the Omeka-S Hierarchy module?
(4) We might be able avoid some of this if a resource block for “Item Set with metadata” but that appears to not exist, which makes me suspicious that this is a bad idea.
What would you be looking for an “item set with metadata” block to do? Just what the item one does, but for a set? There’s no special reason there isn’t one in the core currently, only that for many users the sets are of more secondary importance. So I wouldn’t say there’s any reason to think it’s a bad idea to have one.
Hi John - basically, yes, just like Item with metadata. But I’ll provide more context.
The way the Hierarchy model works makes sense to us - a node in the hierarchy is (sometimes) an Item Set. In the context of archival description, a fond or series or file is a thing in and of itself (with metadata) and also only exists because it is an “item set”.
So, our plan is to have the metadata — not just the Items list - display when you click on a node that is and Item Set. Basically to one side (left or right) you have the hierarchy and as you click on nodes the corresponding metadata displays.
I think you want our hierarchies to link directly to the item set view pages (where you can view all the item set metadata) instead of to the “Hierarchy” pages, which display all the items currently found according to the grouping criteria. Basically the way Collection Tree in Classic works - discard the “grouping” concept, always have each hierarchy entry equal to one item set.
That seems like a fair feature request. You can make that request here:
Or if you don’t have a github account, let me know I can do so on your behalf.
I’m not clear on what you want from a “Finding Aid” resource that would be different from an item set. An item set is just a group - it can contain nothing, or via the Hierarchy module it can “contain” other groups. Any metadata you need to assign can be done to an item set as well as an item. You can also use items as Finding Aids, because they’re just nodes of information. Have you looked into our system of linking resources? https://omeka.org/s/docs/user-manual/content/items/#omeka-resource
I wonder if you want “resource pages” that are just set up different based on the resource’s class or template. Which resource blocks were you specifically hoping to include or hide on a “Finding aid” object type, that would be different from items or item sets?
As to adding collapsing and expanding functions to the Hierarchy module, you can add that feature request here also:
Thanks for the response. I can make those feature requests.
Yes, I am familiar with linking resources. The general idea behind the Finding Aid “resource” page is that it easier to layout than a regular page but offers more choices than what I understand to be offered on the Item Set page.
Related to that, I can see how one way to accomplish part of what we want for the Finding Aid is to have the (non-Item) nodes in the Hierarchy link to Item Set Page instead of the list of children Items. But it would be nice to have some choices there (what Item Set Metadata to show, whether to present the list of children Items or just have a link, what resource blocks to include [perhaps this last is just a theme customization], how that changes when the node is an Item versus an Item Set). But I like the idea of starting out with keeping it simple, so your suggestion makes sense.
I have the same issue. If you use Hierarchy module to display archival collection, you will have important metadata at each level of the Hierarchy and each level will be one item-set.
Fonds
- sub-fonds
- serie
- sub-serie
- folder/file
So we need a way to display this archival metadata for each level/item-set.
In the way the module currently works, it does not display metadata of item-set level but allows to browse items where there are located in the hierarchy (which is also nice).
It seems to me there are two options discussed below:
Allow Hierarchy module to link to the item-set pages instead of the https://xxx.com/s/site/hierarchy/## pages. Hierachies are displayed on the item-set pages so we are not completely leaving the hierarchy. If this solution is chosen it would be nice to have it as an option (because the other view is also something users can want).
Modify the view provided by Hierarchy module (https://xxx.com/s/site/hierarchy/## pages) to include metadata from the current item set. I think this is what nxm had in mind when speaking of a “Finding Aid resource page” or "resource block for “Item Set with metadata”. I am not sure this is the way because there is already an item-set configuration page on the theme settings (/theme-resource-pages#section-item_sets) and it would be difficult maybe to distinguish item-set used in hierarchies from other item-set.
The simplest solution seems to me to do 1 as everything is already in place to customize item-set pages in theme settings.
Just to add that we have prototyped a change to the “hierarchy view” (right side of page when displaying a hierarchy) to show both the item set metadata (the node in the hierarchy currently selected) and the list of children in that node . We will make this configurable in the Theme Settings. We are getting feedback from archivists on that now.
