Repeatable group of fields


I started to look around Omeka-S and I like a lot the concept of resource templates and the possibility to link properties with other resources. Very nice!

I’m interested in creating groups of fields/properties that can be repeated. Not just that single property can have multiple values (text, URI, resource).

Mini example could be couple of properties: object_number_type, object_number_value and object_number_note. I would need to repeat those 3 properties multiple times as a group and fill the values for each group (some of the properties may be even present multiple times, like for single property)

  • object_number_type = xyz
  • object_number_value = 123
  • object_number_value = 456
  • object_number_note = note


  • object_number_type = abc
  • object_number_value = 123
  • object_number_note = note
  • object_number_note =

What would be best way to accomplish that in Omeka-S? Any help or advice is greatly appreciated, thanks!

version 1.0.0-beta4

I think you should define a dedicated item for each group.

Thank you for help! Do I understand correctly that I should open new tab, create 2 new dedicated items (group1, group2) and then go back to main item and link those dedicated items via some property (i.e. dcterms:identifier)?
But I wonder how to search for those dedicated items, without title they will be all Untitled, right? Or is there some trick to build display title based on resource class?

Also as I haven’t filled Omeka-S with real-life data yet, I wonder how will the dedicated items affect the listing and overview quality. I can imagine there will be 1 main item and then possibly several dozens of dedicated items that will describe the item (linked to item). Do you have some experience or tips how to handle this situation? Or is there still some other recommendation for those groups of fields?

What you describe is exactly how I proceed… with the same issues.

I give a dcterm:title to all sub-items to better manage them, and I add them to specific item sets to recognize them more easily.

If someone has a better idea, I am interested!

I see two possible improvement for manage this case:

  1. Allow to customize title (with a customizable o:title property, or choosing for each item what property will be display as title in Omeka)
  2. Create “sub-item” resource type, which would be automatically included in their parent items (in display page, edit page and while searching).

What do you think about these ideas?

Thanks @pols12!

I definitely agree with the need for customizable title, not only for the sake of this feature request, but simply because dc:title is not always useful. As for sub-items I would prefer to keep them coupled inside the item, rather than have them in new listing or as sub-items.

I have another valid example of group of properties, that cannot be easily solved with the current way of things. Let’s say I have an item with multiple inscriptions. Each inscription may be related to person (inscriber), it may have date, description, interpretation, position or more info. Another repeatable area is about item dimension (its parts). It may need properties like measured part, measurement unit, value, date of measurement… Same with material for example for knife with wooden handle. And there are plenty more group of properties and in most cases they’re not reusable for other items. What would be recommended way of filling this kind of info into Omeka S according to core developers?

I was thinking about adding inline tab inside Item form (similar to what Geo plugin does) and prepare the group of fields there with possibility to repeat them. I’m concerned about the number of tabs that this will create, but it’s OK. Also I haven’t look deeply into database structure so I’m not sure if I need standalone table(s) for this. Could this be the way to go?

This is certainly the option that works best within the current system. The Mapping plugin is basically an example of what you’re talking about: to relate the longitude and latitude together, it must make a Location “sub-item” essentially for each mapped point. Mapping is a slightly different case because it does this through linking (because it wants to also make the locations available by a direct query as well as from viewing an individual item), but a module could just use blank nodes instead for simplicity.