Hello. I am building a database of artworks that are in the museum where I work. For each image file, I’d like to be able to have a standard set of metadata: artist(s), year created, title, country of origin, possibly information about provenance, as well as collection and gallery within the museum.
I thought about creating custom metadata, but before I go down that path, I wanted to see if anyone had better ideas about how best to do this. Any opinions/thoughts would be welcome! Thanks in advance.
Of course I like DT for lots of things. But I would not try to use it for anything that would be represented better by a relational database. As it is probably the case here.
For example, you want to store art works and their artists. This is literally screaming “relational model”:
use one table for the artists (first, middle, last name, date of birth/death, place of birth, whatever)
use another table for the artworks (title, description, materials like oil on canvas, date of acquisition, place of display, catalog # … whatever) and link to the relevant artist here.
the same goes for country of origin: Have one table with all the countries and just link to it from the artworks and/or the artists.
That way, you have each artist only once with all relevant information, and each of their artworks simply refers to them. In DT, you’d have to replicate this information for every piece of art by the same author (@BLUEFROG: At least that’s my impression. Please correct me if I’m wrong here). That’s error prone (think typos) and redundant: If you have pieces by a living artist and this person dies, you’d have to add their date of death to all their artworks.
In a relational database, you could easily get a view of all artworks by a certain artist. Or all artworks acquired in 2002. Or all displayed in the “Rockefeller Gallery” of your museum.
In fact, we’re using a Ninox database for our privat art (only some three hundred pieces), but there are of course other options like Filemaker.
Agreed, I totally see how this would make sense in a relational database. But maybe it would help to know what I’m doing with these images… I’m trying to get started on a Zettelkasten kind of note system about art, and want to be able to link to individual works. And yes, it might be better to use a relational database, but in my thinking, the slip-box system would have, say, one “card” for Picasso, which would link to all of the artworks that he created in my museum. It feels like this might actually suggest the answer in itself - maybe I make a “card” for each piece of metadata…?
As you describe a Zettelkasten, it sounds nearly like a relational database😉
But it’s not. Depending on the size of your collection, it might very fast get unwieldy to use “links” (now I’m sorry for having used this term myself, where “reference” might have been more appropriate).
It really depends on what you intend to do with the data. If you’ll like to search for nearly arbitrary information (“all paintings Picasso painted between 1945 and 1952” or “what’s the value of all works currently on loan”), a Zettelkasten is probably not the right tool.
You might consider contacting Howard Oakley: https://eclecticlight.co/ – a man who knows a lot about both art and Macintoshes. He uses Tinderbox in his work. Not the easiest program to get to grips with, but it does things that other programs do not.
In my workflows the markdown files can be processed in different automated ways. So in some cases they are sent to a LaTeX template which formats for PDF „printing“ and sending as e-letter by mail. As of now I did not found an easy way to process custom metadata.
Could you elaborate about how tags would work for this scenario? I would have a “Picasso” tag and then everything related to Picasso would have that tag? What if I have a note dedicated to Picasso - would that also get a Picasso tag?
Thanks, and I appreciate your framing it that way. I think I have two goals: One is to be more of a pure Zettelkasten, so that I have ideas in my own words about the art and artists I encounter, and the other is to create a database of my own information about art and artists, so that I can pull information together to create tours. I don’t think I will have to do complex searches like you described, but I do think it would be useful to have, say, all of the little anecdotes and what I think are important facts about Picasso on hand. Maybe that’s another group within the database? Not sure…
Most (relational) databases are not well suited to deal with free form data like arbitrary chunks of text – they’re geared towards similarly structured records of data (like the basic information about an artist and a piece of art I mentioned before). One can store nearly arbitrary amounts of text in records, but it’s not so easy to search/process them. But if one needs to only retrieve them like you indicated, that shouldn’t be a problem.
Anyway, you might want to give DT a try with a smaller dataset (maybe 10 to 20 artworks and some 5 to 10 artists) and do the same with a database. Than you should see what works best for you
That is correct. You could use a variety of tags for adding arbitrary metadata, like Cubism or Spain, etc.
If you have enabled Preferences > Import > Tags: Convert hashtags to Tags, DEVONthink will add tags automatically. However, hashtags can’t contain spaces so underscores would have to be used for multiword tags.
Only that relational databases are rare creatures in the Mac world. There is this age-old, insane expensive behemoth FileMaker, and then there are very young contenders that have a strong tendency to disappear after a few years.
Yes, FileMaker is expensive and the cheaper Bento offspring has been discontinued. Then there’s Ninox, but they are not very agile. Not sure about them going away.
And of course there are MariaDB/MySQL, PostgreSQL (free and free of charge), but they come without a GUI, which probably deters most users on a Mac.
Nevertheless, relational databases are better suited for this kind of task then DT, I think.
Pricing — Panorama X uses an entirely new approach to licensing and pricing. I know what you’re thinking: Oh No, Not Another Subscription App. Right? Of course that’s what you’re thinking. ProVUE knows that customers have a love-hate (but mostly hate) relationship with subscriptions, but at the same time, the company needs dependable, recurring revenue. So Jim Rea has come up with a new way of doing subscriptions that I haven’t seen before.
It works like this: You have to set up an account and purchase one or more credits to use Panorama X. To oversimplify slightly, think of a credit as permission to run Panorama X on one Mac for a month. If you want to use Panorama X for just one month, fine: buy one credit, one time, for $15 — no strings attached. But the more credits you buy, the lower the cost. So, a 12-month subscription costs $100 ($8.33 per month), but if you buy 60 credits — enough to last one user 5 years — that’ll set you back only $300, or just $5 per month.
Credits are based on concurrent usage. So if you use Panorama X on two Macs during a given month, but never at the same time, those computers effectively share a credit. Use two computers simultaneously on the same account, however, and that’ll cost you a second credit. On the other hand, if you don’t use Panorama X at all in a given month, you won’t use up any credits, and those unused credits roll over to the next month. For intermittent usage, even a 12-month subscription could last several years.