Writing StructMap and StructLink to mets xml.

[n00blet]

Currently, there are no methods to write StructMap and StructLink to the mets file to link the logical and physical structure of the document. It would be nice, if those functions are added in the next release. @kba

[kba]

We do have some code for writing stuctMaps but only the physical ones, not logical ones.

Can you elaborate a bit on what you need and point me to the code you're currently using? Since you are currently the only project producing logical structMaps, you have the opportunity to shape this API to your liking. :-)

[n00blet]

As our module includes document analysis, we have to link each of the physical file to the logical label (front page, chapter, section..) produced by our classifier.
Yes, we are using core api to write some of the physical structure. And I have referenced you in one of our script for understanding where we write the logical structMaps.

[kba]

Possible spec solution to be implemented to fix this: OCR-D/spec#154

[kba]

These is useful functionality and doable but since ocrd_anybaseocr development has stalled and I don't know any actively developed processors that would benefit from it, let's close this. If there is a more recent/concrete need, please comment.

[bertsky]

These is useful functionality and doable but since ocrd_anybaseocr development has stalled and I don't know any actively developed processors that would benefit from it, let's close this. If there is a more recent/concrete need, please comment.

I am against closing this. Why should core depend on a single module here? After all, we know that some basic API for this is indeed needed, in the least to allow implementations like ocrd_anybaseocr and to fulfil the spec. Keeping this visibly open helps finding the topic – closing would bury it.

[kba]

in the least to allow implementations like ocrd_anybaseocr and to fulfil the spec

But who is going to do that for ocrd_anybaseocr? As I said, I do think the functionality is useful, it would just be much more motivating to have an actual, in-development implementation that needs it. But okay, let's keep it open, let's hope such an implementation will come around in the future.

[bertsky]

I see core as an enabler here. Coming up with a concept/spec how this should eventually look like in the METS, and implementing a simple API is much easier than devising some detection model for it. Maybe the first use-case will be an interactive tool for the intellectual part of digitization workflows, perhaps even as simple as a view in ocrd_browser...