Skip to end of metadata
Go to start of metadata

Date

Call-in Information

Time: 11:00 am, Eastern Daylight Time (New York, GMT-04:00)

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. Brian Lowe
  2. Ralph O'Flinn
  3. Andrew Woods
  4. Mike Conlon
  5. Steven McCauley
  6. Huda Khan  (star)

Agenda

  1. What are folks working on? What are the local priorities?
  2. Sprint update (June 17th - 28th)
    1. External Search

      1. Merge 'sprint-search' (vivo, vitro) into 'develop'?
        1. Ralph is refreshing "devsprint" today that will bring in develop, sprint search, and tickets.
    2. Enable connection of decoupled, read-only "profiles" user interface to VIVO

    3. Define "shapes" of VIVO entities

    4. Dockerize appropriate components

  3. TAMU Scholars / VIVO Scholars Entities
    1. Domains related to representing scholarship
    2. VIVO classes
    3. TAMU data model
    4. VIVO UI default expectations?
  4. New feature: Messaging
    1. Based on the IndexingChangeListener pattern
    2. Potentially with RDF-Patch bodies
    3. Early development
  5. Working towards the VIVO 1.11.0 release
    1. Landing Design - External Search
    2. Other tickets we want to include?
      1. Docker work:
        1. VIVO-1679 - Getting issue details... STATUS  - Don Elsborg to review?
        2. VIVO-1680 - Getting issue details... STATUS  - Don Elsborg to review?
        3. VIVO-1682 - Getting issue details... STATUS  - Ralph O'Flinn to review? - Now in https://github.com/vivo-community/vivo-docker2
      2. VIVO-1670 - Getting issue details... STATUS
      3. VIVO-1415 - Getting issue details... STATUS
      4. VIVO-1692 - Getting issue details... STATUS
    3. Release manager?
  6. Tickets

    1. Needing additional review
      1. VIVO-1692 - Getting issue details... STATUS
      2. VIVO-1687 - Getting issue details... STATUS
      3. VIVO-1675 - Getting issue details... STATUS  - Benjamin Gross?
    2.  Received Tickets...

      T Key Summary Assignee Reporter P Status Resolution Created Updated Due
      Loading...
      Refresh

Tickets

  1. Status of In-Review tickets

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due
    Loading...
    Refresh

  2. Received

     Click here to expand...
     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due
    Loading...
    Refresh

    1. VIVO-1666 - Getting issue details... STATUS

      1. (re-)Raises interest in reconsidering first-time, every-time, tdbconfig design

    2. VIVO-1665 - Getting issue details... STATUS
      1. Should be low-hanging
    3. VIVO-1663 - Getting issue details... STATUS

      1. Where does this stand? What is needed to add more person identifiers to VIVO?

    4. VIVO-1644 - Getting issue details... STATUS
      1. Mike Conlon : thoughts on where this stands?
  3. Bugs (1.11)

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due
    Loading...
    Refresh

Notes 

Draft notes in Google-Doc


Edit capability

Ralph: Changing the editing front-end? Come over to the dark side and join the React effort.  (Even used the word synergy. Ralph comes out swinging hard. )

Mike: Editing challenges: (a) russian doll problem (editing object A requires also editing object B and so on).  VIVO approaches this by using custom forms for editing (sometimes) and sometimes having the user navigate all the nested relationships.  (b) Certain values should be picked from lists so we don’t have 1 million ways of stating a particular department/university. Lookups/controlled vocabularies.  

Mike: https://www.project-freya.eu/en/blogs/blogs/the-pid-graph -> working on research graph editing problem.  (son of Thor. that’s right, he went there. Oh wait, Thor was a project.)

  1. Current approach VIVO UI takes:
    1. Take RDF from a page for a given entity
    2. Currently, looking at class of objects
      1. what properties are supported by ontology
      2. what properties exist
      3. are any properties controlled
  2. A "shapes" approach
    1. Karma and The Pump already do a shape->rdf mapping

    2. These tools have already analyzed the nature of the shapes

    3. These tools are still more complex than is currently palatable

      1. Maybe create as a service?

      2. Ingest tools could be smarter (e.g. pulling DOI data)

    4. Shapes provide for expectations in the UI

    5. not all data in the triplestore are not represented in shapes

      1. ability to create custom shapes?

Andrew: Can we align local priorities with the core development priorities?

(We’re all friends)

Ralph: Focusing on core stuff and will move to local later

Andrew: Trying to wrap up sprint work that remains from past sprint.  VIVO scholars task force has own sprint underway focusing on read only UI - and this is in line with the work for this sprint.  Pattern: extracting data from VIVO into externalized search index and then UI built off that index.

Entities.  Where it’s at. Expectations around UI.  

Actions

  •  

Previous Actions


  • No labels