User stories drive development.  User stories may be contributed by anyone.

Megan is assigning stories to incremental releases in the Project Roadmap.  Only stories assigned to a release will be worked on.

Movement Control

Comments on the Location and Movement Control Schema

Michael: Only thing missing is external to this.
The external text/vocabulary to describe locations has to be hierarchical.

Richard: Location has to be one of our location objects; by default will be
hierarchical.

Michael: Comparison of schema to TMS.

Patrick: Schema - right kind of information.  The way the UI models this
isn't necessarily the way that the services will do it.  Could denormalize
the current location, or could count on the fact that for a whole number
of things we'll need to get the current value, when there's history.

Location and movement lumped together in a way that's hard to separate.

One use of location is storage location - a common meaning.
Movement is an activity; storage location is a state of reality
that *may* be bound to the activity.

Susan: Can storage location be used without movement?

Michael: Going forward for the last 10 years we have associated
them.  For old records, we may know they were stored in a
particular place, but have no movement record associated with them.

The way we use them, the act of changing the location creates
a movement event.

Patrick: Two ways:
* UI can explicitly create a movement, giving a reason.
* (As described above.)
* If nature of movement is going out on loan, will have
associated records: movement, insurance, transport.

Michael: One form of movement is to put 50 little nitskies
into a box or crate, and move the latter.  It may be a
permanent storage.  If it's moved, all of the objects
are moved.  True of any museum doing loans, preparing to
move, doing a surge.

Patrick: We talked before about a box coming in; the box
gets a location, and the objects in it inherit from the
box.  Structured objects: is the crate considered an
object or just a container?

Michael: We would consider it an object.  Not a cataloged
object, but an object.  We may repurpose it, like a museum
display case.  Considered a storage or shipping object.

Sanjay: Shelf is not a container; shelf is a location.

Patrick: Archive people may think the box is worth cataloging.
Box was so-and-so's box for their stuff.

Michael: We could "catalog" it without cataloging it.

Patrick: Grouping of collection objects.  Question is do
we mark a collection object as a container, or just consider
it just another object.

Richard: Set of bones from site 32 that nobody ever looked at.

Patrick: Until you've cataloged the components, you have to
treat it as an object.

Box will have to have a name, so it can be distinguished,
receive a label.

Michael: Palette 75.

Patrick: Easier for right now to model as a collectionobject.
If no accession number, just a container.

Michael: That would be fine.  We do name all of our containers
right now.

We will eventually catalog the individual sherds in a box.

Patrick: Could even be cases where someone has scribbled
something significant on the box.

Or we find some way to mark or designate a collectionobject
as a container.  Concerned about a proliferation of objects;
associations would need to be made with it as well.

Michael: We've gotten in trouble by considering a container
as a location; objects in the container inherit the container's
location, but that can change over time.

Collection managers often feel that palette or crate is an object,
when fetching it or working with it; it's natural for them.

Patrick: Parenting through multiple models; may not be a
preferred one in all cases.  As soon as you have part-of
relationships ... chess set pieces may not be the same as
a wing pulled from a fly; entomologists do that all the time.

Michael: Concept of natural grouping.  Chess pieces that all
fit in a box, versus chess pieces plus some salt shakers that
all fit in the same box.

Patrick: Will declare nature of constituent relationship:
is it a constituent part, or just something contained within.
In life sciences, not sure how break down, say, a wing versus
a tissue sample.

Susan: They have so many words for these in the botanical
gardens and herbaria context.

Patrick: Still just collectionobject-to-collectionobject,
but may create a vocabulary around the reason for the
constituent link; e.g. pages, folios, folders.

May create all as collectionobjects, generic predicate
that associates constituents, but then a vocabulary for
a reason.  Mixing implementation with model

Richard: User would need to assign a relationship
each time.

Patrick: Semantics to inherit location, when this
occurs.

Richard: We need to define this vocabulary and
semantics of it.

Patrick: "Proper" storage location and current location
for a chess piece is this chess box; can break that,
if a piece is removed; changes contained-within relationship.

Michael: Concept of a "home" location where a piece might
return when it comes back from loan.

Introducing new objects got us into trouble in TMS.
TMS made new kind of container, storage versus shipping
containers.  Would prefer keeping it simple.  Gallery
Systems folks made it harder to keep track of sets that
were already made.

Richard: Is the idea of a container - outside collectionobjects -
useful for collections manager.

Patrick: If clean model from UI that distinguishes between
this to a service that doesn't.

Richard: Lots of containers cluttering up insurance model.

Michael: That's true.

We're looking to broaden what we have cataloged to include
archival materials, including the ability to catalog "the
box," much like archives would, with the ability to catalog
the contents later.

In TMS, just a group, object package, can be annotated,
can't be searched with objects.  Will put objects into
a package to do updates for an exhibit, etc.

Patrick: Authored and query-based groups that people
want to manipulate as a group.

Richard: Doesn't mean they share intake records, etc.

Patrick: True.  Need to be careful about what we allow
to be associated with a group.

Highly useful to "Create a loan from this group, exhibit,
movement ..."

Michael: Yes.

Patrick: May be "just a crate," but later, "the crate
that held King Tut's crown" ...

Susan: Can you promote it?

Michael: As long as you can separate out the containers
from "real" objects for insurance, for a count of
objects.

Patrick: Incremental cataloging: first box, then
catalog four, then later catalog 10

Michael: We would say we have 300 fragments in a box.
Then catalog some of them.  We might later recatalog
the original container into "nothingness."

Patrick: Recharacterize the original object, then
clear out the box as an object.

Michael: In most cases, the last object standing
in there keeps the original number it had.
Although it doesn't always work that way.

Patrick: What is the count?

Michael: A month's debate over beer; we don't have
a real answer for that.  Lots of different answers,
and we shouldn't get too hung up on that.

Patrick: We characterize the box in some way,
counts will ignore it.  If it's a container and
has a count then take that.

Sanjay: Workflows may be associated with some
collectionobjects, may have to add exceptions
to ignore those.

Patrick: If they get handled like collectionobjects,
would also have exceptions for those that don't -
goes both ways.

Michael: If we had a box of sherds that noone
looked at, for in-UC system loans we may give out,
not to others.

Patrick: Would be interesting to identify workflows
where you'd actually want to make that distinction,
then identify how you'd want to treat it differently.

Safer to treat as collection object, with two different
types of grouping, one being "it contains," the other
being "it's the natural whole."

Michael: I can think of many others, for another day.

Schema ...

Has "normal" location (aka "home" location in other CMSes).

Patrick: Each information group is really its own schema.
Should a "normal" location go into each storage location.
Normal location changes a lot less often than the current
location.  Sticking the normal location into the repeatable
location is weird.

Michael: Problem I have is with the movement location as
not repeatable.  So we have all of these 'people' in TMS called
"Michael and Bob and Richard" - combinatorial.

Patrick: Within Movement Location, you should have
multiple contacts.

Michael: Yes.  They're all "involved" - it takes four or
six people to move a sarcophagus.  No other distinction
is needed between the people.

Might be a few different methods.  Even for people like
us who love data, documenting the different methods used
for a single move should be done in notes, if at all.

Patrick: All movements are "move to."  Should this be
"from" and "to."

Michael: What we'd like to go to, perhaps within 15 years,
barcode system, you 'bleep' on the drawer, identify yourself
by your card, can even bleep on cart to show method, if
you really wish.  Get to other end, assume same person,
same thing, and bleep on new location.  The 'from' location
might be implicit if it's already there.

Patrick: From and to are implicit in the history.

Michael: Kind of nice not to make that assumption,
have the movement event itself be a form of inventory,
such as "here's where I found it."

Patrick: Default 'from' is current location, but you
can override it.

Michael and Susan: Yes.

Patrick: Likely going to RFID, object, person, cart.
How libraries are doing inventory now, drive big
scanner down aisles of their books, saves phenomenal
amount of time.

Sanjay: Correlation such as container relationships
still a bit tricky with RFIDs.

Patrick: In some factories fixed scanners, don't
have to do anything, object, cart and person are all
crossing a scanner now.

Michael: RFIDs now under a penny each, still expensive
times four million theoretical objects.

Patrick: 670,000 real objects.

Michael: Plus every drawer, plus readers ...

Patrick: Dwarfed by time to put stickers on.

Michael: Do it as you come across it, much like
photographs.

Typo on location condition, note date
Note was written.

Michael: Object locations are private, may want a few
locations (e.g. warehouse) may be private.  If on exhibit,
public - case locations - may want public to know.

Patrick: Could do - get me all items from exhibit.

Michael: Rotations of items even during an exhibit.
Instead location based - any items within our gallery
can have their locations made public.

Patrick: If location is characterized as public,
those storage locations can be made public.

Michael: yes

Patrick: Implies a kind of class associated with the
location.  If can associate with tree and child
locations inherit from parent, one building is
a storage location, private; a gallery is public.

Michael: Storage, exhibit, and site locations - all
stored together.

Susan: Would need lots of types.

Patrick: Current Location is referencing an authority.
The authority happens to be the "Location information"
group.

Sanjay: Location security note?

Michael: Can't imagine using.

Patrick: Art museum might.

Workflow rules - should Location Security Note be supplemented by
a class or type?

Richard: Reason for Movement?

Omitted inadvertently?

Richard: SPECTRUM doesn't have it either.

Patrick: What is nature of Reason? Controlled vocabulary, or
link to something else, such as a Loan or Exhibit.

Michael: Would be nice to have controlled vocabulary, with
the ability to have an association.

Controlled vocabulary emphasizes that moves are non-trivial;
inventory, conservation, housing in better condition.

Every 2-6 months still add new item to that vocabulary.
E.g. building moves, floods.

Otherwise, could be fairly short, e.g. emergency, plus a note.

That's exactly what we'd want.

Patrick: Reason type, reason note, and reason references to others.

If you had a movement reason, would you put rest in note?

Michael: We just have a reason right now.  Notes for everything
in TMS, but awkward to both create and access; have to drill
down through 3 layers of tabs.

Patrick: In principal, reason and note are sufficient, but
also good to be able to associate with loan, exhibit.

Michael: Yes.

We do want to keep "plumbing emergencies" separate, so
is easier to have broader categories like "emergency."

Missing also:

Concept in TMS of "planning a move" and getting a tickler
date with that.  E.g. in 2011, the LA County Museum of
Art wants this item, the ability to put in future moves
helps with future loans, exhibits, researchers, moves ...

Susan: Help to avoid conflicts?

Michael: Would be great to have better and smarter.

Patrick: Heard at workshops - correlate conservation with
possible future loan or moves, so that we do the
conservation first.

Being able to model as generic activity around an object,
generic work rules such as "show me all objects with
future activities," or "when I'm adding an activity,
show me any future scheduled activities."

Susan and Patrick: Sounds like a shared calendar - "an
appointment calendar for an object." People would
understand that model.

Michael: Would help us avoid embarrassments.

Researcher scheduled for 6 months, coming from Australia,
loans people have sent it out.

Patrick: Concept of "from" and "to" for movements,
identify when the object is going out, coming back.

Michael: Out 8 hours for a class.

Susan: Conflict with other objects, such as duration
of loan or exhibit?

Michael: It's not at all uncommon for objects to only
be in for part of the time.

Patrick: Flag - you planned for this exhibit to be
two months, are you sure this movement should occur
at two weeks?

Exceptionally you might overwrite it.  For planning
purposes, might want to correlate movement length
with the length of the loan.

Business rules, configurable to do either "don't
allow," or "don't allow with override," or "flag."