An evergreen topic - came up recently on the TMS listserve as well. > so much of what is required for > DAM is irrelevant and usually not present on a CMS
My personal belief is that the functional requirements differ enough that it is rarely practical to shoehorn the functionality of a DAM into an existing CMS (or vice versa). You end up short changing one area or another and rarely get everything you need. However, I've talked with others on the list who feel quite the opposite. Perhaps it's material enough for a panel sometime at MCN ... >Is anyone using a DAM that is usefully connected >to their CMS? What is good/not so good about what you've got? We assign object data to images in our DAM [Extensis Portfolio] using extract data from our CMS [TMS] , we also push images into the CMS from the DAM. Absolutely essential. In this day and age, I don't see a reason to select systems that cannot communicate with other systems. I would be hesitant to work with a vendor who is unwilling or unable to provide information regarding integration [such as a comprehensible data dictionary] with other products. Again, personal opinion, but I think this one of the real strengths of both Portfolio and TMS - they really do work well together. Peter Dueker Contract DAMS Manager Division of Imaging and Visual Services National Gallery of Art, Washington D.C. On 12/7/09 2:07 PM, "Ari Davidow" <aridavidow at gmail.com> wrote: . >Is anyone using a DAM that is usefully connected >to their CMS? What is good/not so good about what you've got?
