Just adding my support for improved custom metadata.
My tuppence-worth:
allow metadata to be defined at the global, database, or defined group levels
my use-case would prefer a defined group that could be used everywhere. I already utilise metadata for referencing sources, but I also have a separate database to store receipts of large purchases. One custom metadata field I defined was Warranty Expiry along with the Store Name and Purchase price. Ideally I’d like to have a custom metadata group that just hold these three items, rather than cluttering up my other metadata fields.
also, I’m unable to see any metadata within DTTG - myst be there somewhere! Any clues, anyone?
While I see where the requests for local metadata are coming from I am not sure this is the right way to go.
What the requests seem to imply is that all databases are strictly separated from each other. But what if they are not or won’t be anymore in the future? What happens if an item from database A is moved to database B. And database A has custom metadata B does not have. Will the moving strip the A-only metadata from the item or does the local custom metadata of database B get a silent update? Neither might be intended.
Having DEVONthink ask for what to do every time does not seem very practical either. Just imagine a bigger number of moved items and lots of custom metadata exclusively in database A. And maybe the user only wants some of them to get stripped from the items.
Both databases might even have custom metadata with the same names but different formats. What then?
From my point of view a better approach would be to keep all metadata global, like tags, but to allow to customize their visibility. And not only of custom but all metadata.
What I am suggesting is no less than full modularity of DT’s right pane(s). (And by the way, why stop at the right pane?) ((But please, Christian, if ever, this could only be part of a major for-pay upgrade and not some point-point-point update!))
The visibility of the modules should be customizable per database (and Workspace?). So, say, in a database with photos the geolocation might be interesting and therefore visible. For a database with bills geolocation might be of no interest but a due date and the paid status instead.
That will certainly guarantee a steady flow of interesting and panicky questions in the forum
Seriously: while I like the idea, I’m afraid it will create a UI and support nightmare. Imagine someone seeing data in one database and not in another…
I have largely stopped using custom metadata precisely because of the visibly cluttered nature of global custom metadata.
Global custom metadata that has controlled visibility per database (or group) makes the most sense. Data isn’t lost when moving items from database to database, but what is visible in the inspector pane is controlled and, therefore, potentially less cluttered.
This scenario may lead to additional support questions (e.g. “Where is my data?”) but the questions are quickly and easily resolved (e.g. toggle on your custom metadata fields that have been toggled off).
Database A has custom metadata Author.
Database B does not.
Document with Author attribute is moved to database B. So Author is added to the database’s metadata?
Document with Author is deleted from the database. Author is left behind in the metadata?
Database A has custom metadata Publication Date set as a Date data type.
Database A has custom metadata Publication Date set as a Single-line Text data type.
When a document from database A moves to database B, what happens to the custom metadata in B to resolve the conflict?
Things aren’t as simple as they may appear to you.
Database-specific visibility of global custom metadata is indeed planned, this won’t affect the actual metadata. And it’s not complex at all, just user interface stuff.
