2020-06-03 EMWG Meeting

Attendees: Lisa, Jason, Christie, Jim, Steven, Charlotte, Jacquie

Agenda:

• Action Items from 4/22 meeting

  • For next meeting: all members go into the use cases / areas of work spreadsheet... and expand/describe, etc., features that would fall within the Entity Management epic. All of this is draft so don't feel like thoughts need to be complete to input information. Getting started for POs wiki page can help explain the epic/features context. 

• Next step for work areas

  • Diagram: https://drive.google.com/file/d/1RgnExbZBZ4OusRQ0LDFvSTSTNnV5SdlK/view?usp=sharing (Christie)

    • makes sense of functional requirements and how they relate to each other

    • Questions/comments:

      • Two entity SRSs: why more than one?: Trying to think thru what it means to have abstraction layer (to facilitate local data and external data from many sources with different properties, etc.) with local updates that may not align with external data sources. May need different types of storage in different formats

      • Clear / makes sense

      • may or may not be well-enough represented in chart: entity records could be local data OR sourced from cached external data OR refreshed in real-time

      • current data flow: everything coming thru SRS to Inventory. In this case, arrow coming from SRS to Inventory but also double-arrow going between Inventory and Entity Management App; when does data flow from Inventory to Entity SRS?

        • possibly for controlling headings

        • reference data currently in FOLIO that are using internal UUIDs rather than external identifiers : should be using external identifiers whenever possible. Problem: if update to resource type or carrier type vocabulary, cannot update that automatically since UUIDs for these terms will vary per FOLIO instance

  • Jira feature drafting on Work Area spreadsheet: https://docs.google.com/spreadsheets/d/1h2qJrlPIGKKIF9GGzfgtNwgRQw7AhmAD4G23ZTCHDzg/edit?usp=sharing

    • Jacquie: question around "hubs" and "opus" and whether those should be in the Entity App as compared to querying.

      • From data modeling standpoint, would this be a different data type OR would the Work entity just need to abstract different types of works. The same goes for all different types of Works (e.g.: LRM, etc.) OR if we have a single Work type and abstract from there

      • less about abstracting than revealing the relationships between works

      • would it be safer if use case is more about flexibility in types of entities being managed rather than specifically talking about hubs, opuses, etc.

      • perhaps ensure that we include the full area of entities (e.g.: agents, locations, works, superworks, etc.)

      • geographic region is reference data but also entities and also amorphous and updated, etc. 

      • if we are scoping what we want to achieve with each of the features (doing that with the use case description and user stories) but can also add outstanding questions to be discussed for us to capture... (e.g.: in this given feature we want to address this discussion)

      • Do Works and Superworks need their own Feature or do the Entity Features need to somewhat generic to then list out the various entity types? Put these in the use cases not the description 

      • NEED: Overview / scoping document that provide decisions and background

        • provide description of what entitie types we are discussing.

        • wanting same kind of flexibility that Inventory does... where tenants can decide which entities they manage

        • this can allow us to discuss extensibility

        • use cases in spreadsheet do not necessarily provide cohesive story for the features... this would

        • question: is there a hierarchical issue with superwork and work that would need to be address; or are all entities on the same hierarchical level

        • need ability to create relationships between entities (e.g.: parentOf, childOf, siblingOf, relatedTo)

        • sidestepping some problems that we will eventually run into with hierarchical inheritance. one could say "for this entity, one can define the elements that exist in this entity"

        • aligned example: Inventory - what it is and what it is not; CODEX visionary document

        • two years ago we were at a face-to-face talking about authority management in MARCcat. need to address how this work relates 

        • Next two weeks:

          • Jason will start the document

          • Steven: yes

          • Lisa: yes

          • Jacquie: yes

          • Christie: yes; can start after this week

          • Charlotte: yes

          • Jim: yes

    • To give to MM-SIG

      • overview document

      • features draft spreadsheet

      • diagram (embedded in doc)

Action Items:

• Jason: download a PDF of the diagram for the wiki

• Jason: start the scoping doc

• Jason: send Doodle

Upcoming meeting(s)

• Jason unavailable 6/17. Someone else willing to run meeting? If not, should we reschedule for another day that week?

  • reschedule

Future Meeting topics:

• what is the approach in FOLIO wrt: data modeling?

• what kinds of authority control services are expected in MARCcat?

• What is the relationship between SHARE-VDE & the J. Cricket editor with the work we're planning for FOLIO?