E-ARK SIP parse ignores CONTENTINFORMATIONTYPE and misreads TYPE/OTHERTYPE for contentType

[ThomasEdvardsen]

Summary

Parsing an E-ARK SIP via EARKSIP.parse(...) has two related issues:

1. contentInformationType is never populated from METS, so it stays at default MIXED.
2. contentType is derived from CONTENTINFORMATIONTYPE / OTHERCONTENTINFORMATIONTYPE instead of TYPE / OTHERTYPE.

Steps to Reproduce

1. Create a SIP with root METS attributes:
   • TYPE="Other"
   • csip:OTHERTYPE="Moving images - on tangible media"
   • csip:CONTENTINFORMATIONTYPE="OTHER"
   • csip:OTHERCONTENTINFORMATIONTYPE="MOVINGIMAGES-PROFILE-1.0"
2. Parse it with new EARKSIP().parse(path).
3. Inspect results:
   • sip.getContentType().asString() → incorrect (taken from content information fields)
   • sip.getContentInformationType().asString() → remains MIXED

Expected

• contentType should come from TYPE / OTHERTYPE
• contentInformationType should come from csip:CONTENTINFORMATIONTYPE / csip:OTHERCONTENTINFORMATIONTYPE

Actual

• contentType incorrectly uses content information attributes
• contentInformationType remains default MIXED

Likely Cause

In EARKUtils.setIPContentType(...), the value is taken from CONTENTINFORMATIONTYPE / OTHERCONTENTINFORMATIONTYPE rather than TYPE / OTHERTYPE.
Also, processMainMets(...) (and representation parsing) never call a setter for contentInformationType.

[dosubot]

Hi @ThomasEdvardsen! I'm Dosu and I’m helping the commons-ip team.

Your analysis is correct and matches known issues: the current parsing logic does not set contentInformationType from the METS attributes, so it stays at the default (MIXED), and contentType is incorrectly derived from CONTENTINFORMATIONTYPE/OTHERCONTENTINFORMATIONTYPE instead of TYPE/OTHERTYPE. This is confirmed by user reports and maintainer responses, with several issues and discussions highlighting that these attributes are not set or parsed as expected during SIP parsing or creation (example, example, example).

There is no evidence in the codebase or documentation that this mapping has been fixed. The relevant methods (like EARKUtils.setIPContentType) are not present in the current commons-ip repository, and the model classes only provide generic parse methods without actual parsing logic for these attributes. Multiple issues and PRs indicate ongoing or planned improvements, but the specific mapping bug you described remains unresolved (example).

To address this, the parsing logic should be updated so that:

• contentType is set from TYPE/OTHERTYPE,
• contentInformationType is set from CONTENTINFORMATIONTYPE/OTHERCONTENTINFORMATIONTYPE.

If you need to work around this, you may need to manually set these fields after parsing, or patch the parsing logic to extract the correct attributes from the METS file.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}