@JKenP: Although I agree with your point in many situations, this isn't one of them.
We are talking about 4 things:
- A conceptual entity w/some relationships dictionary for *book bibliographic data*. This dictionary would help standardize terms and their semantics. For example, the dictionary could contain the term "in print", noting that this term means that the book is still available from a "publisher", and may have a "last print run date". This dictionary is documentation, and has nothing to do with calibre code. I can't see any objection to the creation of this dictionary.
NB: I draw a distinction between book bibliographic data and, for example, research paper bibliographic data. The two domains seem similar, but are in detail quite different. Calibre should not try to become Endnote or Zotero.
- A calibre implementation of the dictionary. This dictionary is a subset of the above, providing agreed-upon names and abstract types, then mapping the abstract types onto one of calibre's column types. To be sure, this process will generate discomfort, because the mapping of abstract type to calibre type will often be approximate.
- A user-supplied mapping of dictionary terms to database columns. This mapping permits me to name my columns however I want, while specifying at the entity level the semantics of the data.
- Metadata plugins that use the above three things to automatically insert data into the database. The writer of the plugin determines the meaning of the information supplied by the metadata source, maps it to the closest equivalent in the calibre dictionary, and uses the map to store the data.
Calibre already does all of the above in one form or another. I consider this work almost to be a refactoring effort, moving to using the same term for the same thing, changing code that doesn't respect the mappings, and using common code where the same thing is done.
Responding to your last paragraph: note that we are not proposing many of the other things that come with SAP customization: active relationships, customizable user interfaces, data integrity rules, report generation, event triggers, and interconnection of wildly-differing domains such as CRM and JIT inventory management. What is being proposed here is codification of something that many of us already have in mind and is already implemented throughout calibre: the meaning of the data we store about books.
@kiwidude: what is it you would like from me? I would be happy to build the code that maps from external dictionary field names to columns (this is trivial), and to do the work so that edit metadata single updates the custom data. Building the data dictionary will be work over time, with the metadata plugin authors providing a push. A gatekeeper is probably necessary, but we have a pleasant sufficiency of these.
Is there something else?