Testimony: DTPO used for an artist's official committee

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).

Thanks for this brilliant and in-depth post on your use of DEVONthink. It is very interesting stuff. (In fact, I’m archiving a copy for my Support database to read again later.)

Also, I’ve been with the company over 3.5 years and I have never used the See Also (magic hat) with an image. This app never ceases to amaze me. Thanks for the pointer!
Cheers! :smiley:

You’re welcome.
Maybe the screenshot isn’t clear enough about the structure, and it is in French as well.
So here’s the rough and incomplete database outline in English (limited to exhibitions and artworks, there are other object types such as audio/video and texts/books).

! Artworks
Artwork type
Creation year
Artwork name
! Exhibitions
Exhibition type
Exhibition year
Exhibition name
* Artworks
replicates of “Artwork name” groups

You can view all the artworks shown in an exhibition by simple expanding the “* Artworks” group tree. You can view all the exhibitions of a specific artwork by selecting the “Artwork name” group, opening the file information panel, and opening the Replicates list (which would then list all the “Exhibition name” that contain a replicate of the currently selected “Artwork name”).

Hello Jim,

As I’m about to receive the visit of a researcher that will consult our archives, I intended to use the web server interface to obtain a read-only mode, but after testing it myself for a few minutes, it occurred to me that this was not powerful enough as a work interface.

Even though you made a great effort to make the interface look like the full software as much as possible, document preview is painful and some critical features are missing, such as “Reveal” after a search.

Therefore I will have to give access to the full application, but is there any way, even by way of “defaults write”, to activate a read-only mode, or at least to activate a debug mode that logs all operation so that I can make sure that no document or group was moved, renamed or deleted by mistake?

Best regards,

Per our other conversation, you could apply a uchg to the .dtBase2 file. When you open it you will see a crossed pencil icon to the right of the database name. Searching will be available but no changes will be able to be made to the database itself.

(Kind of a nice exploit if you ask me. :smiley: )
(And again - because I have to say it - just be careful. :frowning: :open_mouth: :mrgreen: )

Thanks a lot Jim for your answer. However in this post, I was not worried by modifications on the PDFs themselves by the usual team members, which is handled fine by the uchg method, but rather on the database modifications made by guest and junior users: moving groups or documents would be a serious issue due to our specific sorting requirements. Do you have any idea?

This is what I was addressing in this post. If you have a copy of the database on a machine, you can apply the uchg flag to the entire database in Terminal. No one will be able to modify the database until the flag is changed.

Well thanks, I get what you mean now: applying the uchg flag to the whole database files in Terminal would prevent any change, even on the groups and files properties. I haven’t tested it yet, but I suppose that your suggestion means that DEVONthink Pro will not crash if the user tries to make a modification while all files are uchg-locked.

It shouldn’t crash based on this. Also, you can jsut as easily check the Locked checkbox in the Get Info window. :smiley:

Hi Jim,
I wanted to say that I tested the Locked DT database file solution for read-only purposes and it works great! Not only does it not crash, but the UI adapts itself and does not allow even trying to rename or move an item. Easy solution to enable and disable depending on the profile of the user. Way easier than to delete a database after it has been consulted and transfer a brand new copy before resynchronizing again.

Now for other purposes, such as avoiding unwanted modifications to a file, having DT use the OS lock in sync with the internal lock would be great. As I have found, this cannot be done by custom script. When renaming an item or handling sync, only DT could unlock, rename or modify, then lock again. Maybe in a later release.
Best, Edouard

Glad to hear the database lock served its purpose.

Well, we are always working and improving, so we’ll see what the future brings. :smiley: