Dear all, Addendum.
Sorry, missed an example related to the public/private question. It’s true that a museum would likely not want to do a public sharing of the internal moves of their objects. This is about use case context but okay (you can imagine just having an internal semantic network to match different systems and want to represent this data). A public use case of internal moves that you could want to share for research purposes would be move of object from storage to exhibition and back. This is a trace of the fact that an object really did go on exhibition (internally). It would be tracked by any museum using Emu and their internal moves module properly. Cheers, George > On Oct 3, 2017, at 1:05 PM, George Bruseker <[email protected]> wrote: > > Dear all, > > I don’t know of CRM encoded data with this information, but internal movement > is traced in almost any major collections management system that I know of. > The one I am most familiar with is the Emu system owned, now, by Axiell. It > generates automatic internal movement records when registrars authorize the > moment around the museum who carried it out and why. An example would be that > the object is moved from storage to conservation lab for work and then back. > This happened in the Museum of Islamic Art, so I guess it would be a use case > for art objects. I also seem to recall some major projects of moving > collections (perhaps of the Field Museum that uses Emu), where the work was > to get everything from old storage A to new storage b. This was crucial > provenance information because it helps them know why something may have gone > missing and or what happened to it along the way (how was it packed, in what > truck did it go). Here again what happened in reality was, I believe, an > instance of move and not a transfer of custody acquisition or any such thing. > > Best, > > George > > >> On Oct 2, 2017, at 10:06 PM, Robert Sanderson <[email protected]> wrote: >> >> >> Hi Christian-Emil, >> >> Could you provide some pointers to data that has Moves? In our experience >> Move is theoretically important, but we could not find any museum that had >> Move activities that weren’t better described as a Transfer of Custody. >> >> In particular: >> • No history of internal movement between galleries / sites (which would not >> be a change of custody) >> • No history of the actual movement of the object between institutions (e.g. >> for exhibitions), which would be better as a transfer of custody anyway. >> • Disincentive to record these events or make them public as it encourages >> theft >> • No real incentive to integrate shipping/tracking and descriptive systems >> >> We’re very happy to move terms around, but only with good cause :) In >> particular, two institutions that both require the class and have actual >> data to support it… preferably also with the intent to publish that data. >> >> Rob >> >> On 10/2/17, 11:59 AM, "Christian-Emil Smith Ore" <[email protected]> >> wrote: >> >> Before Getty(?) send out the the profile to all arts museum, maybe one >> could go through the list once more and add a few central classes, move is >> one of them. >> Best >> Christian-Emil >> ________________________________________ >> From: Crm-sig <[email protected]> on behalf of Robert Sanderson >> <[email protected]> >> Sent: 02 October 2017 19:15 >> To: Dan Matei; martin >> Cc: [email protected] >> Subject: Re: [Crm-sig] NEW ISSUE using CRM >> >> Hi Dan, >> >> If the terms were moved to an extension, for example moving Site to the >> Archaeological extension, would then they would still be available for use >> but not add to the complexity of the base model. >> >> I think there is some “food” they’re asking for, which is the cognitive >> cost of understanding them and when they should be used. If that cost is >> high compared to the value (which I argue that it currently is), then the >> result is decreased usage of the model. This “usability” cost is the >> primary driver for Linked Art – if we can do it once for the entire art >> domain, then every (art) museum or gallery has then had that cost pre-paid. >> >> If you have data in real systems that _require_ the classes we’ve set >> aside, we’d very much like to discuss those with you off-list. >> >> Hope that helps! >> >> Rob >> >> >> On 10/2/17, 7:31 AM, "Crm-sig on behalf of Dan Matei" >> <[email protected] on behalf of [email protected]> wrote: >> >> Friends, >> >> On 30 September 2017 at 17:24, martin <[email protected]> wrote: >> >> >> >> Some classes may be an overspecialization, this has to be discussed >> and respective classes be removed. >> >> >> >> >> >> Oh no ! Please do not remove anything ! >> >> >> I use almost all the CRM elements, in order not to loose nuances in my >> legacy databases (besides museum and library resources I have to model >> intangible resources - e.g. theatre productions). So I have to add elements >> from other ontologies and even – horror >> – to invent some more. I trust more the CRM elements than those I >> invent :-) >> >> >> Moreover, even if some CRM elements are not used too much, they do not >> ask for food. So... >> >> >> Please... >> >> >> Dan >> >> >> PS. You can establish Oskars for the "best" class of the year, the >> most popular property of the year, etc. And the "overspecialised" ones will >> earn no Oskar. >> >> >> >> >> >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
