DEVONthink Pro Office is the main software we use. It contains all our archives separated into two databases, « private » which is mainly e-mails, invoices, productivity documents, standard stuff for your software, and « public » which is accessible to interns, thesis students and researchers that come on premise (for now the only way to provide a read-only mode for them is to use the web interface) and contains the scanned versions of our physical archives (books, artwork pictures, exhibit folders).
We use DTPO as an electric document manager and a database as well. Rather than having fixed forms for each object (artwork, exhibit, book, etc.) — I tested FileMaker Pro and decided I would rather use DTPO extensively instead — we sorted the items within object type groups and chronological subgroups, and indicate links (for instance this artwork was displayed at that exhibit) by using replicants in specific subgroups, thereby getting the flexibility of an EDM (I can dump as many unsorted images or related news article scans into an artwork’s group) and the relationship management of a DB (through the file information window I can see where the replicants are, answering question such as where was this artwork exhibited, what books talk about it, and vice versa, what artworks this book shows or talks about).
The following setup is a bit hard to explain without a screenshot, so I’m posting one. Groups that are supposed to be the primary location for object of a specific type (audio/video, exhibits, artworks, books/texts, non-artwork photos) are named prefixed with a ! (to make them listed higher in the group tree) followed by the object type. Groups that are supposed to contain only links to other groups, which means replicants of a specific type, are named prefixed with an asterisk (like a pointer) followed by the object type. This allows to link objects (represented by groups), browse linked objects within a group, and maintain the linked object in its original location.
Of course links have to be done only in one direction, which must be set during the modeling of the database, but it is totally manageable. If links were done both ways, not only would it be prone to error and take twice the time to set them, but it would be prevented by DTPO since this would generate a recursive error (trying to display the exhibits linked to the artworks linked to one exhibit).
The way I’m planning to store form-like fields (non-linked information) about an object (such as the usual description of an artwork: size, year, technique, etc.) is in structured plain text files (On each line the field name is followed by a colon then the field’s value). I thought this allows for search (I can always type “field name: expected value” in the search field) and this would make it possible to mass-extract the information later, for instance in order to generate the outline of the catalogue raisonné (I will have to deal with the pictures manually I guess). Maybe I could put the key and value on two different lines, in order to better accommodate multiline description fields. I can always add fields in newer files without problems. Of course I lose DB features such as drop-down lists of fixed values.
Maintaining this somehow complex database structure is not a problem, but it requires being cautious, as I’ve seen some examples where people assisting me would move a group instead of replicating it, thereby losing the main sorting plan (for instance a movie’s group would not be in the movies global group anymore). It also makes failed synchronizations a risky operation: last time I tried to cancel a sync between my laptop and my desktop computers (because it appeared to have stopped after the laptop got into sleep mode), I lost no file but I lost dozens of replicates that I had to manually recreate. So right now, when before a sync, I take a screenshot of the group tree with the items counter, in order to compare with the counters after the sync. This shows me if the sync went fine, and also if someone did move (or even delete) a group mistakenly.
Last but not least, I am using a fairly unknown feature of DTPO that could and should be advertised: the magic hat button can display a list of similar documents, not only based on text but also for pictures. I don’t know if the algorithm for that is pHash or something else. This allows me to search through all my archives when I receive a painting’s picture which I need to find a match for in our archives, without having to open all book PDFs and read them page by page in order to look for the same painting. So all pictures in our PDFs have been manually cut and saved JPGs into the database. When I import the picture I received into an empty group, I can look for the similar images thanks to the magic hat button. In my full process I import several variations as well, 90°/180°/270° rotations, H/V flip, B&W conversion (because of B&W photos in old books). Of course this only works when the painting’s picture is cropped mostly in the same way. I’m not sure how precise the similitude hashing algorithm will actually remain when I will have tens of thousands of pictures in the database (especially since the results list is fixed in length, and it is not very long), and I’m not sure how it manages to find similarity when old color pictures show an altered palette, but as of now, it helps me find resembling paintings within pictures of different format and size, that actually are the same painting or even more interestingly, when the received picture is a lookalike/fake of a painting in that archives. Unfortunately, this usage requires that I manually cut and save all the artwork pictures that lie within the pages of PDFs so that they can be compared (I contacted TinEye and others but found no one that could do such a thing, it seems technically too complex anyway and cutting images is useful anyway to kickstart each artwork’s group).