DILCISBoard / E-ARK-DIP

E-ARK DIP Specification
https://earkdip.dilcis.eu/
Creative Commons Attribution 4.0 International
7 stars 4 forks source link

More argumentation needed for one and only one representation in a DIP #9

Open andersbonielsen opened 5 years ago

andersbonielsen commented 5 years ago

Should the other cases than "one and only one representation in a DIP" be somehow shortly discussed further, to leave clear room for other options? Maybe one page discussion for the possibilities?

andersbonielsen commented 5 years ago

In section 4.1 of the DIP specification we have written the following about the argument for the "one and only one representation in a DIP":

The differences between a METS instance for an E-ARK DIP vs an E-ARK AIP are small. Actually, most of the metadata differences between an AIP and a DIP are in the descriptive metadata or preservation metadata such as EAD and PREMIS. The E-ARK DIP specification is limited to include one and only one representation from an AIP (for which many may exist). This limitation is made to reduce the complexity of the DIP. Future, more complex E-ARK DIP specifications awaits implementations and experiences from this current specification. The chosen representation is itself an E-ARK IP and therefore follows the same structure. This is reflected in the IP being migrated from an AIP to a DIP.

We are aware of other possibilities, and we have also experimented with more than one representation in a DIP, but we find the argument of reduced complexity essential. As we write, more complex E-ARK DIP specifications awaits implementations and experiences from this current specification.

andersbonielsen commented 5 years ago

See also #8

shsdev commented 11 months ago

This requirement was critizised. In some cases it would make sense to distribute several distributions as part of the SIP. "Reduced complexity" is a weak argument to support this.

shsdev commented 10 months ago

I got an additional opinion that this is too restrictive and is being ignored. I also think that there is no reason to limit representations to only one. I would therefore go forward and remove it.

jmaferreira commented 10 months ago

You know... I'm kind of fond of the simplicity argument...

If one needs to expose different manifestations of the same data, then they should create multiple DIPs that perfectly identify the type of manifestation so that the consumer can easily choose right viewer (or consuming mechanism) for that particular data type.

Having multiple manifestations inside a DIP would just make rendering applications more complex...

Is there a concrete use case where this is necessary?