2018-02-22 Metadata Management Meeting Notes

• Talked about mechanisms for getting feedback. Preferred solutions: Via SIG, Comment on Discuss, Communicate with Product Owner.
• Facilitator of roadmap for v.1 will wait for Harry Kaplanian to come back.
• WorldCon planned for May may have a date change, possibly to mid-June. That is to be confirmed.
• Dracine Emphasize reading Holly's weekly status report.
• [LINK to Google Folder: https://drive.google.com/drive/u/1/search?q=OLE%20Project%20Report%20]

• March 7: Roadmap update and demo (Harry and developer TBD)

https://discuss.folio.org/t/folio-location-model-and-wireframes/1606

• Cate showed slides concerning the location model
• The Consortia SIG posted input on this on Discuss
• Location Model
  • 3 Fixed Levels: Institution, Campus, Library (Also Parking Level, but this is not part of the hierarchical
    location structure. This can be used for anything we want. This won't display at all.)
  • Call Numbers are not part of Locations at all. Lynn said, it had been discussed, "Call Number" would be in the Parking area.
  • Location is part of the item metadata.
  • Why a hierarchy, as opposed to flat. Slides explain advantages.
  • Why is "Parking" flexible and not a hierarchy? Slides explain. Still open discussion as to whether or not hierarchy can be divorced from Parking. Loan rules may complicate that model.
  • Jason Kovari (in chat);

    "are stacks management colleagues involved in the other SIG that has reviewed this? if not, would be great to include them in the parking discussion. From my position, I can give thoughts but i don’t have the use cases for parking off-hand"
    
    Cate: She is not sure.
    
    Jason: More granular use cases will come from Stacks Management.

• • Cate showed a slide of Location CRUD UI

    • Locations could auto-populate
    • Christie Thomas asked if relationships can be built from the Parking assignments

    • Ann-Marie emphasized the need for a unique location codes, that can go down to the smallest unit.
      
      

  • Assigning a Location to an item or holding

    • FOLIO will support permanent and temp location.
    • RA SIG made suggestions that include having the ability to set permanent and temp locations at holding and item level.
    • Assigning a Location screen is very simple, with only Permanent Location and Temporary Location fields available.
    • Lynn pointed out that call numbers will not work as a Parking feature, since it is essentially a unique identifier.
    • Suggestion is that call number metadata will fall outside of Locations. Call number is probably a property of the item itself.
      
      
  • Christie Thomas: Does the location code drill down to the parking lot? Cate - yes - the code represent everything defined.
    
    
  • Location hierarchiy will be related to loan rules.
    
    
  • Ann-Marie brought up the idea of locations for electronic resources. Is there a general running philosophy in FOLIO? Cate has been focused on physical items. FOLIO is set up right now so permanent location is required. Does everything in the inventory have to have a location? Therefore if there is e-content does it have to have a location?
    
    
  • Laura: If locations will be used as a filter, and there are not locations, what are the ramifications?
    
    
  • Lisa (from TAMU) - (in chat) - "

    "Location for e-resources: We are using 'www' but it's because Voyager makes us have a code. Is a good point: the 'www' lets us filter"

  • General group thought: for electronic resources locations may be needed.

 refined UX work on the Advanced Search page

Faceting search will change to eliminate non-possibilities from displaying. (Shopping online example: If 7 1/2 shoes are not available in black, black will not show up as a faceting color option for the shoes.) FOLIO's faceting will work with these ideas.

Text searching will be an option as well, using Boolean operators or indexing indicators.

There is an explicit interface, an implied one, and a Google-type search field.

Bookmarks - there will be a bookmark type that is a fixed list, and another that is based on a search, so results are dynamic, based on a saved search. This means there can be no ambiguity in the interface. The faceting mechanism describe above will not be beneficial in this dynamic search scenario. Users should not be confined to those limits in this "canned search" scenario.

Laura Wright (in chat): "The dynamic bookmarks concept is really exciting."

They are getting to a point to where they need to define this functionality in detail.

If people have thoughts or ideas on this, please add to a Discuss post that Filip will put up.

Lynn: If anyone is interested in participating on this subject in more depth, contact Lynn.

Next week: We will return to the conversation on the Simple Search interface on the inventory screen.