CSpace Implementers:

We've gotten a lot of feedback about the current implementation of location
and movement, so have made upgrading this functionality a priority for the
next release. Based on feedback, user stories, and use cases, Angela and I
developed two alternative implementation options for your consideration and
comments. You are also welcome to respond to this email with new
suggestions for implementation that aren't covered by our proposed
solutions.

Option I

Separate the current location and movement tab into two separate tabs, one
called Location and one called Movement. The new tab would have the same
functionality as all current tabs.

There are both pros and cons to this approach; for example, it would get us
out of the current situation where an object or group of objects must be
"moved" in order to be given an updated location. It would unfortunately
not solve the problem of a user being able to inadvertently change the
current location of a group of objects, if s/he did not know that the
location record were tied to multiple objects.

Option 2

Separate the current location and movement tab into two separate services.
Movement would remain a top-level service with its own tab. Location would
be modeled on the sub-record approach we have taken with Contact, where the
Location information group would be its own service, able to be appended to
any procedure (e.g. Cataloging, Intake, Acquisition, etc.).

On the plus side, this approach would provide a clearer link between an
object (or procedure) and its location. We would likely need to couple this
approach with a new UI for batch processing, so that we didn't lose the
ability to make changes in current location to more than one object at a
time. The sub-record model may cause some difficulties with report writing
or import/export, as the information group is not part of the record but
related to it.

The current wireframe for Acquisition shows how this approach would look,
with location as a repeatable group within the procedural record:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Acquisition
.

Additional Ideas

It has been suggested that making the location information group - whether
as a separate procedure or as a separate service - "write once" would help
to mitigate the potential for data or audit trail losses that are possible
with the current implementation and both new options. In other words, once
that data is filled out and the record is saved, it can no longer be
edited. To add a new location, update the current location, fix a typo,
etc., a new location record or group of fields would need to be created. We
are interested in hearing your thoughts on adding this piece of
functionality to either of the new options or to the existing functionality.

Feedback
**
Please submit your comments, critiques, questions, or alternative solutions
to the talk list by Friday, January 27th. I created a wiki page that
includes a description of the current implementation, both options, and a
few sample workflows to show how these new approaches differ:
http://wiki.collectionspace.org/display/collectionspace/Phase+III+Location+and+Movement+Upgrade.
We do also have a wiki page for location and movement use cases - if you
have a use case that isn't helped by either the current or proposed
options, please post it!
http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Use+Cases
.

Thanks everyone,
Megan

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

Note: we have the notion in all our authorities of items that are inactive,
and these (I think) are already being filtered in calls for term-completion.

In addition, we can fairly easily define a new set of states for any
document type (including the Location records). We currently have most of
the records in a simple set that includes active and "deleted", and we
filter the deleted ones in the normal UI (but allow access with reports, as
you suggest). We just need some UI to mark the Location record as
"inactive". Or, you can just delete them since we only soft-delete them
anyway.

Patrick

From: work-bounces@lists.collectionspace.org
[mailto:work-bounces@lists.collectionspace.org] On Behalf Of Michael T.
Black
Sent: Monday, January 23, 2012 5:59 PM
To: Megan Forbes
Cc: CollectionSpace Talk List; CollectionSpace Work list
Subject: Re: [Work] Upgrading Location and Movement

Hi Megan,

Option 2 sounds like the better/safer of the two options for us.  PAHMA
would need to be able to support multiple current locations (the wireframe
at
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Acquisi
tion makes it appear that it could do so by having Location be a repeatable
section), and to see (at least the most recent) previous locations.
Presumably this information would be in the right-hand column under related
procedures?

The "write once" functionality for locations sounded great to our
registrars.

Also, a request from our registrars and collections managers: They wonder if
it would be possible to implement the concept of "active" and "inactive"
location records?  The point is to hide inactive locations and to only show
active locations.  In general, current locations would be considered active
and previous locations (and erroneously created location records, as in your
"write once" example) would be considered inactive.  Without this, some
objects (i.e., frequently moved/exhibited/lent objects) would be drowning in
a sea of visible location and/or movement records.  Ideally, the current
location(s) and perhaps the immediately previous location(s) would be
active/visible, and others/older location records would require more work
(e.g., running a report) to get at.

Michael

On Jan 19, 2012, at 7:31 AM, Megan Forbes wrote:

CSpace Implementers:

We've gotten a lot of feedback about the current implementation of location
and movement, so have made upgrading this functionality a priority for the
next release. Based on feedback, user stories, and use cases, Angela and I
developed two alternative implementation options for your consideration and
comments. You are also welcome to respond to this email with new suggestions
for implementation that aren't covered by our proposed solutions.

Option I

Separate the current location and movement tab into two separate tabs, one
called Location and one called Movement. The new tab would have the same
functionality as all current tabs.

There are both pros and cons to this approach; for example, it would get us
out of the current situation where an object or group of objects must be
"moved" in order to be given an updated location. It would unfortunately not
solve the problem of a user being able to inadvertently change the current
location of a group of objects, if s/he did not know that the location
record were tied to multiple objects.

Option 2

Separate the current location and movement tab into two separate services.
Movement would remain a top-level service with its own tab. Location would
be modeled on the sub-record approach we have taken with Contact, where the
Location information group would be its own service, able to be appended to
any procedure (e.g. Cataloging, Intake, Acquisition, etc.).

On the plus side, this approach would provide a clearer link between an
object (or procedure) and its location. We would likely need to couple this
approach with a new UI for batch processing, so that we didn't lose the
ability to make changes in current location to more than one object at a
time. The sub-record model may cause some difficulties with report writing
or import/export, as the information group is not part of the record but
related to it.

The current wireframe for Acquisition shows how this approach would look,
with location as a repeatable group within the procedural record:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Acquisi
tion.

Additional Ideas

It has been suggested that making the location information group - whether
as a separate procedure or as a separate service - "write once" would help
to mitigate the potential for data or audit trail losses that are possible
with the current implementation and both new options. In other words, once
that data is filled out and the record is saved, it can no longer be edited.
To add a new location, update the current location, fix a typo, etc., a new
location record or group of fields would need to be created. We are
interested in hearing your thoughts on adding this piece of functionality to
either of the new options or to the existing functionality.

Feedback

Please submit your comments, critiques, questions, or alternative solutions
to the talk list by Friday, January 27th. I created a wiki page that
includes a description of the current implementation, both options, and a
few sample workflows to show how these new approaches differ:
http://wiki.collectionspace.org/display/collectionspace/Phase+III+Location+a
nd+Movement+Upgrade. We do also have a wiki page for location and movement
use cases - if you have a use case that isn't helped by either the current
or proposed options, please post it!
http://wiki.collectionspace.org/display/collectionspace/Location+and+Movemen
t+Control+Use+Cases.

Thanks everyone,
Megan

--
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  tel:718%20777%206834 6834

Work mailing list
Work@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace
.org

Thanks to those who have responded to this email. If you haven't yet,
please read the email, visit the wiki page, and let me know your feedback
by the end of this week. If you have any questions, let me know and we can
set up a time to chat via IRC, Skype, Connect, or whatever works for you!

Thanks,
Megan

---------- Forwarded message ----------
From: Megan Forbes mforbes@movingimage.us
Date: Thu, Jan 19, 2012 at 10:31 AM
Subject: Upgrading Location and Movement
To: CollectionSpace Talk List talk@lists.collectionspace.org
Cc: CollectionSpace Work list work@lists.collectionspace.org

CSpace Implementers:

We've gotten a lot of feedback about the current implementation of location
and movement, so have made upgrading this functionality a priority for the
next release. Based on feedback, user stories, and use cases, Angela and I
developed two alternative implementation options for your consideration and
comments. You are also welcome to respond to this email with new
suggestions for implementation that aren't covered by our proposed
solutions.

Option I

Separate the current location and movement tab into two separate tabs, one
called Location and one called Movement. The new tab would have the same
functionality as all current tabs.

There are both pros and cons to this approach; for example, it would get us
out of the current situation where an object or group of objects must be
"moved" in order to be given an updated location. It would unfortunately
not solve the problem of a user being able to inadvertently change the
current location of a group of objects, if s/he did not know that the
location record were tied to multiple objects.

Option 2

Separate the current location and movement tab into two separate services.
Movement would remain a top-level service with its own tab. Location would
be modeled on the sub-record approach we have taken with Contact, where the
Location information group would be its own service, able to be appended to
any procedure (e.g. Cataloging, Intake, Acquisition, etc.).

On the plus side, this approach would provide a clearer link between an
object (or procedure) and its location. We would likely need to couple this
approach with a new UI for batch processing, so that we didn't lose the
ability to make changes in current location to more than one object at a
time. The sub-record model may cause some difficulties with report writing
or import/export, as the information group is not part of the record but
related to it.

The current wireframe for Acquisition shows how this approach would look,
with location as a repeatable group within the procedural record:
http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Acquisition
.

Additional Ideas

It has been suggested that making the location information group - whether
as a separate procedure or as a separate service - "write once" would help
to mitigate the potential for data or audit trail losses that are possible
with the current implementation and both new options. In other words, once
that data is filled out and the record is saved, it can no longer be
edited. To add a new location, update the current location, fix a typo,
etc., a new location record or group of fields would need to be created. We
are interested in hearing your thoughts on adding this piece of
functionality to either of the new options or to the existing functionality.

Feedback
**
Please submit your comments, critiques, questions, or alternative solutions
to the talk list by Friday, January 27th. I created a wiki page that
includes a description of the current implementation, both options, and a
few sample workflows to show how these new approaches differ:
http://wiki.collectionspace.org/display/collectionspace/Phase+III+Location+and+Movement+Upgrade.
We do also have a wiki page for location and movement use cases - if you
have a use case that isn't helped by either the current or proposed
options, please post it!
http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Use+Cases
.

Thanks everyone,
Megan

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

Hi Megan

As Michael T. Black and PAHMA we would probably prefer option 2. And as PAHMA we need several current locations i.e. future locations. We also support the suggestion of active/inactive locations, and the notion of inactive locations being previous locations (i.e. locations with an end date).

The "write once" solution seems mandatory to us in order to avoid any confusion.

When a work of art is on loan to another institution or organization we record the Current Location as the name of the institution or organization in question. This means that we either need two separate Current Location fields - internal/external, or the Current Location field to be fed from both the Storage Location Authority and the Organization Name Authority if possible.

We have a couple of extensions that might be of interest to other implementers. We need a Location Type (controlled list: deposit, exhibition, office, permanent display, storage, loan out, etc.). Today we also record whether a location is connected to an exhibition (whether organized by us or another institution), so we have en Exhibition field fed by an Exhibition Authority (I'm fully aware that this will probably remain a SMK specific extension).

Regarding the Movement Procedure we also have a number of additions that other implementers might like to take into consideration. We need a Destination field fed by the Storage Location Authority. In order to plan future movements we suggest addition of a field for Movement Order Date (calendar date), and the Contact field as a repeatable group with a Contact > Role added to it.

Cheers,

Kim

Best regards,

Kim Brasen

Curator

T +45 3374 8460

Statens Museum for Kunst

Sølvgade 48-50

DK-1307 København K

T +45 3374 8494

F +45 3374 8404

smk.dk http://smk.dk/

Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes
Sendt: 19. januar 2012 16:31
Til: CollectionSpace Talk List
Cc: CollectionSpace Work list
Emne: [Talk] Upgrading Location and Movement

CSpace Implementers:

We've gotten a lot of feedback about the current implementation of location and movement, so have made upgrading this functionality a priority for the next release. Based on feedback, user stories, and use cases, Angela and I developed two alternative implementation options for your consideration and comments. You are also welcome to respond to this email with new suggestions for implementation that aren't covered by our proposed solutions.

Option I

Separate the current location and movement tab into two separate tabs, one called Location and one called Movement. The new tab would have the same functionality as all current tabs.

There are both pros and cons to this approach; for example, it would get us out of the current situation where an object or group of objects must be "moved" in order to be given an updated location. It would unfortunately not solve the problem of a user being able to inadvertently change the current location of a group of objects, if s/he did not know that the location record were tied to multiple objects.

Option 2

Separate the current location and movement tab into two separate services. Movement would remain a top-level service with its own tab. Location would be modeled on the sub-record approach we have taken with Contact, where the Location information group would be its own service, able to be appended to any procedure (e.g. Cataloging, Intake, Acquisition, etc.).

On the plus side, this approach would provide a clearer link between an object (or procedure) and its location. We would likely need to couple this approach with a new UI for batch processing, so that we didn't lose the ability to make changes in current location to more than one object at a time. The sub-record model may cause some difficulties with report writing or import/export, as the information group is not part of the record but related to it.

The current wireframe for Acquisition shows how this approach would look, with location as a repeatable group within the procedural record: http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Acquisition.

Additional Ideas

It has been suggested that making the location information group - whether as a separate procedure or as a separate service - "write once" would help to mitigate the potential for data or audit trail losses that are possible with the current implementation and both new options. In other words, once that data is filled out and the record is saved, it can no longer be edited. To add a new location, update the current location, fix a typo, etc., a new location record or group of fields would need to be created. We are interested in hearing your thoughts on adding this piece of functionality to either of the new options or to the existing functionality.

Feedback

Please submit your comments, critiques, questions, or alternative solutions to the talk list by Friday, January 27th. I created a wiki page that includes a description of the current implementation, both options, and a few sample workflows to show how these new approaches differ: http://wiki.collectionspace.org/display/collectionspace/Phase+III+Location+and+Movement+Upgrade. We do also have a wiki page for location and movement use cases - if you have a use case that isn't helped by either the current or proposed options, please post it! http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Use+Cases.

Thanks everyone,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800 tel:718%20777%206800
Direct 718 777 6834 tel:718%20777%206834

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