Metadata type concept, in particular metadata types with more than one lookup value selection

Using Mayan EDMS
1

I am currently evaluating v4.6.1 of Mayan EDMS. Mayan EDMS looks quite powerful. :clap: But there a few things (mostly regarding metadata types) that I am a bit concerned about.

Consider the following five usage requirements (category != document type):

  1. The DMS shall provide the administrator with the ability to define the categories for a document.
  2. The DMS shall provide the user with the ability to set one category for a document.
  3. The DMS shall provide the administrator with the ability to rename an existing category.
  4. As soon as the administrator renames one category, all documents associated with the renamed category shall be updated to reflect the name change of the category.
  5. The DMS shall provide the administrator with the ability to define the projects for a document.
  6. The DMS shall provide the user with the ability to set multiple projects for a document.
  7. The DMS shall store metadata values without data duplication.

In my understanding, Mayan EDMS is compliant with requirements 1 and 2, but it is non-compliant with the remaining requirements.

The first two requirements can be fulfilled by defining one metadata type with the name category, the label “Category” and a value lookup (e.g., Foo, Bar, This is a pretty long category requiring 50 bytes). But I’m unable to think about a “proper” solution using Mayan EDMS to fulfill the remaining requirements.

One workaround for requirements 4 to 6 could be to write an additional application that uses the Mayan REST API and would allow to modify the metadata type value for all documents by implementing such domain-specific logic. For example, such an application would add a multi-select combo box for the projects metadata type field. This would allow the user to select from multiple predefined project values (which must be manageable via this application as well then). The value sent to Mayan EDMS via the REST API would then be created by concatenating the values, e.g., "Selection A | Selection B | Selection C". Using the built-in Mayan EDMS search feature, it should be possible to search for the values then.

But this seems to be quite a lot of work, in order to achieve this. If I think about this in more detail, it introduces a lot of other problems and raises questions, e.g., how to enforce that the administrator uses the separate app (and not Mayan EDMS) to deal with such metadata types?

Maybe the comparison to a relational database management system (RDBMS) also helps to understand my concerns:

  • Mayan EDMS supports logical one-to-one relationship of metadata.
  • Mayan EDMS does not support logical many-to-one relationship of metadata.

With “logical” I mean that there seems to be no true relationship, e.g., using indirection with primary and foreign keys. It seems that each and every metadata value is stored as a string in the backend. This also means, that it seems to be impossible to “rename” the value of a metadata type.

Example: Consider two documents with the metadata type category = "Foo". There seems to be no concept that allows to rename the value "Foo" (e.g., to "Bar") once. Instead, the metadata type category has to be updated for the two documents explicitly.

Last but not least: Storage consumption and the single source of truth (SSOT) principle (also related to the above mentioned renaming of metadata type values): If the user stores two documents with the metadata type category set to the value This is a pretty long category requiring 50 bytes (which is defined as a lookup value), it seems that 100 bytes are used in total to store the category of two documents. Since I have to add a few metadata types (category and projects are just an example) with quite long values, this doesn’t sound like the way to go…

To conclude, I got the following questions:

  1. Is my basic understanding of the metadata type concept of Mayan EDMS correct?
  2. Is each and every metadata type value really stored as a flat string in the backend?
  3. Can the requirements mentioned above be fulfilled if using Mayan EDMS?
  4. If the answer to question 3. is “no”: Is there any possibility (plugin concept, anything else), that would allow one to extend Mayan EDMS to fulfill these requirements?
  5. If one adds a lot of metadata types to Mayan EDMS with a some of these metadata types set to pretty long string values: Is there any data available if and how this impacts performance (e.g. regarding search)?

Hopefully there is a way to achieve my requirements using Mayan EDMS. If all this is not possible at all (because it contradicts the core concepts of Mayan EDMS), I do have to look for an alternative. :frowning:

Note that I’ve found and read some resources on the WWW, which seem to confirm my current assessment (Sadly I can only link two here as a new users):