Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attendees

(star)  Indicating note-taker

  1. Kitio Fofack (star)Don Elsborg
  2. Ralph O'Flinn Don Elsborg
  3. Andrew Woods  
  4. Alex Viggio
  5. Daniel Mietchen
  6. Violeta Ilik
  7. Justin Littman
  8. Chris Barnes
  9. John Mark Ockerbloom
  10. Steve Brown
  11. Mike Conlon
  12. Mike Conlon
  13. Huda Khan
  14. Steven McCauley
  15. Jim Blake
  16. Brian Lowe

Agenda

  1. Holiday reflections? Wikidata reflections?

  2. Design / Contribution process for larger features, examples:

    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1415
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1436
    3. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1545
  3. Leading up to the architectural fly-in, thoughts on refactoring / decoupling
  4. Resolved
    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1619
  5. Received

    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14802
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5

    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1666
       - Pending response from Brian Lowe

      1. Sub-question: Don Elsborgsuggesting simplification of firsttime, everytime, filegraph
    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1663
       - Where does this stand? What is needed to add more person identifiers to VIVO?

    3. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1671
       - Benjamin Gross : Does Stefan Wolff 's recommendation resolve the issue?

  6. Status of In-Review tickets

    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14416
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5

    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1667
       - low-hanging

    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1661
       - An important step for i18n... resolves many other open issues
    3. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1659
       - low-hanging, documentation
    4. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1641
       - relatively straight-forward bug fix
    5. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1630
       - Kitio Fofack to review?
    6. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1525
       - low-hanging
  7. Bugs (1.11)

    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14702
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


...

  1. Mike Conlon investigated wikidata un countries
  2. Less countries then he thinks it should have - 162
  3. This was entities instance of country – so that’s odd
    • Eg Albania wasn’t on the list, sounds inconsistent for country definition
  4. So how do we work with Wikidata to determine why the list is so short and how is it maintained
  5. Main question – how do we follow up
    • Don +1
  6. Mikes goal is not to update wikidata data
  7. Andrew noted that in Sem w3 list a wikidata question was monitored and answered by wikidata folks
  8. Mike C. — scholia seems very biased, very focused, working on large scale dumps. So if you want all papers from university of x, you might get nowhere
  9. Don – wikidata should be augmentation - non-authoritative.
  10. Ralph - wikidata should augment - also to deal with lag
  11. Don – wants to use wikidata concepts and use VIVO to map concepts between VIVO and wikidata - perhaps use openvivo for this. So try to store sameAs relationships between VIVO and wikidata. #  
  12. Use the VIVO triple store and VIVO editorial interface to maintain these relationships
  13. Mike - UFL has the same need - Research Intelligence

...

  1. How to address workflows that bring things in from multiple data stores and store in VIVO
  2. On the flip side, have exports from VIVO or a canonical data store that pushes data to VIVO.
  3. Different VIVO front ends - so a read only view
    Edit - can edit be separated from the standard view
  4. Complexity added with seperate VIVO and Vitro. # What are the pros/cons of collapsing the two. So who cares about Vitro that doesn’t care about VIVO.
  5. Steve McCauley - more interested in Vitro than VIVO. He works more with Vitro.
  6. Mike - Metabolomics (sp?) project also using Vitro with some VIVO ontology
  7. Steve - will use some Vivo ontology but not all since they departed from the VIVO display.
  8. Andrew - Steve - are there natural architectural patterns that you would have like?
  9. Steve - separating the display layer from the rest of the system. Arch is fine since they don’t use it for display. Entirely as a backend.Some things could be changed. Things like externalizing search which would make things more modular. Or database not being tied to SDB/TDB so have a different triple store. Would like ability to swap things in and out. We replicate the VIVO SOLR for back end purposes.
  10. Mike - a deployment pattern could be that there is no front end. So could have a non vivo front end like Brown. So facts on demand and you put them where you want them. Not all sites want a front end. Just facts.
  11. Andrew/Mike - research intelligence system
  12. Don - are we discussing graph, LOD, and semantics
  13. Mike - semantics allow swapping out entities


Actions

  •  Mike Conlon to find contacts at wikidata to answer technical questions. We need to know how to interact with the wikidata community when it comes to understanding and validating, or eventually updating their data.
  •  Don Elsborg to move forward with a firsttime/everytime config model discussion

Previous Actions

...