What's the definition of toplevel:true? It's a feature or a bug in collection plugin to show all issues twice?

[albig]

There are toplevel structures and non-toplevel structures. Up to a certain point, that's comprehensible. Of course an article or a chapter is not a toplevel structure. But I'm a little confused in some details.

In newspapers, the Kitodo.Presentation comes with the defaults:

• type:newspaper --> toplevel:true
• type:year --> toplevel:false
• type:month --> toplevel: false
• type:issue --> toplevel:true

Newspaper, year and issue are indexed as Kitodo.presentation documents in tx_dlf_documents. In case of type:year, you cannot edit the structure in the backend because year is not toplevel. So we changed the configuration and set year to toplevel.

Question 1

Shouldn't be type:year a toplevel document? Same as type:newspaper and type:issue?

In the collection plugin in showSingleCollection() we are looking for all documents with toplevel:true. That's why we find all newspaper issues and show them as "Toplevel" entries. The newspaper itself is shown, too with all years below. This behaviour is confusing and we modified the collection by the field "index_search" to exclude issues and year. This can be done e.g. with !type:(year OR issue) toplevel:true.

Question 2

Is this the expected behaviour of the collection plugin? Shouldn't it show the (real) toplevel element (type:newspaper) with the years below?

Looking forward to some explanation :-)

[sebastian-meyer]

Originally toplevel was meant as an indicator for aggregation: When showing collections, all non-toplevel documents should be grouped under their respective toplevel document (e.g. volumes are grouped together under their respective multi-volume work and issues are grouped together under their respective periodical).

But keep in mind that there are other forms of lists, like fulltext search results. In those cases, we want all hits within a document grouped under the respective document without worrying about the toplevel status.

So effectively there were two modi operandi for ListView:

• When showing a collection, only real documents (i.e. those represented by records in tx_dlf_documents) should be shown, whereby all non-toplevel documents are grouped under their respective toplevel parent. This worked fine as long as we had only two levels of hierarchy.
• When showing search results, we have to deal with sub-structures (i.e. chapters, pages, etc.) as well, so all results are grouped under their respective real document (i.e. the record in tx_dlf_documents) - completely disregarding any toplevel status. This effectively means, that content-less parent structures like newspapers, multi-volume works, etc. are never shown in search results (but only their content-bearing descendants like issues, volumes, etc.). This worked fine for fulltext searches, because those produce no hits for parent documents of hierarchical entities. But it was inconsistent when performing metadata searches, because those can produce hits for parent documents, their children and sub-structures of those children as well (fortunately his was a rare edge case, so we didn't bother).

Now newspapers have even more levels of hierarchy (newspaper, year, issue and sub-structures like articles) and those aren't rare edge cases any more. If only the newspaper was toplevel, collection lists would show years grouped under their respective newspapers, but there would be no issues shown. So I declared issues as toplevel as well in order to show them in collection lists, but now they are no longer grouped together. (And when searching, things get even more complicated...)

I think, we have to completely rethink how we want to do grouping and aggregating in a consistent and yet configurable way.