Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

METS div parser: generalize to cover more cases #64

Open
bertsky opened this issue Apr 29, 2022 · 4 comments
Open

METS div parser: generalize to cover more cases #64

bertsky opened this issue Apr 29, 2022 · 4 comments

Comments

@bertsky
Copy link
Member

bertsky commented Apr 29, 2022

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):

# 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
Copy link

t-mayer commented May 17, 2022

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
Copy link
Member Author

bertsky commented May 17, 2022

@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
Copy link
Member Author

bertsky commented May 19, 2022

duplicate of #65

@bertsky
Copy link
Member Author

bertsky commented Dec 1, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants