I'd be interested in joining the conversation, but I won't be able to meet on Monday from 9:20 to 11:20.  Any other time on Monday or Tuesday (or even today) would be fine.

That works for me. Michael On Jan 27, 2012, at 12:59 PM, Megan Forbes wrote: > How about 12PST/3EST on Monday? > > On Fri, Jan 27, 2012 at 3:21 PM, Michael T. Black <mtblack@berkeley.edu> wrote: > Hi John, > > I'd be interested in joining the conversation, but I won't be able to meet on Monday from 9:20 to 11:20. Any other time on Monday or Tuesday (or even today) would be fine. > > Michael > > On Jan 27, 2012, at 9:56 AM, jblowe@berkeley.edu wrote: > > > Megan, > > > > Yes, there's a lot there! > > > > I could do any of those time, with a slight preference for Monday. > > > > May I tentatively suggest Monday 10AM PST / 1PM EST? We can wait to here > > from other interested parties before confirming. > > > > Regards, > > > > John > > > >> Thank you for the feedback, John, and welcome to the team! > >> > >> I think there are more issues in the below than can be comfortably dealt > >> with over email - how about an open Skype or Connect session with any > >> interested parties? I could do anytime in the afternoon on either Monday > >> or > >> Tuesday next week. If anyone from SMK would like to attend, we'd have to > >> go > >> earlier, more like 8PST/11EST, which I could do on Tuesday or Wednesday of > >> next week. > >> > >> Please let me know what works for you. > >> > >> Best regards, > >> Megan > >> > >> > >> On Thu, Jan 26, 2012 at 7:11 PM, <jblowe@berkeley.edu> wrote: > >> > >>> Megan, et al., > >>> > >>> Thanks for the opporunity to comment on changes to this functionality. > >>> > >>> The alas rather lengthy response here grew from recent discussions with > >>> the UCB deployment team working on PAHMA and other CSpace folks. While > >>> the use cases and points made below are relevant to the PAHMA > >>> implementation, a review of wiki pages indicates that most if not all of > >>> these are germane to other institutions, so I apologize in advance if > >>> the > >>> points and use cases at times redundant with remarks already made wrt > >>> other deployments; nevertheless, I have at times mentioned other use > >>> cases > >>> in the discussion below to butress my points. > >>> > >>> And parenthetically, let me say that despite the fact that this is my > >>> first month as a CSpace deployer, I fully expect to be held to answer > >>> for > >>> any errors, omissions, and misrepresentations in these remarks. Please > >>> point out any faults you find! And I apologize again in advance for the > >>> length of this post. (Je n'ai fait celle-ci plus longue que parce que je > >>> n'ai pas eu le loisir de la faire plus courte. -- Pascal) > >>> > >>> WIKI PAGES REFERRED TO > >>> > >>> Current proposal for changes, contains links to current and proposed > >>> workflows > >>> > >>> > >>> http://wiki.collectionspace.org/display/collectionspace/Phase+III+Location+and+Movement+Upgrade > >>> > >>> A Requirements page, perhaps now outdated, describing how locations and > >>> and the history of an object's location are to be handled. > >>> > >>> > >>> http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Requirements > >>> > >>> Use cases and other "on the ground" writings about locations and > >>> movements. > >>> > >>> > >>> http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Use+Cases > >>> > >>> > >>> http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping > >>> > >>> > >>> http://wiki.collectionspace.org/display/deploy/PAHMA+Customizations+-+Storage+Authority > >>> > >>> > >>> https://wiki.collectionspace.org:8444/display/deploy/Crates+and+other+mobile+containers > >>> > >>> REMARKS AND OBSERVATIONS > >>> > >>> While it does seem clear that some revisions will be needed to the way > >>> Locations and Movements are handled, some of the changes suggested seem > >>> rather drastic while others seem not to go far enough. Some of the > >>> issues > >>> identified appear to be *merely* semantic, conceptual, or ontological > >>> (and > >>> therefore may *simply* require a change in thinking and documentation), > >>> while others are engineering conundrums which (may) require changes at > >>> every level of the software, schema to UI). I am not sure which is > >>> which! > >>> > >>> The notion that "the current situation where an object or group of > >>> objects > >>> must be 'move' in order to be given an updated location" represents a > >>> bug > >>> to be fixed is a misconceptualization. It is in fact a desired feature > >>> whose utility deserves clarification. Some examples: > >>> > >>> 1. Moving an object from one location to the same location is either a > >>> data entry mistake *or* an inventory action. That is, the Inventory > >>> process can viewed as a sub-case of Movement. (This is how it works at > >>> PAHMA in TMS now). Therefore, all location updates are indeed moves! > >>> (Aside: from an implementation point of view, perhaps all movements > >>> merit > >>> a separate attribute on the Movement record to indicate their > >>> "moveType", > >>> to facilitate UI filtering and reporting.) > >>> > >>> 2. Both Objects and Locations can move. It is important not to conflate > >>> these two cases. > >>> > >>> 2a. On the one hand, moving a bunch of objects that are all in the same > >>> location to another location could be conceptualized as just that: a > >>> bunch > >>> of objects moving. However, if in reality it is the *location* that is > >>> moving (a tray, or a crate), then perhaps this is best thought of (and > >>> perhaps implemented as) a change to one Location and not as a change to > >>> multiple Objects. > >>> > >>> Indeed, it is unclear to me how CSpace implements "Movements of > >>> Locations", if it handles them at all. > >>> > >>> 2b. Thinking about this is complicated by the fact that Movable > >>> Locations > >>> have a number of potential important properties that Immovable Locations > >>> do not have, and these distinctions may need to be captured. Subcases > >>> of > >>> Movable Locations include not only the "crate use case" and "specimen > >>> tray > >>> use case" (not the same, I think), but alsot Transitory Locations (which > >>> exist only for a little while, e.g. "this crate is now on Moving Van #7 > >>> and enroute", "this package was picked up by UPS, tracking number > >>> 1Z23456789") and Fuzzy Locations (which are underspecified or even > >>> completely unspecified e.g. "all the crates in this room will be moving > >>> tomorrow to our Storage Facility, we just don't know which room", "the > >>> specimens on these trays on Rack 26 are gonna need to get cleared out > >>> and > >>> go someplace refrigerated soon!"). > >>> > >>> 3. The constraints on Object Movement are of course different than those > >>> for Location Movement. A short list of these: > >>> > >>> 3a. Movable Locations can move to most any location (movable or not, > >>> though real-world constraints certainly exist), but Fixed Locations > >>> cannot > >>> move. The case of a Movable Location moving to another Movable (or > >>> Transitory) Location is usually either a "nesting move" (a container > >>> into > >>> another container) or an instance of "typical move", where objects are > >>> being moved en masse for exhibition, restoration, etc. > >>> > >>> 3b. Changing a Fixed Location (in the Storage Location Authority) may > >>> entail a number of real-world and databases changes, ergo the idea of > >>> having "write once" location storage records seems like quite a good > >>> one. > >>> In PAHMA's case, a location's displayName will be barcoded so updating > >>> its > >>> record in the database implies reprinting and distributing barcode > >>> labels. > >>> In PAHMA's case, therefore "crates", if represented as Locations, will > >>> have to have immutable displayNames. This in turn creates the > >>> uncomfortable conundrum that the displayName in CSpace as shown in the > >>> UI > >>> will not show the actual location in PAHMA's location hierarchy. Not > >>> sure > >>> what to do about this yet! > >>> > >>> 3c. Object movements are generally simple or atomic, though in the case > >>> where an object is at a Movable Location a UI caution about moving the > >>> other objects is probably warranted. > >>> > >>> 4. Parenthetically, it's been lamented that a Storage Location authority > >>> lacks a suitable hierarchical model. Some of the location movement > >>> issues > >>> mentioned above *might* be addressed with such a model. A Storage > >>> Location Authority is a sub-type of a Concept Authority, with (it seems) > >>> some additional properties. At PAHMA, the 5 levels of the "location > >>> hierarchy" are quite parallel to the 7 ranks of Biological > >>> Classification. > >>> Any CSpace implementation supporting the biological or geographical > >>> domains would be welcome in the location domain. > >>> > >>> (A complication is that the values used for each rank in a location > >>> hierarchy is not guaranteed to be unique: the string "Cordata" only > >>> occurs > >>> in the rank of phylum, under kingdom "Animalia"; but container "Vault > >>> 15" > >>> may appear in room "Room 12" of site "Kroeber Hall" or room "Room 12" of > >>> site "Hearst Gym".) > >>> > >>> UPSHOT > >>> > >>> The upshot of this, presented tentatively and with humility, is: > >>> > >>> * Movement and Location Authority records deserve some set of attributes > >>> (term statuses?) in the core implementation to facilitate some > >>> as-yet-not-completely-understood-or-implemented features. Examples of > >>> these attributes might include (for Storage Locations) > >>> "active/inactive", > >>> "movable/fixed", "transitory/permanent", etc. Patrick noted that > >>> some/all > >>> of this functionality exists for authorities. For movements, statuses or > >>> attributes might include "planned/completed", "inventory/reallymoving", > >>> etc. (Can a term in an authority have several statuses?) > >>> > >>> * Best Practices and a few "worked examples" might go a long way towards > >>> clarifying what can and can't be done and how. Wiki pages covering cases > >>> like "How to Move Containers like Crates and Trays", "Moving Multiple > >>> Objects", "Moving Objects When You Don't Know Where They Are Going", > >>> "Updating a Location Authority Record: Making Sure It Works", etc. > >>> remain > >>> to be defined. The workflows proposed may in fact cover the required > >>> cases, but a warm and fuzzy sense of completeness is lacking. > >>> > >>> * At PAHMA, we are considering whether a generalization of one of the > >>> "regular" Movement workflows (i.e. "location update via barcode > >>> scanner") > >>> might not be the way to actually accomplish the migration of existing > >>> object location data to CSpace. Reactions from other users about the > >>> efficacy and wisdom of this would be most welcome! > >>> > >>> Hope this helps! > >>> > >>> John B. Lowe, PhD > >>> > >>> "Wherever you go, there you are" -- DR Davenport > >>> > >>> > >>> _______________________________________________ > >>> Talk mailing list > >>> Talk@lists.collectionspace.org > >>> > >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >>> > >> > >> > >> > >> -- > >> Megan Forbes > >> Collection Manager > >> > >> Museum of the Moving Image > >> 36-01 35 Avenue Astoria, NY 11106 > >> movingimage.us 718 777 6800 > >> Direct 718 777 6834 > >> > > > > > > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct 718 777 6834 > >

    I'd be interested in joining the conversation, but I won't be able

Ok, let's shoot for Monday at 12PST/3EST to discuss plans for upgrading our location and movement functionality. Skype is usually better than Connect for conversations, so let's plan to have it there. Everyone who's attending - if we're not already Skype friends, please send me your ID so I can bring you in. Thanks, Megan On Fri, Jan 27, 2012 at 4:05 PM, Michael T. Black <mtblack@berkeley.edu>wrote: > That works for me. > > Michael > > > On Jan 27, 2012, at 12:59 PM, Megan Forbes wrote: > > How about 12PST/3EST on Monday? > > On Fri, Jan 27, 2012 at 3:21 PM, Michael T. Black <mtblack@berkeley.edu>wrote: > >> Hi John, >> >> I'd be interested in joining the conversation, but I won't be able >> to meet on Monday from 9:20 to 11:20. Any other time on Monday or Tuesday >> (or even today) would be fine. >> >> Michael >> >> On Jan 27, 2012, at 9:56 AM, jblowe@berkeley.edu wrote: >> >> > Megan, >> > >> > Yes, there's a lot there! >> > >> > I could do any of those time, with a slight preference for Monday. >> > >> > May I tentatively suggest Monday 10AM PST / 1PM EST? We can wait to here >> > from other interested parties before confirming. >> > >> > Regards, >> > >> > John >> > >> >> Thank you for the feedback, John, and welcome to the team! >> >> >> >> I think there are more issues in the below than can be comfortably >> dealt >> >> with over email - how about an open Skype or Connect session with any >> >> interested parties? I could do anytime in the afternoon on either >> Monday >> >> or >> >> Tuesday next week. If anyone from SMK would like to attend, we'd have >> to >> >> go >> >> earlier, more like 8PST/11EST, which I could do on Tuesday or >> Wednesday of >> >> next week. >> >> >> >> Please let me know what works for you. >> >> >> >> Best regards, >> >> Megan >> >> >> >> >> >> On Thu, Jan 26, 2012 at 7:11 PM, <jblowe@berkeley.edu> wrote: >> >> >> >>> Megan, et al., >> >>> >> >>> Thanks for the opporunity to comment on changes to this functionality. >> >>> >> >>> The alas rather lengthy response here grew from recent discussions >> with >> >>> the UCB deployment team working on PAHMA and other CSpace folks. >> While >> >>> the use cases and points made below are relevant to the PAHMA >> >>> implementation, a review of wiki pages indicates that most if not all >> of >> >>> these are germane to other institutions, so I apologize in advance if >> >>> the >> >>> points and use cases at times redundant with remarks already made wrt >> >>> other deployments; nevertheless, I have at times mentioned other use >> >>> cases >> >>> in the discussion below to butress my points. >> >>> >> >>> And parenthetically, let me say that despite the fact that this is my >> >>> first month as a CSpace deployer, I fully expect to be held to answer >> >>> for >> >>> any errors, omissions, and misrepresentations in these remarks. Please >> >>> point out any faults you find! And I apologize again in advance for >> the >> >>> length of this post. (Je n'ai fait celle-ci plus longue que parce que >> je >> >>> n'ai pas eu le loisir de la faire plus courte. -- Pascal) >> >>> >> >>> WIKI PAGES REFERRED TO >> >>> >> >>> Current proposal for changes, contains links to current and proposed >> >>> workflows >> >>> >> >>> >> >>> >> http://wiki.collectionspace.org/display/collectionspace/Phase+III+Location+and+Movement+Upgrade >> >>> >> >>> A Requirements page, perhaps now outdated, describing how locations >> and >> >>> and the history of an object's location are to be handled. >> >>> >> >>> >> >>> >> http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Requirements >> >>> >> >>> Use cases and other "on the ground" writings about locations and >> >>> movements. >> >>> >> >>> >> >>> >> http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Use+Cases >> >>> >> >>> >> >>> >> http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping >> >>> >> >>> >> >>> >> http://wiki.collectionspace.org/display/deploy/PAHMA+Customizations+-+Storage+Authority >> >>> >> >>> >> >>> >> https://wiki.collectionspace.org:8444/display/deploy/Crates+and+other+mobile+containers >> >>> >> >>> REMARKS AND OBSERVATIONS >> >>> >> >>> While it does seem clear that some revisions will be needed to the way >> >>> Locations and Movements are handled, some of the changes suggested >> seem >> >>> rather drastic while others seem not to go far enough. Some of the >> >>> issues >> >>> identified appear to be *merely* semantic, conceptual, or ontological >> >>> (and >> >>> therefore may *simply* require a change in thinking and >> documentation), >> >>> while others are engineering conundrums which (may) require changes at >> >>> every level of the software, schema to UI). I am not sure which is >> >>> which! >> >>> >> >>> The notion that "the current situation where an object or group of >> >>> objects >> >>> must be 'move' in order to be given an updated location" represents a >> >>> bug >> >>> to be fixed is a misconceptualization. It is in fact a desired feature >> >>> whose utility deserves clarification. Some examples: >> >>> >> >>> 1. Moving an object from one location to the same location is either a >> >>> data entry mistake *or* an inventory action. That is, the Inventory >> >>> process can viewed as a sub-case of Movement. (This is how it works at >> >>> PAHMA in TMS now). Therefore, all location updates are indeed moves! >> >>> (Aside: from an implementation point of view, perhaps all movements >> >>> merit >> >>> a separate attribute on the Movement record to indicate their >> >>> "moveType", >> >>> to facilitate UI filtering and reporting.) >> >>> >> >>> 2. Both Objects and Locations can move. It is important not to >> conflate >> >>> these two cases. >> >>> >> >>> 2a. On the one hand, moving a bunch of objects that are all in the >> same >> >>> location to another location could be conceptualized as just that: a >> >>> bunch >> >>> of objects moving. However, if in reality it is the *location* that is >> >>> moving (a tray, or a crate), then perhaps this is best thought of (and >> >>> perhaps implemented as) a change to one Location and not as a change >> to >> >>> multiple Objects. >> >>> >> >>> Indeed, it is unclear to me how CSpace implements "Movements of >> >>> Locations", if it handles them at all. >> >>> >> >>> 2b. Thinking about this is complicated by the fact that Movable >> >>> Locations >> >>> have a number of potential important properties that Immovable >> Locations >> >>> do not have, and these distinctions may need to be captured. Subcases >> >>> of >> >>> Movable Locations include not only the "crate use case" and "specimen >> >>> tray >> >>> use case" (not the same, I think), but alsot Transitory Locations >> (which >> >>> exist only for a little while, e.g. "this crate is now on Moving Van >> #7 >> >>> and enroute", "this package was picked up by UPS, tracking number >> >>> 1Z23456789") and Fuzzy Locations (which are underspecified or even >> >>> completely unspecified e.g. "all the crates in this room will be >> moving >> >>> tomorrow to our Storage Facility, we just don't know which room", "the >> >>> specimens on these trays on Rack 26 are gonna need to get cleared out >> >>> and >> >>> go someplace refrigerated soon!"). >> >>> >> >>> 3. The constraints on Object Movement are of course different than >> those >> >>> for Location Movement. A short list of these: >> >>> >> >>> 3a. Movable Locations can move to most any location (movable or not, >> >>> though real-world constraints certainly exist), but Fixed Locations >> >>> cannot >> >>> move. The case of a Movable Location moving to another Movable (or >> >>> Transitory) Location is usually either a "nesting move" (a container >> >>> into >> >>> another container) or an instance of "typical move", where objects are >> >>> being moved en masse for exhibition, restoration, etc. >> >>> >> >>> 3b. Changing a Fixed Location (in the Storage Location Authority) may >> >>> entail a number of real-world and databases changes, ergo the idea of >> >>> having "write once" location storage records seems like quite a good >> >>> one. >> >>> In PAHMA's case, a location's displayName will be barcoded so updating >> >>> its >> >>> record in the database implies reprinting and distributing barcode >> >>> labels. >> >>> In PAHMA's case, therefore "crates", if represented as Locations, will >> >>> have to have immutable displayNames. This in turn creates the >> >>> uncomfortable conundrum that the displayName in CSpace as shown in the >> >>> UI >> >>> will not show the actual location in PAHMA's location hierarchy. Not >> >>> sure >> >>> what to do about this yet! >> >>> >> >>> 3c. Object movements are generally simple or atomic, though in the >> case >> >>> where an object is at a Movable Location a UI caution about moving the >> >>> other objects is probably warranted. >> >>> >> >>> 4. Parenthetically, it's been lamented that a Storage Location >> authority >> >>> lacks a suitable hierarchical model. Some of the location movement >> >>> issues >> >>> mentioned above *might* be addressed with such a model. A Storage >> >>> Location Authority is a sub-type of a Concept Authority, with (it >> seems) >> >>> some additional properties. At PAHMA, the 5 levels of the "location >> >>> hierarchy" are quite parallel to the 7 ranks of Biological >> >>> Classification. >> >>> Any CSpace implementation supporting the biological or geographical >> >>> domains would be welcome in the location domain. >> >>> >> >>> (A complication is that the values used for each rank in a location >> >>> hierarchy is not guaranteed to be unique: the string "Cordata" only >> >>> occurs >> >>> in the rank of phylum, under kingdom "Animalia"; but container "Vault >> >>> 15" >> >>> may appear in room "Room 12" of site "Kroeber Hall" or room "Room 12" >> of >> >>> site "Hearst Gym".) >> >>> >> >>> UPSHOT >> >>> >> >>> The upshot of this, presented tentatively and with humility, is: >> >>> >> >>> * Movement and Location Authority records deserve some set of >> attributes >> >>> (term statuses?) in the core implementation to facilitate some >> >>> as-yet-not-completely-understood-or-implemented features. Examples of >> >>> these attributes might include (for Storage Locations) >> >>> "active/inactive", >> >>> "movable/fixed", "transitory/permanent", etc. Patrick noted that >> >>> some/all >> >>> of this functionality exists for authorities. For movements, statuses >> or >> >>> attributes might include "planned/completed", >> "inventory/reallymoving", >> >>> etc. (Can a term in an authority have several statuses?) >> >>> >> >>> * Best Practices and a few "worked examples" might go a long way >> towards >> >>> clarifying what can and can't be done and how. Wiki pages covering >> cases >> >>> like "How to Move Containers like Crates and Trays", "Moving Multiple >> >>> Objects", "Moving Objects When You Don't Know Where They Are Going", >> >>> "Updating a Location Authority Record: Making Sure It Works", etc. >> >>> remain >> >>> to be defined. The workflows proposed may in fact cover the required >> >>> cases, but a warm and fuzzy sense of completeness is lacking. >> >>> >> >>> * At PAHMA, we are considering whether a generalization of one of the >> >>> "regular" Movement workflows (i.e. "location update via barcode >> >>> scanner") >> >>> might not be the way to actually accomplish the migration of existing >> >>> object location data to CSpace. Reactions from other users about the >> >>> efficacy and wisdom of this would be most welcome! >> >>> >> >>> Hope this helps! >> >>> >> >>> John B. Lowe, PhD >> >>> >> >>> "Wherever you go, there you are" -- DR Davenport >> >>> >> >>> >> >>> _______________________________________________ >> >>> Talk mailing list >> >>> Talk@lists.collectionspace.org >> >>> >> >>> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >>> >> >> >> >> >> >> >> >> -- >> >> Megan Forbes >> >> Collection Manager >> >> >> >> Museum of the Moving Image >> >> 36-01 35 Avenue Astoria, NY 11106 >> >> movingimage.us 718 777 6800 >> >> Direct 718 777 6834 >> >> >> > >> > >> > >> > _______________________________________________ >> > Talk mailing list >> > Talk@lists.collectionspace.org >> > >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct 718 777 6834 > > > > -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 Direct 718 777 6834

   I'd be interested in joining the conversation, but I won't be able to meet on Monday from 9:20 to 11:20.  Any other time on Monday or Tuesday (or even today) would be fine.

We will not be able to join you for this discussion - but we would very much like to read the minutes of your meeting. FYI - At SMK we do not at present use movable locations. Cheers, Kim ________________________________ Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes Sendt: 27. januar 2012 23:22 Til: Michael T. Black Cc: CollectionSpace Talk List Emne: Re: [Talk] [Work] Fwd: Upgrading Location and Movement Ok, let's shoot for Monday at 12PST/3EST to discuss plans for upgrading our location and movement functionality. Skype is usually better than Connect for conversations, so let's plan to have it there. Everyone who's attending - if we're not already Skype friends, please send me your ID so I can bring you in. Thanks, Megan On Fri, Jan 27, 2012 at 4:05 PM, Michael T. Black <mtblack@berkeley.edu> wrote: That works for me. Michael On Jan 27, 2012, at 12:59 PM, Megan Forbes wrote: How about 12PST/3EST on Monday? On Fri, Jan 27, 2012 at 3:21 PM, Michael T. Black <mtblack@berkeley.edu> wrote: Hi John, I'd be interested in joining the conversation, but I won't be able to meet on Monday from 9:20 to 11:20. Any other time on Monday or Tuesday (or even today) would be fine. Michael On Jan 27, 2012, at 9:56 AM, jblowe@berkeley.edu wrote: > Megan, > > Yes, there's a lot there! > > I could do any of those time, with a slight preference for Monday. > > May I tentatively suggest Monday 10AM PST / 1PM EST? We can wait to here > from other interested parties before confirming. > > Regards, > > John > >> Thank you for the feedback, John, and welcome to the team! >> >> I think there are more issues in the below than can be comfortably dealt >> with over email - how about an open Skype or Connect session with any >> interested parties? I could do anytime in the afternoon on either Monday >> or >> Tuesday next week. If anyone from SMK would like to attend, we'd have to >> go >> earlier, more like 8PST/11EST, which I could do on Tuesday or Wednesday of >> next week. >> >> Please let me know what works for you. >> >> Best regards, >> Megan >> >> >> On Thu, Jan 26, 2012 at 7:11 PM, <jblowe@berkeley.edu> wrote: >> >>> Megan, et al., >>> >>> Thanks for the opporunity to comment on changes to this functionality. >>> >>> The alas rather lengthy response here grew from recent discussions with >>> the UCB deployment team working on PAHMA and other CSpace folks. While >>> the use cases and points made below are relevant to the PAHMA >>> implementation, a review of wiki pages indicates that most if not all of >>> these are germane to other institutions, so I apologize in advance if >>> the >>> points and use cases at times redundant with remarks already made wrt >>> other deployments; nevertheless, I have at times mentioned other use >>> cases >>> in the discussion below to butress my points. >>> >>> And parenthetically, let me say that despite the fact that this is my >>> first month as a CSpace deployer, I fully expect to be held to answer >>> for >>> any errors, omissions, and misrepresentations in these remarks. Please >>> point out any faults you find! And I apologize again in advance for the >>> length of this post. (Je n'ai fait celle-ci plus longue que parce que je >>> n'ai pas eu le loisir de la faire plus courte. -- Pascal) >>> >>> WIKI PAGES REFERRED TO >>> >>> Current proposal for changes, contains links to current and proposed >>> workflows >>> >>> >>> http://wiki.collectionspace.org/display/collectionspace/Phase+III+Location+and+Movement+Upgrade >>> >>> A Requirements page, perhaps now outdated, describing how locations and >>> and the history of an object's location are to be handled. >>> >>> >>> http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Requirements >>> >>> Use cases and other "on the ground" writings about locations and >>> movements. >>> >>> >>> http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Use+Cases >>> >>> >>> http://wiki.collectionspace.org/display/deploy/PAHMA+Storage+Location+data+mapping >>> >>> >>> http://wiki.collectionspace.org/display/deploy/PAHMA+Customizations+-+Storage+Authority >>> >>> >>> https://wiki.collectionspace.org:8444/display/deploy/Crates+and+other+mobile+containers >>> >>> REMARKS AND OBSERVATIONS >>> >>> While it does seem clear that some revisions will be needed to the way >>> Locations and Movements are handled, some of the changes suggested seem >>> rather drastic while others seem not to go far enough. Some of the >>> issues >>> identified appear to be *merely* semantic, conceptual, or ontological >>> (and >>> therefore may *simply* require a change in thinking and documentation), >>> while others are engineering conundrums which (may) require changes at >>> every level of the software, schema to UI). I am not sure which is >>> which! >>> >>> The notion that "the current situation where an object or group of >>> objects >>> must be 'move' in order to be given an updated location" represents a >>> bug >>> to be fixed is a misconceptualization. It is in fact a desired feature >>> whose utility deserves clarification. Some examples: >>> >>> 1. Moving an object from one location to the same location is either a >>> data entry mistake *or* an inventory action. That is, the Inventory >>> process can viewed as a sub-case of Movement. (This is how it works at >>> PAHMA in TMS now). Therefore, all location updates are indeed moves! >>> (Aside: from an implementation point of view, perhaps all movements >>> merit >>> a separate attribute on the Movement record to indicate their >>> "moveType", >>> to facilitate UI filtering and reporting.) >>> >>> 2. Both Objects and Locations can move. It is important not to conflate >>> these two cases. >>> >>> 2a. On the one hand, moving a bunch of objects that are all in the same >>> location to another location could be conceptualized as just that: a >>> bunch >>> of objects moving. However, if in reality it is the *location* that is >>> moving (a tray, or a crate), then perhaps this is best thought of (and >>> perhaps implemented as) a change to one Location and not as a change to >>> multiple Objects. >>> >>> Indeed, it is unclear to me how CSpace implements "Movements of >>> Locations", if it handles them at all. >>> >>> 2b. Thinking about this is complicated by the fact that Movable >>> Locations >>> have a number of potential important properties that Immovable Locations >>> do not have, and these distinctions may need to be captured. Subcases >>> of >>> Movable Locations include not only the "crate use case" and "specimen >>> tray >>> use case" (not the same, I think), but alsot Transitory Locations (which >>> exist only for a little while, e.g. "this crate is now on Moving Van #7 >>> and enroute", "this package was picked up by UPS, tracking number >>> 1Z23456789") and Fuzzy Locations (which are underspecified or even >>> completely unspecified e.g. "all the crates in this room will be moving >>> tomorrow to our Storage Facility, we just don't know which room", "the >>> specimens on these trays on Rack 26 are gonna need to get cleared out >>> and >>> go someplace refrigerated soon!"). >>> >>> 3. The constraints on Object Movement are of course different than those >>> for Location Movement. A short list of these: >>> >>> 3a. Movable Locations can move to most any location (movable or not, >>> though real-world constraints certainly exist), but Fixed Locations >>> cannot >>> move. The case of a Movable Location moving to another Movable (or >>> Transitory) Location is usually either a "nesting move" (a container >>> into >>> another container) or an instance of "typical move", where objects are >>> being moved en masse for exhibition, restoration, etc. >>> >>> 3b. Changing a Fixed Location (in the Storage Location Authority) may >>> entail a number of real-world and databases changes, ergo the idea of >>> having "write once" location storage records seems like quite a good >>> one. >>> In PAHMA's case, a location's displayName will be barcoded so updating >>> its >>> record in the database implies reprinting and distributing barcode >>> labels. >>> In PAHMA's case, therefore "crates", if represented as Locations, will >>> have to have immutable displayNames. This in turn creates the >>> uncomfortable conundrum that the displayName in CSpace as shown in the >>> UI >>> will not show the actual location in PAHMA's location hierarchy. Not >>> sure >>> what to do about this yet! >>> >>> 3c. Object movements are generally simple or atomic, though in the case >>> where an object is at a Movable Location a UI caution about moving the >>> other objects is probably warranted. >>> >>> 4. Parenthetically, it's been lamented that a Storage Location authority >>> lacks a suitable hierarchical model. Some of the location movement >>> issues >>> mentioned above *might* be addressed with such a model. A Storage >>> Location Authority is a sub-type of a Concept Authority, with (it seems) >>> some additional properties. At PAHMA, the 5 levels of the "location >>> hierarchy" are quite parallel to the 7 ranks of Biological >>> Classification. >>> Any CSpace implementation supporting the biological or geographical >>> domains would be welcome in the location domain. >>> >>> (A complication is that the values used for each rank in a location >>> hierarchy is not guaranteed to be unique: the string "Cordata" only >>> occurs >>> in the rank of phylum, under kingdom "Animalia"; but container "Vault >>> 15" >>> may appear in room "Room 12" of site "Kroeber Hall" or room "Room 12" of >>> site "Hearst Gym".) >>> >>> UPSHOT >>> >>> The upshot of this, presented tentatively and with humility, is: >>> >>> * Movement and Location Authority records deserve some set of attributes >>> (term statuses?) in the core implementation to facilitate some >>> as-yet-not-completely-understood-or-implemented features. Examples of >>> these attributes might include (for Storage Locations) >>> "active/inactive", >>> "movable/fixed", "transitory/permanent", etc. Patrick noted that >>> some/all >>> of this functionality exists for authorities. For movements, statuses or >>> attributes might include "planned/completed", "inventory/reallymoving", >>> etc. (Can a term in an authority have several statuses?) >>> >>> * Best Practices and a few "worked examples" might go a long way towards >>> clarifying what can and can't be done and how. Wiki pages covering cases >>> like "How to Move Containers like Crates and Trays", "Moving Multiple >>> Objects", "Moving Objects When You Don't Know Where They Are Going", >>> "Updating a Location Authority Record: Making Sure It Works", etc. >>> remain >>> to be defined. The workflows proposed may in fact cover the required >>> cases, but a warm and fuzzy sense of completeness is lacking. >>> >>> * At PAHMA, we are considering whether a generalization of one of the >>> "regular" Movement workflows (i.e. "location update via barcode >>> scanner") >>> might not be the way to actually accomplish the migration of existing >>> object location data to CSpace. Reactions from other users about the >>> efficacy and wisdom of this would be most welcome! >>> >>> Hope this helps! >>> >>> John B. Lowe, PhD >>> >>> "Wherever you go, there you are" -- DR Davenport >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >> >> >> >> -- >> Megan Forbes >> Collection Manager >> >> Museum of the Moving Image >> 36-01 35 Avenue Astoria, NY 11106 >> movingimage.us <http://movingimage.us/> 718 777 6800 <tel:718%20777%206800> >> Direct 718 777 6834 <tel:718%20777%206834> >> > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us <http://movingimage.us/> 718 777 6800 <tel:718%20777%206800> Direct 718 777 6834 <tel:718%20777%206834> -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 Direct 718 777 6834