METS div parser: generalize to cover more cases

[bertsky]

We currently rely on the assumption, that the mets:div content element contains an @ADMID (which is mandatory by METS DFG application profile, but optional in the ENMAP profile):

mets-mods2tei/mets_mods2tei/api/tei.py

Lines 828 to 837 in 47f5bc2

	# descend to the deepest AMD
	while div.get_ADMID() is None:
	self.logger.debug("Found logical outer div type %s: %s", div.get_TYPE(), div.get_ID())
	div = div.get_div()[0]
	start_div = div.get_div()[0]
	self.logger.debug("Found logical inner div type %s: %s", start_div.get_TYPE(), start_div.get_ID())
	while start_div.get_div() and start_div.get_div()[0].get_ADMID() is not None:
	self.logger.debug("Found logical inner div type %s: %s", start_div.get_TYPE(), start_div.get_ID())
	div = start_div
	start_div = start_div.get_div()[0]

Since this is fragile and inflexible, the parser should probably search for @TYPE and @ID (perhaps cross-checking with structlink) instead.

[t-mayer]

Hi @bertsky,
we also currently have the problem that ENMAP is not covered, so mm2tei does not work on those files. Do you know by any chance if there a workaround that can be used with mets files like these?

[bertsky]

@t-mayer I have been digging a little deeper, and found that ENMAP support would require a lot more besides flexible mets:div parsing (to identify the top content element encompassing all sections/paragraphs/...) in the mets:structMap:

• ENMAP allows different sub-element types than DFG Strukturdatenset, viz. (any recursive number of) content_section and (any recursive number of) content_unit above the other types (article, table etc);
  and there seem to be additional sub-element types below content_unit in use, too (e.g. caption, advertisement, body, body_content, heading, title...)
• the DFG profile requires fileGrps to be flat and named by @USE (in a predefined set of names), while ENMAP requires recursive fileGrps named by @ID in a certain way
• we currently only use the mets:structLink mechanism to map (ranges of) whole pages to divs, but ENMAP uses mets:area (with @COORDS, which would be hard to match with fulltext files, or @BEGIN, which references the ALTO elements directly)
• ENMAP even seems to allow mets:area/@FILEID references to the mets:file entries instead of direct mets:fptr/@FILEID in the physical structMap

There are probably more challenges, but this is already a lot of work. So I'm afraid there is no simple workaround. Sorry, I cannot promise any progress on this matter ATM. But PRs are always welcome of course!

[bertsky]

duplicate of #65

EDIT: let's keep this separate!

[bertsky]

self-note: cf. MODS and METS parsing in ULB Halle's digital-flow