Location and StorageLocation discussion
- Patrick Schmitz (Unlicensed)
Email 1 - a thread between Patrick and Megan
Patrick –
Might be easier to have a call about this – it seems that some of the below questions conflate storage location with geographic location (should be two separate authority files), but my answers are in line.
As far as I know there isn’t a wireframe for the place (geographic location) authority, but the schema is here:
http://wiki.collectionspace.org/display/collectionspace/Place+Authority+Schema
The schema for storage location: http://wiki.collectionspace.org/display/collectionspace/Storage+Location+Schema, although it should be noted that this is something that will definitely be customized and expanded by every adopting institution.
M
--------------------------------------------------------------------------------
From: Patrick Schmitz pschmitz@berkeley.edu
Sent: Tuesday, January 19, 2010 8:03 PM
To: Forbes, Megan; Angela Spinazze
Cc: 'Chris Hoffman'
Subject: Location and Movement stories
Looking at: http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Control+Schema
and
I see some disconnect between the information that a user can record, and what is in the schema (e.g., person responsible for the movement, purpose, etc.)
There is a good deal of work around these stories that I would like to get a handle on, to determine what we really have to do for 1.0. Here's a list of some questions I have. Most of the below comes from someone's idea of what CollectionSpace should be able to do, at least at some point (if not in 1.0). Clearly, this is more than we can do, but I'd rather not make my own calls by fiat, so your help will be much appreciated.
E.g.:
- What other uses of location authority references are anticipated in 1.0? I.e., in addition to storage location:
- Will we support provenience (found at location)? I hope so, or we cannot support PAHMA, or most of our nat.hist./life sci collections.
Can provenience be handled by a field/set of fields pointing to the place authority? If so, then yes we can support it. - Are there other locations? E.g., an object might have been purchased at one location, and is presumed (or attested) to come from another.
There can be any number of fields pointing to the place authority. The cataloging schema, for example, includes fields to note where something was produced, where the materials it is made of came from, and so on. If these fields do not support every story, it doesn’t seem like a big deal to add more.
- Will we support provenience (found at location)? I hope so, or we cannot support PAHMA, or most of our nat.hist./life sci collections.
- What search functionality is implied or assumed, based upon location (especially upon location that is represented in an ontology that has lat/long info):
- Can they search on "broader concepts" and expect to see all the objects stored in all "narrower concept" locations (search on Albany and see the PAHMA stuff in their warehouses up there)? I presume yes, and so this should be a user story.
This seems like a larger issue around searching within hierarchical vocabularies. I think that giving users the ability to include all narrower terms in search results is something we should support in 1.0. - Can they search on a point location and expect to get all items stored with some specified radius of that point, using some geospatial libraries that can do the math where we have lat/long for objects? If so, this must be laid out in a user story.
This seems out of scope for 1.0, given your comment on #5 below. - Can they search on more abstract concepts that are features of storage locations, e.g., "moveable", "exhibit space", "researcher work areas"?
If they capture that type of information in their storage location records, they should be able to search on it. - Can they search on height/altitude, as well as lat/long?
- Can they search on relative height? This was a specific request from PAHMA, to determine which objects were located within 18" of the floor during a flood. The floor in question was the second floor of a building (flooded from a failed pipe above), and so absolute height was not enough.
Again, if this type of information is captured, I don’t see why searching would be an issue. If we’re asking the system to determine from storage location that something is 18” off the ground, that is probably not in scope for 1.0.
- Can they search on relative height? This was a specific request from PAHMA, to determine which objects were located within 18" of the floor during a flood. The floor in question was the second floor of a building (flooded from a failed pipe above), and so absolute height was not enough.
- Can they search on an abstract geographic concept, like "within 100 miles of the coast"? This is more for the provenience (found at location) than storage, but I presume we have to support that as well. I would beg to say we cannot support this level of geospatial reasoning in 1.0.
Agreed, this seems like something we can add to the to-do list for the Mellon Phase 2 grant.
- Can they search on "broader concepts" and expect to see all the objects stored in all "narrower concept" locations (search on Albany and see the PAHMA stuff in their warehouses up there)? I presume yes, and so this should be a user story.
- How much functionality is expected from the Location authority?
- Do we support broader/narrower locations? I presume yes. This should be described somewhere, ideally in the location/movement stories area.
Yes, both the storage location and place authority should be hierarchical. I think the TGN is polyhierarchical. - What abstractions do we need to support?
- Do we distinguish between political and geographic areas ("southwest" has parts of CA, plus most of AZ and NM)? Do we allow both and translate, or let them switch back and forth?
What are folks using for their place authority? Does the Hearst (for example) maintain a local list, TGN, or a combination? This seems like institutional preference. Translating seems out of our scope, as again, it would be up to the institution. - Do we support geographic features, like rivers? Note these belong to multiple states.
Natural features can be managed by the place authority. - Do we support built-world locations? (I presume yes).
- Do we support buildings, as narrower locations?
- Do we support floors and rooms and model the containment within a building?
- Do we support shelving units, which have shelves, which have runs from some origin? AIUI, this is what the archivists need.
Depends on what you want to use the built-world locations for. If we’re talking about describing where an object in the collection is stored, that’s the storage location authority. If we’re talking about describing a built work in a catalog record (e.g. your history of art visual resources collection may have a slide of a painting of the Parthenon), those generally fit into a subject authority.
- Do we distinguish between political and geographic areas ("southwest" has parts of CA, plus most of AZ and NM)? Do we allow both and translate, or let them switch back and forth?
- Do we support broader/narrower locations? I presume yes. This should be described somewhere, ideally in the location/movement stories area.
-
- Should we be able (on import or via the UI) to translate between lat/long and named location?
- How flexible or smart should this be?
- E.g., if they enter a lat/long, do we give them a set of matching locations for them to choose from among?
- If they give us a new location to add to the authority, do we insist on a lat/long?
- What translations do we do between/among geospatial systems (e.g., for lat/long specification)?
Again, can we keep geospatial wrangling for phase two?
- What accuracy should we provide for lat/long?
Can you clarify what you mean by this? - Do we need to make some distinctions within the location authority between locations that are appropriate for storage, versus those that will be used for where an object was found? I presume yes, but have also heard about edge cases where something was found in a built-world structure, so...
Again, these are two separate authorities. - Do we support temporary built-world structures, like exhibition structures?
Sure. Places can have a lifespan. - Do we support movable built-world structures, like roll-around carts (this is another specific request from PAHMA). Tracking the location of the cart is not dissimilar to the case of tracking a tray of specimens as it moves from fridge to fridge.
Sure. We’d have to think about it and get some use cases, but I don’t see why not. - Do we support synonyms (possibly museum wide, or temporally varying, or personalized) for locations. E.g., some departments call a cart "the little cart", while other departments know the same cart as "cart 21", and have their own notion of "the little cart". This is not a joke, but rather is based upon actual scenarios described by folks.
All our vocabularies should support synonyms. Making those synonyms temporally variant or personalized is another kettle of fish – can we get a use case for this, and an argument for how it would be easier than just a list of synonyms with notes? - Should we include support for ancient as well as modern locations? How ancient?
Again, I call institutional preference. If folks want to support ancient locations, I don’t see a barrier.
- Should we be able (on import or via the UI) to translate between lat/long and named location?
- What location authorities are we expected to include out of the box? TGN? Others?
- Even if we cannot bundle Getty ones, do we have to be able to import them easily? In what formats?
- Do we have to support updates from licensed external authorities?
We have the license to support TGN, which would be sufficient for MMI. We can poll our adopters to see what (if any) others they would expect.
This is just a start to the questions I have been wondering about. I really need some help clarifying the 1.0 functionality. I know it is kind of overwhelming, but I need to nail down some set of constraints on what is in and what is out. If something is out for 1.0 but we know we should do it, that is important to our approach (allowing for expansion). If something seems just plain wrong, that would be useful too.
Thanks - Patrick
EMail 2 from Patrick
The StorageLocation schema described at: http://wiki.collectionspace.org/display/collectionspace/Storage+Location+Schema is really confusing to me. Why would we duplicate all the hierarchy of structure into every record? This looks like a hierarchy to me, but if we store it this way, it will be harder to benefit from the hierarchy in search (since things like units and shelve numbers are just text, and not concepts linked into a hierarchy). It will be hard to represent a hierarchy as well, since we would have to build it from the text, on the fly. Doing things like searching for objects that are nearby, or objects near the floor (e.g., in case of flooding) becomes much harder.
The current model seems to struggle a bit with this, as there is an entry for both tray and box, when I would think that the storage would tend to be one or the other. Also, there is no way to have boxes within boxes, without extending the schema and all the associated code. I cannot imagine how the archivists would work with this.
I had assumed that there would be a hierarchy of concepts, perhaps typed to reflect concepts like a "room" and a "shelf". This would allow for easy extension: boxes in boxes, and sheets in envelopes in folders in boxes as the archivists require. It would make it much easier to move a shelf or shelving unit, since only one record (the shelf item) must be updated, instead of a ton of locations that all reference the unit.
This would leverage the same functionality that supports geo location, taxonomy, and others.
Because there is one place to describe a room or unit, the risk of mistakes with duplicates or misspellings is greatly reduced. Because it leverages functionality we're building elsewhere, we can ask questions like "what is stored near object X"? We can also more easily associated barcodes with items like Units, Shelves, boxes, trays, etc. The current model would make that functionality kind of messy to support.
I have seen systems that model taxonomy this was as well, forcing users to fill in the whole taxonomic tree for each specimen. This seems incredibly painful to me.