Only one sub structure in list view?

That's a tricky question unless you provide a little more information. :o)

Obviously this does work in Hamburg and Dresden, so it seems to be a misconfiguration, but to be sure I have to take a look at it.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Sorry, but I'm not quite sure that it really works like expected, at least not in Dresden.

Consider the following: If searching for "Dresden" in http://digital.slub-dresden.de/, you will see that at the very first pages of the hit list there are many monographs, volumes and manuscripts that have the "Show details" button on bottom, and certain sub elements (chapters, illustrations, contained works ...) to these works are being shown when clicking it.

On the contrary, there are also multivolume works (and also many other monographs etc.) in the hit list that do _not_ have sub structures, e.g. a multivolume work at page 179 called "Architectura curiosa nova, Das ist: Neue Ergötzliche Sinn- und Kunstreiche auch nützliche Bau- und Wasser-Kunst".

This doesn't seem to make sense. Are there any explanations for this behaviour?

That also leads me to the following question. As you know, when collecting structural/bibliographical metadata for volumes of multivolume works in Goobi.Production, always two METS files are being generated: One file that contains the complete metadata of the volume, and an "anchor file" which contains part of the information referring to the super element (common title).

When indexing with the "old" GDZ indexer, these anchor files are being merged into a single METS file so that the relation between common title and volume can be recognized in the presentation level (a feature that was originally broken in the GDZ presentation, by the way, and had to be fixed by me). Does this work the same way in Goobi.Presentation? Are there any known issues here?

Could it furthermore be the case that the original issue I posted here has got to do with the fact that for historical reasons our METS files still have some inconsistencies in themselves? For example we have got

./mets:div[@TYPE="monograph"]

as well as

./mets:div[@TYPE="Monograph"]

or

./mets:div[@TYPE="title_page"]

as well as

./mets:div[@TYPE="TitlePage"]

Why do you think there is something wrong with that? Technically everything works as expected: you are searching for "dresden" and get all structures which contain this string in any of their indexed metadata fields. Some of these structures are top-level structures (according to the configuration), while others aren't. Those which are sub-structures get aggregated under their respective top-level structure. That's how it is supposed to work and actually does.

Goobi.Presentation recognizes "anchor" files by their record identifier. So when indexing a volume of a multivolume work, Goobi.Presentation iterates through its structure and indexes every linked "mptr" reference. This way the "anchor" files get indexed, too. If there already is a document with the same record identifier as the "anchor" file's, the volume gets connected to this existing "anchor". This way all volumes of a multivolume work finally have the same parent document in Goobi.Presentation. (Actually this is a very generic thing when indexing documents and doesn't apply only when indexing multivolume works: in fact every single METS file is recognized by its record identifier and reindexing just updates the already existing DB entry if found.)

The inconsistencies in your METS files shouldn't be a problem as long as you configure all the variants in Goobi.Presentation. Just create separate entries for every variant of the structure elements.

I still don't really get it. Does this mean _only_ if a search term occurs in a volume too that then this volume, and only this one, will be shown in the "Show details" field, also if there are other volumes where this search term doesn't match?

And that the same "Show details" field will show all volumes when browsing a collection, e.g. "Technikgeschichte" --> "Tractat Der Mechanischen Instrumenten Levini Hulsii", and never show chapters, illustrations etc. then?

If it really works like this, then it's at least confusing - not only for me, but surely also for the user. Please consider that you are using the very same page element for two completely different purposes, depending on which approach the user takes to access your presentation. Sorry, but I doubt that this is good UE.

However, again it's something that should have been pointed out earlier. A good documentation of Goobi.Presentation would most likely be very useful, if not essential, to subsequent libraries, developers and admins.

In principle there is no difference between a collection list and a (search) result list. Just think of the collection list as a search for a specific collection: the resulting list will show all structures which are part of this collection. The only difference is the grade of aggregation, but that's just because the sub-structures don't have the metadata "collection" and therefore can't be a result of a search for a collection.

For example: selecting the collection "Griechische Handschriften" from digital.slub-dresden.de gives you exactly the same result list as searching for "collection_tui:(Griechische Handschriften)".
(This differs a bit for multi-volume works, but only because the grade of aggregation is different when searching instead of directly selecting a collection - the results are still the same!)

I see. What you say is a strict technical view of the whole thing, and I agree that as such it is coherent. But believe me, this ain't what users expect (and what I expect), and so it definitely leads to confusion.

And besides in Hamburg it seems to work different. Browse "Hamburgensien: Darstellungen und Nachschlagewerke" under http://www.sub.uni-hamburg.de/recherche/digitalisierte-bestaende.html, and you'll notice that there _are_ multivolume works where volumes are being shown as "details".

So did they reprogram the whole feature?

That's exactly the same way it works in Dresden. When browsing a collection you get only top-level documents (i.e. monographs, volumes, manuscripts, multi-volume works) where the volumes are aggregated under their respective multi-volume parents. When searching for something else you get top-level documents as well as sub-structures (i.e. chapters, illustrations, title pages etc.) where the sub-structures are aggregated under their respective top-level documents.
So the only difference (not only technically) is the level of aggregation. And I think this is what a user expects: When browsing a collection he would expect getting only documents, but no chapters (because a chapter isn't part of a collection, but a document is) - which is the same way an OPAC handles collections. But when searching he would expect getting hits inside the documents, too - which is why the level of aggregation changes to reflect this.

Another (technical) reason for this is the way of sorting: while a collection list is typically sorted by the documents' title, a result list of a search request is sorted by relevance. If the search hits would get aggregated at the same level as the documents of a collection list, the sorting would take place on the level of multi-volume works, too (which obviously isn't appropriate when searching on sub-structure level).

--
Sebastian Meyer

Referatsleiter 2.1 - Digitale Bibliothek
Abteilung 2 - Informationstechnologie

Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden

Tel.: +49 351 4677 - 206
Fax.: +49 351 4677 - 711
http://www.slub-dresden.de/

I'm still not at all convinced that this is good usability or satisfactory user experience, but however, at least I'll now be able to explain this as default behaviour which I won't change.