Skip to end of metadata
Go to start of metadata

Date

Call-in Information

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

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1.  Don Elsborg
  2. Ralph O'Flinn 
  3. Andrew Woods
  4. Huda Khan 
  5. Jim Blake (star)
  6. Steven McCauley
  7. Alex Viggio
  8. Mike Conlon

Agenda

  1. Notes from the Architectural Fly-in

  2. Mailing list messages

    1. Re: help related to facetview in vivo - Facet view expertise, anyone?
    2. jquery.scrollTo error - Do we need to upgrade `jquery_plugins`? – Has anyone else been able to reproduce?
    3. No Subject - "How can I add more associated profiles for that particular  editor."
    4. Freemarker Template Error
    5. [vivo-tech] help regarding the custamization
    6. [vivo-tech] Inferencing engine not adding triples needed
  3. Status of In-Review tickets

     Click here to expand...

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

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

      1. Only touches one file
    2. VIVO-1670 - Getting issue details... STATUS  

      1. Kitio Fofack ? Benjamin Gross ? Orcid and i18n

    3. VIVO-1668 - Getting issue details... STATUS  

      1. Only touches one file

    4. VIVO-1667 - Getting issue details... STATUS  

      1. Low-hanging - need one more reviewer

    5. VIVO-1656 - Getting issue details... STATUS  
      1. Is this feature of broader interest?
    6. VIVO-1643 - Getting issue details... STATUS  
      1. Andrew Woods to look into
    7. VIVO-1642 - Getting issue details... STATUS  
      1. Mostly trivial, with conversation around Tomcat version support
    8. VIVO-1641 - Getting issue details... STATUS  
      1. Relatively straight-forward bug fix
    9. VIVO-1661 - Getting issue details... STATUS  
      1. An important step for i18n... resolves many other open issues
    10. VIVO-1659 - Getting issue details... STATUS  
      1. Low-hanging, documentation
    11. VIVO-1630 - Getting issue details... STATUS  
      1. Kitio Fofack to review?
    12. VIVO-1525 - Getting issue details... STATUS  
      1. Low-hanging... need one more review
  4. 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?
  5. 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

  • Notes from the Architectural Fly-in

    • Still needs work

      • Not yet reviewed by the entire team

      • Need more details, from the whiteboards, etc.

      • Ralph is pulling together material from the notes, trying to get the correct terminology for the tools.

    • When completed and reviewed, these will be brought to the leadership group and the broader VIVO community.

      • Looking to get consensus, and perhaps even buy-in.

      • Ideally, create a calendar to accomplish the action items in sprints.

    • Mike: the leadership group has discussed having a sprint starting on March 18, 2019. If we have a plan in place, the leadership will be more able to commit resources.

      • 2019 sprint schedule

      • March 18-29

      • June 17-28

      • September 16-27

      • December 2-13

    • Touch lightly on the contents of the (preliminary) summary of the Fly-in: https://wiki.duraspace.org/display/VIVO/2019-01+Architectural+Fly-in+Summary

      • topics included:

        • Ingest

          • Mike: what was the thinking about "editing in production"?

          • Ralph: not part of the first round of tasks. Focus on read-only GUI first, then move on to editing.

          • Jim: there was more focus on the read-only pages. There was some discussion of putting the editing functionality in a component outside of the VIVO frame (or core).

          • Andrew: again, the concept of "Shapes" or "entities"; i.e., a set of RDF that confirms to the shape of a Person.

            • In some installations, the only permitted edits are in the source systems, not in VIVO itself.

            • Also, if there is an ingest pipeline that includes "shape validation", then edits should come through that pipeline,.

          • Alex: Duke and others are looking at incremental updates, in additional to full ingests.

          • Don, steve: what are the "shapes"?

            • More than the data on the page -- Mike: the backend always contains more data than the page displays

            • Don: if the shape doesn't include all of the data on the page, then we need to do additional calls to create the page.

            • Mike: having the shapes forces us to think about the edges of the graph that represents an entity. "Your graph" overlaps with other people's graphs.

              • It's good to think about this!

        • Decoupling the UI

          • Do the "shapes" play into this as well?

        • Decoupling other pieces of VIVO (Triple-store, search engine, etc.)

        • As much as possible, independent components would be packages as Docker containers.

          • Allows (compels) independent development.

          • Facilitates cloud-based installation.

        • Are shapes customizable? (steve, Andrew) Andrew says this will be true. Steve: if we are going to tighten down the entities, apply schemas, then why not use a relational database? Why not just scrap the existing code base?

          • Ralph: the shapes and schemas are to help with ingest and to help with the UI, without breaking things that we have been supporting.

          • Mike: the LOD is primarily for the RIM application, If you are only interested in putting profiles on the screen, then any application can do it.

          • Mike: also consider, why is a company like MasterCard hiring ontologists? What do they see as the value of semantic tech?

          • Steve: don't you lose that flexibility/power if you start enforcing shapes? Mike: it's a balancing act. Jim: there might be other paths that reach around the shapes validation.

          • Steve: After 20 years, do we see any real results from RDF? If anything, the point of a triple-store is that it's schema-less. The developers must accept the burden of data validation.

          • "Blah-blah-blah" maturity of the technology. Hang out with the Europeans.

          • Alex: Justin was talking about SHACL etc as a lesson learned from the RIALTO project. this and other evidence suggests that this is not a wayward concept.

          • Don: shapes could be used to prohibit data, or perhaps just to flag data irregularities.

  • Status of in-review tickets

    • There are two tickets that are small changes and that need one more review.

Actions

  •  

Previous Actions

  • Brian Lowe  confirm LDF server issue with TDB content stores
  • Don Elsborg - add jira tickets for abox/tbox use cases - one ticket for each use case
  • Brian Lowe  - check with ontology group on handles
  • Alex Viggio will bring news of Elasticsearch instead of Solr up with Product Evolution.  


  • No labels