Missing volume_sorting?

Asked by Siegfried Schweizer

Multivolume works always have only one volume. It turns out that the reason for this is that the field volume_sorting always is 0 (zero) which leads to overriding all volumes but the last one in tx_dlf_collection::showSingleCollection(), lines 361-367 (v1.2b1).

I can't figure out where this field should get any values bigger than zero from. Is this a configuration isssue, is it concerned to malformed METS data or could it be a bug?

Question information

Language:
English Edit question
Status:
Answered
For:
Goobi.Presentation Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Sebastian Meyer (sebastian-meyer) said :
#1

There should be a metadata element named "volume". This is part of the default configuration. For this element (just like for any element) you can define xpath statements.

For us, these are set as followed:

XPath: ./mods:part/mods:detail/mods:number
XPath (Sorting): ./mods:part[@type="host"]/@order

Revision history for this message
Siegfried Schweizer (siegfried-schweizer) said :
#2

OK, if that metadata element also is marked "Prepare for sorting?" and after subsequent reindexing all volumes seem to be in place finally, so thank you for pointing this out.

But where is that "default configuration"? It's quite impossible for anyone configuring DLF to figure this out if there's no real default, i.e. something being automatically set when installing the software.

Besides it isn't very logical that one should have a metadate called "volume" where one already most likely has a structure also called "volume" (which is DFG viewer compatible), and that this metadate is responsible for the particular issue we're talking about here.

Revision history for this message
Sebastian Meyer (sebastian-meyer) said :
#3

The default configuration isn't set automatically, because then it would overwrite your individual configuration each time you update the extension. At least this is how the TYPO3 updating mechanism works when providing static default data.
But there is a backend module you could have noticed, which allows you to import the default configuration into a sysfolder. When preparing for an update it is recommended to always import the default configuration into any sysfolder and compare it to your individual settings. If you want to look at the defaults without importing them into the database you can find them in /modules/newclient/structures.inc.php and /modules/newclient/metadata.inc.php.

The existence of a structure named "volume" and a metadate of the same name is no duplication, because it handles completely different things:
1. The metadata configuration always refers to the MODS section (or whatever bibliographic format you use) while the structure configuration refers to the METS structMap. So if you have a structure type and a bibliographic metadate of the same name, you have to configure both. (Thus this isn't a DLF issue but a METS/MODS annoyance.)
2. The structure element named "volume" means, that you have structures of type "volume" in your METS files. So the DLF only reflects what you have written in your files and therefore can't be blamed if there is a metadate of the same name. Theoretically you can name your volumes anyway you want to avoid this (but then you won't be compatible with the DFG viewer profile).
3. The metadate named "volume" refers to the name of a volume and its counting. This is an element of MODS which is used for identifying volumes (which often don't have bibliographic titles) and bringing them in the right order.

Sorting in list view always works by metadata, so if you want to sort the items by any property, you have to configure it as a metadate.

Can you help with this problem?

Provide an answer of your own, or ask Siegfried Schweizer for more information if necessary.

To post a message you must log in.